Managing projects is like walking on a tightrope. You feel you could be falling down any minute. And once you’re back in balance something unexpected happens.
One of these unexpected things are scope changes. The green button that should be blue. The door that should open to the right instead of the left. You know what I’m talking about.
Now, you can’t do anything to avoid changes from happening. But you can improve your approach of dealing with them. And the step-by-step process I’m giving you here might actually be really useful for you.
What are scope changes?
Whenever there’s a change to the originally defined project scope, this is called a scope change. We are talking about deviations from what has been agreed with the customer in terms of functionality, layout, quality, responsibilities and other aspects. PM smart asses wearing suits also call it scope creep.
Why you need a process for dealing with changes
If you don’t have a system in place for evaluating scope changes, you will suffer in multiple ways. For once, you will be spending an insane amount of time on each change that pops into your mailbox. Why? Without a process you can’t delegate work to somebody else. Second, the whole situation will get messy and you will lose overview of change requests (and the customer will get angry).
That’s why you need a solid change process, and here I’m giving you my process.
What a change request process looks like
What you need is the following:
- an approval process (that your customer understands) for new changes
- a change request form
- a change tracking sheet
(You will find templates below)
My step by step scope change process
Here’s how I handle changes in my projects:
STEP 1: RECORD THE CHANGE
First thing: record new changes into your change tracking list the minute they come in. It doesn’t matter if the change is going to be approved or not. Just make sure it’s recorded so you don’t forget about it.
STEP 2: LISTEN TO THE CUSTOMER
Now listen to what the customer says why they need the change. How did they find out about it? How does it help them in their work? What’s the ultimate goal of having the change implemented?
STEP 3: Document the change in a change request form
This is typically the customer’s responsibility. Use a form such as the change request template that you can download here.
STEP 4: EVALUATE THE REQUIREMENT
The right next step is to evaluate the new requirement with respect to different factors.
What does customer actually need?
Trying to understand what the customer actually needs should be your first step.
If it sounds confusing, let me tell you this: Sometimes, there is a big difference between what a customer wants and what he actually needs.
People always want to stick with familiar processes. They don’t want to question why a process is done in a particular way. This can become a problem in scope definition when they are not aware of the big picture. Instead of tackling the core of the problem, they just care about fighting the symptoms.
Here is an example:
Take a scenario with two departments: A sales department which enters the customer orders, and a logistics department which packs the goods to be shipped to the customer.
The sales department is unhappy with the work of the logistics team, as they often forget to add the necessary information to the shipment. That’s why it has become practice that sales is double-checking the shipments and makes final adjustments.
Is that the right way of doing things? No. To proper solution would be to train the logistics team to do a better job.
Is the requirement relevant at all?
This one is very common in IT projects.
When replacing an old system with a new system, the new system is usually a lot more powerful than its predecessor. The problem: The customer does not have enough overview of all the new functionality, and so requires stuff that in fact is not needed.
Many of the tasks that had to be carried out manually before are now automated. Many of the issues that users struggled have been solved, due to smarter systems and more automation.
Therefore, the change the customer is requesting may just no longer be required.
Example 1: The customer tells you he needs to be able to edit his address on the invoice form. On the new system the address may be just printed automatically, making this additional step obsolete.
Example 2: The customer asks you to develop a “data check report” so he can find errors in the customer orders. In a new IT system there may be no need for such a report, because the system automatically corrects any errors or automatically notifies the user in case his intervention is required.
Is the requirement really missing?
You might be surprised to hear this: It happened to me that a requirement that appeared to have been forgotten was in fact delivered. The reason: we had been sloppy with the description.
Example: The customer requested a “printout function for purchase orders“. Your IT people had a technical perspective on it and called it “enhance printing interface for purchasing“. It’s the same thing, but with two different names.
Conclusion: Be very precise in your communication and ensure consistent naming.
Is the change in line with policy?
Once you have checked that it is a valid requirement, there may still be a reason why one would not just go ahead and implement the new requirement.
Sometimes requests fall into a grey zone area and others are simply not allowed. Either because there is a company policy disapproving certain practices or because it’s not allowed by accounting or legal standards.
In one of my projects, a group of employees was asking for the possibility to change purchasing prices. This is a very sensitive topic and if you grant this right to too many people, you open the doors to fraud.
If there is any kind of financial risk or potential loss of knowledge involved, make sure you check with the respective department. This could be legal, accounting, HR or another department depending on the area.
How urgent is the change?
These two questions must be answered in combination.
I recommend you discuss both points with the customer. To give the meeting proper weight, I usually also invite the manager of the person who raised the request.
During the meeting, I let the client explain why they need the change. In the beginning I might even respond with: We currently have no resources, but we’ll see how we can fit it in. When do you need it latest? Can it wait after [SOME IMPORTANT MILESTONE]?
Naturally, the customer will respond: We need it as soon as possible! We can’t do our job without it!
This is not always true. But it’s the kind of bargaining that you should do in such situations. It’s OK to challenge your customer a bit, but of course always stay rational and fair.
You might find the following scripts helpful that I’ve used to qualify changes:
- If this thing was so important, why was it forgotten in the first place?
- How often do you use/perform this process? (which requires the change)
- How would it affect your business if the [CHANGE] was not implemented?
- Is the change supported by your management?
After some discussion the customer might even drop his requirement (because it’s actually not needed) or you can agree on a later implementation date.
Whatever the outcome will be, in the end the customer will have to accept the extra budget for the change.
STEP 5: What is the cost for implementation?
In this step you make an estimate for the cost it takes to implement the change.
Don’t forget to track that number in your change log.
STEP 6: Get the change approved
Now the change needs to be improved by management. Send the completed change request form to the managers who have been appointed as approvers.
STEP 7: Implement the change
Obviously, the last step is to implement the change.
Here’s what I would like to know from you
What do YOU struggle with when it comes to requirement changes?
I’d love to hear from you in the comments!
–Adrian
