where do capabilities come from and how do they matter

8/14/2019 Where Do Capabilities Come From and How Do They Matter

1/21

Strategic Management JournalStrat. Mgmt. J., 26: 2545 (2005)

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

WHERE DO CAPABILITIES COME FROM AND HOW

DO THEY MATTER? A STUDY IN THE SOFTWARE

SERVICES INDUSTRY

SENDIL K. ETHIRAJ,1 PRASHANT KALE,1* M. S. KRISHNAN1 andJITENDRA V. SINGH21 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 present

paper 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 a

given 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 firms 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 for

future 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 on

the 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 resources

or capabilities that yield competitive advantage

(Barney, 1991) and what prevents their imitation

(Dierickx and Cool, 1989; Peteraf, 1993), we have

limited understanding of where capabilities come

from or what kinds of investment in money, time,

and managerial effort is required in building them.

Copyright 2004 John Wiley & Sons, Ltd. Received 10 December 2002

Final revision received 4 June 2004


2/21

26 S. K. Ethiraj et al.

Furthermore, if the development of capabilitiesrequires deliberate and sustained investment of

financial 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 industrys 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 revenues

in 200001 (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 setoffirms growing at a compounded average annualrate of about 4565 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 clients 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 it

amounts 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-specifi

c and fruitful researchin this area might emanate from enjoining anin-depth study of the capabilities specific t o 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: 2545 (2005)


3/21

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 benefits

associated 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 andhow.

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 and

develop 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 they

important?

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 capabilityto 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 thatresources consist . . . of know-how that can betraded, financial or physical assets, human capitaletc. . . . [whereas] capabilities . . . refer to a firmscapacity to deploy resources (Amit and Schoe-maker, 1993: 35). In this paper, we adopt the latterconceptualization offirm 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 curve

for 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 assets 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 that

are 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 rentsentrepreneurial rents or rents from innovationand monopolyrentsrents from output restriction under inelastic demand.Since neither of these rents is associated with resources orcapabilities we do not discuss them here.



4/21


come from. Nelson and Winter (1982) made oneof the early theoretical attempts to understand

this question. They viewed the firm as bundlesof path-dependent knowledge bases. Over time,firms knowledge, accumulated through learningby doing, is embedded in bundles of routinesthat 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 of

endogenous, 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, and

the 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 and

making 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 offirms and

the 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 offirm-specific investmentssuggest that firms face significant ex ante trade-offs in their choices of firm-specific investments

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



5/21


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 costbenefit 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 on

thefi

rm 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 spirit

of 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 address

this 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



6/21


we examine the choices made by a single firm overtime and evaluate the performance trade-offs or

the 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 focus

on 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 industryssales (Nasscom, 2001). The Indian industry re-ceived a big boost in the early 1990s when

the 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 software

services 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



7/21


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 clients 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, the

nature 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 clients 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 not

only supports the argument that Indian softwareteams are capable of executing these high-valueprojects but also erodes much of the Indian firmstraditional 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 the

services. We elaborate below.Indian software firms have traditionally executed

two 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 that

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



8/21


time & material (T&M) contract, the vendor pro-vides services at a pre-negotiated rate for every

person-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 Indianvendors 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 a

critical 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 firms 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 develop

better clarity of how the software relates to theclients 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 created

problems 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 firms 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 firms understanding of the clientsbusiness domain. Thus, repeat projects for clientshelped develop important client-specific capabili-ties that contributed to higher profits by reducing



9/21


costs. Therefore, we hypothesize:

Hypothesis 1: Development of client-specificcapabilities based on repeated interaction with

clients 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 the

requirements 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 have

a 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 whether

they 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 anorganizations 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.



10/21


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 guidelines

for 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 of

project 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 of

firm 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 help

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



11/21


35 repeat clients for whom the first project wasexecuted prior to the study period. The average

number 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 thefi

rms operations andits costs depend almost exclusively on manpower.The firms 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 Care the costs respectively of project i for client jin 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, andijt 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-panel

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



12/21


focus on the project level because the firm capa-bilities that we study primarily exist and evolve

at 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 andINRUSD (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. These

repeated interactions may be a function of time(on a long project) or spread over several projects.We measured it in two ways. For each project 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 capabilities

developed 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 rupeedollar 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 clientfixed 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 firms software development and management

capabilities. Further, there is evidence that the costof fixing defects in the early phases of softwaredevelopment can be substantially lower than thecost offixing 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 up

as effort increases. This measure refl

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



13/21


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 of

contracts. 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-offfixedprice 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

sizeprofitability relationship might be increasingbelow the minimum efficient scale and decreasing

above 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 and

decrease 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 studied

executed projects for clients in multiple industries.Since competition and appropriability conditionscan vary by industry and the vendors 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.



14/21


domains, we include industry dummies to con-trol for industry-specific differences. We included

three 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 Windows

NT, 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 important

to 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 model

by 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 personmonthsvariable 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 offirst-time projects after controlling for projectcharacteristics. Revenues tended to remain constant after adjust-ing for inflation and exchange rate changes.



15/21


Table1.

Descriptivestatisticsandcor

relationmatrixofvariables(N=

138)

Variables

Mean

S.D.

1

2

3

4

5

6

7

8

9

10

11

12

Log(Contribution)

4.875

1.314

Log(Size)

6.458

1.491

0.489

Log(Teamsize)

2.117

0.668

0.609

0.679

Log(Person-months)

3.077

1.041

0.675

0.670

0.741

Log(Duration)

4.884

0.601

0.459

0.536

0.470

0.639

Customertype

0.159

0.367

0.100

0.169

0.177

0.235

0.195

Processdefects

0.630

1.9800.3190.638

0.3020.4110.2760.117

Scheduleslippage

0.018

0.0930.138

0.026

0.034

0.052

0.045

0.087

0.0

28

Effortoverrun

0.050

1.1740.077

0.037

0.033

0.043

0.002

0.148

0.0060.142

Contracttype

0.609

0.4900.254

0.080

0.117

0.059

0.038

0.023

0.1150.102

0.138

Year

1999.0

50

1.479

0.120

0.081

0.013

0.156

0.2490.375

0.1130.140

0.043

0.085

EffortoverrunY2001

0.089

0.009

0.056

0.081

0.031

0.028

0.0

070.1

95

0.544

0.0830.026

ScheduleslippageY1996

0.027

0.044

0.006

0.077

0.031

0.136

0.034

0.353

0.052

0.0800.235

0.006

Asterisksindicatecoefficientssignificantat

0.05levelorlower.



16/21


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 cost

during execution than if they were to befi

xedafter 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



17/21


related to project contribution, especially withrepeat projects. However, the need to fix defects

during 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 clients 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. We

further 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 that

the extent of effort overrun on projects is declin-ing over the 19962001 period and this declineis positively related to project performance. Con-trary to expectation, we found that schedule slip-page increased marginally during the 19962001period, 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 offixed 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 projects. 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 the19962001 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. Our

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



18/21


an increase in e-commerce-related projects in thepost-1996 period. The e-commerce clients, in their

effort 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 capabilities

and 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, in

models 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 in

future 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. It

seems 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 than

facing 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 19962000. 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 offi

rm 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,)/Xii 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.



19/21


grounded. Each industry is driven by its owndemand- and supply-side economics, which also

changes 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 Penroses(1959) key insight that differential firm capabilitiesin productively deploying resources lie at the heartoffirm 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 provide

the 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 marginal

benefit 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 cost

of 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

where do capabilities come from and how do they matter

Documents