-: H A NJJ Product Number wpO3-19 TA IC,1 - Released April1, 2003 B U SI NES S S cH O OL From the Department of COPRT TAEYADITRAINLBSNS > A 1.................................... 1. 1 1................... F i........ n s................................................................................................... P e r f o r m a n c e i n t h e S o f t w a re................................................................................................................................................................................1...........1............................1..........1.....................................................................1............... b y............................................................................................................................................................... Recent......................years. have...... w itnessed........................ a......... surge............................ of....... interest......................................... in the notion of capabilities as an im portant S en d il K......................................Et........................................h....i.........................................r....a.... source...............of.......com petitive...... advantage.......................... This..... recognition........................ M ICHAEL... R.................................. AND............ has, in turn, placed em phasis on the question of A SS I STAN T P R O F ESS............................................................................................................................ w here..............and..........how. these.... capabilities....................... em erge.... and............................... IN TERN A TIO N A L................................ B.........U.... how they influence firm perform ance.... The.. pres-.................................................................................................................................... ent.............paper.............. is....... an.............attem pt............ to....... address........................... this..... question......................................... Using a large sam ple of detailed project level lo...............................................................................................................................i....l.......ata.......fro m.........a....le a d in g firm...... in...................th e........glo b a l......... so ftw a re................A S...........I..........A.................................E S................ services i nd ustry, we attem pt to em pi rica I Iy I N T E R N AT I O N A L................B................................................U.... S.......................................... I........ study....................the...... im portance of............................... capabilities............................... W e........ find............................................ that two broad classes of capabilities are signifi- M....................................................................................................................................... cant..................The.......... first.... class,............................. which.... we...................label........ client-specific............................................. capabilities, is a function of repeated interactions M ICH A EL R........................... A...................................................................................................... w ith........c l....................ov e r..........i m e.......an d.......ac ro s s..........d i..........e.........................A S..........O...C....I. A T.......E.......................E... S..........O.... e......ts..........This.........................................from............repeated..... interactions........................... INTERNATIONAL....................................................................................................................................................................................................................................... persistent........................ Investm ents................................ in........ infrastructure................... and.............................................................................................................................................................................................................................. system s.........................to im prove... the.............................. firm 's.... softw are......................... develop-................................................... m ent process............................ Our. em pirical............................. results..................................... suggest................................that........... th e..............ma rg in a l......... re tu rn s.. to............................... a c q u irin g. d iffe re n t................................................................................... capabilities m ay be different and an understand-........................................................................................................................................ ing.............of.........such.... trade-offs.................................. can...... im prove........................... firm..... decisions........................................ to im prove and/or acquire such capabilities........................................................................................................................................... W e...........discuss.............. the....... key.............................contributions................................ of........ our.........................paper............................................................................................................................................................................................................................................................................................................................................................................ LEADING IN THOUGHT AND ACTION

SMJ 02-5109 A study of firm capabilities and performance in the Software Services industry1 SENDIL K ETHIRAJ University of Michigan Business School 701 Tappan Street, Room D5203 Ann Arbor, MI 48109 Ph. 734-764 1230 Email: sendil(aumich.edu PRASHANT KALE University of Michigan Business School 701 Tappan Street, Room D4209 Ann Arbor, MI 48109 Ph. 734-764 2305 Email: kalegumiced M.S. KRISHNAN University of Michigan Business School 701 Tappan Street, Room D3251 Ann Arbor, MI 48109 Ph. 734-763 6749 Email: mskrishnan@bus.umichedu AND JITENDRA V. SINGH The Wharton School of Business 3620 Locust Walk, Suite 2000 University of Pennsylvania, Philadelphia PA 19104 Ph. 215-898 6605 Email: singhj awhartonupenn.edu Revised: April 2003 1 We thank Rich Makadok, Phanish Puranam and an anonymous referee for helpful comments on an earlier version of this paper. Errors and omissions remain our responsibility. The names are listed in alphabetical order reflecting equal contribution by the authors. Research funding for this project from the Mack Center for Technological Innovation at the Wharton School and The William Davidson Institute and May and Mike Hallman Fellowship at the University of Michigan is gratefully acknowledged.

SMJ 02-5109 A study of firm capabilities and performance in the software services industry Abstract Recent years have witnessed a surge of interest in the notion of capabilities as an important source of competitive advantage. This recognition has, in turn, placed emphasis on the question of where and how these capabilities emerge and how they influence firm performance. The present paper is an attempt to address this question. Using a large sample of detailed project level data from a leading firm in the global software services industry, we attempt to empirically study the importance of capabilities. We find that two broad classes of capabilities are significant. The first class, which we label client-specific capabilities, is a function of repeated interactions with clients over time and across different projects. This learning from repeated interactions with a given client reduces project execution costs and helps improve project contribution. The second class, termed project management capabilities, are acquired through deliberate and persistent investments in infrastructure and systems to improve the firm's software development process. Our empirical results suggest that the marginal returns to acquiring different capabilities may be different and an understanding of such trade-offs can improve firm decisions to improve and/or acquire such capabilities. We discuss the key contributions of our paper and the implications for future research on capabilities. 2

1. Introduction In recent years strategy scholars have increasingly agreed that non-imitable and nonsubstitutable organizational capabilities (and resources) are a key source of inter-firm performance differences (Barney, 1991; Dosi et al., 2000; Nelson, 1991; Rumelt, 1984; Wernerfelt, 1984). This recognition has, in turn, placed emphasis on the question of where and how these capabilities emerge and how they influence firm performance. Although there are a number of theoretical arguments about the characteristics of resources or capabilities that yield competitive advantage (Barney, 1991) and what prevents their imitation (Dierickx & Cool, 1989; Peteraf, 1993), we have limited understanding of where capabilities come from or what kinds of investment in money, time, and managerial effort is required in building them. Furthermore, if the development of capabilities requires deliberate and sustained investment of financial and managerial resources, both of which have alternative uses, it becomes important to understand the costs and benefits of such investments. In other words, different capabilities may entail different financial and managerial costs and yield dissimilar performance benefits. The systematic understanding of such trade-offs promises to enrich the theory and practice of strategy. This paper makes a modest attempt to systematically address some of these questions. This paper investigates two interrelated research questions: one, where do capabilities come from, and two, how do capabilities affect firm performance? We combine in depth interview data with detailed, large sample, project-level data from one firm in the Indian software services industry over a six-year period to carefully address both questions. The rich, disaggregated project-level data about resource inputs, project characteristics, capability metrics and profitability allow us to delve deeper into the capabilities-performance link than extant research has done so. 1

Several reasons make the Indian software industry an attractive context for the study of firm capabilities. First, there is a widely shared view that much of the Indian software industry's explosive growth over the last decade is accounted for by factor cost differences between India and the developed country markets (Arora et al., 2001; Nasscom, 2001). The implication is that performance differences are driven not by firm capability differences, but by country-level comparative cost advantages. While factor cost differences definitely exist, even a cursory examination of the data suggests that firm-level explanations cannot be discounted. The Indian software services industry accounted for $6.2 billion of export revenues in 2000-01 (Nasscom, 2001). A telling statistic is that 0.8 percent (25 firms) of the firms in the industry (nearly 3000 firms) accounted for 60 percent of export revenues. Therefore, a relatively small set of firms growing at a compounded average annual rate of about 45-65 percent over the last decade accounts for much of the activity in the Indian software services industry. Our premise is that a detailed examination of the economics of one or more of these 25 firms can afford a good insight into the micro-foundations of the capabilities that underlie such sustained and robust growth in a competitive industry. Building on research on firm capabilities in general and on our detailed fieldwork and interviews with the project managers of several firms in the software services industry we argue that two sets of capabilities are important in the software services industry: client-specific capabilities and project management capabilities. Client specific capabilities are a function of repeated interaction with a given client across multiple projects over time. They largely reflect tacit knowledge of the client's business domain and operating routines acquired through repeated interaction with the client. In contrast, project management capabilities are acquired through deliberate and persistent investments in infrastructure (systems and processes) and training to 2

improve the firms' software development processes. They reflect technical capabilities in software design, development, and execution. The development of these capabilities rests not only on implicit learning by doing processes but also on deliberate, proactive investments in building them. For example, based on industry experience, some scholars have presented economic models to show that it makes economic sense for software vendors to initiate the first project with a client at low prices even if it amounts to a modest loss on the project. The first project serves as a platform for the development of client-specific and project management capabilities that help significantly reduce costs in the long-run and ultimately generate positive returns (Whang, 1995). In our empirical analyses, we estimate the marginal contribution, crosssectionally and temporally, of the two capabilities to project profitability. The study makes two principal contributions to the extant literature on capabilities. First, we argue, and empirically demonstrate, that firm capabilities are often context specific and fruitful research in this area might emanate from enjoining an in depth study of the capabilities specific to a context and careful empirical estimation of their significance and value. The distinguishing feature of our work is that we conceptualize the notion of capabilities at a more micro-level within the firm, namely the project(s) which the firm executes for its clients, develop appropriate measures for these capabilities, and examine their evolution and impact on financial performance. Second, we argue, and show, that not all capabilities provide the same marginal contribution to performance. This is significant because it suggests that if different capabilities have different costs and benefits associated with their development or acquisition, managers should pay attention to understanding these trade-offs in making investments in capability development. More broadly, our study advocates a shift in the debate from whether or not capabilities matter to "what" capabilities matter and "how". 3

The rest of the paper is organized as follows. The next section briefly outlines the research literature on capabilities and how capabilities influence performance differences. Section 3 describes the Indian software industry context in some detail and develops our hypotheses. Section 4 describes the data, the measures, and empirical estimation procedures. Finally, we present the results and discuss their implications for research on capabilities. 2. Theory 2.1. What are capabilities and why are they important? The notion of capabilities can be traced back to Penrose (1959) and Andrews (1971) among others (see also Selznick, 1957). Penrose (1959: 25) suggested that resources consist of a bundle of potential services. While these resources or factor inputs are available to all firms, the "capability" to deploy them productively is not uniformly distributed. Analogously, Andrews (1971) argued that the "distinctive competence" of an organization is more than what it can do; it is what it can do particularly well. Building upon this earlier work, recent literature on the resource-based view conceptualizes resources and capabilities along two lines. One set of authors (see e.g., Barney, 1991; Peteraf, 1993) tend to define resources rather broadly so as to "include all assets, capabilities, organizational processes, firm attributes, information, knowledge, etc" (Barney, 1991: 101). Other authors, however, have sought to clearly delineate between resources and capabilities (Amit & Schoemaker, 1993; Grant, 1991) by arguing that "resources consist...of know-how that can be traded, financial or physical assets, human capital etc... [whereas] capabilities....refer to a firm's capacity to deploy resources" (Amit & Schoemaker, 1993: 35). In this paper, we adopt the latter conceptualization of firm capabilities in developing our arguments about where they come from and how they matter. These definitional and conceptual differences notwithstanding, strategy researchers agree that both resources and capabilities are essentially assets with rent generating potential. The 4

resource-based view literature largely emphasizes two kinds of rents' they can generate. The first parallels the textbook notion of (Ricardian) rents from scarce resources. Ownership of a scarce resource (say land in Manhattan) enables the owner to enjoy superior rents relative to competitors who do not own the resource (they lease the land). The scarcity rents here are rooted in the inelastic supply curve for the resource. In addition, there is the implicit condition that, all else being equal, the cost of ownership is less than the lease cost. It means that at the time the scarce resource was acquired, its price was less than its (future) marginal product (Peteraf, 1993). A second type of rent is quasi-rents (Klein et al., 1978). Quasi-rents "are the excess of an asset's value over its salvage value or its value in its next best use" (Peteraf, 1993: 184). Quasirents are often associated with capabilities. The primary reason for this is because they are considered to be a product of specialized assets that are embedded within the context of the organization (Rumelt, 1987) such that their optimal deployment is contingent on the presence of other complementary assets (e.g., managers, culture, technology, etc.) or even learning how to deploy the bundle of assets efficiently. Additionally, there is a cost involved in transferring this asset along with the complementary assets to another firm thereby reducing its productive value (Langlois, 1992). This difference in value is the quasi-rent accruing to the owner of the asset. It may be noted that quasi-rents are distinct from scarcity (Ricardian) rents and monopoly rents; they are not a function of an inelastic supply curve (Ricardian rents) or output restriction (monopoly rents). Instead, they are a function of the uncertainty about the production function underlying the deployment of resources (Rumelt, 1984). If, however, inputs are freely available and the knowledge of exact inputs, the input proportions, and the technology underlying a firm's production function is available to all competitors then there are no quasi-rents to be exploited 1 Note that Winter (1995) refers also to Schumpeterian rents - entrepreneurial rents or rents from innovation - and monopoly rents - rents from output restriction under inelastic demand. Since neither of these rents is associated with resources or capabilities we do not discuss them here. 5

since the value of the assets in alternative uses is equal to its value in current use. In this paper, our notion of capabilities reflects assets that can generate quasi-rents. 2.2. Where do capabilities come from? Traditionally, strategy research has devoted little attention to the issue of where capabilities come from. Nelson and Winter (1982) made one of the early theoretical attempts to understand this question. They viewed the firm as bundles of path-dependent knowledge bases. Over time, firms' knowledge, accumulated through "learning by doing", is embedded in bundles of "routines" that are likened to the genetic material of the firm. Routines, a central concept in evolutionary theory, involve repetitive patterns of activity, require investment in routine-specific human and physical capital, and are easily recognized as belonging to a class (Winter, 1990). An important element of their theory is the description of the firm as a historical entity, with productive knowledge being a result of endogenous, learning by doing processes. Consequently, this perspective sees firms as entities that possess heterogeneous capabilities as a function of their routines and search processes. These capabilities are rooted in the organizational skills and routines that serve as organizational memory to repetitively execute the sequence of productive activities without trouble. At their core, these organizational skills and routines embody knowledge and competence in carrying out the productive activities that the firm is engaged in. Building on the basic idea that history matters and that capabilities are rooted in contextually embedded knowledge underlying the production function, others have emphasized the significance of absorptive capacity (Cohen & Levinthal, 1990) and asset stocks and flows (Dierickx & Cool, 1989) in driving capabilities-based competition. Some researchers have also suggested that capabilities are not merely the result of tacit accumulation of experience embedded in routines and learning by doing. They are also the result of deliberate investments in organizational structure and systems to make constant improvements 6

in those routines and practices (Zollo & Winter, 2002). Organizations strive to adapt their operating processes through proactive actions dedicated to process improvements. These may include explicit efforts to continuously learn and capture the lessons from prior experience of self or others (Collis, 1996; Zollo & Winter, 2002) and incorporate those lessons to make improvements in prevalent practices, or create organizational mechanisms to coordinate and institutionalize the improvement efforts (Kale et al., 2002). Although the notion of making deliberate investments to improve firm capabilities may be understood uniformly by most firms, there are idiosyncratic firm-level differences in the timing of this effort, the nature and amount of the investment and effort they undertake, and the internal organizational mind-set that supports this process. These differences may get reflected in significant heterogeneity across firms with respect to the capabilities that result from this effort. In sum, it appears that in operationalizing the notion of capabilities, it is important to show that: (1) capabilities involve the deployment of resources and there are strong theoretical reasons under girding how and why they generate rents; (2) capabilities tend to evolve over time to reflect the joint effects of passive learning-by-doing and deliberate firm level investments in learning and making improvements and, (3) capabilities are hard to imitate or easily acquire in factor markets, and this forms the basis for rent generation. 2.3. How do capabilities matter? The question, how do capabilities matter, is one that derives from the question posed earlier, where do capabilities come from. We argued above that capabilities reflect the evolutionary process of deliberate firm-specific investments and the largely tacit "leaming-bydoing" that firms engage in. This in turn results in heterogeneity of firms and the consequent differences in their performance. If we assume for the moment that "learning-by-doing" is 7

distributed uniformly2 among firms, then most of the ex post firm performance heterogeneity is in fact a function of the differences in the deliberate, firm-specific investments made (see Helfat, 1994 for an excellent account of how differential R&D investments by a sample of petroleum firms led to firm heterogeneity). Differences in the ex post productive value of firm-specific investments suggests that firms face significant ex ante trade-offs in their choices of firmspecific investments made to acquire certain capabilities. In the main, we expect that the tradeoffs themselves are likely to vary between firms as well as within firms over time. Each firm needs to make a set of strategic choices that fit together as a system (Porter, 1991). In making these choices, firms face significant trade-offs, and the nature of the trade-offs can vary over time as well. The trade-offs are primarily a function of the interdependencies and complementarities between the various strategic choices of the firm (Levinthal, 1997). When the choice to invest in acquiring a capability shares positive interactions with other choices within the firm, the marginal benefit of acquiring the capability is likely to be higher than in the case when the choice shares negative interactions with other choices made by the firm. Simply put, different capabilities are likely to yield different marginal benefits to the firms making the investments in such capabilities. If indeed money and managerial time and effort are scarce and firms need to allocate these scarce resources among competing initiatives to acquire relevant capabilities then it is of significant theoretical and practical importance to understand the tradeoffs they face in doing so. Theoretically speaking, the answer to this puzzle is rather obvious - managers should invest in acquiring capabilities that yield the greatest marginal returns to the investment. In practice, however, such a cost-benefit calculus is far from simple. We face formidable theoretical and empirical challenges because the interdependencies between the 2 The assumption of uniformity in learning-by-doing is unrealistic simply because it is likely to be endogenous with the choices of firm-specific investments. In effect, this assumption is plausible only if we can separate out learningby-doing from the choices about firm-specific investments. 8

various strategic choices made by a firm are often unknown and the impact on the firm of altering one choice can be unpredictable (Ethiraj & Levinthal, 2002). Moreover, as a firm attains critical levels on a given capability, its marginal returns to investing in the same capability might decline. Alternatively, the marginal returns to building other complementary capabilities might increase. In this paper, we make a modest attempt to examine the marginal returns to different capabilities, both cross-sectionally and temporally. 2.4. Empirical research on capabilities The empirical literature on capabilities is fast growing and we can partition this body of work along two broad lines. The first stream of work includes detailed historical accounts that track alternative choices made by firms and their performance outcomes. Several excellent papers in this tradition provide useful insight into the historical development and evolution of capabilities (lansiti & Khanna, 1995; Rosenbloom, 2000). Unfortunately, such methods do not permit the estimation of the significance and value of capabilities. The second stream of research that includes large-sample empirical work has attempted to do this. Even in this tradition, however, few studies have managed to adequately capture the spirit of the idea. They usually fall short either in the choice of the independent variables employed to measure capabilities or the dependent variable used to measure performance. Many studies have measured capabilities using aggregate indicators such as R&D intensity (e.g., Silverman, 1999) at the firm level. But if capabilities critically reside at the operational level within firms, aggregate firm-level measures may tend to mask much of the variance within firms. Some recent studies have identified and measured more disaggregated capabilities to address this limitation. For instance, Henderson & Cockburn (1994), using survey data attempted 9

to get at more disaggregated measures of R&D capability at the program level. They measured architectural competence (ability to integrate knowledge within the firm) and component competence (locally embedded knowledge) at the R&D program level to predict patenting productivity. Similarly, McGrath et al. (1995) measured firm competence at pursuing new initiatives and identified that deftness and comprehensiveness are important pre-cursors to competence acquisition and ultimately to the emergence of competitive advantage. These studies and others in this tradition (e.g., Schroeder et al., 2002), however, have been limited to assessing firm performance with disaggregated, non-financial measures of performance such as patenting or survey-based self-reports of performance. This is not surprising given that it is extremely difficult to relate disaggregated measures of capabilities to aggregate, financial measures of firm performance. Makadok and Walker (2000), in a notable exception, examine the financial returns to forecasting ability in the money fund industry. Along similar lines, Brush and Artz (1999) explore the trade-offs in various services offered by different firms and their impact on revenue per transaction in the veterinary medicine industry. Our study adopts an approach that is similar to this latter set of studies We construct disaggregated, context-specific capability measures that are as close to the operational level as is practically possible and we also construct disaggregated financial measures of performance at the same operational level. We also track the evolution of these capability measures over time. Most importantly, our study is distinctive from these prior studies in that we examine the choices made by a single firm over time and evaluate the performance trade-offs or the marginal returns to different capabilities that it sought to build over a six year period. The following section develops the key hypotheses advanced in this study. 10

3. Overview of the Indian Software Services Industry In this section we provide a brief overview of the Indian software services industry. We focus on the demand- and supply-side economics of the industry and attempt to draw out the nature and type of capabilities that might have the potential to generate rents. The Indian software services industry is relatively young, with many of its most mature companies incorporated in the late-70s and early 80s. The domestic market for IT services was always small and continues, even today, to account for only about 25-30 percent of the industry's sales (Nasscom, 2001). The Indian industry received a big boost in the early 1990s when the demand for IT services in the developed world outstripped the available supply of skilled labor. India, which at that time was graduating 150,000 English speaking engineers a year with only a limited demand for their services within the country, was well placed to take advantage of this opportunity. Companies in the developed world began focusing on India to leverage its low cost, English-speaking IT manpower. The low levels of initial investment required to enter the software services business and the minimal regulatory intervention from the Indian Government, created few, if any, entry barriers or constraints in these early years. Several hundred Indian firms were founded to exploit this opportunity and the industry witnessed very rapid growth. Overall, there was a general consensus that macro factors such as the access to large, low-cost, English-speaking technical manpower in India and improvements in IT-related infrastructure (e.g., high bandwidth communication lines) set up by private and state-owned companies positively influenced the competitive advantage and growth of Indian companies (Arora et al., 2001; Nasscom, 2001). 3.1. Demand for Indian software services Faced with a small and undeveloped domestic software services market, Indian software firms focused primarily on the export market. Their early work, however, was neither 11

technologically very sophisticated nor critical to clients' businesses. Clients usually did the highend work such as requirement analysis and top-level design either in-house or through US based consultants. They outsourced the low-end, labor-intensive work such as low-level design, coding, testing, support and maintenance to Indian companies to leverage their low-cost activity base. Clients retained the high-end work in the early years either because their Indian vendors did not possess the requisite skills to undertake these activities or, even if they did, clients did not have sufficient confidence to entrust such activities to them. Thus, the origin of the Indian software industry was firmly rooted in performing low-end, technically less demanding and labor intensive work for the global IT industry and exploiting labor cost arbitrage opportunities between India and developed country markets (Nasscom, 2001). Over time, however, there was a change in this trend. The low entry barriers in the Indian software services industry triggered abnormally high levels of entry by new firms. Between 1989 and 1998, over 3000 software services firms were founded that aspired to serve export markets. Consequently, domestic competition in the labor market (i.e. for trained engineers) shot up. It was not enough anymore to just possess low-cost labor resources and exploit arbitrage opportunities. Firms also needed to improve the productivity of labor to compete effectively in the market. Thus, some companies began a systematic push to build high end software capabilities, move up the value chain, and improve per employee revenue figures. Consequently, the leading Indian software firms today are also the leading firms in the global market (MarketGuide, 2002). Since the mid-nineties there has been a distinct shift in the nature of software projects undertaken by some of the leading Indian software firms. They gradually shifted their role from that of merely implementing a design provided by their overseas clients to becoming active 12

participants in the design of the complete application product. As a consequence, they now undertake a range of jobs from highly labor intensive code migration work such as the integration of old mainframe-based systems into new e-commerce platforms, or developing new code for pre-designed applications and software tools, to projects that involve both conceptual design and implementation of customer relationship applications and supply-chain management systems. The capacity to execute such a range of jobs enabled these firms to deliver end-to-end solutions and, thereby, lay claim to a larger share of the client's IT budget and compete for it with leading firms in the US such as IBM and Accenture. Overall, while comparative cost advantages do exist for Indian software firms, they are by no means a source of sustainable advantage. First, the nature of services provided by these firms involves specialized work (e.g., designing supply chain management systems or setting up trading exchanges) that requires not only technical knowledge of software design but also an in depth understanding of the client's industry and business process. Second, even firms such as IBM, Sapient, and Accenture have set up subsidiaries in India exploiting the same cost advantages. These subsidiaries undertake software projects involving both design and development on latest technology platforms and business applications. This development not only supports the argument that Indian software teams are capable of executing these high value projects but also erodes much of the Indian firms' traditional cost advantages. 3.2. Supply of Indian software services3 Two aspects of the Indian software services industry are critical to understanding its supply-side economics: (a) where and how the software development process is managed and organized and (b) what type of contracts are used to provide the services. We elaborate on each of them below. 3 Sections 3.2. and 3.3. draw heavily from an excellent article on the Indian software industry by Arora et al. (2001). 13

Indian software firms have traditionally executed two types of projects: onsite and offshore. In onsite projects the Indian firm supplies its overseas clients with software professionals with particular technical skills required by the client and the entire project is developed and executed at the clients' site. In offshore projects, on the other hand, the Indian firm may send a few software professionals to the client site to understand its requirements and specifications, but thereafter the entire software is developed in India. The post development support and maintenance of the software is also carried out largely from India. In some cases, a hybrid of the two types is also observed. Obviously, the offshore development model is more cost effective due to labor market arbitrage. From a cost standpoint, the greater the proportion of work completed offshore, the lower the cost of project execution. This is primarily because in onsite projects employees need to be paid in accordance with host country norms4, which erodes a significant proportion of the cost-based advantages that Indian firms enjoy. In the early days of the Indian software industry, Indian companies executed a majority of the projects onsite. This happened because, first, the overseas clients did not have full confidence in the Indian firms' ability to execute projects in conformance to their needs. Secondly, the Indian firms also did not have sufficient understanding of clients' needs and often required close and regular interaction with the client. But, over time, as overseas clients developed confidence in the software capabilities of their Indian vendors and the vendors, in turn, developed a better understanding of clients' needs, it made economic sense to relocate the bulk of the project development activities to India to take full advantage of its low cost 4 In the United States, issue of HIB visas to overseas software professionals requires the sponsoring firm to certify that the professionals are being paid wages commensurate with what a US-based employee with similar qualifications would obtain. This provision was introduced to discourage firms from substituting domestic labor with low cost foreign labor, while allowing them to access overseas specialized labor not easily available domestically. 14

development base. The improvements in the infrastructure for long-distance communication and data-transfer facilitated this process further. The second significant feature of software services, both in India as well as worldwide, involves the type of contract adopted in software outsourcing arrangements with software firms. Contracts can be broadly classified into two categories: Fixed-Price and Time & Material (Banerjee & Duflo, 2000). In fixed price contracts the vendor charges a fixed fee for its software development services which is usually negotiated before the start of the project. Although the vendor bears most of the risk in this case, tight and efficient project management can yield potentially higher margins. In a Time & Materials (T&M) contract, the vendor provides services at a pre-negotiated rate for every person-hour of effort expended on the project and receives payment either at the end of the project or at periodic intervals when project milestones are reached. Here, although a vendor is usually protected against any cost and schedule over-runs that may arise due to changes in client specifications, there may be also reduced incentives for the vendor to execute more efficiently. In the early years, most Indian software firms usually preferred undertaking T&M contracts with their clients. Since these contracts are behavioral, the client needs a safeguard that the Indian firm is not billing them more person-hours than is necessary to execute the project. So clients typically reduce their risk by negotiating hard on the price per person-hour. Hence, from the Indian vendor firm's point of view, their reduced risk came at the cost of reduced margins. Therefore, for firms that had the capability to manage their projects efficiently and assume the risks, it made economic sense to move to a Fixed Price contract that potentially provided higher margins. In Fixed Price contracts, clients were willing to concede higher prices because such contracts reduced their need for behavioral monitoring and had strong penalties associated with 15

delays or defects in project completion. So a combination of improved project execution and management capabilities and the Indian firms' impetus to improve profit margins led to an increasing thrust toward taking on more Fixed Price contracts. Overall, on the supply-side the steady transition from onsite to offshore projects and from T&M to Fixed Price contracts meant that an increasing share of project management risk had to be borne by the Indian firms. This meant that the firms had to acquire the requisite capabilities to compete effectively. The following section elaborates what these capabilities were and how they played a critical role in Indian firms' successful evolution. 3.3. Capabilities of Indian software services firms Against the backdrop of the demand- and supply-side economics of the Indian software services industry, two broad sets of capabilities are critical. The first are what we term clientspecific capabilities. As software firms work with their clients over time they develop several client-specific patterns of interaction that become cost effective over repeated interactions. For instance, one of the firms we interviewed mentioned that clients tend to have fairly idiosyncratic ways of doing things and it takes some time to understand and appreciate this. One of this firm's clients wanted a team of its employees to be stationed at the client site for three months after completion of the project. Initially the Indian firm resisted such a demand since it led to increased costs. However, over a period of time, the firm was able to convince the client that it could provide the same quality of after-sales service with the support team based in India. This was possible because with repeated interaction with the same client over time, software vendors not only develop a better understanding of the information infrastructure at the client site but also have better clarity of requirements from these software projects in the context of the client's business environment. This knowledge is acquired through several interactions with the client 16

over various stages of the development cycle such as requirements specification, business process design, data preparation, software installation, debugging and testing, etc. Hence longterm relationships and repeated interactions with clients resulted in client-specific learning that had a positive effect on both revenues and costs. On the revenue side, clients were more willing to agree to higher prices on repeat projects as they developed confidence in the capability of the Indian firm to execute projects per their specifications. We reckon that Indian firms were able to capture at least some of the switching costs faced by the client in finding a new vendor and building a new working relationship. On the cost-side, there was tangible cost reductions associated with learning the client's requirements over time. For instance, one of our interviewees pointed to a client who never specified requirements very clearly at the outset and tended to repeatedly come back and ask for new features after the project was delivered. While this tended initially to be disruptive and create problems for the Indian firm, over time it learned to work around this. Rather than deliver very finished projects, the vendor firm began to involve the client firm at the prototype stage itself and then started building in the client firm's needs as the project went along. In this manner, they were able to avoid the post-delivery negotiations and completion delays and the associated costs. Such client-specific tailoring of projects also enhances the software firm's understanding of the client's business domain. Thus, repeat projects for clients helped develop important client-specific capabilities that contribute to higher profits by reducing costs. Therefore, we hypothesize that, HI: Development of client-specific capabilities based on repeated interaction with clients is positively related to project performance. 17

A second capability that is more fungible across clients and industry domains is the software development and project management capability (Humphrey, 1989; Jalote, 1997). The following three capabilities are particularly important: (i) Software design and building capabilities: Software companies must have the capability to first properly understand the requirements of the clients and design an appropriate system or architecture to address them. Secondly, they must possess the capability to efficiently and effectively build the code based on the product design as well as coordinate the entire code development process that is usually distributed across many teams and/or sites. These capabilities are usually reflected in the defects identified in the product/software during the design and development process. (ii) Effort estimation and management capabilities: Companies have to be skilled in not only accurately assessing the requirements of the client but also in assessing the resource inputs or effort required to build and execute the project. They need to be able to identify appropriate resources (for instance people with the necessary skill, experience, availability, etc.) and create and use prior experience/data to arrive at accurate estimates of the resource/effort requirements. Further, they also require skills to ensure the effective management and deployment of the required resources. Poor capabilities in effort estimation and management are usually reflected in increased manpower cost and/or effort overrun. (iii) Schedule estimation and management capabilities: Once companies have a tentative idea of the resource inputs necessary to build and implement the project, they must be able correctly to assess the duration and schedule required for completing the project for a given level and quality of resources. They also need to possess the management skills to ensure that the project resources are garnered, deployed and managed to complete the project within the planned schedule. Again, poor capabilities on this dimension are reflected in project completion delays and schedule slippages. 18

Given the importance of the above capabilities, in recent years, firms have placed a great deal of emphasis on software engineering and project management and have been making investments in improving their processes and capabilities. The Capability Maturity Model (CMM) developed by the Software Engineering Institute (SEI) at Carnegie Mellon University is a widely adopted framework to improve software capabilities. Built on theories of quality and continuous process improvement, the CMM~ was first initiated to provide the Department of Defense a standard means for measuring contractor capability via its definition of process maturity (Humphrey, 1989). As the CMM became widely adopted as a standard quality process model in the defense sector, commercial organizations began to investigate whether they, too, could benefit from the approach to software process improvement expressed in the CMM. In the last few years software process improvement based on the CMM has emerged as an integrated solution to the software problems in various corporations and empirical evidence in support of the same has been reported (Herbsleb et al., 1997; Krishnan, 1996). Recognizing the importance of project management capabilities, several Indian firms have been the leaders in adopting CMM guidelines to improve their software development processes. According to SEI, in 2001, of the 42 companies worldwide certified as having attained a level-5 capability, 25 are based out of India. Meeting these guidelines is not a trivial task. Firms need to make substantial investments in firm infrastructure, systems and human capital. The CMM specifies five maturity levels, each consisting of several Key Process Areas (KPAs), to assess an organization's process capability by measuring the degree to which processes are defined and managed (see Paulk et al., 1993: Figure 1). Firms first need to do a detailed comparison of their development and project management processes with the CMM process quality framework and identify specific aspects that need to be improved. After making 19

these organizational and process changes, software firms need to set up a rigorous metrics program to collect data to assess various aspects of their development process and institute audit systems to track non-conformance of best practices, process deviations, and exceptions. Measurement based feedback to improve the process capability is achieved through monitoring and review forums to track improvements and make required changes on a regular basis. In addition, software firms need to invest in training programs to improve their process maturity under the CMM framework. The training activities mandated by CMM include ongoing training in both new technology and software process and project management skills for software developers and managers. To achieve higher levels of process maturity, firms need to organize rigorous training of all their employees not only with a view to improve their development/project management practices but also to institutionalize the entire capability improvement initiative (Paulk et al., 1993). The CMM framework offers generic guidelines for institutionalizing disciplined practices across various activities in software development. Since the nature of software development is such that software teams can quickly turn to ad hoc practices, institutionalization of disciplined practices and continuous feedback based improvements can evolve as a core project management capability of the firm. Overall, firms can eventually develop their software development and project management capabilities as a result of cumulative and integrated effort across the many process areas of CMM as described above. Eventually the possession of these capabilities should lead to better project level performance for the firm. Past studies have already recorded how strong software and project management capabilities and processes are linked to substantial improvements in the quality of the products/services provided as well as the efficiency of providing them (Harter et al., 2000; Herbsleb et al., 1997; Krishnan, 1996). Eventually, we 20

believe that these benefits should result in improved performance at the project level in terms of profitability and contributions. Therefore, we hypothesize that, H2: Higher levels of project management capabilities will lead to higher levels of project performance. While client-specific capabilities and project management capabilities are both positively related to project performance they might differ in terms of the marginal returns they provide. Even within the set of project management capabilities, one may expect to see some differences in their marginal returns. As argued earlier, differences in marginal returns may arise due to differences in the costs associated with developing these respective capabilities. Our empirical analysis can help shed light on whether that is indeed the case in our setting. To summarize the paper so far: We have sought to understand the origin, significance, and value of firm capabilities. We first argued that capabilities reflect the distinctive deployment of resources and also that they are contextually grounded. We then elaborated the specific capabilities that are important in the software services industry, namely, client-specific capabilities that arise in the context of repeated interactions with clients over time and project management capabilities that develop through deliberate and persistent investments in the effort and infrastructure to create them. While client-specific capabilities help reduce project execution costs, project management capabilities help maintain low-cost and high-quality all along the software development and management value chain. These capabilities, in turn, provide opportunities for rent generation for firms. We next turn our attention to the significance and value of these capabilities as a matter for empirical investigation. 21

4. Methods 4.1. Data We obtained detailed quantitative data at the project level from a leading, world-class software services firm headquartered in India5. Over 90 percent of its revenues are export-based of which more than 60 percent comes from North American clients. The dataset includes information on revenues, cost, factor inputs, capability measures, various project characteristics such as size, client industry, development platform, etc., measured at the project level. We have data on 223 projects executed by the firm over a six-year period from 1996 -2001. However, after dropping projects with missing data, our sample was reduced to 138 projects6. The firm has executed these 138 projects for 57 different clients over the study period. For some clients, it executed just one project whereas for others it executed multiple or repeat projects. We label the former set of clients as "new clients" and the latter as "repeat clients". Our dataset has 22 new clients for whom the firm just executed its first and only project during the study period and 35 repeat clients for whom it executed more than one project. The average number of projects executed per client is 2.4; the range is from a minimum of 1 to a maximum of 30 projects. Thus, our dataset comprises a panel of 57 clients for whom the firm has executed one or more projects during the study period. Our panels, however, are unbalanced since the number of projects executed varies across the set of clients. 4.2. Model specification and estimation We assume that the firm produces a single output, software services, using skilled labor. Since the software services business is highly labor intensive, the scale of the firm's operations 5 Since the dataset reveals the economics of the firm and has competitive implications, we are unable to reveal the identity of the firm. 6 We found no statistically significant differences between projects with complete data and those with missing data for those variables for which we had complete information. This increased our confidence that the analyzed data were not systematically different from the data on all the projects. The results reported in the paper are estimated using the sample of 138 projects. 22

and its costs depend almost exclusively on manpower. The firm's profit function from each project is given by, nijt = F(P, C(, K )) where, ijt are the profits from project 'i' for client 'j' in year 't'. This recognizes that profitability can vary as a function of time, client characteristics, and project characteristics. P are the prices and C are the costs respectively of project 'i' for client 'j' in year 't'. Both prices and costs depend on project specific characteristics, 6, such as size, complexity, duration, type of contract and so on. The last term in the equation, K, captures the capabilities measures, which vary with client and time and also depend on project specific characteristics 6. This reflects our hypotheses that capabilities tend to influence both the prices and costs of software services. As argued in the previous section, capabilities allow the firm to command a price premium (shift the demand curve), and also reduce costs (shift the supply curve). We estimated the following equation using project level data, log( r ijt ) = P log( wt ) + XZijt + yK1it + 6 where the dependent variable, Wijt, is project-level contribution (revenue minus cost), wjt is the vector of input characteristics that determine costs, zijt is a vector of project specific controls, and Kjt reflect the capability measures. The coefficients on the logged variables are directly interpreted as elasticities, while the coefficients on variables measured in levels vary with the magnitude of the variables7. We only logged independent variables that did not have zero values and retained variables with zero values as levels to avoid estimation difficulties. We employed a fixed effects panel data estimator to estimate the above equation. We used this methodology since our sample comprises of data on 57 different clients from whom the 7 We explain our rationale for logging the dependent variable in the section describing the measures. Note that entering the variables in levels does not change the results. We report the results on the logged variables for obvious ease of interpretation. 23

firm executed one or more projects during 1996-2001. Each panel comprises all the projects executed for a given client during this period. The coefficient estimates are interpreted as the amount of within-panel variation in the dependent variable (project performance) that is explained by the within-panel variation in the independent variables. Thus, the regression analysis relates changes in project contribution across different projects for a given client to changes in the independent variables after controlling for unobserved time-invariant effects, and the included control variables. 4.3. Measures Dependent variable Project Contribution: The dependent variable is project contribution (revenues minus costs) measured in Indian Rupees (INR) recognized on the date of completion of the project. We chose to focus on the project level because the firm capabilities that we study primarily exist and evolve at the activity or project level within firms. Firm performance and profitability is essentially an aggregate of project level contribution so we expect the correspondence between project and firm performance to be quite high. Project performance is an imperfect indicator of firm performance only to the extent that it does not account for firm-level cost overheads. To be able to use this variable meaningfully we need to adjust the INR values both for inflation and INR-USD (US dollar) exchange rate depreciation over time8. As we discovered, this is a far from a simple problem, since identifying an appropriate price index specific to an export-based software services firm is quite difficult. Fortunately, we found that a simple solution is to take 8 The exchange rate depreciation over time is important since the firm incurs most of its costs (e.g., wages) in Indian Rupees whereas its revenues are in US dollars. Therefore a change in the Rupee-Dollar exchange rates will also change the coefficient estimates of the firm profit function. 24

logs of the dependent variable and include year dummies in the regression estimation. This helps remove the effect of the adjustment factor from the parameters being estimated9. Independent variables Client-specific Capabilities. As outlined in section 3.3., client-specific capabilities are a function of repeated interactions with a given client. These repeated interactions may be a function of time (on a long project) or spread over several projects. We measured it in two ways. For each project in our dataset, we have information on whether the client is new (i.e., the first has executed the first project for that client) or a repeat client (i.e., the firm has executed projects for that client in the past). We created a dummy variable, called customer type, which is coded 0 if it is a repeat client and coded 1 if it is new. Repeat clients are a proxy for client-specific capabilities developed by the firm. We expect the sign on this coefficient will be negative. Since we also have panel data on each client in our sample (i.e. data on multiple projects done for each client), we used it to estimate a client fixed effect by including a dummy variablefor each client. Though both measures are largely substitutes, the first measure captures some information about past projects not included in our dataset, and the second produces a within-sample estimate of the client-specific effect. Since we cannot estimate a single parameter for the client fixed effects, we only examine whether they are jointly significant after controlling for input and project characteristics and time. Project Management Capabilities. Project capabilities are not client-specific (or domain/platform specific). They are capabilities that can, by definition, be leveraged across 9 For example, C2000 (contribution in year 2000) needs to be adjusted to the same units as C1996 (contribution in 1996). Usually, C2000 is adjusted as C2000/P1996 where the denominator (PI996) is the appropriate index for adjustment. Taking logs we obtain, log(C2000)-log(P1996). This means that if we take logs on the dependent variable and include year dummies, the parameters are free of the adjustment factor. The year dummies absorb the adjustment factor and since the year dummies are only controls, the main results and our interpretation remain unaffected. 25

clients, industry domains, and development platforms. We used three metric variables to measure these internal project management capabilities. The first variable measures the number of inprocess defects identified during the project execution phase. Since in-process defects can vary by size of the project, we normalized it by a project size measure (FP) described below10. Inprocess defects, which measure the defects detected in the product, reflect a firm's software development and management capabilities. Further, it has also been reported that the cost of fixing a defect detected in the early phases of software development can be substantially lower than the cost of fixing a customer reported defect or defects detected at the final stages of software development before releasing the product to customers (Jones, 1997). Hence we expect that lower in-process defects will lead to higher project contribution. A second variable measures effort overrun, i.e., difference between actual person-months required to complete the project and person-months that were initially estimated. Effort overrun can directly affect project profitability since project costs go up as effort increases. This measure reflects the effort estimation and management capability. Effective project management involves minimizing such overruns. Since effort overrun is likely to vary directly with budgeted personmonths, we normalized effort overrun by the budgeted person-months to estimate its main effect. The expected sign on this coefficient is negative, i.e. higher effort overrun will lead to lower project contribution. The capability measures were entered as levels (rather than logs) since zero or negative values are possible. A third variable measures the extent of schedule slippage, i.e., by how much the project completion date was delayed. It reflects the schedule estimation and management capability in projects. Delays in project completion can adversely affect profitability since the firm can incur 10 The measure of project size, called Function Points (FP) is a composite measure of project size and complexity and described in greater detail in the sub-section below on the control variables included in the estimation. 26

contractual penalties for delays and also bear increased labor costs. We expect the magnitude of schedule slippage to vary directly with expected project duration. To control for this, we normalized schedule slippage measured in days by project duration also measured in days. The expected sign on this coefficient is negative, i.e. higher schedule slippage will lead to lower project contribution. In summary, the capabilities measures employed here reflect our view that capabilities are distinct from either inputs or resources. While inputs or resources such as capital or software manpower are accessible by all firms at prevailing factor prices, capabilities reflect the deployment of resources. Therefore, capability differences between firms are reflected in productivity differences between them, and within firms in productivity improvement over time. Thus, in the research design employed here, changes in the capability measures reflect changes in the productivity of resources over time. Control Variables We controlled for a variety of other variables that might impact project profitability. We briefly describe these variables below. Contract type. There are two types of contracts commonly used in the Indian software services industry: Time & Material (T&M) and Fixed Price. As explained earlier the role of project management capabilities may differ in the two types of contracts. Also, these contracts may vary in terms of their influence on project profitability. To control for the obvious effect of contract type on profitability we included a dummy variable, where a T&M contract was coded as 0 and Fixed Price was coded 1. In terms of the risk-return trade-off Fixed Price projects are expected to yield superior project profitability suggesting an expectation of a positive sign on the coefficient. 27

Project size and complexity. We expect project size to affect profitability. Though we have no priors on this, we might reasonably expect that the size-profitability relationship might be increasing below the minimum efficient scale and decreasing above the maximum efficient scale. We used a measure of project size, called Function Points (FP), to capture a composite measure of project size and complexity"l. We logged the FP measure in our estimation and, as a result, the coefficient can be interpreted as elasticity with respect to project profitability. Team size. We also expect team size to have an effect on project profitability. As above, we expect project profitability will increase with team size when the team is too small and overworked and decrease when the team size is large enough to create coordination problems. Team size is logged in our model and can be interpreted as elasticity with respect to profitability. Person-months. The team size measure is imperfect since there may be attrition'2 during the project or some members may work only part-time. This will cause the team size measure to be overstated. A more precise measure of project size is person-months of labor. This accounts for both team member attrition and part-time manpower usage. Person-months are entered as logs and can be interpreted as elasticity with respect to profitability. Project Duration. Duration is an important control variable since longer projects are more prone to cost overruns, either due to forecasting difficulties or employee attrition. We measure project duration as the actual months taken for project completion. This measure is entered in logs and can also be interpreted as elasticity with respect to project profitability. 11 Earlier measures of size and complexity tended to just count the number of lines of code in software and use it as a proxy. The problem with this measure is that the number of lines of code for a given application varies directly by software platform. For example, for a given application, the number of lines of code in Cobol is several times greater than the number of lines of code in Java. The FP measure is designed to be independent of programming language (see Albrecht & Gaffney, 1983). 12 Employee attrition is historically very high in this industry ranging from 10-30 percent per year. 28

Industry domains. The software firm we studied executed projects for clients in multiple industries. Since competition and appropriability conditions can vary by industry and the firm's capabilities may not be entirely fungible across industry domains, we include industry domain dummies to control for industry specific differences. We included three dummy variables for financial services, manufacturing, and marketing industries. The omitted category was "other." Development platforms. Profitability can also depend on the software platform on which the project is executed. The firm is likely to have better experience with platforms on which it has executed a number of prior projects and is likely to incur substantial learning and start-up costs on newer platforms. To account for this, we included four dummy variables to distinguish between Windows NT, Mainframe, Unix, and Web-based platforms. The omitted category was "other." Time. We control for time in all our models using year dummies. The year dummies reflect the particular year in which each project was started. (We also tested the models using year dummies based on the completion year of each project and found that the results did not change substantively). This control is necessary to capture the variance in the dependent variable due to exchange rate fluctuations and inflation. The time dummies are also important to account for any variation in the proportion of onsite and offshore projects that the firm has done over time. We found that no projects in our dataset were exclusively onsite or offshore. All projects had a component of both. Unfortunately, the firm did not have data at the project level on the proportion of work done onsite and offshore. According to the firm there were no dramatic changes from one project to another on mix of onsite and offshore work. However, there has 29

been some change in this mix over the years. Thus including the year dummies also helps control for the change in the proportion of onsite and offshore work over time. 5. Results Table 1 presents the descriptive statistics and correlation matrix of the variables employed in the estimation. From the correlation matrix it is clear that all the control variables (i.e., project/team size, and project duration) are significantly positively related to project contribution. We also note that the relationship between the capability measures and project contribution is negative as expected, though only the process defects variable is statistically significant. Table 2 presents the coefficient estimates from the fixed-effects panel regression analysis. The second column lists the predicted sign on the key independent variables in the model. The next column labeled Model 1 presents results with just the control variables in the model. The Rsquared for this model is highly significant and the control variables account for about 66 percent of the variance in the data13. The model also includes client fixed effects, wherein we included a dummy variable for each client within the dataset. As expected the client fixed effect is strongly significant, providing some prima facie evidence for client-specific learning and/or switching cost associated with repeat projects for a given clientl4. 13 We examined the possibility of decreasing returns to project and team size by introducing quadratic powers of the variables. The coefficients were non-significant suggesting that the constant returns to scale assumption might be reasonable for this dataset. 14 To check for multi-collinearity, we computed the variance inflation factor (VIF) indices and found that the person-months variable had a VIF of 4.42, followed by team size (2.97), Size FP (2.46), and duration (2.36). The mean VIF for all independent variables was 2.51, alleviating multi-collinearity concerns (Chatterjee et al., 2000). 30

In model 2A we added the customer type variable to the analysis. The model is again highly significant and its adjusted R-square15 increases to about 0.67. The customer type measure reflects whether the project in the dataset involved a new client or repeat client. We sought to capture aspects of client specific capabilities, such as specialized investments and learning from repeated interactions with the client16. Though the sign on the coefficient was in the expected direction, it was not statistically significant. Note, however, that the client fixed effect continues to be highly significant even in model 2A. To investigate the possibility that the client fixed effect might be capturing the variance in the customer type variable, we re-estimated the model by dropping the client fixed effect. Since dropping the fixed effect can bias the estimates, we employed a generalized least squares (GLS) model that allowed us to correct for heteroskedasticity within projects executed for a given client. These results are presented in Model 2B. As seen from the results our conjecture was confirmed. The coefficient on the customer type variable turns out negative and statistically significant suggesting that project contribution, on average, is lower for new clients than for repeat clients. This provides some confidence that client specific capabilities are related to project contribution. In Model 3A we added variables for the three project management capabilities to the regression. The overall model continues to be significant and accounts for about 70 percent of variance in the data. We find that schedule slippage and effort overrun respectively are 15 The table reports adjusted R-squares for all the models. In displaying nested regression models, reporting Rsquares tells us little about whether the added variable contributes significantly to model fit, since R-squares always increase when an independent variable is added. The adjustment of R-square to reflect the residual degrees of freedom solves this problem. Thus, an increase in adjusted R-square between successive nested models in table 2 signifies improvement in model fit 16 In the dataset used for empirical estimation there is no evidence that revenues from repeat clients were systematically higher than that of first-time projects after controlling for project characteristics. Revenues tended to remain constant after adjusting for inflation and exchange rate changes. 31

significantly negatively related to project contribution, suggesting that improvement in project management capabilities are rent generating at the project level. The coefficient for in-process defects is not statistically significant though its sign is in the expected direction. We reckon that this result is largely due to the lack of significant variance on this measure (Mean = 0.605; S.D. = 1.781). We also explored this result in discussions with project managers. They reasoned that the identification of defects during project execution is indeed a capability since defects can be fixed at lower cost during execution than if they were to be fixed after the project was completed. In other words, higher values on the in-process defects measure might indicate better project management skills. However, they also pointed out that an increase in the number of in-process defects tends to disrupt delivery schedules and negatively impact project profitability. In sum, it seems that while in-process defects capture some detection capability, it also exposes some weakness in software design and execution capabilities; namely why did these defects arise in the first place. In the long-run, we expect that this defect detection capability might be positively related to project contribution, especially with repeat projects. However, the imperative to fix defects during project execution can disrupt project schedules as well as increase project costs leading to the observed result. In Model 3A, we also find that the customer type variable remains non-significant when the project management capabilities measures are included along with the client fixed effects. Therefore, we once again re-estimated the model by dropping the client fixed effects. Model 3B reports the results of the GLS estimation with the correction for panel heteroskedasticity. Not surprisingly, customer type remains significant, though only marginally (p<=0.09). The project management capabilities variables, however, continue to be robustly significant in the predicted direction. This result seems to suggest that the project management capabilities variables share 32

some common variance with the client-specific capabilities measure. This runs counter to our hypothesis that they are each distinct sets of capabilities. We discussed this result with industry experts who suggested that by working with a given client over time (i.e., repeat projects) the software firm gains a better understanding of the client's needs and expectations. This, in turn, can help reduce effort overrun and schedule slippage accounting for the observed result. The managers in the software firm we studied tended to agree with this possible interpretation. Finally, we also performed a joint significance test of the project management capabilities. We found that the three variables were jointly significant (F=3.23; P<=0.01) reconfirming the independent, additional significance of these variables in influencing project contribution. The results in models 3A and 3B suggest that decreases in schedule slippage and effort overrun respectively contribute to increases in project contribution after controlling for time and other input/project characteristics. But we can conduct further analysis to examine whether and how project management capabilities have evolved over time and how that affects contribution7. In order to examine the evolution of project management capabilities over time, we included an interaction term of schedule slippage with 1996 (the first year of data) and effort overrun with 2001 (the last year of data)18. These results are reported in Model 4. The overall model continues to be highly significant accounting for about 72 percent of the variance in the data. As expected, we find that the extent of effort overrun on projects has been declining during the period 1996 -17 Ideally we would have liked to examine the evolution over time of client-specific capability also. We were unable to do this since client-specific capability is measured as a dummy variable thus precluding the inclusion of an interaction term with time. 18 We did not include an interaction term with capabilities and time as a continuous measure since this implies the assumption that capabilities change linearly over time. We found no theoretical or empirical basis for such an assumption. Note that our results are robust to including year as a continuous variable. However, we were unable to include both interactions in the same model. The high correlations between the two interaction terms created estimation difficulties. Similarly, interacting both capability measures with the same year (i.e., 1996 or 2001) created estimation problems since they were highly correlated. We switched the years to avoid this problem. Just in the interest of reporting all results, an interaction of schedule slippage with 2001 is negative and significant which is consistent with our interpretation. 33

2001 and this decline is positively related to project performance. Contrary to expectation, we find that schedule slippage has marginally increased during the period 1996-2001 and as a result adversely affected project contribution in more recent years. To understand this result, we examined the data more closely and found three possible reasons that might explain it. First, the firm has steadily increased the number of fixed price projects over the years and has not managed this transition well. As observed in our data, Fixed Price projects tend to suffer from a greater schedule slippage than T&M projects. This result is also corroborated in the regression results where we find that T&M projects, contrary to expectations, tend to be more profitable than fixed price projects. Second, for the fixed price projects we find a greater difference between the team size and person-months measures. While team size reflects the maximum number of persons who worked on a given project, the personmonths measure more accurately captures the labor input in the project. At one extreme, if all members of the team worked full time on a given project we will find that team size and person months are perfectly correlated. The difference in the two measures appears when there is high turnover in the project teams. We find that the difference between the two measures has increased over the years suggesting that an increase in project team turnover might account for the increase in schedule slippage. During the period 1996-2001, the attrition due to employee resignation fluctuated between 9-16 percent. Increase in turnover directly contributes to schedule slippages since there is a setup cost when new employees enter a project mid-way. Some time may be lost in getting the newer employees on board the project that may lead to greater schedule slippage. Our discussion with the company executives revealed that a third possible reason for increase in schedule slippage is due to an increase in e-commerce related projects in the post-1996 period. The e-commerce clients, in their effort to speedily set up their web 34

infrastructure, set up aggressive project completion schedules that realistically were quite difficult for the company to complete within the stipulated time. One or more of these three explanations account for the observed increase in schedule slippage that in turn contributed to reduced project profitability. 6. Discussion We sought to examine two interrelated research questions in this paper: where do capabilities come from and how do they affect firm performance? We made three main arguments in addressing these questions. First, we suggested that capabilities involve the deployment of resources and they evolve over time through the joint effects of deliberate, persistent firm-specific investments and learning-by-doing. Second, we proposed that capabilities are context specific and therefore we need to conceptualize and study them accordingly. In this paper we looked at the software services industry and identified two important capabilities at the project level: client-specific capabilities and project management capabilities at the project level. Third, we argued that improvement in capabilities will result in improved project profitability and that different capabilities yield different marginal benefits. Our results are broadly supportive of our hypotheses. In the context of the software services business we find that capabilities contribute positively to project level performance. We, however, found limited evidence that client-specific capabilities were positively related to project performance. In models that included client fixed effects we did not find any support for the effect of client-specific capabilities on contribution. However, in models that did not include the client fixed effect, we found that new clients/projects, on average, yield approximately 2 percent lower contribution than repeat clients/projects after controlling for input and project characteristics. In the models including the client fixed effect, it appears that the dummy variable 35

capturing repeat or new clients is too coarse a measure to adequately reflect client-specific capabilities. Ideally, we would have liked to measure client-specific capabilities by using a count of all the projects undertaken for a client during the firm's entire course of interaction with that client (and not just a count of projects within the sample period). Unfortunately, the firm was unable to provide this data. Nevertheless, the significance of the client-specific capabilities measure in the GLS model is indicative and might be useful to examine carefully in future research. In addition, we have reason to believe that the client fixed effect might also be picking up some variance in the learning associated with repeated interaction with clients. This interpretation is consistent with past studies that attributed fixed effects to persistent capability differences (Henderson & Cockburn, 1994). Project management capabilities were generally predictive of higher project contribution. Two of the three dimensions of project management capabilities were statistically significant. A one percent increase in schedule slippage resulted in a 0.06 percent drop in project contribution'9. A one percent increase in effort overrun causes a 0.01 percent decline in project contribution. It seems that the effect of effort overruns just increases labor cost and causes less damage to project contribution, whereas increases in schedule slippage triggers two independent and additive increases in cost - labor costs and contractual penalties for late completion. Our results suggest that although both types of capabilities, namely schedule estimation and management, and effort estimation are significantly related to performance, the former makes a higher marginal contribution to performance. Therefore, our results suggest that firms may be 19 The semi-elasticities for the coefficients on the capabilities measures were computed as _ aF(X, f) with all the variables fixed at their means. the variables fixed at their means. 36

better off erring on the side of caution and overstaffing their project teams rather than facing the prospect of a schedule slippage. Finally, we found some evidence for the evolution of capabilities over time and its impact on project contribution. We found that a tighter control of effort overrun in projects in 2001 resulted in better project contribution as compared with projects in 1996-2000. On the other hand, we found that an increase in schedule slippage from 1996-2001 has had a significant negative effect on project contribution20. In sum, it seems that the firm needs to focus significant efforts on improving its capability to tightly manage schedule slippages. We believe our study of firm capabilities and their effects on performance in the context of the software services industry has raised several important issues. First, our study has sought to make the case that identifying the capabilities that are the sources of performance differences need to be contextually grounded. Each industry is driven by its own demand- and supply-side economics. It is important to take this into account while identifying and measuring capabilities. It seems that there are indeed significant differences in the way the same firm deploys its resources, both across projects and over time. Holding project inputs and characteristics (i.e., project size, team size, technology, and industry of application) constant we found that an improvement in project management capabilities resulted in increases in project contribution. Put simply, our results demonstrate that differential project profits can be a function of differences in the way the same resources are deployed by the firm. Also, we found some evidence that an improvement in the productive deployment of resources over time yielded increases in project profitability as well. This provides reason to take more seriously Penrose's (1959) key insight 20 We avoid calculating semi-elasticities for the interaction terms. The typically high correlations between the main effect and the interaction effect result in imprecisely estimated coefficients. As a result, computing accurate economic significance of these coefficients becomes difficult. 37

that differential firm capabilities in productively deploying resources lie at the heart of firm performance differences. Second, it appears that measuring capabilities at more micro levels within a firm is quite promising. It not only helps better estimate their economic significance but also provides clear guidelines to the firm on where and how it needs to improve its capabilities. Measures of capabilities at the aggregate firm-level, while useful in identifying between-firm differences, provide little understanding of the micro-foundations of such inter-firm differences. As our study demonstrates, measurement of firm capabilities at the micro-level holds promise of enhancing our understanding "how" and "why" some firms perform better than others. Lastly, our analyses also show that the marginal returns to different capabilities are not uniform. Given scarce managerial resources, it is useful for firms to first identify the capabilities that provide the highest marginal returns to performance and then direct the bulk of its resources to acquiring them. Building capabilities requires significant and, often, irreversible commitment of real resources, both financial and managerial. Decisions about which capabilities to acquire or build require due diligence in the analysis of costs and benefits. Moreover, it is likely that different firms will face different costs and benefits of acquiring the same capabilities given the interdependencies and complementarities with various other organizational choices (Ethiraj & Levinthal, 2002). For instance, for a firm that engages in relatively few repeat projects, the marginal benefit of client-specific capabilities is likely to be significantly less than the marginal benefit of project management capabilities (this would generally be the case for smaller or newer firms who are likely to have fewer repeat clients in their early years). The converse is likely to be true in the case of a firm that engages in a large number of repeat projects. In fact, the latter set of firms could also explore the feasibility of investing in creating deliberate and institutionalized 38

mechanisms to build their client specific capabilities than leaving it to tacit learning by doing. Our fieldwork seems to support this contention. Finally, in our dataset, if we assume that the marginal cost of acquiring different project management capabilities are the same, our results suggest that the firm would be well advised to expend resources to improve schedule estimation and management capabilities so as to tightly manage schedule slippages. Improvements in this capability promise to provide higher marginal improvement in project contribution performance. 7. Limitations and directions for Future Research In this paper we have attempted to study capabilities and how they affect performance in the context of a software services firm. However, like any study, our study also has some limitations. First, it is based on a single service industry with its own peculiar characteristics. It is not clear to what extent the substantive results of this paper are generalizable across industries. At the same time, as we have asserted above, capabilities are usually context-specific, i.e., industry specific, and capabilities that are generalizable across industries are likely to be overly abstract. A second limitation is that our study is based on data from a single firm. Ideally, we would have liked to include data from a few more firms. However, getting access to such detailed data of great competitive significance is a difficult challenge. In our case, this involved several years of data collection, ongoing negotiations with the firm concerned, and the signing of non-disclosure agreements. Third, since our analysis is based on data from only one firm we could not make any explicit inter-firm comparisons of competitive advantage. However, since the firm is among the top five firms in the industry on several dimensions such as growth, total revenues, etc. it gives us some confidence for drawing the capabilities-performance link. In spite of some of the data limitations outlined above, some of the unique aspects of our dataset outweigh some of these disadvantages. First, the data on resource inputs (team size, 39

experience, etc) and capabilities allow us to empirically measure Penrose's (1959) key distinction between available resources (factor inputs such as labor) and how they are deployed (i.e., productivity of resources). Second, the data on project-level contribution performance suffers from relatively fewer problems associated with aggregate accounting data. Finally, our design allows us to combine the depth and richness of longitudinal, single firm case studies with the rigor of large-sample empirical estimation. Lastly, our identification of capabilities in the software services industry is by no means comprehensive. For instance, people related capabilities are conspicuously absent from our study. Unfortunately, we were unable to obtain data on skills and qualifications of project team members. In future research, we hope to deal with some of these limitations. In conclusion, the paper attempted to take an initial step in teasing out the importance of capabilities and estimating their impact on performance. We hope that the spirit of this paper in advocating the importance of contextually grounded studies of firm capabilities will spur further research along these lines in other industries. The shift in research focus from whether or not capabilities matter to "what" capabilities matter and "how" they matter, promises to enrich research on capabilities. 40

References Albrecht AJ, Gaffney JE. 1983. Software function, source lines of code, and development effort prediction: A software science validation. IEEE Transactions on Software Engineering SE-9(6): 639-648. Amit R, Schoemaker PJH. 1993. Strategic assets and organizational rent. Strategic Management Journal 14(1): 33-46. Andrews K. 1971. The concept of corporate strategy. Richard D. Irwin: Homewood, IL. Arora A, Arunachalam VS, Asundi J, Fernandes R. 2001. The Indian software services industry. Research Policy 30(8): 1267-1287. Banerjee AV, Duflo E. 2000. Reputation effects and the limits of contracting: A study of the Indian software industry. Quarterly Journal of Economics 115(3): 989-1017. Barney J. 1991. Firm Resources and Sustained Competitive Advantage. Journal of Management 17(1): 99-120. Brush TH, Artz KW. 1999. Toward a contingent resource-based theory: The impact of information asymmetry on the value of capabilities in veterinary medicine. Strategic Management Journal 20: 223-250. Chatterjee S, Hadi AS, Price B. 2000. Regression analysis by example (3rd ed.). John Wiley & Sons: New York. Cohen WM, Levinthal DA. 1990. Absorptive Capacity: A New Perspective on Learning and Innovation. Administrative Science Quarterly 35(1): 128-152. Collis DJ. 1996. Organizational capability as a source of profit. In Moigeon, Edmondson (Eds.), Organizational learning and competitive advantage. SAGE Publications: London. Dierickx I, Cool K. 1989. Asset Stock Accumulation and Sustainability of Competitive Advantage. Management Science 35(12): 1504-1512. Dosi G, Nelson RR, Winter SG. 2000. Introduction. In G Dosi, RR Nelson, SG Winter (Eds.), The nature and dynamics of organizational capabilities. Oxford University Press: New York. Ethiraj S, Levinthal DA. 2002. Modularity and innovation in complex systems. Academy of Management Proceedings 2002: C1-C6. Grant RM. 1991. The resource-based theory of competitive advantage: Implications for strategy formulation. California Management Review 33(3): 114-135. Harter DE, Krishnan MS, Slaughter SA. 2000. Effects of process maturity on quality, cycle time, and effort in software product development. Management Science 46(4): 451-466. 41

Helfat CE. 1994. Evolutionary trajectories in petroleum firm R&D. Management Science 40(12): 1720-1747. Henderson R, Cockburn I. 1994. Measuring competence? Exploring firm effects in pharmaceutical research. Strategic Management Journal 15(Special Issue): 63-84. Herbsleb J, Zubrow D, Goldenson D, Hayes W, Paulk M. 1997. Software quality and the capability maturity model. Communications of the ACM 40(6): 30-40. Humphrey WS. 1989. Managing the software process. Addison-Wesley: Cambridge, MA. lansiti M, Khanna T. 1995. Technological Evolution, System Architecture and the Obsolescence of Firm Capabilities. Industrial & Corporate Change 4(2): 333-361. Jalote P. 1997. An integrated approach to software engineering. Springer-Verlag: New York. Jones C. 1997. Software quality: Analysis and guidelinesfor success. International Thomson Computer Press: Boston. Kale P, Dyer JH, Singh H. 2002. Alliance capability, stock market returns and long-term alliance function: The role of the alliance function. Strategic Management Journal 23(8): 747-767. Klein B, Crawford RG, Alchian. 1978. Vertical Integration, Appropriable Rents, and the Competitive Contracting Process. Journal of Law & Economics 21(2): 297-326. Krishnan MS. 1996. Cost and quality considerations in software product management, Graduate School of Industrial Administration. Carnegie Mellon University: Pittsburgh. Langlois RN. 1992. Transaction cost economics in real time. Industrial and Corporate Change 1(1): 99-127. Levinthal DA. 1997. Adaptation on rugged landscapes. Management Science 43(7): 934-950. Makadok R, Walker G. 2000. Identifying a distinctive competence: Forecasting ability in the money fund industry. Strategic Management Journal 21(8): 853-864. Market Guide. 2002. Software and programming companies list. Internet, http://biz.yahdoo.com/p/softwrttmd.html. McGrath RG, MacMillan IC, Venkataraman S. 1995. Defining and developing a competence: A strategic process paradigm. Strategic Management Journal 16(4): 251-275. Nasscom. 2001. The Indian Software Industry Report. Nasscom: New Delhi. Nelson R, Winter S. 1982. An evolutionary theory of economic change. Belknap Press: Cambridge, MA. Nelson RR. 1991. Why Do Firms Differ, and How Does It Matter? Strategic Management Journal 12(Winter): 61-74. 42

Paulk MC, Curtis B, Chrissin MB, Weber CV. 1993. Capability Maturity Model, Version 1.1. IEEE Software 10(4): 18-27. Penrose ET. 1959. The theory of the growth of thefirm. John Wiley: New York. Peteraf MA. 1993. The cornerstones of competitive advantage: A resource-based view. Strategic Management Journal 14(3): 179-191. Porter ME. 1991. Towards a Dynamic Theory of Strategy. Strategic Management Journal 12(Winter): 95-117. Rosenbloom RS. 2000. Leadership, Capabilities, and Technological Change: The Transformation of NCR in the Electronic Era. Strategic Management Journal 21(10-11): 1083 -1103. Rumelt RP. 1984. Toward a strategic theory of the firm. In RB Lamb (Ed.), Competitive Strategic Management: 556-570. Prentice-Hall: Englewood Cliffs: NJ. Rumelt RP. 1987. Theory, strategy, and entrepreneurship. In D Teece (Ed.), The Competitive Challenge: 137-158. Ballinger: Cambridge, AM. Schroeder RG, Bates KA, Junttila MA. 2002. A resource-based view of manufacturing strategy and the relationship to manufacturing performance. Strategic Management Journal 23: 105-117. Selznick P. 1957. Leadership in administration: A sociological interpretation. Harper & Row: New York. Silverman BS. 1999. Technological resources and the direction of corporate diversification: Toward an integration of the resource-based view and transaction cost economics. Management Science 45(8): 1109-1124. Wernerfelt B. 1984. The resource-based view of the firm. Strategic Management Journal 5: 171 -180. Whang S. 1995. Market provision of custom software: Learning effects and low balling. Management Science 41(8): 1343-1352. Winter S. 1990. Survival, selection, and inheritance in evolutionary theories of organization. In JV Singh (Ed.), Organizational Evolution: New Directions: 269-297. Sage: New York. Winter SG. 1995. The four Rs of profitability: Rents, resources, routines, and replication. In CA Montgomery (Ed.), Resource-based and evolutionary theories of thefirm: Towards a synthesis: 147-178. Kluwer Academic Publishers: Boston, MA. Zollo M, Winter S. 2002. Deliberate learning and the evolution of dynamic capabilities. Organization Science 13(3): 339-351. 43

Table 1 Descriptive statistics and correlation matrix of variables (N=138) Variables Mean S.D. 1 2 3 4 5 6 7 8 9 10 11 12 Log(Contribution) 4.875 1.314 Log(Size) 6.458 1.491 0.489* Log(Team size) 2.117 0.668 0.609* 0.679* Log (Person months) 3.077 1.041 0.675* 0.670* 0.741* Log(Duration) 4.884 0.601 0.459* 0.536* 0.470* 0.639* Customer type 0.159 0.367 0.100 0. 169* 0. 177 * 0.235* 0.195* Process defects 0.630 1.980 -0.319* -0.638* -0.302* -0.41 1 -0.276* -0.117 Schedule slippage 0.0 18 0.093 -0.138 0.026 0.034 -0.052 -0.045 0.087 -0.028 Effort overrun 0.050 1.174 -0.077 -0.037 0.033 0.043 -0.002 0. 148* 0.006 -0.142 Contract type 0.609 0.490 -0.254* -0.080 -0.117 -0.059 -0.038 0.023 0.115 -0.102 -0.138 Year 1999.05 1.479 0.120 -0.081 0.013 -0. 156* -0.249* -0.375* 0.113 -0. 140* 0.043 -0.085 Effort overrun * Y2001 -- -- 0.089 0.009 0.056 0.08 1 0.03 1 0.028 0.007 -0. 195 * 0.544* -0.083 -0.026 Schedule slippage * Yearl996 -- -- 0.027 -0.044 -0.006 0.077 -0.03 1 0.136* 0.034 0.353* 0.052 -0.080 -0.235* 0.006 Note:- Stars indicate coefficients significant at 0.05 level or lower. 44

Table 2 Regression estimates (N=138) Independent Pred. Dependent variable: Log(Contribution) _____ variables Sign Model 1 Model 2A Model 2B Model 3A Model 3B Model 4 Customer type - -0.841 -0. 154 ** -0.687 -0.118 t -0.108 (0.538) (0.055) (0.531) (0.070) (0.191) Process defects - -0.037 -0.049 ** -0.038 (0.046) (0.014) (0.042) Schedule slippage - -3.493 * -2.734 ** -4.790 (1.582) (0.486) -0.823 Effort overrun - -0. 197* -0. 166* -0.422** (0.087) (0.037) (0.094) Schedule slippage - *Y1996 7.355 (1.873) Effort overrun * + Y2001 0.297 * _ _ _ _ _ _ _ _ _ _ _ _ _ _(0.1 1 8 ) Controls Contract type -0.309 -0.289 -0.463 -0.321 t -0.538 -0.512 (0.202) (0.201) (0.071) (0.193) (0.071) (0.14) Project size (FP)a 0.108 0.103 0.059 0.092 0.012 0.119 (0.096) (0.095) (0.037) (0.111) (0.037) (0.083) Temsza 0.057 0.074 0.041 0.055 0.237 0.118 (0.272) (0.282) (0.088) (0.281) (0.085) (0.189) Person monthsa 0.675** 0.602** 0.731** 0.517** 0.598** 0.477** (0.175) (0.179) (0.071) (0.179) (0.062) (0.137) Duration a0.233 0.258 0. 198 * 0.363 t 0.250 ** 0.278 t (0.23) (0.228) (0.099) (0.221) (0.079) (0.167) Domain controls Sig. Sig. Sig. Sig. Sig. Sig. Platform controls Sig. Sig. Sig. Sig. Sig. Sig. Year effects Sig. Sig. Sig. Sig. Sig. Sig. Constant 1.459 1.033 1.985 0.976 1.712 1.550* ____(1.063) (0.982) (0.366) (0.981) (0.291) (0.728) Adjusted R-square 0.66 0.672 -- 0.704 -- 0.719 N 138 138 138 138 138 138 F-Value / Wald Chi-Sq 11.04** 10.51* 1641.72** 9.50** 2062.54** 8.82** F-Test for client fixed effects ____2.06 * 1.82 ** -1.78* -- 1.72* a'Variables are logged *** p<=O.O0l; ** p <=0.01; *p<=O.OS; tp<=O.lIO Standard errors are reported in parentheses 45