Thesis: Software Development Strategy: A Practical Application of Transaction Cost Economics

Software Development Strategy: A Practical Application of Transaction Cost Economics

Rahul Jaswa April, 2010

Advised by Professor Oliver E. Williamson

Undergraduate Honors Thesis Department of Economics, U.C. Berkeley

Software Development Strategy

Assistance provided by Professor Steven Tadelis, my family, and particularly my thesis advisor, Professor Oliver Williamson, is greatly appreciated.

2


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


Table of Figures Figure 1: Typical Organizational Modes in Software Development ........................................................13 Figure 2: Contractual Schema ........................................................................................................................27 Figure 3: Evolution of Major Software Engineering and Management Methodologies .......................31 Figure 4: Aggregated Survey Results .............................................................................................................35 Figure 5: Case Study Questionnaire ..............................................................................................................56

4


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

added dimension of “making” or “buying” offshore. Motivated primarily by access to specialized

skills and relatively inexpensive labor in developing countries, firms of all shapes and sizes have

increasingly turned to offshore vendors1. 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


became apparent to the management: (1) lack of domain knowledge2 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

IronPort’s technologies and needs could be used instead of those who would need to learn from

scratch. However, moving projects farther outside the firm’s 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 Cisco’s 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 IronPort’s offshore centers.

6


Make-or-buy decisions fundamentally require consideration of distinct modes of governance.

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 firm’s strategic alternatives requires identifying the key factors.

Unfortunately, as the IronPort case demonstrates, the relevant factors for such an analysis may not

always be transparent to decision makers.

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.

I hypothesize that incorporating transaction factors can improve the accuracy of

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


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

five interesting, representative cases and make preliminary conclusions.

(1.1.) The (Many) Roles of Software 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 1980’s, 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

vendors (Lee et al, pp. 198; Hirschheim et al, pp. 5).

Researchers sometimes obscure differences between various software applications. In their

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


firm is uniquely complex may be a good candidate for outsourcing to a vendor with extensive prior

experience.

(2.) Literature Review 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

last consider two studies which make novel contributions.

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.

Comparative economic organization linked to transaction costs has been empirically

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


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 “large5” (Aubert et al, 1996;

Lacity and Hirschheim), they have not been found to consistently overwhelm production cost

savings in the outsourcing decision calculus.

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

are identified in detail in the following section.

Wang (2002) determines whether asset specificity6 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

with project success.

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 industry…Although 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


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

this observation to justify evaluating outsourcing as a standalone organizational configuration rather

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

separately but always in relation to alternatives” (Williamson, 1991). My paper considers

disequilibrium contracting in section 3.5.

(3.) Analytical Framework: Comparative Economic Organization

Textbook, neo-classical microeconomics simplifies by introducing a series of strong

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

organization and behavior of firms in practice.

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

7 Many 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


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 “buys”—although, in the end,

provision for production cost differences need to be made.

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 costs…have 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:

economizing on production expense and economizing on transaction costs” (Williamson, 1979).

(3.1.) Modes of Economic Governance

Comparative economic organization as developed by Williamson identifies alternative

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


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

and rely on complex, relational contracts to protect market exchange.

Figure 1: Typical Organizational Modes in Software Development

Enterprise Software Development

Make (Hierarchy)

Buy (Hybrid)

Outsource Domestically

Outsource Offshore

Produce In-House Domestically

Produce In-House Offshore

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.

Hierarchical transactions include in-house production either domestically or abroad. These

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


differentiated from market governance by its relative complexity, and from hierarchical governance

by dealings with an outside vendor(s).

Complex transactions are frequently subject to unforeseeable disturbances. The comparative

appropriateness of alternative governance structures hinges crucially in their differential capacity to

make coordinated or autonomous adaptations as these disturbances arise. Coordinated adaptations

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

should be anticipated for efficient decisions:

(1) External. Introduction of new tax codes necessitates adjustment of internal accounting,

finance and legal software. Innovations require companies to modify or produce

software which is compatible with these new technologies.

(2) Client side. If a firm learns its consumers desire more features, software must be re-

engineered or a better product must be built to accommodate.

(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

coordinate during projects.

14


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

the characteristics of the asset to be transacted; find the best match.

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

a powerful role in organizational decisions.

Domestic, compared to multi-national, hierarchies have more transparent interactions with

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,

2004). Offshore development is driven significantly by access to skilled, yet comparatively

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).

Hybrid governance forms which correspond to outsourcing arrangements of even modest

complexity provide access to specialized skills and vendor expertise (Currie, 2000). However, when

15


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 party’s 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)

for the same reasons described with respect to offshore hierarchies.

(3.2.) Project and Asset Attributes

In the TCE schema, the attributes of transactions to which differential adaptation needs

accrue derive primarily from frequency, uncertainty, and asset specificity.

(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


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 VW’s 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

investment relative to the value added to the firm decreases.

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


(3.2.2.) Asset Specificity 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

vendor’s 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 VW’s specifications (Arnold, 2000). In this case, the client

and vendor are bilaterally dependent. From the vendor’s 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

if…redesigned…In such cases quite often a total loss must be accepted if the original use is

18


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

outsource (Ellram et al, 2008).

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 firm’s 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 vendor’s 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

“Uncertainty is the source of disturbances to which adaptation is required” (Williamson,

2005, 2008). Because individual agents lack perfect foresight, all complex contracts are vulnerable to

19


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

appropriate because of its ability to make coordinated adjustments by fiat.

This paper argues procedural and environmental uncertainties are major variables in software

development. Procedurally, software development often progresses in an adaptive, sequential way; as

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

timely and compatible combined response” (Williamson, 1991).

Second, progress is difficult to measure and monitor. Different programmers employ

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 client’s systems and

product line. Circumstances where accountability is lacking are “ripe for opportunistic supplier

behavior” (Ellram et al, 2008).

20


Environmental uncertainty pertains to an organizational decision’s context. Offshore

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 Organization’s 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

attributes of a particular transaction render it vulnerable to such exogenous variables, outsourcing

will become less attractive.

(3.2.4.) Production Costs

Software is in essence the application of specialized languages. By virtue of its intangibility,

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


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

international regions by 2004 (Carmel and Tjia, pp. 4).

Ceteris paribus, firms can now outsource to production locations with inexpensive labor.

The lure is strong: “a master’s 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


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

catastrophic transaction outcomes referred to in the introduction make clear.

(3.3.) Transaction Support 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

credible commitments” (Williamson, 2008). As circumstances change and projects become

increasingly well defined, contracts are often renegotiated (Wang, 2002) and progress from one form

to another, as appropriate.

(3.3.1.) Legal Contracting 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


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 client’s

reliability and the complexity of their technology.

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


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 vendor’s 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

suppliers” (McKinsey, 2009).

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

objective third parties (Tafti, 2005).

(3.3.2.) Relational Norms

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

(Ang and Straub, pp. 51).

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

customized software development, “reputation can be an asset” that provides indication 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


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-

ups and encourage specific investments by … the transactors” (Wang, 2002).

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).

(3.4.) Discriminating Alignment Framework

The contractual schema in figure 28 depicts the relationship between different transaction

attributes and governance structures. Asset specificity denoted as K plays a fundamental role in

choosing between alternative governance strategies. In node B, procuring turnkey applications is an

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

forms of governance where a lack of contractual safeguards (S = 0) leaves potential hazards

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

increased complexity of international transactions, domestic outsourcing (D1) requires less

8 Williamson (2002, 2008) develops the fundamental version of this contractual schema. I have made modifications for software development strategy.

26


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

hierarchical organization. These configurations are favored as disturbances become increasingly

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

enterprise is managed multi-nationally. Time, distance, and cultural dissimilarities in different

geographical locations, as explained in section 3.1, magnify coordination costs within the firm.

Figure 2: Contractual Schema

(3.5.) Extensions and Qualifications 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


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

in non-academic research (Gartner, 2009-2010).

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

outsourcing and offshoring.

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

transactions are pursued. As Williamson formulates it:

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

timeliness is the challenge (Williamson, 2008).

28


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-

1990s onwards, increasingly turned to outsourcing as a panacea to manage the dilemma of

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 TCE’s 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


This is made clear by looking at the evolution of software development methodologies.

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

minimum, it is worthy of consideration.

Speed is also not a given. If a vendor’s 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 model9 (Rao,

2004; Gonzalez et al, 2006; Mockus and Herbsleb, 2001; Beulen et al, 2005). Because software

development is often highly collaborative, implications of miscommunication can be significant. For

example, while minor problems can be addressed amongst an in-house team by walking to a

coworker’s 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 client’s workday starts, to be followed up by

another email when the vendor’s next workday starts, can continue cyclically, resulting in substantial

9 Client and vendor operate in different time zones so that when one team’s workday ends, the other’s begins.

30


delays (Mockus and Herbsleb, 2001). As it turns out, these problems can sometimes be averted by

giving vendors significant ownership over projects, so back-and-forth communication is less

necessary. For example, having the vendor do all the programming and the client do all the testing

can, if instituted properly, take advantage of the near 24-hour-workday.

Figure 3: Evolution of Major Software Engineering and Management Methodologies

Software Development Methodology Eras10

Pre-Methodology Era

1960s – 1970s

Early Methodology Era Late 1970s – Early 1980s

Methodology Era Late 1980s – 1990s

Post-Methodology Era Late 1990’s – Today

Mature SDLC (Waterfall Model)

Widespread adoption of the

SLDC model.

Object-Oriented

Programming (OOP)

Dominant mode of programming during mid-

1990s which requires careful construction of a

programming by creating a broad set of fundamental objects (data blocks) and

building up.

Extreme Programming (XP)

Prototyping with little to no planning, allowing constant modification of applications

and frequent release of builds based on user

feedback.

Rapid Application

Development (RAD)

Sacrifices planning stages in favor of prototyping

software designs to reduce project turnaround time.

Early Systems Development Life Cycle

(SDLC)

Very structured and deliberate process driven

framework. Each development stage must be completed before moving

onto next stage.

Structured Systems Analysis and Design

Methodology (SSADM)

Documentation heavy process focused on careful and meticulous planning prior to programming.

Scrum

Careful division of tasks among programmers to

allows for different stages to be completed simultaneously.

Accelerated RAD

Applies the 1990s RAD process to an even shorter

timeframe.

10 Avison and Fitzgerald (2003) and Maurer and Martel (2002).

31


(4.) Methodology: Case Study Analysis I conducted phone and/or face-to-face interviews with 14 companies, each conversation

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

correctives need to be applied to increase consistency?

Ultimately, the goal of framework development is empirical confirmation using statistical

analyses. Make alignment predictions, observe real-world behavior and compare. Several factors

32


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.

However, there are obvious shortcomings to my approach. First, how do we determine if a

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 client’s perspective. Does this obscure

any important dynamics?

(5.) Case Studies

The summary of transaction attributes, as determined by interviewees, in the areas of

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


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

significantly. As will become clear, MobileMaster presented an extraordinarily interesting set of

transactions which it would be detrimental to omit.

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

complete set of questions posed is available in the appendix.

34


Figure 4: Aggregated Survey Results

(0: Not Applicable; 1: Insignificant; 2: Moderately Significant; 3: Significant)

LogSim MobileMaster YourLive LCDInternational AppGenie Production Costs 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 Internal Labor Shortage 3 2 3 3 3 2 3 3 Local Labor Shortage 1 1 1 1 1 1 3 3 Time-to-Market 3 2 2 3 2 3 2 3 Contracting / Safeguarding Due Diligence Intensity 0 1 1 1 1 3 0 2 Contracting Intensity 0 1 1 1 1 1 2 3 On-Site Monitoring 0 0 0 0 0 1 0 0 Tracking Software 0 0 1 1 1 1 0 2 Informal Communication 3 1 1 2 2 3 0 2

35


(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,

purposely left anonymous, in the chip design industry.

(5.1.1.) Historical Events

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 LS’s chip design work soon

thereafter. LS hired the vendor’s 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 LS’s 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

released the beta version of its logic simulation software.

36


(5.1.2.) Analysis

LS’s organizational strategy evolved significantly over time. My proposed framework is

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

candidate for offshore outsourcing? Our discriminating alignment methodology is equipped to

attempt answers to both.

Key Motivations Labor Shortage, Cost Savings Frequency Recurrent Asset Specificity High: Idiosyncratic Skills Procedural Uncertainty High: Weakly Defined Specifications Environmental Uncertainty Mixed: Somewhat Sensitive

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 LS’s software projects suggest offshore hierarchical

governance is favored. (1) Frequency was recurrent. Because the software being developed was LS’s

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 LS’s

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


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 LS’s

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

buildup more experience.

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, LS’s 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

within their enterprise.


MM first considered outsourcing because the prospect of substantially increased manpower

at a low cost was “seductive.” And, because one of the firm’s board members had success offshore

outsourcing in other ventures, it seemed a workable strategy.

38


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. “There’s 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

been previously completed by MM and lacked precise specifications. Coordination and

communication difficulties quickly became overwhelming. Requirements changed constantly, and

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

MM to continuously re-explain its evolving needs.

Second, MM outsourced development of software reports to a Chinese firm which had

performed well for MM’s 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


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

development back in-house.

Last, MM outsourced a project to build multimedia applications using the Microsoft

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 team’s work was low quality and “things which

needed to be done elegantly were done with force” (Baar). The project was moved back to MM

prematurely, before even the first cycle was completed.

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

Key Motivations Labor Shortage, Cost Savings Frequency Recurrent Asset Specificity High: Idiosyncratic Skills Procedural Uncertainty High: Weakly Defined Specifications Environmental Uncertainty Mixed: Somewhat Sensitive

40


Failures make for interesting case studies. Because each of these projects is technologically

distinct, I will consider them separately.

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 company’s 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 company’s 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 company’s 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 MM’s 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

remained in-house. However, MM chose to outsource to an offshore vendor. Sources of contractual

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


Key Motivations Labor Shortage, Cost Savings Frequency Recurrent Asset Specificity Low: Idiosyncratic Skills Not Required Procedural Uncertainty Low: Well Defined Specifications Environmental Uncertainty Low: Insensitive

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

speed of their delivery was important to MM.

Considering both production and transaction attributes, outsourcing is clearly appropriate.

MM felt similarly (their rationale was primarily the well-defined specifications) and selected a vendor

owned by the CEO’s personal friend. However, the transaction invariably failed and was brought

42


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.

Key Motivations Labor Shortage, Cost Savings Frequency Occasional Asset Specificity Mixed: Somewhat Idiosyncratic Skills Procedural Uncertainty Mixed: Somewhat Well Defined Specifications Environmental Uncertainty Low: Insensitive

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

firm’s 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 MM’s 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


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 team’s progress. The vendor was chosen

because they had the requisite knowledge to pursue creative solutions which met MM’s vague needs.

(4) Environmental uncertainty was negligible because of the distance of this particular application

from MM’s 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

for relatively rapid project turnaround.

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

project being brought back in-house.

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


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

time variables is beyond the scope of the model as is.

Key Motivations Labor Shortage, Cost Savings Frequency Occasional Asset Specificity Mixed: Somewhat Idiosyncratic Skills Procedural Uncertainty Mixed: Somewhat Well Defined Specifications Environmental Uncertainty Low: Insensitive

MM last outsourced development of applications using the Microsoft Silverlight framework.

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 company’s 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 MM’s inexperience. (4) Environmental

uncertainty was insignificant because these applications were only tangentially relevant to MM’s

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


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

LCDInternational is a company which uses LCD monitors as a multimedia platform. While

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

into LCD screens sourced from China and Taiwan.


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


suited for their business model. However, after realizing all their potential partners were located in

Bangalore, they changed their plans.

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

its core engineering team in Bangalore.

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 company’s

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


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

(from another country).

Key Motivations Convenience, Cost Savings Frequency Recurrent Asset Specificity High: Idiosyncratic Skills Procedural Uncertainty High: Weakly Defined Specifications Environmental Uncertainty High: Very Sensitive

The production attributes suggest that outsourcing would be most cost effective because in

addition to providing the same low-cost labor, the vendor’s 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 LCDI’s

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 firm’s first-mover advantage at risk. (5) Disequilibrium conditions play an important role. As

part of a product both interviewees categorized as “of the future,” LCDI’s software development

48


strategy must be capable of responding to new developments quickly. Only the experienced internal

employees are capable of providing that kind of flexibility.

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

some overlapping work.

(5.4.) AppGenie

AppGenie is a multimedia applications developer on the Facebook and Myspace social

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


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 AI’s unique domain knowledge and 3-D art talent, they were able to charge prices comparable to

American vendors despite relying on offshore studios and employees.

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 AG’s.

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 AG’s decision

to outsource application development appropriate? Second, was AG’s decision to acquire AI and

move that software development in-house appropriate?

Key Motivations Labor Shortage Frequency Recurrent Asset Specificity High: Idiosyncratic Skills Procedural Uncertainty High: Weakly Defined Specifications Environmental Uncertainty High: Very Sensitive

50


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 AI’s 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

intermittently necessary (according to interviewees). However, because AG constantly develops

applications, they were not as poorly equipped to make informed judgments about AI’s 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

exhibited prominently, as time-to-market considerations are central to competitive survival, and

applications must be developed in concert with exogenous changes in the Myspace and Facebook

technological platforms.

As a result, while all equilibrium signs point to hierarchical governance, real-time

responsiveness motivates outsourcing. Developing the requisite talent for building 3-D art in-house

would have been a timely process that compromised AG’s position in the competitive environment.

Thus, they outsourced to AI, but invested heavily in due diligence and contracting. Giving AI

51


substantial project ownership also played a role in partially realigning incentives, as explained

generally in section 3.3.1.

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 AG’s specialized skills, AI became

increasingly capable of emerging as a competitor. The decision to transition from offshore

outsourcing to hierarchical offshoring was a response to this threat.

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

disequilibrium conditions which accentuated real-time responsiveness concerns. And, vertical

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

in favor of adapting in real-time by contracting an outside vendor?

(5.5.) YourLive YourLive is an internet software company which allows consumers to broadcast video or

other computer activity to the public on personal internet channels.


Recently, YL decided they needed to develop an application which could tap into

Facebook’s 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


relatively difficult process. An Indian firm which one of YL’s employees had used previously was

contracted. This project is still in progress.

Several benefits were identified to outsourcing over in-house development. The driving

factor was the ability to spend more resources focused on YL’s 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 vendor’s

knowledge of YL’s 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

project results are observable.

53


Key Motivations Labor Shortage, Cost Savings Frequency Occasional Asset Specificity Mixed: Somewhat Idiosyncratic Skills Procedural Uncertainty Low: Well Defined Specifications Environmental Uncertainty Mixed: Somewhat Sensitive

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 vendor’s 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 YL’s core code. However, the vendor was not in a position to become

a competitor. And, YL’s 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, YL’s decision to outsource with a minimalistic contract

54


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

transaction with this vendor.

(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).

Whether my analytical framework applies to organizational decisions made by foreign companies

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

treatments including monitoring and coordinating relationships, as well as threats of opportunistic

behavior, were evident in many of the real world decisions observed. Though each of the

shortcomings identified must be overcome before nearing completeness, an honest assessment of

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


(7.) Appendix

Figure 5: Case Study Questionnaire Production Costs (3: Very Significant; 2: Somewhat Significant; 1: Insignificant; 0: Not Applicable)

Labor Was labor cost significant? (0-3):

Capital Was the purchase of technology or machines significant? (0-3):

Land Was the purchase of facilities, factories, etc. significant? (0-3):

Shipping / Communications Were shipping / telecommunications costs significant? (0-3):

Transaction Costs: Frequency (Daily or Weekly: 3; Monthly or Biannually: 2; Annually or more: 1; Not Applicable: 0)

Maintenance How often does the maintenance team need to work on the technology? (0-3):

Re-engineering / New Releases How often are new versions released? (0-3):

New Products in Same Area How often would you / do you do new projects in a similar area? (0-3):

Transaction Costs: Asset Specificity Answer key: (3: Very Significant; 2: Somewhat Significant; 1: Insignificant; 0: Not Applicable)

Specialized Skills

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?

(0-3):

Customized Was the software specialized and customized? (0-3):

Core Product Was this project for part of the

company’s core, or was it a side / supplemental project?

(0-3):

Transaction Costs: Uncertainty (3: Very Significant; 2: Somewhat Significant; 1: Insignificant; 0: Not Applicable)

Procedural: well-defined specifications

Were the project’s specifications well-defined at the outset? (0-3):

Procedural: measurability / verifiability Was progress easy to measure? (0-3):

Procedural: transparent / easy to see what vendor was doing Was the work done transparently? (0-3):

Procedural: extensive communication necessary

Was a lot of communication necessary to convey project needs? (0-3):

Procedural: coordinating with offshore team

Was a lot of back-and-forth coordination necessary, or did you simply hand it off and wait for the results to be delivered?

(0-3):

Technological: need to build new technologies and products

Was this project for a new technology your business was interested in? (0-3):

Technological: new platforms (eg Facebook, cloud, etc.)

Was this project a way of adapting to new technologies? (e.g. Facebook

application, cloud computing, Silverlight, etc.)

(0-3):

Environmental: Legal, security, IP Was data security / privacy an issue? (0-3):

56


Transition Costs (3: Very Significant; 2: Somewhat Significant; 1: Insignificant; 0: Not Applicable)

Moving Out Was it difficult to transfer the work to the team / vendor? (0-3):

Moving In Was it difficult to integrate the team’s result into the company’s product line? (0-3):

Disequilibrium Conditions (3: Very Significant; 2: Somewhat Significant; 1: Insignificant; 0: Not Applicable)

Labor Shortage Was there a deficit of workers who had the requisite knowledge to work on the

project?

In the firm (0-3): Locally (0-3):

Needed to Develop Product Quickly

Was project turnaround time a significant concern? (0-3):

Contracting / Safeguarding (3: A lot; 2: Some; 1: Little; 0: Not Applicable)

Due Diligence / Background Checking

Did you do a lot of background research on the vendor? (0-3):

Writing Contracts Did you spend a lot of time writing contracts? (0-3):

Monitoring: people on-site Did you have somebody / people on the vendor’s site monitoring progress and/or

managing? (0-3):

Monitoring: tracking software Did you use collaboration tools or tracking software to monitor the

vendor’s progress?

Please Also Provide Brief Explanation

(0-3):

Monitoring: informal communication

What types of communication technologies were used? (e.g. Instant

Messaging, Skype, E-mail, etc.)

Please Also Provide Brief Explanation

(0-3):

57


(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. Arnold, Ulli. (2000). New Dimensions of Outsourcing: A combination of Transaction Cost Economics and the Core Competencies Concept. European Journal of Purchasing and Supply Management, 6, 23-29 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. Computer Economics: Metrics for IT Management. (2009-2010). IT Outsourcing Statistics 2009/2010: Outsourcing Trends and Cost Experiences for 11 Key IT Functions. 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. 5–39 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 World’s 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. Dun & Bradstreet. (2002). Barometer of Outsourcing. Ebert, Christof and De Neve, Philip. (2001). Survival Global Software Development, IEEE Software, March / April.

58


Ellram, Lisa et al. (2008). Offshore Outsourcing of Professional Services: A Transaction Cost Economics Perspective. Journal of Operations Management, 26, 148-163. Fitzgerald, Michael. (2003). “At Risk Offshore,” CIO Magazine, November 15. Gartner. (2009). Gartner on Outsourcing, 2009-2010. December 23. Gold, Tandy. (2005). Outsourcing Software Development Offshore: Making it Work. 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), 89–116. Gupta, Amar. (2008). Outsourcing and Offshoring of Professional Services: Business Optimization in a Global Economy. Henisz, Witold and Williamson, Oliver. (1999). Comparative Economic Organization—Within 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 Input. (1999b). IS Outsourcing Soars in 4Q 98, Plummets in 1Q 99. www.input.com/public/article31.cfm 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


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. Loh, Lawrence. (2004). An Organization-economic blueprint for information technology outsourcing: concepts and evidence. In: Proceedings of the Fifteenth International Conference on Information Systems, Vancouver, DeGross, J.I., Huff, S.L.& Munro, M.C.(eds), pp. 73–90. Lyons, Bruce R. (1996). Empirical Relevance of Efficient Contract Theory: Inter-Firm Contracts. Oxford Review of Economic Policy. 12:4, pp. 27–52. 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, 26–27 April. Masten, Scott and Stephane Saussier. (2000). Econometrics of Contracts: An Assessment of Developments in the Empirical Literature on Contracting. Revue d’Economie Industrielle. Second and Third Trimesters, 92, pp. 215–36 Maurer, Frank and Martel, Sebastian. (2002). Extreme Programming: Rapid Development for Web-Based Applications. IEEE Internet Computing, January/February. McKinsey. (2009). How Innovators are Changing IT Offshoring. McKinsey on Business Technology. Number 17. 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. Nam, Kichan. (1996). A Two-Level Investigation of Information Systems Outsourcing. Communications of ACM, 39 (7), 36–44. Oracle. (2010). Communications Products. Accessed: March 2010. http://www.oracle.com/us/industries/communications/046718.html

60


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. 30–54 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. 335–61 Simon, Herbert. (1985). Human Nature in Politics: The Dialogue of Psychology with Political Science. American Political Science Review, 79, pp. 293–304 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. Venkatraman, N. (1997). Beyond Outsourcing: Managing IT Resources as a Value Center. Sloan Management Review, Spring. 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. Williamson, Oliver. (1979). Transaction-Cost Economics: The Governance of Contractual Relations. Journal of Law and Economics, 21, 2, October, 233-262.

61


Williamson, Oliver. (1985). The Economic Institutions of Capitalism: Firms, Markets, Relational Contracting. Williamson, Oliver. (1991). Comparative Economic Organization: The Analysis of Discrete Structural Alternatives. Administrative Science Quarterly, 36, 269-296 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

Thesis: Software Development Strategy: A Practical Application of Transaction Cost Economics

Documents

Transcript of Thesis: Software Development Strategy: A Practical Application of Transaction Cost Economics