Duplicate Conversations. Duplicate Conversations.

In almost all places of work, there exists a level of wasted time and effort when communicating a message multiple times.

In almost all places of work, there exists a level of wasted time and effort when communicating a message multiple times.

 

These “duplicate conversations” are wasteful and ultimately take people away from the work they are trying to complete.

 

Image courtesy of : http://www.flickr.com/photos/kalexanderson/

We need to communicate to our “communication stakeholders” (team members, project, sales, marketing etc) but this communication should not need to be repeated multiple times.

 

Duplicate conversations can occur for a vast number of reasons, but often it is as simple as key communication stakeholders dropping by for updates. Only to be shortly followed by another stakeholder. And then another. Soon you find the whole morning has gone and all you have done is update people. This is especially so when the management style is to “manage by wandering around“.

Meeting are a ripe source of duplicate conversations, typically arising due to a key stakeholder not being present in the meeting or people taking away a different set of actions or conclusions from the other attendees.

Different teams working on the same problems can often result in duplicate conversations, especially when they aren’t talking to each other during the development and are both updating the stakeholders individually.

No designated “Panic Manager” or “Point of Contact” can result in the whole team being involved in a bug investigation when it could easily be dealt with by just one person.

 

Repeating the communication once is bad enough, but to repeat it several times is very trying.

Even worse is the predictable amount of panic these multiple conversations can cause. This is especially so when it reaches a person of “power” after travelling through a series of Chinese Whispers (other people repeating the same conversation but missing out details or adding in details not included in the original message).

It can sound like a full scale project meltdown by the time the last person in the chain hears about it. Emergency planning meetings are called. People are furious. You’re wondering what went wrong. Panic and flapping over nothing. A storm in a tea cup. A miscommunication.

 

Communication failures I believe cause an unprecedented amount of wasted time, unneccessary panic and general grief for all involved.

 

So what’s the solution?

 

Each situation will be different and there is unlikely to be any one single answer to any communication problem but what follows are a few suggestions.

1. Hold a daily stand up meeting (where applicable with team size) and encourage all members to be clear and accurate in their description of what they are working on, what they are blocked by and what they have completed.

A standup (like any meeting) is only valuable if people are going to actively communicate. Too much information and people switch off. Too little and you’re losing the value. And no, they aren’t exclusive to agile projects.

 

2. Take “minutes” in meetings with clearly defined Actions. Read the actions out at the end of the meeting to ensure everyone understood them and took on board those actions they were tasked with. Communicate the minute notes immediately after the meeting in your preferred format of communication.

 

3. Use information radiators (low tech boards or areas or pages used to communicate information). Make sure the information is simple and easy to understand. Making your information radiators tricky to read is no good. They need to communicate the correct information, to the correct audience with the least chance of noise creeping in or misunderstanding of the message.

 

4. Dedicate someone (or more than one person) from your team to be the main point of contact for issues, questions and panics. Issue do happen so it’s prudent to make sure you are set up to handle them in the most appropriate fashion to avoid distraction and interuption and also to ensure the best possible response to any customer issues.

It’s also incredibly expensive to have a large team investigating an issue, especially when that issue turns out not to be an issue.

 

5. Organise cross team meetings or standups or chat channels. Use whatever communication medium floats your boat to ensure different teams are talking to each other when working on the same area, or problem or feature set. It’s crucial to start the communication process and try to keep the channels open.

Otherwisey you could find you end up with a situation Melvin Conway was describing in Conways Law.

 

6. Fine tune your process. If you find yourself repeating the same message to multiple stakeholders then stop doing it and work on the cheapest and lowest tech solution to the problem.

In my experience, the more expensive, integrated and purpose built a software communication tool is (like Test Management Tool), the least likely it is to solve your problem.

You cannot beat face to face communication for gathering the non-verbal subtleties and clues, but if that’s not possible then what about a good information radiator like a status written on a white board?

Or a Chat Group where the discussions and outcomes are already audited and exportable for future reference?

Or a free wiki? Or a blog?

Look for the most cost effective way to solve the problem and keep iterating around the problem until it goes away.

 

However, none of the above will solve your communication problem if the right people aren’t kept in the loop and the people involved aren’t communicating the right messages.

This is a much harder problem to solve.