When the customer calls to inform you about a needed addition to the scope, there is no point in getting nervous. Follow the process I’m giving you below.
This is probably the situation project managers fear the most: It’s when the customer asks for changes when you’re already going in full speed.
You have worked your butt off to keep the project in safe waters and all seems to go well. And then you get the call from the customer saying they would need some changes.
“Why do they have to make my life miserable? We have no budget for this!” is what many project managers are thinking.
Keep calm and take a deep breath. There is a solution for every problem! Here I’m giving you the process I am using to deal with unplanned customer requirements.
Why you should never say YES right away
Let me start with some psychology first. The way you come across and how you act when the customer contacts you to discuss a new requirement is crucial.
You don’t want to be seen as the nice guy/girl who unconditionally accepts changes on the spot. This would undermine your power in the long run and damage your reputation. Rather, you want to be the tough project leader who is not easy to convince.
Apart from this more tactical reason why you should not run and deliver the new requirement, there is another more experience based reason.
From my experience I can tell you there are a dozen reasons why a change may not really be required. Misunderstandings or a lack of overview on the customer side are just two of them.
Instead of rushing ahead, pause and tell the customer politely that you are going to take a look at it and get back to him at the earliest time possible.
A step-by-step process for evaluating new requirements
It took me some time to develop and internalize this process. But it definitely made my life easier and I hope yours too.
Whenever a customer calls you to request changes, follow the processes.
Check 1: What does the 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 don’t see the big picture. Instead of tackling the core of the problem, they just know how to deal with 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.
Check 2: Is the requirement obsolete (or implicitly fulfilled)?
This one is very common in IT projects.
When replacing old systems 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.
Check 3: 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.
Check 4: Is there a conflict with company policies or legal rules?
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 employees ask for things which are in the grey zone or which 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 for 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.
Check 5: How urgent is it and does a suitable workaround exist?
These two questions must be answered in combination.
I recommend you schedule a meeting to clarify 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 folks explain again why they need the change. Then I tell them: We currently have no resources, but we’ll se 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!
More often than not, this is just not true. But it’s the typical bargaining that you are going to face in such situations. Don’t make it easy for the customer to get his “thing”. Challenge him!
If you need help with that, here are some scripts I use:
- 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)
- Tell me, how would it affect your business if the [CHANGE] was not implemented?
- I hope you have a good explanation when this point is addressed with the management!
Your goal should be either to make the customer review his requirement (maybe he realizes it is not needed) or to move the implementation date further out.
How you handle the situation and to what degree you apply guilt and pressure depends of course on the circumstances.
If you are dealing with an external customer it’s a totally different story. You would act much more customer-oriented, and there would be no problem adding the requirement to the scope as long as the customer agrees to pay for it (very important!).
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!