The Change Control Process is Your Secret Weapon to Scope Management
Projects are iterative by nature, and often scope is refined as the project progresses. What you set out to deliver isn’t always the same as what gets delivered.
That’s a normal part of project evolution, as the stakeholders find out more about how the end result will look and work, and more business information comes to light. However, it’s how you deal with changes that matter.
Scope creep is the name given to extra features, functions or requirements that are not authorized parts of the project scope. It can cause issues on projects because the scope seems to balloon and it looks like the work will never end.
The change control process is your secret (OK, not so secret) weapon to managing scope creep and ensuring that changes are reviewed, analyzed and approved.
So how does it work?
The change control process
Changes are expected on projects, and the change control process helps you manage them. Here are the core steps in the process:
- Someone decides it would be good to have a change
- They inform the project manager of the change suggestion, via a change request
- The change request is reviewed by the team
- The size, scale and scope of the change is analyzed to see what impact it would have to the project overall
- The team make a recommendation to the project sponsor or key decision maker about whether the change should be incorporated or not, and if it should, what the impact would be
- The sponsor accepts or rejects the change.
The change request itself can be in several formats. It could be an informal conversation in the corridor, or your process may require a formal document to be completed, covering all aspects of the prospective change. The level of formality in the process is up to your PMO and is driven by the project management culture of the organization.
What goes into a change request
A project change request can cover changes to:
- Scope
- Budget
- Timeline
- Quality measures
Or something else. However, changing one thing normally has implications for everything else, and in our experience, most changes relate to amending the scope of a project.
For example, let’s say you receive a change request to add an additional feature into the scope of a mobile app your team is building. The request seems reasonable and you can see that the feature will improve the end result.
The request is to add the feature into scope – great. But doing so is going to cost money. It might mean work that is already completed has to be redone. It may need extra or specialist resources, or it might mean the current team has to work a bit longer to finish the request.
In other words, you can’t magic up a change just because it’s a good idea. It has to be paid for with money and time, and someone has to do the work.
The change request should document the full implications of going ahead with the change, so the decision makers have the information they need to make the right choice.
Options for change requests
When a change request is received, the team evaluates it and then has to make the decision. Do we accept this change or not? If not, is it a ‘no’ forever or simply a ‘not now’?
It’s normally the project sponsor who has the power to accept or reject change requests because they are the person who holds the budget and agrees the timescales. In some situations, someone else might be the change approver, so be sure the decision is being made by the most appropriate person.
Tip: If the change is accepted, be sure to get agreement on where the money is coming from to do it before you start the work!
Regardless of the outcome of the request, the decision should be documented for future reference. Too often we see managers ask why something wasn’t done because they don’t recall that the change was rejected. Sometimes the rationale for the rejection wasn’t clear, so they ask again, a little later, hoping things have changed. Things might have changed on the project, but if their request was an inappropriate idea then, it’s probably still an inappropriate idea right now.
If the change was agreed in principle but the decision was taken to hold off working on it right now, you can add it to a ‘Phase 2’ list or the product backlog so it’s considered for the future.
Keep a record of decisions made and the key reasons for those decisions so you can provide the information if required.
Next steps
The change management process is a key part of being able to execute your project effectively. We cover it in our Project Management Fundamentals training, where we have the time to go into it in a more hands-on way than in this blog post.
Make sure all the project managers on your team, and the stakeholders within the project, have a solid understanding of how change is to be managed. Support them with training if they need additional guidance in how to make change work for successful project delivery.