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.

Project Governance – Maturity Level III

Project governance is an oversight function that is aligned with the organization’s governance model and that encompasses the project life cycle.  Project governance framework provides the project manager and team with structure, processes, decision-making models and tools for managing the project, while supporting and controlling the project for successful delivery.

                                                                                                - PMBoK v5 (p34)

This is the third post in my series on governance in the project context.  In the first post I introduced my arbitrary, tongue-in-cheek governance maturity level (gml) and in the second post described gml-II Solution, the first level of maturity of project governance.  With this post, we advance to describing gml-III.

Remember from the previous post that minimal project governance is focused on the project solution.  Advanced project governance, in contrast, is focused on project delivery.  Rather than just being concentrated on Executing Process Group (PMBoK v5 section 3.5) activities, gml-III governance covers the entire gamut of process groups:  Initiating, Planning, Monitoring and Control, and Closing.

At gml-II, governance activities were directed at the product deliverables.  At gml-III, in contrast, expect the governance team to examine the project charter, statement of work, status reports, meeting minutes, and all deliverables in the organization’s methodology, all the way through to the project retrospective and closing.  Not only will they be looking to see that the work product was produced, but that the proper template was used, the content conforms to standards, it was distributed properly (both audience and time), and that approval authorities are correct.

While governance processes may be similar to those at gml-II, the tools used at this level are ratcheted up.  Periodic audits with formal auditing checklists, scoring models (i.e., a project that is not conforming to process is higher risk than one that does), and public, structured project reviews are all normal practices.  These audits and reviews are distinctive in that performance is not determined by time, cost or scope;  performance is exclusively measured by conformance to process and proper use of tools by the right people.

At this level, there are also differences from the previous level with the governance team.  All governance is a form of “Check and Balance” to assure credibility.  At gml-II, project governance is within the project delivery methodology, for example, stage gates.  As such, it is contained within the department or division;  it might even be within the PMO.  At gml-III, in contrast, the concern for credibility goes much higher in the organization, thus governance is completely separate from the project delivery organization.  At a pharmaceutical company, for example, governance may report up through the legal department;  at a financial institution, depending on what department the project team is in, governance may report to legal or to the CFO;  in a large (completely projectized) consulting firm that I worked for for many years, the governance team reported directly to the COO.  That is, the project delivery organization existed, with branches, branch managers, PMs, Delivery managers, divisions, VPs, etc.  But governance was completely independent of the project delivery organization.  The project auditors that worked at the branch level did not report to the branch managers, but reported up through their own hierarchy that reached directly to the company president.  This demonstrates that gml-III is the appropriate governance level for the consultancy PM.

My final comments on gml-III are that, because the governance elements are formal and process-ized, the environment is positioned for continuing process improvement.  The project audits will encourage post-project reviews and documented Lessons Learned.  These will, in turn, be fed back as inputs into the project audits, resulting in improvements to the checklists, tools, templates and training.  This virtuous cycle represents the capstone of gml-III maturity.

In my first post in this series, I mentioned that we would explore governance in the project context.  So far, we’ve been exclusively discussing project governance, but with the next post, on gml-IV Alignment, we will step outside the project to see what penultimate governance looks like in a project organization.

When governance is discussed, someone usually bemoans the inefficiency, the overhead, the burden.  Does your organization have too much, too little or just the right amount of governance?

© 2013 Chuck Morton.  All Rights Reserved.

Project Governance – Maturity Level II

"I think the next best thing to solving a problem is finding some humor in it”

                                                                                                - Frank A. Clark

In my previous post, the first post in this series on governance in the project context, I introduced my arbitrary, tongue-in-cheek governance maturity level (gml) and described gml-I Chaos.  With this post, we advance to describing gml-II, the first maturity level where governance is contributing to project success.

Effective governance is external to the project (and therefore to the project team).  I’ll dwell on this more in a later post in this series, but this means that project governance cannot be performed by the project manager;  governance is someone outside the project looking at what the project manager and the project team have done.  Other requirements for the organization to be at gml-II are a project methodology, project standards, and deliverable templates, since, for governance there must be something to govern to. 

At the lowest level of mature project governance, the attention is on the project solution, the product or service , such as in the Product & Service Delivery (P&SD) organization.  Governance at this level is focused on the Executing Process Group (PMBoK v5 section 3.5) activities and the product deliverables.  Examples of project governance activities at this level include architectural reviews and stage gate reviews.

Another factor I check is how the project managers are measured and incented.  This is a topic I touched briefly a while back (How Should a Project Manager be Measured?), so I won’t dwell on it here.  Suffice it to say, though, that if the organization has a methodology and standards and the PM is not measured (and incented) based on those standards (rather than the PM Triple Constraints), then the organization is most likely still at gml-I Chaos.  After all, the organization is sending a mixed signal on whether they want the PM to follow the standards or to abandon them to deliver the product or service solution any way they want.

Governance models that describe governance maturity level II are Microsoft Solutions Framework (MSF) and the SEI Capability Maturity Model – Integrated (CMMI), which are both solution-focused methodologies.

In my next post, we’ll move slightly up the food chain to gml-III Consultancy, which will discuss a more advanced implementation of project governance.

Does your organization have effective project governance?  How does it stack up so far based on this description?  Do you think I’ve fairly described minimal project governance?

© 2013 Chuck Morton.  All Rights Reserved.

Project Governance – Maturity Level I

"Good project governance provides just enough oversight, process, guidance, and rigor to efficiently and effectively use project resources, deliver a solution, and handle trade-off decisions while optimally balancing adherence to a set of potentially changing project constraints.”

- Michael S. V. Turner, Microsoft Solutions Framework Essentials: Building successful technology solutions.  p271.

With this post I start a new series on governance.  Project governance, yes, but not just project governance.  Governance in the project context, though.  This should be a fun exercise, and I invite you to join the conversation.  Project managers historically have a love-hate relationship with governance, but it shouldn’t necessarily be so.

I have worked in the financial, pharma (GxP), and government domains, among others.  These are all high-governance environments and, with that experience, I can say that governance is a project manager’s good friend.  Understand that both you and the governance team have the same objective – project success.  If you don’t grasp that, then the yin-yang balance between advocate and adversary will be lost for you;  you’ll see governance only as an adversary to your success.  This will not be to your (or, more importantly, the project’s) benefit.  One thing in particular that keeps me on my toes is that, in these environments, I know someone who knows what they’re doing is going to be looking over my shoulder and evaluating my results critically.

There is probably some governance professional organization with its own body of knowledge and well-defined formal maturity levels for governance.  I wouldn’t know.  With apologies to that organization and to SEI and, completely tongue-in-cheek, I’m creating for this series an arbitrary set of maturity levels.

The first governance maturity level (gml), then, is one where any of the following are true:  there is no formal project governance process or methodology;  the project governance methodology is ineffective or insufficient;  or, the project manager perceives the project governance as (substantially) an adversary to success.  This is generally, in the maturity level worlds, called the state of chaos.  And that epithet clearly applies.

In the next post, I’ll advance to gml-II Solution and expound way too long on the characteristics of the first level of project governance maturity.

I would love to hear your stories on governance.  Have you found it to be an ally or an adversary?  What guidance do you have for fellow PMs?

© 2013 Chuck Morton.  All Rights Reserved.

Change Management – The Process (Part 2)

“If you do not change direction, you may end up where you are heading.”
                                                                                                                                - Lao Tzu

This post concludes the series on change management that started with a discussion about what’s so confusing and is a continuation of my previous post on the process of project change management.  That post described the conceptual activities in project change management and why there are not explicit change management processes in the PMBoK.  Now it is appropriate to review what is in PMBoK and how it aligns with the conceptual activities.

The following PMBoK processes relate to project change management:
·         Develop project management plan
·         Plan [Knowledge Area] management
·         Direct and manage project work
·         Monitor & Control project work
·         Perform integrated change control

“Develop project management plan” and “Plan [Knowledge Area] management go hand-in-hand.  The project management plan includes each of the knowledge area management plans.  Each knowledge area plan (scope, time, cost, etc.) needs to include how change to that component will be managed.  In addition, the project management plan should describe how change requests are submitted, processed, reviewed and decided.

One thing I haven’t yet discussed is the two types of change.  There are, for example, changes to the product or service that is produced in “Direct and manage project work” and variance and compliance changes that are recognized in “Monitor and Control project work.”  We encountered both of these in a previous post on the philosophical dilemma of project change.  The project plans should,, of course, address how this dilemma is recognized and resolved in the “direct and manage” and “monitor and control” processes.

“Perform integrated change control” is the key to having project change work effectively.  It is here that change requests are received and processed.  As I mentioned in the previous post, this process is like initiating a complete mini-project for each request.  That’s why I have a dissonant response to Table 3-1 on page 60 of the PMBoK every time I pay attention to the location of 4.5 Perform Integrated Change Control, in the Monitoring and Controlling Process Group column.  Realistically, this step spans all five columns, from Initiating to Closing.  Not only does this span all process groups, but because a change to one functional group will trigger cascading changes in other functional groups, this activity also spans all functions (scope, time, cost, etc.), which is why it is integrated change control.

As I now bring this series to a close, the most important point to emphasize is that change will occur on your project, it will happen, and it must be planned for, you must prepare to have change, and you must have the processes and practices in place to effectively include, manage and control change in your project.

So now that you know everything I know about project change, what tips do you have for other PMs?

© 2013 Chuck Morton.  All Rights Reserved.

Change Management – The Process (Part 1)

“What you have become is the price you paid to get what you used to want.”

                                                               - Mignon McLaughlin, The Neurotic's Notebook, 1960

Continuing my series on Project Change Management, it is now time to drill into the change management process.  As I explained in my previous post in this series, the change management process is unlike other project management processes because it is not neatly contained, either by PMBoK knowledge area nor, except for one Monitoring and Controlling process, by PMBoK process group.  This post will attempt to demystify change management by examining what is in place, how it works, and what it could look like.

In the PMBoK (5^th ed), other than “Perform integrated change control” in the Monitoring and Controlling Process Group, the remaining change management activities are spread across and buried within the Knowledge Areas and Process Group activities.  So there’s a “perform” process, but how do you know what to “perform” if you don’t plan for it?  How can you “perform” an activity if you don’t recognize it?

Let’s start with an understanding of what, conceptually, project change is.  In a project, if you could alter the plan indiscriminately, there would be no need for a change management process.  The change process would be “do whatever you want, whenever you want” and, thus, the project would equally be “do whatever you want, whenever you want.”  Similarly, if there’s no plan, then there’s nothing to change.  So, project change is the formal approach for replacing an agreed-to plan with an amended agreed-to plan.  Since the plan establishes stakeholder expectations, change management is the structured approach for resetting expectations.

The word we usually use for “agreed-to plan” is baseline.

Let’s step through this from the beginning of a project:  The project is initiated, chartered and planned.  A project plan (time, cost, procurement, HR, scope, change, etc.) is produced, agreed to by the appropriate authorities (baselined) and published to stakeholders.  At this point, all stakeholders should be operating on the same expectations and you, the PM, should be reporting status, progress and variance based on the plan.  Now, someone comes along with a request to add a new feature (or get it done quicker, or cheaper, or without a key resource, or ….).  At that point, the project change management process is used.

The requestor submits the request according to the approved change management process.  The interesting thing here is that, regardless of how it’s described, the change activity is like a mini-project with all of the steps.  The change request is equivalent to a Charter.  The project team evaluates the request, estimating how the current project activities will be altered (new tasks, changed tasks, eliminated tasks, etc.) and creating a revised project plan, which must then be reviewed and approved (at which time it becomes the new baseline plan) or rejected (and the current plan remains effective).

So, if a stakeholder can submit a request to change the schedule, why isn’t there an “Evaluate schedule change request” or “Perform schedule change,” and likewise for all of the process groups?  As you – an experienced project manager – well know, all the project parts are connected:  you can’t tweak one area without somehow changing some other area.  Therefore, there is no time (or scope or cost or HR or procurement, etc.) change activity:  there is, reasonably, “Perform integrated change control.”

So I want to pause here:  I will continue this subject in my next post on this, where I will discuss how the current PMBoK activities relate to change management.

Does your organization have an effective and manageable project change management process?  How does it work?

© 2013 Chuck Morton.  All Rights Reserved.

Project Change Management – Process Overview

"Change is inevitable - except from a vending machine.”
                                                                                                - Robert C. Gallagher

Now that we have the confusions and dilemmas of change management behind us, it’s time to drill into the change management process. 

The one thing you can count on to stay the same when running a project is that there will be change.  Yet, the PMBoK (5^th ed, p60) identifies nine knowledge areas and change is not in the name of any.  And change is not in the name of the five process groups.  There is no process that says “Plan Change Management.”  If change is so prevalent, what is the process and where is it documented?

Some examples of change include:
·         We need to complete the project sooner.
·         We need to reduce the project budget.
·         We need to add this feature to the project scope.
·         This person has resigned, but we still need to complete the project.

In fact, there are eight broad areas where change can occur:  Scope, Time, Cost, Quality, HR, Communications, Risk, Procurement and Stakeholders.  This list, no coincidence, corresponds to eight of the PMI knowledge areas (PMBoK 5^th ed, p60).  But there is no “Deal with scope change” or “Handle HR disruption.”

As any practitioner of project management quickly learns, everything is connected to everything else and nothing happens in isolation.  It’s like there’s a seven dimensional pyramid (eight nodes), where there are 28 connections between the nodes.  (This concept also applies in communications management and communications planning related to the project team size.)  This means that if, for example, you need to complete the project sooner, that has a potential impact on all seven of the other knowledge areas that needs to be evaluated (and each impact to one of those has a potential impact on the other seven, etc.).  So, a “Deal with scope change” process cannot be done in isolation from time, cost, quality,….

Thus, we have, in the wisdom and experience of the PMI, the ninth knowledge area:  Project Integration Management with the process Perform Integrated Change Control.  This is the only practical technique for addressing project change – holistically across all areas.  But “perform” omits “plan” and “evaluate.”  It’s still not complete.

In the next installment of this series, I’ll drill deeper into the change process and how it works.

Has it occurred to you before that change management and communication management have this mathematical relationship?  What consequences can you foresee from this?

© 2013 Chuck Morton.  All Rights Reserved.

How Should Project Manager’s Be Measured?

"Being in power is like being a lady. If you have to tell people you are, you aren't”

                                                                                                - Margaret Thatcher

“How should I measure my PMs?” is a frequent question (in a number of variants) on various LinkedIn discussion boards.  The classical answer to this question, of course, is that the Project Manager is measured on their success at delivering the contracted/ chartered scope on time and within budget.  The practical answer is not so simple.

The traditional response is based on the purist PMI definition of a project and project manager:  a Sponsor funds a specific project (agreed-on scope, time and cost) and the PM has complete authority and autonomy to deliver the project.  In this scenario, it is proper to base the PM’s performance on those criteria.

I don’t know about you, but I’ve never worked on a project like that.  So let’s look at a couple of scenarios more consistent with what I’ve experienced.  In the first, the PM is assigned to a VP or senior manager and is their agent for delivering their project.  (From the purist PMI definition, the executive is the PM, but that’s not how it’s recognized in the industry.)  In this scenario, the PM is the agent of the executive;  the executive makes the strategic and significant controlling decisions;  the PM is responsible for tactical and operational delivery on behalf of the executive and for monitoring and reporting.  The key PM skill is proactive stakeholder communications.

This PM should not be measured on the traditional criteria:  they don’t have the authority to make significant or strategic resource reallocations to meet the project objectives.  However, this PM should be measured on the quality of the plan (relative to the organization’s delivery capability), the quality of the schedule, delivery to plan and frequency, appropriateness and quality of communications.  On this last point, communications, for example, the PM should be measured on how well they keep the stakeholders (particularly the executive) informed about variances from plan, but the PM should not be assessed on the magnitude of the variations, that there are variations or the response to the variations.

Another common scenario is that the PM is assigned to a PMO or that the organization has a formal, well-defined project delivery process.  In this scenario, the organization, not the PM, takes on the responsibility for delivering scope within time and cost by specifying the process.  In this scenario, the PM should be measured on adhering to the process, the quality of the deliverables and the contribution to improving the process.

There is an important lesson in this scenario:  if the PM follows the process and the project fails, the PM was successful;  if the PM doesn’t follow the process, regardless of whether the project is a success, the PM has failed.  This may sound heretical, but is the difference between how GM and Toyota manufacture cars.  For GM, delivering a car on schedule is paramount, regardless of the process disruption.  Thus, each car becomes a one-off craftsman product with inconsistent quality (results are not in statistical control and quality is tested in).  In contrast, for Toyota the process is paramount.  If the process is not working properly, they will stop the process until the problem is corrected.  That is a true assembly line and the product quality is consistent.

If your organization has a project delivery methodology, the only way to know if it works is to apply it absolutely and allow it to succeed or fail.  If it fails, then do the appropriate root cause analysis and problem resolution to improve the process.  Thus, a PM who shortchanges the process is not benefiting the long-term quality of the organization.

The bottom line is that the PM should be evaluated based on their performance within their span of control and to the organization’s delivery objectives.  Use of any other criteria creates dissonance between what you say you want and want you are rewarding the PM for.  To paraphrase Sgt. Esterhaus, “Let’s be consistent out there.”

What experience do you have with inconsistencies between the reality of what the PM does and how the PM is measured?

© 2013 Chuck Morton.  All Rights Reserved.

Going Dark

“I’m twenty-five percent complete and on schedule,” reported Peter at the end of the first week of his four week task.  A week later, Peter reported “I’m fifty percent complete and on schedule.”  Some foreshadowing was offered in Peter’s report at the end of week three: “seventy-five percent complete, but I have some other things competing for my time next week.  I should be able to catch up, though.”  Then the bomb dropped on Wednesday, just three days later, when Peter finally had to face his deadline.  “It’s going to take me three more weeks to complete this.  I was going to use the API in the new version, but it’s returning the data in the wrong format and the vendor doesn’t have a patch, so I’ll have to rewrite it to use the old API and …”

I believe the phrase “going dark” originated with Jim McCarthy in Dynamics of Software Development (Microsoft Press, 1995).  As a guide for managing programmers, this classic is valuable still.  Rule number 30, Don’t Go Dark (pp 102-106), describes the hazards of failing to get regular, frequent, concrete evidence of a developer’s progress.  In this age of Agile, Scrum, RAD, RUP and other TLA methodologies, we project managers still allow team members to do this to us.  And not just in software development projects or by programmers.

There may be several different reasons to explain why a team member goes dark.  Maybe they don’t understand how to complete the task nearly as much as they thought they did.  Maybe they have 15 other things to do and this isn’t (from their perspective), the most important.  Maybe they don’t find the task as compellingly interesting as something else they can work on.  Maybe it’s a passive-aggressive way to make a point.  Often it is some combination of these – a less experienced team member, slightly over their head and with a seemingly endless list of must-haves from other managers, so they focus on doing what they can do rather than committing the time that’s needed to focus on this task.

It could be just the opposite, a team member who thinks they know how to complete the task and spends endless time searching false leads and dead ends without converging toward the solution.  For whatever reason, it needs to be recognized and addressed.  Fred P. Brooks, Jr., in The Mythical Man-Month (Addison-Wesley, 1975) documented the consequences of even slight slippages.  “How does a project get to be one year late” he asked.  “One day at a time.”

Regardless of why it may happen, appropriate planning and control protect us from these consequences.  A key task should have one owner, be no more than two weeks duration (about 65 effort hours if the owner is dedicated), and have a clearly defined Done state (see my previous entry).  That covers “appropriate planning.”  Appropriate control is to have an early warning system (which I will discuss in a future post) for when a task will be delayed so the delay can be addressed and corrected before it is a project problem.

Have you had a team member “go dark?”