Quite often project managers have to deal with difficult situations on their projects. A good example of such a tough situation is when the client comes up with an unrealistic request. In this situation, the project manager faces a dilemma: on the one hand, he doesn’t want to upset the client, but on the other hand, he understands that it is impossible to achieve what the client requests. Consequently, if the team commits to the client’s unreasonable request, they will fail and the client will be disappointed anyway.
Before we dive into what project managers can do in such situations, let`s first try to figure out what kind of requests are considered to be unrealistic or unreasonable.
It`s well known that projects have different constraints. The most common ones are time, cost, and scope. If we take these particular constraints into account, we can give a few examples of client`s unrealistic requests. The most common one is to do a big amount of work in a small amount of time. This type of unrealistic request can take another form – when the client asks to accommodate a new scope (new feature) into the Sprint or Release on the fly when there is not much time remaining till the end of the Sprint. An example of an unrealistic request related to cost would be when the client asks to implement a feature that costs a lot for a little money. I believe these examples can give you a good clue on what unrealistic requests may be like, so, let’s see how we can push back on them without any negative consequences.
How to Push Back on Unrealistic Requests
Be polite and understanding
When you get an unrealistic request from the client it is very easy to get mad about it. Even if you think that the client is not right, you shouldn`t blame him. If you show your outrage to him, it can make matters only worse.
You must realize that the client is unlikely to want to put you in a tough position. He may either not understand that his request is difficult to fulfill, or maybe some circumstances forced him to make this request. There should be a reason behind this request and instead of worsening the situation with an erupting conflict between you and the client, try to focus on how you can collaborate with him to get out of this situation.
Drive the conversation with the client politely. Avoid generic phrases such as: “I’m too busy!” or “No one understands how busy I am”, or even the sighs and huffs. These don’t look good on your part and aren’t helpful. Use assertive responses instead, which are always precise statements based on seeking a win-win solution. Also, try to use “we” rather than “you” when speaking to the clients about their requests. This will demonstrate that you`re in this together and you care about the situation as your client does.
Clarify the reason behind the request
Before you start negotiating with the client it is very helpful to figure out why he asks to do this or that. If this request is just a creative idea about improving the product that came to the client’s mind last night, you can be quite assertive in pushing back. However, if the request is grounded in a serious issue that may impact the business, then you better step back.
Justify your position
The first two tips were about gathering information from the client and setting up proper communication. Now let`s turn to the action. It may sound obvious, but it is very important not just decline the client’s request but explain why you can`t do what he wants. If you dryly say a simple “We can`t do this” or even worse you start complaining about the request, it may drive the client mad – it is he who pays the money at the end of the day. So, it is always better to declare your understanding of the situation and the reason behind the request and only after that proceed with the exact list of points why it is either not doable or not recommended to do.
Use the “Assertive No” approach, instead of the “Aggressive No”. The aggressive “No” gives the other person the impression that his request is insignificant. The assertive “No” instead is where we acknowledge his request and thank them for it, but at the same time we are very clear about why we`re saying “No”.
Another good approach, not easy to master though, is the “Indirect No’. This is a polite refusal without actually using the word ‘No’, followed by a brief explanation as to why the request isn’t possible immediately, or a brief rationale as to the complexity of the request, which will give others the understanding of what your stance is really about. It will also command respect in terms of your time and ability to juggle your demanding workload.
It is a commonly known fact that people perceive new information differently. Some are better at perceiving visual information, others better grasp information phonetically or by touching physical objects. It means that when you explain the constraints of getting the unrealistic request done, it makes sense to use different types of information. It is always helpful to reinforce your position with some visual data – like numbers, tables, graphs, etc. For example, if your client asks you to accommodate a new feature into ongoing Sprint, you may prepare a table showing the current team capacity and the number of tasks already taken into the Sprint. Numbers are always much more persuasive than mere talk.
The next logical step in persuading the client to give up the unreasonable request is to show the consequences which will follow if he decides to insist. This by far is the most important step in the art of pushing back. If you`re able to demonstrate to the client that his decision of doing something his way will have negative consequences for the project and his business, it will definitely make him think twice about the necessity of this request. A good tip here is to try to convert the consequences into money equivalent. Most businessmen understand the language of money better than everything else. But if this is not the case, you may show the impact on the other constraints of the project – time or scope. If we return to the previous example with adding a new feature into Sprint, you would show that if you`re taking a new feature, you should give up other features taken into Sprint initially, which will lead to the delay in implementing those features.
Even if you are compelling enough about the reason why the client`s request can not be implemented, the client will probably feel upset because his initial issue or problem won`t be solved. And that`s your moment to consolidate the gains. It would be really great if you can suggest an alternative solution to the initial client`s problem. If this works out, you will turn an unsatisfied client into a happy one, and not only do you resolve the situation to your benefit, but you`ll also increase the trust and improve your relationships.
For example, in the case of the additional scope mentioned above, maybe you can find a workaround, that is a temporary solution you can implement quickly without impact on the initial scope and schedule. You do this instantly and implement the fully-fledged solution later in the next iteration.
If you know that the client would be resistant to your arguments about his request being unrealistic, you may not limit yourself with the direct tactics explained above, but also try to use a more cunning approach. If you`re rubbing elbows with somebody who can influence your client, first reach out to this person, persuade him or her of your ideas, and probably even ask to support you in discussion with your opponent. However, even if you don`t have such a trump card, it still makes sense to gain the support of as many project stakeholders as possible before discussing the client`s request. Negotiating something in a group is always easier than one-on-one.
Hopefully, these pieces of advice will help you to cope with unrealistic client`s requests more effectively. If you have any other pushing back on unrealistic requests techniques, please, share them in the comments.