WHERE DO CAPABILITIES COME FROM AND HOW DO THEY MATTER? A STUDY IN

Strategic Management JournalStrat. Mgmt. J., 26: 25–45 (2005)

Published online 28 October 2004 in Wiley InterScience (www.interscience.wiley.com). DOI: 10.1002/smj.433

WHERE DO CAPABILITIES COME FROM AND HOWDO THEY MATTER? A STUDY IN THE SOFTWARESERVICES INDUSTRY

SENDIL K. ETHIRAJ,1 PRASHANT KALE,1* M. S. KRISHNAN1 andJITENDRA V. SINGH2

1 University of Michigan Business School, Ann Arbor, Michigan, U.S.A.2 The Wharton School of Business, University of Pennsylvania, Philadelphia,Pennsylvania, U.S.A.

Recent years have witnessed a surge of interest in the notion of capabilities as an importantsource of competitive advantage. This recognition has, in turn, placed emphasis on the questionof where and how these capabilities emerge and how they influence firm performance. The presentpaper is an attempt to address this question. Using a large sample of detailed project-level datafrom a leading firm in the global software services industry, we attempt to empirically study theimportance of capabilities. We find that two broad classes of capabilities are significant. Thefirst class, which we label client-specific capabilities, is a function of repeated interactions withclients over time and across different projects. This learning from repeated interactions with agiven client reduces project execution costs and helps improve project contribution. The secondclass, termed project management capabilities, is acquired through deliberate and persistentinvestments 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 bedifferent and an understanding of such trade-offs can improve firm decisions to improve and/oracquire such capabilities. We discuss the key contributions of our paper and the implications forfuture research on capabilities. Copyright 2004 John Wiley & Sons, Ltd.

INTRODUCTION

In recent years strategy scholars have increasinglyagreed that non-imitable and non-substitutable or-ganizational capabilities (and resources) are akey source of inter-firm performance differences(Barney, 1991; Dosi, Nelson, and Winter, 2000;

Keywords: organizational capabilities; firm performance;software services*Correspondence to: Prashant Kale, University of MichiganBusiness School, 701 Tappan Street, Room D4209, Ann Arbor,MI 48109, U.S.A. E-mail: [email protected]

Nelson, 1991; Rumelt, 1984; Wernerfelt, 1984).This recognition has, in turn, placed emphasis onthe question of where and how these capabili-ties emerge and how they influence firm perfor-mance. Although there are a number of theoreticalarguments about the characteristics of resourcesor capabilities that yield competitive advantage(Barney, 1991) and what prevents their imitation(Dierickx and Cool, 1989; Peteraf, 1993), we havelimited understanding of where capabilities comefrom or what kinds of investment in money, time,and managerial effort is required in building them.

Copyright 2004 John Wiley & Sons, Ltd. Received 10 December 2002Final revision received 4 June 2004

26 S. K. Ethiraj et al.

Furthermore, if the development of capabilitiesrequires deliberate and sustained investment offinancial and managerial resources, both of whichhave alternative uses, it becomes important tounderstand the costs and benefits of such invest-ments. In other words, different capabilities mayentail different financial and managerial costs andyield dissimilar performance benefits. The system-atic understanding of such trade-offs promises toenrich the theory and practice of strategy. Thispaper makes a modest attempt to systematicallyaddress some of these questions.

This paper investigates two interrelated researchquestions: one, where do capabilities come from,and two, how do capabilities affect firm perfor-mance? We combine in-depth interview data withdetailed, large sample, project-level data spanninga 6-year period from one firm in the Indian soft-ware services industry to carefully address bothquestions. In contrast with prior research, the rich,disaggregated project-level data about resourceinputs, project characteristics, capability metrics,and profitability that we collected allow us to delvedeeper into the capabilities–performance link.

Several reasons make the Indian software indus-try an attractive context for the study of firmcapabilities. First, there is a widely shared viewthat much of the Indian software industry’s explo-sive growth over the last decade is accounted forby factor cost differences between India and thedeveloped country markets (Arora et al., 2001;Nasscom, 2001). The implication is that perfor-mance differences are driven not by firm capabil-ity differences, but by country-level comparativecost advantages. While factor cost differences def-initely exist, even a cursory examination of thedata suggests that firm-level explanations cannotbe discounted. The Indian software services indus-try accounted for $6.2 billion of export revenuesin 2000–01 (Nasscom, 2001). A telling statistic isthat 0.8 percent (25 firms) of the firms in the indus-try (nearly 3000 firms) accounted for 60 percent ofexport revenues. Therefore, a relatively small setof firms growing at a compounded average annualrate of about 45–65 percent over the last decadeaccounts for much of the activity in the Indiansoftware services industry. Our premise is that adetailed examination of the economics of one ormore of these 25 firms can afford useful insightinto the micro-foundations of the capabilities thatunderlie such sustained and robust growth in acompetitive industry.

Building on research on firm capabilities ingeneral and on our detailed fieldwork and inter-views with the project managers of several firms inthe software services industry, we argue that twosets of capabilities are important in the softwareservices industry: client-specific capabilities andproject management capabilities. Client-specificcapabilities are a function of repeated interac-tion with a given client across multiple projectsover time. They largely reflect tacit knowledge ofthe client’s business domain and operating rou-tines acquired through repeated interaction withthe client. In contrast, project management capa-bilities are acquired through deliberate and per-sistent investments in infrastructure (systems andprocesses) and training to improve the firms’ soft-ware development processes. They reflect techni-cal capabilities in software design, development,and execution. The development of these capabil-ities rests not only on implicit learning-by-doingprocesses but also on deliberate, proactive invest-ments in building them. For example, drawing onindustry experience, some scholars derived eco-nomic models to show that it makes economicsense for software vendors to initiate the firstproject with a client at low prices even if itamounts to a modest loss on the project. The firstproject serves as a platform for the developmentof client-specific and project management capa-bilities that help significantly reduce costs in thelong run and ultimately generate positive returns(Whang, 1995). In our empirical analyses, we esti-mate the marginal contribution, cross-sectionallyand temporally, of the two capabilities to projectprofitability.

The study makes two principal contributions tothe extant literature on capabilities. First, we argue,and empirically demonstrate, that firm capabili-ties are often context-specific and fruitful researchin this area might emanate from enjoining anin-depth study of the capabilities specific to acontext and careful empirical estimation of theirsignificance and value. The distinguishing featureof our work is that we conceptualize the notionof capabilities at a more micro-level within thefirm, namely the project(s) which the firm exe-cutes for its clients, develop appropriate measuresfor these capabilities, and examine their evolutionand impact on financial performance. Second, weargue, and show, that not all capabilities providethe same marginal contribution to performance.

Copyright 2004 John Wiley & Sons, Ltd. Strat. Mgmt. J., 26: 25–45 (2005)

Where Do Capabilities Come From and How Do They Matter? 27

This is significant because it suggests that if dif-ferent capabilities have different costs and benefitsassociated with their development or acquisition,managers should pay attention to understandingthese trade-offs in making investments in capabil-ity development. More broadly, our study advo-cates a shift in the debate from whether or notcapabilities matter to ‘what’ capabilities matter and‘how.’

The rest of the paper is organized as follows. Inthe next section, we briefly outline the research lit-erature on capabilities and how capabilities driveperformance differences. We then describe theIndian software industry context in some detail anddevelop our hypotheses. In the following sectionwe describe the data, the measures, and empiri-cal estimation procedures. Finally, we present theresults and discuss their implications for researchon capabilities.

THEORY

What are capabilities and why are theyimportant?

The notion of capabilities can be traced back toPenrose (1959) and Andrews (1971), among oth-ers (see also Selznick, 1957). Penrose (1959: 25)suggested that resources consist of a bundle ofpotential services. While these resources or factorinputs are available to all firms, the ‘capability’to deploy them productively is not uniformly dis-tributed. Analogously, Andrews (1971) argued thatthe ‘distinctive competence’ of an organization ismore than what it can do; it is what it can doparticularly well. Building upon this earlier work,recent literature on the resource-based view con-ceptualizes resources and capabilities along twolines. One set of authors (see, for example, Barney,1991; Peteraf, 1993) tend to define resources ratherbroadly so as to ‘include all assets, capabilities,organizational processes, firm attributes, informa-tion, knowledge, etc.’ (Barney, 1991: 101). Otherauthors, however, have sought to clearly delin-eate between resources and capabilities (Amit andSchoemaker, 1993; Grant, 1991) by arguing that‘resources consist . . . of know-how that can betraded, financial or physical assets, human capitaletc. . . . [whereas] capabilities . . . refer to a firm’scapacity to deploy resources’ (Amit and Schoe-maker, 1993: 35). In this paper, we adopt the latterconceptualization of firm capabilities in developing

our arguments about where they come from andhow they matter.

These definitional and conceptual differencesnotwithstanding, strategy researchers agree thatboth resources and capabilities are essentiallyassets with rent-generating potential. The resource-based view literature largely emphasizes two kindsof rents1 they can generate. The first parallels thetextbook notion of (Ricardian) rents from scarceresources. Ownership of a scarce resource (sayland in Manhattan) enables the owner to enjoysuperior rents relative to competitors who do notown the resource (they lease the land). The scarcityrents here are rooted in the inelastic supply curvefor the resource. In addition, there is the implicitcondition that, all else being equal, the cost of own-ership is less than the lease cost. This means thatat the time the scarce resource was acquired itsprice was less than its (future) marginal product(Peteraf, 1993).

A second type of rent is quasi-rents (Klein,Crawford, and Alchian, 1978). Quasi-rents ‘are theexcess of an asset’s value over its salvage value orits value in its next best use’ (Peteraf, 1993: 184).Quasi-rents are often associated with capabilities.The primary reason for this is that they are con-sidered to be a product of specialized assets thatare embedded within the organizational context(Rumelt, 1987) such that their optimal deploymentis contingent on the presence of other complemen-tary assets (e.g., managers, culture, technology) oreven learning how to deploy the bundle of assetsefficiently. Additionally, there is a cost involved intransferring this asset along with the complemen-tary assets to another firm, thereby reducing itsproductive value (Langlois, 1992). This differencein value is the quasi-rent accruing to the owner ofthe asset. Usually, quasi-rents are a function of theuncertainty about the production function underly-ing the deployment of resources (Rumelt, 1984). Inthis paper, our notion of capabilities reflects assetsthat can generate quasi-rents.

Where do capabilities come from?

Traditionally, strategy research has devoted lit-tle attention to the issue of where capabilities

1 Note that Winter (1995) refers also to Schumpeterian rents—entrepreneurial rents or rents from innovation—and monopolyrents—rents from output restriction under inelastic demand.Since neither of these rents is associated with resources orcapabilities we do not discuss them here.



come from. Nelson and Winter (1982) made oneof the early theoretical attempts to understandthis question. They viewed the firm as bundlesof path-dependent knowledge bases. Over time,firms’ knowledge, accumulated through ‘learningby doing,’ is embedded in bundles of ‘routines’that are likened to the genetic material of the firm.Routines, a central concept in evolutionary the-ory, involve repetitive patterns of activity, requireinvestment in routine-specific human and physicalcapital, and are easily recognized as belonging to aclass (Winter, 1990). An important element of theirtheory is the description of the firm as a historicalentity, with productive knowledge being a result ofendogenous, learning-by-doing processes. Conse-quently, this perspective sees firms as entities thatpossess heterogeneous capabilities as a function oftheir routines and search processes. These capabil-ities are rooted in the organizational skills and rou-tines that serve as organizational memory to repeti-tively execute the sequence of productive activitieswithout trouble. At their core, these organizationalskills and routines embody knowledge and compe-tence in carrying out the productive activities thatthe firm is engaged in. Building on the basic ideathat history matters and that capabilities are rootedin contextually embedded knowledge underlyingthe production function, others have emphasizedthe significance of absorptive capacity (Cohen andLevinthal, 1990) and asset stocks and flows (Dier-ickx and Cool, 1989) in driving capabilities-basedcompetition.

Some researchers have also suggested that capa-bilities are not merely the result of tacit accu-mulation of experience embedded in routines andlearning by doing. They are also the result ofdeliberate investments in organizational structureand systems to make constant improvements inthose routines and practices (Zollo and Winter,2002). Organizations strive to adapt their oper-ating processes through proactive actions dedi-cated to process improvements. These may includeexplicit efforts to continuously learn and capturethe lessons from prior experience of self or oth-ers (Collis, 1996; Zollo and Winter, 2002) andincorporate those lessons to make improvements inprevalent practices, or create formal mechanismsto coordinate and institutionalize the improvementefforts (Kale et al., 2002). Although the notionof making deliberate investments to improve firmcapabilities may be understood uniformly by mostfirms, there are idiosyncratic firm-level differences

in the timing of this effort, the nature and amountof the investment and effort they undertake, andthe internal organizational mind-set that supportsthis process. These differences may get reflected insignificant heterogeneity across firms with respectto the capabilities that result from this effort.

In sum, it appears that in operationalizing thenotion of capabilities it is important to showthat: (1) capabilities involve the deployment ofresources and there are strong theoretical reasonsthat undergird how and why they generate rents;(2) capabilities tend to evolve over time to reflectthe joint effects of passive learning-by-doing anddeliberate firm-level investments in learning andmaking improvements; and (3) capabilities arehard to imitate or easily acquire in factor marketsand this forms the basis for rent generation.

How do capabilities matter?

The question ‘How do capabilities matter?’ isone that derives from the question posed earlier,‘Where do capabilities come from’? We arguedabove that capabilities reflect the evolutionary pro-cess of deliberate firm-specific investments and thelargely tacit ‘learning-by-doing’ that firms engagein. This in turn results in heterogeneity of firms andthe consequent differences in their performance.If we assume for the moment that ‘learning-by-doing’ is distributed uniformly2 among firms, thenmost of the ex post firm performance heterogeneityis in fact a function of differences in the delib-erate, firm-specific investments made (see Helfat,1994, for an excellent account of how differentialR&D investments by a sample of petroleum firmsled to firm heterogeneity). Differences in the expost productive value of firm-specific investmentssuggest that firms face significant ex ante trade-offs in their choices of firm-specific investmentsmade to acquire certain capabilities. In the main,we expect that the trade-offs themselves are likelyto vary between firms as well as within firms overtime.

Each firm needs to make a set of strategicchoices that fit together as a system (Porter, 1991).In making these choices, firms face significanttrade-offs, and the nature of the trade-offs can vary

2 The assumption of uniformity in learning-by-doing is unrealis-tic simply because it is likely to be endogenous with the choicesof firm-specific investments. In effect, this assumption is plau-sible only if we can separate out learning-by-doing from thechoices about firm-specific investments.



over time as well. The trade-offs are primarily afunction of the interdependencies between the var-ious strategic choices of the firm (Levinthal, 1997).When the choice to invest in acquiring a capabil-ity shares positive interactions with other choiceswithin the firm, the marginal benefit of acquiringthe capability is likely to be higher than in thecase when the choice shares negative interactionswith other choices made by the firm. Simply put,different capabilities are likely to yield differentmarginal benefits to the firms making the invest-ments in such capabilities. If indeed money andmanagerial time and effort are scarce and firmsneed to allocate these scarce resources among com-peting initiatives to acquire relevant capabilities,then it is of significant theoretical and practicalimportance to understand the trade-offs they facein doing so. Theoretically speaking, the answer tothis puzzle is rather obvious—managers shouldinvest in acquiring capabilities that yield the great-est marginal returns to the investment. In prac-tice, however, such a cost–benefit calculus is farfrom simple. We face formidable theoretical andempirical challenges because the interdependen-cies between the various strategic choices that afirm makes are often unknown and the impact onthe firm of altering one choice can be unpredictable(Ethiraj and Levinthal, 2004). Moreover, as a firmattains critical levels on a given capability, itsmarginal returns to investing in the same capabilitymight decline. Alternatively, the marginal returnsto building other complementary capabilities mightincrease. In this paper, we make a modest attemptto examine the marginal returns to different capa-bilities, both cross-sectionally and temporally.

Empirical research on capabilities

The empirical literature on capabilities is fastgrowing and we can partition this body of workalong two broad lines. The first stream of workincludes detailed historical accounts that trackalternative choices made by firms and their perfor-mance outcomes. Several excellent papers in thistradition provide useful insight into the historicaldevelopment and evolution of capabilities (e.g.,Iansiti and Khanna, 1995; Rosenbloom, 2000).Unfortunately, such methods do not permit theestimation of the significance and value of capabil-ities. The second stream of research that includeslarge-sample empirical work has attempted to do

this. Even in this tradition, however, few stud-ies have managed to adequately capture the spiritof the idea. They usually fall short either in thechoice of the independent variables employed tomeasure capabilities or the dependent variable usedto measure performance. Many studies have mea-sured capabilities using aggregate indicators suchas R&D intensity (e.g., Silverman, 1999) at thefirm level. But if capabilities critically reside at theoperational level within firms, aggregate firm-levelmeasures may tend to mask much of the variancewithin firms.

Some recent studies have identified and mea-sured more disaggregated capabilities to addressthis limitation. For instance, Henderson and Cock-burn (1994), using survey data attempted to getat more disaggregated measures of R&D capabil-ity at the program level. They measured archi-tectural competence (ability to integrate knowl-edge within the firm) and component competence(locally embedded knowledge) at the R&D pro-gram level to predict patenting productivity. Sim-ilarly, McGrath, MacMillan, and Venkataraman(1995) measured firm competence at pursuing newinitiatives and identified that deftness and com-prehensiveness are important precursors to compe-tence acquisition and ultimately to the emergenceof competitive advantage. These studies and othersin this tradition (e.g., Schroeder, Bates, and Junt-tila, 2002), however, have been limited to assess-ing firm performance with disaggregated, non-financial measures of performance such as patent-ing or survey-based self-reports of performance.This is not surprising given that it is extremelydifficult to relate disaggregated measures of capa-bilities to aggregate, financial measures of firmperformance. Makadok and Walker (2000), in anotable exception, examine the financial returnsto forecasting ability in the money fund industry.Along similar lines, Brush and Artz (1999) explorethe trade-offs in various services offered by differ-ent firms and their impact on revenue per transac-tion in the veterinary medicine industry.

Our study adopts an approach that is similar tothis latter set of studies. We construct disaggre-gated, context-specific capability measures that areas close to the operational level as is practicallypossible and we construct disaggregated financialmeasures of performance at the same operationallevel. We also track the evolution of these capa-bility measures over time. Most importantly, ourstudy is distinctive from these prior studies in that



we examine the choices made by a single firm overtime and evaluate the performance trade-offs orthe marginal returns to different capabilities that itsought to build over a 6-year period. The follow-ing section develops the key hypotheses advancedin this study.

OVERVIEW OF THE INDIANSOFTWARE SERVICES INDUSTRY

In this section we provide a brief overview ofthe Indian software services industry. We focuson the demand- and supply-side economics of theindustry and attempt to draw out the nature andtype of capabilities that might have the potentialto generate rents.

The Indian software services industry is rela-tively young, with many of its most mature com-panies incorporated in the late-1970s and early1980s. The domestic market for IT services wasalways small and continues, even today, to accountfor only about 25–30 percent of the industry’ssales (Nasscom, 2001). The Indian industry re-ceived a big boost in the early 1990s whenthe demand for IT services in the developedworld outstripped the available supply of skilledlabor. India, which at that time was graduat-ing 150,000 English-speaking engineers a yearwith only a limited demand for their serviceswithin the country, was well placed to take advan-tage of this opportunity. Companies in the devel-oped world began focusing on India to lever-age its low-cost, English-speaking IT manpower.The low levels of initial investment required toenter the software services business and the min-imal regulatory intervention from the Indian gov-ernment, created few, if any, entry barriers orconstraints in these early years. Several hun-dred Indian firms were founded to exploit thisopportunity and the industry witnessed very rapidgrowth. Overall, there was a general consensusthat macro factors such as the access to large,low-cost, English-speaking technical manpower inIndia and improvements in IT-related infrastruc-ture (e.g., high-bandwidth communication lines)set up by private and state-owned enterprises pos-itively influenced the competitive advantage andgrowth of Indian companies (Arora et al., 2001;Nasscom, 2001).

Demand for Indian software services

Faced with a small and undeveloped domesticsoftware services market, Indian software firmsfocused primarily on the export market. Their earlywork, however, was neither technologically verysophisticated nor critical to clients’ businesses.Clients usually did the high-end work such asrequirement analysis and top-level design eitherin-house or through U.S.-based consultants. Theyoutsourced the low-end, labor-intensive work suchas low-level design, coding, testing, support andmaintenance to Indian companies to leverage theirlow-cost activity base. Clients retained the high-end work in the early years either because theirIndian vendors did not possess the requisite skillsto undertake these activities or, even if they did,clients did not have sufficient confidence to entrustsuch activities to them. Thus, the origin of theIndian software industry was firmly rooted inperforming low-end, technically less demandingand labor-intensive work for the global IT indus-try and exploiting labor cost arbitrage opportuni-ties between India and developed country markets(Nasscom, 2001).

Over time, however, there was a change in thistrend. The low entry barriers in the Indian softwareservices industry triggered abnormally high levelsof entry by new firms. Between 1989 and 1998,over 3000 software services firms were foundedthat aspired to serve export markets. Consequently,domestic competition in the labor market (i.e., fortrained engineers) shot up. It was not enough anymore to just possess low-cost labor resources andexploit arbitrage opportunities. Firms also neededto improve the productivity of labor to competeeffectively in the market. Thus, some firms begana systematic push to build high-end software capa-bilities, move up the value chain, and improve rev-enue per employee figures. Consequently, the lead-ing Indian firms today are also the leading firmsin the global market (see Market-Guide, 2002).

Since the mid-1990s there has been a distinctshift in the nature of software projects executed bythe leading Indian software firms. They graduallyshifted their role from that of merely implement-ing a design provided by their overseas clients tobecoming active participants in the design of thecomplete application product. As a consequence,they now span the full spectrum of jobs fromhighly labor-intensive code migration work suchas the integration of old mainframe-based systems



into new e-commerce platforms, or developingnew code for pre-designed applications and soft-ware tools, to projects that involve both conceptualdesign and implementation of customer relation-ship applications and supply-chain managementsystems. The capacity to execute such a range ofjobs enabled these firms to deliver end-to-end solu-tions and, thereby, lay claim to a larger share ofthe client’s IT budget and compete for it with lead-ing firms in the United States such as IBM andAccenture.

Overall, while comparative cost advantages doexist for Indian software firms, they are by nomeans sufficient or even sustainable. First, thenature of services provided by these firms involvesspecialized work (e.g., designing supply chainmanagement systems or setting up trading ex-changes) that requires not only technical knowl-edge of software design but also an in-depth under-standing of the client’s industry and business pro-cess. Second, even firms such as IBM, Sapient, andAccenture have set up subsidiaries in India exploit-ing the same cost advantages. These subsidiariesundertake software projects involving both designand development on latest-technology platformsand business applications. This development notonly supports the argument that Indian softwareteams are capable of executing these high-valueprojects but also erodes much of the Indian firms’traditional cost advantages.

Supply of Indian software services3

Two aspects of the Indian software services indus-try are critical to understanding its supply-sideeconomics: (a) where and how the software devel-opment process is managed and organized; and(b) what type of contracts are used to provide theservices. We elaborate below.

Indian software firms have traditionally executedtwo types of projects: onsite and offshore. In onsiteprojects the Indian firm supplies software profes-sionals who possess the requisite technical skillsthat the clients demand. The entire project is thendeveloped and executed at the clients’ site. In off-shore projects, in contrast, the Indian firm typicallysends a few software professionals to the client

3 The material here draws heavily from an excellent article onthe Indian software industry by Arora et al. (2001).

site to understand its requirements and specifica-tions, but thereafter the entire software is devel-oped in India. The post-development support andmaintenance of the software is also carried outlargely from India. In some cases, a hybrid of thetwo types is also observed. Obviously, the offshoredevelopment model is more cost effective due tolabor market arbitrage. From a cost standpoint, thegreater the proportion of work completed offshore,the lower the cost of project execution (Gopalet al., 2003). This is primarily because in onsiteprojects employees need to be paid in accordancewith host country norms,4 which erodes a signifi-cant proportion of the cost-based advantages thatIndian firms enjoy.

In the early days of the Indian software indus-try, Indian companies executed a majority of theprojects onsite. This happened because, first, theoverseas clients had limited confidence in theIndian firms’ ability to execute projects in confor-mance to their needs. Second, the Indian firms alsohad only a limited understanding of clients’ needsand often required close and regular interactionwith the client. But, over time, as overseas clientsdeveloped confidence in the software capabilitiesof their Indian vendors and the vendors, in turn,developed a better understanding of clients’ needs,it was possible to relocate the bulk of the projectdevelopment activities to India to take full advan-tage of its low-cost development base. Improve-ments in the infrastructure for long-distance com-munication and data transfer facilitated this processas well.

The second significant feature of software ser-vices, both in India and worldwide, involves thetype of contract adopted in software outsourcingarrangements. Contracts can be broadly classifiedinto two categories: fixed price and time & mate-rial (Banerjee and Duflo, 2000). In fixed pricecontracts the vendor charges a fixed fee for itsservices, which is usually negotiated before thestart of the project. Although the vendor bearsmost of the risk in this case, efficient project man-agement can yield potentially higher margins. In a

4 In the United States, issue of H1B visas to overseas softwareprofessionals requires the sponsoring firm to certify that the pro-fessionals are being paid wages commensurate with what a U.S.-based employee with similar qualifications would obtain. Thisprovision was introduced to discourage firms from substitutingdomestic labor with low-cost foreign labor, while allowing themto access specialized labor not easily available domestically.



time & material (T&M) contract, the vendor pro-vides services at a pre-negotiated rate for everyperson-hour of effort expended on the project andreceives payment either at the end of the project orat periodic intervals when project milestones arereached. Here, although a vendor is usually pro-tected against any cost and schedule overruns thatmay arise due to changes in client specifications,there is a concomitant reduction in incentives forthe vendor to execute more efficiently.

In the early years, most Indian software firmspreferred T&M contracts. Since these contractswere behavioral, the client needed a safeguard thatthe Indian firm was not billing them more person-hours than was necessary to execute the project. Soclients typically reduced their risk by negotiatinghard on the price per person-hour. From the Indianvendor’s standpoint, reduced risk came at the costof reduced margins. Therefore, for firms that hadthe capability to manage their projects efficientlyand assume the risks, it made economic senseto move to a fixed-price contract that potentiallyyielded higher margins. In fixed-price contracts,clients often agreed to higher prices because suchcontracts reduced the need for behavioral monitor-ing and had strong penalties associated with delaysor defects in project completion. Thus a combina-tion of improved project execution and manage-ment capabilities and the Indian firms’ impetus toimprove profit margins led to an increasing pref-erence for fixed-price contracts.

Overall, on the supply side the steady transitionfrom onsite to offshore projects and from T&Mto fixed-price contracts meant that an increasingshare of project management risk had to be borneby the Indian firms. This meant that the firmshad to acquire the requisite capabilities to competeeffectively. The following section elaborates whatthese capabilities were and how they played acritical role in Indian firms’ successful evolution.

Capabilities of Indian software services firms

Against the backdrop of the demand- and supply-side economics of the Indian software servicesindustry, two broad sets of capabilities are critical.The first is what we term client-specific capabil-ities. As software firms work with their clientsover time they develop several client-specific pat-terns of interaction that become cost-effective overrepeated interactions. For instance, one of the firmswe interviewed mentioned that clients tend to have

fairly idiosyncratic ways of doing things and ittakes some time to understand and appreciate this.One of this firm’s clients wanted a team of itsemployees to be stationed at the client site for3 months after completion of the project. Initiallythe Indian firm resisted such a demand since itled to increased costs. However, over a period oftime, the firm was able to convince the client thatit could provide the same quality of after-sales ser-vice with the support team based in India. This waspossible because with repeated interaction with thesame client over time software vendors not onlydevelop a better understanding of the informationinfrastructure at the client site but also developbetter clarity of how the software relates to theclient’s business environment. Such knowledge isacquired through repeated interactions with theclient over various stages of the development cyclesuch as requirements specification, business pro-cess design, data preparation, software installation,debugging, and testing. Hence long-term relation-ships and repeated interactions with clients resultedin client-specific learning that had a positive effecton both revenues and costs.

On the revenue side, clients were more will-ing to agree to higher prices on repeat projectsas they developed confidence in the capability ofthe Indian firm to execute projects per their speci-fications. We reckon that Indian firms were able tocapture at least some of the switching costs facedby the client in finding a new vendor and build-ing a new working relationship. On the cost side,there was tangible cost reduction associated withworking with a client over time. For instance, oneof our interviewees pointed to a client who neverspecified requirements very clearly at the outsetand tended to repeatedly come back and ask fornew features after the project was delivered. Whilethis tended to be disruptive initially and createdproblems for the Indian firm, over time it learnedto work around this. Rather than deliver very fin-ished projects, the vendor firm began to involvethe client firm at the prototype stage itself andthen started building in the client firm’s needs asthe project went along. In this manner, they wereable to avoid the post-delivery negotiations andcompletion delays and the associated costs. Suchclient-specific tailoring of projects also enhancesthe software firm’s understanding of the client’sbusiness domain. Thus, repeat projects for clientshelped develop important client-specific capabili-ties that contributed to higher profits by reducing



costs. Therefore, we hypothesize:

Hypothesis 1: Development of client-specificcapabilities based on repeated interaction withclients is positively related to project perfor-mance.

A second capability that is more fungible acrossclients and industry domains is the software devel-opment and project management capability(Humphrey, 1989; Jalote, 1997). The followingthree capabilities are particularly important. (i)Software design and building capabilities: First,vendors must have the capability to understand therequirements of the client and design an appropri-ate system or architecture to address them. Second,they must possess the capability to efficiently andeffectively build the code in conformance to thedesign and coordinate the entire code developmentprocess that is usually distributed across manyteams and/or sites. These capabilities are usuallyreflected in the defects identified in the prod-uct/software during the design and developmentprocess. (ii) Effort estimation and managementcapabilities: Vendors have to be skilled not only inaccurately assessing the requirements of the clientbut also in assessing the resource inputs or effortrequired to build and execute the project. Theyneed to be able to identify appropriate resources(for instance, people with the necessary skill, expe-rience, availability, etc.) and create and use priorexperience/data to arrive at accurate estimates ofthe resource/effort requirements. Further, they alsorequire skills to ensure the effective managementand deployment of the required resources. Poorcapabilities in effort estimation and managementare usually reflected in increased manpower costand/or effort overrun. (iii) Schedule estimation andmanagement capabilities: Once companies havea tentative idea of the resource inputs necessaryto build and implement the project, they must beable to correctly estimate the duration and sched-ule for completing the project. They also need topossess the management skills to ensure that theproject resources are garnered, deployed and man-aged to complete the project within the plannedschedule. Again, poor capabilities on this dimen-sion are reflected in project completion delays andschedule slippages.

Given the importance of the above capabili-ties, in recent years firms have placed a greatdeal of emphasis on software engineering and

project management and have been making invest-ments in improving their processes and capabili-ties. The Capability Maturity Model (CMM) devel-oped by the Software Engineering Institute (SEI)at Carnegie Mellon University is a widely adoptedframework to improve software capabilities. Builton theories of quality and continuous processimprovement, the CMM was first initiated to pro-vide the Department of Defense a standard meansfor measuring contractor capability via its defini-tion of process maturity (Humphrey, 1989). As theCMM became widely adopted as a standard qualityprocess model in the defense sector, commercialorganizations also began to investigate whetherthey could benefit from the approach to softwareprocess improvement expressed in the CMM. Inthe last few years software process improvementbased on the CMM has emerged as an integratedsolution to the software problems in various cor-porations and empirical evidence in support of thesame has been reported (Herbsleb et al., 1997;Krishnan, 1996).

Recognizing the importance of project man-agement capabilities, several Indian firms havebeen the leaders in adopting CMM guidelinesto improve their software development processes.According to SEI, in 2001, of the 42 companiesworldwide certified as having attained a level-5capability, 25 are based out of India. Meetingthese guidelines is not a trivial task. Firms needto make substantial investments in firm infras-tructure, systems, and human capital. The CMMspecifies five maturity levels, each consisting ofseveral key process areas (KPAs), to assess anorganization’s process capability by measuring thedegree to which processes are defined and man-aged (see Paulk et al., 1993: Figure 1). Firms firstneed to do a detailed comparison of their devel-opment and project management processes withthe CMM process quality framework and identifyspecific aspects that need to be improved. Aftermaking these organizational and process changes,software firms need to set up a rigorous metricsprogram to collect data to assess various aspects oftheir development process and institute audit sys-tems to track non-conformance of best practices,process deviations, and exceptions. Measurement-based feedback to improve process capability isachieved through monitoring and review forumsto track improvements and make required changeson a regular basis.



In addition, software firms need to invest intraining programs to improve their process matu-rity under the CMM framework. The trainingactivities mandated by CMM include ongoingtraining in both new technology and software pro-cess and project management skills for softwaredevelopers and managers. To achieve higher lev-els of process maturity, firms need to organizerigorous training of all their employees not onlywith a view to improve their development/projectmanagement practices but also to institutionalizethe entire capability improvement initiative (Paulket al., 1993).

The CMM framework offers generic guidelinesfor institutionalizing disciplined practices acrossvarious activities in software development. Sincethe nature of software development is such thatsoftware teams can quickly turn to ad hoc prac-tices, institutionalization of disciplined practicesand continuous feedback-based improvements canevolve as a core project management capabilityof the firm. Overall, firms can eventually developtheir software development and project manage-ment capabilities as a result of cumulative andintegrated effort across the many process areasof CMM as described above. Eventually the pos-session of these capabilities should lead to bet-ter project-level performance for the firm. Paststudies document the relationship between soft-ware and project management capabilities and pro-cesses and the quality of the products/services pro-vided as well as the efficiency in providing them(Herbsleb et al., 1997; Krishnan, 1996). Eventu-ally, we believe that these benefits should resultin improved project performance in terms of prof-itability. Therefore, we hypothesize:

Hypothesis 2: Higher levels of project manage-ment capabilities will lead to higher levels ofproject performance

While client-specific capabilities and projectmanagement capabilities are both positively relatedto project performance, they might differ in themarginal returns they generate. Even within theset of project management capabilities, it is possi-ble to observe some differences in their marginalreturns. As argued earlier, differences in marginalreturns may arise due to differences in the costsassociated with developing these respective capa-bilities. Our empirical analysis can help shed lighton whether that is indeed the case in our setting.

To summarize the paper so far: We have soughtto understand the origin, significance, and value offirm capabilities. We first argued that capabilitiesreflect the distinctive deployment of resources andalso that they are contextually grounded. We thenelaborated the specific capabilities that are impor-tant in the software services industry, namely,client-specific capabilities that arise in the con-text of repeated interactions with clients over timeand project management capabilities that developthrough deliberate and persistent investments inthe effort and infrastructure to create them. Whileclient-specific capabilities help reduce project exe-cution costs, project management capabilities helpmaintain low cost and high quality all alongthe software development and management valuechain. These capabilities, in turn, provide oppor-tunities for rent generation for firms. We next turnour attention to the significance and value of thesecapabilities as a matter for empirical investigation.

METHODS

Data

We obtained detailed quantitative data at the pro-ject level from a leading world-class softwareservices firm headquartered in India.5 Over90 percent of its revenues are export-based, ofwhich more than 60 percent comes from NorthAmerican clients. The dataset includes informationon revenues, cost, factor inputs, capabilitymeasures, and various project characteristics suchas size, client industry, development platform, etc.,measured at the project level.

We have data on 227 projects executed by thefirm over a 6-year period from 1996 to 2001. How-ever, after dropping single projects and projectswith missing data, our sample was reduced to 138projects.6 The firm has executed these 138 projectsfor 57 different clients over the study period. Ourdataset has 22 new clients for whom the firm exe-cuted its first project during the study period and

5 Since the dataset reveals the economics of the firm and hascompetitive implications, we are unable to reveal the identity ofthe firm.6 We found no statistically significant differences between pro-jects with complete data and those with missing data for thosevariables for which we had complete information. This increasedour confidence that the analyzed data were not systematicallydifferent from the data on all the projects. The results reportedin the paper are estimated using the sample of 138 projects.



35 repeat clients for whom the first project wasexecuted prior to the study period. The averagenumber of projects executed per client is 2.385;the range is from a minimum of 2 to a maximumof 12 projects. Thus, our dataset comprises a panelof 57 clients for whom the firm has executed twoor more projects during the study period.

Model specification and estimation

We assume that the firm produces a single out-put, software services, using skilled labor. Sincethe software services business is highly labor-intensive, the scale of the firm’s operations andits costs depend almost exclusively on manpower.The firm’s profit function from each project isgiven by

πijt = F(P, C(δ, κ))

where, πijt are the profits from project i for clientj in year t . This recognizes that profitability canvary 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, δ, such as size, complexity,duration, and type of contract. The last term inthe equation, κ , captures the capabilities measures,which vary with client and time and also dependon project-specific characteristics δ.

This reflects our hypotheses that capabilitiestend to influence both the prices and costs of soft-ware services. As argued in the previous section,capabilities allow the firm to command a price pre-mium (shift the demand curve), and also reducecosts (shift the supply curve).

We estimated the following equation using pro-ject-level data:

log(πijt ) = β log(wijt ) + χzijt + γ κijt + ε

where the dependent variable, πijt , is project-levelcontribution (revenue minus cost), wijt is the vec-tor of input characteristics that determine costs,zijt is a vector of project specific controls, andκijt reflect the capability measures. The coefficientson the logged variables are directly interpreted aselasticities, while the coefficients on variables mea-sured in levels vary with the magnitude of the

variables.7 We only logged independent variablesthat did not have zero values and retained vari-ables with zero values as levels to avoid estimationdifficulties.

The equation above cannot be estimated usingsimple OLS since there are multiple projectsper client. Any unobserved relationships amongprojects for a given client and the consequentheterogeneity across clients can contribute to het-eroskedasticity and bias the standard errors of thecoefficient estimates. The standard solution to thisproblem is either to use a GLS estimator and cor-rect for panel heteroskedasticity or employ OLSand account for the correlations within each panel(Wooldridge, 2002). In using OLS to estimateequations with panel data such as that employedin this paper, the usual practice is to employa fixed-effects specification8 (Greene, 1997). Thefixed-effects model involves parameterizing theclient-specific effects by including dummies foreach client. We report the results of the estima-tion using, primarily, a fixed-effects specification.As a robustness check, we also report GLS withpanel heteroskedasticity-corrected standard errors.

In the fixed-effects models the coefficient esti-mates are interpreted as the amount of within-panelvariation in the dependent variable (project per-formance) that is explained by the within-panelvariation in the independent variables. Thus, theregression analysis relates changes in project con-tribution across different projects for a given clientto changes in the independent variables after con-trolling for unobserved time-invariant effects, andthe included controls.

Measures

Dependent variable

Project contribution. The dependent variable isproject contribution (revenues minus costs) mea-sured in Indian rupees (INR) recognized on thedate of completion of the project. We chose to

7 We explain our rationale for logging the dependent variable inthe following section. Entering the variables in levels does notchange the results. We report the results on the logged variablesfor ease of interpretation.8 We performed a Hausman test to choose between the random-effects and fixed-effects models. The Hausman test on thefull model yielded a chi-squared test statistic equal to 36.22(p ≤ 0.03), suggesting that the fixed-effects model is preferredover the random-effects model.



focus on the project level because the firm capa-bilities that we study primarily exist and evolveat the project level within firms. However, firmprofitability is essentially an aggregate of project-level contribution so we expect the correspon-dence between project and firm profitability to behigh. Project profitability is an imperfect indica-tor of firm profitability to the extent that it doesnot account for firm-level cost overheads. To beable to use this measure meaningfully we needto adjust the INR values both for inflation andINR–USD (U.S. dollar) exchange rate deprecia-tion over time.9 As we discovered, this is a farfrom simple problem, since identifying an appro-priate price index specific to an export-based soft-ware services firm is quite difficult. Fortunately,we found that a simple solution is to take logs ofthe dependent variable and include year dummiesin the regression estimation. This helps remove theeffect of the adjustment factor from the parametersbeing estimated.10

Independent variables

Client-specific capabilities. As outlined earlier,client-specific capabilities are a function ofrepeated interactions with a given client. Theserepeated 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 inour dataset, we have information on whether theclient is new (i.e., the first project executed for thatclient) or a repeat client (i.e., the firm has executedprojects for that client in the past). For eachproject in the dataset, we have a dummy variable,customer type, coded 0 if the firm has executedprojects for the client in the past and coded 1 if itis the first project executed for the client. Repeatclients are a proxy for client-specific capabilitiesdeveloped by the firm. We expect the sign on

9 The exchange rate depreciation over time is important sincethe firm incurs most of its costs (e.g., wages) in Indian rupeeswhereas its revenues are in U.S. dollars. Therefore, changes inthe rupee–dollar exchange rates will also change the coefficientestimates in the firm profit function.10 For example, C2000 (contribution in year 2000) needs to beadjusted to the same units as C1996 (contribution in 1996). Usu-ally, C2000 is adjusted as C2000/P1996, where the denominator(P1996) is the appropriate index for adjustment. Taking logs,we obtain log(C2000)—log(P1996). Thus if we take logs on thedependent variable and include year dummies, the parametersare free of the adjustment factor. The year dummies absorb theadjustment factor, and since the year dummies are only controlsthe main results and our interpretation remain unaffected.

this coefficient will be negative. Since we alsohave panel data on each client in our sample (i.e.,data on multiple projects done for each client), weused it to estimate a client fixed effect by includinga dummy variable for each client. Though bothmeasures are largely substitutes, the first measurecaptures some information about past projects notincluded in our dataset, and the second produces awithin-sample estimate of the client-specific effect.Since we cannot estimate a single parameter for theclient fixed effects, we only examine whether theyare jointly significant after controlling for input andproject characteristics and time.

Project management capabilities. Project capa-bilities are not client-specific. They are capabil-ities that can, by definition, be leveraged acrossclients, industry domains, and development plat-forms. We used three metric variables to measureproject management capabilities. The first variablemeasures the number of in-process defects iden-tified during the project execution phase. Sincein-process defects can vary by size of the project,we normalized it by a project size measure (FP)described below.11 In-process defects, which mea-sure the defects detected in the product, reflecta firm’s software development and managementcapabilities. Further, there is evidence that the costof fixing defects in the early phases of softwaredevelopment can be substantially lower than thecost of fixing them in the final stages of softwaredevelopment (Jones, 1997). Hence we expect thatlower in-process defects will lead to higher projectcontribution.

A second variable measures effort overrun, i.e.,difference between actual person-months requiredto complete the project and person-months thatwere initially estimated. Effort overrun can affectproject profitability since project costs go upas effort increases. This measure reflects effortestimation and management capability. Effectiveproject management involves minimizing suchoverruns. Since effort overrun is likely to varydirectly with budgeted person-months, we normal-ized effort overrun by the budgeted person-monthsto estimate its main effect. The expected sign onthis coefficient is negative, i.e., higher effort over-run will lead to lower project contribution. It was

11 The measure of project size, called function points (FP), isa composite measure of project size and complexity and isdescribed in greater detail in the subsection below on the controlvariables included in the estimation.



entered as levels (rather than logs) since zero ornegative values are possible.

A third variable measures the extent of scheduleslippage, i.e., delay in project completion date. Itreflects schedule estimation and management capa-bility. Delays in project completion can adverselyaffect profitability since the firm can incur contrac-tual penalties for delays and also bear increasedlabor costs. We expect the magnitude of sched-ule slippage to vary directly with expected projectduration. To control for this, we normalized sched-ule slippage measured in days by project duration(also measured in days). The expected sign on thiscoefficient is negative, i.e., higher schedule slip-page will lead to lower project contribution.

In sum, the capabilities measures employedhere reflect our view that capabilities are dis-tinct from either inputs or resources. While inputsor resources such as capital or labor are acces-sible by all firms at prevailing factor prices,capabilities reflect the deployment of resources(Makadok, 2001). Therefore, capability differencesbetween firms are reflected in productivity differ-ences between them, and within firms in produc-tivity improvement over time. Thus, changes in thecapability measures reflect changes in the produc-tivity of resources over time.

Control variables

We controlled for a variety of other variablesthat might impact project profitability. We brieflydescribe these variables below.

Contract type. There are two types of contractscommonly used in the Indian software servicesindustry: time & material (T&M) and fixed price.As explained earlier, the role of project manage-ment capabilities may differ in the two types ofcontracts. Also, these contracts may vary in termsof their influence on project profitability. To con-trol for the obvious effect of contract type onprofitability we included a dummy variable, whereT&M contract was coded 0 and fixed price wascoded 1. In terms of the risk–return trade-off fixedprice projects are expected to yield superior projectprofitability, suggesting an expectation of a posi-tive sign on the coefficient.

Project size and complexity. We expect projectsize to affect profitability. Though we have nopriors on this, we might reasonably expect that the

size–profitability relationship might be increasingbelow the minimum efficient scale and decreasingabove the maximum efficient scale. We employeda measure of project size, called function points(FP), to reflect a composite measure of project sizeand complexity.12 We logged the FP measure inour estimation and, as a result, the coefficient canbe interpreted as elasticity with respect to projectprofitability.

Team size. We also expect team size to have aneffect on project profitability. As above, we expectproject profitability will increase with team sizewhen the team is too small and overworked anddecrease when the team size is large enough tocreate coordination problems. Team size is loggedin our model and can be interpreted as elasticitywith respect to profitability.

Person-months. The team size measure is imper-fect since there may be attrition13 during the projector some members may work only part-time. Thiswill cause the team size measure to be overstated.A more precise measure of project size is person-months of labor. This accounts for both teammember attrition and part-time manpower usage.Person-months are entered as logs and can be inter-preted as elasticity with respect to profitability.

Project duration. Duration is an important con-trol variable since longer projects are more proneto cost overruns, either due to forecasting diffi-culties or employee attrition. We measure projectduration as the actual months taken for projectcompletion. This measure is entered in logs andcan also be interpreted as elasticity with respect toproject profitability.

Industry domains. The vendor firm we studiedexecuted projects for clients in multiple industries.Since competition and appropriability conditionscan vary by industry and the vendor’s capabili-ties may not be entirely fungible across industry

12 Earlier measures of size and complexity tended to just countthe number of lines of code in software and use it as a proxy. Theproblem with this measure is that the number of lines of codefor a given application varies directly by software platform. Forexample, for a given application, the number of lines of codein Cobol is several times greater than the number of lines ofcode in Java. The FP measure is designed to be independent ofprogramming language (see Albrecht and Gaffney, 1983).13 Employee attrition is historically very high in this industry,ranging from 10 to 30 percent per year.



domains, we include industry dummies to con-trol for industry-specific differences. We includedthree dummy variables for financial services, man-ufacturing, and marketing industries. The omittedcategory was ‘other.’

Development platforms. Profitability can alsodepend on the software platform on which thesoftware is coded. The vendor is likely to facelower costs on platforms on which it has executeda number of prior projects and is likely to incursubstantial learning and start-up costs on newerplatforms. To account for this, we included fourdummy variables to distinguish between WindowsNT, Mainframe, Unix, and Web-based platforms.The omitted category was ‘other.’

Time. We control for time in all our models usingyear dummies. The year dummies reflect the par-ticular year in which each project was started.(We also tested models using year dummies basedon project completion year and found that theresults did not change substantively.) This controlis necessary to capture the variance in the depen-dent variable due to exchange rate fluctuations andinflation. The time dummies are also importantto account for any variation in the proportion ofonsite and offshore projects that the firm has doneover time. No projects in our dataset were exclu-sively onsite or offshore. Unfortunately, the firmdid not have data at the project level on the pro-portion of work done onsite and offshore. The firmconfirmed that there were no dramatic differencesacross projects on the mix of onsite and offshorework. However, there has been some change in thismix over time. Thus including the year dummiesalso helps control for the change in the proportionof onsite and offshore work over time.

RESULTS

Table 1 presents the descriptive statistics and cor-relation matrix of the variables employed in theestimation. From the correlation matrix it is clearthat all the control variables are significantly pos-itively related to project contribution. We alsonote that the relationship between the capabilitymeasures and project contribution is negative asexpected, though only the process defects variableis statistically significant.

Table 2 presents the coefficient estimates fromthe fixed-effects panel regression analysis. The sec-ond column lists the predicted sign on the keyindependent variables in the model. The columnlabeled Model 1 presents results with just the con-trol variables in the model. The R2 for this model ishighly significant and the control variables accountfor about 66 percent of the variance in the data.14

The model also includes the client fixed effects.As expected, the client fixed effect is strongly sig-nificant, providing some prima facie evidence forclient-specific learning and/or switching cost asso-ciated with repeat projects for a given client.15

In Model 2A we added the customer type vari-able to the analysis. The model is again highlysignificant and its adjusted R2 increases to about0.67. The customer type measure sought to cap-ture aspects of client-specific capabilities, such asspecialized investments and learning from repeatedinteractions with the client.16 Though the sign onthe coefficient was in the expected direction, it wasnot statistically significant. Note, however, that theclient fixed effect continues to be highly significanteven in Model 2A.

To investigate the possibility that the client fixedeffect might be capturing variance in the cus-tomer type variable, we re-estimated the modelby dropping the client fixed effect. Since drop-ping the fixed effect can bias the estimates, weemployed a generalized least squares (GLS) modelthat allowed us to correct for heteroskedasticitywithin projects executed for a given client. Theseresults, presented in Model 2B, confirm our conjec-ture. The coefficient on the customer type variableis negative and statistically significant, suggestingthat project contribution, on average, is lower fornew clients as compared with repeat clients. Thisprovides some confidence that client-specific capa-bilities are related to project contribution.

14 We tested for decreasing returns to project and team sizeby introducing their quadratic powers. The coefficients werenon-significant, suggesting that the constant returns to scaleassumption might be reasonable for this dataset.15 To check for multicollinearity, we computed the variance infla-tion factor (VIF) indices and found that the person–monthsvariable had a VIF of 4.42, followed by team size (2.97), sizeFP (2.46), and duration (2.36). The mean VIF for all indepen-dent variables was 2.51, alleviating multicollinearity concerns(Chatterjee, Hadi, and Price, 2000).16 In the dataset used for empirical estimation there is no evi-dence that revenues from repeat clients were systematicallyhigher than that of first-time projects after controlling for projectcharacteristics. Revenues tended to remain constant after adjust-ing for inflation and exchange rate changes.



Tabl

e1.

Des

crip

tive

stat

istic

san

dco

rrel

atio

nm

atrix

ofva

riab

les

(N=

138)

Var

iabl

esM

ean

S.D

.1

23

45

67

89

1011

12

Log

(Con

trib

utio

n)4.

875

1.31

4Log

(Siz

e)6.

458

1.49

10.

489∗

Log

(Tea

msi

ze)

2.11

70.

668

0.60

9∗0.

679∗

Log

(Per

son-

mon

ths)

3.07

71.

041

0.67

5∗0.

670∗

0.74

1∗

Log

(Dur

atio

n)4.

884

0.60

10.

459∗

0.53

6∗0.

470∗

0.63

9∗

Cus

tom

erty

pe0.

159

0.36

70.

100

0.16

9∗0.

177∗

0.23

5∗0.

195∗

Proc

ess

defe

cts

0.63

01.

980

−0.3

19∗

−0.6

38∗

−0.3

02∗

−0.4

11∗

−0.2

76∗

−0.1

17Sc

hedu

lesl

ippa

ge0.

018

0.09

3−0

.138

0.02

60.

034

−0.0

52−0

.045

0.08

7−0

.028

Effor

tov

erru

n0.

050

1.17

4−0

.077

−0.0

370.

033

0.04

3−0

.002

0.14

8∗0.

006

−0.1

42C

ontrac

tty

pe0.

609

0.49

0−0

.254

∗−0

.080

−0.1

17−0

.059

−0.0

380.

023

0.11

5−0

.102

−0.1

38Yea

r19

99.0

501.

479

0.12

0−0

.081

0.01

3−0

.156

∗−0

.249

∗−0

.375

∗0.

113

−0.1

40∗

0.04

3−0

.085

Effor

tov

erru

n∗Y

2001

——

0.08

90.

009

0.05

60.

081

0.03

10.

028

0.00

7−0

.195

∗0.

544∗

−0.0

83−0

.026

Sche

dule

slip

page

∗Y19

96—

—0.

027

−0.0

44−0

.006

0.07

7−0

.031

0.13

6∗0.

034

0.35

3∗0.

052

−0.0

80−0

.235

∗0.

006

Ast

eris

ksin

dica

teco

effic

ient

ssi

gnifi

cant

at0.

05le

velor

low

er.



Table 2. Regression estimates (N = 138)

Independent variables Pred. Dependent variable: log (Contribution)sign

Model 1 Model 2A Model 2B Model 3A Model 3B Model 4

Customer type — −0.841 −0.154∗∗ −0.687 −0.118† −0.108(0.538) (0.055) (0.531) (0.07) (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.823Effort 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.118)ControlsContract type −0.309 −0.289 −0.463∗∗∗ −0.321† −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)Team sizea 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)Durationa 0.233 0.258 0.198∗ 0.363† 0.250∗∗ 0.278†

(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 R2 0.66 0.672 — 0.704 — 0.719N 138 138 138 138 138 138F -value 11.04∗∗∗ 10.51∗∗∗ — 9.50∗∗∗ — 8.82∗∗∗

Wald Chi-Sq. — — 1641.72∗∗∗ — 2062.54∗∗∗ —F -test for client fixed effects 2.06∗∗∗ 1.82∗∗∗ — 1.78∗∗ — 1.72∗∗

a Variables are logged. ∗∗∗ p ≤ 0.001; ∗∗ p ≤ 0.01; ∗ p ≤ 0.05; † p ≤ 0.10. Standard errors are reported in parentheses.

In Model 3A, we included variables for thethree project management capabilities. The over-all model continues to be significant and accountsfor about 70 percent of variance in the data.We find that schedule slippage and effort over-run respectively are significantly negatively relatedto project contribution, suggesting that improve-ment in project management capabilities is rent-generating at the project level. The coefficientfor in-process defects is not statistically signifi-cant though its sign is in the expected direction.17

We explored this result in discussions with project

17 One reviewer suggested that we enter in-process defects as abinary variable given that the modal value is zero. When enteredas a binary (1 or 0) variable, in-process defects was marginallysignificant (at the 10% level).

managers. They reasoned that the identification ofdefects during project execution is indeed a capa-bility since defects can be fixed at lower costduring execution than if they were to be fixedafter the project was completed. In other words,higher values on the in-process defects measuremight indicate better project management skills.On the flip side, they also pointed out that anincrease in the number of in-process defects tendsto disrupt delivery schedules and negatively impactproject profitability. In sum, it seems that while in-process defects do reflect detection capability, theyalso expose some weakness in software design andexecution capabilities; namely why these defectsarose in the first place. In the long run, we expectthat defect detection capability might be positively



related to project contribution, especially withrepeat projects. However, the need to fix defectsduring project execution can disrupt project sched-ules and increase project costs, leading to theobserved result.

In Model 3A, we also find that the customer typevariable remains non-significant when the projectmanagement capabilities measures are includedalong with the client fixed effects. Therefore, weagain re-estimated the model by dropping the clientfixed effects. Model 3B reports the results of theGLS estimation with the correction for panel het-eroskedasticity. Not surprisingly, customer typeturns significant, though only marginally (p ≤0.09). The project management capabilities vari-ables, however, continue to be robustly signifi-cant in the predicted direction. This result seemsto suggest that the project management capabili-ties variables share some common variance withthe client-specific capabilities measure. This runscounter to our hypothesis that they are each dis-tinct sets of capabilities. We discussed this resultwith industry experts, who suggested that by work-ing with a given client over time (i.e., repeatprojects) the vendor firm gains a better understand-ing of the client’s needs and expectations. This, inturn, can help reduce effort overrun and sched-ule slippage accounting for the observed result.The managers in the software firm we studiedtended to agree with this possible interpretation.Finally, we also performed a joint significance testof the project management capabilities. We foundthat the three variables were jointly significant(F = 3.23; p ≤ 0.01), reconfirming the indepen-dent, additional significance of these variables ininfluencing project contribution.

Models 3A and 3B suggest that decreases inschedule slippage and effort overrun respectivelycontribute to increases in project contribution. Wefurther analyzed whether and how project man-agement capabilities evolved over time and howthat affects contribution.18 We included an interac-tion term of schedule slippage with 1996 (the firstyear of data) and effort overrun with 2001 (thelast year of data).19 These results are reported inModel 4. The overall model continues to be highly

18 Ideally we would have liked to examine the evolution ofclient-specific capability over time. It was not possible sinceclient-specific capability is measured as a dummy variable, thusprecluding an interaction term with time.19 We did not include an interaction term with capabilities andtime as a continuous measure since this implies the assumption

significant, accounting for about 72 percent of thevariance in the data. As expected, we find thatthe extent of effort overrun on projects is declin-ing over the 1996–2001 period and this declineis positively related to project performance. Con-trary to expectation, we found that schedule slip-page increased marginally during the 1996–2001period, which adversely affected project contribu-tion in the later years.

To understand this result, we examined the datamore closely and found three possible reasonsthat might explain it. First, the vendor steadilyincreased the number of fixed price projects overthe years and did not manage this transition well.As observed in our data, fixed price projectsexhibit greater schedule slippage than T&M pro-jects. This is also corroborated in the regres-sion results, where we find T&M projects, con-trary to expectations, to be more profitable thanfixed price projects. Second, in the fixed priceprojects we found a greater difference betweenthe team size and person-months measures. Whileteam size reflects the maximum number of per-sons who worked on a given project, the person-months measure captures actual labor input in theproject. At one extreme, if all members of theteam worked full time on a given project theteam size and person-months would be identical.The divergence in the two measures appears whenthere is high turnover in the project teams. Wefound that the difference between the two mea-sures increased over the years, suggesting that anincrease in project team turnover might accountfor the increase in schedule slippage. During the1996–2001 period, the attrition due to employeeresignations fluctuated between 9 and 16 percent.Increase in turnover directly contributes to sched-ule slippages since there is a set-up cost whennew employees enter a project mid-way. Ourdiscussions with company executives revealed athird reason for increase in schedule slippage:

that capabilities change linearly over time. We found no theo-retical or empirical basis for such an assumption. Our results,however, are robust to including year as a continuous variable.However, we were unable to include both interactions in thesame model. The high correlations between the two interac-tion terms created estimation difficulties. Similarly, includingan interaction effect of both capability measures with the sameyear (i.e., 1996 or 2001) created estimation problems since theywere highly correlated. We switched the years to avoid this prob-lem. For completeness, an interaction of schedule slippage with2001 is negative and significant, which is consistent with ourinterpretation.



an increase in e-commerce-related projects in thepost-1996 period. The e-commerce clients, in theireffort to speedily set up their Web infrastructure,set aggressive project completion schedules thatwere difficult for the company to meet. One ormore of these three explanations account for theobserved increase in schedule slippage that in turncontributed to reduced project profitability.

DISCUSSION

We sought to examine two interrelated researchquestions in this paper: Where do capabilitiescome from and how do they affect firm perfor-mance? We made three main arguments in address-ing these questions. First, we suggested that capa-bilities involve the deployment of resources andthey evolve over time through the joint effectsof deliberate, persistent firm-specific investmentsand learning-by-doing. Second, we proposed thatcapabilities are context-specific and, therefore, weneed to conceptualize and study them accordingly.In this paper, we looked at the software servicesindustry and identified two important capabili-ties at the project level: client-specific capabilitiesand project management capabilities. Third, weargued that improvement in capabilities will resultin improved project profitability and that differentcapabilities yield different marginal benefits.

Our results are broadly supportive of our hy-potheses. In the software services industry we findthat capabilities contribute positively to projectperformance. The empirical evidence for the im-portance of client-specific capabilities was onlymodest. In models that included client fixed effectswe did not find support for the effect of client-specific capabilities on contribution. However, inmodels that did not include the client fixed effect,we found that projects for new clients, on aver-age, yield approximately 2 percent lower contri-bution than projects for repeat clients. In modelsincluding the client fixed effect, it appears that thedummy variable capturing repeat or new clients istoo coarse a measure to adequately reflect client-specific capabilities. An ideal measure of client-specific capabilities is a historical count of all theprojects executed for a client (not just a countof projects within the sample period). Unfortu-nately, the firm was unable to provide these data.Nevertheless, the significance of the client-specific

capabilities measure in the GLS model is indica-tive and might be useful to examine carefully infuture research. In addition, we believe that theclient fixed effect might be also picking up somevariance in the learning associated with repeatedinteraction with clients (Anand and Khanna, 2000).

Project management capabilities were gener-ally predictive of higher project contribution.Two of the three measures of project manage-ment capabilities were statistically significant. A1 percent increase in schedule slippage resultedin a 0.6 percent decline in project contribution.20

A 1 percent increase in effort overrun causesa 0.1 percent decline in project contribution. Itseems that the effect of effort overruns justincreases labor cost and causes less damage toproject contribution, whereas increases in sched-ule slippage triggers two independent and addi-tive increases in cost: labor costs and contractualpenalties for late completion. Our results suggestthat although both types of capabilities, namelyschedule estimation and management, and effortestimation are significantly related to performance,the former makes a higher marginal contributionto performance. Therefore, our results suggest thatfirms may be better off erring on the side of cau-tion and overstaffing their project teams rather thanfacing the prospect of a schedule slippage.

Finally, we found some evidence for the evo-lution of capabilities over time and its impact onproject contribution. We found that a tighter con-trol of effort overrun in projects in 2001 resultedin better project contribution as compared withprojects in 1996–2000. On the other hand, wefound that an increase in schedule slippage from1997 to 2001 has had a significant negative effecton project contribution.21 This raises the value ofimproving the capability to better forecast sched-ules and stick to them.

We believe our study of firm capabilities andtheir effects on performance in the softwareservices industry raises several important issues.First, our study has sought to make the case thatidentifying the capabilities that are the sources ofperformance differences need to be contextually

20 The semi-elasticities for the coefficients on the capabilitiesmeasures were computed as mi = ∂F (X, β)/∂Xiβi with all thevariables fixed at their means.21 We avoid calculating semi-elasticities for the interaction terms.The typically high correlations between the main effect and theinteraction effect result in imprecisely estimated coefficients.As a result, computing accurate economic significance of thesecoefficients becomes difficult.



grounded. Each industry is driven by its owndemand- and supply-side economics, which alsochanges over time. It is important to take thisinto account while identifying and measuringcapabilities. It seems that there are indeedsignificant differences in the way the same firmdeploys its resources, both across projects and overtime. Holding project inputs and characteristicsconstant we found that an improvement in projectmanagement capabilities resulted in increasesin project contribution. Put simply, our resultsdemonstrate that project profitability differencescould be a function of differences in the way thesame resources are deployed by the firm. Also,we found some evidence that an improvementin the productive deployment of resources overtime yielded increases in project profitability. Thisprovides reason to take more seriously Penrose’s(1959) key insight that differential firm capabilitiesin productively deploying resources lie at the heartof firm performance differences.

Second, it appears that measuring capabilities atmore micro levels within a firm is quite promis-ing. It not only helps better estimate their eco-nomic significance but also provides clear guide-lines to the firm on where and how it needsto improve its capabilities. Measures of capabil-ities at the aggregate firm level, while useful inidentifying between-firm differences, provide lit-tle understanding of the micro-foundations of suchinter-firm differences. As our study demonstrates,measurement of firm capabilities at the micro-level holds promise of enhancing our understand-ing ‘how’ and ‘why’ some firms perform betterthan others.

Lastly, our analyses also show that the marginalreturns to different capabilities are not uniform.Given scarce managerial resources, it is useful forfirms first to identify the capabilities that providethe highest marginal returns to performance andthen direct the bulk of its resources to acquir-ing them. Building capabilities requires signifi-cant and, often, irreversible commitment of realresources, both financial and managerial. Deci-sions about which capabilities to acquire or buildrequire due diligence in the analysis of costs andbenefits. Moreover, it is likely that different firmswill face different costs and benefits of acquiringthe same capabilities given the interdependencieswith various other organizational choices (Ethi-raj and Levinthal, 2004). For instance, for a firmthat engages in relatively few repeat projects, the

marginal benefit of client-specific capabilities islikely to be significantly less than the marginalbenefit of project management capabilities (thiswould generally be the case for smaller or newerfirms who are likely to have fewer repeat clientsin their early years). The converse is likely to betrue in the case of a firm that engages in a largenumber of repeat projects. In fact, the latter set offirms could also explore the feasibility of investingin creating deliberate and institutionalized mecha-nisms to build their client-specific capabilities thanleaving it to tacit learning-by-doing. Our inter-views seem to support this contention. Finally, inour dataset, if we assume that the marginal costof acquiring different project management capa-bilities is the same, our results suggest that thefirm would be well advised to expend resourcesto improve schedule estimation and managementcapabilities so as to tightly manage schedule slip-pages. Improvements in this capability promise toyield higher marginal improvement in project con-tribution performance.

LIMITATIONS AND DIRECTIONS FORFUTURE RESEARCH

In this paper we attempted to uncover the micro-foundations of capabilities and how they affect per-formance. Our study, like any study, suffers fromsome limitations. First, it is based on a single ser-vice industry with its own peculiar characteristics.It is not clear to what extent the substantive resultsof this paper are generalizable across industries. Atthe same time, as we have asserted above, capa-bilities are usually context-specific, i.e., industry-specific, and capabilities that are generalizableacross industries are likely to be overly abstractand less useful as a guide to managerial action. Asecond limitation is that our study is based on datafrom a single firm. Ideally, we would have likedto include data from a few more firms. However,getting access to such detailed data of great com-petitive significance is a difficult challenge. In ourcase, this involved several years of data collection,ongoing negotiations with the firm concerned, andthe signing of non-disclosure agreements. Third,since our analysis is based on data from only onefirm we could not make any explicit inter-firmcomparisons of competitive advantage. However,since the firm is among the top five firms in theindustry on several dimensions such as growth



and total revenues it gives us some confidence fordrawing the capabilities–performance link.

In spite of some of the data limitations out-lined above, some of the unique aspects of ourdataset outweigh some of these disadvantages.One, the data on resource inputs (team size, experi-ence, etc.) and capabilities allow us to empiricallymeasure Penrose’s (1959) key distinction betweenavailable resources (factor inputs such as labor)and how they are deployed (i.e., productivity ofresources). Two, the data on project-level contri-bution suffer from relatively fewer problems asso-ciated with aggregate accounting data. Finally, ourdesign allowed us to combine the depth and rich-ness of longitudinal, single-firm case studies withthe rigor of large-sample empirical estimation.

In conclusion, the paper attempted to take aninitial step in teasing out the importance of capabil-ities and estimating their impact on performance.We hope that the spirit of this paper in advocatingthe importance of contextually grounded studiesof firm capabilities will spur further research alongthese lines in other industries. The shift in researchfocus from whether or not capabilities matter to‘what’ capabilities matter and ‘how’ they matterpromises to enrich our understanding of firm prof-itability differences.

ACKNOWLEDGEMENTS

We thank Rich Makadok, Phanish Puranam, andan anonymous referee for helpful comments onan earlier version of this paper. Errors and omis-sions remain our responsibility. Research fundingfor this project from the Mack Center for Tech-nological Innovation at the Wharton School andthe William Davidson Institute and Mike and MaryKay Hallman Fellowship at the Michigan BusinessSchool is gratefully acknowledged.

REFERENCES

Albrecht AJ, Gaffney JE. 1983. Software function, sourcelines of code, and development effort prediction: asoftware science validation. IEEE Transactions onSoftware Engineering SE-9(6): 639–648.

Amit R, Schoemaker PJH. 1993. Strategic assets andorganizational rent. Strategic Management Journal14(1): 33–46.

Anand BN, Khanna T. 2000. Do firms learn to createvalue? The case of alliances. Strategic ManagementJournal 21(3): 295–315.

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. ResearchPolicy 30(8): 1267–1287.

Banerjee AV, Duflo E. 2000. Reputation effects and thelimits of contracting: a study of the Indian softwareindustry. Quarterly Journal of Economics 115(3):989–1017.

Barney J. 1991. Firm resources and sustained competitiveadvantage. Journal of Management 17(1): 99–120.

Brush TH, Artz KW. 1999. Toward a contingentresource-based theory: the impact of informationasymmetry on the value of capabilities in veterinarymedicine. Strategic Management Journal 20(3):223–250.

Chatterjee S, Hadi AS, Price B. 2000. RegressionAnalysis by Example (3rd edn). Wiley: 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 sourceof profit. In Organizational Learning and CompetitiveAdvantage, Moingeon B, Edmondson A (eds). Sage:London; 139–163.

Dierickx I, Cool K. 1989. Asset stock accumulation andsustainability of competitive advantage. ManagementScience 35(12): 1504–1512.

Dosi G, Nelson RR, Winter SG. 2000. Introduction.In The Nature and Dynamics of OrganizationalCapabilities , Dosi G, Nelson RR, Winter SG (eds).Oxford University Press: New York; 1–22.

Ethiraj S, Levinthal DA. 2004. Modularity and innova-tion in complex systems. Management Science 50(2):159–173.

Gopal A, Sivaramakrishnan K, Krishnan MS, Mukhopad-hyay T. 2003. Determinants of contract choice inoffshore software development. Management Science49(12): 1671–1683.

Grant RM. 1991. The resource-based theory of competi-tive advantage: implications for strategy formulation.California Management Review 33(3): 114–135.

Greene WH. 1997. Econometric Analysis (3rd edn).Prentice-Hall: Upper Saddle River, NJ.

Helfat CE. 1994. Evolutionary trajectories in petroleumfirm R&D. Management Science 40(12): 1720–1747.

Henderson RM, Cockburn I. 1994. Measuring com-petence? Exploring firm effects in pharmaceuticalresearch. Strategic Management Journal , Winter Spe-cial Issue 15: 63–84.

Herbsleb J, Zubrow D, Goldenson D, Hayes W, Paulk M.1997. Software quality and the capability maturitymodel. Communications of the ACM 40(6): 30–40.

Humphrey WS. 1989. Managing the Software Process .Addison-Wesley: Cambridge, MA.

Iansiti M, Khanna T. 1995. Technological evolution,system architecture and the obsolescence of firmcapabilities. Industrial and Corporate Change 4(2):333–361.

Jalote P. 1997. An Integrated Approach to SoftwareEngineering . Springer-Verlag: New York.



Jones C. 1997. Software Quality: Analysis and Guidelinesfor Success . International Thomson Computer Press:Boston, MA.

Kale P, Dyer JH, Singh H. 2002. Alliance capability,stock market returns and long-term alliance function:the role of the alliance function. Strategic ManagementJournal 23(8): 747–767.

Klein B, Crawford RG, Alchian AA. 1978. Verticalintegration, appropriable rents, and the competitivecontracting process. Journal of Law and Economics21(2): 297–326.

Krishnan MS. 1996. Cost and quality considerationsin software product management. Doctoral disserta-tion, Graduate School of Industrial Administration,Carnegie Mellon University, Pittsburgh, PA.

Langlois RN. 1992. Transaction cost economics in realtime. Industrial and Corporate Change 1(1): 99–127.

Levinthal DA. 1997. Adaptation on rugged landscapes.Management Science 43(7): 934–950.

Makadok R. 2001. Toward a synthesis of the resource-based and dynamic-capability views of rent creation.Strategic Management Journal 22(5): 387–401.

Makadok R, Walker G. 2000. Identifying a distinctivecompetence: forecasting ability in the moneyfund industry. Strategic Management Journal 21(8):853–864.

Market-Guide. 2002. Software and programming compa-nies list. http://biz.yahoo.com/p/softwrttmd.html.

McGrath RG, MacMillan IC, Venkataraman S. 1995.Defining and developing a competence: a strategicprocess paradigm. Strategic Management Journal16(4): 251–275.

Nasscom. 2001. The Indian Software Industry Report .Nasscom: New Delhi.

Nelson RR. 1991. Why do firms differ, and how doesit matter? Strategic Management Journal , WinterSpecial Issue 12: 61–74.

Nelson RR, Winter S. 1982. An Evolutionary Theory ofEconomic Change. Belknap Press: Cambridge, MA.

Paulk MC, Curtis B, Chrissin MB, Weber CV. 1993.Capability Maturity Model, Version 1.1. IEEESoftware 10(4): 18–27.

Penrose ET. 1959. The Theory of the Growth of the Firm .Wiley: New York.

Peteraf MA. 1993. The cornerstones of competitiveadvantage: a resource-based view. Strategic Manage-ment Journal 14(3): 179–191.

Porter ME. 1991. Towards a dynamic theory of strategy.Strategic Management Journal , Winter Special Issue12: 95–117.

Rosenbloom RS. 2000. Leadership, capabilities, andtechnological change: the transformation of NCRin the electronic era. Strategic Management Journal21(10–11): 1083–1103.

Rumelt RP. 1984. Toward a strategic theory of thefirm. In Competitive Strategic Management , Lamb RB(ed.). Prentice-Hall: Englewood Cliffs, NJ; 556–570.

Rumelt RP. 1987. Theory, strategy, and entrepreneurship.In The Competitive Challenge, Teece D (ed.).Ballinger: Cambridge, MA; 137–158.

Schroeder RG, Bates KA, Junttila MA. 2002. A resource-based view of manufacturing strategy and therelationship to manufacturing performance. StrategicManagement Journal 23(2): 105–117.

Selznick P. 1957. Leadership in Administration: ASociological Interpretation . Harper & Row: NewYork.

Silverman BS. 1999. Technological resources andthe direction of corporate diversification: towardan integration of the resource-based view andtransaction cost economics. Management Science45(8): 1109–1124.

Wernerfelt B. 1984. The resource-based view of the firm.Strategic Management Journal 5(2): 171–180.

Whang S. 1995. Market provision of custom software:learning effects and low balling. Management Science41(8): 1343–1352.

Winter S. 1990. Survival, selection, and inheritance inevolutionary theories of organization. In Organi-zational Evolution: New Directions , Singh JV (ed).Sage: New York; 269–297.

Winter SG. 1995. The four Rs of profitability: rents,resources, routines, and replication. In Resource-Basedand Evolutionary Theories of the Firm: Towards aSynthesis , Montgomery CA (ed). Kluwer Academic:Boston, MA; 147–178.

Wooldridge JM. 2002. Econometric Analysis of PanelData . MIT Press: Cambridge, MA.

Zollo M, Winter S. 2002. Deliberate learning andthe evolution of dynamic capabilities. OrganizationScience 13(3): 339–351.


WHERE DO CAPABILITIES COME FROM AND HOW DO THEY MATTER? A STUDY IN

Documents

Transcript of WHERE DO CAPABILITIES COME FROM AND HOW DO THEY MATTER? A STUDY IN