Project Change Management

Published: 2009-04-14
Last updated: 2022-03-20


Why do we need to prepare for project change management?


We set up all necessary planning documents, including a detailed Gantt chart that tells us when to do what – we just have to follow our plan. And yet, things happen which we cannot foresee and lead to problems which are not covered by our plans. Then, it proves useful to have at least a generic procedure how to deal with unforeseeable events and their impact, that is, how to manage project changes. Especially, when there are legally binding contracts we want to minimize the number of situations with any disagreement about the

  • necessity of a change,
  • time delay it causes, or
  • additional cost to be covered.

In the practical approach here, we start with a situation where two parties, customer A and contractor B, are involved in a project and draft a binding project contract. These principles can be extended to more complex situations.


So, what do we need to prepare for project change management? In section Project Contract Management, we introduce the generic project change management process with this diagram:


Change Management ProcessChange Management Process


Now we need to translate this diagram into a clearly structured procedure how A and B have to handle a change that is initiated by either party.






Project Change Management Process - Step by Step


Whatever event triggers the change, we need records of that event and notifications to all parties involved, in order to enable a profound analysis of the situation and its possible impact on all involved parties. Usually, we expect any change to have impact in terms of project scope, schedule and budget. This leads to the first four steps of the project change management process:

(1)   Collect all records of the event that triggers a possible change.

(2)   Notify all involved or affected parties, as soon as possible or reasonable.

(3)   Each party analyzes the situation and impact the event can have and identifies possible solutions and their impact.

(4)   Notify all involved or affected parties of the analysis results and the possible solutions, as soon as possible or reasonable.


In most project change situations, we expect different impact levels in terms of scope, schedule and budget, like in this example:

  • Solution 1: Three new work packages, two weeks delay, 0.04% additional cost;
  • Solution 2: Five new work packages, no delay, 0.7% additional cost;
  • Solution 3: One new work package, four weeks delay, no additional cost;
  • Solution 4: Do nothing and change the plan instead, eight weeks delay, 0.07% additional cost;
  • etc.

In any case, the next step is:

(5)   Prepare a change request, based on the different alternative solutions and send it to the involved and affected parties, as soon as possible or reasonable.


When we are already in project implementation phase we do not want to lose too much time with preparing and negotiating change requests. Therefore, it will be useful to setup a change escalation system for those different impact levels and reserve a portion of the project float or buffer, as well as a portion of the project budget, our project reserve, in order to cover “small” changes without losing time. This provides for the next step of our project change management process:

(6)   Follow the change escalation system for the discussion, negotiation and decision of the change request.


A simple change escalation system could look like the following table:


Cost
Delay Less than 0.05% 0.05% to 0.5% More than 0.5%
Less than 3 weeks
Sub-project managers of A and B Sub-project managers of A and B Project managers of A and B
3 to 6 weeks
Sub-project managers of A and B Project managers of A and B Project control board of A and B
More than 6 weeks
Project managers of A and B Project control board of A and B Project control board of A and B


In the example above: If we prepare a change request based on solution 1, then the sub-project managers of A and B have to negotiate and decide, while with a change request based on solution 4, the control board members of A and B need to negotiate and decide.


Whatever change escalation system you choose, make sure that it helps you to prioritize the change requests appropriately, following your experience with earlier projects. Too conservative escalation leads to too much work for higher level managers and most likely more time for making the decision; with too lax escalation the budget for changes might be consumed too early.


After making a decision about the change request, we continue our project change management process:

(7)   Issue the change order.

(8)   Execute the change order.

(9)   Issue the corresponding invoice, make the payment and close the change.


We conclude this sub-section with a summarizing diagram of the nine-step project change management process:


Linear Change Management ProcessLinear Change Management Process

Remark


Following the sequence of these nine steps takes extra time - how much time, strongly depends on how long the escalation and decision making takes. Please consider the consequences of this in the project schedule.




Traditional PM
Learning Path Navigation







Related topics

  • Project Planning Continued

    In the section Project Planning Continued, I show how to build the plans for change, contract, claim, communications management, and controlling tools

  • Contract Management

    In this sub-section, we describe contract management for project managers.

  • Project Claim Management

    In this sub-section, we propose a procedure for analyzing a claim situation which, in turn, supports successful project claim management.

  • Project Controlling Tools

    In this sub-section, we present useful project controlling tools for implementation phase which we prepare in planning phase.

  • Project Communications Plan

    In this sub-section, we describe the elements of a project communications plan.

  • Critical Chain Method

    In this sub-section, we describe what problems the critical chain method addresses and how it works.

  • Project Management Plan

    In this sub-section, we explain in what sense every project management plan is recursive.

  • Project Planning Software

    In this sub-section, we describe basic features and functionality project planning software should have and recommend how to use it.






Return to Project Planning Continued

Return to Project Implementation

Return from Project Change Management to Home Page





Your Comments

Have your say about what you just read! Leave me a comment in the box below.
Enjoy this page? Please pay it forward. Here's how...

Would you prefer to share this page with others by linking to it?

  1. Click on the HTML link code below.
  2. Copy and paste it, adding a note of your own, into your blog, a Web page, forums, a blog comment, your Facebook account, or anywhere that someone would find this page valuable.