I think most of you at least once in your software engineering career have experienced a situation when the Product Owner’s “help” led to disorganisation of the work of the entire team. Moreover, it can be disturbing or even put in question the value of your work. What’s even worse – it may cause some delays in the project’s completion. Sounds familiar, right? Therefore, in my article, I will try to present some advice to deal with communication problems in software development.

Communication techniques used in software development process

The client is often the Product Owner. They pay for outsourcing software development and the final product and therefore, no one should be surprised by their willingness to participate in the team’s work. However, the role of the team is to make the best use of product knowledge, business experience and the client’s commitment to the product development process.

Where to start? Well, it may sound a bit like a truism but – communication is the most important aspect. Really. Especially in some challenging situations, it turns out that transparent communication is the key to success at every stage of cooperation with the client. What does it mean in practice for software engineering?

Good communication starts with clear expectations

What is the most common problem of misunderstandings (and not only in IT projects)?. The answer is quite simple… it’s a different point of view on expectations. Like you know – a boy, hearing from the girl that they are going out to the cinema, probably does not expect to watch the next part of the popular vampire series. On the other hand – a girl, hearing about a date in a luxurious restaurant, probably won’t imagine going out to a neighbourhood pizzeria.

That is why it is so important early on to gather the interested group of people in one place when starting a new project and determine all the important things. Well, not necessarily things like what a “good movie” or “luxurious restaurant” means for them but rather – what do they mean about “high-quality software product” and so on.

Therefore, effective communication means setting with the client all the details of your future cooperation. How do they understand the quality? What standards should we adhere to? Why do we run projects the way we do? What are all these procedures for?

It is very important to make sure that the client understands that thanks to this we can ensure the highest quality of the source code of delivered solutions. Of course, it’s good to remain opened to process improvements proposed by the client and work together to come up with a solution that will allow you to run the project efficiently. 

However, we must remember that some standards often may be unclear and sometimes even meaningless for a client from a non-tech industry, some standards may be unclear and sometimes even meaningless! They need to understand that QA Specialist is not a software developer – we don’t create, but rather find defects. 

Also, try to stay patient when repeating certain issues several times. Talking about some software development process for a non-technology client may be as difficult as trying to understand how their bucket elevator works for you. That’s why it’s called cooperation. You should rely on open and honest conversation and patience. It takes a bit of effort to develop those communication skills. 

It is also worth reminding that both organizations have a common goal – the success of the project. Even if we have a different vision than the client when it comes to certain processes.

We are the team – let’s talk

Taking care of the good information flow with the client, we must not forget about clear communication within the team. Especially now, when we do not see each other at the coffee machine, it is worth paying even more attention to having a good relationship and communication between team members. 

You may say – “hey, but we have daily meetings” – and you are right. Properly conducted, a daily may be a mix of project analysis and small talks. But it’s good to have it in the back of your heads and perform a “health check” from time to time to see if everyone knows what to do. If they know who they can ask when something is unclear and make sure that the project goes exactly in the direction you agreed with a client. This will help to avoid unpleasant situations and conflicts. Typically, it should be a project manager role, but it can be anyone from the team who feels good in this role.

In effective communication, trust must work both ways

Since we talk about the team, it is worth discussing the issue that, apart from communication, is crucial in building effective cooperation – trust.

I mean the trust between team members on a very basic level, assuming that if someone declares that they will do something, it will be done, and if there is any difficulty in carrying out the task, they will clearly communicate it to the rest of the colleagues. 

Remember that you are one team, so any setback is a problem for everyone involved. And you should think about a solution together. If your teammate did not do something they should or did it wrong – it’s good to find a reason for that. Maybe the lead requirements changed during the implementation of the task? Or maybe the documentation was unclear from the beginning? Whatever the reason is – you should discuss it effectively and find a solution. So, before calling someone out on a meeting with management, it’s good to find the source of misunderstanding or mistake. 

Developers that supports and trusts each other not only makes work more pleasant and efficient but also gives the feeling that the team has the same goal. It also builds trust with the client and can prove that we will deliver the product for them. 

Additional support needed immediately!

So, let’s assume that we communicate well, we trust each other in every situation, but the project is still not going our way. What else can we do? Sometimes it may be a good solution to have an additional expert or even teams of experts. 

It can be a developer, an additional Project Manager or a QA Specialist – depending on the needs. In addition to real work support, such a new person can look at the project from a different perspective and possibly find new solutions to problems that you have been dealing with for weeks, or notice things that the team may have missed so far. 

Remember, a new person entering a project always sees things that you are already used to, it is a completely natural state, even a benefit that should be used, not a form of control.

Often, the appearance of such support from outside, especially if this person has the status of an expert or a higher position, can help you build relationships with a client. Also, if a client sees a new person as an “ally” of them and appreciates his authority, it may be easier to convince them that some ideas and solutions you have may be good – even if it was difficult before.

What if all verbal communication fails?

I would love to say that every project can be made straight and completed with success, but unfortunately, it is not. There are situations when, despite both parties’ efforts, cooperation does not work out as it should.

If you tried all the available methods but they failed, you normally have two more options:

• The first and… not the ideal one – to clench your fists and do the best you can. It’s not really an “option” but sometimes the only solution.
• The second option that is worth considering is to stop working on that project for some time. If you can do that, it’s better to say “enough” in some cases instead of rewriting the whole application from scratch. 

If you can afford it – you should sit down and think about how we want to continue working and what we want to achieve, otherwise, we are inevitably heading towards a catastrophe or at least a budget burnout. Maybe in such a situation, it is worth offering the client workshops or support of a business analyst? 

Obviously, you should first communicate it to the client and together think about what’s the best for the project. Nevertheless, sometimes such a moment to take a breath can be beneficial for both parties and the project.

Summary – what to do to complete the project rather than to finish it?

The most important thing is to remember that we are all humans. A client, just like you, may have a bad day or a stakeholder who looks over his shoulder. There may be tight deadlines they cannot tell you about or any other non-work-related problems they face. 

Therefore, everybody involved  should:

• take care of clear, effective and transparent communication,
• explain misunderstandings as soon as they occur – remember that the feedback has parameters (we refer to the fact or situation and not to the person; we do not wait, we talk as soon as possible; we make sure that our interlocutor understood what we wanted to tell them),
• clarify any doubts,
• trust each other at all times – whether it’s a team member, supervisor or client,
• get and give space to make and correct mistakes.

And last but not least – remember that at the end of the day – we all have the same goal, that is the success of the project.