Offshore Software Development: How to select projects that will succeed

GoArticles, June 23, 2007 By M.M.Sathyanarayan
(http://www.goarticles.com/cgi-bin/showa.cgi?C=529601)

One of the key decisions a company needs to make in offshoring software development is which projects to offshore. You cannot simply offshore “maintenance” projects, because your staff in the U.S. wants to work on new product development. This issue must be carefully thought through and here are time tested and proven guidelines:

1. Business objective: It may sound simple but make sure you clearly define your objectives for offshore outsourcing. Are you going offshore for cost only, for cost and skills, do you wish to use local expertise to develop or customize products for that part of the world? Each of these can lead you to a different list of potential projects.

2. Adequate resource pool offshore: This issue is not always obvious; but depending on the technologies you employ, you need to ascertain if there is a large enough resource pool. Competition for the right resources in countries like India is intense; if you are in a narrow niche and you need to invest significant training dollars to get the staff up to speed, you need to think through how you can retain your staff. Industry has experienced many instances where one company invested in training key staff, only to find that 6 months later a competitor offered enough incentives for the recently trained staff to leave the first company. A mid-sized company who experienced this is evaluating if they should bring the project back to U.S.

3. ROI: A small software company recently considered offshoring; the proposal was to offshore the equivalent of four to six developers. The financial analysis indicated that at this level, the overhead needed to establish and manage an offshore effort was significant and the cost savings after considering all associated costs didn’t exist. The company decided against outsourcing. This example points to another criterion for determining whether a project makes sense for offshore — return on investment. After all, one of the most common reasons for offshoring is to reduce cost.

4. Deliverables and level of interface with the U.S. team: Can you define clearly what the offshore team needs to do? The more you can do this, the better your chances of success. What is the level of interface? How much interaction does the offshore team need to do with the U.S. team? If you need to provide ongoing (read: some times daily) management guidance, it will take significant management effort make it successful or worse yet, it may not succeed at all.

5. Specialized equipment or tools: If your development environment involves specialized tools and equipment, it can impact financial feasibility and schedules; you need to think through the time it will take to create the necessary environment offshore.

6. Transfer of Information and Training: How long does it take, at what cost and whether you have personnel available to devote to this, in addition to doing their own current tasks?

7. Cultural fit (Contextual knowledge necessary); is it possible to train offshore personnel within a reasonable time frame? For example, projects that deal with user interfaces are harder to transfer because of the need to understand the cultural issues in the U.S.

8. Attracting and retaining offshore talent: If you are doing new development or you are in a hot technology area, this will work in your favour. If you are considering dated or proprietary technology with limited market appeal and/or sustaining effort, this will work against you.