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.

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?

The Project Manager’s Cycle – Change Control

“We missed one of the major requirements,” Don, the PM, was reporting to the owner in the status meeting.  “However, at this point we have very limited options.  If we add it now, we blow out the schedule and budget.”  “So what you are telling me,” replied Amy, the Finance Director and owner of this project, “is that I either have to live without this feature or I have to OK more money and it will go into production even later?”

The next activity in The Project Manager’s Cycle continues the “initiation” activities of the cycle.  We’re still collecting and building the inputs to the week’s monitoring and controlling activities that we repeatedly perform for the life of the project.  Therefore, this activity can be performed before, concurrently with, or after Validate the Metrics and Validate Task Status.

For this activity, Incorporate Approved Change Control, we are applying to our model the changes that have been approved in the prior week.  We then re-baseline those elements of the model.  The model is, of course, the project plan including the project schedule.  It’s appropriate to perform this activity now so that as we update the actual results based on team members’ accomplishments, the updates are made to the current, approved plan.  In addition, we want subsequent reports to reflect the approved plan – the one the stakeholder’s expect to see.

This activity completes the “initiation” activities of the weekly cycle.  We now begin taking these inputs as well as other outputs from the previous cycle to work the project.

I’m going to throw in a semi-unrelated aside here.  It’s unfortunate, but “Change Management” has two distinctly different connotations that lead to unnecessary confusion when we fail to make the intent crystal clear.  Specifically, there is “Project Change Management” and “Organizational Change Management.”  This post, as well as the PMBoK references to change management are for project change management – identifying, tracking, and applying approved changes to the baseline project plan.

Organizational change management, in contrast, is what we run into when we plan implementation of our project results – the people, process, and tool changes that our project makes to the organization.