There aren’t many ways that you can stop change completely on your project, and frankly, that would be a bad idea. However, changes to project requirements can have a massive financial and schedule impact.
Take, for example, this anecdote from a McKinsey study. The project team at a bank only involved the finance department towards the end of the project, a few months before the transformation project was due to launch. Unfortunately, this led to the need to make changes to the system’s accounting modules. Recent changes to how the bank operated hadn’t been picked up by the project team, and as Finance hadn’t been involved to that point, they had no way of knowing the impact. The changes delayed the project by 3 months, at a cost of over $8 million. That’s a huge impact that probably could have been avoided by having the right stakeholders on the team, but it shows how important it is to manage change well.
The changes in this example sound to me as if they were essential, but you’ll often get asked to incorporate changes that don’t truly have to be done right now. If the initiator understands that their request is going to cost millions and delay the project overall they might better appreciate why they should back off and agree to bounce their change into Phase 2.
Higher project cost and schedule delays are two reasons why change control for new project requirements is important, but there are other benefits too. A Forrester study concluded that businesses are hit with 5 other issues when change control isn’t carried out appropriately on IT projects:

Poor software quality
Dissatisfied customers
Unnecessary rework
Failed changes
Downtime in production systems.
The change control process can help you avoid all of those issues. Your change process should look something like this.

1. Change request
The change arrives with the project manager. This could be via email, a formal request template, or through a chat in the corridor or during a meeting. You may require formal documentation or you may be happy to take on ad hoc requests – that’s up to you and will probably depend on the scale of your project. Anyone should be able to put forward a request but if it’s a really big project you may want to implement some control on that to say, for example, only team leaders can propose changes on behalf of their team.

2. Change log
The change is added to the change log (or register). Record the date, the originator, a brief description and the person responsible for seeing this change through the process.

3. Change analysis
Review the change. What implications does it have for the project? The budget? The schedule? The team? What work has to stop so we can do this? What’s the risk of not doing it? What’s the risk of doing it?
Analyse the change from all angles so you have a thorough view of what is going to be different on your project if you decide to go ahead.

4. Change decision
Are you going to do it? Sometimes as the project manager you can take this decision if it is within your area of control. But often you’ll have to take a recommendation to the change control board or project sponsor so that they can assess it too and make the final call.
Typically you’ll decide Yes, No or Not Right Now. This last one, Not Right Now, is good for changes that are sensible and will improve the product but that have come at the wrong time for the project and you don’t have the budget/capacity/time/something else to do it properly now. Record the decision and the reasons in your change log.

5. Change implementation
Of course, you only do this step if you are agreed that the change is going to go ahead. Update all the project artefacts and ensure everyone knows what they have to do. Then get on with it.
If you aren’t going to implement the change, then make sure that the originator understands that and the reasons why their change was rejected.
Personally I used to call this change management, but it seems to me that there’s been a bit of a shift in thinking and ‘change management’ is now in wide use as a term to mean organisational change preparedness or readiness. Change management is a discipline that helps the business prepare for and maximise the changes that projects deliver. Change within a project is easier differentiated as change control, so I’ve stuck to that term in this article.
Whatever you call it, you should do it! Does your process include all these steps? Is there anything that I’ve missed out? Let us know in the comments below.