Have you experienced a specification change request suddenly?
If you’ve been a project manager for a few years, you might have experienced sudden specification change requests from your customers. If so you may know that sudden specification changes may require tough negotiations with customers as well as your development team. And that may cause problems and could be a reason for the development project’s failure.
When there is a sudden request for a specification change, it is necessary to estimate the impact on the development schedule and cost, and decide whether to support it. Since your product value would be changed, it could be an important change point in the success or failure of a development project.
In the case of a custom product dedicated to a specific customer, it might be OK if the customer accepts the development schedule delay and pay more for additional resources needed for the specification change. As far as I know, specification requests happen more frequently for custom products rather than standard products.
Specification change is good or bad?
Firstly I want to clarify that the activity of changing the target specification is not a problem. Rather, I would say that discussion of product specifications with important customers is a mandatory process for increasing the value of products. Therefore it is quite normal to change specifications frequently before product development or in the early stages of development.
Usually, product specifications are changed significantly in the early stages of development, and as development progresses, the change becomes smaller. Then, finally, the specification is frozen by the deadline. So what we have to avoid is an unplanned specification change that comes suddenly.
How does the specification change happen suddenly?
This is because you don’t want to change the specifications.
The first step is a customer asks you to change a specification, for example adding some new functions, then you answer in a negative way because you don’t want to change the specifications. If you are the only supplier who can support customer demand, specification change won’t happen. However, there are competitors who may answer in a positive way to support specification change.
Then the second step is that the customer discusses with your competitor about new functions. So you are not involved in the discussion.
As a result of the discussion, there are cases where specification changes do not happen. Even so, you may have a disadvantage in product development in the future. Because you haven’t anticipated the discussion of a potential new function, you don’t know why the specification change was postponed. On the other hand, your competitor knows the judgment criteria and mandatory conditions of specification change. So the competitor may be able to predict the specifications change timing in the future.
And the third step is when the customer makes a decision of adding a new function and you suddenly hear about a specification change notification. At this stage, it is not a request but a notification so there is no room for negotiation or adjustment.
In summary, the process of how specification requests happen suddenly is that you don’t want to support the request so the customer doesn’t invite you for the discussion, and then you will be notified by the customer after everything is decided. This is the case you can choose if you don’t support new functions.
And the other possible case is that you are not requested about specification request so there is no chance to get involved. This is because your product is out of the scope of your customer selection because of a lack of competitiveness in terms of price, quality or performance, etc.
What is the solution?
Propose timely specification discussion with key customers
As I wrote, specification discussion itself is not a problem but the timing is the problem. If you feel you don’t want to change the specification, the reason could be the misalignment of your development schedule. In other words, it’s too late to change the specification. In the product planning stage or early development stage, you should proactively contact key customers to make a discussion to make sure which kind of product will be needed. If the key customers understand your product development schedule, they will cooperate to provide feedback as much as possible before the deadline.
Be positive to discuss specifications anytime
Even if you try to collect key customer feedback within the desired timeline, there is a case when a customer requests an additional function in the middle of development. Even if it’s difficult to support that, I would suggest you sit at a table to discuss specifications and try to understand the customer requirement in detail and how it is important to the customer. If you are involved in the discussion that is helpful information for your future product development. And it is still beneficial even in the case you don’t support the customer’s request.
Explain the background in detail
Once you decided to support sudden customer requests you may expect a strong pushback from the development team. It’s another tough part to negotiate with an internal organization. Your development team often has frustration because of a poor explanation about the background. If you explain the full story of why you have to support the customer’s request, they may understand.
An explanation would be like this.
- If the customer’s request is not supported, the value of the product will be significantly reduced.
- On the other hand, when you support the customer’s request the impact of the change can be controlled.
- Despite having thoroughly discussed the specifications with the customer before development started, this specification request came.
However, although it is necessary to explain these backgrounds, you need to listen first to the anxieties and dissatisfactions that the development team has. If you explain it before you hear their opinion, they won’t hear you.
This might be the most important process of the explanation.
Please check the related posts about listening.