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.

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.

Estimate Confidence Buffers, Risk Buffers and Management Reserve

"If confusion is the first step to knowledge, I must be a genius.”
                                                                                                - Larry Leissner

We’re nearing the conclusion of this series that started with the basics of scheduling.  I want to tie up a few loose ends, maybe clarify some inaccuracies and address some confusion I may have introduced.

As I developed this series on scheduling, leading up to the previous post on estimate buffers, I hopefully offered convincing arguments for including appropriate buffers.  In this post, I want to compare and contrast various types of buffers that are common.

I think the discussion I offered on risk buffers is consistent with other authors and industry practices, so I won’t belabor that discussion.  I will point out that risk buffers are included in the project (time and cost) budget and are managed by the Project Manager.

Literature and practices for improving estimate confidence are much rarer.  Therefore, there may be some stakeholder pushback for including these buffers in the schedule.  However, you can demonstrate through logic, reason, science and ethics that, in order to have a realistic schedule, these buffers, like the risk buffers, must be included in the schedule.  Like risk buffers, these confidence buffers are included in the project budget and are managed by the Project Manager.

However, you don’t want to “double count” your risks.  Let’s say you do a lot of similar projects.  For these, there will probably be a common pool of risks that are included.  However, if your estimates are based on historical results and sometimes these risks occur, then there is the potential that your Pessimistic estimates will already account for those risks.  You will need to adjust either the estimates or the risk buffers so they are in the schedule only once.

In contrast to the confidence and risk buffers, some PMs Pad their estimates.  Some project managers, after over-running the project schedule a few times, learn that their estimates are never sufficient and start adding arbitrary amounts.  “We go over by 20% every time, so I’ll just start adding 20% to the schedule.”  This may sound logical on the surface, but is actually bad for their credibility and for the PM profession.  (Look for more discussion on this topic in a future discussion of The Toyota Way.)  Stakeholders learn that the PM is padding and, in response, start cutting the budget or otherwise compensating.  Pad is Bad.

In contrast, neither confidence buffers nor risk buffers are arbitrary.  Hopefully, if you’ve followed the discussion this far, the reasonable, logical and scientific justification for including these in the project are thoroughly explained and documented.

One last buffer that is sometimes seen in large, third-party project contracts is Management Reserve.  Management Reserve is separate from and distinctly different than estimate confidence buffers, risk buffers or pad.  Management Reserve is contingency funds allocated for use by the contract owner (sponsor).  These funds are not part of the project budget and are not available to the Project Manager except after approved project change control to authorize allocation to the project.

I hope this series has been interesting and informative for you.  One last remaining post and then we can move on to new topics.

Was this discussion scheduling and estimating clear and thorough?  Is there anything I missed that you would like me to address or anything that is still not clear that I should expand on?

© 2013 Chuck Morton.  All Rights Reserved.

The Project Manager’s Cycle – Check Variances and Productivity

“Kevin, I see that for the Architectural Strategy Document, your task to track down all of the legacy systems we interface to is falling behind.  What’s going on?”

The next activity in The Project Manager’s Cycle takes as input the revised schedule from the replanning and rescheduling activity.  For this activity, the project manager compares the newly current project (cost and duration) schedule with the baseline to identify variances and develop appropriate response plans.

For example, the PM will review the current expected cost to complete each project deliverable with the baseline cost.  Not all shops track (dollar) costs, but resource hours can generally be used as a proxy for cost when effort-based scheduling is used.  (If you are not using effort-based scheduling, well, you are already behind the eight ball for best practices.)  For any deliverable where the current costs differ from plan by a designated percentage or dollar amount (say, 10%) plus or minus, the PM should investigate and document the reason for the variance.  As appropriate, prepare an action plan for addressing the cost/effort variances.

Likewise, for each project deliverable compare the completion dates with the baseline completion dates.  Again where the dates differ by a designated amount (say, two weeks) plus or minus, the PM should investigate and document the reason for the variance.  As appropriate, prepare an action plan for addressing the schedule variances.

As PM, you also want to review progress (effort and duration) at a more granular level to determine whether you are getting the performance and productivity from team members that you expect.  This is, of course, subjective.  Look at each active task and the team members’ recent reports for early warning signals that there is slippage or that you can act to prevent slippage.  Also look for patterns that should be factored into the remaining project schedule.  After all, you want to be already responding to variances long before the dashboard turns red.

Finally, having identified and explained the cost and schedule variances, consider whether project change management is appropriate.    That is, are the changes caused by the team or because the plan was faulty (absorb the variance) or because of scope, environment, risk, or client events (change is appropriate).

How high do you allow the variances to get before you step in?  How do you typically raise the need to discuss a variance with a team member?  When do you escalate?