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.

Planning or Delivery is More Important?

"Maturity of mind is the capacity to endure uncertainty.”
                                                                                                - John Finley

Which would you say is more important:  Project Planning or Project Execution?

There are lots of these question forms that are just meaningless, but this one isn’t.  You can have good (consistent, reliable) project delivery even with poor planning;  but you cannot have good planning without good delivery.

If you think about it even briefly, it’s obvious why successful planning requires reliable execution.  Planning is, after all, the projection of future activities.  The plan includes the activities to be performed as well as predictive criteria about the activities (start date, end date, duration, cost, etc.).  If you can’t predict the activities that will be performed, then the plan is flawed and unreliable.  If you can predict the activities, but the activity criteria are unpredictable then the plan is flawed and unreliable.

Reference Figure 1, a control chart example I created for this post.  Note that you cannot predict the quality of the result because the process is out of control (and apparently worsening).   There’s a saying that you can’t control what you don’t measure.  I’ll take that to the next level by saying that you can’t plan for what you can’t control.

Figure 1

 

Figure 1 and unreliable project delivery capability are prime examples of an organization that is not process mature.  This is comparable to the CMMI Maturity Level 1 organization.  To improve delivery, your organization needs to move up the maturity level capability for whatever methodology (e.g., P&SD PM or Consultancy PM) is most important (whether that is CMMI or OPM3, for example).

Since the essence of project delivery is the combination of planning processes with monitoring and controlling processes, this offers some insight on where to start if your organization needs to improve the project delivery capability.  First, capture and track (the right) project metrics.  Next, select the maturity model that is appropriate for your organization.  Then, begin systematically implementing and institutionalizing the processes in the maturity model.

Once you have the capability to deliver consistently, reliably and predictably, then you can plan and your plan will also be reliable.  Now that’s maturity.

Do you know how to use a maturity model to assess and improve your organization’s project delivery capability?  What has been your experience implementing maturity model capabilities?  What were the results?

© 2013 Chuck Morton.  All Rights Reserved.

Where to Find Risks

"Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so.”

                                                                                                - Douglas Adams

As I mentioned in my previous post,  Risk Buffers – An Example, this post is dedicated to identifying risks.  The only real way to find risks is by experience, and if you don’t have the experience yourself, then you must rely on the experience of others.  I’ll discuss three reliable sources for finding risks (but this is not exhaustive).

A taxonomy is a schema for classifying things.  The library’s Dewey Decimal System and the Species-Genus-Phyla (or whatever it is) system that biologists use for classifying animals are both taxonomies.  Risk taxonomies have been developed for classifying and organizing risks.  Since the taxonomy is exhaustive, the beneficial aspect of this is that you can then use these risk taxonomies to make sure you consider all areas of risk.

For IT and service projects, the Software Engineering Institute’s (SEI’s) Capability Maturity Model (CMM) developed a risk taxonomy (tr06.93.pdf – Taxonomy-based Risk Identification) twenty years ago that is still applicable.  I have Appendix page A-1 with me on every project and refer to it often.  For each entry, I ask the question:  Are there any xxx risks?  For example, for requirements stability, I ask:   Are the requirements stable?  Other industries have appropriate risk taxonomies available via the popular search engines.

These risk taxonomies are appropriate for finding product and service delivery risks, but not optimized for finding project delivery risks.  For that, PMI’s Organizational Project Management Maturity Model (OPM3) is a better source for identifying risks, though it’s cumbersome.  Basically, areas where the organization is not mature for project management are opportunities for risk.

These taxonomies and maturity models are sources from other’s experiences to help identify sources of risk projects in general.  Getting specific to your project, another useful technique for identifying risks (opportunities and threats), is work with your team or task owners and go through the WBS at a Deliverable, Activity, or Task level and ask them to estimate the Optimistic, Most Likely, and Pessimistic schedule for each.  It’s really amusing that I can ask the project team if they can identify any risks and they’ll consistently say “No.”  But they can confidently give me O, ML, and P estimates, then I follow up with:  What about the Pessimistic estimate can make this be late (or what has to happen for us to achieve the Optimistic estimate)?  Then, they can give me both threats and opportunities.  Amazing.

Finally, a reliable source of risk that you never want to miss is your assumptions.  An assumption can be defined as a risk without an owner.  Project estimating assumptions, task estimating assumptions, all assumptions need to be formalized and documented in the risk register.

In the previous post with the example risks, did you notice anything special about “risks” #3 and #4?
3.       Ice could be so bad that your office closes for the day
4.       You are low on gas and need to refill before you can make it all the way to work

Did you recognize that neither of these are risks?  I’m being somewhat pedagogical to demonstrate my point here, but to complete our task, you have to go into the office.  For “risk” #3, since the office is closed, you can’t complete the task.  Part of the definition of a risk is that you have to be able to “control” the risk (mitigate, avoid, transfer or accept).  This is why civilization-destroying asteroid collisions are not project risks.  For “risk” #4, this is not a “might happen in the future.”  It exists and must be dealt with, so it is not a risk, it is an issue. 

To summarize my comments from today’s post:
·         Use taxonomies and maturity models to identify sources of risk
·         Look for Product/ Service risks
·         Look for Project Delivery risks
·         Use your project team to identify risks (opportunities and threats)
·         Formalize assumptions into risks

Do you have suggestions or techniques for finding risks?

© 2013 Chuck Morton.  All Rights Reserved.

A Philosophy of Projects and Products (Part 2 of 3)

“How are you fitting in?”  Tom, the Account Manager, was conducting the three-month review with Eric, PM trainee.  “I can handle the technical aspects of the job OK,” Eric answered, “but the culture is very different.”  Eric had jumped ship from one of the clients and had joined the consulting firm for the opportunity to travel.  “My old job was all about fixing the applications.  You focus on the numbers more than we ever did.”

This is the middle of a three-part series taking an uncommon perspective on the Project Management environment.  The first entry discussed the characteristics of the Product & Service Delivery PM environment.  This entry discusses the Consultancy PM and the next entry concludes the series by reviewing the impact and significance of this subject.

The Consultancy PM is usually found in the big consulting houses:  PWC, Deloitte, Accenture, E&Y, KPMG, Tata Consultancy, etc.  The core competency of the Consultancy PM is project delivery, independent of domain, product, or service.  Whereas the P&SD environment will apply lessons learned to improve the product or service, the Consultancy PM applies lessons learned to improve project delivery.  The Consultancy PM focuses on stakeholder management, risk management, change management, and acceptance management.  Metrics concentrate on cost management and Earned Value Management (EVM) is common in Consultancy PM.  Product or service metrics are rare.

The Consultancy PM will be more attuned to deliverables rather than milestones, cost is prioritized over schedule or scope, resources are valued for their skill producing deliverables, and resources are generally exclusive to a project for the duration of their assignment.

Consultancy PMs could also be called Assembly Line PMs.  This shows the continuing evolution of the PM function, from journeyman PM, to craftsman, then to manufacturer.  In this case, the Consultancy PM aspires to complete projects like a company runs an assembly line.  In this case, however, the product or service – the target of the project – is a black box to the Consultancy PM.  Think of it like cans coming off an assembly line.  Except for the label, each can should be identical on the outside, but the content of each can could be different.

PMI’s Organizational Project Management Maturity Model (OPM3) aligns best with the Consultancy PM.

Small consulting firms offer an interesting mix across these descriptions.  Some, for example, specialize in a particular product or service, operating in the P&SD model;  others are immature, competing on price, mostly clueless about the needs for PM maturity, thus operating as journeymen;  then there are the second-tier consulting firms – they aspire to join the big leagues, but don’t yet have the volume and lessons learned loop so that their assembly line is not yet operating with the smooth efficiency of the top-tier players.  For those interested, this series of articles will help identify which model describes a particular consultancy you might engage.

Are you familiar with P&SD and Consultancy PM environments?  What other characteristics describe and differentiate them?  Can you use these models to improve negotiations with consulting firms?