I receive lots of queries on the Sequence of Change Request by PMP® exam aspirants. This blog is a step towards addressing queries related to –
Integrated Change Control and Sequence of Change Request.
A formal integrated change control starts with a change request. So, let’s begin by answering the question – What is a change request in project management?
As per PMBOK® Guide
We can say it is a tool to ask for a change in an approved plan or a project document. So we should have a plan in place before we raise a change request. If the project management plan is still emerging, we don’t need a change request. As here, we are still planning, so we can change anything without raising a change request. As an exception, the procurement planning process may generate a change request. To understand the reason, you may watch the following video:
In Summary, planning and initiating processes usually do not raise any change requests. In general, Change Request comes from the Execution and Monitoring processes. And, then we process it with the Perform Integrated Change Control.
Why do we need change request? Why can’t we get a perfect plan and follow it?
There is a famous military quote – No plan survives the first contact with the enemy. Still, we keep planning as we need a reference point to execute and complete deliverables. But many times we need a change in project plans and documents, because –
So, during execution and monitoring, the team come across requirements which have to be part of the project. Source of new requirements can be either-
Project internal and external project environment keeps changing, many times, which introduces lots of changes to the project plan, and documents.
How change requests are generated? What are the main sources of a change?
Who can ask for a change in the project management?
A change can come from multiple sources, some of the possible sources but not limited to as follows:
For more details on these sources, please watch following video from 10:10 time stamp:
Which project management processes generate change requests?
In general, there are three types of processes which generate change requests:
Expand, adjust, or reduce project scope, product scope, quality requirements, and schedule, and cost baselines.
We process all change requests through Performed Integrated Change Control process. This process handles all change requests irrespective of their origin or source. This process ensures overall impact of the change on the project and project objectives are taken care. And, based on this integrated impact analysis, this process approves, rejects, or defers the change request.
Now, the next question is what are the steps after raising a change request? And, what is Integrated Change Control in project management?
Here, the critical point is whenever a change request is received, suggested, or identified; we need to log it in the Change Log. Irrespective of the size of the change or the impact of the change, we record every change request in the Change Log.
After logging the change request, we move first to the impact analysis of integrated change control process.
Before looking into the steps of the Perform Integrated Change Control, let’s see what all it includes? What is Perform Integrated Change Control?
The Perform Integrated Change Control is the process: of:
Now, let’s see the Perform Integrated Change Control process steps to process a Change Request:
1. Impact Analysis: Whenever a change request comes, it has to be analysed for how it can impact other areas of the project. Like, if we need a change in the scope we need to see:
In summary, if need a change in one area of the project, it is crucial to see its impact on remaining knowledge areas. It makes a primary reason to do an impact analysis in an integrated form.
Requirement Traceability Matrix (RTM) is an important tool in doing impact analysis. RTM links a product requirement from its business need to the final deliverables. So whenever we want to do a change in any requirement, we can use this RTM to see how it will impact to:
For more details, please refer my blog – Requirements Traceability Matrix (RTM) – What Is RTM And Why Do We Need It?
In this impact analysis process, the project manager involves project team members and other stakeholders (if needed). The impact analysis influences the decision on the change request. Thus, Impact Analysis is a significant step in integrated change control.
2. Decision Making Process: A through impact analysis helps in quality decision. Once the impact analysis completed, we present it to the Change Control Board (CCB).
Based on change management plan, CCB use decision making techniques to accept, reject or to defer the change. The possible decision-making techniques but not limited to:
Now the question is – What is a change control board (CCB) in project management?
When we work in a complex project, we need a group of people who have different expertise to decide on the change request. This group of people forms the Change Control Board, which may include but not limited to:
These people collaborate to discuss, understand, and to decide the decision on change request.
Also, it is not necessary that each change request needs same people in CCB. The CCB can be at multiple layers. For example, if change request includes less than seven days impact, sponsor won’t be part of the CCB.
So, It is not like that CCB decides for each change request. For some changes, Project Manager alone can also review the results of the impact analysis. And, can choose to proceed with the change, reject, or to defer it.
So now the question is – When CCB takes the decision and when the project manager alone can take the decision?
It is dependent on the level/impact of the change. The change management plan describes for what level of changes, we need to involve CCB. And for what kind of changes, the project manager can take the decision.
Here important point is that the project manager is also part of the CCB. Also, in some cases, after CCB approval, a customer or sponsor approval is needed, unless they are part of CCB.
The Change Management Plan explains how the CCB forms based on the level and complexity of the change. Also, it tells the roles and responsibilities of CCB members.
3. Update Change Log: Once CCB takes the decision, we need to register in the change log. We need to record Change request in the change log for all details like
The Change Log is a repository of whatever happens to the change request. It may include details like Change Request ID, Source, Raise Date, and the Final Decision
4. Update Project Management Plan/Project Document’s: 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, we refer impact analysis to get information about what all needs to be reviewed/updated.
5. Communicate to Stakeholders: Irrespective of acceptance, rejection or deferring of change request –
Once the final decision comes for the change request, we inform stakeholders about it. If Change request gets Rejected or Postponed, the communication is sent to requestor/stakeholder with the reasons for rejection or postponed.
Now, we come to our next segment – WHY formal change management process?
Many times I observe a common question from PMP® exam aspirants –
Why we follow so many formal steps for even tiny changes in the project? Which may not even impact the project baselines or project plans.
It is important to understand that we should not assume the impact of any change. We need a formal change control process to analyze the impact of change. So that we can do respective planning 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 we can send it with the due deliverable.
Ray and his team conducted a meeting to discuss the change. And, decided to implement the change without following a 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 would take five 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 added the scope without doing any impact analysis. And, as impact analysis not done, scope baseline doesn’t contain the information of the new scope added recently. Since it was not the part of requirements and scope baseline against which they were checking the deliverable –
While inspecting, the quality control team missed inspecting the new functionality added –
So, here we can see a small change in the scope of the product has cascaded into a large amount of rework afterward.
If Ray had followed the formal change control process for the scope change received –
Irrespective of what the client is saying or without any assumption about change. All the affected 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.
The Change Management plan describes the process of managing change requests. In general, it explains:
It depends. It depends on how you mentioned the handling of changing documents in the change management plan. Level of changes is not equal for each project documents. Like, even if you need a small change in the Requirement Traceability Matrix, you need to follow a change control process. Because, impacts are high in changing in Requirements Traceability Matrix. But, the change management plan can allow you to update issue log without any formal change control procedures.
It depends. Many times, some change requests do not qualify as a change. Because these are mentioned in the scope exclusion of the project scope statement. So if something is an exclusion in the project charter or project scope statement, we don’t need a change request for it.
If a change request needs an update in a project document, we may or may not need a formal change control procedure. The change management plan is the ultimate guide to understand if we need to follow a formal change control procedures.
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.
You can join the discussion on the same and do post follow up questions here on our DISCUSSION FORUM. You may also want to check our other blogs on PMP® Trainings.
The following video explains the Perform Integrated Change Control process in depth, do watch it:
Enroll to our FREE PMP® Introductory Program to learn more about PMP® certification
|PMP Certification and Training||22 July – 20 August 2023||Bangalore||More Details|
|PMP Certification and Training||17 Aug – 15 Sept||Chennai||More Details|