You are on page 1of 3

Phil Ulrich

CSC 640, Spring '08


Final Paper (New Fallacy)

Fallacy: Offshoring some or all development work to outside companies is a guaranteed cost-
saving measure for American corporations.
Discussion

Outsourcing of software development work is a trend that has existed since at least the 1990s. It first
blew up into a major issue, however, in 2002[1], and a debate over its effectiveness as a cost-cutting
measure has continued ever since. There are other reasons cited for outsourcing work, such as:
unresponsive IT/IS departments, restructuring purposes, access to emerging technology, ease of
managing IT/IS functions, but almost all cases indicated a central motivator besides these - financial
reasons. Interestingly, this even applies to companies for whom some kind of IT or IS function is the
core of their business, contrary to what the belief about the extents of outsourcing might be[3].

However, there are a number of issues with offshoring development work that would make it an
unattractive option for corporations who would be willing to dig just a little deeper. For most business
decision-makers the 'cost' of software simply refers to the initial costs - the cost of hiring, training, and
employing full-time developers to create a new piece of software. There is some evidence of cost
overruns and quality disappointments, leading to what Frank refers to as "buyer's remorse". However,
there are other costs that companies must take into consideration. One cost, for example, is the loss of
intellectual property. With innovation moving offshore in some companies, there is fear that intellectual
property could be easy to steal for an offshoring company's employee - while countries like India do
have laws protecting copyrights and patents and against intellectual property theft, they are reportedly
"impossible to enforce,"[2] leading to a situation where a company could pay for new development but
then incur further costs when their own IP is stolen and reused elsewhere. Some countries that engage
in offshore development work for the US, such as Russia, do not even have IP laws, making them an
even more risky venture for American companies[2].

Privacy and security should be two other major concerns for companies considering offshoring their
work. While only one major situation involving offshore developers and privacy concerns had happened
as of 2005, and no major security threats had occurred yet, American companies were and are worried
about privacy even more than ever[4]. Again, the issue lies largely with concerns of legal systems:
India does not have a major privacy law, and yet it is the recipient of a large part of America's software
outshoring business. Furthermore, Singh's article notes that even if a client succeeds in getting a
favorable judgment under the United States legal system, enforcing it in India is extremely difficult, if
not outright impossible. While Indian development firms do claim that they meet the standards of their
American counterparts, the fear still exists today of a security breach brought on by offshore
development.

Furthermore, there is evidence to show that companies incur additional costs in the maintenance phase
of a software product that is developed offshore - in some cases, equal to the cost of having the
software developed domestically in the first place[5]. One example Kharif mentions is a buggy, nearly-
unusable .NET web portal developed offshore with a budget overrun of over $1m dollars, a number that
does not even take into account the initial budget. The lead on the development team that earned
$500,000 in revenue from fixing the portal estimated that the product could have been developed
onshore for somewhere closer to $900,000 - a total cost less than just the overrun itself. A large part of
this phenomenon of extremely buggy software and poor cost planning, however, comes from a couple
of problems that Robert Glass has already pointed out; one, that one of the two most common causes
of runaway projects is poor estimation, and two, that maintenance consumes between 40 and 80
percent of the cost of a software development project[6] - a cost that many managers are likely not
taking into account when offshoring since, as one of Kharif's sources mentions, most managers are only
looking at wages.

There is even a political cost to offshoring. Ganesh found in 2007 that one of the costs of offshore
development came in the form of "ethnic scapegoating"[7], a tendency to blame offshore developers for
problems encountered in software development, as well as characterizing offshore developers as less
skilled than domestic developers simply by virtue of working offshore - regardless of personal
experience or credentials.

Controversy

As long as companies continue to send software development work offshore, there will be those who
disagree with this fallacy and hold offshoring up as a cornerstone of their company's cost-saving and
productivity-enhancing measures. However, some of the rampant cry to offshore everything has
subsided in recent years, even as 40% of American companies reportedly engage in offshoring
activities[5], and proponents of offshoring have started to study ways to reduce the costs, instead of
simply assuming there are none.

S. Krishna has studied the ways to offset the cross-cultural issues that could result in ethnic
scapegoating[8]. Heeks et al. are even proponents of moving even more functions offshore, moving
further up the 'value chain' of software development to assist in saving money[9], yet they warn that
without 'synching' - their term for effective communication by building a close relationship between
client and developer - it will be difficult to perform well in a globalized market, and that even with
effective communication there will still be shocks along the way for companies new to offshoring.

The majority of controversy in offshoring seems to come from the fact that its proponents insist that it
is not an ineffective cost-saving measure, but that those who use it tend to use it incorrectly. In
response, there are a number of frameworks, such as that provided by Smith et al., that attempt to
bring into focus a number of other costs besides simple obvious financial costs - such as "the
relationship between project characteristics and site suitability, ...financial and intellectual property
issues in the context of software development, and ... the role of agents outside the outsourcing and
vendor firms in the offshore outsourcing process.[10]"

References
1. Engardio, Pete. "Outsourcing: Job Killer or Innovation Boost?" Business Week. 8 November 2006,
Business Week. 27 April 2008:
<http://www.businessweek.com/globalbiz/content/nov2006/gb20061108_738883.htm>.
2. Frank, Steven J. "Source Out, Risk In." IEEE Spectrum. April 2005, IEEE.
<http://www.spectrum.ieee.org/apr05/1298>
3. Mclellan, K., B.L. Marcolin, and P.W. Beamish. "Financial and strategic motivations behind IS
outsourcing." Journal of Information Technology 10.4 (1995), 299-321.
4. Singh, Vir. "Under Pressure, India Mulls Steps to Protect Privacy." IEEE Spectrum. February 2005,
IEEE. 27 April 2008: <http://www.spectrum.ieee.org/feb05/2944>
5. Kharif, Olga. "The Hidden Costs of IT Outsourcing." Business Week. 27 October 2003, Business Week.
27 April 2008:
<http://www.businessweek.com/technology/content/oct2003/tc20031027_9655_tc119.htm>
6. Glass, Robert L. Facts and Fallacies of Software Engineering. Boston: Pearson Education, 2003.
7. Ganesh, Shiv. "Outsourcing as symptomatic: class visibility and ethnic scapegoating in the US IT
sector." Journal of Communication Management 11.1 (2007), 71-83.
8. Krishna, S., Sundeep Sahay, and Geoff Walsham. "Managing cross-cultural issues in global
software outsourcing." Communications of the ACM 47.4 (April 2004), 62-66.
9. Heeks, Richard, S. Krishna, Brian Nicholson, and Sundeep Sahay. "Synching or Sinking: Global
Software Outsourcing Relationships." IEEE Software 18.2 (Mar/Apr 2001), 54-60.
10. Smith, Michael Alan, Sabyasachi Mitra, and Sridhar Narasimhan. "Offshore outsourcing of software
development and maintenance: A framework for issues." Information and
Management 31.3 (December 1996), 165-175.

You might also like