In-house Outsourced offshore
Figure 1.5 Offshoring by phase of the software life cycle.
Source: Software Development Magazine, 2004.14
Survey results of US development managers/engineers in projects that were already partially or
fully offshored. Numbers do not add to 100 because the activity could be both in-house and
offshore and because some projects did not use some phases.
The best method for analyzing which activities are suitable for offshoring is to use the
software development life cycle. This was the approach taken in a survey conducted by an
American trade magazine that is depicted in Figure 1.5. The survey results show that
activities offshored most often were coding, testing, and maintenance; while those that
were least offshored were business integration, architecture, and requirements gathering.
This is a picture of two clusters: activities that are frequently offshored and those
that are not. This clustering is essentially the split offshore migration that was described
earlier in the chapter (Figure 1.2), in the forecasted separation between design and devel-
opment. Recall that the chart forecasted that development (such as coding) would move
offshore faster than design (where the word design was used broadly to include any
high-level activity including architecture). The survey results are consistent with the styl-
ized depiction of the life cycle in Figure 1.6, applied to offshore and onshore.
Let us take a closer look at these two clusters to see what differentiates them from
one another. First, activities offshored are those which: are standardized (commoditized),
can be precisely de´¬üned (precisely speci´¬üed), and may even be considered tedious, repet-
itive, and undesirable. Hence, coding and maintenance, which can be well de´¬üned, are
Activities that tend to stay onshore are those which require customer interaction,
customer proximity, deep domain knowledge, and deep cultural knowledge. Thus,
15 The offshore landscape
Figure 1.6 Common division of onshore/offshore phases.
requirements gathering activities, early in the development cycle, are conducted onshore
because of the need to be close to customers; that is, to meet with them and talk to them
in their own language. At the end of the development cycle comes systems integration
(also labeled ÔÇťdeploymentÔÇŁ), where the software pieces are sewn together; this is dif´¬ücult
to do from afar.
Two phases appear as both onshore and offshore in Figure 1.6: design and testing.
High-level design is often done onshore while lower-level design is offshored. Testing, a
largely tedious task, is offshored in part. Unit testing can easily be done offshore. Some
testing activities, such as systems testing, have remained onshore, because they are
better performed together with other integration/deployment tasks. Separately, for con-
trol reasons, managers keep later testing phases onshore in order to monitor quality.
Some important IT activities are not depicted in Figure 1.6: data center management
and a variety of managed services, such as network services and support. Generally,
these have not been offshored since they require some proximity. Furthermore, there
are business continuity risks in moving such services offshore.
The ´¬ünal differentiation between the two clusters is competitiveness. Companies
tend to keep ÔÇťhigh-endÔÇŁ activities at home (onshore) to maintain their competitiveness.
These tasks are more likely to be creative, innovative, and research oriented, or they
require very broad knowledge and experience. For example, architecture (systems archi-
tecture or product architecture) ´¬üts all of these criteria and is kept onshore as shown in
Companies give these competitive activities many labels namely, core activities,
proprietary activities, the most sensitive activities, the leading product design, and the
companyÔÇ™s competitive edge. Most IT applications at end-user ´¬ürms (e.g. a bank) involve
few activities which are proprietary and therefore such companies are not hesitant to
offshore. The picture is different, at least in theory, for a software product company: its
software code is its ÔÇťcrown jewel.ÔÇŁ Any company should carefully weigh allowing
16 The fundamentals
an outsider access to its crown jewels. Yet even among software product ´¬ürms that per-
form R&D there is signi´¬ücant offshoring. An estimated 5ÔÇ“15% of American software
product R&D is offshored, forecast to rise by 2007/2008 to 25ÔÇ“30%.15 And some of
the companies which are offshoring software product R&D are the largest US technol-
ogy ´¬ürms. Yet, this is a risk that they have presumably considered carefully. We return
to discuss this topic in Chapter 5, Offshore Strategy.
Quality, processes, and methodologies
Until the 1960s, Japan was known as a destination for cheap, low-quality
manufactured goods. ÔÇťMade in JapanÔÇŁ was a derogatory term. Beginning in
the 1950s, the Japanese began to implement quality production processes from
abroad and re-invented their production culture. Within a relatively short
period, Japan became known as a source for high-quality manufacturing.
This is an example of history repeating itself. Until about 1990 IndiaÔÇ™s reputation was for
shoddy products. The Indian offshore providers recognized early that by attaining high-
quality development processes (CMM, ISO 9001, and Six Sigma) they could achieve
two important goals: they could overcome some of the dif´¬üculties of working over dis-
tance, and, perhaps more important for the nascent Indian industry, they could signal to
potential customers that they were world-class companies worthy of their business.
The Indian organizationsÔÇ™ success in this regard is remarkable. The very ´¬ürst organiza-
tion in the world to attain the highest-level software process maturity rating, the CMM
Level 5, was IndiaÔÇ™s Motorola unit in 1993. Since then many other Indian ´¬ürms have
adapted this standard. By 2001, 32 organizations with CMM Level 5 were in India. By
2003, there were over 65 Indian organizations that attained CMM Level 5 (including
both Indian ´¬ürms and foreign multinational subsidiaries), representing more than half
of all organizations in the world at that highest level. The outcomes of all these efforts
have been impressive: a 2003 survey among US offshore users found that 71% of the
users stated ÔÇťthat offshore suppliers delivered somewhat better- or much-better-quality
workÔÇŁ compared to their US-based counterparts.16
By the early 2000s, offshore units in nations that compete with India, namely China
and Russia, began to emulate the Indian sectorÔÇ™s successes in this area. RussiaÔÇ™s Luxoft
attained CMM Level 5 in 2003, while two Chinese organizations attained Level 5
CMM and its newer cousin CMM-I, both came out of the US Software Engineering
Institute to impose structured, standardized development processes that are repeatable,
planned, and optimized. The advantages of these process improvements are error rate
reductions and cost savings. Moreover when working across distance, these processes
17 The offshore landscape
reduce the communication dif´¬üculties by structuring the development process ÔÇ“ by
introducing standard approaches that reduce the need for explicit coordination.
Nevertheless, several issues need to be noted about the promise of structured
approaches in general, and CMM in particular. CMM cannot address many of the off-
shore challenges that were described earlier in this chapter. Furthermore, the ´¬üxation on
CMM Level 5 is misguided: CMM Level 3 is considered suf´¬ücient for most software
development activities (CMM Level 5 was designed to satisfy large American defense
contractors and NASA). Finally, the hoopla around CMM generated by the Indian suc-
cess has created an environment of exaggeration and fraud. A 2004 CIO magazine17
expos├© documented this landscape: some offshore providers misrepresent their CMM
rating and others have not ÔÇťrenewedÔÇŁ their ratings in years since there is no requirement
for such renewals.
National differences in software abilities
When in a comfortable private setting, executive decision-makers ask the following
questions: Are the programmers in Country A better than the programmers in Country
B? Do the engineers of Country C have a better work ethics than those of Country D?
Are the ´¬ürms in Country E more sophisticated than those in Country F?
These are important questions. No one has answered them properly. And it is unlikely
that anyone will, in part because of the extreme political sensitivity of giving a country
a failing grade. Furthermore, comparative studies are likely to be fraught with sample
biases. Project outcomes are often mixed and depend on many factors including short-
comings of the client. We found an American software manager that set out to answer
the ÔÇťwhich country is better for usÔÇŁ question on his own, using an interesting approach.
His small software ´¬ürm set out to contract an identical pilot project to three providers,
one each in India, China, and Russia. Once the pilot projects were complete the ´¬ürm
chose the winner. The case appears in Chapter 4.
An important study was conducted by Cusumano and colleagues18 using data col-
lected in 2001ÔÇ“2002. The study compared best practices of ´¬ürms in Europe, Japan,
USA, and India (most were technology ´¬ürms). The eleven best practices included: archi-
tecture speci´¬ücations, code generation, code reviews, sub-cycles, pair programming,
and daily builds. The researchers concluded that IndiaÔÇ™s stated strengths in processes
and best practices are correct, namely, that Indian ´¬ürms were combining disciplined
approaches such as architectural speci´¬ücation, code and design reviews, with more ´¬‚ex-
ible approaches. The study also noted continued software strengths in Japan. Separately,
the study authors made an interesting observation in their conclusions, writing that ÔÇťÔÇ¦
no Indian or Japanese company has yet to make any real global mark in widely-
recognized software innovation, which has long been the provenance of US and a
few European software ´¬ürms.ÔÇŁ
18 The fundamentals
The demand for offshore work
In the next two sections we examine the two sides of the offshoring equation: the
demand (answering the question: who are the customers?) and then later the supply
(answering the question: who are the providers?). The global context of demand and
supply is presented in Table 1.2.
On the demand side we begin with a few broad observations before looking at spe-
ci´¬üc geographic regions:
Ô—Ć Geography. The most aggressive offshore consumers are in the US. Within
Europe, the UK has been the most active in offshoring.
Ô—Ć Industry. Among the end-user industries, the most active in offshoring are ´¬ünancial
services (banks, investment ´¬ürms, and insurance) and technology ´¬ürms (software,
hardware, and telecommunications).21
Ô—Ć Company size. Companies that offshore are generally the larger ´¬ürms, with the
largest global corporations, such as GE, American Express, and British Telecom
having taken the lead. The vast majority of small- and medium-sized ´¬ürms (SMEs)
do not offshore, with the exception of technology ´¬ürms.
Ô—Ć Motivation. Cost savings has always been the dominant driver for offshoring in
both Europe and America, except for the short period in the late 1990s, when labor
Table 1.2 Selected ´¬ügures and estimates on market sizes
Data for 2003 Forecast for 2008
Global market of IT services 536 billion USD growing N/A
(Source: Gartner) at 6.2%
Global market of IT-enabled 405 billion USD, growing 680 billion USD
services at 8%
Indian IT services providers Growth of 29% for the year, N/A
(Source: Gartner) though Indian providers represent
only 1.4% of global market
Foreign R&D subsidiaries India: 77 global software product N/A
´¬ürms.19 China: 223 technology
Indian R&D sourcing 1.3 billion USD 9.1 billion USD
(Source: Frost & Sullivan)
Global [offshore] sourcing 10 billion USD. Total savings 21 billion USD. Total
of software and services from offshoring by US savings from offshoring by
(Source: ITAA) corporations was 6.7 billion USD US corporations will be
31 billion USD
19 The offshore landscape
markets were very tight due to the technology boom, the Y2K remediation efforts,
and the euro currency conversion.
The largest market for offshoring is the US. This should not be surprising given that the
US has long maintained leadership in the software industry through its clusters of
innovation, such as Silicon Valley, its catalyst role on the internet, and its powerful
global corporations. The largest of these corporations, IBM, may qualify as the ÔÇťFatherÔÇŁ
of globalized software development. In the 1960s and 1970s, IBM, then the most
powerful computer ´¬ürm in the world, and always among the top 10 largest US corpo-
rations, had R&D centers in three countries with development centers in some addi-
tional European nations (see Figure 1.7). No company came close to this global network
for many decades.
In 2003, global sourcing of computer software and services was estimated at 10 billion
USD, which represents but a small portion of total US corporate spending on IT. Of
the 10 billion USD in global sourcing, the US purchases have generally represented
two-thirds. This ratio will probably remain steady for some years, though the amount
in dollars will continue to rise at double-digit rates.
Thomas J. Watson Research Center
(Westchester County, NY and Zurich Research Laboratory (Rueschlikon, Switzerland)
Cambridge, MA, USA) Established in 1956
Established in 1961
Almaden Research Center
Haifa Research Laboratory (Haifa, Israel)
(San Jose, CA, USA)
Established in 1972
Established in 1955
Figure 1.7 IBMÔÇ™s early global network of R&D sites, circa 1970.
20 The fundamentals
Table 1.3 Selected US software ´¬ürmsÔÇ™ offshore activities
Cadence Cadence is the largest semiconductor design software ´¬ürm. The ´¬ürm opened an India
R&D center in 1987 where its staff reached 300 developers by 2004. It also had
development centers in Taiwan, China, and Russia22
Google In 2004, search engine company Google was viewed as one of the most innovative
American tech ´¬ürms and its public offering of stock was closely watched. Google
stated that it could afford to hire the best developers in the US, but chose to open
an R&D center in India to attract creative talent
I2 I2 develops logistics software for business customers. In 2004 the ´¬ürm had
1400 engineers outside the US, mostly in India, representing about half of the ´¬ürmÔÇ™s
global employees. The Indian staff included about 180 staffers of Indian origin who
were previously working in the US and volunteered to go back to India23
Microsoft Microsoft has traditionally been cautious about dispersion of its R&D, with nearly
all activities at its Redmond headquarters. Its four foreign centers, India, China,
Israel, and England, were set up in 1990s. Growth since 2000 has been primarily in
India and China. The ´¬ürm had roughly 300 employees in its Hyderabad (India)
locations scheduled to double within 2 years
Oracle Oracle began offshoring in 1990. By 2003, its Indian centers grew to 3000 developers
with a stated goal of doubling to 6000. Oracle also performs offshore R&D in Ireland
The offshore spending is disproportionately concentrated in larger ´¬ürms, particularly
in ´¬ünancial services. But even among the largest ´¬ürms, only a minority is actively off-
shoring. Estimates regarding offshoring from the largest US ´¬ürms, the Fortune 1000, sum-
marized in Table 1.1, indicate that in 2004 only about 10% of these US ´¬ürms were past
the experimental stage of offshoring in which more than 10% of their budgets were
devoted to offshoring.
The landscape is quite different for American technology ´¬ürms. All the top 20 US
technology ´¬ürms perform at least some offshore software work. Furthermore, at all sizes
(small, medium, and large) high-tech ´¬ürms that are offshoring are much more prevalent
than for non-tech ´¬ürms. Table 1.3 presents a sampling of some US technology ´¬ürmsÔÇ™
Europe has been slower than the US in offshoring IT, even though the cost advantages