Project Change Management – A Philosophical Dilemma

"Our dilemma is that we hate change and love it at the same time; what we really want is for things to remain the same but get better.”
                                                                                                - Sydney J. Harris

Now that we know we’re discussing project change management, it’s time for a decision on how approved change will be addressed in the project.  Let me describe a scenario to help illustrate the two schools of thought.

You start a project and complete and baseline the plan.  It is a six month project.  Three months into the project, you are now one month behind when a key stakeholder requests a significant change to the project scope (a new feature).  You do the planning for this new feature and it will add two months to the project.  What is the new completion date?

One school says the new baseline is the former baseline plus the new change, meaning the project is now baselined as an eight-month project and still one month behind.  The other school says that the new baseline is current actual plus the new change, meaning the project is now baselined as a nine-month project and on schedule.  Advocates for the first method argue that the baseline shouldn’t absorb the delay just because they’ve proposed a change – and they’re right.  Advocates for the second method say that it doesn’t make sense to publish a new baseline with an inaccurate end date – and they’re right.  The ultimate choice depends on subjective considerations over which of the two better fits the organizational culture.

Since there is no absolute “right” or “wrong” choice between these schools, the participants should all understand how change management will work in this scenario (this would be a key section of the change management sections of the Time Management Plan and Cost Management Plan).  While this may not be a critical decision for a P&SD PM, for a consultancy PM or a contracted third-party organization providing PM services, this could be significant given that compensation (penalties and bonuses) may depend on whether the project is early, late or on schedule.

Like many controversies where there is no absolute “right” or “wrong,” this too will have practitioners who have an intuitive and firm position one way or another;  they may have difficulty understanding or even acknowledging the other view.  This can make discussions on the topic difficult because they can get emotional.

If you follow the first scenario, the project team has an incentive to “game” the change estimates, especially if there is a subjective component to the estimate.  That is, if they are behind or over budget, this is their opportunity to catch up, so it may not make much difference which school you prefer.

If you follow the second scenario, there may be stakeholders who feel the project team is taking advantage of them to erase variances.  Thus, in the end it comes down to the ethical practices of the project manager and the project team.

Which method do you use and why?  Have you experienced any problems caused by this?

© 2013 Chuck Morton.  All Rights Reserved.

Change Management – What’s so Confusing?

"I know that you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant.”
                                                                                                - Robert McCloskey

With this post, I begin a series on change management.  Today I’ll make the effort to clarify what change management we’re discussing.  Next I’ll discuss a challenging philosophical dilemma posed by the choices of how change management is implemented.  Then I can settle in with actually discussing the “hows” of change management best practices.

When change management comes up on my projects, I always ask what “change management” the person is referring to.  I know of three different change managements that are commonly encountered on projects and there is invariably confusion because different project team members have different contexts where their specific change management label makes sense, but they often don’t realize that other groups use the same label, change management, to refer to something completely different.

In the HR and process worlds, change management refers to Organizational Change Management, the methods for transitioning people, teams and processes from a current state to a new future state.  This can involve realigning people, changing roles and duties, training, adding people, eliminating positions, streamlining job functions, etc.

In software engineering, change management refers to Systems Change Management, the practices necessary to successfully implement new software or update the installed software with new features.  This is better referred to as release management, but is frequently called change management by the practitioners.

When the PMBoK refers to change management, it means Project Change Management, which involves documenting and updating changes to the approved baseline project plan.  Project Change Management is neither difficult nor complex, but few organizations practice it effectively.

Note that an organizational change may involve a project and/or a software release.  A project can involve making organizational changes.  A project can involve implementing a software release.  A software release may be run as a project.  As I opened, it is not unusual at all to encounter all three of these change managements on a project and have different team members using the same terms and meaning completely different things.  Oh, the confusion you can sow.

For the remainder of my series on change management, I will be exclusively discussing project change management.  In my next post, I’ll take up one of the challenging philosophical questions about implementing project change management.

Are there any other change managements out there that I’ve missed?  Have you encountered confusion on projects when referring to change management?  How did you resolve the confusion?

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

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.

Project Management Research Topics

"Avant-garde music is sort of research music.  You’re glad someone’s done it but you don’t necessarily want to listen to it.”

                                                                                                - Brian Eno

I am a regular reader of the Project Management Journal and take a keen interest in the latest research on the project management profession.  While some of the content is abstrusely academic and some just doesn’t apply to me, it is rare that I don’t find several articles that interest me.

While I appreciate the research that Project Management Journal brings me, I am a practitioner, not a researcher.  That said, my experience affords me a direct exposure to anecdotal evidence of themes, patterns and practices relevant to our profession.  What I don’t know is whether these anecdotal observations are representative or outliers.

Therefore, I’ve reviewed all my posts and tagged a few with “Project Management Research” to indicate I’ve made an assertion in that post that would benefit from an objective application of the scientific method.  I thus invite and encourage any students looking for project management research topics to review these posts and conduct the appropriate research to (in)validate my premise.  I offer these topics freely.  I ask that you provide me with the published results.  I’ll post them here, supportive or non, with generous credit to you.

To get you started, here is a summary of all of the posts I’ve tagged and the outstanding research question in each.

A Philosophy of Projects and Products (Part 3 of 3)  [Published:  01/13/2011]

Hypothesis:  Consultancy PM environments can be distinguished from P&SD PM environments (core skill, priority, metrics, milestones vs deliverables, scope vs cost, domain knowledge vs monitor/ control, shared with support/ maintenance).

Hypothesis:  Consultancy PM organizations are more successful at delivering projects than P&SD PM organizations.

The Project Manager’s Cycle [Published:  01/31/2011]

Hypothesis:  That the activities documented constitute the Managing & Controlling cycle.

Hypothesis:  That PMs (or organizations) that follow these best practices are more successful at delivering projects.

The Project Manager’s Cycle – Redux  [Published:  12/31/2012]

Hypothesis:  That the activities documented constitute the Managing & Controlling cycle.

Hypothesis:  That PMs (or organizations) that follow these best practices are more successful at delivering projects.

Project Failures & The Chaos Reports [Published:  06/26/2011]

This post identifies a host of research opportunities:  distinguishing between success rates for professionally managed projects versus ad hoc managed projects;  perception of success vs failure by different stakeholders on the same project;  different “types” of project failure;  etc.

The Root Cause of IT Project Failure [Published:  07/04/2011]

Hypothesis:  Failure of novel projects is due to the project team committing to a schedule too soon.

Ode to ETC – The Task Overrun Early Warning System [Published:  10/04/2011]

Hypothesis:  That Estimate to Complete (ETC) is superior to Percent Complete for determining accurate project status and providing earlier indication of problems.

The Schedule – Basics [Published:  11/27/2012]

Hypothesis:  Organizations that well-formed schedules have superior project success rates than organizations that do not use these practices.

The Schedule – Risk Buffers [Published:  12/28/2012]

Hypothesis:  Organizations that apply quantitative risk analysis have superior project success rates than organizations that do not.

Estimate Confidence – A Demonstrative Example [Published:  03/02/2013]

Hypothesis:  That PERT practices for determining standard deviation are valid.

Hypothesis:  That schedules developed using PERT scheduling techniques more accurately reflect actual results than schedules developed from other techniques.

I look forward to learning about and learning from the research you conduct on any of these topics.  Further, I’m happy to assist you with defining and refining the research instruments.

© 2013 Chuck Morton.  All Rights Reserved.

Estimates, Schedules, Assumptions and Risks

"Though life is made up of mere bubbles, 'Tis better than many aver, For while we've a whole lot of troubles, The most of them never occur.”
                                                                                                - Nixon Waterman

With this post I conclude the series on scheduling and estimating that started with the basics of scheduling.  I hope that this series has successfully drilled into you that offering an informal estimate, without including all of the elements for success and properly qualifying the estimate with assumptions or risks, is an eventual path to damaging your credibility and the credibility of the PM profession.  Estimates should almost universally be presented as ranges with statistical probabilities.  (It’s a real disgrace that our tools generally don’t provide this capability.)

Estimates should always include estimating assumptions.  This is not a CYA point, but rather the estimating assumptions further clarify the scope and scope boundaries, establishing basis for (project) change control.  Change Management is a topic that I haven’t developed yet and is a good one for a future series.  Stay tuned for that one.

A well-formed schedule takes work to produce.   When done well it has a rational basis and a foundation in science.  And despite all that, it is still subject to failure.  That is no excuse, though, for us not to do the work that our profession calls for.  In fact, it is the reason that we should be as rigorous as possible in our duties.

Starting with my next post, I’m going to cover a few miscellaneous topics for a few posts before starting a new series.

What estimating and scheduling issues do you experience that I have not addressed in this series?

© 2013 Chuck Morton.  All Rights Reserved.