Guide to Project Change Management

Change is the only constant thing in life.

– Heraclitus, Greek Philosopher

Human nature is such that, if you ask me to do something for you, you expect me to have a plan and, following your approval of that plan, to adhere to it.

That’s why project management involves the development of a project management plan, which includes the budget, schedule, stakeholder communication plan, and any other items necessary for a successful project.  The plan is approved by the parent organization and/or project sponsor, and changes to the plan mid-project are unwelcome.

In fact, project changes are one of the easiest ways to raise the blood pressure of senior management.  Project plans are intended to provide certainty – of purpose and outcome.  When the plans change, the expectations must be revised, and project success is at stake.

But since change is the only constant in life, project changes should be planned into every project from the beginning.  The most likely potential changes, approval procedures, risk analysis, budget and schedule implications, and stakeholder communication should all be a part of the plan.  You can’t anticipate every change, but you have to be prepared for what you can.  Thankfully, the Project Management Body of Knowledge (PMBOK Guide) gives us direction on how to perform project change management.

Project changes must be considered in each of the three major phases of project management:

1. Planning
2. Execution
3. Monitoring & Controlling
4. Closing

Although the PMBOK Guide contains a fifth process group, Initiating, it is small and not all that relevant to project change management.

Planning Phase

During planning, a listing of configuration items is developed and placed within the project management plan.  These are things that require control to ensure that there are no unauthorized changes because they affect the budget and schedule of the project.

For example, in a house construction project, the house plans are configuration items.  If they are changed by anyone that wants to make the project easier for them, the project’s budget and schedule will spiral out of control.

Changes to configuration items are tracked with the following style of data (manually or within software):

Item: House Plans
Date	By	Change
2019/07/26	Bob	Issued for Construction
2019/08/25	Jane	Changed paint color
2019/10/12	Bob	Widened the garage

The change control process goes like this:

• When someone wants to change a configuration item, they make a request to the change control department.
• The change control department documents the change and analyzes the cost and schedule implications, reporting them to the project manager.
• The project manager makes the decision to proceed with the change request.
• The change control department prepares the request for change, together with the supporting documentation, to the change control board.
• The change control board meets and makes the final decision on whether to approve the change.
• The project manager implements the change.

This is the well documented project change management process within the PMBOK Guide, and on large megaprojects this process actually happens.  I know because I’ve been a part of it.  But since most projects aren’t megaprojects, suffice it to say the process is a simplified version of this that suits the circumstances.  The most important thing is to have an independent set of eyes (in place of the change control board) approve the change because project managers love to “gold plate” the product.

Hence, the steps to perform change control during project planning are:

1. The project’s success factors are identified, that is, the items that define whether the project has succeeded or failed.  Being on schedule and budget are almost always at the top of the list, but there are usually others as well, such as the satisfaction of certain stakeholders, or meeting quality goals.
2. Potential risk events that might affect those success factors are identified.  Things like stakeholder’s changing their requirements, or a plane crashing into the office.
3. The risks are analyzed according to their two underlying factors, probability and severity.
   Risk = Probability x Severity
   • When something bad has a high likelihood of happening, it’s risky.
   • When something bad is catastrophically bad, it’s also risky.
4. The highest risk events are prioritized into a risk register and tracked throughout the project.  Risk triggers are set up and monitored to allow rapid recognition that the risk has occurred, and pre-defined response plans are put into place.

Large megaprojects spend a significant portion of their budget assessing and managing project risks.  In contrast, small to medium sized projects normally spend little or no effort on risk analysis, however if it has value on large projects, don’t you think it would have a corresponding, albeit smaller, value on small projects?  If a small project manager spends one hour brainstorming about all of the unexpected things that could happen on their project and potential responses, they have performed risk management.

To finalize the planning process, the project management plan, which includes the configuration management items, change control process, and risk analysis, is submitted to the project sponsor (the person one level above the project manager, above the project) within the parent organization for approval.  Once the project management plan is approved, it becomes a configuration item itself and cannot be changed without re-approval by the project sponsor.

Project Execution Phase

During the execution phase, change requests are continually generated and fed into the project change management process.

Change requests originate from the project team and are fed to the project manager, who can either solve the problem by re-allocating resources and so forth, or proceed to making the project project change request.

Change requests can include defect repairs, or corrective and preventive action.

The change control process documents the change in a document called a change log.  This log tracks information about the change such as who requested it, why they requested it, and if/when it was approved.  If the project budget or schedule has been changed, or the project management plan updated, the process as determined in the planning phase is implemented.

The change control board analyzes the change request and makes a decision.  Once the decision has been made, the project management plan is updated and submitted for re-approval to the project sponsor.

Project Monitoring & Controlling Phase

Project control refers to the systematic monitoring of project cost and schedule status and comparing it against the cost and schedule baseline to determine whether the project is on track or not.

Hence, the monitoring and controlling function attempts to prevent project changes before they occur, or to obtain early warning to notify stakeholders of an upcoming project change.

This happens using a process called earned value management (EVM).

In EVM, specific progress reporting periods are determined (often weekly) at which time four variables are extracted from each task of the project:

1. Budget at Completion (BAC) is the task budget.
2. Planned Value (PV) is the expected progress expressed as the task budget.  For example, if a task lasts from Sep. 1 to Sep. 10 and it’s Sep. 6 today, the task’s PV = 60% of the task budget.
3. Earned Value (EV) is the actual progress expressed as the task budget.  For example, if the task is actually 75% complete, EV = 75% of the task budget.
4. Actual Cost (AC) is the actual cost of the task.  Most organizations track this quite well but if not you may need to collect receipts or implement a cost tracking system with the project team.

The current project status at the point of analysis (usually today) is determined using four variables.  Each task is calculated separately and averaged to determine the whole project status:

1. Schedule Variance (SV) tells you how far ahead or behind schedule the project is.
2. Schedule Performance Index (SPI) tells you how far ahead or behind schedule the project is as a percentage of the project.  It is a “schedule efficiency.”
3. Cost Variance (CV) tells you how far over or under budget the project is.
4. Cost Performance Index (CPI) tells you how far over or under budget the project is as a percentage of the project budget.  It is a “cost efficiency.”

Once the current status is determined, it is extrapolated to determine what the overall project values are trending to using the following four variables.

1. Estimate to Complete (ETC) is the remaining funds necessary to complete the project.
2. Estimate at Completion (EAC) is the anticipated final project budget.  This is one of the most heavily used metrics.
3. Variance at Completion (VAC) is the final project Cost Variance (CV).
4. To Complete Performance Index (TCPI) is the Cost Performance Index (CPI) necessary to finish on budget.

When the CV and SV are negative, the project is over budget and behind schedule.  The CPI and SPI will be below 1.  The EAC tells you where the trend is heading.

And the VAC tells you how much more money you need to ask for.

The major benefit of earned value management, outside of the great picture of project health, is the early warning signs of project distress that it gives you, at the time when implementing project change management is at its least painful point.

Project Closing Phase

Project closure is one of the most neglected, yet most visible, phases of the project to senior management.  This is because the project budget has run out and project managers feel they can make it up by skipping closure paperwork that won’t fail the project.

Fair enough.  Most of the time it won’t.

But since project change management are so integral to project success, the closure phase should re-evaluate each project change and determine if the change was a success, how well it was implemented, and what could be done differently next time.

Projects that go according to plan present no learning opportunities.  It’s the changes that should be evaluated with a retrospective that will benefit future projects.  This is supported within the PMBOK Guide, in the form of a lessons learned register, developed as an output to the Close Project or Phase process.