Parlez-vous software development?

(continued from previous page)

Information about the capabilities, tools, and expertise of some offshore vendors is sketchy, so on-site visits (as well as references and research) are essential in selecting partners. First and foremost, potential ones should be ranked on their ability to provide all of the needed expertise. Another important consideration is whether their resources will be devoted solely to one's company, since an outsourcer that works for several clients simultaneously may require sophisticated resource- and project-management procedures it doesn't really have.

To estimate the ability of a potential offshore outsourcer to ramp up and sustain its resources, companies should therefore try to gauge its financial soundness and its history of attracting, training, and reallocating talent. Talent in some key categories will undoubtedly run short as more companies begin to use offshore partners, so only those with strong training and recruiting programs are likely to keep up with the demands of the work. Finally, a potential partner needs a good local presence near the client IT organization to communicate with it freely and to manage the project smoothly.

Once a company chooses its offshore outsourcer, it should define the required level of service on three dimensions: resources, performance incentives, and quality. The offshore outsourcer should guarantee that it will assign people with specific skills to the client company's project within, say, four weeks of the initial request, and the client should have the right to conduct regular audits of the outsourcer's project management, quality assurance, and development processes. IT service level agreements too often ignore such procedures because many companies seem to view them as more trouble than they are worth, but in the absence of an audit, a company whose relations with its partner are deteriorating may be unable to diagnose the problem.

The next steps
Next, the client company should develop a performance-based incentive structure that might include metrics such as the number of bugs for each 100,000 lines of code, the percentage of code accepted after its first test by the user, and adherence to schedule and price agreements. Finally, there should be clear definitions of success and failure on both sides of the partnership, with defined processes for raising or lowering the level of collaboration between them. Carefully worded exit clauses that address the responsibility for documentation, for the transfer of knowledge, and for intellectual-property rights are important as well.

The choice of one vendor over another shouldn't depend on price, but both parties ought to accept certain clear pricing principles. Companies should lock in per-diem rates for each category of developer that a project will require for the duration of the contract. Those rates, as well as the cost of the entire project, ought to be monitored over time so that the benefits of improved efficiencies at the offshore outsourcer flow to the contracting company. (In the automobile industry, for instance, original-equipment manufacturers get better prices every year thanks to the improved processes of their component vendors.)

It makes sense to work out a project schedule that moves a company's less critical projects off-shore first. Support projects lend themselves well to building confidence; only after a few of them have been carried out successfully should companies entrust development work to an offshore outsourcer--and, even then, it is wise to start with work that isn't critically important. In many instances, companies ask outsourcers with whom they are building relationships to initiate development projects at their own sites; once confidence is established, the projects move offshore.

Keeping tabs on the project
Old hands at outsourcing have found that client companies can best manage their offshore projects by appointing a project manager who works with each offshore development team to provide technical oversight and links to the client's business units.

The manager also serves as a troubleshooter, ensures that the offshore developer makes steady progress and works efficiently, and facilitates the execution of the project--for instance, by setting up user groups to test the software, easing communication with the leaders of business units, and arranging for company-specific documentation. This decentralized approach to development promotes collaboration between the offshore outsourcer and the business units' in-house software architects, who have deep technical knowledge. Nonetheless, a central management office is typically needed to manage the offshore relationship as a whole; otherwise, an excess of contact points with the offshore developer will probably give rise to misunderstandings and, often, to higher costs or missed deadlines.

Coordination becomes an important issue for companies that are developing several projects simultaneously with one or more outsourcers. For instance, a Fortune 500 company that had four separate business units and four different outsourcing-management organizations quickly came to the realization that it was duplicating many activities and failing to reap sufficient economies of scale. According to the company's CIO, "Once we realized that the resources that these vendors were demanding from us were very similar, we decided to streamline the management of our offshore efforts through a central organization for the whole company, without sacrificing our speed of development."

Communication can pose a challenge even with a single project, however. One reason is a mismatch between the IT capabilities of client companies and those of their offshore outsourcers, which now actually tend to have higher qualifications. Another is that the client company's project managers have less physical interaction with an outsourcer's developers than with in-house employees. Most of the companies that have successfully outsourced their projects require offshore suppliers to install 24-hour progress-monitoring systems that give them constant access to the work, generally through Internet-based electronic databases that are updated as projects are completed. In addition, the client should have access to the files and the code under development, so that the offshore vendor has a real responsibility for ensuring that the tracking tools adequately represent the status of a project at any given time.

Sometimes more is needed, even with trusted offshore outsourcers. A retail point-of-sale software company, which found that its chosen outsourcing partner had developed poor prototypes, decided that it would improve communication by having a small team from its outsourcer rotate between its own U.S. facility and the outsourcer's home location. The client company found that although bringing offshore developers to the United States was expensive, the improved transfer of knowledge soon paid off, and the overall costs of the project were still a good deal lower than they would have been with any other option.

Finally, a client company should make every effort to ensure that its in-house staff stays up to speed technically with its offshore vendors so that it doesn't become entirely dependent on their assistance. Such dependence can be very costly indeed.

A financial-services company we encountered in our work found itself almost held hostage by its offshore vendor: no one in the client company had supported one of its legacy systems for three long years, which meant that it had no substantial knowledge of this system and thus simply couldn't switch vendors. As a result, the company was unable to negotiate a favorable deal with its current vendor, which was in a position to charge $1 million more than any competitor would have done for similar work--on a contract that totaled only $3 million to $4 million. The client company escaped from this trap only when it finally replaced the legacy system in question.

It can be very fruitful to maintain long-term partnerships--but not too many partnerships simultaneously: economies of scale in infrastructure costs and in the time needed to transfer knowledge can be achieved with just a few such partnerships. Whatever relationship model a company chooses, it should maintain its ties with other vendors so that they can serve as backups for local or highly specialized work or in the event of emergency development efforts.

The offshore outsourcing of software development is an increasingly important strategic option. Any company that considers the idea of establishing strategic offshore partnerships must have a thorough understanding of their benefits and risks, as well as a strong management plan. Companies that do outsource will find that offshore development firms are more and more capable of providing high-quality service, quick turnarounds, and big cost savings.

For more insight, go to the McKinsey Quarterly Web site.

Copyright © 1992-2001 McKinsey & Company, Inc.