dcsimg

Achieving Offshoring Success

By Linda Belhoucine

(Back to article)

What can an organization expect by taking development offshore? The simple answer is not only cost savings, but the possibility of riskier projects. A rather straightforward project executed offshore is simply more complicated than the same project executed locally.

The cost savings may also not be as dramatic as they first appear. For example, if you estimate your project at 2000 hours locally, assuming $50/hour, you can be sure that the offshore version will not be 2000 hours at $25/hour. You need to account for distribution cost, which is the cost of effort required by the simple fact that your project is now distributed, plus the cost associated with the added complexity of your project.

Best practices, however, do exist for offshore development -- and software development in general -- and have proven that, coupled with a collaborative, open environment, a successful offshore project can become a reality.

There are many papers about offshore development, listing challenges such as reduced opportunities for communication, decreased visibility into project progress, misaligned expectations, et al.

The same challenges exist on troubled projects where all the players are in the same location. This suggests that they must be due to something beyond the geographical distribution. The fact that a project is distributed is only another aspect that needs to be taken into consideration when structuring the project. An organization contemplating offshore development must first look at their local successes.

If you are dealing with challenged projects locally then offshore development isn't going to be an exception. You can expect the same challenges, if not more. But, if you are successful with your local projects, your chances of succeeding in a distributed environment are greater (although not guaranteed). Your first step must be the conscious design of an appropriate structure and approach for the project.

Offshore projects are more demanding in terms of collaboration, communication, expectation management and real-time, accurate progress tracking. Therefore, the mechanics and dynamics used on local projects will have to be adjusted to handle the time, culture and language differences.

The following best practices contribute greatly to fostering the appropriate collaboration and to mitigating the distribution challenges.

Distributed project management and quality assurance. Avoid locating project management and quality assurance on one site only. The cost savings are not worth the risks that are introduced by such an option.

The main rule is that each site requires one contact point responsible for the integrity of the overall project vision as progress is made. They are the coordinators across sites when the big picture is impacted and they are the local managers as local activities are carried out; the glue for their respective local teams and the driving force behind the global team dynamic.

Complimentary distribution of competencies when such distribution is required. Distributed project management and quality assurance are examples of necessary distribution of competencies. Project complexity may also require distribution of analysis and/or development competencies. Competency distribution comes with a price as your collaboration and coordination efforts become even more complex and demanding.

Complimentary distribution reduces, even eliminates, unnecessary complexity. Two individuals conducting the same task at different locations will require more collaboration than two individuals conducting complementary tasks and sharing competency understanding.

Localized elicitation process. Remote elicitation is costly and risky. Non-verbal communication is key to elicitation, therefore phone, e-mail, and even video conferencing will never be as effective for such activities as an in-person meeting.

A perfect example is the requirements gathering phase. Domain experts with deep understanding of the business and analysts with deep understanding of the development process must collaborate and use their respective competencies to develop the functional requirements. Remote execution of this collaborative effort will not only take longer, but will reduce the quality of the requirements.

Local autonomy and global alignment. The three best practices above should be considered the building blocks for local autonomy and global alignment. On a local project, the teams rally around the project vision and then each competency drives toward that vision on a daily basis. The integrity of the vision throughout the project execution ensures alignment as the project progresses.

Local autonomy is not optional in a distributed project; any expectation of remote individuals influencing local activities on a daily basis is wrong. Local and daily activities are best assessed and influenced by local individuals while the remote contribution is one that serves to build understanding for the needs of the remote team.

Depending on the project complexity and your success with local development, the result may be that it will be cheaper to keep your project local. In the end, the best advice is to go through the exercise and decide what kind of cost savings will be worth the added distribution risk.

Lynda Belhoucine is a project manager at ThoughtWorks, a global IT professional services firm. For more information about software development best practices, you can reach Lynda at lbelhoucine@thoughtworks.com or visit www.thoughtworks.com.