Why many-a-times the client is not happy even with good engineers
Many-a-times the client is not happy with the development team. This is not a problem because every team is not great and this is not unjust to be unhappy with an under-performing team on various occasions. But many-a-times, surprisingly, the client is not happy with a team despite being highly skilled and high-performing.
In this document, we would like to shed light on some of the factors that a team can and should do to achieve client’s satisfaction along with being a technically expert team.
Is this article for you
This article is not applicable for all the environments. This article may help you if you server under a software development company that is following outsourcing business model meaning the company develops software for certain clients in exchange of some kind of monetary benefit. For such companies, client satisfaction is important.
How far we should go for client satisfaction
Many a times, the client gets dissatisfied for not doing some basic tasks that a development team should do as described in a later section of this document. We should try to do these basic stuff accordingly. But achieving client’s satisfaction does not necessarily mean our own very life is dependent on it. I have seen some entities, ornamental speaking, that may even demand developers’ blood to satisfy the clients which is of course bad, bad not because this is morally bad but because this is not good for business- why this is not good for business- that is a topic for separate discussion.
This document only focuses the basic things (not even the proactive tasks) that we should do to achieve client satisfaction.
Some of the common reasons
Late presence in meetings
This may sound very silly but throughout my career, I have always found several engineers who are not punctual to the meetings. I am not saying they are bad engineers, rather many of them are superb but they are not just punctual when it comes to meetings.
In general, the client is not closely involved with software development. Most of the time, the client does not sit under the same roof as the technical team. He may not know about one’s technical superiority, generally he does not have the skills required to judge one’ technical superiority.
The client is a human and like most of the human beings, he makes most of a judgement based on the interaction he has with the team members. When he sees that engineers (or a single engineer) are not on the meeting on due time, it often strikes a client as that late comer is not serious enough or professional enough. That late comer may put valiant efforts in the previous night on technical tasks but just for being 5 minutes late for a meeting, a negative impression is created on the client’s end, and once an impression is created, it often persists up to various degrees. Due to one single late-comer, the client impression towards the whole team may be damaged.
The client is not engaged enough
Many-a-time, the client is not engaged enough with the project. This is obviously not the team’s fault, the client is obviously the faulter here and for his/her fault, the team suffers. As s/he is not engaged with the team much, s/he feels lack of ownership & empathy towards team and remains on a mood of criticizing. The team needs to always proactively try to keep the client engaged with the project as much as they can. Some common ways to involve the client are given below
Provide regular updates even if the client does not want it
Motivate the client to participate in daily scrum meeting (joining online is okay too). If the client can not participate in the daily scrum regularly, schedule a regular (weekly or bi-weekly, the more frequent the better) meeting with the client.
Ask for his/her feedback as much as possible, make him/her feel that s/he is an integral part of development team
Try to keep him on the same page about updates, challenges, breakthroughs etc
Provides demo (or working software) regularly etc.
We have to make the client feel that s/he is deeply involved with the development team. Once a client can believe this, s/he will feel ownership and gradually s/he will take a supportive role for the team and thus his happiness with the team will increase.
Lack of early escalation
Software engineering is not an engineering, this is more like crafting. Whenever we make or share a plan/estimation, that is based on many assumptions. This is quite normal that previously built plan may not remain intact for various reasons. But what is not acceptable and normal is not to update the stakeholders including client timely.
This is a common incident that we tell the client that we are not being able to complete some task on the eleventh hour and this is utterly frustrating for that client because generally s/he has other plans dependent on our (the development team’s) plan and s/he does not have enough time to adjust his plans if he gets notified at the last moment.
Yes, this is true that sometimes we may get really stuck at the eleventh hour and so there is no other way but to notify the client at the eleventh hour. But this is a rare case. The common case is that we could notify the client earlier but we choose not to, because we have some kind of hope that we will manage it somehow. But “manage it somehow” does not happen always and we start losing client’s trust gradually. Trust is too important to loose, once we loose it, the client starts doubting everything, even if you are the best team in the world and we can not blame the client.
So, we should let the client know as early as possible when there is a chance for the plan to go south. Even if it is the case that we sense some issue but we are still not quite sure that the previously shared timeline will be compromised, we should let the client know that there is a chance of that (compromising timeline). Believe me, nobody likes surprise, your other half may like surprise but your client is not the right person for surprises.
So, keep the client updated with every challenge, blocker etc so that all the surprises can be avoided. Yes, I know, this is not possible always but try to do it at least whenever possible.
Not updating the task status accordingly
In modern software development, we often use some tools like JIRA, trello, spreadsheet etc to track the tasks. This is a very common case that a developer brilliantly completes all the tasks but s/he forgets to update the JIRA task. So, when the client looks at the JIRA board, s/he gets frustrated as the JIRA board does not reflect the real status of the tasks.
Whatever task tracking tool we use, that tool should be a major source of truth so that any stakeholder can know the status of the tasks accordingly at any given time. The developers, testers, designers etc everybody needs to contribute here properly. If the client gets confused by seeing the outdated status, then his rate of dissatisfaction will increase eventually.
Lack of regular progress updates
So, say, everything is going perfect, we have shared a plan at the start of the sprint and now we have completed 60% of the sprint time and we have completed the tasks accordingly so far and the rest is on track too.
So, do we need to do more? Answer is yes!
Most people like to hear “all is well”, human beings crave for reassurance and believe it or not, your client is a human being. Even when everything is going okay, you need to tell that to the client after a certain interval. Like in a 2-week sprint, after every 3 days, you are telling the client that “everything is okay, we will let you know if any challenges come up” etc type stuff. Do this and you will be surprised by seeing client’s positive response after getting this reassurance.
Lack of proper communication
Many engineers are reluctant towards communication, they believe communication to be an unworthy task and many ones also lack the communication skills which as a result make them less comfortable in doing so. The importance of proper communication can not be described in words! The team needs to communicate with the client smoothly. If someone is not comfortable with communication, then others should help it to minimize the gap.
Unfortunately, this is not uncommon that the client asks something on email or slack and the engineer forgets of replying it or even if s/he replies, s/he does it after unacceptable delay. Please do not do it, it may even hurt the client in self-prestige level. Even if we may not notice it but our client is a human being and like most of the human beings, s/he is egoistic, at least s/he has some self-esteem (let alone the consequence of no/delayed reply on some other front). Also, this is a basic decency to respond others’ message on due time.
If your client asks for some information which you do not have, then tell him that. When your client says something to you, reply him with at least “acknowledged”.
This basic decency is not for client only, this is true for all the professionals you are interacting with in your entire life.
Lack of professional decency
This is not true for the client only, this is true for all interactions with all the professionals in our entire life. When we interact or communicate with the client, sometimes we express our feelings/frustration/message etc in an inappropriate way.
Remember, here nobody is fighting over lands like Mughals or Ottomans or Spaniards. We are here to achieve some professional achievement. In the course of our job, many-a-times, we get frustrated and that is quite okay, this is not humanly possible (not healthy too) to agree with everything the client says or ask for, but when we are responding to it, we need to be careful about how we are responding to it. Sometimes, out of frustration and/or emotion, we exceed the professional boundary which we never should. We need to respond firmly and politely with strong logic within the boundary of professionalism.
Reluctance to submitting regular reports
In some projects, the team is required to submit various kinds of regular reports. Many a times, the engineers consider it as an extra burden (which may not be wrong) and are very reluctant to do so. Either you should come to an agreement with the client to make those reports optional (not mandatory) or you need to do it accordingly.
Unhappy to hear it? Come on man, do not get surprised, in the professional world, we need to do many things that we do not like. We have to be realistic.
Too much communication?
So, what I am suggesting involves too much communication which may be a burden for the development team?
If you think so, then you may be right! Not all the teams find communication an enjoyable task!
Communication is much more crucial for the success of a project and client satisfaction than 90% of the software professionals like to believe. And unfortunately, many engineers are not comfortable with communication and we can not blame them too for various reasons.
How we can manage this amount of communication effectively – I will discuss it on some other article someday. Many projects include some designated communicators, many teams have personnel responsible to manage the flow of communication effectively. Whatever the case, regardless of whether we like it or not, there is no alternative of effective communication.
Example of Monstar Lab Bangladesh
Monstar Lab Bangladesh is one of the renowned and esteemed software companies in BD software industry. We are working with many clients, some of them are difficult ones, of course.
But we have been successful to work effectively with those clients too by doing the basic stuff as mentioned above (also other proactive stuff) and deliver successful projects. Whenever we work with some apparently difficult client, we try to see their perspective and come to some arrangement through which all the parties can be benefitted. We do not get defensive, rather than we always find the common grounds that help both the client and the development team (and other stakeholders) to benefit in an equal way.
If nothing works
Now, say, you did everything perfectly and still nothing works, then what should you do? We have to accept the fact. We can only try but there is no guarantee of anything except for we all are going to die someday. Like any other human beings, some clients are not just workable. We have to endure it, some clients will never be satisfied, some projects will never be successful no matter how hard or perfectly you try, this is a part of your professional experience.
Arafat Sultan, Project Manager, Monstar Lab Bangladesh. If you have any thoughts about this article, please let me know at firstname.lastname@example.org . Thanks