Change Request in Project Management
Change Request Management
Introduction
Project is an instrument of change. Hence during the project lifecycle changes are inevitable. Therefore Change Request in Project Management is an extremely important process in any project. Uncertainties in a project can be managed by using the concept of “Progressive Elaboration” and “Rolling Wave Planning” techniques. As a project manager, you must understand that how much agility is affordable and acceptable. For example in a one-year-long project, if you decide that you will make only a monthly plan and not anything beyond this period (because many things can change in one year period), then what is the guarantee that this one-month plan will not change during execution? Absolutely no guarantee!
What is the Meaning of Change
PMI’s PMBOK helps us handling the change request very carefully throughout the project. As per PMBOK change request is any deviation from the plan which you need to follow in order to make a project successful. Therefore change requests can be related to baselines (scope, schedule, cost, quality), plan (risk, communication, resources, procurement, etc), project documents (design, RTM, issue register, risk register, procurement document, etc), organization process assets (OPA), and enterprise environmental factors (EEF). PMBOK 5th edition has defined 47 processes and out of those 16 processes can issue change request at any time in the project life-cycle. And there is only one process that can integrate all change requests and this process is “Perform Integrated Change Control” (PICC)
What is Change Management Process?
PICC process of the PMBOK suggests the following steps to process a change request. The first step is to review the change requests. Review includes.
- Ensure that the change request is properly understood.
- Assigns urgency to the change request (e.g. immediate, next week, next release, etc.)
- Assigns type to the change request ( e.g. resources, training, scope, quality, tools, etc.)
- Assigns source to the change request (e.g. Security, IT Infrastructure, Customer, Management, Sponsor, Marketing Team, etc.)
The next step of the PICC process is CR is assigned to an expert(s) for the evaluation. After this expert(s) evaluates the change request. Evaluation includes.
- What are the other existing systems CR is affecting? For example, the sponsor has CR where he is requesting to assign a full stake developer (FSD) to the project team. As of today when FSD is not there then what are the problems that a team is facing?
- How serious is the CR? Does it justify the urgency set by the CR raiser?
- What is the impact if a CR is accepted? For example, If FSD is hired and assigned to the team then what needs to be done before he is injected in the midst of the project. What are the consequences of this hiring?
- Estimates the financial cost (impact) of this CR.
After this evaluation CR is forwarded to a “Change Control Board”. The size of the impact of the change may be small, medium, or huge. The impact of the change may on architecture, cost, schedule, quality. Depending upon the size and complexity of a project, a project can have multiple layers of “Changer Control Board” CCB. Depending upon the power/authority of the CCB a CR is forwarded by the PM to an appropriate CCB. The CCB makes the final decision to accept or reject the change request.
Whatever is the final decision of CCB, PM updates project documents and project plan accordingly and assign the work project team. The project team implements change requests and the implementation of CR is verified by the quality team.
PMBOK Processes for Change Management
As per PMBOK 5th Edition following 16 processes can raise change requests. These processes are part of different process groups. The 17th process which handles all the CR is Perform Integrated Change Control (PICC) is not listed below.
| 1 | Direct and Manage Project Work | Executing |
|---|---|---|
| 2 | Perform Quality Assurance | Executing |
| 3 | Manage Project Team | Executing |
| 4 | Conduct Procurements | Executing |
| 5 | Manage Stakeholder Engagement | Executing |
| 6 | Monitor & Control Project Work | Monitoring & Controlling |
| 7 | Validate Scope | Monitoring & Controlling |
| 8 | Control Scope | Monitoring & Controlling |
| 9 | Control Schedule | Monitoring & Controlling |
| 10 | Control Cost | Monitoring & Controlling |
| 11 | Control Quality | Monitoring & Controlling |
| 12 | Control Communications | Monitoring & Controlling |
| 13 | Control Risks | Monitoring & Controlling |
| 14 | Control Procurements | Monitoring & Controlling |
| 15 | Control Stakeholder Engagement | Monitoring & Controlling |
| 16 | Plan Procurements | Planning |
Conclusion
From the above table, you can observe that a CR is raised during the project execution or the M&C stage. To ensure that you don’t complicate the PICC process or increase the work of experts these processes need to be tuned in such a way that a sensible CR is raised. Another thing we need to keep in mind that when CR is not raised on time it is leaked as a defect in the product. The cost of not raising a CR on time can be costly when we need to fix something in a final product.