Integrated Change Control – Sequence of Change Request

Most of the times, I receive lots of queries on Sequence of Change Request by several PMP® aspirants preparing for the certification exam.This blog is a step towards addressing queries related to Integrated Change Control – Sequence of Change Request.

Let us begin by answering what is a Change Request?

As per PMBOK® Guide Fifth Edition,

“Change Request is a formal proposal to modify any project document, deliverable or baseline. “

The reasons for a change request can be:

• Preventive actions – How to prevent potential non-conformities in the project, e.g. training the team members on new technology required in the project. For this training, a change request is required as it may impact the schedule baseline (for the days of training) and cost baseline (for training cost). The proposed training may prevent some amount of rework in the project.
• Corrective actions – How to correct non-conformities in the project, e.g. Noncompliance points reported post audit which can refine the project’s process. A change request is required to implement these corrective actions in the project as it may change the schedule and scope of the project.
• Defect repair, e.g. rework which is required to rectify the points identified as defects while inspection will be logged as change request (s)
• An update request for any change in the project, e.g. change in project scope or some compliance related work needed to be done via following a change control process of the project.

 

Irrespective of the reason, intensity or size of change, a formal change request is required to take forward the change to be a part of the project activities or project baselines.And, how the change request need to documented, managed, monitored and controlled in the project is defined in the Change Management Plan.

Now, we come to our next segment – WHY formal change management process?

It is a common perception that why follow so many formal steps for very small changes in the project, which may not even impact the project baselines or project plans. It is important to understand that the impact of any change shouldn’t be assumed. The formal change control process is required to analyze the impact of change so that the respective planning can be done in advance.

Let’s exemplify it – Ray is the project manager of a website development project. His client sent a scope change for the website and requested Ray to implement the change in the project deliverable which is due after 2 days. As per client,the change is small and can be sent with due deliverable.

Ray and his team conducted a meeting to discuss the change and decided to implement the change without following formal change control process. As they assumed that change is quite small and no need for so many formal steps. They implemented the change on project deliverable without doing even any impact analysis.

The deliverable was not accepted by the customer, as the new scope added was not working as desired.  This failure of new scope added, ended in several defects from the customer.

Ray realized that the defect repair will take 5 days and that he needs to review the schedule baseline and add the new scope in scope baseline as well. The mistake what Ray and his team did was that they just added the scope without doing any impact analysis. Since, impact analysis not done, scope baseline doesn’t contain the information regarding the new scope added recently. The quality control team while doing the inspection of the deliverable missed to inspect the new functionality added since it was not the part of requirements and scope baseline against which they were checking the deliverable. So, here we can see a small change in the scope of the product has cascaded into a large amount of rework afterwards.

If Ray had followed the formal change control process for the scope change received from the customer irrespective of what the client is saying or without any assumption about change, all the impacted documents/ plans/baselines would have been updated. And, at the time of quality control of the deliverable, all the non-compliance with the requirements must have been captured before deliverables sent to the customer for acceptance.

Sequence of Change Request-

• Whenever a change request is received or suggested or identified, itneeds to be logged in the Change log of the project. Irrespective of the size of the change or the impact of the change, each and every change need to be logged in the change log
• Project manager alone cannot do the impact analysis, inputs from the project team and if required, from stakeholders are needed. In impact analysis, the impact of the proposed change is analyzed on all project constraints like on scope, schedule, quality, risk, cost or any other project dimension. This is a very important step in integrated change control as impact analysis will be considered as input for the Change request’s approval or rejection.
• Once the impact analysis done, it is provided to CCB along with change request for the decision of Approval/Postponed/Rejection. In several organizations, authority to take decision on change request lies with Project Manager also, depending on the level/impact of change. And if the impact of change is bigger than that, change request goes to CCB for further decision. A point to remember here – Before Change request is reviewed by the CCB; Impact analysis must have done by the project team as it is the input to CCB for taking decision on change request. OnceCCB takes the decision, it needs to be registered in the change log.
• If Change request gets approved, the work related to change request becomes part of the project and all related project documents, plans and baselines got updated. For these updates impact analysis is referred to get the information what all need to be reviewed/updated.
• If Change request gets Rejected or Postponed, the communication is sent torequestor / stakeholder withthe reasons of rejection or postponed.
• Record of Change request in the change log need to be updated for all details regarding change request like what decision has been taken on it, the reasons for rejection/postponed, and if accepted then what are the follow up steps.

Now, you must have understood what all Integrated Change Control is all about and how it impacts the entire performance of the Project and project team. Thus, not only the presence of change control process is needed in the project, but it has to be followed in the project consistently too. Change control process prevents unnecessary risks to the objective or the success of the project.