Let’s talk Project Change Control. There’s one distinctive sign that your project is going well. A stakeholder approaches you in the corridor, and says:
‘We’re very pleased with how your project is going…’
‘The only thing is… we’ve changed our minds.’
This is a job for Project Change Control.
Even on the most traditional of projects, you will need to adapt to changes. They may be driven by technology, commercial opportunities, regulatory changes, or a dozen more reasons. Whatever it is, you need to be flexible.
And the longer your project, the bigger the need. So it pays to set up a change control process as part of your project setup. This usually happens during the planning stage, and it will serve you well, during your delivery stage.
In this giant guide, we give you everything you need to know to start setting up a robust change control process for your project.
- Why do we Need Project Change Control?
- What is Project Change Control?
- How does Project Change Control Work?
- Some Specific Change Control Scenarios
Let’s get straight into it!
Why do we Need Project Change Control?
Great question. The answer is simple…
Shift happens! Things change. So, no matter how much you’d like to nail down your scope from day 1 and never review it… You can’t. Your project needs to respond to changes if you want it to stay relevant.
Changes can come from many sources and I use the SPECTRES framework to remember the most common:
- Social changes among customers, stakeholders, and society in general
- Political changes – national, local, and within your organization
- Economic and financial changes
- Commercial and trading changes
- Technology changes
- Regulatory and legislative changes
- Environmental changes – not just ‘The Environment’, but your work and local environments
- Security or safety-related changes
The problem with changes is that they can create project chaos. As one stakeholder after another requests this change, and then that one… It is hard to keep track. And the temptation will be to say either:
- ‘Yes, no problem. We’ll sort it.’ or
- ‘No. We can’t. The scope is fixed.’
…or maybe you just pretend not to hear!
The one thing you need, as a Project Manager, is control. So, we use a project change control process. This gives you the control you crave.
The alternative is madness. You will either have:
- No control
…over your project costs, schedule, quality, or risk, or
- Frustrated stakeholders
…and the possibility of missed opportunities or, worse, un-met requirements
That’s why you need a change control process.
Contract Change and Change Control
And there is one other reason too. Often, some or all of your project is subject to contractual obligations. You use contractors, suppliers, and consultants who expect to be paid for the work they do.
Or, maybe you are a contractor, supplier, or consultant. Without a formal change control process, you have no mechanism to control any changes to contracts. And let’s not even think about the consequences there!
By the way, within a contract, what we will call a Change Request later in this article may also be known as a Variation Order, or VO (or Contract Variation Order – CVO).
For a full guide to Project Procurement, here’s another of our detailed articles:
And, if you want to weigh-up the pros and cons of fixed- and variable-priced contracts:
So, What is Project Change Control?
So, I hope we’ve comprehensively established a need for project change control. The next question then, is precisely what is it. Let’s start with a short video:
A Definition of Project Change Control
Project change control is a process. It starts with requests for changes to the scope, functionality, or capabilities of your project’s products (or deliverables). The process will then:
- Capture the request formally
- Assess it rapidly
- Carry out a full evaluation
- Review the options and make a decision
- Implement the changes
- Track the project changes and learn from the process
Is Implementation a part of the Change Control Process?
Note that there are many project managers who will, quite reasonably, argue that step, Implement the Changes, is not a part of change control. Indeed, the PMI’s PMBOK Guide process: ‘Perform Integrated Change Control’, does not discuss implementation.
The reason I prefer to include it, is that it forms a bridge to an important part of the process: ‘Track and learn from Project Changes’.
So, you can think of the Project Change Control process as either the first four or all six of these steps. It is up to you.
Speed is of the Essence
One thing I do want to emphasise is this. The longer you wait to implement a change; the more time, money and resources will be lost on potentially abortive work. Delay costs time and money. So, the faster your change control process works, from first request to start of implementation, the better. I’ll say more about this towards the end of this article, when I answer the question: ‘What if you get a decision to defer?’
How do the BIG Players Define Project Change Control
I always think it’s worth comparing the different definitions by the main authorities. In the case of Change Control, there is remarkable consistency!
A process whereby modifications to documents, deliverables, or baselines associated with the project are identified, documented, approved, or rejected.A Guide to the Project Management Body of Knowledge (PMBOK Guide), 6th Edition
The Project Management Institute (PMI)
The process through which all requests to change the approved baseline of a project, programme or portfolio are captured, evaluated and then approved, rejected or deferred.APM Body of Knowledge, 7th Edition
The Association for Project Management
The procedure that ensures that all changes that may affect the project’s agreed objectives are identified, assessed and then approved, rejected or deferred.Managing Successful Projects with PRINCE2
I take a slightly different approach in my free glossary, ‘Be on the Inside: Decode the Jargon of Project Management‘.
The process of managing requests for change to make sure decisions are made accountably. The requests are documented on a change request form, and all requests are logged and tracked on a change log. It ensures that where changes are authorized, appropriate additional resources are allocated.Be on the Inside: Decode the Jargon of Project Management (2nd Edition)
Dr Mike Clayton, OnlinePMCourses
How does Project Change Control Work?
Nothing beats a good checklist! This section is linked closely to our Change Control Process Checklist – one of over 50 in our Project Management Checklists Kit.
The other thing you’ll need is a Change Log. This is a simple document (or software tool) that captures each element of the process. It provides a useful management tool for you, and an invaluable audit trail for the project. It’s an important part of your project governance. We provide Change Log templates as part of our Project Management Templates Kit.
[thrive_text_block color=”note” headline=”Get Your Free Change Control Resources”]
We’re offering our readers free copies of our Change Control Process Checklist and our PDF Change Log template.
Step 1: A Request for Change
The process starts when someone suggest or requests a change. This is known as a ‘change request’ or a ‘request for change (RfC)’.
Either way, your response is simple. Thank them for their request and ask them to document it. You’ll need a simple Change Request form – either paper or online – like the one in our Project Management Templates Kit. It should have three parts:
– with a Reason for the request – either the benefits or the compelling driver
– with the Implications of the request – your team will complete Part 2 at Step 3.
– with space for the decision-maker to formally record their endorsement (signature usually) and reasons.
This is the structure of our Change Control template; part of our Project Management Templates Kit.
Step 2: Change Control Rapid Assessment
Not all change control processes have this step. But it makes sense for the project manager to conduct a quick assessment of the change request. There are two things they can consider here.
1. Familiarity of the Change Request
Has this request (or a similar one) been made before?
- If this is new, then proceed.
- Otherwise, if this request is familiar, has a decision already been made?
If so, refer the requester to the decision. You’ll probably not need to take further action.
- If this change request is still in process, consider whether this new one can be combined with it?
2. Scale of the Change Request
In some processes, the Project Manager has discretion to resolve ‘minor’ change requests. This will depend on your authority – and often your seniority.
Ask: ‘Does the request have nil or de minimis impact on budget, schedule, resource requirements, or quality?’
If so, the project manager can make the decision with minimal formality.
Step 3: Change Request Evaluation
The bulk of your work comes at this step. Work with your project team to review the requested change and document the implications for:
- Project Timescales
- Project Budget
- Risk profile
- Resource requirements
- Other projects and organizational activities
This will allow you to complete the second part of the change request form. From this, you can present a balanced assessment to the decision-makers. In many ways, this is like a mini Business Case for the change, with:
- The benefits and reasons for the change set out by the proposer
- The costs, risks, and other implications set out by the project team
Step 4: Formal Review
Your project decision-makers need to assess the case you present. If you have done your job well, they will have the basis to decide whether to:
- Accept the request for change.
The case is compelling. The benefit outweighs the costs and risks involved
- Reject the request for change.
The case is weak. The benefits do not outweigh the costs, or the delays, costs, or risks are too great.
You will need to record a formal decision and have your decision-makers endorse it in whatever way your organization requires – usually, a signature. You will also track the staus on your Change Log.
The only alternative to accepting or rejecting the request for change is to defer the decision. We’ll look at that as a specific scenario in the next section, when we answer the question: ‘What if you get a decision to defer?’
Step 5: Change Implementation
Now it’s time for you and your project team to implement the decision. That should be pretty straightforward. After all, you’ve completed the re-planning:
- resource planning
- risk mitigation
Now it’s just work!
Step 6: Track and Learn from Project Changes
As with all good project implementation, you need to monitor and control the implementation of the agreed changes.
And, when the changes are completed, it is wise to review both the process and the outcome of the decision. This is the way you will learn from the experience and improve both your process and its implementation.
Some Specific Change Control Scenarios
Right. Now you know the reasons why we need project change control, what it is, and how you do it. So the last thing to cover are six of the more important specific scenarios and ‘what if…?’ questions I get asked.
1. What if You get a Decision to Defer?
And the first question is the commonest one. It’s also one I’ve trailed above. So, what if you get a deferral decision?
Well, the first priority is to ensure that your decision-makers know that there is only one acceptable reason for deferring their decision. And that is because they do not have sufficient information on which to base a robust decision. And if that’s the case, whose fault is that?
It is your job to provide your decision-makers with the information and analysis they need. And if you’ve not done it, you need to answer their questions and turn around a revised evaluation rapidly. Delays to change control decisions can have a big cost to your project – both in budget and schedule.
This, by the way, is also the reason why there is only one justification for your decision-makers to defer making a decision. ‘It’s too difficult’ just won’t do. After all, it won’t get easier, and time and budgets will only get tighter. That will make an ‘accept’ decision harder to make.
So, if the decision is too hard…
Make it a no. Force a reject, and suggest the person who requested the change looks for an alternative change request, which may be more acceptable.
2. What if the Decision Maker makes the Request for Change?
Surely, in this case, you don’t need to go through the whole process?
They can approve their own request, and require you to go through with it?
Well, in practice, probably… ‘yes, they can’.
And, pragmatically, you don’t want to waste time on a process that adds little value.
But the process does add some value
Good governance. You need your project to be transparent and accountable. So, even in this case, I’d counsel you to follow the process – even if you apply less detail. And, as a minimum, complete a Change Request form, get that signature, and write up your Change Log. This provides the audit trail you need, to cover yourself in the case of an audit.
3. What if You Need to Change a Contractual Agreement?
A signed change request form has a contractual equivalent: a Variation Order, or VO.
This is a signed change request for a contract. It is a mini-contract that varies the original contract. So, sometimes, you will hear a change request referred to as a VO, and the change control process referred to as a Contract Variation process.
4. What if it’s just a Small Project?
As always, good judgment is a key part of project management. The bigger, more complex, more strategic, and riskier your project is… The more robust, rigorous, and detailed your change control process will need to be.
So, if you are working on a small project, with low risk, then you should scale down the complexity and administrative burden of your change control process. Never let your urge to follow some standard process get in the way of doing what is sensible!
5. What if it’s a Big, Complex Project, with lots of Change?
On the other hand, I’ve managed a large project with a full time team of change control staff. They fed a constant stream of detailed technical assessments of change requests to our decision-makers.
And the decision-making was carried out by a formal ‘Design Authority Group’ (DAG). This consisted of a small group of very senior executives. At the peak of the project, they met three times a week. They received briefing papers, and sometimes formal presentations by the change control team and by the senior users or technical managers responsible for the change requests. And the team had a full-time administrator to support the process.
6. What if You are Using Agile Project Management?
In principle, Agile processes don’t have to deal with change requests, because scope is never locked down. Each iteration or sprint works on a new element of functionality, capability, or scope. So, the changes come as a part of the process, at the start of the iteration, when determining its priorities.
The Agile Manifesto welcomes changing requirements, even late in development.Principle 2 of the 12 Agile Principles
Agile processes should harness change for the customer’s competitive advantage.
See our article, Agile Principles: The 12 Keys to Adaptive Project Management
Iterations are short, so within them, there should be no change.
That said, reality doesn’t always respect principles. The subject of change control within the various different Agile methodologies is a big one. It is also one I am not an expert in. So, I’ll refer you to an excellent comprehensive article by Brad Appleton, Steve Berczuk, and Steve Konieczka, called ‘Agile Change Management: From First Principles to Best Practices‘. This covers the Scrum and XP Agile methodologies.
For a simpler read, I also like Steve Thomas’s article: ‘Agile Change Management‘.
What are Your Experiences or Questions regarding Change Control?
I’d love to hear from you on your Project Change Control experiences. What are your recommendations, or what questions do you have?
I’ll read and respond to every comment you make.