Offshoring: what can go wrong?

July ❘ August 2005 IT Pro 39

Offshoring:What Can Go Wrong?Norman Matloff

C omedian Woody Allensaid, “Eighty percentof success is showingup.” On the topic of

offshoring, thatsays it all.Humanswork best inphysical proxim-ity to each other.Yet today,globaldifferentials inpay rates makeit tempting forcompanies toemploy peo-ple working

tens of thousands of miles fromthe home base—a client in theUS offshoring IT work to a ven-dor in India or China, for exam-ple. Can it be done well?

Offshoring has recently sus-tained much criticism, mainlyover the issue of whether ship-ping IT work abroad is good forthe US as a whole. I have writ-ten in that context as well, butmy focus here is at the companylevel. Does it benefit a US firm

to offshore its IT work—specif-ically software developmentand maintenance? I’ll discussseveral reasons for firms to bewary of this practice. For somemanagers, these considerationsmight tip the balance againstoffshoring. For those who wishto offshore anyway, this articlecan serve as a map of the pitfallsto try to avoid.

THE VALUE OF FACE TIME

Proponents of offshoringblithely say that companies canovercome any geographicalobstacles by using the propertools. But no matter howadvanced your telecommunica-tions tools are—videoconfer-encing, software for managingcollaborative development, andso on—it’s still not the same asbeing there.

Indeed, the work models ofvendors from India illustratethis point.Although the bulk of

Distance, cultural differences, inexperienced programmers, andother obstacles mightmake you wish you’dkept that IT project at home.

a project’s team might be inIndia, the offshore firm typicallystations some team membersonshore—that is, at the client’ssite. A University of Rochesterstudy found that the typicalratio is around one onsiteworker to every two offshoreworkers (Ron Hira, “U.S.Immigration Regulations andIndia’s Information TechnologyIndustry,” Technological Fore-casting and Social Change, vol.71, no. 8, Mar. 2005). Someonsite workers remain at theclient site for the duration ofthe project; others make tem-porary visits for training orconsultation.

Craig Hergenroether, CIO ofBarry-Wehmiller Companies, isboth a consumer and purveyorof offshore services; his US firmhas a subsidiary in India. Hisanswer to my query about theimportance of physical proxim-ity illustrates the point in moredetail:

1520-9202/05/$20.00 © 2005 IEEE

Of the all the issues in IT today, outsourcing is indisputablythe most controversial. Here, the author offers his views onwhy companies should carefully consider the choices theymake in offshoring.A professor of computer science, NormanMatloff has written widely on work visa issues and testifiedbefore the US Congress about their effects on the IT work-force.

As always, IT Pro welcomes and encourages opposing view-points; contact us at [email protected].

—Frank E. Ferrante, Editor in Chief

Inside

40 IT Pro July ❘ August 2005

... any significant project related todevelopment must be accompaniedby onsite interaction. This is truewhether it is outsourced in Chicagoor Chennai.Phone conversations arefine for straightforward conversionsor any other pure labor endeavor.When it comes to developmentwork,you must understand the stan-dards and local nuances of the client.… This interaction can take placeover several weeks and then moveback offshore. However, we havefound that the communications willdeteriorate over time if there is notperiodic face-to-face interaction.

Clearly, then, even firms that provideoffshore services believe that physi-

cal presence onsite does matter.Ed Frauenheim, a journalist who

covers the tech industry, once spent aday shadowing an engineer at aSilicon Valley company. He was sur-prised to see how much work wasdone serendipitously, in the officehallways.This should come as no sur-prise to any IT manager. Good soft-ware development requires constantinformal interaction among develop-ers and managers, the ability to godown the hall to talk face-to-face onthe spur of the moment.

Because of the time differencesbetween the US and the chief off-shoring service countries, typically thebest interaction offshoring can offeris a discussion every 24 hours via

videoconferencing; this isn’t enough.If a question arises suddenly, you waita whole day for the next meeting.Andbecause most people are much morecomfortable meeting in person,they’re more likely to ask all theirquestions and elaborate on all theissues when they’re sitting on oppo-site sides of a table, instead of oppo-site sides of the globe.

THE QUALITY GAPA key but not widely known point

about offshoring is that its typicalbusiness model minimizes costs bystaffing projects with young, inexpe-rienced programmers.The medianage of programmers in India is25.6 (En Interactive Technologies,http://www.eninteractive.com/Why+Choose+India). Youth is thesalient characteristic of the onsiteworkers as well. At giant TataConsultancy Services, headquarteredin Mumbai, India,50 percent of the H-1B visa programmers (the workerswho travel to client sites) are underage 25, and 88 percent are under 30(TCS recruiting Web page,“Why JoinTCS America,” 2004).

Arvind Thakur,president of the off-shoring firm NIIT, has explained thatthe philosophy underlying this modelis to have higher-level, more experi-enced personnel divide a program-ming project into small pieces thatless-experienced programmers caneasily handle. The simplicity of theindividual tasks is supposed to neu-tralize the programmers’ inexperi-ence. In my observation, however,projects rarely attain the ideal of theeasy pieces, leaving a programmer’srelative lack of experience toadversely affect quality.

As evidence that they can solvesuch problems, many offshoring firmsin India would point to their adher-ence to the highest standards of theCapability Maturity Model (CMM,http://www.sei.cmu.edu/cmm). ButCMM wasn’t designed as a substitutefor experience. Let’s take a closerlook.

CMM is a checkpointing system

P E R S P E C T I V E S

You might wonder whether theLinux operating system providesevidence that offshoring can payoff. I had often wondered aboutthis point myself, so I put the ques-tion to Linus Torvalds, founder ofthe Linux project.Torvalds repliedthat the two models of softwaredevelopment aren’t comparable:

I don’t think the Linux model works for offshoring in the commercial sense,or really ends up even being very relevant.The problem ends up being com-munication and the mental model pretty inherent in offshoring.

My belief is that when you say “offshoring,” you very much mean “con-trol the project on one shore; work on the other.” That is, the implication ofthe offshore work being “subservient” is very much there in the notion ofoffshoring.

In contrast, the Linux model (and open-source in general) is that there’sno one-sided control, and that when work gets done overseas, it gets donebecause it makes sense to them,not to “us.” There’s no control of one end overthe other—both shores do what they want to do.The fact that makes it all workout is that, in the end, everybody tends to have somewhat overlapping goals.

Of course, the goals don’t always overlap. Although all Linux distribu-tions use the same kernel, at least two major user interfaces have evolved—KDE and Gnome. So again, this differs greatly from the offshoring context.Another major difference is that Linux, as a noncommercial product, isdeveloped pretty much without time pressure. The next version is readywhen it’s ready. In most commercial settings, this leisurely approach wouldbe out of the question.

What about Linux?

that’s supposed to put managementof a software project on a rigorousbasis.A company can seek CMM cer-tification at quality levels up to level5—and now even beyond, with certi-fications such as the new TeamSoftware Processes assessment. TheIndian offshoring industry has madeCMM its marketing cornerstone.Currently, more than half of the firmsworldwide that are certified at CMMlevel 5 are in India.

However, most of the commotionabout CMM is misleading.The systemdoes impose a degree of discipline onthe software development process.But what companies overlook in allthe certification enthusiasm is thatCMM is simply a project manage-ment tool—not a measure of softwarequality. Even Jay Douglass, an execu-tive at the Software EngineeringInstitute (SEI) at Carnegie MellonUniversity, home of the CMM, haspointed out, “You can be a level-5organization that produces softwarethat might be garbage.”

In fact, although SEI (hardly anunbiased source) claims that level-5firms have code error rates sevenfoldlower than level-1 firms, a study of 89level-5 companies by Reasoning, asoftware quality consultancy, foundthat, on average, the code producedby level-5 firms had higher error ratesthan those of non-CMM-rated firms(Christopher Koch, “Bursting theCMM Hype,” CIO, 1 Mar. 2004,http://www.cio.com/archive/030104/cmm.html).

A quality assurance specialist for amajor US firm bluntly told me hernegative experience with trustingCMM: “We used [a major CMMlevel-5 firm] on several projects. Notone line of their code made it intoeither our test suites or finished prod-ucts.” The fact is that many expertsconsider CMM, at least at the higherlevels, to be bureaucratic overkill;software developers end up spendingfar more time on documentation thanis beneficial.

According to an article inBusinessWeek, programmers at Indian

offshoring companies tend not to beas productive as their US counterpartsat the client company (David Gumpert,“An Unseen Peril of Outsourcing,” 3Mar. 2004).The article quotes one vet-eran offshoring client as saying,“I feltwe needed one-and-a-half times theIndian programmers to do the sameamount of work as US programmers.”

Another offshoring client quoted inthe article put the ratio at about fiveor six to one (Indian to US program-mers).As an Indian-American devel-oper explained to me, it’s part of theculture: “In India, there is overman-ning wherever you go.”

The fact that the offshore program-mers tend to be rather recent gradu-ates has another implication: Newgraduates of non-US universitiesmight be “greener” than those edu-cated in the US. I asked an under-graduate exchange student of minefrom Hong Kong University—one ofthe most selective universities inAsia—to describe the differencebetween her courses there and thoseshe took this year at the University ofCalifornia, Davis. She noted that herclasses in the US involved much morediscussion, with students being askedto evaluate alternative approaches tosolving a problem.“Here [in the US],class time is much more interactive.At HKU, we just sit there.”

Though new US graduates mightnot be conversant in a wide variety ofsoftware tools, many are arguablymore ready than their offshore peersto engage in the constant decisionmaking necessary in the softwaredevelopment process. As one ethnic-Indian programmer told me, “The

American employees are moreassertive, offering solutions, moreproactive.”

Project manager Wesley Bertch,who wrote about his offshoring expe-riences for Network Computing (seethe “Further Reading” sidebar), hasalso described the consequences ofusing inexperienced programmers:

Our vendor’s employees averagedonly two years’ experience.Becauseso much was riding on this trial pro-ject, the vendor assigned us a“senior” team: The Java and JSPdevelopers each had four years ofexperience, and the tester had twoyears of experience. By compari-son, any one of our internal ...developers has more experiencethan the entire offshore team com-bined. … This development in-experience led to a series of rookieblunders.

These eventual blunders occurredeven though the offshore vendor inthat case was from the so-called tier 1group, composed of the top firms inIndia.


Another quality issueis that the clientseldom vets the

selection of the offshore

programmers.

➤ Wesley Bertch, “HowOffshore Outsourcing FailedUs,” Network Computing, 16Oct. 2003, http://www.nwc.com/showArticle.jhtml?articleID=15201900.

➤ Deloitte Consulting, LLP,“Calling a Change in theOutsourcing Market,” 19Apr. 2005.

➤ Christopher Koch, “Burstingthe CMM Hype,” CIO,1 Mar.2004, http://www.cio.com/archive/030104/cmm.html.

➤ Stephanie Overby, “TheHidden Costs of OffshoreOutsourcing,” CIO, 1 Sept.2003, http://www.cio.com/archive/090103/money.html.

Further Reading


In a 1999 article in the AmericanSociety for Engineering Education’sPrism magazine, an engineering pro-fessor in China, Chen Lixin, warned hisnation that the engineers coming out ofChinese universities weren’t good enoughto make China competitive in the global high-tech market (“Reform: China’s NewEngineering Obstacle,”http://www.prism-magazine.org/sept99/lastword.htm). Chencomplained that the Chinese educational sys-tem produces students who can’t thinkindependently or creatively, and whocan’t solve practical problems. Hewrote that the system “results in thephenomenon of high scores and lowability.”

Another offshoring quality issue isthat the client seldom vets the selec-tion of the offshore programmers.Asone US developer put it to me, at hisfirm,“we would never hire anyone like[those offshore programmers] here,but we didn’t get to do any screening.Their experience was in system inte-gration, yet they were assigned towork on our large, complex applica-tion development project.”

LANGUAGE AND CULTUREAn old story in China tells of a

Mandarin-speaking official in Beijingwho ordered a Cantonese-speakingworker to inspect some telegraph

wires.The latter thought he heard dis-mantle rather than inspect, and alas,complied. Thus the problem of lin-guistic mismatch in technology pro-jects is not a new phenomenon,though it tends to take more subtleforms today. In India, today’s domi-nant offshoring site, many peoplehave been speaking English since agefive, if not earlier. In fact,many Indianengineers put their US counterpartsto shame in terms of working vocab-ulary, richness of expression, and soon. But Indians speak their owndialect of English, with pronuncia-tions and idioms that can sometimesbaffle their coworkers in the US;imperfect audio clarity on the video-conferencing link can worsen the sit-uation. Spending some extra effort tocommunicate might not seem overlyburdensome, but some reports havedescribed language problems work-ing their way into the product or intothe code itself. In source code com-ments, the phrasing an offshore teamuses can seem odd, even downrightcryptic. This can compromise codemaintainability: a hidden cost of off-shoring that surfaces later. One frus-trated developer described offshoringa GUI project: the Chinese team thatworked on it used completely unac-ceptable phrasing, which then had to

be redone.GUI work can encounter cultural

obstacles as well. Say, for instance, aproject involves a GUI that lets a com-pany’s employees check their 401(k)accounts; this is literally a foreign con-cept to some non-US programmers.The result could be a GUI that con-sumers don’t find comfortable,or evenusable. The need to correct problemslike these is another typical hiddencost of offshoring.A client firm mightavoid such problems by providingextremely detailed specifications, butthat too would mean extra time, thusextra cost in some form.

Cultural differences can also affectthe work process. For example, thetypical US workplace informality canclash with the hierarchical structurescommon in India and China. A USprogrammer communicating directlywith her peer in India, bypassingupper management layers, mightinadvertently cause resentment.

Indian workers’ stricter observanceof workplace hierarchies can alsomake them overly reluctant toexpress their opinions; some compa-nies have reported offshore teamsfollowing a client’s program specifi-cations even though the team saw thatthe specs wouldn’t work. Similarproblems might arise in China, withits Confucian traditions of respect forauthority.

WORKING ROUND THE CLOCKAnother claimed virtue of off-

shoring is that companies can exploittime zone differences to shorten prod-uct development times.With teams inthe US and India,one group programswhile the other sleeps—such a deal!

When this works—and in somecases it does—it does indeed speed upthe development process,a major con-sideration for some customers. Thereis, however, the potential for disaster,or at least inefficiency. The situationrecalls a scene from the movie com-edy The Odd Couple, in which the twoincompatible roommates alternatelymove a chair from one room toanother and back again,each unaware


computer.org/e-News

Available for FREE to members.

Be alerted to• articles and special issues • conference news• registration deadlines

Sign Up Today for the IEEE Computer Society’se-News

Sign Up Today for the IEEE Computer Society’se-News

that he is repeatedly undoing the workof the other. This movie should berequired viewing for any IT managertempted by an offshoring firm’s claimsof a shortened product cycle. Oneunwilling “Felix Unger” described hisoffshoring experience to me:

Due to being many time zonesaway, there is no time to loop backand fix problems or make changes.If the work were onsite, one couldjust walk over and talk to the leadin five minutes. But with the devel-opers in India, every time you haveto talk, it’s another day. So, thedevelopment cycle is elongated,notcompressed. As a result of beingable to talk just once a day, theremote developers start working ontheir own, and start making poordecisions.

Indeed, if the program-around-the-clock model were so good, all USfirms would already be using it. Lotsof programmers have nighttime per-sonalities; why not assign a few ofthem to the graveyard shift and havethem alternate work with a daytimecrew? The fact that this hasn’t becomea standard model speaks volumes.

One activity that might better fit thearound-the-clock model is softwaretesting.It might make sense for testersto do their work in India while US pro-grammers sleep, providing the latterwith a new set of bugs to work on whenthey arrive at work in the morning.

INNOVATIONOffshoring boosters say,“The forté

of the US is innovation. It should con-centrate on that and offshore themundane work.” Is this a reasonableanalysis? If so, what are the implica-tions from a company’s perspective?

Technology journalist John Dvorakonce pointed out to me that therehave been no “killer apps”—daz-zlingly creative applications soft-ware—from India or China. I canthink of one exception (albeit a little-known one), the JiaJia distributedshared-memory library from the

Chinese Academy of Sciences, whichhas some nice, innovative features.Onthe whole, though, I agree with thenotion that neither country has pro-duced much interesting software.

The governments of several EastAsian countries—China (and HongKong), Japan, Korea, and Taiwan—believe that their educational systemshave traditionally stifled creativity andindependent thinking (“Roll Over,Confucius: Reforming Education inChina,” The Economist, 23 Jan. 2003).They have taken steps to reverse thepattern, but this will take decades,

especially because it is as much a cul-tural issue as an educational one.Theemphasis on authority found inConfucianism and other similar tradi-tions means that students find it diffi-cult to question first their teachers,andlater established expertise in the work-ing world; this is definitely not con-ducive to thinking outside the box.Ontop of that, the overly regimentativeCMM system has the effect of stiflinginnovation.

Accordingly, for projects in whichinnovation is important, you mightavoid sending programming work off-


A rather alarming aspect ofthe coverage of offshoring inthe popular press is that thereader rarely hears of thevested interests of some of off-shoring’s proponents.

Consider, for example, themuch-touted McKinsey study(“Offshoring: Is It a Win-WinGame?” Aug. 2003, http://www.mckinsey.com/mgi/pub-lications/win_win_game.asp).A March 2004 article in the San Francisco Chronicle noted that “an oft-cited study from consulting firm McKinsey & Co. says that every dollarUS companies spend on offshoring will return up to $1.14 to the domes-tic economy” (“Tech Association Urges Congress to Delay ProtectionistMeasures,” 24 Mar. 2004). What the article doesn’t mention is that thisconsulting firm sells offshore services.

The Information Technology Association of America (ITAA), a pow-erful industry lobbying group, commissioned a respected research firm toconduct a study of offshoring, and then widely publicized the study’s pos-itive conclusions. Yet the ITAA essentially withheld the study itself fromthe press and the public, so consumers have no idea what negative con-clusions the study’s authors might have also reached. Nor did the ITAAdisclose how the authors conducted the study, how reasonable their mod-eling assumptions were, what caveats they made, and so on.

Then there is the Capability Maturity Model itself. Because CMM is aproduct associated with Carnegie Mellon University (CMU), the studiespromoting its usefulness might seem to be free of any vested-interest bias.Sadly, nothing could be further from the truth. Research is a big profit cen-ter for enterprising “university.com” institutions. The SoftwareEngineering Institute at CMU reaps $200 million a year for conductingthese studies.

Consider the Source


shore. It isn’t enough simply to keepthe high-level software architecturaldesign onsite, having offshore teamsdo the implementation. Innovationoccurs serendipitously, with program-mers coming up with creative ideaswhile they are working on the actualdevelopment. If you don’t staff yourproject with creative programmers,you stand to lose much of your pro-ject’s potential for innovation.

Of course, the notion of culturallydetermined creativity deals with pop-ulation tendencies, not individuals.Not all US programmers are innova-tive, and many immigrant program-mers in the US are creative. Youshould hire people with a demon-strated track record of creativity—earned, perhaps, by having worked atinnovative firms or by doing somethingout of the ordinary during college.

DEVELOPING AND RETAININGGOOD ONSITE MANAGERS

Clearly, offshoring lowers themorale of your in-house program-mers, which makes it difficult for youto hire good ones. But it can hurt youat the management level as well.First,it has been traditional to “grow” ITmanagers by promoting program-mers, so that you have managers who

know your company, its products, itsclients,and so on.Obviously, the moreprogramming you move offshore, thedrier your internal managementpipeline will become. Second, man-agers of offshore projects face frus-trations and disruptions in theirfamily lives that can rapidly lead toburnout. You risk losing your bestpeople.

THE BOTTOM LINE: HOW MUCH DO YOU REALLY SAVE?

The popular press touts the fact thatIndian programmers tend to makeonly about one-tenth of US salaries,with the implication being that off-shoring will save you 90 percent ofyour project expenses. In practice, thesavings might be more like 20 to 40percent.Factors that whittle down the90 percent include

• infrastructure costs—high-speednetwork connections, videoconfer-encing software and hardware,travel between vendor and clientsites, and so on;

• higher hourly charges to the clientfor the vendor’s onsite workers;

• cost overruns due to communica-tion problems and to vendor pro-

grammers’ lower experience levels;and, of course,

• vendor markup.

The vendors themselves, and otherproponents of offshoring, agree thatactual savings to client firms are farbelow the 90 percent reported in thepopular press. Table 1 shows someactual figures with their sources.

Two of the sources listed in Table 1are particularly interesting. First,Howard Rubin’s and PatriciaJaramillo’s 44 percent savings figureis relative to hiring onsite in NewYork City, which has an extremelyhigh cost of living. They found that ifthe company had instead moved itssite upstate to Syracuse or Rochester,and employed US labor there, it couldattain savings close to those of off-shoring.

Second, the DiamondClusterInternational survey is of special rel-evance as it is more recent. It warnsthat wages in India have now risensignificantly, reducing the cost savingsattainable by offshoring. A 2004 sur-vey conducted by the Gartner Groupfound that 18 percent of the firms sur-veyed had attained no savings at allby offshoring, and 9 percent had actu-ally experienced an increase in costs


Table 1. Actual reported savings from offshoring.

Savingspercentage Source Web site

10 to 44 Howard A. Rubin and “Outsourcing: An Analysis of the Current State of Offshore Outsourcing Patricia Jaramillo in New York City Based Companies,” New Jobs for New York, 2004,

http://www.newjobsforny.org/OutsourcingReport.php

15 to 40 Sand Hill Group http://www.sandhill.com

20 to 40 CIO magazine “The Hidden Costs of Offshore Outsourcing,” 1 Sept. 2003; Stephanie Overby, http://www.cio.com/archive/090103/money.html

25 to 50 Gartner Group Ed Parry, “Gartner: Offshore Outsourcing Horse Has ‘Left the Barn,’” 8 Jul. 2003, SearchCIO.com; http://searchcio.techtarget.com/qna/0,289202,sid19_gci913695,00.html.

10 to 20 DiamondCluster “India’s Salary Growth Threatens Outsourcing,” Mike Yamamoto, ZDNetUK,International 4 June 2004; http://insight.zdnet.co.uk/specials/outsourcing/

0,39026381,39150917,00.htm.

(“Sending Jobs Overseas Isn’t AlwaysWorth It,” Los Angeles Times, 11 Apr.2004).

HOW TO OFFSHORE IF YOUMUST

If you still wish to move part or allof your software work abroad, hereare some points to keep in mind:

• Expect only modest cost savings.• Decide how important US worker

retention is to your business.• Keep creative work in house—from

top to bottom,not just architecturaldesign.

• Write your product specificationsin extremely fine detail.

• At the beginning of the project,hirea consultant who can warn youabout avoidable language and cul-tural problems.

• Insist on having detailed résumés

on all overseas workers; if possible,interview each one via videocon-ference.

• Retain an onsite vendor liaison forthe project’s duration. Even withthe extra expense, this will make lifeeasier for your managers and avoidcostly mistakes and delays.

• Encourage the offshore team to beupfront with you regarding poten-tial problems with specs and designissues.

• Take a hard look at intellectualproperty issues, especially for yourcore business products.

The last section’s title alludes to aclassic book on probability (Howto Gamble If You Must:

Inequalities for Stochastic Processes,McGraw-Hill, 1965) by Lester Dubins,former professor of statistics at the

University of California, Berkeley. Ihope I have raised enough concerns inthis article to justify the casinometaphor.There are some winners, butmany losers—78 percent of the firms sur-veyed by DiamondCluster decided to endtheir outsourcing projects early.However,proper management shouldincrease your odds of winning. ■

Norman Matloff is a professor of com-puter science and a former softwaredeveloper in industry.He has also writ-ten extensively on IT labor issues.Con-tact him at [email protected].

For further information on this or anyother computing topic, visit our Digi-tal Library at http://www.computer.org/publications/dlib.


computer.org/join/Complete the online application and

• Take Web-based training courses in technical areas for free

• Receive substantial discounts for our software development professional certification program

• Get immediate online access to Computer

• Subscribe to our new publication, IEEE Security & Privacy, or any of our 22 periodicals at discounted rates

• Attend leading conferences at member prices

• Sign up for a free e-mail alias—[email protected]

Join the IEEE Computer Society online at

T H E W O R L D ' S C O M P U T E R S O C I E T Y

Documents

Offshoring: what can go wrong?