Reconstructing Project Management (1 of probably 9)

Does project management cover the management of the project front-end, the definitional, development stages, or is it concerned essentially only with execution delivery?  What should it be responsible for?  How far does it stretch into concept definition at one end and operations at the other?

Morris, Peter.  Reconstructing Project Management Reprised: A Knowledge Perspective.  Project Management Journal, Vol. 44, No. 5, October 2013, p13.

With this post I embark on what I hope will be a series of nine posts, which diverge considerably from how I have historically presented content on this blog.  My focus has been on PM Best Practices and, as a practicing PM, my posts – at least from my perspective – have been intended as practical guides for the functioning PM in the trenches.  For the next couple of months, however, I’m going to wander into the (cue theme from The Twilight Zone) wilderness of PM Existentialism.

Peter Morris authored Reconstructing Project Management (2013) and was invited by PMJ to encapsulate the book for its readers.  If permitted (I’ve asked the publishers of PMJ for permission, which is still pending, to quote from the article for this series), I plan to take nine questions that Morris highlights in the article (Figure 3 Current issues in project management as a discipline, p13) and add my commentary and color, hopefully without getting too lost.

However, I don’t want to give the impression that Morris’ article is these nine questions (which, by the way, are also on page 111 in the book) or, even, that they are the central theme.  In the article’s eighteen pages, Morris condenses, presumably, the topics, points, arguments and themes of two-thirds of his book.  I’m pulling these nine questions, then, completely out of context and I encourage you to read the article (and the book) to understand his thesis.  When I read these nine questions, though, they spoke to me so deeply that I felt compelled to explore them beyond the (here I avoid the use of “mere” or “just”, maybe “unadorned” works) concrete expression that Morris has given us.  Further, I believe there is a tenuous link to my series on Governance.

By tossing these questions, like grenades, on the floor without further expanding on them, Morris challenges us to face the assumptions and core values that define our profession.

Practically a post’s worth of preamble, so let’s get to it…

Enterprise leadership holds their quarterly off-site to review strategy.  They return and the business line VP needs to replace the legacy, proprietary application with a cloud-based SaaS application that is the market leader.  She assigns a director responsibility for accomplishing this, who engages a manager to lead the day-to-day tactical project delivery effort.  The manager, following the company’s methodology, prepares a business case, a charter, a staffing plan and a time and cost schedule.  These are approved by the Director and the project kicks off.

Who is the project manager for this project?

There is so much depth and complexity in Morris’ first question (above).  When I took the PMP certification exam, the model project manager we were told to visualize was the construction PM for whom a sponsor provided money in exchange for a commitment to scope and time.  At that time I worked for a large IT consulting and project management company with aspirations of offering clients responsibility to deliver their projects – high value contracting based on responsibility for deliverables, not time and materials.

Fast forward to the world of today:  that company is limping along as a has-been, ne’er-heard-of-‘em firm and the PM community is bifurcated between reality and wants.  As a profession, we want responsibility for the projects, but in an enterprise reality where, instead, we are just responsible for delivery for someone else.

Executives, managers, and operations leadership make the strategic decisions about what projects to run and have ownership of the operational project decisions (funding, scope, who will be on the team and whether to pull the plug when things go akilter).  They don’t want the mundane tactical responsibilities (and risks) of project delivery, but at the same time there are three market factors that prevent the elevation of professional project leaders into that sphere.  First, those operational leaders, having gotten where they are, are not going to trust someone else with the responsibility (and esteem) for success with their vision.  Second, without projects, their jobs are just, let’s face it, boring.  Projects are the spice to the same daily gruel they otherwise consume (and that consumes them).  They live vicariously through our efforts.

The third condition that reinforces the status quo is that, if other project managers are anything like me, we love delivering projects and don’t want those boring, mundane operational responsibilities.  We are too happy doing what we’re doing to want to trade this for the better world where projects are run by project professionals, but at the cost that we are tied down to quarterly budget cycles, annual personnel reviews (which, btw, should be annual budget cycles and quarterly personnel reviews), product support and maintenance, and enforcing all the petty practices and policies of the very model of a modern major enterprise.

So we take the bones we’re fed, we deliver the project to scope, time and cost (or, in a more mature organization, to process), celebrate the successful delivery, hand it over to them to support, and happily walk away to pre-storm with our next project team.

© 2014 Chuck Morton.  All Rights Reserved.

What is the Most Important Skill for a Project Manager to Have?

Srini was a veteran project manager, but had never coached a junior project manager before.  Sarah was a newly hired junior PM who had the right credentials and some experience.  They were at lunch and Srini was describing the organization, the key people Sarah needed to get to know, and the background for their project processes.  He was winding down when Sarah asked him, “What is the most important skill I should develop to be a successful project manager?”  With the cynicism that years of political maneuvering had created, he thought, “How can someone be so innocent?”

The introductory paragraph is fictional, but I encounter this question regularly on LinkedIn group forums.  I almost always want to throw my hands in the air and scream at the person who asked this question how they could be so naïve.  Or maybe they are intentionally trying to cause trouble and controversy.  Either way, the question is just So Wrong.

But then I sit back, let my breath return to normal, and pop a few Metaprolol (no, I don’t really do that).  When I’ve calmed down, I realize there is an appropriate answer to this question.  (Before reading further, do you agree that there is an answer?  If so, what would you say is the most important skill for a PM?)

Let’s break this question down.  A PM has to have a variety of skills across several domains:  political skills (for navigating successfully within an organization), social skills (for dealing with stakeholders and motivating team members), emotional skills and technical skills in both the project and product domains.  How can anyone say, conclusively, that any one specific skill in any one of those areas is most important over all of the others?

Further, PMs operate across many organizations, industries, cultures, etc.  And whatever conditions may be appropriate with a specific team, they change and evolve over time.  So how can anyone say, conclusively, that any one specific skill is most important over all these different environments and at all times?

Realistically, they can’t.  Except…

Let’s take a momentary interlude here.  In one LinkedIn discussion I followed on this topic, the comments eventually reached the consensus that soft skills were the most important skill set for contemporary PMs.  I don’t disagree that soft skills are important for success, but, well, doesn’t the question assume that you have the hard PM skills?  And that if you don’t have those, you’re not a PM and, thus, the value of soft skills don’t apply?  Or, from another approach, can you say that, universally, soft skills are always more valuable than other skills in all environments at all times?  I think anyone stating that is naïve.  I mean that this way:  there are environments and times that demand other skills that are more important (even if you don’t encounter those conditions very often) and, if you haven’t, then you naively assume that what you’ve encountered is sufficient.

Getting back to the discussion then, what is the answer?  Is it flexibility?  I think that’s a good answer.  The PM often has to be flexible about how they mix and match the skills on a particular project or assignment, but, as good as this answer is, I don’t think flexibility is the best answer.

My vote for the best answer to the question “What is the most important skill for a PM?” is Balance.  Balance so accurately describes what we do:  we have to balance the inflexible demands of the iron triangle of scope, time and money.  We also have to balance our approach to each project to deliver precisely the right mix of soft and hard skills appropriate to that situation.  We even have to change at different times during the project which skills we present. 

If I answer otherwise – if I name any one skill – that indicates that I believe that one skill is universally more valuable than any other skill, which just is not the case.  It is the complete mix of skills, appropriately stirred, combined and presented in the right way at the right time that makes for a successful project manager over many projects over a long and successful career.

© 2014 Chuck Morton.  All Rights Reserved.

The Tailoring Rule

"Professionalism is knowing how to do it, when to do it, and doing it.”

                                                                                                - Frank Tyger

When people choose to complain about project management, one frequent refrain is the burden and overhead of all that process.  (I believe this is often a red herring, used by detractors who are concerned that project management best practices will expose their delivery weaknesses, but today’s discussion is to address the valid concerns for appropriate levels of process.)

A typical organization does many different types of projects of different sizes, styles and complexity.  For example, an IT department might have projects for:

• Infrastructure
• New software development
• Enhancement and maintenance
• Product selection, acquisition and installation

Since all projects, regardless of size, style or complexity have many common elements necessary for success, does that mean that the organization only needs one methodology?  Well, yes.  And no.

If the organization has one bloated methodology dictating that all projects must produce all deliverables from identical templates, then those people who complain about too much process have a (partially) legitimate complaint.  It’s legitimate because for most projects there will be too much process, but they are complaining about the wrong thing.

However, there are so many common and essential elements for project success that no organization wants to manage multiple (many?  dozens?) of different, but similar processes.  How to resolve this contradiction?

Both SEI’s CMMI and PMI’s PMBOK® Guide provide for Tailoring.  Tailoring is an important but rarely formally practiced principle.  In fact, in all of my years of consulting across a broad range of companies, I’ve encountered numerous cases where formal practices are ignored or circumvented because they are too onerous or just irrelevant, but in only one case have I worked at an organization that formalized process tailoring.

Even the description in PMBoK does little to suggest that the organization should establish tailoring in the formal processes:  Initiation and Planning includes “guidelines and criteria for tailoring the organization’s set of standard processes and procedures to satisfy the specific needs of the project” (27).  This description makes it sound like tailoring should be done inside the project to customize the organization’s standards rather than that the organization’s standards should specify the tailoring appropriate to different projects.

For example, an IT software development project, an IT software implementation project, an IT infrastructure project and a business process redesign project all have many similarities on how they should be run (they should all have charters, business cases, status meetings, risk logs, change management, etc.), but also significant differences (a new software development project won’t need the RFP activities in the implementation project and the BPR project will need a host of training and documentation activities that will not be needed for a back-office infrastructure project that has no end-user visibility).

Further, for a sufficiently small project, the charter could be fully contained within an email and the change approval process will need to be sufficiently streamlined, since long decision timeframes would jeopardize the delivery of the project.  In contrast, a long, complex, risky project wouldn’t want to make change decisions too informally or too quickly.

The process burden needs to be appropriate to benefit the project – designating those best practices that best assure project success – while addressing project risk without over burdening the project.  A requirements document for a small project might be a few pages, whereas the requirements document for a large, complex project could be a tome, with sections and subsections for business requirements, functional requirements, technical requirements, non-functional requirements, etc.

One size does fit all in project management, as long as that one size addresses the principles of successful project management.  (Is that a tautology?)  Organizations with best practices are clear about what processes are required and how those processes are customized based on type of project, complexity, size, risk.

The mistake often implied by those that complain about excessive process is that the situation would be better if there were no process.  But processes evolved because lack of process (chaos) could not be relied on to consistently deliver successful projects, whereas the use of the processes improved the project success rate.  The solution to excessive process burden (or bad process, for that matter) is not eliminating process.  Rather, the solution is to fix the process through lessons learned and continuous process improvement.

Of course, organizations are even worse at lessons learned and process improvement than they are at projects.  Look for my eventual series on lessons learned to address just this subject.

© 2014 Chuck Morton.  All Rights Reserved.

Command and Control

Command and Control: Nuclear weapons, the Damascus Accident, and the illusion of safety.  Eric Schlosser.  The Penguin Press, NY.  2013.

Command and Control, by Eric Schlosser, is not a project management book.  Quoting the inside cover of the dust jacket, “Command and Control interweaves the minute-by-minute story of an accident at a nuclear missile silo in rural Arkansas with a historical narrative that spans more than fifty years.”

The anecdotes, stories, and discussions in the book are about systems and practices in operations, maintenance and support.  But projects culminate in systems and practices in operations, maintenance and support.  Command and Control is a case study – or a collection of case studies – on topics near and dear to project management:  risk, management and control, communications management, and lessons learned.  I can recommend the book as a fascinating read for any number of reasons, but this is a blog on project management best practices.  Let’s look at a few lessons for us:  the few, the proud, the PMs.

Excluding military veterans, few of us will have the opportunity (if you call it that) over the course of our careers to participate in a true life-or-death project.  But the servicemen depicted in Command and Control worked too close to a nuclear core sitting on top of an unstable mixture of liquid fuel and oxygen packaged in a paper-thin shell and buried in an underground containment vessel cum concentration chamber.  The book describes occasions when the fail safes intended to protect them (and us) worked and, in minute by minute detail, one specific occasion when they didn’t.

Much of the book is about the history of super-secret military nuclear arms development and deployment during the cold war.  It is worth reading this book to see how often it is one person, championing a cause against a tide of resistance, who is responsible for the implementation of a failsafe or risk-reducing feature that ultimately saved lives.  I think this is an apt metaphor for my experience getting owners and sponsors to responsibly address both project and product risk.

I was also fascinated by the account of the unintended, unplanned testing of the limits of the launch complex blast doors – and the conflicted confidence, by the various players, in the structural integrity of those doors under catastrophic load.  Not to mention the comical -- in other circumstances – decisions to override, bypass and ignore the available protective features.  In our projects, how often, in our urgency to get a system out the door, do we face similar choices and make similar decisions?  For what our project deploys to production, do we ever plan for operational systems management in a disaster under realistic, degraded conditions?

Another relevant theme is organizational decision making under stress.  The US military operates in an hierarchical, command and control structure.  But when she’s about to blow, that structure broke down because of both communication limits and independent agency.  The fog of uncertainty when radios don’t work, the most knowledgeable person can’t be reached, the tools don’t give the information needed, leadership is communicating conflicted priorities, and different experts give contradictory advice at high volume, means that wrong decisions will be made – at all levels up and down the line.  Further, the guy in the bunker, face-to-face with the devil, may decide that he knows better what to do than the general sitting safely under a far-away mountain.  Or he may decide to follow orders anyway, despite knowing it’s the wrong decision.  The book tells the tale of a real event, so there is no magical fairy tale ending.  We as PMs need to understand that, for all our expectations that the team will follow where we lead, those team members are each independent agents with their own motives, priorities, and interests that may – or not – coincide with ours.

Another theme we can learn from is the lessons learned result.  It’s disappointing that over 50 years later, we still haven’t learned to address the systemic root cause of a failure rather than blaming the grunt on the ground.  After all, fixing the root cause means addressing a capability that management and leadership is responsible for;  blaming the grunt deflects the attention away from the upper castes.  This is a topic I am preparing to take up at length in the near future.

We as project managers have two levels of learning from Command and Control.  One is that we can see how things really work when the fan is spinning – it isn’t clean, it isn’t pretty, and it’s not like they describe in the textbook.  Just as importantly, we should also pay attention that our projects, which end and we walk away from, produce these things that people have to live with and work in.  It was projects that built the Titan II missile, the launch complex, the operational processes, and all the complex and complicated pieces that came together and, well, blew up.  It was our professional ancestors that built these products and systems.  What will our progenitors a half century from now be reading about us?

© 2014 Chuck Morton.  All Rights Reserved.

Conflict

"All polishing is done by friction.  The music of the violin we get by friction.  We left the savage style when we discovered fire by friction.  We talk of the friction of mind on mind as a good thing.”
                                                                                                - Mary Parker Follett

“Conflict is as inevitable in a project environment as change seems to be” (Vijay K. Verma, The Human Aspects of Project Management: Human Resource Skills for the Project Manager, Volume Two, PMI 1996).  So begins chapter 3 on Understanding Conflict.  (I have a hardcopy of the book around here somewhere, but for my refresher for this post, I re-read chapters three and four from PMI’s eReads member benefit.)

I completed my five-part series on governance in the project context and project conflict seemed the natural successor to that series.  After all, putting a governance system in place establishes a state of conflict that is beneficial to the project.  A good project manager and a good PMO will understand the different types of conflict and know when and how to use them for the project’s benefit.

I’ve worked with many managers and project managers that are conflict averse.  When I bring it up with them and point out what they are doing, they often readily acknowledge what they are doing and are still hesitant to change.  This style is consistent with the earliest management and project management practices, which was to avoid or reduce conflict.

Eventually, accepted practice was to allow natural occurrences of conflict to develop, the behavioral view.  The latest practice, the interactionist view, is to encourage appropriate conflict, much as implementing project governance creates a conflict between the governance team and the project delivery team, that, when done properly, benefits the organization and the project.  Verma goes much further into these three views.

The whole notion of stimulating conflict is difficult to accept because conflict traditionally has a negative connotation. However, the interactionist view encourages conflict. There is evidence that, in some situations, an increase in conflict actually improves performance (Verma, ibid, chapter 4).  However, too much of anything is detrimental.  They key is finding the proper balance (foreshadowing for a future post), as shown in this table from Verma’s book:

Table 3.1: The Value of Conflict
Positive Aspects	Negative Aspects
Diffuses more serious conflicts	Can lead to more hostility and aggression
Fosters change and creativity as new options are explored	Desire to "win" blocks exploration of new opportunities
Enhances communication if both parties are committed to mutual gain	Inhibits communication; relevant information never shared
Increases performance, energy, and group cohesion	Causes stress; creates in unproductive atmosphere
Balances power and influence if collaborative problem solving techniques are emphasized.	May cause loss of status or position power when both parties take it as a contest of wills and strive for a win-lose outcome.
Clarifies issues and goals Negative Aspects	Real issues overlooked as positions become confused with personalities

 So what is the best practice?  Expect conflict.  Find the proper balance between avoiding conflict and stimulating conflict.  This means both averaging toward the center of the spectrum, but also having a high deviation.  This way, conflict management becomes another tool available for you to apply appropriately as conditions warrant.

So are you a conflict traditionalist (conflict is bad), a behavioralist (conflict is natural) or an interactionist (conflict should be encouraged)?  How about the management and leadership (these, of course, are two different groups) of your company?  Does that explain your company’s performance?

© 2014 Chuck Morton.  All Rights Reserved.

Project Governance – Maturity Level V

"There is a universality to comedy.”
                                      - Simon Pegg

We have been building to this post for a while now.  This is the final installment of my series on project governance – or, more accurately, governance in the project context.  In the first post I introduced my arbitrary, tongue-in-cheek governance maturity level (gml).  Having covered all of the descriptions for project governance maturity up to this point, it is now time to reveal the ultimate state of governance of interest to project managers.

Historically, the highest level of governance is some variation on the theme of continuous improvement or optimizing, but I announced in my previous post that that was not the case for this maturity model.  And that post described the penultimate maturity level as alignment with organizational strategy, so what remains for the highest level of project governance maturity?

For strategic projects, there are really only three reasons that justify the project:  it increases revenue;  it reduces cost;  it is a regulatory requirement.  (Do you know of any other reasons that legitimately justify a strategic project?)  For most enterprises, what department has the highest stature?  Marketing?  HR?  Procurement?  FINANCE (hint hint)?  Of course it’s finance.  And it’s time finance started seeing projects as generating revenue or reducing expenses.

In May, Angelo Baratta presented a webinar for PMI’s Information Systems Community of Practice titled “The Value Triple Constraint: Project Value Left Behind” (PMI and ISCoP membership required).  In it, Baratta reminded us that projects have an economic benefit to the organization.  So often as project managers, we are focused on cost (along with time and scope) and leave benefit and value to the cost-benefit analysis or the charter – and to bean counters or stakeholders with “higher pay grade.”  But because there is this positive financial component, delays (among other choices) have a financial impact to the organization.

The highest level of project governance maturity, then, is when projects are recognized as enterprise assets.  Just like raw materials and capital investments, we (the PM community) should be lobbying to have our projects recognized as corporate assets.  This would immediately transition us to the big leagues.  Our babies would be elevated in stature within the corporate and political pecking order.  Project choices (delay, increase scope, cut scope, etc.) would have clear financial impact to the organization.  Getting resources, as Baratta noted in his presentation, would be straightforward to justify when the alternatives can be quantified.

Of course, these benefits don’t come without perils, but such is the consequence of maturity.  We will no longer be able to operate informally.  We will operate in the spotlight.  We will have to learn to speak “executive” (cut your vocabulary in half!).  Risk management will impact the corporate risk profile.  Governance in the project context will be integrated into the organization’s financial governance (think Sarbox).

One of the objectives of PMI is to have “Project Management” recognized as a discipline (or profession) distinct from “Management.”  A step in this direction is to elevate the governance maturity and to transition project delivery from a technical discipline to a financial discipline with direct consequence for the enterprise bottom line. 

From gml-I Chaos, gml-II Solution, gml-III Consultancy, and gml-IV Alignment, we have climbed the maturity staircase.  Getting to gml-V Capitalized is governance your CFO would recognize – the next stage in PMI maturity.

Has this journey been worth it?  What changes would you make to gml?  Or how would you define a project governance maturity model?

© 2013 Chuck Morton.  All Rights Reserved.

Project Governance – Maturity Level IV

The alignment of the project with stakeholders’ needs or objectives. (p30)

Project Governance: The alignment of project objectives with the strategy of the larger organization by the project sponsor and project team.  A project’s governance is defined by and is required to fit within the larger context of the program or organization sponsoring it, but is separate from organizational governance.  (p553)

                                                                                                - PMBoK v5

This is the fourth and penultimate installment of my series on project governance – or, more accurately, governance in the project context.  In the first post I introduced my arbitrary, tongue-in-cheek governance maturity level (gml) and expanded on the subject in the second and third posts.  With this post, we advance to describing gml-IV, moving beyond the strict focus on project governance.

Project governance is needed – that is, there need to be controls in place to assure project delivery according to the organization’s defined processes.  But project governance alone is not sufficient for most organizations.  Successful projects (completing projects successfully) assumes that the right and proper projects are being done.   In fact, The Guide to the Project Management Body of Knowledge (PMBoK) has almost no references to project governance.  All references to “governance” are either in the introductory first two chapters or are in an appendix (such as the definition, above).  As these representative quotes indicate, for PMI project governance is more about delivering the right project than about delivering the project right.  (In contrast, for Microsoft Solutions Framework, governance is strictly about delivering the solution.)

The interesting thing is, there is another accepted term for doing the right project:  project portfolio management.  But project portfolio management, like any other process or methodology, needs to be paired with a governance structure.  There need to be checks and balances, oversight, and independence.  These governance processes need to integrated with organizational governance, most appropriately around strategic planning and success.

With my next post, the final post in this series, I will introduce gml-V.  Everyone, of course, already knows that gml-V, like all good maturity models, will be about continuous improvement, what SEI CMMI calls Optimizing.  Surprise:  that isn’t what gml-V is.  So stick around, read the next post and be surprised.

You’ve read what I’ve posted on governance so far, so what would be your five governance maturity levels?  Specifically, what would you have for the highest level of project governance maturity?

© 2013 Chuck Morton.  All Rights Reserved.