Sometimes a client can be demanding as hell. Their requirements can go so far beyond the scope of a project that it isn’t funny anymore. Or they may see a really cool feature of your software assume that everything else around it is a piece of cake for you, and immediately enter “wishful thinking” mode. Or you might face a stakeholder on the client’s side who, for some reason, doesn’t want the project to succeed. Those people will constantly search for a needle in a haystack and will never find it, making your job horribly difficult.
I once had a client who wanted their whole legacy system replicated, and did not feel comfortable with anything else. Basically, business users wanted to keep the existing system, because they had gotten used to it, and their management wanted to go with the global platform. We constantly had a problem with not being able to replicate a completely custom system. I banged my head against a wall for a long time, not figuring out that replicating something outdated is a bad idea altogether.
In some cases, clients can have really tough negotiators on their side, and you will need to seek help. Sometimes you need to let your superiors handle the situation, especially if your task list is growing and you need to focus on the actual work.
I am sure that in the course of your career, you have come across some really nasty people on the other end of the phone/Skype/WebEx line. Sometimes the sales team promises that your code will launch the system on Mars, or will need no maintenance at all. Or you might have faced a situation that I have been in many times—where your company is developing a piece of vendor-type software and has the feature request needed on the roadmap. But for the fourth quarter. Next year.
If you are reading this article, it is likely that you have been or are about to be in situations where you need to calmly postpone any decision that is important enough to affect the whole project. And you will not just say the following to the client:
- “No, we can’t do it. You need to get rid of that requirement.”
- “No, that is a new feature. You need to wait for God knows how long.”
- “No, and I don’t care. Speak to my managers.”
The ultimate goal of every consultant in the computer software industry is to learn how to say “No” in a way that your client will accept it. And sometimes you will need help to make that happen. There’s no shame in needing to bring in someone with more experience to provide an assist.
Below is an example of a situation where you should consult with your manager.
Client: I think we need this in order to complete requirement #45.
You: Yeah, it would be great, but we don’t have that exact feature to support it.
Client: How do you plan on solving #45, then?
You: Well … We have a workaround for that; it will involve some scripting, but …
Client: No way! You need to have a feature for that. I don’t want to maintain dozens of scripts, just because you guys don’t have a standard feature!
You: I think we might do something about that by the end of the year …
Client: No! We need that in your next release, okay?
You: Okay.
Now you are committed. You promised something you don’t even know is on a roadmap. You didn’t consult with the product team or their manager; you didn’t even postpone it to check if that request is covered in the statement of work (SOW). Basically, you are now in a world of hurt.
To avoid this kind of scenario, let’s go through the four steps you should take when you need to bring in someone from management to talk with a client.
Recognize When It’s Time To Say Something
Too many developers (and not only developers) run into “problems” where they find themselves regularly talking with extroverted, outgoing people who can speak their mind very openly. After some time, developers may open up too, but it often does not work for them in the same way. They can fall into a trap whereby they over-promise something and then can’t escape it.
Missing a huge feature that is critical for a project milestone is where things start to get complicated. A perfect example is when a client asks, “Hey, remember that user interface (UI) thing, where you said we can build the responsive view for reports? I just spoke to our lead engineer, and it’s really critical, so we need to build it next.”
Now, you know the product team is building that, but you can’t be sure if it is going to be done on time. It might be if it is prioritized by the product team. Who can prioritize that? Well, the product manager.
If you are not a lead engineer or project/product manager, there is no way that you can promise something to a client so firmly that you will not need approval from your manager. It is a rare case that you can prioritize your product team’s backlog based on your client’s urgency. They are building software for other clients, too. If you keep postponing the decision to alert your superiors, an experienced client will think they can get away with pushing you and they may try to use it for leverage.
Don’t postpone the moment when you talk to your project or product manager: do it at the right time and you’ll avoid problems down the line.
Talk to your Superiors First
Instead of promising something that you can’t deliver (or that you are not sure you can deliver), there is something that you actually can promise and feel really good about.
And that is the Consulting 101 lesson: “I understand the problem. Here is what I can suggest: Let me talk to the product management team and I will get back to you with the answer.”
What you accomplished by saying this is:
- You bought yourself some time (I have never had a situation where the client said, “No, I need this right now!”).
- You showed that you understand their concerns and that you are willing to help by escalating the issue to upper management (even though you are not escalating anything, really, you will just sit and discuss the roadmap with the product team).
This way, you will prepare your management team so they are not surprised when they are copied in on an email about the issue.
Go to your manager, schedule a meeting with the development team, and discuss this client’s feature request. Maybe there is a workaround for it.
It is not up to you to decide which client will have an advantage in having their request on the roadmap earlier. Let that be the product team’s call. In the end, a product manager is the one whose job it is to prioritize the product backlog.
I remember one time when a client wanted to be able to give access to another user in the system when he was out of the office. That was something that I needed to check to see if it was on a roadmap. I talked to the team, and they told me, “Well, we are not developing that for the next two quarters, but you can try this thing that we added where the user gives that same permission to the support team. Ask them if it is okay until we develop an exact feature for administrative users.” And that option eventually was accepted by the client.
Talk to you management team before issues happen, not after.
Use the Appropriate Attitude
You should always try to be prepared with the right information. Don’t get in a position of trying to defend your opinion if you can’t back it up.
This is something I learned in college. I had a class called “Standards in Quality Management” and I remember a conversation between the professor and one of my fellow students that went like this:
Professor: Hey, do you have an ID?
Student: Yes, I do.
Professor: Wrong answer, buddy.
I remember the whole class staring at him, expecting the right answer. And sure enough, he explained: “‘Yes, I do’ is the right answer. But along with you reaching into your pocket and actually showing your ID to me.”
If you are careful with your documentation, you will easily be in a position where you can say to a client, “Hey, here is the SOW. We agreed not to do XYZ for this implementation phase (or at all). If you want that, we can write a CR (Change Request) and estimate it properly.”
The attitude here is important. You never want to sound like a jerk, even if you are a million times right. Try to sound friendly and like you are sincerely trying to help out (which you are) and looking for every possible solution.
There is no silver bullet for this where I could say to you something like, “You should say this and that in this situation.” You must be able to study your client’s behavior, attitude, what their goal is in the current project, etc. Based on that, you will gain knowledge of whether the client prefers to be treated as a child, with you constantly “holding their hand,” or if they like you to treat them like they conquered the whole world. Once you know that, it will be easier to maintain the attitude they prefer.
Don’t forget, business is often like a play in a theater—we need to put on the mask required by the drama we participate in.
You might say:
“Your requirement XYZ is really going to affect:
- Maintenance, because we need to implement additional scripts/custom actions;
- Performance, because that will affect the speed of the system by triggering additional logic; and
- Storage, because we need to double the fields, add a new UI layer to it, etc.
“I think adding this kind of logic will affect performance in a significant way. Plus, if you take a look at the SOW, we did not scope it.” (And then you go back to the CR story.)
Of course, this kind of statement will be more than sufficient in 65 to 70 percent of cases. In other 30 percent of cases you will have to use points from this article. And it can be settled on a regular weekly call with the client, or via email.
Remember, it is always good to consult with your product manager/product owner about these types of emails. It is crucial that statements are correct, and can be confirmed later on. Spend some time understanding them as well, because you might need them in the future with some other clients.
The main points to take away from the above example are: do not lie, and do not use these statements by default. Take them as a guideline, apply the principle to the specific case you are dealing with, and tailor them to be in line with what your manager has explained to you. This is important because later on, if necessary, your manager will be able to expand on facts that you have already set with the client.
Being polite, accurate, and appropriate in tone will go a long way to communicating a good attitude, which will help avoid some conflict situations with difficult clients.
Be Direct in Your Language
Sometimes in big enough corporations, key stakeholders don’t have time for weekly meetings and prefer email (looooong email chains). They also see that as a more convenient opportunity to be pushy, because it really is easier for almost anyone to sound tougher over email than over the phone.
At some point—and usually, this is the point where you reach the top of your “Mr. Nice Guy” zone and the top of your accountability—you need to reroute the client to your superiors or product/project managers.
There is no way that you will act appropriately if you are steamed, and maybe you’re in a situation where there is no time to cool off. If you have a team lead, maybe you can talk to them first, and discuss what would be the right path of action to take. Maybe there is a rule that you are not aware of, especially if you are new to the company.
If you were sitting with the client in the same building, it would be easy. If your superiors were present on regular calls, it would be easy. Instead, you need to accomplish good outcomes, but with emails.
Emails are good for many reasons, but there is one crucial advantage: You have a written trail of communication.
In my experience, the best way to put a referral to your superiors is something like this:
“Hi [Client],
I’m copying [Manager 1] and [Manager 2] on this email to add them into this discussion. They are from the product management team.
[Manager 1], [Manager 2], meet [Client]. They are the IT lead for [XYZ] project. [Client] has a requirement of automated archiving/purging data after a certain period of time. Can you let us know if we have this feature in our release queue or if/when it is being planned for?
Thanks”
You can use this as a template (changing the requirement part) for future emails. As you can see, this email is straight action: the introduction is made, you acknowledge that your manager(s) is aware of the problem, and you just want to give them a quick start so they can explain everything in one or two emails.
Knowing When and How To Involve Management Is Key to Handling Difficult Clients
After you receive an answer from the product team, you can follow up easily with them, just to make sure that you don’t miss any eventual offline conversations that might have happened.
Clients can be tough—we all know that. Often angry, furious, and unreasonable, difficult clients are a challenge. But that doesn’t mean that you are necessarily the cause of their reactions.
If you fall into the trap of over-promising or poor communication, you can easily become a cause. That is why it is important to have a clear understanding of when you should let your managers handle difficult situations that are not caused by a problem with your work.
Speak to your client, have a talk with your managers, and let them decide if you are going to write code for a new feature now or in three months. You should act as a middleman in these situations, and keep your focus on the actual tasks.
It is important to bring your management into these situations, because their job is to handle difficult clients, product backlog, and future roadmaps. And your client is not the only client your company has.
It is not your fault that clients can’t have a feature whenever they want, but it is your job to act professionally and “hold their hand” to lead them toward the right exit. And knowing when to involve your management can help you do just that.