I often come across project managers who ask me what the correct way is to say no to scope changes. They have been taught that changes to scope are dangerous as they worry it might morph into scope creep. When we talk about scope creep it implies that changes are uncontrolled and that scope grows and grows without anyone explicitly agreeing to it. That’s obviously an undesirable situation, which should be avoided because the project team ends up having to deliver more work within the same cost and time constraints.
But scope creep has other disadvantages too. When a requirement changes and we blindly implement it without assessing the impact, we easily overlook dependencies and knock-on effects that can end up costing us dearly further down the line. We may also forget to document the changes and to train the users in that new feature which was added.
Not all changes are bad
As we have seen there are good reasons why scope creep should be avoided and why it’s a cause of concern for project managers. But let’s get clear on one thing. Changes to scope are not synonymous with scope creep. Changing the project in one way or another as it progresses through the lifecycle can be a good thing and is often necessary.
Imagine for instance that a competitor launches a new product, which will make your planned product look markedly inferior, and that it could be rectified with just a simple adjustment on your side. Or imagine that new technological advances happen in the marketplace that could significantly improve your output and strengthen the business case if integrated into your project. In these circumstances you could invalidate the project if the changes aren’t undertaken.
Project managers therefore don’t need to learn to say no to changes, they simply need to control them and learn how to appropriately manage them. Feeling that they have to be the gatekeeper and rigorously say no isn’t only stressful, it is also misunderstood. When project managers possess a deep knowledge of the subject matter and the business context within which they operate they are much better placed to assess in which cases a change is appropriate and absolutely necessary.
Let’s examine the three essential steps that project managers can take to manage scope and prevent it from creeping out of control.
The first step in controlling scope is to agree, to a reasonable level of detail, what is in and what is out of scope.
As obvious as it sounds it surprises me how many project managers think that scope has been clearly defined on their project, when it really hasn’t.
At a high level yes, we know that we are building a house with four bedrooms and we have an agreed floor plan. But we haven’t agreed the details of the kitchen and bathroom. Furthermore we assume that the path to the house is out of scope whereas the client is of the understanding that it’s in scope.
The truth is that on many projects the scope statement is far too high level to be of any use and no attention has been given to what is out of scope.
Having a detailed and signed off scope statement (for instance in the form of a requirements traceability matrix) will not prevent the requirements from changing later on, but it does minimize changes because the client’s needs have been discussed to a great level of depth early on.
Asking as many detailed questions as possible about the client’s circumstances and helping them envision how they will use the end product or solution after delivery will help to get the specification as correct as possible.
I’m a great advocate of requirements definition workshops and physically drawing or mapping out the solution for the client on whiteboards and with process maps.
The better the client is at visualizing how the end product will work for them, the greater the chances that the project is correctly scoped from the outset.
The second step in managing changes is to be prepared that they might happen.
You can do that by adding contingency the plan so that if something changes you have buffer in the schedule. The amount of buffer you add to the plan should be in direct proportion to the level of risk or uncertainty in your project. The more vague the requirements, the more contingency you will need.
On the other hand, if you have previously worked with the same client and worked on a roughly similar project, it’s likely that you will need less contingency.
But changes to scope don’t just affect the schedule of a project, they also affect budget, which is why contingency should be added to the budget too.
The way to do this is to quantify the level of risk on your project and to add that number to the budget. Say that there is a risk that you can’t source the right materials for your new groundbreaking glass roof of the house you are constructing and that you would need to change the design if the risk materialized. There is a 10% likelihood that this risk will happen, and in case it does, the impact will be a cost of £20,000. The cost of this risk is therefore 10% of £20,000, which is £2,000 that should be added to the budget as contingency.
In addition to calculating the cost of each risk, you can also agree with the client that you set aside a dedicated change budget – this is simply a bucket of money that can only be drawn down if a change is agreed and signed off by the board. This extra budget must not be used for general overruns, but only for items that are added to the scope of the project.
Now that you have done as much up front as possible to prevent and prepare for changes, the last step is to mange them when they happen.
I know that it can be tempting to simply say no to a client who would like a change to scope because you are trying to deliver the project on time and within budget, but as we discussed earlier on, that may simply not be an appropriate answer.
In fact, the most appropriate answer may often be to not given an answer at all. Let me explain.
If the change will affect any of the key success criteria of the project, you will not be best placed to make that judgment call. What this means is that if the suggested change impacts the agreed deadline, the allotted budget or the approved benefits, then the change needs to be escalated to the project’s steering committee or change control board for approval because something very fundamental to the project is about the change.
If the change on the other hand is minor and won’t affect any of the project’s success criteria, it may be within your tolerance to either approve or reject it.
The best way to deal with an imminent request for change – whether you can authorize it or you have to escalate it – is to assess the impact of the change. How will it affect the project’s outcomes, benefits, timescales, cost and business case? When escalating a change to the steering committee, simply present your impact analysis with a number of options.
Option 1: do nothing. Option 2: implement the proposed change. Option 3: implement a compromised solution. Your job is to present the options and their impact and to then leave the final decision to the steering committee.
If the change is signed off, ensure that you document it (e.g. in a change log) and that you get further funding allocated to do the work. The whole point of controlling change is to understand and compensate for the impact of it. No one should be expected to deliver more, but to still be kept accountable to the original time and cost estimates.
Many project managers are too concerned with how to say no to changes, when instead their focus should be to appropriately manage and control them.
First they have to baseline the scope by being crystal clear and reasonably detailed about what is in and what is out of scope.
Secondly they have to anticipate change by adding sufficient buffer and contingency to the budget and schedule.
Thirdly they have to assess the impact of the change, and escalate it to the steering committee or change control board if it’s beyond their level of tolerance to made a decision on.
Find out more about the courses that can help you with scope creep.