The Community Blog for Business Analysts


How to Ruin a Relationship With the Client

Most of the IT projects imply constant cooperation between the team members and customers. Although it might be often overlooked, the role and the importance of the client within the project is very crucial. Thus, it is in your interest to build a strong relationship based on trust. However, gaining trust on a single occasion is not a dealmaker — you have to maintain and reinforce it by every action.

As a project manager at Mad Devs, my colleague Tamara has worked with quite many clients and gained first-hand experience and knowledge on how to elevate trustful partnerships. Here are her 5 wake-up calls, which indicate that you are on the verge of losing credibility and setting doubts on your expertise to clients.

1. Lacking transparency

We often talk about the great importance of transparency for businesses in a modern-day world. Even though companies implement the latest software to achieve the required level of transparency in the documentation and on organizational levels, there are still easy to eliminate yet often overlooked aspects such as transparent communication.

Transparent communication between client and company.

Nowadays, the ability to collaborate with people from around the globe is more feasible than ever before. As globalization brings us closer to each other, we have to remember that everybody comes from different cultural and linguistic backgrounds. Such cases are commonly found in slack group channels when someone starts speaking in the language that not every member of the group understands as a native speaker. Yes, maybe the majority do understand it, but the person who did not is going to feel left out and neglected.

I would suggest implementing a one language policy not only for video calls with the client but also for every group chat where he/she participates. Of course, it is not only about the language barrier but the overall feeling of inclusivity. It also would be better to avoid any inside jokes and topics that a person might not be familiar with.

2. Broken promises

Have you scheduled a deadline for fixing a bug with your front-end engineer, but he asks for an extension? Sounds familiar, right? I can’t even count how many times such irresponsible actions were putting me into a risky position with a client and upsetting the whole team. Because for a team to operate as a single entity, everyone should be self-organized and committed to common goals. The well-structured team is key to an outstanding final product, which will leave the client satisfied with the result and a feeling of a civil partnership. And as the word of mouth rules, good reviews can bring more customers to your services.

I believe it is essential to create an environment where achievements and success can be regularly tracked and celebrated because it helps team members to stay focused and keep track of their responsibilities and tasks. For example, we at Mad Devs have been implementing the OKR approach (Objectives and Key Results). And I am already seeing the positive impact it brings to the teams because it provides each member with a clear vision of the goals. Clear goals make it easier for them to contribute and allocate their time efficiently.

Not clear goals make the work harder.

3. Poor reporting

Reporting might be a point of frustration for companies in the early development stages or teams that don’t have a clear organizational structure. For example, you have signed off the project with the client and carefully planned it. Then you are proceeding to the execution stage. Your engineering team is working hard on developing the product, but at the same time, the client is continuously asking questions about the progress made. And don’t get me wrong, an interested, and involved client is an excellent thing! Yet clients repeatedly asking questions about development may be evidence of a poor reporting process in the team. The team should proactively share what’s going on in the project to keep everyone up-to-date.

Eye on laptop.

Nowadays, the client’s involvement in the project is higher than ever before. The client participates at almost every stage of the project. Therefore, it is vital to set the right plan for further interaction and give the client easy access to check the team’s progress. Moreover, modern-day solutions make it way easier to accomplish this goal by using project management apps such as JIRA, Trello, Basecamp, etc. You can create a very sophisticated and easy-to-comprehend schedule where all the deadlines and set goals can be tracked and updated while also giving customers more tools and room to be involved and supervise the project.

4. Discrediting the team

This point will probably better resonate with a project manager. Imagine a situation where the deadline is approaching you, but the QA team found new bugs that are delaying the release. And now, you have to explain your struggle to the client. This conversation is not going to be one of the most relaxed, but you have to remain calm and clear-minded, no matter what. Otherwise, it is easy to fall in the pitfall of assigning the blame to other team members and shedding the wrong light. You have to remember that any problems that may arise will be faced by the team together, and there can’t be any scapegoats. If something is falling apart, it indicates poor time management or a lack of planning and testing.

Aside from the previous example, it is essential to remember that disclosing any problems you have within the team with the client is probably not the best solution. If you have any complaints about a specific member, this feedback should be discussed directly with the recipient and in privacy.

Discrediting the team.

5. Ignoring clients’ needs

Often some ideas of how the final product should look like are diverging between developers and clients. And, understandably, engineers are getting very committed to it throughout the project and trying to improve it in every possible way. Yet being absentmindedly carried away by such ideas can negatively result in your relationship with the customer. If the feature you are trying to implement is not on his/her priority list and you are spending a significant amount of time working on it, (while the more appropriate stack of work is being pushed to the side), you might end up not meeting the main goal and therefore not fulfilling clients’ wishes.

Even though such enthusiasm from team members is well appreciated, any modifications that are wished to be made should be negotiated and approved by the customer to prevent future misunderstandings.

Two man with phone.


Of course, these wake-up calls don’t cover every possible issue. However, I believe that these small miscommunications can be fixed without any pain and increase your credibility in the customers’ eyes. I hope this article will help you be more attentive to your actions, and no client/team relationship is going to be further harmed by any of the points I mentioned above.

Happy team and client.

This entry was published on Jul 22, 2020 / Andrew. Posted in Project Management. Bookmark the Permalink or E-mail it to a friend.
Like this article:
  2 members liked this article

Related Articles


Only registered users may post comments.

Modern Analyst Blog Latests

As we start a new year many of us will take the time to reflect on our accomplishments from 2012 and plan our goals for 2013. We can set small or large goals. goals that will be accomplished quickly or could take several years. For 2013, I think Business Analysts should look to go beyond our traditional boundaries and set audacious goals. Merriam-...
Recently, I was asked by the IIBA to present a talk at one of their chapter meetings. I am reprinting here my response to that invitation in the hope that it will begin a conversation with fellow EEPs and BAs about an area of great concern to the profession. Hi xx …. Regarding the IIBA talk, there is another issue that I am considering. It's p...
Continuing the ABC series for Business Analysts, Howard Podeswa created the next installment titled "BA ABCs: “C” is for Class Diagram" as an article rather than a blog post. You can find the article here: BA ABCs: “C” is for Class Diagram Here are the previous two posts: BA ABCs: “A” is for Activity Diagram BA ABCs: “B” is for BPMN


Blog Information

» What is the Community Blog and what are the Benefits of Contributing?

» Review our Blog Posting Guidelines.

» I am looking for the original Modern Analyst blog posts.


Copyright 2006-2024 by Modern Analyst Media LLC