The first type of No Communication is very simple: nada, none, no acknowledgment, and zero feedback. Here’s an example. Our project was at a critical juncture and we ran into a few important questions. I wrote an email message carefully explaining the issues and sent it to Joe, our lead BA and product owner. I even made sure I checked the “important” flag so my email will get the appropriate attention. That was 2 days ago, and still no response. I saw Joe when I walked past a meeting room this morning and he appeared to be very busy. I am sure it wasn’t anything personal since he actually exchanged greetings with me. I left him a voice mail but he had not returned. I finally staked out his office and got the answers I needed. What if I was working in a distributed team thousands of miles away? What if our time difference did not allow us to easily communicate in real time? What if…? It’s always a best practice to send back acknowledgment. Communicate even if the only message is that you will have to get back later with a full answer.
Another thing I want to talk about is No Communication Plan. One interesting thing is communication issues are not exclusive to multi-shore teams. Pull together a few seasoned managers over a beer and ask them to talk about communication issues. You will hear that communication problems happen to distributed team located in the same country, same city or even in the same building but on different floors. Well, you may even hear stories about communication issue within a single collocated team. What do you think will happen if we don’t pay enough attention and plan for communication between multi-shore teams? Over the years of working and talking to multi-shore teams, communication has always been near if not at the top of the issue list. Our colleague, Ken McCorkell, gave a great example of communication plans in his post Visibility and communication with multi-shore teams
So, we have looked at a couple of “bad” No Communication practices. Let’s take a look at times when No Communication is actually a good thing. There will be time you are able to reduce the amount of information/knowledge need to be communicated between multi-shore teams. You can strategically plan and manage your project, project portfolio, and resources to reduce dependencies and retain knowledge from past projects. It’s not possible to do away with communication entirely. However, the following best practices may help reduce communication costs:
1. Where possible, apply the modularity principle to your design/architecture and assign work so that you can reduce cross-shore dependencies.
2. Manage your project portfolio and schedule so that you can take advantage of the knowledge your team members gained from previous projects. Sometimes it makes sense to delay a project a couple of weeks so you can have the same project team working on related projects.
3. Plan to increase and balance the number of resources with knowledge of a certain system. With this, you can “seed” a new project with people who are already familiar with the system. If you are outsourcing, besides looking at the obvious turnover rate, you may want to know how/when resources are assigned to or taken away from your project. The more people who already know about your business/systems you have on your next multi-shore project, less communication will need to happen across teams. This will reduce (but never eliminate) the cost of communication.
Do you have a No Communication experience to share? Do you have additional ideas or best practices to reduce the cost of communication? Please share them with us.
Next time I’ll write about mixing different communication types/channels between multi-shore teams for best results.
No communication and its impact on multi-shore teams
by Binh Nguyen (San Diego, CA) on April 7th, 2010 | ~ minute read
