“Just say No.” How many times have we heard that advice? In some situations, it may be the best or even the only course of action. But for customers eagerly pushing for extra features or accelerated delivery schedules for a project, being that blunt could cause problems. On the other hand, appearing indecisive or setting up false hopes may not be a good idea either.

To start with, when do you need to say “No”? In project management, a “No” is often the result of the ‘Iron Triangle’ of features – schedule – resources. If your customer wants a change in one of these factors, then at least one other element must also change. If your customer can’t or won’t accept such related change, then the answer to the extra feature request can only be ‘No’.

Communicating that ‘No’ may be done best by a short, friendly reminder about the current project goals, timeline and investment. Done the right way, a ‘No’ in this case also has two advantages. It shows your customer that you’re on the ball. It also demonstrates that you’re looking out for the customer’s interests, ensuring that the project will be completed on time and on budget.

Are there exceptions? Feature requests and schedule changes might be handled as part of an agile process, with appropriate re-planning or re-prioritization between cycles. But even with agile, sometimes it just has to be ‘No’. In that case, take the opportunity to demonstrate your professionalism and any short-term disappointment is likely to be outweighed by longer term customer satisfaction.

1 reply
  1. longmind
    longmind says:

    Answering “No” is the way to avoid creating false beliefs in customer. If you go on answering “Yes”, you are probably putting off the inevitable pain to the customer when you do not deliver. And this increase frustrations and false beliefs in the customer about the service going to be provided.

Comments are closed.