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.

Measuring Software Productivity

Enhancing the Efficiency and Effectiveness of Application Development.  Michael Huskins, James Kaplan, and Krish Krishnakantham.  August 2013.  (registration required)

I just read this recent article from McKinsey and Company that extols the virtues of software productivity metrics, compares several alternative methods, and offers their recommendation.

I find it amazing that in the several years I have been publishing this blog, I have never discussed software productivity metrics – but after a review today, that is exactly what I found.  As an avid advocate and proponent of metrics, the topic has certainly been on the list for discussion.

Had I written the article before today, I would’ve advocated Function Points.  Function Points have several advantages, including being the most consistent, accurate and reliable of the various methods and the one most appropriate for evaluating and measuring vendor software.  In particular, if you are comparing building a package versus buying a commercial (COTS) package for the same capability, then FPs offer an objective measure for comparing both features and cost to determine the appropriate path.  Likewise, it is similarly appropriate when comparing products from multiple vendors.

As the McKinsey article explains, though, FPs are expensive and challenging to introduce.  For organizations that rely primarily on software development (rather than purchasing vendor offerings), the McKinsey authors introduce a new (to me) method called Use Case Points, compare this to Lines of Code, Story Points, and FPs, and describe how to introduce UCPs into the organization.  Further, the article notes that UCPs are comparable across applications and teams.  And UCPs can be used with both agile and waterfall development methodologies.

I encourage you to take a look at this article for your application development environment.  Metrics add a valuable tool to your toolbox.  And metrics are an absolute, foundational necessity for continuous improvement.

Have you worked in an organization that uses software productivity metrics?  What benefits did you find?  What problems did you encounter?

© 2013 Chuck Morton.  All Rights Reserved.

The Project Status Report – The Bad News

"It not knowing what to do, it's doing what you know.”

                                                                                                - Tony Robbins

Over the last couple of posts, I’ve discussed the “what” of the project status report (i.e., the content).  In this post, the conclusion of this three part series, I discuss the “why” of the PSR, but focusing on some of the less obvious benefits.

Everyone understands the theoretical or conceptual need for the project status report.  The client expects it, it may be obligated by the contract, and it may be in the standard process.  But it’s a burden to put together every week, to come up with newly creative ways to say you’re still behind on the project and you don’t have any tangible accomplishments to report.  We want a reason to do this activity – week in and week out – some reason larger than obligation to process;  some reason that overcomes the urge to make anything else we can be doing a higher priority than the Project Status Report.  We want something that gives this activity purpose and meaning.

There are a few good reasons for producing the weekly Project Status Report.  For example, a well-written PSR – succinct, factual, comprehensive – launches good discussions in the client project meeting.  It documents the action items and effects of non-compliance and non-responsiveness from the stakeholders.  It is an archive of the project trail.  But, there’s more.

On the LinkedIn discussion boards for Project Management that I follow, the question “What’s the best way to deliver bad news?” appears regularly.  This is a question I struggle with answering because the question those LinkedIn questioners are asking is not really “How to deliver bad news” but rather “How to deliver surprising bad news.”

The bad news I deliver to my project stakeholders is rarely a surprise to them because I publish the project status report religiously every week and I pack it with factual information about the project – the good and the bad.  I document the issues we are experiencing and the risks that present threats and opportunities.  I show where we have variances.  Sure, this is hard.  But it is a professional and ethical responsibility.  And if you don’t do this (think good risk management here), you are going to be struggling with the question of how to deliver surprising bad news to your stakeholders.

I can’t think of a better reason or a higher purpose than this.

Producing the project status report every cycle is a Project Management Best Practice.  What problems have you experienced when you ignored this practice?  What problems have you avoided by publishing it even when it didn’t seem like a healthy choice?

© 2013 Chuck Morton.  All Rights Reserved.

The Project Status Report – Content That Matters

"Thinking is more interesting than knowing, but less interesting than looking.”

                                                                                                - Johann Wolfgang von Goethe

This is the second post in the series on The Project Status Report.  In this post, I get specific about the appropriate content of a PSR.  But first, while it is called a Project Status Report, it typically includes status (snapshot), trending, progress (accomplishments) and exception (variance) content.  Second, the PSR should not be confused with a person’s (individual) status report (ISR), which everyone on the team should be completing.  Further, the PSR is not a roll-up from the ISRs.  Finally, the PSR, when done properly, is aligned with and contributes to the overall Management by Objectives (MBO) approach.

This last point deserves emphasis.  The PSR does not and should not say what is going on.  I know this seems totally off base, but to ignore this point devalues the PM contribution.  Rather, the project has a plan and the PSR documents the consistency with or variance from the plan.  So rather than saying “what is going on,” the PSR should say what is going on relative to the plan, which is a key distinction.

I’ve found that the following sections are useful to have in the PSR:
·         Current snapshot
·         Dashboard
·         Performance to plan
·         Accomplishments
·         Planned for next period
·         Issues/ Variances
·         Acceptances
·         Change activity
·         Risk summary
·         Downtime

Not all organizations use all sections and not all sections are appropriate for all organizations.  Let me discuss each section.

Current snapshot

This optional section is status content and is the executive summary of the PSR.  It should be a very brief (no more than a few sentences) narrative.  Of particular significance is to use this section to emphasize areas where stakeholder intervention is required, such as resolving third-party bureaucratic or administrative interference, stakeholder non-compliance (failure to approve a deliverable or change request), failure of a risk or issue owner to act, or when intervention is needed to address a “red light.”

Dashboard

This optional section is status content (and is improved with trending indicators).  Despite their popularity, I’m not a big fan of “traffic lights,” those red-yellow-green circles to summarize status, primarily because there often is not a clear understanding by all stakeholders what the traffic lights mean.  Further, a single traffic light summarizes too much to be sufficiently actionable (for example, something I experience regularly is that we will start a project before all of the budget administrivia is complete, knowing that the executives have approved the project and it will go forward.  However, the project shows red because of the budget and, so, everyone ignores the traffic light.  But there may also be other factors that should be recognized that are concealed because of the attention to the budget.)

I’m OK with traffic lights when the following conditions are met:  1) all stakeholders understand what the lights mean (in particular, when their action or intervention is required);  2) that there are multiple lights providing sufficiently discrete information to the stakeholders (e. g., budget, schedule, scope, approvals, issues, risks).  Traffic light value is improved if there are trending indicators (for example, up/ down arrows) to communicate changes.

Performance to plan

This is required status content.  This should include a Gantt chart (showing variance from plan) or, even better, Earned Value (and Earned Schedule) graphs.  This is the meat of the status report.

Accomplishments

This is optional progress content, though it is universally included.  Equally universal is that the wrong information is presented.  This should report accomplishments, not activity.  Avoid muddy verbs, such as:  worked on, met, attended.  Instead, use only concrete verbs, such as completed, published, documented, tested, coded.  The activities associated with these verbs should be tasks or activities in the WBS (and thus on the project schedule).  Finally, include metrics whenever possible (e.g., completed 20 of 30 test cases).

To digress momentarily, be clear about what “completed” means.  I often have developers report they completed an assignment.  “Have you completed the unit testing,” I ask.  “No, I completed the coding.”  OK, but the task is not complete.  These types of grey areas compromise the accuracy and the credibility of your reporting.

Planned for next period

This is optional progress content.  The same rules as listed for Accomplishments apply.

Issues/ Variances

This is required exception content and is usually a table documenting current project issues, the issue owner, activity and plan for resolution.

Acceptances

This is required status and exception content.  This should be a table listing each deliverable that has been submitted but not approved and deliverables that will be submitted in the next few weeks.  Table columns should list the deliverable name, responsible approver, date (to be) submitted, date approval was (or will be) due, and status (Not submitted, Pending approval, Overdue, Approved).  Overdue approvals should be highlighted.  Once an approval is received, this is reported as complete on the next PSR, then it is removed from future PSRs.

Change activity

This is required exception content.  This, too, is a table listing each submitted, but not completed, project change request.  Columns should include PCR number, title, date submitted, date response due, and status (Submitted, Pending approval, Approved/ Denied, Project plan updated).  Once the PCR has been denied or after the project plan is updated following the approval, this is reported on the next PCR, then it is removed from the table.

Risk summary (key risks)

This is required exception content.  This section is formatted similar to the Issues section.  One thing important to add to the section heading is “Date last discussed.”  This should be the date that risks were most recently discussed in the Client Project Meeting with the stakeholders.  I find that these meetings rarely discuss risks because time runs out before we get to this agenda item.  Risks should be discussed at least monthly and, if they haven’t been, this discussion should be moved to the top part of the agenda.

Downtime

This is optional exception content and will rarely be seen except in the status reports of the top echelon consulting firms.  It really isn’t meaningful in a Product & Service Delivery environment, but may mean the difference between profit and loss for a Consultancy PM.  When the client is responsible for the infrastructure on which the project depends, any failure, downtime, or force majeure where they are billed for your services but no work is being performed because of their nonperfomance, should be reported in this section.  It should (hopefully) be rare to have content here, but it is important to report it when appropriate.  I have also seen this section used to report “thumb twiddling” time because a client has not given timely approval to a deliverable.

There are obvious direct benefits from issuing weekly project status reports.  In the next and final post on this series, some key indirect benefits that may not be obvious.

What benefits do you receive or would you expect from publishing a weekly status report with this content?  What project problems can be avoided?  Can you guess what points I’ll bring up?

© 2013 Chuck Morton.  All Rights Reserved.

The Project Status Report

"Oft expectation fails, and most oft where most it promises; and oft it hits where hope is coldest; and despair most sits.”

                                                                               - William Shakespeare (All’s Well That Ends Well)

It has been a few weeks since I last posted.  Not because I don’t have ideas to share, but rather that I have a whole list of “next topics” and I struggle with where to go next.  I mentioned the Project Status Report in a post long ago during my series on The Project Manager’s Cycle, which I encourage you to review to properly understand the context for this expanded discussion on the Project Status Report (PSR).  With this post, I want to revisit the discussion about the PSR, going into depth on both the content (what goes in the PSR) and the rationale for the content.

The PSR is a key component of project communications.  There are the day-to-day communications by the project manager (the activities in the Project Manager’s Cycle where the PM meets with team members to get updates, to encourage, to motivate and meets with stakeholders for behind-the-scenes discussions).  But these build to the three central communication practices of the Project Manager’s Cycle:  the project team meeting, the PSR and the Client Project Meeting.

One of the essential decisions that must be made about the PSR – and this will be documented in the Communications Plan – is whether the PSR is a stand-alone document or whether it is a discussion aid to supplement the Client Project Meeting.  As a stand-alone document, I mean that it has to comprehensively explain information without the need for a discussion.  I don’t operate this way and, as a best practice, I recommend, instead, that the PSR is an aid to facilitate discussion in the Client Project Meeting (and I don’t mean either that the PSR substitutes for the Client Project Meeting agenda).   Thus, the Client Project Meeting – or rather, the minutes from that meeting – is the record of decisions made about the status.

The content of the PSR needs to answer a few basic, but essential questions:  how are we doing relative to the plan;  what is being (or will be) done to restore the project to plan, if necessary;  what threats jeopardize the project;  what actions are needed from the project owners or sponsors.

In the next post, I’ll address common sections of the PSR and the appropriate content for each;  and I’ll follow with a post on some of the tactical benefits of regular, proper status reporting.

What problems have you avoided that were attributable to good status reporting practices?  What problems have you encountered from deficiencies in status reporting?

© 2013 Chuck Morton.  All Rights Reserved.

Microsoft Solutions Framework

"The difference between a boss and a leader: a boss says, 'Go!' -a leader says, 'Let's go!'”

                                                                                                - E. M. Kelly

Sometime in a previous (professional) life, I worked for a company that used Microsoft Solutions Framework.  This was a very long time ago and I don’t even remember the company.  As a development framework, MSF didn’t really impress me much at the time, but there was one key element of MSF that did impress me and has stayed with me all of these years.

It may be that I wasn’t that impressed with MSF because the company that was using it wasn’t the best candidate for it.  MSF is ideally suited for software development for distribution (i.e., to consumers).  My client (employer?) was using it to develop software for internal use.  Further, they weren’t set up with the appropriate infrastructure and architecture for daily builds.  It was good they were using a development framework, but other choices would most likely have been more appropriate to their organization.

(This paragraph is an attempt at sarcastic humor.)  I have never used MSF in, what I would consider, an appropriate context for MSF.  However, Microsoft has years of success using it to deliver reliable, user friendly, quality software on schedule.  Therefore, I will accept their experience as its endorsement.

Nonetheless, I got training on MSF at my client.  As a framework and not a methodology, MSF is (intentionally and appropriately) light on the “how” of software development.  One area of the framework, however, is fleshed out in particularly specific detail:  the MSF Team Model.  The MSF Team Model has several favorable attributes:  it is specific about the roles (and responsibilities of those roles) that must be represented on the project team;  it is specific about the relationship of the team members to each other;   and it intentionally creates conflict between roles to establish natural “checks and balances.”

Prior to my training on MSF, my experience with building project teams was to have the “right” people.  But that is unabashedly vague.  Further, we may know that the team members we have are the right people, but how do we know what right people we might be missing?  The MSF Team Model resolved this weakness in my experience and practice.  Further, I know of no other framework or methodology that puts such emphasis on composing the team.

Therefore, as a Best Practice, I want to pass on the benefits of the MSF Team Model and strongly recommend that you consider the MSF Team Model on your projects.  More information on MSF and the Team Model is available in Microsoft Solutions Framework Essentials by Michael S. V. Turner (Microsoft Press, 2006).  Chapter 4 discusses building an MSF Team.

Have you had experience with MSF?  What is your opinion of the Team Model?

© 2013 Chuck Morton.  All Rights Reserved.

Power Listening

Power Listening: Mastering the Most Critical Business Skill of All.  Bernard T. Ferrari. Portfolio/Penguin, 2012.

I highly recommend Power Listening by Bernard T. Ferrari for PMs (and managers, executives, BAs, spouses, parents, children, …).  This book doesn’t offer platitudes about why listening is important;  in fact, Ferrari, who is obviously experienced with coaching on this subject, offers specific direction on, not just the why but, the how of listening.

The first few chapters of Power Listening are devoted to documenting archetypes of listening failures:  Opinionator, Grouch, Preambler, Perseverator, Answer Man, and Pretender.  These are described sufficiently well so that you can recognize them when you encounter them in others but, more importantly, when you find yourself, as we all do at various times, exhibiting these characteristics.  These opening chapters help us recognize poor listening archetypes, understand why each of these deficiencies prevents us from reaching our potential as listeners, and provide techniques for breaking bad habits associated with poor listening.

The meat of the book follows, though.  Here Ferrari provides the structure to swing from poor listening to Power Listening, by providing a schema for collecting and organizing (mandate, plan, team, execution and personal) information.  The goal of power listening (the technique) is to make better business decisions and this section helps us to better know when we are (still) missing critical information and what questions to ask to fill the gaps.  Knowing what questions to ask is beneficial;  knowing what information is missing is priceless.

The final section of Ferrari’s book explains how the organizational leader’s listening skills set the tone for the organization and that the leader can improve the organization by modeling Power Listening skills.

Communications is the most important skill in project management.  Therefore, anything we can do to improve communication skills – for ourselves, our project teams and our stakeholders – should be explored and practiced.  This book should be in your library;  these skills should be in your toolset.

© 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.

PM Journal – Risk in Complex Projects

Thamhain, Hans.  "Managing Risks in Complex Projects," Project ManagementJournal, April 2013 (Vol 44 #2), pp 20-35.

From discussions and networking with my peers and colleagues, I don’t think there are very many that read PM Journal.  I won’t suggest that’s a mistake because the applicability of the content varies – some articles are so academic and esoteric they are only of interest to the author’s mother, some are only applicable in narrow contexts, and some are a challenge to decipher.

In contrast, Hans Thamhain has written a very approachable and relevant article that I recommend to my readers (Yes, both of you).  He reports on the result of research on managing risk in complex projects (hence the title of his article).  Thamhain’s discussion of the current state of research and knowledge of risk in enterprise projects is both enlightening and disheartening:  “Predicting and controlling such [unknown] risks appears impossible with the existing organizational systems and management processes in place” (21) and “there is no framework currently available for handling risks that are either unknown or too dynamic to fit conventional management models” (22).  “…Many of the organizational tools and techniques that support early risk detection and management … readily exist in many organizations ….  Project managers, while actually using these project management tools and techniques extensively … do not give much credit to these operational systems for helping to deal with risks” (29).

The model he provides on pages 22-24 describing the three-dimensional relationship of risk characteristics (Uncertainty, Complexity and Impact) is easy to grasp and is probably valuable to introduce in your risk log for classifying risks.

Thamhain covers a variety of topics beneficial to PMs and, as the article’s title indicates, the focus is on the outsized consequences of risk effects that are not effectively managed.

I did find that since Thamhain shifts between discussing risks (a possible future event) and looking back after-the-fact to discuss the consequences, his terminology is sometimes confusing.  It’s like reading an article written by someone a few years in the future about something that for them happened a few months earlier.  They’re talking about something in their past that is still in my future.  I’ll offer a bit of guidance for readers of this article.  The word “contingency” appears throughout the article.  Late in the article he provides a couple of contextual definitions, undesirable events (29) and risk situations (30), which don’t help clarity.  However, from the article context it appears that he uses “risk” to refer to a future event and “contingency” to refer to a past event that was formerly a “risk.”  I would have used the term “risk event” to describe these, but I understand his difficulty.  The other confusion is the use of “issue.”  PM purists will no doubt object to Thamhain’s use of “risk issue,” but in context it translates to “the project issue that results from the occurrence of a risk event.”  I caution newbies to have a firm grasp on the distinctions between “risk” and “issue” before tackling this article.

One specific takeaway from the article that I want to share is worth noting by both PMs and managers.  PMs “blame project performance problems and failures predominantly on contingencies that originate outside their sphere of control … while senior management points directly at [PMs] for not managing effectively” (30).  Thamhain’s further commentary on this topic in the article should be read by both PMs and executives.  It probably deserves reworking for broader distribution, such as an article in PM Network.

For reference, my previous posts on project risk management:

·         The Project Manager’s Cycle – Review Risks & Mitigation Actions [Published:  03/06/2011]
·         The Schedule – Risk Buffers [Published:  12/28/2012]
·         Where to Find Risks  [Published:  03/20/2013]
·         Estimates, Schedules, Assumptions and Risks  [Published:  04/03/2013]

© 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.