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

Software Development Strategy

Table of Contents Abstract ...............................................................................................................................................................5 (1.) Introduction.................................................................................................................................................5 (1.1.) The (Many) Roles of Software ..........................................................................................................8 (2.) Literature Review ........................................................................................................................................9 (3.) Analytical Framework: Comparative Economic Organization ..........................................................11 (3.1.) Modes of Economic Governance...................................................................................................12 (3.2.) Project and Asset Attributes............................................................................................................16 (3.2.1.) Frequency....................................................................................................................................16 (3.2.2.) Asset Specificity .........................................................................................................................18 (3.2.3.) Uncertainty .................................................................................................................................19 (3.2.4.) Production Costs .......................................................................................................................21 (3.3.) Transaction Support .........................................................................................................................23 (3.3.1.) Legal Contracting.......................................................................................................................23 (3.3.2.) Relational Norms.......................................................................................................................25 (3.4.) Discriminating Alignment Framework ..........................................................................................26 (3.5.) Extensions and Qualifications.........................................................................................................27 (4.) Methodology: Case Study Analysis.........................................................................................................32 (5.) Case Studies ...............................................................................................................................................33 (5.1.) LogSim ................................................................................................................................................36 (5.1.1.) Historical Events .......................................................................................................................36 (5.1.2.) Analysis .......................................................................................................................................37 (5.2.) MobileMaster .....................................................................................................................................38 (5.2.1.) Historical Events .......................................................................................................................38 (5.2.2.) Analysis .......................................................................................................................................40 (5.3.) LCDInternational..............................................................................................................................46 (5.3.1.) Historical Events .......................................................................................................................46 (5.3.2.) Analysis .......................................................................................................................................47 (5.4.) AppGenie ...........................................................................................................................................49 (5.4.1.) Historical Events .......................................................................................................................49 (5.4.2.) Analysis .......................................................................................................................................50 (5.5.) YourLive.............................................................................................................................................52 (5.5.1.) Historical Events .......................................................................................................................52 (5.5.2.) Analysis .......................................................................................................................................53 (6.) Conclusion .................................................................................................................................................55 (7.) Appendix ....................................................................................................................................................56 (8.) References ..................................................................................................................................................58

3

Software Development Strategy

Table of Figures 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

Software Development Strategy

Abstract Software development strategy has become increasingly complex in the global age. Decisions about whether to make-or-buy, to develop in-house or acquire from an outside vendor, now face the 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 vendors 1 . However, the failure rate is notably high. This begs two questions. First, when are offshore development and outsourcing appropriate? Second, when appropriate, what kind of (legal and relational) support increases the likelihood of project success? Previous economic investigations rely primarily on production factors such as wages and the cost of machines and technology to explain why many firms choose offshore outsourcing over other organizational configurations. However, researchers consistently find that the source of contractual strain which leads to outsourcing failure lies in transactional, rather than production, variables such as monitoring and coordinating with vendors. This suggests a more complete comparative analysis of alternative software development strategies would also include transaction costs. The framework I propose to accomplish this is generally supported by the case studies analyzed in the second half of the paper. (1.) Introduction IronPort Systems first outsourced software development in 2003. As a major web security company, their products serve as “the ‘main switch’ for email and Web traffic into and out of the largest companies in the world (42 of the G100)” (IronPort Systems, 2006). Outsourcing was conceived to “keep up with the demand for new features while keeping development costs low” (IronPort Systems, 2006). IronPort hired an offshore vendor to provide increased manpower and cooperate with the preexisting engineering team on projects. Three crucial shortcomings quickly
1

Gartner (2009-2010), Computer Economics (2009-2010), Deloitte (2005, 2008), and Morrison and Foerster (2009).

5

Software Development Strategy

became apparent to the management: (1) lack of domain knowledge 2 diminished the overseas teams’ contributions, (2) lack of accountability compromised quality control, and (3) time differences and long-distance communication were inefficient and caused delays. In 2005, the staff augmentation model used initially was replaced in favor of assigning outside teams projects for independent completion. Progress was tracked remotely using monitoring applications. To reduce “ramp-up time” resulting from training a new batch of engineers for each project, offshore teams would work on similar projects consecutively (IronPort Systems, 2006). This way, engineers familiar with 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.
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.
2

6

Software Development Strategy

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

Software Development Strategy

closely tracks Williamson (1985, 1991), with special emphasis on the critical factors for software development strategy. I proceed in four parts. First, I provide some background on the role of software in enterprises. Second, I briefly discuss the state of the existing literature. Third, I introduce a framework for comparative economic organization, starting with nonspecific descriptions of the theoretical constructs developed (primarily) in transaction cost economics (TCE), and followed by contextualization to software development decisions. Last, I use the proposed framework to analyze 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

Software Development Strategy

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 realworld behavior is consistent (Poppo and Lacity, pp. 211). However, when applied to IT the results

4

Williamson (2002) identifies the following studies as a testament to the success of empirical testing: Shelanski and Klein (1995), Lyons (1996), Crocker and Masten (1996), Rindfleisch and Heide (1997), and Masten and Saussier (2000). More recently, Macher and Richman (2008) conducted a review of empirical TCE studies in various social science and business fields.

9

Software Development Strategy

have been generally discouraging (Nagpal, 2004; Loh, 1994; Nam et al, 1996; Grover et al, 1996; Lacity and Willcocks, 1996). While transaction costs are unambiguously “large 5 ” (Aubert et al, 1996; Lacity and Hirschheim), they have not been found to consistently overwhelm production cost 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 specificity 6 and transaction uncertainty (explained in detail in the following section) can be used to predict software development project performance. He hypothesizes that when highly asset specific and uncertain projects are outsourced, the chance of failure is relatively high. His major findings, for my purposes, are threefold. First, in contrast to his hypothesis, asset specificity is positively correlated with project success. Second, uncertainty is negatively correlated with project success, though statistical significance is weak at (p < .1). Third, intuitively, he also finds that positive perceptions of contractor reputation are positively associated 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 “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.
5

10

Software Development Strategy governance structure, because, after all, the survivability of an organization form depends on its performance (Wang, 2002).

Instead of considering differences between equilibrium and disequilibrium decision making, he uses 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

Software Development Strategy

forms, but those on which TCE relies are associated with adaptation (especially maladaptation of a comparative institutional kind). The paradigm problem for this purpose is not the employment relation (as recommended by Coase and others), but the intermediate product market (outsourcing) decision. So as to focus on hitherto neglected transaction costs, production technologies and labor costs are assumed to be the same whether a firm “makes” or “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

Software Development Strategy

organization wherein firms “make” rather than “buy” an intermediate good or service, subject to oversight by the management. Hybrid forms of governance lie in between markets and hierarchies 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)

Produce In-House Domestically

Produce In-House Offshore

Outsource Domestically

Outsource 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

Software Development Strategy

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

Software Development Strategy

In this light, the primary benefit of TCE is that it takes a symmetrical approach in predicting alignments: identify the strengths and weaknesses of alternative governance structures; determine 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

Software Development Strategy

the software in question is being custom built around unique needs, project completion generally requires “a high degree of interaction” and coordination between client and vendor (Beulen et al, 2005). When needs and specifications change, as they frequently do during software development, both parties must adjust together (Ellram et al, 2008). Adjustment processes are complicated by a lack of transparency resulting from the absence of face-to-face to communication (“corridor talk”; Herbsleb and Moitra, 2001) as well as misaligned incentives: “each 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

Software Development Strategy

annihilates need for coordinated adaptation; absent frequency, transactions possess little to no intertemporal attributes. In contrast, occasional and recurrent transactions carry varying implications for reputation effects and setup costs. Exposure to behavior on multiple transactions allows the client to develop a positive or negative impression of the vendor. At the same time, initial setup costs are eroded as transaction frequency increases if those purchases can support subsequent transactions. In traditional hardware industries, the concept is intuitive. Take, for example, Volkswagen, which outsources the vast majority of its production process (Arnold, 2000). Each time a new fleet of cars is desired, VW places another order with their chosen vendors. Over time, good and bad performance becomes known and eligibility varies accordingly. With respect to physical capital, vendors that have good experiences are increasingly willing to invest in equipment and technologies to build 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

Software Development Strategy

(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

Software Development Strategy

finished” (Arnold, 2000). To the client, alternative suppliers lack such equipment and are therefore less eligible for contracting. Assets such as these, where parties to a transaction become locked-in, possess a degree of specificity. Where it is high, clients should “make” rather than “buy.” With software, asset specificity is primarily a function of human capital, which follows from its intangibility (Wang, 2002). In these cases, clients can more easily use the same vendor because their expertise and know-how eliminates need to extensively train new workers for similar future projects. However, as in hardware industries, the redeployable value of such human capital is less in alternative uses. “The existence of specific know-how and skills and the difficulties of knowledge transfer mean that it will be costly for the parties to switch to a new relationship” (Wang, 2002). Empirical studies have shown that in the case of high asset specificity, managers tend not to 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

Software Development Strategy

unforeseen contingencies and thus “unavoidably incomplete” (Williamson, 2005). The degree of incompleteness plays an important role in determining which governance structure is most efficient for a particular transaction. As uncertainty and adaptive needs grow, hierarchy is increasingly 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

Software Development Strategy

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

Software Development Strategy

technological equipment, setup costs are typically one-time expenditures which support many projects. Labor conceptualized as time spent researching, programming, testing, and maintaining thus factors dominantly into production cost analysis (Beulen et al, 2005). Therefore, offshore organizational modes which provide significant labor cost savings have an advantage for many software projects. This was not always the case. Technologies used to communicate and coordinate with offshore vendors were previously very expensive (Smith et al, 1996; Gonzalez et al, 2006; Carmel and Tjia, pp. 4) and often incapable of handling the volume of data involved in software projects (Khan et al, 2002; Carmel and Tjia, pp. 3-4). “It was only in 1994 that one of the pioneering project managers offshoring to India had his team copy the weekly software ‘build’ onto tape every Friday just in time for the FedEx pick-up that would fly the tape across the ocean” (Carmel and Tjia, pp. 4). Since then, the cost of communication and information transfer has fallen dramatically, almost to the point of negligibility (Gonzalez et al, 2006; Manley and Hobby, 2004; Doh, 2005; Patel, pp. 10; Robinson and Kalakota, pp. 17; Carmel and Tjia, pp. 10-11; Ellram et al, 2008; Rao, 2004). Compared to the late 1990s and early 2000s, communication costs are 10-20% of what they were, voice over internet protocol, widely used by software workers, has zero marginal cost, and bandwidth, once a precious commodity, was available at four gigabits per second in some 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

Software Development Strategy

so great that there was a consensus [firms] could afford the cost of retraining new employees, and even switching suppliers or regions of the world, if necessary” (Ellram et al, 2008). However, despite this appealing picture, TCE has always been quick to demonstrate the costs incurred during market use. Software development outsourcing is no exception, as many of the 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

Software Development Strategy

contract law, I attempt to describe the primary contractual mechanisms employed to control transaction costs. In the case of software development, because transactions involve transfer of intangible assets and human capital, contracts are more difficult to construct (Lee et al, pp. 201). I begin with contract longevity. “The primary alternative to vertical integration as a solution to the general problem of opportunistic behavior is some form of economically enforceable longterm 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

Software Development Strategy

behavior (Aubert et al, pp. 172). As a supplement, contracts integrate underperformance penalties and baseline quality levels benchmarked by independent third parties (Tafti, 2005; Aubert et al, pp. 172; Carmel and Tjia, pp. 112-129). Third party consulting firms which perform benchmarks have access to data which allows them to compare one 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

Software Development Strategy

reports. For example, the Capability Maturity Model is a widely adopted international assessment framework used to judge the process maturity of most vendors, especially those medium and large in size, and identify areas for improvement (Pfannenstein and Tsai, 2004). As a result, clients are more likely to choose vendors with strong reputations, while “reputation effects may [discourage] holdups 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 2 8 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

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

26

Software Development Strategy

contractual support to achieve the same level of security as offshore outsourcing (D2). And, because the risks incurred in the C nodes are greater than those in the D nodes, they will be priced higher by vendors, ceteris paribus. Finally, nodes E1 and E2 represent transactions which are governed best by 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

Software Development Strategy

purportedly inappropriate. Before concluding this way, we must consider whether disequilibrium changes the criteria for “appropriateness.” To be sure, running a business is not easy. “The challenges for the firm of maintaining competitive advantage in the face of pressures to reduce costs and shift production brought about by shifting technology, markets, and competition, the principal forces at work in offshoring” are significant (Doh, 2005). These opinions have been voiced similarly 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

Software Development Strategy

Examples of such innovations are numerous. The introduction of new operating systems (e.g. Windows 1995, 2000, ME, XP, Vista, 7), new technology platforms (e.g. MS-Dos, Windows, Web-based), and the like necessitate adaptation. If outsourcing vendors are better able to deal with exogenous changes, they may be preferred for these tasks. When legacy systems based around mainframes and data centers were perceived as outdated compared to client/server and distributed networks, IT managers needed to transition their entire systems quickly without compromising the overall business (Currie, 2000; Venkatraman, 1997). As a result, “CIOs and IT directors in the mid1990s 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-tomarket constraints” (Herbsleb and Moitra, 2001). “Need to shorten the development time cycle of IS projects … has significantly increased the demand for more flexibility for IT enterprises, which do not have enough time to create and maintain adequately trained human resources that can cope with the volatility of the demand and the heterogeneity of its projects” (Gonzalez et al, 2006). Under these circumstances, if outsourcing vendors can provide flex capacity, their use may be the favored mode of organization.

29

Software Development Strategy

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 model 9 (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

Software Development Strategy

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 Eras 10 Pre-Methodology Era 1960s – 1970s Early Methodology Era Late 1970s – Early 1980s Methodology Era Late 1980s – 1990s Object-Oriented Programming (OOP) Mature SDLC (Waterfall Model) Widespread adoption of the SLDC model. Early Systems Development Life Cycle (SDLC) Very structured and deliberate process driven framework. Each development stage must be completed before moving onto next stage. Dominant mode of programming during mid1990s which requires careful construction of a programming by creating a broad set of fundamental objects (data blocks) and building up. Rapid Application Development (RAD) Structured Systems Analysis and Design Methodology (SSADM) Documentation heavy process focused on careful and meticulous planning prior to programming. Sacrifices planning stages in favor of prototyping software designs to reduce project turnaround time. Scrum Careful division of tasks among programmers to allows for different stages to be completed simultaneously. Post-Methodology Era Late 1990’s – Today

Extreme Programming (XP) Prototyping with little to no planning, allowing constant modification of applications and frequent release of builds based on user feedback.

Accelerated RAD Applies the 1990s RAD process to an even shorter timeframe.

10

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

31

Software Development Strategy

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

Software Development Strategy

caused me to opt for case study analysis. First, microanalytic data, required to determine, for example, asset specificity and procedural uncertainty levels, is extraordinarily difficult to gather for high-technology projects in an appropriate scale for econometric analysis. Second, several companies interviewed were hesitant or unwilling to share detailed data, which would create uncontrollable bias. Third, as a matter of choice rather than necessity, I assert that case study analysis is a prerequisite to more quantitative studies. At this early stage, we must first identify the variables which should figure prominently into alignment predictions. Looking at specific cases and drawing out the relevant factors may point out important missing variables to include in future statistical studies. 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

Software Development Strategy

perform the follow-up survey. However, details of each project were discussed in depth during our conversations, so translation into numerical values was transparent and should not distort the data 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

Software Development Strategy Figure 4: Aggregated Survey Results (0: Not Applicable; 1: Insignificant; 2: Moderately Significant; 3: Significant) LogSim MobileMaster YourLive LCDInternational Production Costs Labor Technology / Machines Facilities Shipping / Telecommunications Frequency Maintenance Reegineering Similar Products Asset Specificity Human Capital Physical Capital Core Competency Uncertainty Definition of Specifications Measurability / Verifiability Vendor Transparency Communication Intensity Coordination Intensity New Internal Technologies New External Technologies Data Security / Privacy Transition Costs Moving Out Moving In Disequilibrium Conditions Internal Labor Shortage Local Labor Shortage Time-to-Market Contracting / Safeguarding Due Diligence Intensity Contracting Intensity On-Site Monitoring Tracking Software Informal Communication 0 0 0 0 3 1 1 0 0 1 1 1 0 1 1 1 1 0 1 2 1 1 0 1 2 3 1 1 1 3 0 2 0 0 0 2 3 0 2 2 3 1 3 2 1 2 3 1 2 3 1 3 3 1 2 2 1 3 3 3 2 3 3 3 3 0 1 2 1 0 1 2 1 2 1 2 0 0 3 1 1 1 1 3 3 3 0 2 1 1 1 1 1 1 0 2 3 2 1 1 1 0 0 1 2 2 1 1 1 3 3 1 2 2 1 1 1 3 3 1 3 3 3 2 2 2 3 2 1 3 0 3 0 3 3 3 1 3 2 2 1 1 1 3 3 3 3 3 3 3 1 1 1 2 1 2 2 1 2 2 2 1 3 3 3 3 0 3 3 3 2 3 2 2 0 0 3 2 2 2 2 1 1 3 2 1 3 2 2 3 3 3 3 0 0 0 3 1 0 1 3 0 0 1 3 1 0 1 3 1 0 1 2 1 0 1 2 2 0 1 2 1 0 0 AppGenie

35

Software Development Strategy

(5.1.) LogSim LogSim develops chip design automation software which uses logic simulation (think artificial intelligence) to replace manual testing. They currently focus on a single vertical market, 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

Software Development Strategy

(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 Frequency Asset Specificity Procedural Uncertainty Environmental Uncertainty Labor Shortage, Cost Savings Recurrent High: Idiosyncratic Skills High: Weakly Defined Specifications 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

Software Development Strategy

monitoring progress both essential and difficult, even more so with use of an outside team (outsourcing). (4) Environmental uncertainty was mixed. Though the code is confidential, LS lacks competitors who could take advantage of unauthorized access. The great complexity of 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. (5.2.1.) Historical Events 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

Software Development Strategy

First, MM hired an overseas team to develop part of their core knowledge source. Only a few months later, the contract was prematurely terminated and operations were brought back inhouse. 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

Software Development Strategy

communication became complicated. Tracking and monitoring tools provided by the vendor were inefficient and defeated the point: the management lacked time and resources to micromanage an offshore team remotely. Again, progress was found to be unsatisfactory as the offshore team could not handle evolving specifications. The firm opted to prematurely terminate their contract and bring 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 Frequency Asset Specificity Procedural Uncertainty Environmental Uncertainty Labor Shortage, Cost Savings Recurrent High: Idiosyncratic Skills High: Weakly Defined Specifications Mixed: Somewhat Sensitive

40

Software Development Strategy

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

Software Development Strategy

Key Motivations Frequency Asset Specificity Procedural Uncertainty Environmental Uncertainty

Labor Shortage, Cost Savings Recurrent Low: Idiosyncratic Skills Not Required Low: Well Defined Specifications 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

Software Development Strategy

back in-house. Looking back on section 3.3, we recall that in circumstances where a project is best suited for relatively simple, hybrid market transactions, only some minimum level of legal and relational support is needed to ensure credible vendor commitments. That MM felt “tricked” by a senior engineer who was ultimately uninvolved with the project suggests even these minimal protections were overlooked. Legally stipulating the experience level of engineers staffed, interviewing engineers directly, and carefully monitoring progress, either remotely or by deploying a U.S. employee(s) at the vendor site are recommendations we could have made at the outset to safeguard against opportunistic behavior. Hindsight being 20/20 and unable to test the feasibility of these safeguards given how the project was executed, these recommendations should be taken with a grain of salt. That being said, the contingencies appear foreseeable and the recommendations apt.
Key Motivations Frequency Asset Specificity Procedural Uncertainty Environmental Uncertainty Labor Shortage, Cost Savings Occasional Mixed: Somewhat Idiosyncratic Skills Mixed: Somewhat Well Defined Specifications 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

Software Development Strategy

However, there was a sense of which features would need to be included, even though the specific coding structure was unknown. As needs and product plans changed, MM would have to communicate and coordinate with the offshore vendor. Monitoring would be difficult because MM lacks prior experience with which to judge the outside 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

Software Development Strategy

quickly than the client could in-house because training was unneeded. However, as it turns out, the transaction support needed would similarly cost precious time. How to negotiate these bidirectional time variables is beyond the scope of the model as is.
Key Motivations Frequency Asset Specificity Procedural Uncertainty Environmental Uncertainty Labor Shortage, Cost Savings Occasional Mixed: Somewhat Idiosyncratic Skills Mixed: Somewhat Well Defined Specifications 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

Software Development Strategy

slightly longer this time, with the vendor ultimately delivering a product, but the coding was below expectations and could not be used. While the temporal aspects of transactional support play a role here as well, another factor emerges. Would more sophisticated contractual specifications such as service level agreements, underperformance penalties and the like have resulted in a higher quality product? If the vendor simply lacked the talent to get the job done then the answer is that in all likelihood, probably not. This raises a second issue with my proposed framework. Whereas in theory we assume that with the right support mechanisms the product ultimately delivered by a vendor or built in-house will be of similar or equal quality, real world circumstances are sometimes different. Future modifications to our framework will need to incorporate the predicted quality of end products when linked to innate differences in skill level. However, low quality performance resulting from insufficient coordination and monitoring is a transaction cost we are already prepared to deal with. (5.3.) LCDInternational 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. (5.3.1.) Historical Events LCDI received funding from an American venture capital firm but knew the U.S. market would be too saturated to sell their products effectively. They had limited capital and determined they could cut 30-50% of their costs by moving overseas. Choosing between Bangalore and Hyderabad, India, the firm first chose Hyderabad because the technological infrastructure was better

46

Software Development Strategy

suited for their business model. However, after realizing all their potential partners were located in 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

Software Development Strategy

The company was motivated to move overseas by inexpensive labor and close access to their end market. Oddly enough, once that move was completed, this was no longer an offshoring case. Now, it is an Indian company producing domestically, which may carry implications we are unprepared to deal with, such as differences between developed and developing countries’ business environments. For the company to “offshore” internally would entail, for example, doing development in a Filipino captive center, but ultimately selling from India. Thus, the question which is relevant for our purposes is whether the firm could benefit from outsourcing domestically (within India) or offshore (from another country).
Key Motivations Frequency Asset Specificity Procedural Uncertainty Environmental Uncertainty Convenience, Cost Savings Recurrent High: Idiosyncratic Skills High: Weakly Defined Specifications 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 cuttingedge 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

Software Development Strategy

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. (5.4.1.) Historical Events As a technology firm, AG needs to be able to adapt to a rapidly changing space where new applications are released very frequently. When considering how, organizationally, to develop a new application, three options are available: build in-house, outsource entirely, and build partly in-house and outsource the rest. From a myopic cost perspective, comprehensive outsourcing is the cheapest option. But, once an application is released to market, resources need to be moved onshore so they are close to the user base and application iterations can be released quickly.

49

Software Development Strategy

Contracting offshore studios provided AG with their desired flex capacity. Because there was a lack of engineers in the U.S. with experience working on social network multimedia applications, AG looked to Arts International. AI had worked on similar projects and also offered a 3-D art specialty which AG needed and other vendors lacked. Because a self-contained team which could operate independently was essential for AG, prior experience was a must. However, because of 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 inhouse. (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 Frequency Asset Specificity Procedural Uncertainty Environmental Uncertainty Labor Shortage Recurrent High: Idiosyncratic Skills High: Weakly Defined Specifications High: Very Sensitive

50

Software Development Strategy

Here, labor cost played an insignificant role. Because AI offered a highly specialized service, they were able to charge U.S. prices despite using offshore development facilities. Instead, AG outsourced because it needed access to 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

Software Development Strategy

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. (5.5.1.) Historical Events 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

Software Development Strategy

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

Software Development Strategy

Key Motivations Frequency Asset Specificity Procedural Uncertainty Environmental Uncertainty

Labor Shortage, Cost Savings Occasional Mixed: Somewhat Idiosyncratic Skills Low: Well Defined Specifications 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

Software Development Strategy

appears supported by our alignment hypothesis. And, although the transaction is still in progress, performance thus far, as indicated by the interviewees, suggests it will ultimately be a successful first 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

Software Development Strategy

(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? Was the purchase of technology or Capital machines significant? Was the purchase of facilities, factories, Land etc. significant? Were shipping / telecommunications Shipping / Communications costs significant? Transaction Costs: Frequency (Daily or Weekly: 3; Monthly or Biannually: 2; Annually or more: 1; Not Applicable: 0) How often does the maintenance team Maintenance need to work on the technology? Re-engineering / New Releases How often are new versions released? How often would you / do you do new New Products in Same Area projects in a similar area? Transaction Costs: Asset Specificity Answer key: (3: Very Significant; 2: Somewhat Significant; 1: Insignificant; 0: Not Applicable) Did those working on the project develop specific skills which make them Specialized Skills more qualified than others for future projects on the same or similar issues? Was the software specialized and Customized customized? Was this project for part of the Core Product company’s core, or was it a side / supplemental project? Transaction Costs: Uncertainty (3: Very Significant; 2: Somewhat Significant; 1: Insignificant; 0: Not Applicable) Procedural: well-defined Were the project’s specifications wellspecifications defined at the outset? Procedural: measurability / Was progress easy to measure? verifiability Procedural: transparent / easy to see Was the work done transparently? what vendor was doing Procedural: extensive Was a lot of communication necessary to communication necessary convey project needs? Was a lot of back-and-forth coordination Procedural: coordinating with necessary, or did you simply hand it off offshore team and wait for the results to be delivered? Technological: need to build new Was this project for a new technology technologies and products your business was interested in? Was this project a way of adapting to Technological: new platforms (eg new technologies? (e.g. Facebook Facebook, cloud, etc.) application, cloud computing, Silverlight, etc.) Environmental: Legal, security, IP Was data security / privacy an issue?

(0-3): (0-3): (0-3): (0-3):

(0-3): (0-3): (0-3):

(0-3): (0-3): (0-3):

(0-3): (0-3): (0-3): (0-3): (0-3): (0-3): (0-3): (0-3):

56

Software Development Strategy Transition Costs (3: Very Significant; 2: Somewhat Significant; 1: Insignificant; 0: Not Applicable) Was it difficult to transfer the work to Moving Out the team / vendor? Was it difficult to integrate the team’s Moving In result into the company’s product line? Disequilibrium Conditions (3: Very Significant; 2: Somewhat Significant; 1: Insignificant; 0: Not Applicable) Was there a deficit of workers who had Labor Shortage the requisite knowledge to work on the project? Needed to Develop Product Was project turnaround time a Quickly significant concern? Contracting / Safeguarding (3: A lot; 2: Some; 1: Little; 0: Not Applicable) Due Diligence / Background Did you do a lot of background research Checking on the vendor? Did you spend a lot of time writing Writing Contracts contracts? Did you have somebody / people on the Monitoring: people on-site vendor’s site monitoring progress and/or managing? Did you use collaboration tools or Monitoring: tracking software tracking software to monitor the vendor’s progress? What types of communication Monitoring: informal technologies were used? (e.g. Instant communication Messaging, Skype, E-mail, etc.)

(0-3): (0-3):

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

(0-3): (0-3): (0-3): Please Also Provide Brief Explanation (0-3): Please Also Provide Brief Explanation (0-3):

57

Software Development Strategy

(8.) References Ang, Soon and Straub, Detmar. (2002). Costs, Transaction-Specific Investments and Vendor Dominance of the Marketplace: The Economics of IS Outsourcing. In: Information Systems Outsourcing: Enduring Themes, Emergent Patterns and Future Directions. 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

Software Development Strategy

Ellram, Lisa et al. (2008). Offshore Outsourcing of Professional Services: A Transaction Cost Economics Perspective. Journal of Operations Management, 26, 148-163. 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

Software Development Strategy

Lacity, Mary and Willcocks, Leslie. (1996). Interpreting Information Technology Sourcing Decisions from a Transaction Cost Perspective: Findings and Critique, Accting., Mgmt. & Info. Tech., Vol. 5, No. 3/4, pp. 203-244. Lee, Jay-Nam et al. (2002). Current and Future Directions of IS Outsourcing. In: Information Systems Outsourcing: Enduring Themes, Emergent Patterns and Future Directions. Ed: Rudy Hirschheim et al. 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 WebBased 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

Software Development Strategy

Pfannenstein, Laura and Tsai, Ray. (2004). Offshore Outsoucing: Current and Future Effects on American IT Industry. ISM-Journal. Poppo, Laura and Lacity, Mary. (2002). The Normative Value of Transaction Cost Economics: What Managers Have Learned About TCE Principles in the IT Context. In: Information Systems Outsourcing: Enduring Themes, Emergent Patterns and Future Directions. Ed: Rudy Hirschheim et al. Raisinghani, Mahesh et al. (2008). Information Technology / Systems Offshore Outsourcing: Key Risks and Success Factors. In: Outsourcing and Offshoring of Professional Services, ed. Amar Gupta. Rao, Madhu. (2004). Key Issues for Global IT Sourcing: Country and Individual Factors. Information Systems and Management Journal, Summer. Rindfleish, Aric and Jan Heide. (1997). Transaction Cost Analysis: Past, Present and Future Applications. Journal of Marketing. October, 61, pp. 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

Software Development Strategy

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

Sign up to vote on this title
UsefulNot useful

Master Your Semester with Scribd & The New York Times

Special offer for students: Only $4.99/month.

Master Your Semester with a Special Offer from Scribd & The New York Times

Cancel anytime.