Rahul Jaswa
April, 2010
Assistance provided by Professor Steven Tadelis, my family, and particularly my thesis advisor, Professor Oliver
Williamson, is greatly appreciated.
2
Software Development Strategy
Table of Contents
Abstract ...............................................................................................................................................................5
(1.) Introduction.................................................................................................................................................5
(1.1.) The (Many) Roles of Software ..........................................................................................................8
(2.) Literature Review ........................................................................................................................................9
(3.) Analytical Framework: Comparative Economic Organization ..........................................................11
(3.1.) Modes of Economic Governance...................................................................................................12
(3.2.) Project and Asset Attributes............................................................................................................16
(3.2.1.) Frequency....................................................................................................................................16
(3.2.2.) Asset Specificity .........................................................................................................................18
(3.2.3.) Uncertainty .................................................................................................................................19
(3.2.4.) Production Costs .......................................................................................................................21
(3.3.) Transaction Support .........................................................................................................................23
(3.3.1.) Legal Contracting.......................................................................................................................23
(3.3.2.) Relational Norms.......................................................................................................................25
(3.4.) Discriminating Alignment Framework ..........................................................................................26
(3.5.) Extensions and Qualifications.........................................................................................................27
(4.) Methodology: Case Study Analysis.........................................................................................................32
(5.) Case Studies ...............................................................................................................................................33
(5.1.) LogSim ................................................................................................................................................36
(5.1.1.) Historical Events .......................................................................................................................36
(5.1.2.) Analysis .......................................................................................................................................37
(5.2.) MobileMaster .....................................................................................................................................38
(5.2.1.) Historical Events .......................................................................................................................38
(5.2.2.) Analysis .......................................................................................................................................40
(5.3.) LCDInternational..............................................................................................................................46
(5.3.1.) Historical Events .......................................................................................................................46
(5.3.2.) Analysis .......................................................................................................................................47
(5.4.) AppGenie ...........................................................................................................................................49
(5.4.1.) Historical Events .......................................................................................................................49
(5.4.2.) Analysis .......................................................................................................................................50
(5.5.) YourLive.............................................................................................................................................52
(5.5.1.) Historical Events .......................................................................................................................52
(5.5.2.) Analysis .......................................................................................................................................53
(6.) Conclusion .................................................................................................................................................55
(7.) Appendix ....................................................................................................................................................56
(8.) References ..................................................................................................................................................58
3
Software Development Strategy
Table of Figures
4
Software Development Strategy
Abstract
Software development strategy has become increasingly complex in the global age. Decisions
about whether to make-or-buy, to develop in-house or acquire from an outside vendor, now face the
skills and relatively inexpensive labor in developing countries, firms of all shapes and sizes have
increasingly turned to offshore vendors 1 . However, the failure rate is notably high. This begs two
questions. First, when are offshore development and outsourcing appropriate? Second, when
appropriate, what kind of (legal and relational) support increases the likelihood of project success?
Previous economic investigations rely primarily on production factors such as wages and the
cost of machines and technology to explain why many firms choose offshore outsourcing over other
organizational configurations. However, researchers consistently find that the source of contractual
strain which leads to outsourcing failure lies in transactional, rather than production, variables such
as monitoring and coordinating with vendors. This suggests a more complete comparative analysis
of alternative software development strategies would also include transaction costs. The framework
I propose to accomplish this is generally supported by the case studies analyzed in the second half of
the paper.
(1.) Introduction
IronPort Systems first outsourced software development in 2003. As a major web security
company, their products serve as the main switch for email and Web traffic into and out of the
largest companies in the world (42 of the G100) (IronPort Systems, 2006). Outsourcing was
conceived to keep up with the demand for new features while keeping development costs low
(IronPort Systems, 2006). IronPort hired an offshore vendor to provide increased manpower and
cooperate with the preexisting engineering team on projects. Three crucial shortcomings quickly
1 Gartner (2009-2010), Computer Economics (2009-2010), Deloitte (2005, 2008), and Morrison and Foerster (2009).
5
Software Development Strategy
became apparent to the management: (1) lack of domain knowledge 2 diminished the overseas teams
contributions, (2) lack of accountability compromised quality control, and (3) time differences and
long-distance communication were inefficient and caused delays. In 2005, the staff augmentation
model used initially was replaced in favor of assigning outside teams projects for independent
completion. Progress was tracked remotely using monitoring applications. To reduce ramp-up
time resulting from training a new batch of engineers for each project, offshore teams would work
on similar projects consecutively (IronPort Systems, 2006). This way, engineers familiar with
IronPorts technologies and needs could be used instead of those who would need to learn from
scratch. However, moving projects farther outside the firms boundaries created a new set of
problems: (1) outsourced projects were generally lower quality than those completed by onshore
teams and (2) absence of direct IronPort management resulted in possibly deliberate
misrepresentation of the work performed by offshore engineers. The number of resources working
on a project and the number of hours needed to be verified and frequently errors were found
(IronPort Systems, 2006). In 2006, IronPort decided to move away from offshore outsourcing in
favor of building overseas centers. After being acquired by Cisco soon thereafter, projects were
moved to Ciscos offshore development centers, where they have been carried out ever since. 3
Though IronPort poured considerable effort and energy into their outsourcing strategy, each
new phase was met with obstacles. The lesson is clear: when firms depend critically on software,
how it is developed or acquired can be strategically significant. Would IronPort have been more
successful with better strategic planning? Economic frameworks which successfully identify the
major factors motivating and complicating global software development would help provide an
answer. Research in this area is a work in progress this paper aims to further.
2 In the context of software development, domain knowledge describes experience and understanding of the area in which
an application is being developed. For example, engineers developing software for hospitals who are familiar with health
care possess domain knowledge. Domain expertise is proficiency in a particular subject area.
3 From IronPort (2006) and personal communication with Peter Schlampp, former GM of IronPorts offshore centers.
6
Software Development Strategy
Firms developing software choose between doing so in-house and sourcing from an outside vendor.
Hybrid strategies such as the coordinated development IronPort first attempted may also be
considered. Comparative analysis of a firms strategic alternatives requires identifying the key factors.
Unfortunately, as the IronPort case demonstrates, the relevant factors for such an analysis may not
Industry surveys find that vendor performance usually (~70%) fails to meet client
expectations, frequently (>20%) resulting in premature contract termination (Deloitte, 2005; Dun &
Bradstreet, 2002; Hirschheim et al, pp. 5; Input, 1999a/b; Raisinghani et al, pp. 53). However,
because of relatively inexpensive labor in developing countries, the pull to outsource remains
strong, and growing (Ellram et al, 2008). Typical economic treatments of these circumstances rely
on production cost theories to identify the relevant variables in comparative analysis. However,
previous studies have also demonstrated that some of the most significant obstacles faced by
software developers are transaction, rather than production, oriented. Indeed, hidden costs such
as difficulty monitoring relationships (Tadelis, 2007), writing complex contracts (Gupta, pp. 56), and
transferring work in and out of the firm (Tadelis, 2007) have frequently complicated transactions
(Poppo and Lacity, pp. 253) and should more carefully be taken into account.
comparative cost-benefit analyses for software development strategy. This paper develops a
discriminating alignment framework which takes a three pronged approach. Identify the strengths
and weaknesses of typical governance structure alternatives. Consider the major attributes of the
transaction in question. Identify the efficient match. To test the appropriateness of such a
framework, I analyze the details of real world software development projects, predict an efficient
alignment, compare to real world behavior, and observe outcomes. The framework used herein
7
Software Development Strategy
closely tracks Williamson (1985, 1991), with special emphasis on the critical factors for software
development strategy.
I proceed in four parts. First, I provide some background on the role of software in
enterprises. Second, I briefly discuss the state of the existing literature. Third, I introduce a
framework for comparative economic organization, starting with nonspecific descriptions of the
theoretical constructs developed (primarily) in transaction cost economics (TCE), and followed by
contextualization to software development decisions. Last, I use the proposed framework to analyze
Software plays many distinct business roles. Independent software vendors (ISVs) develop
applications for sale and distribution to enterprises or individual consumers. Other businesses use
software to support internal activities such as accounting and customer relationship management
(CRM). Until the late 1980s, businesses in either category usually employed their own programmers
to develop applications in-house. Since then, first with domestic and more recently with offshore
outsourcing, firms facing both types of software needs have increasingly turned instead to outside
efforts to construct broadly applicable economic frameworks, details are underemphasized (e.g.
Wang, 2002). Although we ultimately strive for a general framework, this is a long-term goal. I
propose we start with the details and work outwards. Consider Oracle, an enterprise software
developer. Their product line includes more than 60 software applications for the communications
industry alone (Oracle). Treating these applications as interchangeable may conceal details which
have significant implications for sourcing strategy. For instance, applications where integration into a
8
Software Development Strategy
firm is uniquely complex may be a good candidate for outsourcing to a vendor with extensive prior
experience.
Software development has too wide a literature base to discuss comprehensively here.
Instead, I briefly summarize the major contributions of labor cost theories, discuss the findings of
empirical TCE studies in other industries and then with respect to information technology (IT), and
Neo-classical economics has been the predominant explanation for outsourcing to-date.
Studies speculate that because outsourcing allows clients to capitalize on comparatively low wages in
developing countries, labor cost figures dominantly into outsourcing decisions. IT decision makers
have overwhelmingly confirmed the importance of labor costs in their sourcing decisions (Rao,
2004; Pfannenstein and Tsai, 2004; Tafti, 2005; Khan et al, 2002; Carmel and Tjia; Doh, 2005;
Aubert, 1996, pp. 51; Nagpal, 2006, pp. 12; Poppo and Lacity, pp. 265; Beulen et al, 2005).
However, a limited number of researchers have argued that in certain circumstances, transaction
costs can erode comparative advantage in production costs of vendors (Ang and Straub, pp. 50). In
the interest of completeness, this paper considers transaction and production costs in tandem.
confirmed in a number of mature, hardware industries such as textiles, steel, and automobile
manufacturing (Arnold, 2000) 4 . These studies demonstrate the accuracy of predicted alignments by
identifying the efficient governance structure based on transaction attributes and determining if real-
world behavior is consistent (Poppo and Lacity, pp. 211). However, when applied to IT the results
4
Williamson (2002) identifies the following studies as a testament to the success of empirical testing: Shelanski and
Klein (1995), Lyons (1996), Crocker and Masten (1996), Rindfleisch and Heide (1997), and Masten and Saussier (2000).
More recently, Macher and Richman (2008) conducted a review of empirical TCE studies in various social science and
business fields.
9
Software Development Strategy
have been generally discouraging (Nagpal, 2004; Loh, 1994; Nam et al, 1996; Grover et al, 1996;
Lacity and Willcocks, 1996). While transaction costs are unambiguously large 5 (Aubert et al, 1996;
Lacity and Hirschheim), they have not been found to consistently overwhelm production cost
However, two novel studies have made significant contributions to our understanding of the
factors at work. Tadelis (2007) uses comparative transactional analysis to assess the primary costs
and benefits of outsourcing IT. Tadelis attributes failed contracts to defective cost-benefit analyses
which neglect transaction costs, especially contracting and coordination. His proposed framework is
compelling and could benefit from specific case studies. Software development has unique risks; my
research suggests it should be treated distinctly of other IT tasks in TCE studies. These specificities
Wang (2002) determines whether asset specificity 6 and transaction uncertainty (explained in
detail in the following section) can be used to predict software development project performance.
He hypothesizes that when highly asset specific and uncertain projects are outsourced, the chance of
failure is relatively high. His major findings, for my purposes, are threefold. First, in contrast to his
hypothesis, asset specificity is positively correlated with project success. Second, uncertainty is
negatively correlated with project success, though statistical significance is weak at (p < .1). Third,
intuitively, he also finds that positive perceptions of contractor reputation are positively associated
One important note is that Wang takes disequilibrium contracting into careful consideration:
Without reaching an equilibrium state, diverse governance structures may survive for extended periods even
within the same industryAlthough the disequilibrium problem can reduce the predicative power of
transaction cost theory, the theory may still have strong capacity in explaining the performance of a chosen
5 Large is placed in quotes because the question in comparative analysis is not whether a cost is significant or
insignificant on its own, but rather how it compares to the costs associated with other governance options.
6 Specific assets are those which create mutual dependency between a client and vendor.
10
Software Development Strategy
governance structure, because, after all, the survivability of an organization form depends on its performance
(Wang, 2002).
Instead of considering differences between equilibrium and disequilibrium decision making, he uses
than in comparison to alternatives. This strategy is insufficient because the question is not whether
outsourcing will succeed in the abstract, but rather if it is the most efficient option available. As
Williamson puts it, comparative economic organization never examines organization forms
assumptions. Chief among these are perfect information, homogenous (faceless) buyers and sellers,
and hyper rational profit maximization. Though these assumptions are frequently inconsistent with
the decisions faced by real firms, neo-classical economics is mainly concerned with supply and
demand, prices and output rather than firms per se. Organizations are commonly cited as black
boxes rather than dynamic entities with complex inner workings. By substituting analysis of the
complex set of variables which drive business decisions with the overarching theory of the firm as a
production function, textbook economics neglects some of the crucial factors which drive the
TCE, as developed primarily by Oliver Williamson (1979, 1985, 1991, 2002, 2005, 2008) 7 , is
used in this paper as a remedy to application failures of economics as a science of choice. TCE
works out of the science of contract, with emphasis on governance. Transaction costs can take many
7Many other papers and books on TCE have been authored by Williamson, but this paper uses the framework as
explained in the sources cited. Theoretical constructs not cited proximately in section 3 are attributable to these five
works and personal communication with the author.
11
Software Development Strategy
forms, but those on which TCE relies are associated with adaptation (especially maladaptation of a
comparative institutional kind). The paradigm problem for this purpose is not the employment
relation (as recommended by Coase and others), but the intermediate product market (outsourcing)
decision. So as to focus on hitherto neglected transaction costs, production technologies and labor
costs are assumed to be the same whether a firm makes or buysalthough, in the end,
TCE posits that firms can be analyzed as structures which govern transactions between
autonomous entities or internally. These transactions are subject to several features inadmissible in
traditional microeconomics: uncertainty, buyer and seller identity, and bounded rationality, which
refers to actors who are intendedly rational, but only limitedly so (Simon, 1985). Some have
argued that transaction costshave not added substantially to our understanding of IT sourcing
in particular why these decisions are made, suggesting that production costs [by themselves] are
adequate to explain the decision outcomes (Nagpal, 2006). If the observation that transaction costs
do not have organizational implications for IT has merit, I conjecture that some unusual phenomena
must be at work. In my proposed framework, the criterion for organizing commercial transactions
is assumed to be the strictly instrumental one of cost economizing. Essentially this takes two parts:
governance structures, the appropriateness of each of which differs with the attributes of
transactions and differences in the institutional environment. Three typical modes of governance are
markets, hierarchies, and hybrids. Market transactions are simple: buyer and seller identity are
unimportant, and contracts to protect investments are unsophisticated because alternate suppliers
and buyers can be easily identified if a transaction is compromised. Hierarchies describe internal
12
Software Development Strategy
organization wherein firms make rather than buy an intermediate good or service, subject to
oversight by the management. Hybrid forms of governance lie in between markets and hierarchies
Enterprise Software
Development
Make Buy
(Hierarchy) (Hybrid)
For software development, pure market transactions can be conceptualized as the simple
acquisition of prepackaged, turnkey software applications (Lacity and Willcocks, 1996), where
disputes are decided by the legal system. However, this alternative is unworkable in cases where
customized applications are required. Instead, when client needs are relatively unique and complex
(the cases considered in this paper), the four major alternatives identified in figure 1 predominate.
governance modes are threatened by the bureaucratic costs of managing an activity within
ownership boundaries. Rather than being overseen by external arbiters such as those provided by
the legal system, internal disputes are decided by the firm itself. In contrast, hybrid market
transactions involve coordination with an outside vendor and vary in complexity. Examples include
outsourcing long-term projects domestically with regional vendors or offshore with foreign ones.
Relationships are supported by detailed contracts with dispute settlement mechanics, service level
agreements, and the like. Behavioral factors such as reputation can play a further role in establishing
credible commitments. Hybrid governance can take many different forms, but each is clearly
13
Software Development Strategy
differentiated from market governance by its relative complexity, and from hierarchical governance
require both parties in a transaction to adjust in concert, while autonomous adaptations allow clients
to adjust on their own, perhaps by switching to another vendor. Markets are most efficient when
adaptation can be effected autonomously. Hierarchies are preferred for coordinated adaptation
because adjustment is accomplished by fiat and maladaptation costs are avoided, albeit with
increased bureaucratic costs. Intermediate disturbances are typically governed best by hybrid
configurations with complex contracts which contain a machinery to work things out
(Williamson, 1979).
The full extent of potential disturbances in the software development environment cannot
be detailed here, but some categories with examples may clarify the sorts of contingencies which
(1) External. Introduction of new tax codes necessitates adjustment of internal accounting,
(2) Client side. If a firm learns its consumers desire more features, software must be re-
(3) Vendor side. Movement by vendors from local data storage on physical servers to virtual
storage using cloud-based computing requires adjusting the way client and vendor
14
Software Development Strategy
In this light, the primary benefit of TCE is that it takes a symmetrical approach in predicting
alignments: identify the strengths and weaknesses of alternative governance structures; determine
Hierarchical governance provides owner control over the software development process.
Engineering teams are located within the same ownership boundaries as the management, which
ensures both parties are motivated by the same profit stream. Increased worker transparency
facilitates worker oversight and quality control (Tadelis, 2007). Moreover, internal production
affords a firm the security of retaining control over potentially sensitive software code (Morrison
and Foerster, 2009). In cases where intellectual property provides competitive differentiation and
compromised integrity would have negative consequences for survival, this level of security may play
development teams and thus face less coordination obstacles (Herbsleb and Moitra, 2001).
Engineers are located proximately and can often adjust to disturbances relatively quickly by meeting
face-to-face with coworkers (Herbsleb and Moitra, 2001). Similarly, managers can directly observe
the progress of development teams. However, domestic hierarchies are limited to local labor pools
which sometimes lack specialized skills, the critical mass of which is only available overseas (Rao,
inexpensive labor. This phenomenon has been well-documented in developing countries where
offshore development is most prevalent, such as India and China (e.g. Gold, pp. 5). When a client
and vendor must adapt to disturbances in concert, the major drawback to offshore development is
the increased complexity of coordinating across culture and space (Ebert and De Neve, 2001).
complexity provide access to specialized skills and vendor expertise (Currie, 2000). However, when
15
Software Development Strategy
the software in question is being custom built around unique needs, project completion generally
requires a high degree of interaction and coordination between client and vendor (Beulen et al,
2005). When needs and specifications change, as they frequently do during software development,
both parties must adjust together (Ellram et al, 2008). Adjustment processes are complicated by a
lack of transparency resulting from the absence of face-to-face to communication (corridor talk;
Herbsleb and Moitra, 2001) as well as misaligned incentives: each partys main interest is to
maximize its own payoff instead of the combined payoff (Wang, 1997). Vendors may thus have
reason to minimize information disclosure and other practices which increase vulnerability to client
judgment. Monitoring relationships (Tadelis, 2007) and writing complex contracts which ensure
vendor accountability (Poppo and Lacity, pp. 264) have been obstacles for many past outsourcing
arrangements.
Domestic outsourcing is more secure than offshore outsourcing because the U.S.s
regulatory environment is generally preferred to that of developing countries (Gupta, pp. 59; Tafti,
2005). Offshore vendors have an additional labor cost advantage compared to domestic vendors
because of their use of developing countries labor pools (Gold, pp. 5). However, partnering with an
outside team located abroad typically accentuates coordination problems (Ebert and De Neve, 2001)
In the TCE schema, the attributes of transactions to which differential adaptation needs
(3.2.1.) Frequency
Simple, one-shot market transactions are, from a transaction cost perspective, uninteresting.
In these cases, the purported marvel of the market mechanism is often evident. Lack of continuity
16
Software Development Strategy
annihilates need for coordinated adaptation; absent frequency, transactions possess little to no
intertemporal attributes. In contrast, occasional and recurrent transactions carry varying implications
for reputation effects and setup costs. Exposure to behavior on multiple transactions allows the
client to develop a positive or negative impression of the vendor. At the same time, initial setup
costs are eroded as transaction frequency increases if those purchases can support subsequent
transactions.
In traditional hardware industries, the concept is intuitive. Take, for example, Volkswagen,
which outsources the vast majority of its production process (Arnold, 2000). Each time a new fleet
of cars is desired, VW places another order with their chosen vendors. Over time, good and bad
performance becomes known and eligibility varies accordingly. With respect to physical capital,
vendors that have good experiences are increasingly willing to invest in equipment and technologies
to build VWs parts over time. The return on one-time investments increases as a growing number
of transactions are supported. Costs of investment in human capital, the education and skills
developed during a project, erode in the same way. Time spent acquiring skills for one project trades
off with those needed for another; as specific skills support subsequent projects, the cost of initial
However, Wang (2002) argues that frequency is not relevant to software because it is an
intangible asset which once programmed, can be replicated almost instantaneously with few
complications. Although this may be the case, any software engineer will be quick to point out the
importance of maintenance and reengineering, as well as the repeated use of specific skills from one
development project to the next (Ellram et al, 2008; Aubert, 1996). Implications for reputation and
setup costs thus follow in the same way as we see in transactions involving exchange of physical
goods.
17
Software Development Strategy
The traditional economic assumption that buyer and seller identity are unimportant is
misleading when investments in specialized assets are made to support a transaction. In these cases,
the competitive landscape at the outset, composed of many eligible suppliers, is transformed into
one where the client and initial vendor are bilaterally dependent during contract execution and
renewal. In these instances, both parties have cost incentive to continue their relationship. The
vendors specific assets have only diminished redeployable value in alternative uses, while the client
faces difficulty turning to other vendors who lack these assets. Because of this lock-in, as asset
specificity deepens, need for coordinated adaptation builds up. Transactions which require
specialized investments are thus negatively associated with simple market exchange.
These types of relationships carry the risk of opportunistic vendor behavior. Although there
is an incentive to continue the relationship, vendor and client alike also have reason to maximize
profit, resulting in misaligned incentives (Tadelis, 2007). Because the client is disinclined to terminate
their contract in favor of hiring an alternate, less qualified supplier, the vendor may sense an
opportunity to generate profit by, for example, demanding costly contract renegotiation. While
cooperation is the norm, if vendors sense the benefits accrued to opportunistic behavior outweigh
the cost of potentially losing a client, defection from the spirit of cooperation can be anticipated
(Williamson, 2005).
Consider VW, as described above. To build a VW Golf (type of automobile), vendors must
invest in paint shop equipment unique to VWs specifications (Arnold, 2000). In this case, the client
and vendor are bilaterally dependent. From the vendors perspective, such equipment has only
diminished value to other car manufacturers such as Mercedes-Benz, whose cars are painted using
different applicator technologies. These specialized investments can be used for Mercedes only
ifredesignedIn such cases quite often a total loss must be accepted if the original use is
18
Software Development Strategy
finished (Arnold, 2000). To the client, alternative suppliers lack such equipment and are therefore
less eligible for contracting. Assets such as these, where parties to a transaction become locked-in,
possess a degree of specificity. Where it is high, clients should make rather than buy.
With software, asset specificity is primarily a function of human capital, which follows from
its intangibility (Wang, 2002). In these cases, clients can more easily use the same vendor because
their expertise and know-how eliminates need to extensively train new workers for similar future
projects. However, as in hardware industries, the redeployable value of such human capital is less in
alternative uses. The existence of specific know-how and skills and the difficulties of knowledge
transfer mean that it will be costly for the parties to switch to a new relationship (Wang, 2002).
Empirical studies have shown that in the case of high asset specificity, managers tend not to
For instance, bilateral dependence can follow from software development for financial
institutions. Some of the specialized functions of an application are imaging, multimedia, fund
transfers, decision support systems, and others developed to champion idiosyncratic competitive
strategies [that] are hence highly firm-specific (Ang and Straub, pp. 65). Vendors contracted to
develop a firms software may thus develop skills during project completion which make them
uniquely suited for maintenance and modification, as well as building new but similar applications in
the future. Dependence on a vendor may result in high exposure to opportunistic behavior (Aubert
et al, pp. 160). From the vendors perspective, the skills acquired in developing such software are of
less value to other financial institutions which have different and specific needs (Ang and Straub, pp.
65).
(3.2.3.) Uncertainty
2005, 2008). Because individual agents lack perfect foresight, all complex contracts are vulnerable to
19
Software Development Strategy
unforeseen contingencies and thus unavoidably incomplete (Williamson, 2005). The degree of
incompleteness plays an important role in determining which governance structure is most efficient
for a particular transaction. As uncertainty and adaptive needs grow, hierarchy is increasingly
This paper argues procedural and environmental uncertainties are major variables in software
events unfold and uncertainties get resolved, definition takes shape (Aubert, 1996; Ellram et al,
2008). As a result, extensive collaboration and communication between client and vendor are
necessary to communicate project evolution (Herbsleb and Moitra, 2001; Beulen et al, 2005; Gupta,
pp. 5; Ellram et al, 2008). Lack of face-to-face contact forces firms to rely on technologies for
communication which sometimes make it relatively difficult to explain complex ideas (Herbsleb and
Moitra, 2001; Gupta, pp. 5; Mockus and Herbsleb, 2001). Project performance can be further
compromised by misunderstandings and cultural differences (Rao, 2004; Beulen et al, 2005; Gupta,
pp. 5; Gonzalez et al, 2006; Ellram et al, 2008; Khan et al, 2002). As needs and specifications change,
autonomous parties read and react to signals differently, even though their purpose is to achieve a
different styles, methodologies and technologies; remotely observing vendor progress transparently
is thus difficult. Physical measures of throughput, such as lines of code, do not correspond directly
to task completion or system functionality (Wang, 1997). An end product is similarly difficult to
measure, because problems may become apparent only after integration into the clients systems and
product line. Circumstances where accountability is lacking are ripe for opportunistic supplier
20
Software Development Strategy
outsourcing, for example, is frequently scrutinized because of weak legal regimes in developing
countries such as India and China (Gupta, pp. 59; Tafti, 2005). Concerns about the continued safety
and integrity of intellectual property and data are claimed be a significant concern which managers
should and do assess (Gupta, pp. 55; Doh, 2005; Smith et al, 1996; Pfannenstein and Tsai, 2004).
These concerns are not without merit: in South Korea, for example, GS Caltex call center
employees were accused of downloading and attempting to sell names, Social Security numbers and
e-mail addresses of 11 million customers (Morrison & Foerster, 2009). Stories of this variety are
not entirely uncommon (Tafti, 2005; Rao, 2004; Fitzgerald, 2003). And, when vendors handle
sensitive source codes and system designs essential for competitive success (Rao, 2004; Smith et al,
1996), much is at stake. While frameworks such as the World Trade Organizations Trade-Related
Aspects of Intellectual Property Rights (TRIPS) protect software as a literary work, these regulations
require local enforcement which is unreliable in the developing countries where outsourcing is most
prevalent (Rao, 2004). The state of regulatory regimes must be accounted for in global transaction
cost frameworks (Henisz and Williamson, 1999). Clearly, increased environmental uncertainty tends
to discourage risky outsourcing (Henisz and Williamson, 1999). In recent years, legal frameworks
and enforcement mechanisms have improved, but much is still left desired (Rao, 2004). Thus, if the
development requires few physical resources other than a computing platform which can speak the
right language. As a result, the costs of development are driven mostly by the wages of software
labor (Carmel and Tjia, pp. 31). Although new or expanding firms may need to purchase this
21
Software Development Strategy
technological equipment, setup costs are typically one-time expenditures which support many
projects. Labor conceptualized as time spent researching, programming, testing, and maintaining
thus factors dominantly into production cost analysis (Beulen et al, 2005). Therefore, offshore
organizational modes which provide significant labor cost savings have an advantage for many
software projects.
This was not always the case. Technologies used to communicate and coordinate with
offshore vendors were previously very expensive (Smith et al, 1996; Gonzalez et al, 2006; Carmel
and Tjia, pp. 4) and often incapable of handling the volume of data involved in software projects
(Khan et al, 2002; Carmel and Tjia, pp. 3-4). It was only in 1994 that one of the pioneering project
managers offshoring to India had his team copy the weekly software build onto tape every Friday
just in time for the FedEx pick-up that would fly the tape across the ocean (Carmel and Tjia, pp. 4).
Since then, the cost of communication and information transfer has fallen dramatically, almost to
the point of negligibility (Gonzalez et al, 2006; Manley and Hobby, 2004; Doh, 2005; Patel, pp. 10;
Robinson and Kalakota, pp. 17; Carmel and Tjia, pp. 10-11; Ellram et al, 2008; Rao, 2004).
Compared to the late 1990s and early 2000s, communication costs are 10-20% of what they were,
voice over internet protocol, widely used by software workers, has zero marginal cost, and
bandwidth, once a precious commodity, was available at four gigabits per second in some
Ceteris paribus, firms can now outsource to production locations with inexpensive labor.
The lure is strong: a masters level computer scientist makes at most U.S. $14,000 per year in India,
and is generally better educated and more enthusiastic than his $100,000 plus American counterpart
(Gold, pp. 5). Survey participants frequently report the significance of labor costs in justifying their
decisions (Robinson and Kalakota, pp. 3; Carmel and Tjia, pp. 10; Pfannenstein and Tsai, 2004;
Gupta, pp. 52; Patel, pp. 11; Ang and Straub, pp. 51; Doh, 2005). The pressure to reduce costs was
22
Software Development Strategy
so great that there was a consensus [firms] could afford the cost of retraining new employees, and
even switching suppliers or regions of the world, if necessary (Ellram et al, 2008).
However, despite this appealing picture, TCE has always been quick to demonstrate the
costs incurred during market use. Software development outsourcing is no exception, as many of the
While market governance is supported by legal systems and hierarchical governance by the
firm itself, hybrid governance structures are more complicated. Contracts must provide safeguards
against opportunistic behavior, as feasible (Lee et al, pp. 202; Khan et al, 2002). Different types of
contracts are appropriate for transactions with specific risk profiles. While still necessarily
incomplete, contractual safeguards operate as imperfect but positive deterrents and correctives.
Because bilaterally dependent parties are mutually locked into a relationship, each has incentives to
promote continuity and safeguard their specific investments (Williamson, 2002). Goods and
services will be exchanged on better terms with parties who exercise feasible foresight and introduce
increasingly well defined, contracts are often renegotiated (Wang, 2002) and progress from one form
to another, as appropriate.
In IT fields, the sophistication and complexity of contracts has evolved significantly over
time. While they were once simple and minimalistic, negative experiences motivated firms to invest
more resources into legal protections (Gupta, pp. 56). Nowadays, the typical mega deal contract
[contains] over 30,000 lines, with 600 SLAs, [and] 50 different pricing mechanisms (Poppo and
Lacity, pp. 264). While this paper fails to give an authoritative introduction to software development
23
Software Development Strategy
contract law, I attempt to describe the primary contractual mechanisms employed to control
transaction costs. In the case of software development, because transactions involve transfer of
intangible assets and human capital, contracts are more difficult to construct (Lee et al, pp. 201).
I begin with contract longevity. The primary alternative to vertical integration as a solution
to the general problem of opportunistic behavior is some form of economically enforceable long-
term contract (Klein et al, 1978). Previously, long-term contracts were the norm in outsourcing
relationships, typically with approximately 10 years of specified services (Tafti, 2005). However, as
firms began to notice that legal lock-in complicated their ability to adapt to market changes, shorter
contracts, downward of five years, which provided more flexibility, became the norm (Gartner,
2009-2010; Aubert et al, pp. 165). The major drawback of short-term contracts is that without
assurance of future business, vendors are at higher risk and will thus, ceteris paribus, price goods and
services higher (Gartner, 2009-2010; Beulen et al, 2005). Finding what appears to be a balanced
middle ground, many savvy firms rely on pilots and initial short-term contracts to provide
opportunities for vendors to demonstrate their worth before longer contracts are signed (Poppo and
Lacity, pp. 263-264). These contracts are typically limited to 12 months at most (Marriot, 2003;
Beulen et al, 2005) and smooth the transition to hybrid governance. While the danger of
contingencies cannot be eliminated, precautionary behavior is clearly helpful. Vendors may also
benefit from pilots because they provide an opportunity to gauge factors such as the clients
The structure of vendor compensation has also evolved. Rather than continue to rely on
cost-plus contracts where clients pay vendors for the expenses incurred during development plus a
profit, fixed-price contracts, where clients pay a flat rate for project completion, are now often used
instead (Gartner, 2009-2010; McKinsey, 2009; Aubert et al, pp. 172). This shift often helps realign
incentives, reducing the risk of deliberate underperformance and other forms of opportunistic
24
Software Development Strategy
behavior (Aubert et al, pp. 172). As a supplement, contracts integrate underperformance penalties
and baseline quality levels benchmarked by independent third parties (Tafti, 2005; Aubert et al, pp.
172; Carmel and Tjia, pp. 112-129). Third party consulting firms which perform benchmarks have
access to data which allows them to compare one vendors performance to others in similar
industries, and/or evaluate progress, often by collecting feedback from user tests (Ellram et al, 2008;
Beulen et al, 2005; Robinson and Kalakota, pp. 15; Poppo and Lacity, pp. 269). However, at the
same time, project ownership requires a higher level of trust, as clients cede more control to
Dispute settlement mechanics are very important for adapting to disturbances and have been
given more attention over time (Poppo and Lacity, pp. 272; Carmel and Tjia, pp. 112-129; Tafti,
2005). While many models have been developed, most unique to the specific transaction in question,
some examples include virtual committees with equal vendor and client representation, or use of
Relational norms supplement legal contracts in supporting transactions. Essentially, for our
client-side analysis, this concept can be formulated as the mechanisms by which transactions are
infused with confidence. For example, periodic inspections or deploying one or a few on-site
managers better ensures information sharing and informed choices between the client and vendor
Second, reputations provide confidence for clients and incentivize strong performance from
vendors who conceivably want to maintain and build their positive images. In the case of
performance on other projects to prospective buyers (Wang, 2002). As information has become
increasingly accessible and dispersed, vendors are more sensitive to dissemination of negative
25
Software Development Strategy
reports. For example, the Capability Maturity Model is a widely adopted international assessment
framework used to judge the process maturity of most vendors, especially those medium and large in
size, and identify areas for improvement (Pfannenstein and Tsai, 2004). As a result, clients are more
likely to choose vendors with strong reputations, while reputation effects may [discourage] hold-
However, relational and contractual supports are far from a panacea. As one study puts it,
neo-classical contracts have adaptive limits, which allow for a certain level of support for hybrid
governance, but continue to leave certain other problems unaddressed (Poppo and Lacity, pp. 268).
The contractual schema in figure 2 8 depicts the relationship between different transaction
attributes and governance structures. Asset specificity denoted as K plays a fundamental role in
unassisted market transaction which does not exhibit contractual support except the standardized
protections afforded by the legal system. As asset specificity deepens (K > 0), the need for
coordinated adaptation and the risks of opportunistic behavior buildup. Added complexity is
featured as uncertainty and disturbances become increasingly likely. Nodes C1 and C2 are hybrid
unrelieved. Because of the added risk of weak legal regimes in foreign countries, these hazards tend
to be more significant in offshore outsourcing contracts (C2) than domestic outsourcing contracts
(C1). Nodes D1 and D2 are similarly of the hybrid form, but are supported by varyingly complex
contracts and relational norms (S > 0) that safeguard against transaction risks. Because of the
8Williamson (2002, 2008) develops the fundamental version of this contractual schema. I have made modifications for
software development strategy.
26
Software Development Strategy
contractual support to achieve the same level of security as offshore outsourcing (D2). And, because
the risks incurred in the C nodes are greater than those in the D nodes, they will be priced higher by
vendors, ceteris paribus. Finally, nodes E1 and E2 represent transactions which are governed best by
consequential and the need for coordinated adaptation is especially great. Node E1 swaps
transaction costs from using the market for the bureaucratic costs of managing production within
the boundaries of the firm. These bureaucratic costs are compounded in node E2 where an
geographical locations, as explained in section 3.1, magnify coordination costs within the firm.
Each of the factors described above has been formulated with respect to equilibrium
contracting. Do they carry over to disequilibrium conditions where, compared to mature industries,
technologies develop rapidly and are subject to continuous innovation? The evidence suggests they
do, but only in a qualified way. Many outsourcing studies spotlight firms for whom outsourcing was
27
Software Development Strategy
purportedly inappropriate. Before concluding this way, we must consider whether disequilibrium
changes the criteria for appropriateness. To be sure, running a business is not easy. The
challenges for the firm of maintaining competitive advantage in the face of pressures to reduce costs
and shift production brought about by shifting technology, markets, and competition, the principal
forces at work in offshoring are significant (Doh, 2005). These opinions have been voiced similarly
High-technology markets are very dynamic in the status quo. Innovation is more or less
continuous and businesses are in a competitive race where they must develop technologies before
competitors, or face strategic peril. I propose these factors may play a substantial role in motivating
Let us start with innovation. When technologies change and new ones are developed, firms
who use those technologies must adapt, either by modifying their old systems or developing new
ones. When a business depends intimately on these systems, time is of the essence. Being able to
develop new products more flexibly becomes a critical factor within a sector like the IS industry,
which runs a race against obsolescence every day (Gonzalez et al, 2006). Cases where internal
development necessitates training new workers or learning new skills may favor outsourcing where a
vendor has the expertise to complete a project quickly. Here, despite other project characteristics
which may suggest the value of hierarchical governance, timeliness trumps and hybrid or market
Capabilities that, in the fullness of time, could be home grown (successively built up) may simply be
unattainable (except by creating alliances, joint ventures and the like) as the urgency of real-time responsiveness
becomes great. The high-technology sector where a race to be first is underway and few firms possess the
requisite set of capabilities at the outset often displays these real-time responsiveness needs. Assembling a team
that possesses those capabilities and providing the membership with high-powered incentives that are geared to
28
Software Development Strategy
Examples of such innovations are numerous. The introduction of new operating systems
(e.g. Windows 1995, 2000, ME, XP, Vista, 7), new technology platforms (e.g. MS-Dos, Windows,
Web-based), and the like necessitate adaptation. If outsourcing vendors are better able to deal with
exogenous changes, they may be preferred for these tasks. When legacy systems based around
mainframes and data centers were perceived as outdated compared to client/server and distributed
networks, IT managers needed to transition their entire systems quickly without compromising the
overall business (Currie, 2000; Venkatraman, 1997). As a result, CIOs and IT directors in the mid-
maintaining existing systems and applications and introducing new ones at only a marginal increased
cost (Currie, 2000). Lacity and Willcocks (1996) apply the same logic to explain differentials
between TCEs predicted alignments and real-world behavior: senior managers reasoned that by
outsourcing information technology, the vendors would help them keep abreast of new information
technology advancements.
Second is the high-technology race. For the purposes of competitive survival, companies
seek to develop technologies before others. While intuition suggests this was always the case, this
dynamic has been accentuated sharply in recent years. Nowadays, software lifecycles have been
shortened considerably as users are continuously confronted with new and interesting rival
technologies. As any pedestrian computer user can see, the web-based world has created time-to-
market constraints (Herbsleb and Moitra, 2001). Need to shorten the development time cycle of
IS projects has significantly increased the demand for more flexibility for IT enterprises, which
do not have enough time to create and maintain adequately trained human resources that can cope
with the volatility of the demand and the heterogeneity of its projects (Gonzalez et al, 2006). Under
these circumstances, if outsourcing vendors can provide flex capacity, their use may be the favored
mode of organization.
29
Software Development Strategy
While previously the norm for companies was to rely on slow and careful process driven
development strategies, these have been all but replaced in favor of more timely production (Avison
and Fitzgerald, 2003; Maurer and Martel, 2002). Figure 3 breaks down the evolution over time.
However, for longer term contracts, flexibility has sometimes been an outsourcing weakness
(Gartner, 2009-2010). Although some buyers continued to expect innovation without having
specified their objectives in the contract, more sophisticated buyers developed processes and
methodologies to define and negotiate innovation plans (Gartner, 2009-2010). Some transaction
cost theorists may disagree with the idea that outsourcing might increase flexibility in times of
technological flux. However, if an outside vendor can deal better with exogenous change than the
client, it may offer organizational advantages under the specific conditions described above. At
Speed is also not a given. If a vendors teams need extensive training, hierarchy becomes a
more favored means for developing software quickly. Coordinating asynchronously (different time
zones) can create holdups. Miscommunications about work in progress and the difficulty in
scheduling meetings can present a problem for those trying to use a 24-hour-workday model 9 (Rao,
2004; Gonzalez et al, 2006; Mockus and Herbsleb, 2001; Beulen et al, 2005). Because software
example, while minor problems can be addressed amongst an in-house team by walking to a
coworkers cubicle and talking through it, offshore workers have to resort to communication
mediums like e-mail. Instant message and phone calls may be unsuitable depending on firms
respective time zones. An e-mail not answered until the clients workday starts, to be followed up by
another email when the vendors next workday starts, can continue cyclically, resulting in substantial
9 Client and vendor operate in different time zones so that when one teams workday ends, the others begins.
30
Software Development Strategy
delays (Mockus and Herbsleb, 2001). As it turns out, these problems can sometimes be averted by
necessary. For example, having the vendor do all the programming and the client do all the testing
Object-Oriented
Programming (OOP) Extreme Programming
(XP)
Mature SDLC (Waterfall Dominant mode of
Model) programming during mid- Prototyping with little to no
1990s which requires planning, allowing constant
Widespread adoption of the careful construction of a modification of applications
SLDC model. programming by creating a and frequent release of
broad set of fundamental builds based on user
objects (data blocks) and feedback.
Early Systems
building up.
Development Life Cycle
(SDLC)
Rapid Application
Very structured and
Development (RAD)
deliberate process driven
framework. Each
Sacrifices planning stages in
development stage must be
Structured Systems favor of prototyping
completed before moving
Analysis and Design software designs to reduce
onto next stage. Accelerated RAD
Methodology (SSADM) project turnaround time.
Applies the 1990s RAD
Documentation heavy
process to an even shorter
process focused on careful Scrum
timeframe.
and meticulous planning
prior to programming. Careful division of tasks
among programmers to
allows for different stages
to be completed
simultaneously.
31
Software Development Strategy
varying from 45 minutes to two hours. In complex cases, I typically conducted two interviews, each
with different high-level employees. Each interviewee was directly involved with strategic software
development decisions. I present the five companies where transactions were unusual, complex
and/or illuminating. As per their requests, company and individual names were replaced with
fictional ones. Certain transaction details were omitted for the same purpose.
For each company, I begin by describing the transaction or series of transactions without
interjecting analysis. All subjective commentary is merely repetition of the views held by
interviewees. After laying out the events which transpired, I identify the transaction attributes
apparently significant for the company (figure 4 contains complete results). Then, I determine, based
on the strengths and weaknesses of different governance modes laid out in section 3.1, the efficient
match. Next, I consider whether the behavior observed is consistent with my expectation for profit-
maximizing behavior. Finally, I draw out implications for the theoretical framework outlined.
The methodology employed is less a cross-sectional test than a series of individual case
studies where five key issues are important. First, does the proposed framework focus our attention
on the key transaction features? Second, is the decision calculus invoked by software development
strategists broadly consistent with transaction cost reasoning? Third, are deviations from expected
behavior explained by the disequilibrium qualifications laid out in section 3.5? Fourth, are there
cases where the reasoning invoked by decision makers is puzzling or even wrong-headed from the
TCE perspective? Fifth, in what ways and for what reasons is TCE unable to relate and what
analyses. Make alignment predictions, observe real-world behavior and compare. Several factors
32
Software Development Strategy
caused me to opt for case study analysis. First, microanalytic data, required to determine, for
example, asset specificity and procedural uncertainty levels, is extraordinarily difficult to gather for
high-technology projects in an appropriate scale for econometric analysis. Second, several companies
interviewed were hesitant or unwilling to share detailed data, which would create uncontrollable bias.
Third, as a matter of choice rather than necessity, I assert that case study analysis is a prerequisite to
more quantitative studies. At this early stage, we must first identify the variables which should figure
prominently into alignment predictions. Looking at specific cases and drawing out the relevant
factors may point out important missing variables to include in future statistical studies.
company which organized internally would have been better suited for outsourcing? Because that
kind of inefficient decision making is largely reflected only in unrealized cost savings, concrete
mechanisms for observation are lacking. We can surely suggest that in these cases the transaction
attributes might lend themselves to market or hybrid governance, but we lack results to determine if,
in retrospect, these suggestions were apt. Second, hindsight is 20/20. Without being careful and
precise, too much credit for identifying inappropriate alignments may be taken. Future analyses,
especially those which use statistics, must make predictions prior to the execution of real-world
decisions and then wait for outcomes. I argue that there is still value in hindsight because it can
illuminate mistakes which managers should be careful not to repeat. Third, our analysis is
asymmetrical because it looks at decisions primarily from the clients perspective. Does this obscure
production costs, frequency, asset specificity, uncertainty, disequilibrium conditions, and contracting
is presented in figure 4. In one case, MobileMaster, neither interviewee was responsive to requests to
33
Software Development Strategy
perform the follow-up survey. However, details of each project were discussed in depth during our
conversations, so translation into numerical values was transparent and should not distort the data
The numerical values compiled in figure 4 describe the degree to which certain transaction
attributes were present for each company. Interviewees were asked to respond to questions which
target different features of the proposed comparative framework, with zero corresponding to not
applicable, one to insignificant, two to moderately significant, and three to significant. For instance,
the degree of human asset specificity was determined in response to the question: did those
working on the project develop specific skills which make them more qualified than others for
future projects on the same or similar issues? If inapplicable to the transaction, respondents would
select zero. Otherwise, the degree of asset specificity would be judged from one to three. The
34
Software Development Strategy
Labor 3 3 3 3 3 2 2 2
Technology / Machines 0 1 0 1 1 1 2 1
Facilities 0 0 0 0 0 0 0 0
Shipping / Telecommunications 0 1 1 1 1 1 1 0
Frequency
Maintenance 3 3 0 2 2 3 3 3
Reegineering 3 2 0 2 1 2 2 3
Similar Products 2 2 3 2 1 1 2 3
Asset Specificity
Human Capital 3 3 1 2 2 2 3 3
Physical Capital 3 3 1 1 1 2 3 0
Core Competency 3 3 1 2 2 1 3 3
Uncertainty
Definition of Specifications 1 1 3 2 2 3 1 1
Measurability / Verifiability 1 1 2 2 2 3 3 3
Vendor Transparency 1 1 1 1 1 3 0 2
Communication Intensity 3 1 1 1 1 2 3 2
Coordination Intensity 3 1 1 1 1 2 0 1
New Internal Technologies 3 1 0 3 3 2 3 1
New External Technologies 0 0 0 3 3 3 3 1
Data Security / Privacy 2 2 1 1 1 2 3 3
Transition Costs
Moving Out 3 1 1 1 1 1 0 3
Moving In 0 2 0 2 2 2 0 1
Disequilibrium Conditions
Contracting / Safeguarding
35
Software Development Strategy
(5.1.) LogSim
LogSim develops chip design automation software which uses logic simulation (think
artificial intelligence) to replace manual testing. They currently focus on a single vertical market,
LS initially developed software exclusively. The particular vertical market they target is
limited in size (~$700 million) and scope (three competing chip design businesses). However, their
target customers were unwilling to cooperate while the software was still immature. As a result, they
needed to build chips themselves on which they could test their software. Being a small market and
requiring a very specific skill-set, LS was unable to identify a critical mass of workers qualified to
build these chips locally. Inexperienced workers would require years of intensive training.
They initially found an offshore vendor with a small team possessing the relevant experience.
The vendor decided to change its business strategy at the cost of LSs chip design work soon
thereafter. LS hired the vendors team, a managing director and five engineers, into full-time
positions. Starting in July 2006, the MD supplemented their Bangalore staff by luring employees
from the offshore offices of their three target customers. By the beginning of 2008, a complete team
had been formed. Over time, LS found that many of the engineers initially hired to build chips
(hardware) were more talented and cost efficient software developers than LSs American engineers.
As a result, the firm shifted the center of gravity for their software work to the Bangalore office.
The major obstacle was determining how to divide work between the local and offshore
offices. In most cases, the majority of development work is performed overseas while the innovation
(the ideas) is conceived in the U.S. Over many iterations and modifications the firm has finally
36
Software Development Strategy
(5.1.2.) Analysis
equipped only to analyze the decision to assign software development to the preexisting chip design
team in Bangalore. This decision is unique in that it was unplanned: LS had a team of software
engineers in the U.S., but felt the overseas hardware designers were more talented and less expensive
than their American coworkers. However, these factors were irrelevant to the original decision to
setup offshore operations. Two questions need to be answered. First, was it appropriate to reassign
software development to the offshore team? Second, would software development be a good
From a production perspective, the labor quality and cost advantages in India are significant
and transparent. If transaction costs are neglected, the added cost savings from offshore outsourcing
are appealing. However, the attributes of LSs software projects suggest offshore hierarchical
governance is favored. (1) Frequency was recurrent. Because the software being developed was LSs
core product, the firm was under pressure to continuously evolve and improve its application. (2)
Asset specificity was high. Extensive domain knowledge is a prerequisite to programming for LSs
projects, and these skills have considerably diminished value for software projects with other
companies or in different industries. (3) Procedural uncertainty was high because specifications are
in constant flux. Moreover, as a new, cutting-edge technology, what the coding will ultimately look
like is unclear. As a consequence, development teams will regularly need to adjust to changes in
concert with the management. Similarly, the absence of a clear set of project specifications makes
37
Software Development Strategy
monitoring progress both essential and difficult, even more so with use of an outside team
(outsourcing). (4) Environmental uncertainty was mixed. Though the code is confidential, LS lacks
competitors who could take advantage of unauthorized access. The great complexity of LSs
technology creates a substantial barrier to use, even with some pieces of their code. (5)
Disequilibrium conditions did not motivate outsourcing. LS does not face direct competition, and
those most qualified to adapt to disturbances are the employees within the firm who continuously
Consequently, as frequency, asset specificity and procedural uncertainty are all high, internal
organization is clearly the preferred mode of governance. While this framework suggests that a U.S.
office would be appropriate, the offshore team is relatively talented and cost efficient. And, the
coordination difficulties which are ordinarily faced during offshore development are mitigated
considerably by deployment of a management team to which the Indian engineers are accountable.
Need for bilateral communication between the U.S. and Bangalore office is similarly reduced
because the offshore team is given significant ownership over development projects, while the
onshore team is responsible for thinking up new innovations. Clearly, LSs chosen development
strategy, which has been successful to-date, validates the framework proposed in this paper.
(5.2.) MobileMaster
MobileMaster develops software that allows companies to remotely manage mobile phones
at a low cost was seductive. And, because one of the firms board members had success offshore
38
Software Development Strategy
First, MM hired an overseas team to develop part of their core knowledge source. Only a
few months later, the contract was prematurely terminated and operations were brought back in-
house. The offshore team was unable to keep up with project responsibilities because they were
composed primarily of junior workers who lacked even general experience. Theres a big difference
between getting the code 80% ready and actually shipment ready, and the latter was a significant
problem for the outsourcing firm (Baar, vice president of engineering). Also, this project had not
the offshore team was always two to three cycles behind. These issues were exacerbated by the
tendency of vendor employees to constantly say yes to requests they did not understand, forcing
performed well for MMs board member on another venture. Building software reports involves
unifying the data from software development and other aspects of the enterprise into a human
readable form. These reports had been built regularly by the in-house engineering staff and had
precise specifications. This time, the offshore team completed the project, but delivered
shockingly low quality reports. According to Baar, the team had been so desperate to complete the
project, they overlooked the need to build something maintainable and scalable. Reflecting on this
transaction, MM felt tricked: while they initially spoke to a polished, senior person from the
outsourcing team, he ended up being uninvolved with the project and inexperienced junior workers
were used instead. As a result, MM retook control of these projects and has executed them in-house
ever since.
Third, MM hired an offshore firm to develop applications for Blackberry phones, a project
they lacked the talent to complete in-house without some training. However, coordination and
39
Software Development Strategy
communication became complicated. Tracking and monitoring tools provided by the vendor were
inefficient and defeated the point: the management lacked time and resources to micromanage an
offshore team remotely. Again, progress was found to be unsatisfactory as the offshore team could
not handle evolving specifications. The firm opted to prematurely terminate their contract and bring
Silverlight web-based platform. Domain knowledge was lacking in-house, but specifications were
somewhat well-defined. The precise set of features needed was known at the outset. MM planned to
perform two to three cycles using the offshore vendor, to set the project into motion, before
bringing it back in-house. However, the offshore teams work was low quality and things which
needed to be done elegantly were done with force (Baar). The project was moved back to MM
In each instance, because time was short, due diligence and contracting were held to a
minimum. Reflecting on these experiences, both the CEO and VP of engineering speculated as to
what makes an outsourcing project successful: (1) well-defined specifications are essential; (2)
outsourcing part of a team is considerably more risky than a whole team; (3) outside engineers must
be interviewed personally to ensure they are capable and trustworthy; (4) if outside engineers lack
domain experience they cannot adapt to changes in fast-moving technology markets effectively; and
(5) the key to offshore success is building a captive center when a company is first established.
(5.2.2.) Analysis
40
Software Development Strategy
Failures make for interesting case studies. Because each of these projects is technologically
Developing part of the core knowledge source is a labor intensive project which MM wanted
to make more cost efficient. Because an offshore vendor would provide increased manpower at a
relatively low cost, MM chose to outsource. From a production cost perspective, outsourcing is
clearly favored. Let us now consider the transaction attributes. (1) Frequency was recurrent. As part
of the companys core knowledge source, maintenance and re-engineering would be needed often,
and the skills used for development would be used continuously for projects in similar areas. (2)
Asset specificity was high. Engineers working on this project would develop highly specialized skills
essential to the companys core product. (3) Procedural uncertainty was very high because this was a
new project which lacked defined specifications. Without previous projects to use as the basis for
comparison, monitoring would be ultimately little more than ungrounded speculation. And, evolving
software needs would necessitate extensive communication. (4) Environmental uncertainty was
mixed because although this was part of the companys core, it was limited in size. It would be
difficult for a vendor to do significant damage with access to only that level of information. (5)
Disequilibrium conditions were consistent with the equilibrium criteria. Adaptation to changing user
and business needs in real-time is effected better by MMs more experienced, in-house employees.
Clearly, as frequency, asset specificity and procedural uncertainty are significant, internal
organization is the preferred mode of governance. While building an offshore facility would provide
access to inexpensive labor while reducing coordination difficulties, the firm lacked time and
resources needed to engage in such a process. As a result, software development should have
strain were difficulty communicating and coordinating with the offshore team, transaction costs
which are very predictable using the comparative framework developed in this paper.
41
Software Development Strategy
Developing software reports is a simple but labor intensive process. MM had been
completing these projects in-house for some time and believed they could move such a menial task
to an offshore vendor with little hassle. As usual, from a production cost perspective, the decision to
outsource is straightforward. Offshore vendors have a labor supply and cost advantage the
combination of which was inaccessible to MM either within the firm or locally. However, a pure
market transaction consisting of off-the-shelf software reports is unfeasible because such a product
does not exist. Software reports must be developed specifically for a particular enterprise.
Considering transaction costs, the conclusions are largely consistent. (1) Frequency was
recurrent. Software reports must be developed continuously as aspects of the enterprise undergo
change. (2) Asset specificity was low. No idiosyncratic or specialized skills must be possessed prior
to project completion or are developed during a project. (3) Procedural uncertainty was low because
a number of reports had been built in-house previously and specifications were very well-defined.
Based on our analysis in section 3.2.3, monitoring and coordination should be uncomplicated under
these conditions. (4) Environmental uncertainty was low because the reports did not contain any
highly sensitive material which could be used maliciously. (5) Disequilibrium conditions were not
exhibited significantly in this transaction because the software reports were not a response to
exogenous technological change or a key differentiator from market competitors. However, the
MM felt similarly (their rationale was primarily the well-defined specifications) and selected a vendor
owned by the CEOs personal friend. However, the transaction invariably failed and was brought
42
Software Development Strategy
back in-house. Looking back on section 3.3, we recall that in circumstances where a project is best
suited for relatively simple, hybrid market transactions, only some minimum level of legal and
relational support is needed to ensure credible vendor commitments. That MM felt tricked by a
senior engineer who was ultimately uninvolved with the project suggests even these minimal
protections were overlooked. Legally stipulating the experience level of engineers staffed,
interviewing engineers directly, and carefully monitoring progress, either remotely or by deploying a
U.S. employee(s) at the vendor site are recommendations we could have made at the outset to
safeguard against opportunistic behavior. Hindsight being 20/20 and unable to test the feasibility of
these safeguards given how the project was executed, these recommendations should be taken with a
grain of salt. That being said, the contingencies appear foreseeable and the recommendations apt.
The firm had little experience building a specific type of application for Blackberry mobile
phones. Here, they were motivated to outsource by a lack of in-house expertise as well as cost
savings. Being a relatively simple project, MM was easily able to identify a vendor with ample
experience.
While the production side motivation is intuitive, transaction attributes complicate the
picture. (1) Frequency was occasional. Blackberry applications are only a periphery aspect of the
firms core business model and would require only limited maintenance and re-engineering. (2) Asset
specificity was similarly intermediate. Skills required to develop Blackberry applications are not
sophisticated or specialized, but building MMs application in particular may result in teams
developing some unique familiarity and experience. (3) Procedural uncertainty was mixed. This
project had not been previously undertaken within MM and lacked well-defined specifications.
43
Software Development Strategy
However, there was a sense of which features would need to be included, even though the specific
coding structure was unknown. As needs and product plans changed, MM would have to
communicate and coordinate with the offshore vendor. Monitoring would be difficult because MM
lacks prior experience with which to judge the outside teams progress. The vendor was chosen
because they had the requisite knowledge to pursue creative solutions which met MMs vague needs.
(4) Environmental uncertainty was negligible because of the distance of this particular application
from MMs core product. (5) Disequilibrium conditions were exhibited because MM needed to
develop these applications quickly. The outside vendor possessed a set of skills which would allow
While cost savings as well as talent access are clear, the transaction attributes are mixed.
Frequency, asset specificity, and procedural uncertainty are all intermediate. Environmental
uncertainty does not play a role in this analysis. This project seems suited for a hybrid outsourcing
arrangement with a complex contract to protect against opportunistic behavior and increase vendor
accountability. MM pursued such a hybrid arrangement, but neglected the transaction support.
When asked about this, both interviewees stated the time required for extensive legal work would
have been very costly. Time-to-market was essential and contracting would have been a burden.
Eventually, the outside team delivered low quality work and was difficult to monitor, resulting in the
Clearly, transaction support was again needed. Building Blackberry applications is a relatively
simple and unchallenging task (Raab), and with the adequate effort and manpower, the vendor
certainly could have performed to expectations. While my comparative framework provides useful
tools to look at the transaction and production attributes, as currently formulated it does not
consider the time investment in transaction support. In this case, real-time responsiveness
introduces a tradeoff. Assuming project success, an outside vendor could complete the project more
44
Software Development Strategy
quickly than the client could in-house because training was unneeded. However, as it turns out, the
transaction support needed would similarly cost precious time. How to negotiate these bidirectional
Again, lack of in-house domain knowledge and cost savings were the crucial motivations. The firm
was able to easily find an offshore vendor with the requisite experience.
The transaction attributes are almost identical to those faced during Blackberry application
development. (1) Frequency was occasional. MM planned on doing two to three transaction cycles
with an outside firm before bringing the project back in-house. (2) Asset specificity was mixed
because although many vendors possess experience with Silverlight, some previous experience
working with MM would simplify subsequent product cycles. (3) Procedural uncertainty was mixed
because Silverlight applications were outside the companys core and had not been previously built
in-house. A picture of what the application needed to look like was available, but which code would
be used to get there was unclear. The vendor was even chosen to provide creative input. Thus, as
needs changed, intense coordination and communication with the outside team would be necessary.
Monitoring the transaction would be difficult given MMs inexperience. (4) Environmental
uncertainty was insignificant because these applications were only tangentially relevant to MMs
business model. (5) Disequilibrium conditions played a marginal role in motivating outsourcing, as
the company wanted to get the project moving, but minor delays would be tolerable.
For the same reasons as before, outsourcing with the support of legal contracting and
relational norms is most efficient based on our comparative framework. The transaction lasted
45
Software Development Strategy
slightly longer this time, with the vendor ultimately delivering a product, but the coding was below
expectations and could not be used. While the temporal aspects of transactional support play a role
here as well, another factor emerges. Would more sophisticated contractual specifications such as
service level agreements, underperformance penalties and the like have resulted in a higher quality
product? If the vendor simply lacked the talent to get the job done then the answer is that in all
likelihood, probably not. This raises a second issue with my proposed framework. Whereas in theory
we assume that with the right support mechanisms the product ultimately delivered by a vendor or
built in-house will be of similar or equal quality, real world circumstances are sometimes different.
Future modifications to our framework will need to incorporate the predicted quality of end
products when linked to innate differences in skill level. However, low quality performance resulting
from insufficient coordination and monitoring is a transaction cost we are already prepared to deal
with.
(5.3.) LCDInternational
initially the vast majority of software was sourced from outside vendors, the management eventually
realized that the solutions which they were purchasing were insufficient to create a popular medium
which would attract advertisers. Now, the company custom develops software which they integrate
LCDI received funding from an American venture capital firm but knew the U.S. market
would be too saturated to sell their products effectively. They had limited capital and determined
they could cut 30-50% of their costs by moving overseas. Choosing between Bangalore and
Hyderabad, India, the firm first chose Hyderabad because the technological infrastructure was better
46
Software Development Strategy
suited for their business model. However, after realizing all their potential partners were located in
About one year after their founding, the company hired an outsourcing vendor for a small
software programming project involving a network of digital picture frames. Pleased with the
outcome, LCDI hired the team full-time. As they realized these new employees had sufficient
experience to rebuild the failing business model around customized software programming, they
stopped sourcing applications from outside vendors and built them in-house instead. Located as
they were in a new emerging market, their software platform would require continuous innovation,
and the quality of internal talent was thus essential to their adaptability and flexibility. With a
sophisticated knowledge of Java programming and some light previous experience with video, an
employee would be sufficiently qualified. The company was able to find the relevant talent and build
Now LCDI is expanding into North America and Singapore, planning to build development
teams in each local market they attempt to penetrate. Asked about whether they would consider
outsourcing their software development work, the CEO adamantly rejected the idea as unfitting for
a growing software company. From his perspective, outsourcing is worthwhile only when work is
performed in bulk and repetitive tasks can be moved overseas. The central importance of all the
software development work being done to their success creates a massive risk they would be
unwilling to shoulder. However, by building their office overseas they were able to take advantage of
wage differentials without facing the difficulties of moving a project outside the companys
boundaries.
(5.3.2.) Analysis
Because our model deals with only the software development transaction, this is for our
purposes more straightforward than it seems: should LCDI continue to develop software in India?
47
Software Development Strategy
The company was motivated to move overseas by inexpensive labor and close access to their end
market. Oddly enough, once that move was completed, this was no longer an offshoring case. Now,
it is an Indian company producing domestically, which may carry implications we are unprepared to
deal with, such as differences between developed and developing countries business environments.
For the company to offshore internally would entail, for example, doing development in a Filipino
captive center, but ultimately selling from India. Thus, the question which is relevant for our
purposes is whether the firm could benefit from outsourcing domestically (within India) or offshore
The production attributes suggest that outsourcing would be most cost effective because in
addition to providing the same low-cost labor, the vendors economies of scale cost advantage
would be partially reflected in the contract price. On the other hand, the transaction costs of such an
arrangement would be significant. (1) Frequency is recurrent because the software needs to be
constantly maintained and updated. (2) Asset specificity is very high because skills tailored to LCDIs
product are necessary to develop this software. Outside vendors lacked the needed skills and would
be capable of acquiring them only by working on an LCDI project. (3) Procedural uncertainty is
significant. Since the software is in an early development stage, specifications are dynamic and in
many instances entirely undefined. Coordinating intensely with an outside vendor would be essential,
while monitoring would be difficult. (5) Environmental uncertainty is also very high. In a cutting-
edge industry, providing outsiders with access to sensitive materials could introduce competitors and
put the firms first-mover advantage at risk. (5) Disequilibrium conditions play an important role. As
part of a product both interviewees categorized as of the future, LCDIs software development
48
Software Development Strategy
strategy must be capable of responding to new developments quickly. Only the experienced internal
With high levels of asset specificity, uncertainty and frequency, this project is a poor
candidate for outsourcing. However, because labor cost and proximity to local markets play a
significant role, the company moved, essentially in its entirety (two executives, only, spend half of
each year in the U.S.) offshore. Since these advantages would be unavailable to the firm had they
located permanently in the U.S., this model, as unusual as it is, is appropriate given our transaction
cost framework. As the company moves into different national economies, scaling their existing
model by building local subsidiaries for development work in each new location, the viability of this
model will be put to the test. The major factor to be considered is the difficulty of coordinating a
variety of international development facilities, each of which ostensibly houses some different and
(5.4.) AppGenie
network platforms.
As a technology firm, AG needs to be able to adapt to a rapidly changing space where new
applications are released very frequently. When considering how, organizationally, to develop a new
application, three options are available: build in-house, outsource entirely, and build partly in-house
and outsource the rest. From a myopic cost perspective, comprehensive outsourcing is the cheapest
option. But, once an application is released to market, resources need to be moved onshore so they
are close to the user base and application iterations can be released quickly.
49
Software Development Strategy
Contracting offshore studios provided AG with their desired flex capacity. Because there
was a lack of engineers in the U.S. with experience working on social network multimedia
applications, AG looked to Arts International. AI had worked on similar projects and also offered a
3-D art specialty which AG needed and other vendors lacked. Because a self-contained team which
could operate independently was essential for AG, prior experience was a must. However, because
of AIs unique domain knowledge and 3-D art talent, they were able to charge prices comparable to
AG contracted AI for a single application, and after observing strong performance, began
using them regularly. Shortly thereafter, in 2009, AG acquired AI. They sensed AI was developing
the expertise necessary to independently develop applications which would compete with AGs.
They were also confident that because of their smooth experiences in the past, coordination and
integration into the firm would not be overwhelmingly complex or difficult. The acquisition allowed
them to neutralize the risk of AI emerging as a competitor, while bringing specialized talent in-
house.
(5.4.2.) Analysis
AG began by outsourcing one of its software development projects to AI, but after
subsequent projects chose to acquire them. Two questions are thus raised. First, was AGs decision
to outsource application development appropriate? Second, was AGs decision to acquire AI and
50
Software Development Strategy
Here, labor cost played an insignificant role. Because AI offered a highly specialized service,
they were able to charge U.S. prices despite using offshore development facilities. Instead, AG
outsourced because it needed access to AIs application development and 3-D art skills.
The transaction attributes in this case are transparent. (1) Frequency was recurrent, as AG
maintains their products everyday, and builds new applications and new versions of existing
applications every few weeks. (2) Asset specificity was very high because the skills needed to work
on a project are very particular to the types of applications which AG builds and the technological
platforms they use. Subsequent projects are simplified considerably if engineers already have the
relevant knowledge base. (3) Procedural uncertainty was significant because specifications were only
weakly defined at the outset and outside teams were required to provide creative input with only
limited guidance from AG. At the same time, user needs constantly change and evolve, so
coordinated adaptations would be routine and essential while monitoring progress would be
applications, they were not as poorly equipped to make informed judgments about AIs work in
progress as we saw with, for example, MobileMaster. (4) Environmental uncertainty was very
significant because the types of applications AG develops are part of a highly competitive
environment where secrecy is of the utmost importance. (5) Disequilibrium conditions were
applications must be developed in concert with exogenous changes in the Myspace and Facebook
technological platforms.
responsiveness motivates outsourcing. Developing the requisite talent for building 3-D art in-house
would have been a timely process that compromised AGs position in the competitive environment.
Thus, they outsourced to AI, but invested heavily in due diligence and contracting. Giving AI
51
Software Development Strategy
substantial project ownership also played a role in partially realigning incentives, as explained
But, as expected, the risks associated with hybrid market governance when hierarchy was the
best equilibrium option were significant. Even with legal and relational support, the threat of
opportunistic behavior by AI became apparent. With access to AGs specialized skills, AI became
The comparative framework can predict certain aspects of this outcome using the
disequilibrium qualifications in section 3.4. Namely, outsourcing was the efficient strategy given
integration would be the favored mode of organization using equilibrium criteria. What is lacking
from the framework as developed here is how to weigh the tradeoffs between equilibrium and
disequilibrium conditions. In this case, hybrid governance was chosen initially but ultimately
abandoned for hierarchical governance. What is the threshold for disregarding equilibrium indicators
(5.5.) YourLive
Recently, YL decided they needed to develop an application which could tap into
Facebooks social networking environment. However, the internal engineering team lacked
experience with such projects, and building the application in-house would thus have been a
52
Software Development Strategy
relatively difficult process. An Indian firm which one of YLs employees had used previously was
Several benefits were identified to outsourcing over in-house development. The driving
factor was the ability to spend more resources focused on YLs core product, which would have
been sacrificed if employees needed to switch gears and learn the Facebook development platform.
Given the size of the company, approximately 20 people, this would be a significant labor force
displacement. Second, because YL did not want to lag behind competitors who had already
leveraged the Facebook platform, time was of the essence. Developing the talent in-house would
have been a relatively slow process. The last issue, considered last priority, was the shockingly low
cost of $7,500.
YL did reference checks with other clients who had used the vendor for Facebook
applications and requested a detailed proposal. However, legal contracting was kept at a minimum.
The YL team currently spends 30 to 40 hours per week performing oversight and maintenance,
using tools such as email, Skype and collaboration software to communicate. Because the application
was being developed on a platform YL employees could access remotely, progress was easy to
observe; transparency provided confidence. For maintenance, YL pays the vendor on an hourly
basis which extends beyond the original contracted fee for service. And, because the vendors
knowledge of YLs applications is now significant, YL claims they will use them for future projects
in similar areas.
(5.5.2.) Analysis
In this case, the transaction is still in-progress and we have yet to see a final outcome. So, we
can make a prediction, evaluate preliminary outcomes, and revisit the case when more concrete
53
Software Development Strategy
The production cost motivations are clear and intuitive, while the transaction attributes are
complex. (1) Frequency was occasional. Maintenance, reengineering and release of new products are
needed only once in a while, as this software plays a merely periphery business function. (2) Asset
specificity was mixed because building a Facebook application requires skills possessed by many
different vendors, but working with YL on projects would increase a particular vendors suitability
for maintenance and subsequent development projects with YL in similar areas. (3) Procedural
uncertainty was low. In this case, although YL lacked previous experience building Facebook
applications, they knew exactly which features needed to be incorporated, and ensured the vendor
was comfortable with those needs before making a contractual agreement. (4) Environmental
uncertainty was somewhat significant because in order to develop the Facebook applications, the
vendor would need access to YLs core code. However, the vendor was not in a position to become
a competitor. And, YLs preexisting competitors have quite different business models; access to
privileged code would not provide them with much of an advantage. (5) Disequilibrium conditions
were significant because time-to-market was a driving factor in the decision to outsource, but they
do not motivate a governance strategy inconsistent with that which optimizes under equilibrium
criteria.
Occasional frequency, mixed asset specificity and environmental uncertainty, and low
procedural uncertainty suggest hybrid outsourcing is most efficient. Because uncertainty is low, the
contractual support needed to ensure that the vendor is performing adequately is minimal. At the
same time, YL uses a variety of tracking tools and means of communication for staying coordinated
with the outside development team. Clearly, YLs decision to outsource with a minimalistic contract
54
Software Development Strategy
appears supported by our alignment hypothesis. And, although the transaction is still in progress,
performance thus far, as indicated by the interviewees, suggests it will ultimately be a successful first
(6.) Conclusion
My proposed framework has been modestly successful in identifying the major factors at
work in organizational decisions. However, four shortcomings became clear during analysis of the
cases. First, we are not equipped to deal with the time investment needed for transaction support
(MM #3). Second, my framework does not provide an obvious way of incorporating quality of an
end product when innate differences in skill level accompany different modes of governance (MM
#4). Third, although we have looked at differences in the legal regimes of developing versus
developed countries, we have yet to examine their respective business environments (LCDI).
will need to be answered in future studies. Last, the framework lacks a mechanism for choosing
between equilibrium and disequilibrium criteria for software development strategy when they are in
conflict (AG).
Despite these shortcomings, each of the case studies demonstrates the value of
incorporating TCE into software development strategy. Previously missing factors in economic
behavior, were evident in many of the real world decisions observed. Though each of the
the progress made in this paper is encouraging. Using the discriminating alignment methodology
provided here we are better suited to identify the strengths and weaknesses of different modes of
governance, evaluate the production and transaction attributes of specific projects, and choose the
best alternative.
55
Software Development Strategy
(7.) Appendix
56
Software Development Strategy
Transition Costs
(3: Very Significant; 2: Somewhat Significant; 1: Insignificant; 0: Not Applicable)
Was it difficult to transfer the work to
Moving Out (0-3):
the team / vendor?
Was it difficult to integrate the teams
Moving In (0-3):
result into the companys product line?
Disequilibrium Conditions
(3: Very Significant; 2: Somewhat Significant; 1: Insignificant; 0: Not Applicable)
Was there a deficit of workers who had
In the firm (0-3):
Labor Shortage the requisite knowledge to work on the
Locally (0-3):
project?
Needed to Develop Product Was project turnaround time a
(0-3):
Quickly significant concern?
Contracting / Safeguarding
(3: A lot; 2: Some; 1: Little; 0: Not Applicable)
Due Diligence / Background Did you do a lot of background research
(0-3):
Checking on the vendor?
Did you spend a lot of time writing
Writing Contracts (0-3):
contracts?
Did you have somebody / people on the
Monitoring: people on-site vendors site monitoring progress and/or (0-3):
managing?
Did you use collaboration tools or Please Also Provide Brief
Monitoring: tracking software tracking software to monitor the Explanation
vendors progress? (0-3):
What types of communication Please Also Provide Brief
Monitoring: informal
technologies were used? (e.g. Instant Explanation
communication
Messaging, Skype, E-mail, etc.) (0-3):
57
Software Development Strategy
(8.) References
Ang, Soon and Straub, Detmar. (2002). Costs, Transaction-Specific Investments and Vendor
Dominance of the Marketplace: The Economics of IS Outsourcing. In: Information Systems
Outsourcing: Enduring Themes, Emergent Patterns and Future Directions.
Aubert, Benoit et al. (2002). Managing IT Outsourcing Risk: Lessons Learned. In: Information
Systems Outsourcing: Enduring Themes, Emergent Patterns and Future Directions. Ed: Rudy
Hirschheim et al.
Avison, David and Fitzgerald, Guy. (2003). Where Now for Development Methodologies?.
Communications of the ACM, 46, 1.
Beulen, Erik et al. (2005). From Application Outsourcing to Infrastructure Management: Extending
the Offshore Outsourcing Service Portfolio. European Management Journal, 23, 2.
Carmel, Erran and Tjia, Paul. (2005). Offshoring Information Technology: Sourcing and
Outsourcing to a Global Workforce.
Coase, Ronald. (1937). The Nature of the Firm. Economica. November, 4, 386-405.
Crocker, Keith and Scott Masten. (1996). Regulation and Administered Contracts Revisited: Lessons
from Transaction-Cost Economics for Public Utility Regulation. Journal of Regulatory Economics.
January, 9:1, pp. 539
Currie, Wendy. (2000). The Supply-Side of IT Outsourcing: The Trend Towards Mergers,
Acquisitions and Joint Ventures. International Journal of Physical Distribution & Logistics
Management, 30, 3/4.
Deloitte. (2005). Calling a Change in the Outsourcing Market: The Realities for the Worlds Largest
Organizations. April.
Deloitte. (2008). Why Settle for Less? Deloitte Consulting 2008 Outsourcing Report.
Doh, Jonathan. (2005). Offshore Outsourcing: Implications for International Business and Strategic
Management Theory and Practice. Journal of Management Studies, 42, 3.
Ebert, Christof and De Neve, Philip. (2001). Survival Global Software Development, IEEE
Software, March / April.
58
Software Development Strategy
Ellram, Lisa et al. (2008). Offshore Outsourcing of Professional Services: A Transaction Cost
Economics Perspective. Journal of Operations Management, 26, 148-163.
Gonzalez, Reyes et al. (2006). Information Systems Offshore Outsourcing. Industrial Management
and Data Systems, 106, 9.
Grover, Varun et al. (1996). The effect of service quality and partnership on the outsourcing of
information systems functions. Journal of Management Information Systems, 12 (4), 89116.
Gupta, Amar. (2008). Outsourcing and Offshoring of Professional Services: Business Optimization
in a Global Economy.
Henisz, Witold and Williamson, Oliver. (1999). Comparative Economic OrganizationWithin and
Between Countries. Business and Politics, 1, 3.
Herbsleb, James and Moitra, Deependra. (2001). Global Software Development. IEEE Software,
March/April.
Hirschheim, Rudy et al. (2002). Information Systems Outsourcing: Enduring Themes, Emergent
Patterns and Future Directions.
Input. (1999a). Outsourcing Clients are Growing Restless: 20% May Switch Vendors at Contract
Renewal. www.input.com/article27.cfm?research_id=340
IronPort Systems. (2006). IronPort Outsourcing and Offshore Development Center Case Study.
Presented at the Second Annual Conference on the Globalization of Services, Stanford University,
December. http://iis-db.stanford.edu/evnts/4587/IronPort.pdf
Khan, Naureen et al. (2002). Evaluating Offshore IT Outsourcing in India: Supplier and Customer
Scenarios. IEEE Computer Society.
Klein, Benjamin et al. (1978). Vertical Integration, Appropriable Rents, and the Competitive
Contracting Process. Journal of Law and Economics, 21, October, 297-326
Lacity, Mary and Hirschheim, Rudy. (1993). Information Systems Outsourcing: Myths, Metaphors
and Realities.
59
Software Development Strategy
Lacity, Mary and Willcocks, Leslie. (1996). Interpreting Information Technology Sourcing Decisions
from a Transaction Cost Perspective: Findings and Critique, Accting., Mgmt. & Info. Tech., Vol. 5,
No. 3/4, pp. 203-244.
Lee, Jay-Nam et al. (2002). Current and Future Directions of IS Outsourcing. In: Information
Systems Outsourcing: Enduring Themes, Emergent Patterns and Future Directions. Ed: Rudy
Hirschheim et al.
Lyons, Bruce R. (1996). Empirical Relevance of Efficient Contract Theory: Inter-Firm Contracts.
Oxford Review of Economic Policy. 12:4, pp. 2752.
Macher, Jeffrey and Barak Richman. (2008). Transaction Cost Economics: An Assessment of
Empirical Research in the Social Sciences. Business and Politics, 10, 1.
Manley, Thomas and Hobby, Scott. (2004). Globalization of Work: Offshore Outsourcing in the IT
Age. Emory International Law Review.
Marriot, I. (2003). Offshore Sourcing: a framework for success. Outsourcing and IT services Summit
2004, Gartner, Royal Lancaster Hotel, London, 2627 April.
Maurer, Frank and Martel, Sebastian. (2002). Extreme Programming: Rapid Development for Web-
Based Applications. IEEE Internet Computing, January/February.
Mockus, Audris and Herbsleb, James. (2001). Challenges of Global Software Development.
Proceedings of the Seventh International Software Metrics Symposium.
Morrison & Foerster. (2009). Global Sourcing Trends in 2009. Global Sourcing Group.
Nagpal, Ankur. (2004). Use of Transaction Cost Economics to Study Information Technology
Outsourcing: Over-Application or Under Theorizing? Earlier version published in the proceedings
of Americas Conference on Information Systems.
60
Software Development Strategy
Pfannenstein, Laura and Tsai, Ray. (2004). Offshore Outsoucing: Current and Future Effects on
American IT Industry. ISM-Journal.
Poppo, Laura and Lacity, Mary. (2002). The Normative Value of Transaction Cost Economics:
What Managers Have Learned About TCE Principles in the IT Context. In: Information Systems
Outsourcing: Enduring Themes, Emergent Patterns and Future Directions. Ed: Rudy Hirschheim et
al.
Raisinghani, Mahesh et al. (2008). Information Technology / Systems Offshore Outsourcing: Key
Risks and Success Factors. In: Outsourcing and Offshoring of Professional Services, ed. Amar
Gupta.
Rao, Madhu. (2004). Key Issues for Global IT Sourcing: Country and Individual Factors.
Information Systems and Management Journal, Summer.
Rindfleish, Aric and Jan Heide. (1997). Transaction Cost Analysis: Past, Present and Future
Applications. Journal of Marketing. October, 61, pp. 3054
Robinson, Marcia and Kalakota, Ravi. (2005). Offshore Outsourcing: Business Models, ROI and
Best Practices.
Shelanski, Howard A. and Peter G. Klein. (1995). Empirical Research in Transaction Cost
Economics: A Review and Assessment. Journal of Law, Economics and Organization. October, 11,
pp. 33561
Simon, Herbert. (1985). Human Nature in Politics: The Dialogue of Psychology with Political
Science. American Political Science Review, 79, pp. 293304
Smith, Michael et al. (1996). Offshore Outsourcing of Software Development and Maintenance: A
Framework for Issues. Information and Management, 31, 165-175
Tadelis, Steven. (2007). Creating Value Through Outsourcing. California Management Review, 50, 1.
Tafti, Mohammed. (2005). Risks Factors Associated With Offshore IT Outsourcing. Industrial
Management and Data Systems, 105, 5.
Wang, Eric et al. (1997). Contracting Structures for Custom Software Development: The Impacts of
Information Rents and Uncertainty on Internal Development and Outsourcing. Management
Science, 43, 12.
Wang, Eric. (2002). Transaction Attributes and Software Outsourcing Success: An Empirical
Investigation of Transaction Cost Theory. Information Systems Journal, 12, 153-181.
61
Software Development Strategy
Williamson, Oliver. (1985). The Economic Institutions of Capitalism: Firms, Markets, Relational
Contracting.
Williamson, Oliver. (2002). The Theory of the Firm as Governance Structure: From Choice to
Contract. Journal of Economic Perspectives, 16, 3, 171-195
Williamson, Oliver. (2005). The Economics of Governance. The American Economic Review, 95, 2,
Papers and Proceedings of the One Hundred Seventeenth Annual Meeting of the American
Economic Association.
Williamson, Oliver. (2008). Outsourcing: Transaction Cost Economics and Supply Chain
Management. Journal of Supply Chain Management, 44, 2.
62