Common Mistakes in Client Communication: How to Not Frustrate Your Client
When someone requests a project, we have to assume that it’s very important and that they deeply care about the product you’ll be working on. So, it is safe to assume that a client is bound to build a lot of expectation around the final product, and therefore may become emotional when it comes to delivery.
Throughout the course of the project, a client might get super excited about a delivered feature and love you, and on the next day he or she can discover something doesn’t work and that affection will be gone. More often than not, it’s just a matter of client communication gone wrong.
Although there are no recipes for success when it comes to remote software development, I believe there are a few things that must be avoided to maintain a healthy and productive relationship with clients that placed so much trust in your hands.
Don’t Fail at Basic Communication with Clients
Imagine communication with clients as you would everyday communication with coworkers, friends, or any other person to whom you’d extend courtesy.
If an old friend is visiting home and you agree to enjoy a local delicacy “at your old place” at noon, a few weeks later, would you just show up there? Would you stay in touch in the meantime, call to confirm a few days in advance? Or maybe you’d assume they’re too busy and wouldn’t want to bother them for no good reason? Would you expect them to let you know when they arrive?
You aren’t likely to keep chatting every day unless you have a lot to talk about, but you will maintain some form of communication, as a matter of courtesy and practicality: You don’t want the other person to think you forgot about them, but you definitely don’t want to drive halfway across town for no good reason.
At some point, you probably experienced similar situations in your professional communication as well, even with long-time partners and coworkers. Some projects are executed with minimum communication, just like saying “the usual, at noon, see you there” to confirm a light lunch. Even if something comes up, the other party will surely let you know, and you’ll agree to reschedule.
However, things aren’t that simple or linear in the world of software development.
If you start working on a project, especially when you’re dealing with a new client, if they never hear from you, they will begin having second thoughts about your work and commitment. Even if you show up with a flawless product after a few weeks, clients may already have a less than ideal perception of you.
Although sometimes it’s bound to feel awkward, it doesn’t hurt to talk to the client even if you don’t have anything out of the usual to report! Do you have any doubts about one tiny point of a user story? If you think it’s important, let them know. You’re running a bit late and are not sure if you’ll be able to meet that estimated date you agreed on? Call the client ASAP! It’s better they hear about it right away.
You don’t have any doubts and the project is perfectly on schedule, but the client doesn’t talk much? Why not just send an email describing your progress every few days? It won’t do any harm because the emails won’t be a nuisance for anyone, plus you’ll document your progress and maintain regular communication with the client.
Flawed Client Communication Fosters Unrealistic Expectations
So, in the beginning, I mentioned that the client is bound to have a lot of expectations about the project, right? Right. Period.
The client already expects a lot from the product. If it doesn’t go the way they imagined, clients will inevitably get frustrated. So, why would anyone promise more than they can deliver, thus creating even more unrealistic expectations?
Here’s a quick parallel: You bought a tablet online and were promised 10-day delivery. On the 8th day, the shop tells you there’s a problem and delays delivery by a week. To compensate you for the inconvenience, the retailer promises give you $75 store credit.
You probably didn’t really need that tablet for the next few days anyway, so you think it’s a good deal! Now you can enjoy the tablet, plus use the store credit to buy your kids something nice. But the shop calls the next day, saying everything was sorted out overnight.
You’ll get the tablet the next day. No extras, no store credit. Now it’s you that’s frustrated!
“What? Just yesterday you told me I’d get a better deal! That’s not fair! I already told the kids…“
Rewind a couple of days and all you were expecting was the tablet anyway. Had nobody promised you a better deal, you would have been pleased with your toy when it arrived the next day. But now, you feel like you’re missing out for no good reason, other than the shop’s decision to let you know.
How can developers, especially freelancers, avoid similar situations in their communication with clients?
By not going crazy and saying everything that comes to your mind in the first place. Suggestions are not prohibited; actually, they are very welcome if you think that a particular requested feature isn’t a very good option to solve the problem at hand. But the key is: Think first.
- Listen to the client.
- Analyze their problem.
- Analyze the proposed solution.
- Make sure it’s within budget/schedule.
- Finally, go ahead and present your suggestion.
This is why client communication skills can be tricky, because failing at just one of the first four steps means you could end up wasting your time and, worse, your client’s time.
Don’t Assume You Know What the Client Needs
Paraphrasing Mary Schmich, Ladies and gentlemen of the class of ‘17: Listen to the client. If I could offer you only one tip for the future, listening to the client would be it.
If you were called for a project, it is because someone needs something. And who would know better about that necessity than your client? It may seem obvious, but sometimes, in the real world, people forget it.
Let me give you an example. A retailer asks for a “software system” for his business. As soon as you see it, you jump to the conclusion that what they want is something to register all the available products, record every purchase made, generate receipts for customers, and report on what was sold periodically and on which items are running out of stock.
So, on your first meeting, you want to show you are efficient and present them what you have prepared, the proposed features, a basic design to go with the shop’s visual identity and all. But then the puzzled client says that, actually, what they need is an algorithm to calculate how to better display the products on shelves, aiming to raise revenue for specific brands and products!
The error here was simply not identifying what problem you were supposed to solve. Of course, in this case, since it was very early on in the project, there would be plenty of time to make it right, but sometimes, this sort of mistake happens further on. Even it can’t be as drastic as the previous example, it can still harm the project and/or your relationship with the client.
My suggestion is the following: Talk to your future users, a lot if possible, and consult various stakeholders in the project. They are the ones with a good overview of the situation and they know what they need. Try to figure out what they currently do, every step of the way, and explain how software would come in handy. I like to say that, when I’m trying to understand what a client wishes, my goal is to almost be able to perform their job myself. If you get close to this point, then you have truly found out what their needs are.
Not Understanding What the Client Is Asking For
It’s not uncommon to receive some kind of documentation about the problem at hand. Sometimes it is just a high-level description, whereas other times it’s a detailed document with use-cases and business rules. In any case, no matter how clear the records are, the one thing you cannot do, is just assume everything written there is the absolute truth.
Exactly. First, something can mean one thing for someone, in a certain context, and a completely different thing for people who do not belong to that reality. And if there is something that you and the client don’t have in common, it’s context!
Second, not everyone is a very skilled writer; they try to say A but end up describing B.
So, after reading everything you’ve been sent, how will you be sure that what you read is really what they meant? Well, you will digest everything, make some notes, analyze everything and… call a meeting. (You see? It’s all about communication!) At the meeting, you will talk about the problem, and describe what you understood in your own words. At this stage, you will probably be able to identify any misunderstandings.
“Oh, but in my case, I didn’t get any documents. I just sat with the client and they explained everything to me while I took some notes”.
Well, there’s still no guarantee that you understood what they meant and my suggestion still stands: Take some time with your notes, think about the whole problem, organize everything, preferably in some sort of timeline of events, and then call/meet again with the client to present what you understood. It might sound repetitive to you, but sometimes even the client doesn’t have a full vision of all the processes involved to accomplish a specific task and will then see how complex the software will have to be.
At the end, you must be certain there’s no ambiguity or misunderstanding.
Why You Shouldn’t Deliver Everything the Client Asks for without Thinking
OK, now that you know that you should listen to the client and confirm what you understood, you can just go ahead and do everything they asked you to, right?
Now is the moment you can finally use all the experience you have and ask yourself: Is what the client asked you gonna solve their problem? Is what they asked you really what they need?
You would be surprised to see how many times the answer is “no.”
Before just delivering what the client asked for, we need to analyze the problem and, if you don’t agree with what the employer proposed, then it’s your job and professional responsibility to make this clear. Of course, you should, then, explain why you think their proposition isn’t good and what your alternative approach will do to address these shortcomings. Once again, communication is the key.
If you and the client are reasonable, then you will either proceed with your solution or have a brainstorming session to come up with a better one (in case your idea wasn’t acceptable for the client for some reason).
Prototype—Don’t Write Extensive Documentation
I already said that you and your client generally don’t have the same perspective, right? Hence, just as it affects your comprehension of their documentation, it will affect their understanding of what you deliver in writing. It’s a matter of context, too.
So, I agree that somehow (on a higher or lower level), we have to document what we are about to develop. But handing several pages of text without any visual elements won’t do you much good. The client will get bored from reading it, will stop paying attention, and probably won’t be able to understand what you mean by those complex business rules—or they will interpret something completely different from what you had envisioned.
Bear in mind that these misunderstandings can be even worse if the client has no technical background.
All these factors can result in the same problematic outcome: Clients will complain when you deliver the product because it’s likely that it won’t be what they had in mind.
Here is what I suggest: Always prototype, even if it’s just a sketch to draw what your plan is. And whatever definitions you have to make, start from there. Make references and try to keep it simple.
Stop Wasting Time Convincing the Client You’re Right
I can almost be certain that every developer has been through the following situation: At the beginning of the project, the client says “I need the software’s background color to be yellow. It has already been agreed upon by the board.” Then, when the software is delivered they say “Oh, but the background color can’t be yellow. I told you it had to be green!” Now, how should you deal with this?
For sure, it will be no use, in any case, to just insist you were right and they were wrong. If anything, it will just give both you and the client a hard time.
It’s always good to have a good record of communication with the client, just to make sure you are on the same page and leave a written trail. Most of the time, if it’s something simple, you can just email the client, saying, “As we agreed at that meeting, the system’s background is going to be yellow.” And if, in the future, the client changes their mind, you can argue that you did that way because of that meeting mentioned on the email, but if that modification really needs to be made, you can execute it, for an extra x hours (and sometimes, an extra x dollars).
But if there isn’t anything to prove you were right, then you probably have a decision to make (as well as a lesson to learn): Is the change that big that will require a change in the current architecture or affect other features? If not, it’s probably best to just go ahead, do it, and get the client by your side (but with eyes wide open so that it doesn’t happen again). If it does, then a talk with the client will be the best solution; not one focusing on “how you were right,” but on “how we can fix the current problem.”
In any case, the best way to prevent having to make big modifications is to deliver short new features in short periods of time. Therefore, if anything has to be changed, it probably won’t be a major transformation of what already exists.
Know When to Commit to Deadlines
Last, but not least, one of the biggest mistakes you can make is giving your client a deadline for you to finish the project. And they will beg you to make that mistake!
Of course, as a client, you want to know when you’ll be able to use all those nice features you’ve been discussing over the past weeks (months?). But, since a project is not a defined product, a lot can happen from when the development starts until the software is ready to use.
First of all, one cannot predict the unpredictable. It is very likely that you will have to deal with something you were not expecting to. It could be a license the client promised that wasn’t purchased on time, or some other internal software you need to use but was not released when it should have been, or the environment was different than the one agreed to back in the beginning, or the client changed their mind about a (few) features and you had to redo a couple of things.
None of that is really a developer’s fault and can deeply affect a project’s deadline. But if you, willing to please the client, promised you would deliver everything by some date and end up, for all the right reasons, not doing so, one thing I can guarantee is that the client is going to be, at least a little, frustrated. If you’re a freelancer, you have to manage your time efficiently, as this Toptal Engineering Blog article explains. Don’t forget that client relationship management is your job, too.
So, do yourself and the one who depends on the project a favor and at least give them an estimate of how long it will take to develop everything, but always make it crystal clear that it is just an estimate and not a deadline.
Also, I strongly suggest (especially if you’ve already given an estimate) that you always tell the client when something is taking longer than expected so they can act to help you!