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:
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.
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:
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:
|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 project managers of had 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 taking the decision; with too lax escalation the budget for changes might be consumed too early.
After taking 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:
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.