Offshore Development Part 1

Your company has decided to take the leap and begin migrating some of your development offshore. As a business analyst/product manager, I have good news and bad news for you. The good news is that management will probably realize how important your job really is. The bad news is that your job just got a lot harder.

In recent history, most software development was specified and implemented by colocated teams. The developers could just walk down the hall to the product managers and say "hey look at this" and the product managers would get an instant demo. This isn't necessarily a bad way of doing software development and is at the heart of Extreme Programming. However even when the teams were colocated, on very large projects, this model never did work very well. With distributed teams, it is much harder to communicate between the business and the development teams and this difficulty has resulted in the early failure of attempts by many companies who have tried to move their development offshore. The good news is that makes software requirements (and you) more indispensable than ever. Extreme Programming threatened to do away with business analysts altogether. Thankfully most companies are realizing that XP doesn't work for large industrial strength projects or with distributed teams.

The bad news is that your job just got a lot harder. With offshore development, everyone knows that communication is a challenge. This has a tendency to drive teams to use a waterfall model instead and away from the better iterative models. They develop the software requirements (or even worse rely on the developers to create the requirements) and throw them over the wall. The developers design and code and throw their product over the wall to QA. Once QA is done with it, it comes back to product management for validation. This obviously is a sure fire recipe for disaster. As we have discussed in other blog posts, the waterfall model does not work well even in colocated situations. However, even the iterative models that we prefer are made significantly more difficult when dealing with offshore teams.

Here are some of the key software requirements related issues:
1) Lack of developer feedback in evaluating the requirements.
2) Difficulty communicating the requirements due to subtle language or cultural barriers.
3) Written requirements that might be fine for onshore projects are insufficient for offshore projects.
4) Disconnect of the development team with the business stakeholders.
5) Slow response times in responding to requirements issues.

In Part 2 we will discuss ways to improve the way you develop and use requirements with offshore development teams.

Here are a couple of articles discussing the difficulty of offshore development:

Lifetime fitness offshoring failure
http://www.networkcomputing.com/showitem.jhtml?docid=1421f3

Cost savings of offshore development
http://www.cioinsight.com/article2/0,1540,1837328,00.asp

Powerpoint discussing reasons for offshore failure
http://www.unanet.com/news/events/2004/LeverPoint-Unanet%20Seminar%20v16.ppt

Joel on Software discussion about offshore projects
http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPost=51759

Bertrand Meyer article on offshoring
http://se.ethz.ch/~meyer/publications/computer/outsourcing.pdf