There’s one distinctive sign that your project is going well. A stakeholder approaches you in the corridor. ‘We’re very pleased with how your project is going…’ they say. ‘The only thing is… we’ve changed out minds.’ Oh no. 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 set up. 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.
Great question. Let’s get started.
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:
The problem with changes is that they can create project chaos. As one stakeholder after another requests this change then that one… It is hard to keep track. And the temptation will be to say either:
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. Either:
That’s why you need a change control process.
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!
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:
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:
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 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.
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?’
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.
We’re offering our readers free copies of our Change Control Process Checklist and our PDF Change Log template.
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. It should have three parts:
This is the structure of our Change Control template; part of our Project Management Templates Kit.
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.
Has this request (or a similar one) been made before?
In some process, 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.
The bulk of your work comes at this step. Work with your project team to review the requested change and document the implications for:
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.
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:
You will need to record a formal decision and have your decision-makers endorse it in whatever way your organization requires – usually, a signature.
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?’
Now it’s time for you and your project team to implement the decision. That should be pretty straightforward. After all, you’ve done the planning; the scheduling, budgeting and resource planning. Now it’s just work!
As with all good project implementation, you need to monitor and control the implementation of the agreed changes.
And, when the changes are completed, t is wise to review both the process and the outcome of the decision. This is the way you will learn from the experiene and improve both your process and its implementation.
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 some of the more important specific scenarios and ‘what if…?’ questions I get asked.
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 reliable decision. And if that’s the case, whose fault is that?
Yup. It’s yours.
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 except that time and budgets will be 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 ask suggest the person who requested the change looks for a new request, which may be more acceptable.
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 and get that signature. This provides the audit trail you need t cover yourself in the case of an audit.
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. 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.
As always, good judgement 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.
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. They met three times a week, at the peak of the project. They received formal presentations by the change control team, and by the senior users or technical managers responsible for the change requests. The team had a full time administrator to support the process
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.
Agile processes should harness change for the customer’s competitive advantage.
Iterations are short, so within them, there should be no change. That said, reality doesn’t respect principles. The subject of change control within the various different Agile methodologies is a big one. It is also one I am not 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‘.
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.
Dr Mike Clayton is one of the most successful and in-demand project management trainers in the UK. He is author of 13 best-selling books, including four about project management. He is also a prolific blogger and contributor to ProjectManager.com and Project, the journal of the Association for Project Management. Between 1990 and 2002, Mike was a successful project manager, leading large project teams and delivering complex projects. In 2016, Mike launched OnlinePMCourses.
Please log in again. The login page will open in a new window. After logging in you can close it and return to this page.