Does IT outsourcing actually work?

-a view from the trenches

Stephen Turbek

13 April 2005

The goal of this essay is to educate business and technology leaders to make planning decisions. Even if your company has chosen to outsource development, project management decisions can determine the success or failure of the project.

Why don't we know?

The discussion of IT outsourcing has been dominated by the advertisements of the companies selling it and the concerns of US workers. Less discussed is whether it makes sense for a US company to actually outsource major software projects. As with most IT projects, Return On Investment is much discussed, but rarely calculated. In part, this is due to the difficulty of separating structural changes from product offering changes and the ebb and flow of commerce cycles. However few executives want to document how much a project really cost and what it is really delivering. Many of the waves of software integration "knowledge management", intranets, "expert systems" are driven more by buzzword trends rather than careful ROI analysis.

In too many outsourced "development" (code writing) projects, the practical inefficiencies contradict the rosy picture of cost savings. "It just has to be cheaper" is a common sentiment, one that needs to be investigated for your requirements. Lest you be concerned that this is some anti-globalization screed, many of the issues raised here happen with domestic third party development firms, however the scale of the problems is greater with foreign outsourcing. Modern domestic IT consulting simply has a more efficient process: "Integrated Design & Development". IDD means that the programmer or his manager is involved in the design meetings, and codes alongside the documentation. This enables the design team to evaluate the final product faster, while they still remember the details, make quick changes, and be warned when something cannot be built.

It remains to be seen whether outsourcing will continue to grow as a major factor in IT development or will carve out a niche for itself for the tasks it is best suited at. The danger for companies is that they will outsource a project as "everyone is doing it" before finding out whether their competitors are actually happy with the results. As we shall see, a large project undertaken should not be mistaken for a successful result.

Moreover, companies are increasingly dissatisfied with the practical realities of outsourcing. A recent survey by Bain & Co, a firm of consultants, found that a hefty 82% of large firms in Europe, Asia and North America are today using outsourcing firms, and 51% are outsourcing offshore. But almost half say that their outsourcing does not meet their expectations. ^1[1]

A typical example

A critical infrastructure project was undertaken by a Fortune 100 banking corporation. The project was researched, scoped, and designed in the United States. The development was by an major Asian outsourcing company with which the corporation had a relationship. The project was developed on a well known middleware software application platform chosen by the corporation.

The project was divided into segments and sub segments, each with a project team. An overarching project management committee provided regular reviews and checkpoints. Business and technology leaders formed a "gatekeeper" council that reviewed all the project functional specification documents that went to the outsourcing company. Each project team consisted of a business representative, who represented the business logic; a business analyst consultant, who wrote the business logic; a technology analyst consultant, who represented the middleware software maker and answered feasibility questions; a usability & visual design consultant, who advised on those subjects and created screen images; a technical writer who wrote the functional specification; a project manager who husbanded the functional specification through; and a manager representing the programming team from the outsourcing company.

It is clear that the technologist is a small part of the whole team. Note that in an Integrated Design and Development team, the technologist would replace both the middleware representative and the outsourcing manager.

The project team documented what was needed to be built in a very detailed "Functional Specification". This was sent to the outsourcing company and the software was written in the software application framework. It was then tested by the banking companies testing unit, revisions were noted and sent back, to a final approval and release. The communication difficulties, detailed later, mean that the savings of the technologists salary are more than offset by having this team of senior employees write this tremendous document and wait for it to be implemented.

Though all the actors were competent, the design and development process restricted them from delivering the project effectively. The project is way behind schedule, over budget and in danger of being cancelled.

What went wrong?

As is common, decisions made before project started caused it to under-perform expectations of time and costs.

• Choices in the software development platform proved to be restricting.
• Design and development project planning was optimistic.
• Project segmentation (how the project was scoped into manageable parts) was inefficient.
• The largest issue, however was the unexpected costs and delays due to outsourcing the development.

Let's look at the factors of a large project that could not be solved though lower cost implementation.

Technology

Hardware and middleware costs, a significant portion of any IT project, remain. In fact, your software license agreement may not cover developers who work for another company. A separate development server, and possibly other software licenses may be required. As you will not give these other employees full access to your corporate infrastructure, you will require sophisticated security management.

Consultants

If you have dispensed with the senior technologists who will guide the day to day decisions during development, you will need to rely on consultants happily supplied by your middleware provider (at some cost).

The many small but crucial questions with making imperfect middleware software platforms work will be performed by these consultants. A common misunderstanding is that the developers at many of the outsourcing firms are not computer science majors, rather they have passed some certification in middleware software course. This enables them to "drag and drop" pre-built functionality, but does not equip them to solve your specific problems.

These teams of lower level developers need to be managed and the project design goals need to be communicated from the design team. In order for this to work, a manager typically come to the United States to work with your project team to learn a particular segment, then goes back and manages their team. Obviously there are costs with flying people across the world and putting them up in a hotel for months. Note that there are often visa complications and lawyer fees associated with them. Flying them in on a tourist visa is illegal, but many of your project team managers will be tempted to do this to expedite their projects, whether the project management knows about it or not.

Almost three-quarters of companies questioned experienced significant problems with outsourcing projects and a quarter had brought functions back in-house, the study by Deloitte Consulting found.[2]

Project management

As with all projects, the management determines the success or failure of the project. The stakes are much higher in outsourced projects as problems are harder to discover and harder to correct quickly. The single biggest flaw of outsourced projects is the failure to budget and schedule outsourced development as taking longer than in house development. A second review cycle is often omitted from internal projects, with out sourced projects it is a minimum. This is not to say that the quality of work is poor, rather that communication is inefficient. The simple problem of a 12 hour difference in time-zones causes there to be a day-long delay in email correspondence.

One can outsource the development, but you cannot outsource the design of you company. Your "core competencies", that with differentiates you from your competitors cannot be delegated. This requires you to maintain a fairly large staff to represent your interests in the development of the functionality of the application. Your company still needs to research and describe the business logic, form a strategy, evaluate discrepancies in business processes that are discovered. These tasks and the resulting documentation are a significant part of the development process.

The myth that "We come up with the idea, they build it" unfortunately obscures the essential link between design and development. Development IS design on most projects, just as "most writing is re-writing".

As a contracting company, the outsourcing companies are under pressure to deliver quickly. However, due to the difficulties in communication, the development team will rarely ask questions to clarify details. All to often, faced with incomplete information, the developer will guess, and not note that they have made an assumption, as that shows inability.

The cumulative effect of this is for your project team to be unpleasantly surprised with the difference between what they specified in their incredibly detailed document and what they received. Worse still, may be the loss of critical business logic, invisible to all but the closest code readers. If you want to prevent customers from purchasing incompatible products, or apply discounts to only selected customers, the rational needs to be defined in every case.

The question that needs to be determined in every outsourced project is whether the money saved by outsourcing the relatively low cost programmers is outweighs the cost of your high level managers write documents enormous documentation for them and then review their work. In a sense, it replicates the old question of whether it is better to have secretaries or have your executives muddle though making font choices on power point slides.

In any large organization, it is difficult enough to retain the institution memory with employee turnover. This is accelerated when the information is compiled, edited and used by temporary workers. All clients have assurances of non-disclosure, but they should be wary of opening their critical systems. The risk for corporate espionage is just too great.

Communication

Software development is a difficult task with many, many details that could each cause a project to fail. In order to communicate the "core knowledge" that your company takes for granted, serious (and costly) effort must be made. All of the required institutional knowledge must be documented in tremendous "functional requirement" documents, case by case descriptions of what needs to happen in all situations, with all the exceptions and restrictions. A typical document comes to over 500 pages for basic functionality and this must leave out some detail.

As one technical manager said " I could code this feature faster than I can describe it".

Like playing the game of "Telephone" details get lost each time information is handed off. By separating the end programmer from the design team the project makes itself vulnerable to costly mistakes.

Also note that these Functional Specifications are essentially Statement Of Work documents, which will be cited in disputes with the outsourcing company. Do not expect your outsource employees to be generous when it comes to "figuring out the details" - a common error of the design staff.

Cultural differences do exists and effect the project more than you might suspect. Many of the outsourcing employees are the hardworking and friendly employees one would hope to have. However, one should not simply expect workers in other countries to replicate your relatively homogonous coworkers. Cultural knowledge about financial and holiday customs does underpin many business decisions. Knowing that IRA contributions can be made up to the tax deadline of the next year is a small example of something that an American banker would take for granted. All this can be learned, but it slows development and increases errors.

Welcome to 1995

The effect of these problems is to take application development back 10 years. The recent productivity increases are the steady accumulation of sophisticated project management techniques as the industry matures. "Integrated Design & Development" is how successful projects are built by modern companies. We have learned that large projects that are scoped and "thrown over the cubicle wall" are destined to fail, or be more expensive.

Unfortunately, this is exactly what an outsourced IT project entails. The outsource feedback loop is unworkably long, as the project manager flies home after months in the States, the project is staffed, the application is built, and delivered for review. You have the option of having your staff wait around, or move on to another project, either compromising quality or speed.

The Integrated development process, where the developers are present during the design to head off unbuildable ideas is now commonplace. Outsourcing misses the second, equally important part: having the design team be a part of the development process as design continues as inconsistencies are discovered. Small, focused teams who merge design and development will end up being more cost effective, no matter what the hourly rate.

To conclude, projects that require defined scheduling and cost control may find that outsourcing the development adds an uncomfortable amount of delay and uncertainty. The common promotion that "they could do it three times for the cost of a local team doing it once" is unfortunately all too prophetic.