I will start today a series of articles on the topic of conflict avoidance within a Software project, and more particularly within an offshore IT project involving international team members.
As soon you put people together to achieve a common goal, the best and the worst can and most likely will happen. The power of achievement of the group is almost infinite. Unfortunately, the power of conflict and misunderstanding is almost as big.
In this series of articles, I want to present various common obstacles in the life of a project team and how to avoid them. We are not doomed to conflicts. But good will and best intentions are not enough. One needs to realize and truly understand what is happening and see the forces in action, to be able to act on the situation and convert the bad into good.
Let’s get started….
1. Do not trust too much written communication
Human Communication is mostly done by body language. Inside this body language, a part is universal like putting your head inside your shoulders in case of danger. A part is socially acquired like circumstances during which you smile, look embarrassed, look relaxed or formal, etc.
Our modern way of life allows us to work anywhere with anybody which is a rather recent phenomenon on the scale of humanity. To achieve that we have to use distant communication systems such as phone and emails. Writing takes a huge part in this system because it is commonly admitted that we need to put in writing what we agree on to keep a trace for later. It is a fact that writing is extremely convenient; as much as a hard drive is convenient for storing info.
Writing offers some very convenient qualities!
- Writing offers a great luxury in our busy world: asynchronous communication. Emails and SMSs are read whenever the receiver has the time to do so. It is far more convenient than a phone call, which requires being both (or more) available at the same time.
- Writing allows easy one-to-many relationship. One can send an email to the whole team or even company in one click. This is fast, really fast!
- Writing offers long-term memory. If one does not want to remember something in details, one can write it down.
Writing presents some weaknesses
The weakness of this situation is that we are not as good in written communication as we are face to face. Conveying precisely an idea or a message when it is not a fact is hard work.
The first one is ambiguity. For instance, if I write to a colleague about a task: “This week we put the maximum effort on this task.” It is far less precise than if I write: “No less than 6h a day on this task for the next 7 days!”
Unfortunately, we tend to use the first format more often than the second. Indeed, the second requires more effort to produce than the first one. It is very convenient to make assumptions when we communicate with others. We should be glad we do, as otherwise we would be overloaded again and again by information we already know. We must assume things! It would be unbearable otherwise.
It is good to notice that verbal communication does not resolve entirely the problem as we all know, but it reduces it by offering the possibility to send body language signals and voice intonation.
Solution for avoiding the troubles created by written communication
So, in the one hand we have a need to communicate in writing because:
- It allows long term storage of information
- Offers convenient asynchronous communication
- Is can be extremely fast with one-to-many possibilities
In the other hand:
- It is by nature ambiguous. Without body language and voice intonation, it makes it very hard to decrypt.
- We all naturally make assumptions and the lack of direct feedback from the people we are talking to makes it impossible to detect some of these wrong assumptions.
In the situation of an IT project developed totally or partly offshore, communicating in writing is inevitable. And anyway, the point is not to suppress all written communication but to limit its possible negative consequences.
So, what do we do? Here is a short non-exhaustive list of possible actions:
- Ensure you can communicate face to face with someone working inside or hand in hand with the remote team;
- Allow and encourage the readers of the messages (documents, mails, etc.) to ask questions, clean ambiguities, challenge the author, etc.
- Run formal sessions of ambiguities removal on important documents like requirements. I might write an article on such sessions one day as I created the process myself for a customer. The general idea is to hunt and track ambiguities before they bite you in the back later.
- Use tools such as Unified Modelling language (UML) to express ideas and concepts. UML diagrams are non-ambiguous and that is a fantastic asset.
- At any point in time, keep in mind the strength and weaknesses of written communication and don’t be fooled by the ease with which we use it.
Next topic: 3 email management techniques for offshore software development project More…
In the next article I will introduce the dangers of emails and their power to create conflicts. I will also reveal the technique I have been using for years to reduce the risks by 99%.
Liemur provides Software Development Services within UK and with its nearshore branch in Budapest.
If you like this article, what about tweeting it or recommending it?
Sylvain’s personal blog can be found here: blog.sylvainliege.com