I receive lots of queries on the Sequence of Change Request by PMP® 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 Sixth Edition,
Change Request is a formal proposal to modify a document, deliverable or baseline
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 –
- Project team works in an uncertain environment – In projects, we cannot plan everything with 100% confidence. A project manager has to deal with discoveries or changes. If things are so predictable and there is no need for change, then we can say it is not a project – actually, it is an operational activity. Changes are inevitable in projects.
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-
- External like industry competition, where competitor launch a similar product or
- Internal like significant variances in the different project area.
Project internal and external project environment keeps changing, many times, which introduces lots of changes to the project plan, and documents.
- Project team keep learning: As the project moves forward, the team get to know more about assumptions, about the project and product features. Initially, we take lots of assumption, and with time, we get learning related to those assumptions. All these learning are good sources of changes.
How change requests are generated? What are the main sources of a change?
- Value Added: During project execution, if we discover new value-added features, we need change in the project management plan.
- External Events: All environment related reasons which are outside control of the project team, also trigger changes. Like industry competition, government regulations and rules.
- Errors or Omissions: Good amount of change comes from the errors and omissions in the project management plan. When we discover and learn new things, we need to raise a change request.
- Risk Responses: Many times, risk response also become the source of a change request. Let’s take an example; the project team identified that a selected component might introduce security issues. So as a risk response, we need to replace it with another component, which needs a change request.
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:
- Project team
- Preventive Actions
- Corrective Actions
- Stakeholders Need
- Defect repairs
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:
- Executing Processes: During completing project deliverables, sometimes a need appears:
- To change a document or
- An approach mentioned in the plan.And, we raise a change request. The Direct and Manage Project Work is the main source of change requests.
- Knowledge Area specific Monitor and Control process: During tracking and reviewing a knowledge area specific status and progress, we feel need of a change request. Like, when we are doing variance analysis, inspection, or meetings to understand -The actual results compared to plan – we may find a need to change a direction, which results in the change request.
- During Monitor and Control Project Work process: When we are tracking and reviewing overall progress, then also we may identify a need for change. Here, we may raise a change request to –
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:
- Reviewing all changes requests,
- Approving changes and
- Managing changes to the organization process assets, project documents,
- Communicating their disposition.
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:
- How it will impact cost?
- What risk can it introduce?
- How will it impact quality and what quality factors we need to take care?
- How will it impact on stakeholder’s involvement?
- Do we need to procure something?
- How will the schedule be affected?
- What resources are required? Do we have skills in the existing team?
- What communication needs we need to take care?
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:
- Design requirements,
- To the test cases, and
- To the final code?
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:
- Multicriteria Decision Making
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:
- Project Sponsor
- Customer Representative
- Project Manager
- Technical Experts
- Subject Matter Experts
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
- What decision has been taken on it,
- The reasons for rejection/postponed, and
- If accepted then what are the follow-up steps.
If I talk about – What is Change Log?
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 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.
Frequently asked questions:
What’s in a change management plan?
The Change Management plan describes the process of managing change requests. In general, it explains:
- The sequence of the change request,
- What type of changes need formal change control and where you don’t need a formal change control procedure?
- Roles and responsibilities of Change Control Board,
- For what level of the changes the project manager can alone take decisions
- Where is sponsor presence must in CCB?
- After CCB approval if customer approval is needed unless he is part of CCB?
Do we need a change request for modifying project documents?
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.
Do we need to raise change request for all changes asked by stakeholders?
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.
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