How to say “no” to a customer when the customer only wants to hear “yes”?

The word “customer-centricity” is in fashion now, replacing the “customer-oriented” that I, a boomer, was used to. And for me it looks like this: if earlier it was important to make your product or service, focusing on the client, now you just have to go and do as you were ordered. And it doesn't matter what you think, you have to be client-centric. This is very relevant for government projects, those who have worked there know. That's probably why the word “customer-centricity” has become so popular there.

However, there is one small nuance: The Project Manager must respect the project boundaries, he is not a magician. He does not have an endless budget and deadlines, which means that sometimes he will have to argue and defend the boundaries. And that means saying “NO”. How to do this so as not to destroy relationships on the project, in the team, on the account, but, on the contrary, strengthen them? This is what I propose to talk about.

Disclaimer: This is a long and complicated text, as the points in it require detailed pronunciation. In short, this article is about:

1. Soft skills that are not taught in any Project Management school, but which you will need immediately in your job.

2. Psychological attitudes that may hinder you in your work and communication with your clients, and what you can do about all this to become more successful. Successful = earning more, completing more and more difficult projects.

Introduction: If everyone wants to hear “YES” from you, but you don't want to say it?

In my work, I have come to accounts or projects that needed to be saved many times. Once I was hired for a project where 4 RPs had changed in 4 months before me, the lead architect was preparing to resign because he did not sign up for what was sold, and the customer understood that things were wrong and was already thinking about changing the contractor. I could have refused this hopelessness, but I signed up. I became interested in how to do something that is impossible to do? And, a year later, I had a successful project, completed with a deviation from the budget of 0.5% (I'm not kidding, I checked), a satisfied customer and continued work for many years for my company. And we even became friends with that architect.

And this is not an isolated case, in my experience there are about a dozen such stories. How I manage to “get through” hopeless situations and projects – this is what I want to share.

At the beginning, almost any project looks something like this: you quietly and peacefully agree with everyone on the technical specifications, work plans, budget, charter and everything else. Pleasant expectations and light euphoria reign: “Hurray, we've agreed on everything and now we'll start!”

And then your project starts to resemble a cart rushing down a hill, into which they try to throw more and more requirements, reduce the deadlines, and take away half the wheels from the cart (you are a great RP, you can handle it anyway, but on another project everything is burning, there it is more needed). And if the cart does not fly to the finish line or flies, but not as agreed, you will be to blame. Yes, yes, you, dear RP.

If you want to bring your project to a successful conclusion, sooner or later you will have a strong desire to say:

• no, I won't do it twice as fast;

• no, I won't do it if half of my team is taken away;

• no, I will not automate this process and “at the same time” 2 more;

• no, I can't do it for less than the estimate;

and many other “no's”. However, there is a problem. Your customers do not want to hear “no”, it makes them sad. Your manager does not want to hear “no, I can't” either. He wants you to try to do it.

What to do? How to maintain a balance between customer centricity and the desire to send everyone far and for a long time?

The answer is simple: you need to become more flexible and not forget about your boundaries. It's easy to say, but difficult to do. But that's no reason not to understand the mechanisms and what can be done.

How to say “NO”?

I'll start with the base. To say “NO” you don't have to say “no”.

There is a joke (this is part of it, the rest is also funny, but not about that):
If a diplomat says “Yes” it's “Maybe”
If a diplomat says “Maybe” it's “No”
If a diplomat says “No” – he is not a diplomat.

A project manager must be a diplomat. I have experienced this many times. My “no”, completely justified, was very rarely accepted by my managers, my customers. Even if I was 100% right in saying “No”, I was considered negative, inflexible and unconstructive. This made me angry, I did not want to change and this was my glass ceiling for quite a long time. And then I changed my approach, and it worked.

Flexibility does not mean subordinating yourself to your customer (business, account, your boss). It means that you try to find solutions. As in the vulgar but 100% true American phrase “don't tell me why you won't do it. Tell me what you need it done?” This flexibility should have its limits, so that you are not taken advantage of, I will also talk about this below.

I highlight the following reasons why RPs cannot respond to changes flexibly, which leads to a situation where instead of solving the client’s problem, The RP closes down and starts to react unconstructively. Unconstructively is when the RP, without thinking, without offering options and solutions, simply refuses to talk about changes to his project.

Here are the reasons:

1. Negative thinking.

2. The unwillingness to delve into the client’s problem is just plain laziness.

3. Inability to see the space of possibilities for solving p2 above.

4. Inability to take a break, discuss and think.

5. Inability to be proactive.

1. Negative thinking RP

The main problem. Negative – is when I perceive any change as something terrible, unbearable, unsolvable and say “no” without even thinking about how it can be solved. For me, the glass is half empty.

Refusal does not require any energy, you don’t want to make any unnecessary movements, and there is a great temptation to simply answer: “this is not in the technical specifications, and I will not do it, contact your manager.”
Unfortunately, this does not work well, the customer perceives it as a negative and unconstructive position. I have tested this on myself many times and have seen many times how poorly it works for my managers. For a PM with a negative approach, work turns into a daily battle. I have repeatedly seen PMs and even CIOs who perceive business as the main enemy that wishes harm to IT specialists and brings problems. However, this approach is unconstructive. In it, purely psychologically, you want to defend yourself, and not understand the other person. You want to fight back with regulations instead of understanding what can be done. And this – let it go to hell.

Morality: to fight with business or to be friends – it’s up to you. I prefer to negotiate, setting boundaries.

2. Unwillingness to delve into the client’s problem – Laziness.

This is the second most important reason. I often see that the PM perceives the customer as an enemy who came specifically to harm the PM. For some reason, it is difficult to understand that the changes were not just like that. Your customer has a problem, and in order to understand it, you need to make an effort: understand his processes, priorities and pain points. In a word, spend energy and conduct a small business analysis. The problem is that many PMs are too lazy to do this, citing that this is not their job. “Let the customer think about it himself and tell me.” “I am a manager, not an analyst” and the like.

I tell such managers right away: the time of administrators in IT projects has passed, before it even began. Since 2005, I understand the “insides” at the analyst level in all projects and I demand the same from my managers. Otherwise, you simply won't be able to communicate with the customer and his employees. You will look unprofessional, helpless and ridiculous. I had a customer who, after meeting with such a RP, called me and asked to send someone with whom you can actually talk, and not just sign papers. And I agreed with him.

Morality: if you want the customer to trust you and meet you halfway, help him. Know his business even better than he does. Yes, this is optional. But he will come back to you many times over.

3. Inability to see the space of possibilities.

This is about flexibility. Not in the sense that it is the ability to bend over backwards and do good for others at your own expense. But about the ability to assess the problem (see point 2 above) and, based on this, estimate the tree of possibilities (see my article https://habr.com/ru/articles/836588/ there is about the same thing). And then offer the customer possible solutions that suit both him and you.

Note: you are not doing what you were told, but you listened, understood what was being said and, as an expert, offer compromise options. What does your customer see? You are limited by the framework of your project, but you are sincerely trying to help and are looking for solutions. You will be treated completely differently. And also on this point.
If it seems to you that there are no options for solving the problem, it seems to youThere are always many options, you just haven't thought enough or you're just scared. It's normal, everyone is scared. But professionals know how to work even when they're scared.

Morality: you should see not only your “NO, go to hell”, but the space of possibilities. If you don't see it, do p2 higher and p4 lower.

4. Inability to take a break and think.

This is a classic negotiation: an angry customer (or manager) calls you and demands that you do something immediately. Something that will affect your project. And demands that you immediately name a deadline for when you will do it. Or you conduct a demonstration of the functionality, the customer says that everything is great, but here you need to make a tinny improvement. Tiny. By Friday.

As soon as you agree, give in – and you are caught. You become the scapegoat, because the work is not so small, there are no resources and in general, your financiers demand money tomorrow, according to your own work plan. Sound familiar? And all you had to do was say the golden mantra of the RP: “Colleagues, I understood the remark, I need a little time to evaluate it, by the end of the day I will tell you what can be done about it”. Yes, you may be pressured, scolded, but you always have the right to take a break for evaluation. Even a few hours will help you

• breathe out and calm down.

• talk and consult (with colleagues, your boss, or someone else) so as not to make decisions in the heat of the moment.

It's like in boxing: if you go into an open exchange, there's a high risk of making a mistake and missing a punch (in our case, an unpredictably large follow-up). It's better not to rush and make a thoughtful decision for which you can really answer.

Morality: Never name a deadline right away. Don't be shy about taking a break. There's no shame in that. What's shameful is making a promise and then failing. A good RP who thinks before he speaks is a good RP.

5. Inability to be proactive.

Reactivity is when I get hit and I respond. I react. Proactivity is when I understand that it's evening now, I don't want to walk through a dark and scary area, and I call a taxi. This is when I act preemptively. A reactive manager never looks ahead. He has a lot to do now, don't distract him. As a result, he sees nothing further than his nose, which he regularly gets punched in the face for not seeing anything. The ability to get out of the operational environment and the ability to see project problems in advance is the responsibility of a good PM. Seeing your customers' problems that can affect your project is also a must. There are risk matrices, status meetings and many other tools for this, which not everyone knows how to use. “Why should I make a risk table, it's no use”, “why should I conduct status meetings with the customer – it's just a waste of time”. Guys, if you use these tools incorrectly, of course, there is no need. A good status, for example, can take 15 minutes: the RP came out, told the main risk that needs to be addressed, justified it, suggested solutions. The customers and sponsors agreed – that's it, thanks to everyone. If you don't do this, you are a reactive manager, and you will get hit on the head for it regularly until you learn to be proactive.

So, I will list again what will help you, on the one hand, to become an assistant for your customer, and on the other hand, not to do anything that is required of you under the pretext of customer centricity, urgency and other important things:

1. Understand why your customer needs the change? What is the priority, how much work is involved, and is it worth spending time on at all (or is it all decided by the project margin)? The golden question is: “Who will die if we don't do this?”

2. Take a break, don't make decisions right away. If you can't make a decision or you're too scared to make one, talk to someone. A boss, a colleague. Even a psychologist will do.

3. Understand what the solution space of your problem is. There are usually several solutions. The solutions can be written down on a piece of paper. These solutions can also be discussed with someone to understand the pros and cons of each.

4. Proactively offer solutions to the customer yourself, do not wait for the customer to make a decision for you. This is also a classic: “if you can't stop the process, lead it.”

My experience shows that if you do the above regularly, you will no longer need to say a direct “no”, and your clients will begin to value you as a RP who respects the boundaries of his project and, at the same time, is always ready to help. Since there are few such people on the market, the client will almost certainly want to continue working with you. This is the secret of all the projects and accounts I have saved, where I ended up with excellent relationships.

Of course, this does not mean that you should spend all your working time doing the work for the client. Any help has its limits. I will have to write a separate article about this, as this one is already too long.

Conclusion

I like to count from extremes. In the case of the work of a Project Manager, there are two extremes: “agree to everything and try to be good for everyone” and “oppose everything in general, and those who are against it – let them go read the technical specifications” (RACI matrix, project charter, and whatever else).

Both are extreme strategies. The first will result in you burning out valiantly trying to please everyone, and then you will be fired because you will not be able to please everyone anyway. The second will result in you being called inflexible, negative, and unable to meet the customer halfway, and you will also be fired.

For me, the truth lies in the middle, in the balance. You should never forget about the boundaries of your project. But you shouldn't think that these boundaries are immutable, rather, they are your negotiating base from which you should start discussions. The boundaries can be re-negotiated, and the scope can be changed, and if after that all your stakeholders and customers are happy, you did everything right, and you will be the one to do the next project, and not the guy who was scared of changes at the beginning and sent everyone to hell, justifying it by the fact that it was not in the TOR. People are not perfect: customers are not perfect, sponsors are not perfect, you yourself are not perfect, everyone makes mistakes. The assistant strategy is much more profitable than the “I only do what is in the TOR” strategy. In my experience, in 95 cases out of 100.

So my choice is not to say “no” but to say “let's see what we can do.”