Effective Offshore Communication

A while back, my sister-in-law, who was doing her MBA at that time, recommended me to read a book called The Goal by Eliyahu Goldratt. I started reading it just before bedtime and ended up finishing it well into the night in around 4-5 hours straight. It's a fascinating book and written like a story (more on that in another blog later). Anyhow, in the book, the author proposes the idea of 'Theory of Constraints', which in roughly put, says that you have to identify the bottlenecks or constrants in your system and then address them first so that your throughput (or in some sense productivity) increases. The author mainly talks about manufacturing assembly-line style systems (this was written circa 1980).
However, I found that most of the concepts applied very well to the software industry, especially when it comes to onshore-offshore communication. I happened to be managing an offshore team in China at that time and thought I'd apply some of the concepts and ended up finding that it worked extremely well. Inspired, I wrote a white paper (or what I thought was an awesome white paper), only to find out that my company had a long process to actually publish it. I thought I'll share it with the world through my website as an alternative. You can read the full white paper Effective Offshore Communication using Theory of Constraints in my website.
Meanwhile, here's a small gist to get you interested.
In a team that's comprised of onshore and offshore resources, the biggest bottleneck is distance. This bigger bottleneck in turn leads to others such as turnaround time (due to time difference) and cultural differences (leading to misunderstanding). Per ToC, this can be handled using the following techniques.

1. Move the bottleneck to the top: As communication is the primary issue, make sure that is addressed first. For example, if you have a junior resource who knows Chinese, first get him to understand what needs to be done onshore and let him be the liaison to talk to the offshore folks than letting the Technical Lead trying to convey the same in English. You are not there to propagate English but rather to get the work done.
   
2. Increase capacity: Offshore resources are cheaper. If you can, hire a good technical writer on your offshore team (even an English Litt. would do) and get them to do all documentation and additional testing than spend scarcer resources onshore. You can also try to bring in a few junior resources offshore to get some of the daily tasks out of the hands of the more senior developers. The slight increase in cost will be well compensated by the increased productivity from your core team
   
3. Provide smaller chunks: Don't give a month's work to the offshore team and expect that everything will be great when you get it back. It's better to have weekly deliverables so that you can monitor the progress more effectively. More importantly, you can also confirm that what you told them as business requirements are what they understood. The tricky piece here is that too small a chunk would be counter-productive due to the time difference. Asking them to deliver something every day or every other day would make them spend more time in packaging the product than get any good work done. A good balance would be to ask the offshore team to get them to show progress over a video conference once a week and a deliverable every other week.
4. Quality control before a bottleneck: This is probably the biggest timesaver. A day or two before getting a build, get your offshore team to give you a demo over a video conference such as Webex. This way you can do a quick smoke test and visually confirm if what you will be getting is what you're expecting. If you run your tests AFTER you get the build, you might end up losing 3-4 days in sending the build back, getting them to fix, getting it back, and testing it again.
5. Redistribute and parallelize work: I've seen some managers or even tech leads push everything offshore. Just because they are the developers mean they should develop everything. Sometimes it may make sense to do a few prototypes onshore or even a small chunk of work onshore, especially ones that connect to the client systems or need to be validated with the clients frequently.
6. Prioritize work: While this sounds obvious, it's quite important to make sure that the offshore team focuses on the most important work first. It also helps to have a few low-priority items as fillers - stuff that the developers can do to take a break or clear their head.

Hope you get time to read the full white paper. If you do, please do post a comment on your thoughts and your experiences either here or in my site.