Skip to content

Managing Offshore Software Development

3d person and globe
Originally uploaded by 姒儿喵喵

Over the last decade, many lessons have been learned about sending software development work overseas. These lessons have been documented in books, magazines and blogs the world over. Many lessons are similar to those that you would face if you chose a consultancy down the street from you. Others are simply lessons of doing business with cultures foreign to your own.

For those who have been working with offshore partners for a number of years, what I write here on the subject will be a “no duh” moment. Others looking to embark on a pilot of sending work overseas may think “this won’t happen to me.” Regardless – what I write over the coming weeks and years will be my observations and a sort of record of my experiences.

My thought for today is this -> It can be more challenging than it might appear. On the surface, the idea sounds great. You do the customer interactions, the requirements definition and design work – then turn it over to your partners to implement. But what if there are issues? When the work is done within 3 timezones of yourself, getting people together to discuss the issue is very straightforward. Even emailing back and forth is possible when the timezones are close.

But the problem with sending work 12 timezones away is the lag in time. If there is an issue that impacts delivery dates, resolving it via email is a guaranteed way to miss your deadline. One model that has worked well is to use an “onshore coordinator” – a technical individual that works for your offshore partner whose job is to interface with you and the offshore team and work across time boundaries to get issues resolved. 

One final thought on this matter is this -> no matter which of the above options you take, whether you have an onshore coordinator or you are up at midnight on the phone – YOU are the bottleneck. It may be that the team overseas is incompetent, but it’s your job to make them competent (or take some other action). If systems are unreachable, requirements are unclear, or deliverables are of poor quality it is your responsibility to remove the obstacles and rectify the situation. If you execute well, your chances for a successful program are higher.

No comments yet

Leave a Reply

You may use basic HTML in your comments. Your email address will not be published.

Subscribe to this comment feed via RSS