Why good project management is not enough
liabilities of incumbency and newness
NICTA and University of New South Wales, Sydney, Australia
A common view is that good project management is necessary but not enough to ensure project success. This begs the question: Why not? This paper examines current factor-, process-, and capability-based explanations of project performance and finds gaps in their explanatory power. An alternative explanation is developed from organizational learning and capability theory that integrates drivers for project success and drivers for project failure in one model. Project performance is modeled as the contested outcome of the two opposing drivers, enabling unpredictable variations in project outcomes. A key contribution of the model is the inclusion of drivers of underperformance and failure. These comprise common learning barrier conditions that can reduce or negate the performance value of organizational capabilities applied to projects. Two types of conditions are described: liabilities of incumbency and liabilities of newness. Together, these negative drivers can offset or overwhelm the positive effects of organizational learning on capability accumulation, creating a net performance liability, leading to underperformance or failure—even in well-managed projects. The performance model is illustrated using a longitudinal case study. The model improves our understanding of project performance as well as our ability to explain industry data on project outcomes and anomalous inconsistencies in performance in successive projects. Implications of the model are discussed, including how it might be used in practice. The paper argues from an information systems project perspective, but the model also has relevance to other application domains.
Keywords: Project performance, capability, competency, liability of newness, incumbency, risk
It has long been recognized that good project management is not enough to ensure project success. For example, de Wit argued “good project management can contribute towards project success but is unlikely to be able to prevent project failure” (de Wit, 1988, p. 165). Similarly, a recent study of information systems (IS) executive perceptions found no significant difference in the project success experience of PMP® credential holders and uncertified project managers (Starkweather & Stevenson, 2011). This suggests that, at least for IS projects, good project management is a necessary but not sufficient condition for project success. Apart from the unfortunate imputation of this conclusion on the value of management, this leaves the question: What else can account for project success that is beyond the capabilities of project management?
The usual answer to this question in the literature is some function of the argument that projects are one-off, complex, high-risk, multidimensional socio-technical endeavors. In the case of IS projects, reference is also often made to the pervasive, cross-functional impact of information systems technology on most aspects of organizations. Underpinning these answers is the assumption that there is significant scope in projects for other, often unknown, factors than project management to negatively impact performance. However, while for many projects these descriptions might be true, they provide few clues to the underlying mechanisms that can result in variable project performance. Neither do they suggest how to manage the problem. The aim of this paper is to develop a capabilities-based explanation of project performance that can explain the dilemma of the insufficiency of project management to determine project outcomes as well as other anomalies that are found in practice such as high variability in project performance within a single organization from one project to the next. The paper focuses on the IS project domain but the fundamentals of the explanation are not IS-specific, so the mechanisms are also relevant to projects in other application domains (but generalization of the performance model is not addressed here).
Past approaches to answering the larger question of what determines project performance—particularly in software-related projects—have tended to take the functional form of a continuous effect and assume that project success is the expected or normal outcome of a project. Take, for example, the two most common explanations for project performance found in the literature: factor- and process-based approaches (Sauer, 1999). Factor-based approaches seek to identify antecedent variables (factors) that influence project performance. Essentially, they argued that project performance is determined by taking account of recognized critical success factors, and/or avoiding failure factors and managing risk factors. Lists of such factors are commonly known, for example: executive commitment; business/user involvement; clear objectives; stable requirements; minimized scope; project management expertise; change management; and suitable methodology and tools. Fundamentally, this approach argues that if you do the right things in terms of managing identified performance factors, the project will succeed. Furthermore, the more things that are done right, the greater the likelihood of success. That is, it argues that there is a continuous positive main effect of antecedent factors on project outcomes.
Similarly, process-based approaches examine the interactions between stakeholders and events to identify the specific nature of the relationships between factors and outcomes. In essence, they argue that project performance is determined by following best practice processes, methodologies, and techniques in each project situation. Fundamentally, they argued that if you do things in the right ways by following prescribed project processes, the project will succeed. Furthermore, the closer the fit between process and project requirement, the greater is the likelihood of success (again, the functional form of a continuous positive main effect).
Together, the factor and process approaches represent good project management. They are also popular because they have a strong practical appeal, providing specific guidance on what to do in practice to achieve project success. These approaches have dominated the field of project management throughout most of its history and have contributed significantly to the current state of the art and science of project management. However, a key problem with both of these explanations is that they contain no explicit drivers for underperformance. They assume that if you do the right things in the right ways then the project will succeed. Underperformance arises if insufficient attention is given to taking account of the key factors and applying suitable processes. In effect, underperformance or failure is the inverse of success. That is, it is not doing what is necessary (or enough of what is necessary) to succeed. If this occurs, and something is missed in one project, then stakeholders can learn from the experience and do better the next time around. By contrast, the alternative explanation developed in this paper takes the view that underperformance or failure is not just the inverse of success. Neither is it just a matter of learning from experience and doing things better next time. Rather, there are fundamental issues with the learning process that can introduce explicit drivers for failure that are independent of the drivers for success. These drivers make it possible for a project to underperform or fail despite good project management.
As implied previously, another key problem with the current dominant approaches is that they appear to be insufficient to guarantee project success. This dilemma is graphically illustrated in Figure 1. The figure plots survey data from The Standish Group on IS projects that succeeded outright against schedule, budget, and planned features; failed and were terminated before intended completion; and underperformed against schedule, budget, and/or features delivered (i.e., were “challenged”). The graph combines the data for failed and challenged projects and compares it to projects that succeeded outright.
Figure 1: IT Project Performance (data source: The Standish Group, Inc.).
Three points are noteworthy about Figure 1. First, the scientific validity of the survey results on which the graph is based, particularly for the first two surveys, has been challenged in the research literature by claims that it overstates the problem (see, for example, Jørgensen & Moløkken-Østvold, 2006; Eveleens & Verhoef, 2010). Overall, however, the data reported appear to accord anecdotally with the views held by many executives and managers that IS projects are high-risk ventures. Furthermore, a more recent study suggests that “tech” projects have an even worse performance record than that reflected in the graph (Flyvbjerg & Budzier, 2011). Second, ignoring the first two years (in recognition of the literature-based challenge), a visualized trend line suggests a steady improvement in project performance over the period of the surveys. Failed and challenged projects have gradually declined, commensurate with an increase in projects that have succeeded outright. This implies that good project management, as it exists today, may be having a positive effect on project outcomes. Third, the bad news is that there is still a substantial gap between the two trend lines, and intersection seems to be a long way off. Even worse, these data indicate that project underperformance or failure is a more likely outcome than outright project success. That is, IS projects are more likely to fail or underperform than succeed. This is contrary to the assumption of the factor and process approaches to project performance, which assume that success is the normal or expected outcome of an IS project. In sum, despite the apparent improvement trend, this evidence supports the views expressed above that good project management is insufficient to determine successful project outcomes.
Before proceeding, one other explanation of the problem of project performance that is starting to emerge is to attribute outcome variance to black swans (see, for example, Flyvbjerg & Budzier, 2011). Proposed by Taleb (2010), a black swan is an improbable, unexpected event that has massive consequences, either positive or negative. The notion evolved from Taleb's earlier work on luck and randomness, and the human tendency to expect that if 1,000 white swans were seen to fly by, the next swan would also be white (Taleb, 2008). Black swans disrupt our expectations. However, after the event, they can be rationalized in a way that could have made them expected. Applied to IT projects, it is argued that black swans can account for the unexpected disruptions that arise causing a $US5 million project that is believed, ex ante, to be low risk, to blow out to a $US200 million loss (Flyvbjerg & Budzier, 2011). In hindsight, many of the red flags should have been evident.
In the explanation developed in the next section, disruption is also an important element in the model but it arises through a much more concrete mechanism than randomness. The approach draws on literature-based evidence that learning from experience (“learning by doing”) is not a simple continuous process that continually accumulates the organizational capabilities needed to deliver projects successfully, time after time. Rather, discontinuities and other barrier conditions can arise that reduce, block, or negate learning from experience, reducing the capabilities available to the organization to apply to projects. These disruptions can constantly refresh a liability in projects to underperform or fail.
Capability-related research in project management is not new. Substantial prior work has been done on identifying individual capabilities that are important in achieving project success (e.g., Crawford, 2000; Crawford & Nahmias, 2010; Edum-Foywe & McCaffer, 2000; Ingason & Jónasson, 2009; Partington, Pellegrinelli, & Young, 2005; Shi & Chen, 2006; Skulmoski & Hartman, 2010); as well as project team and organizational capabilities (e.g., Bredin, 2008; Crawford, 2006; Melkonian & Picq, 2010; Rose, Pedersen, Hosbond, & Kraemmergaard, 2007; Vaagaasar, 2008); the link between project management capabilities and project/organizational performance (e.g., Geoghegan & Dulewicz, 2008; Haggerty, 2000; Jugdev, Mathur, & Fung, 2007; Lampel, 2001); and project capability building mechanisms and related structural forms (e.g., Ayas & Zeniuk, 2001; Brady & Davies, 2004; Davies & Brady, 2000; Keegan & Turner, 2001; Prencipe & Tell, 2001; Söderlund, 2008; Söderlund, Vaagaasar, & Andeersen, 2008; Söderlund & Tell, 2009). Arguably, capability-related approaches comprise the third, next most dominant explanation of project performance found in the literature after factors and processes.1
This prior research is distinguished from the current paper in two main ways. First, research on specific individual/team/organizational capabilities fits within the existing factor-based explanation paradigm. It focuses on identifying capability factors that influence project outcomes. Second, the prior research focuses on the causal link between capabilities and project performance, and the generative mechanisms whereby capabilities are built. That is, it also assumes a continuous positive main effect between capability factors and project success as the normal project outcome. Typically, it has not directly focused on degenerative mechanisms that can reduce or negate capabilities or account for failure outcomes.
The paper is conceptual. The research method used is theory development from organizational theory and the phenomenon of project underperformance, despite apparent good project management in practice. The unit of analysis is the organization and the capabilities it has to apply to the projects it undertakes. The proposed model draws from capability-based theory, organizational learning theory, and concepts from the organizational ecology literature. The distinctive contribution is an alternative capability-based project performance model that can explain how the circumstances reflected in Figure 1 might be possible. The theory is illustrated by application to a qualitative longitudinal case study, providing initial validation. In applying the theory to practice, the paper also discusses how the problem might be managed to improve project outcomes.
Three related bodies of organization literature contribute to the proposed model of project performance. The first, ‘capability-based theory' (which derives from “resource-based theory”), provides an alternative basis for determining project performance. The second, “organizational learning theory,” describes the primary generative mechanism through which capabilities are developed and accumulated. These two bodies of theory are well established in the literature. The third body does not exist as an integrated theory in the literature. Rather, it comprises various barrier conditions from the learning, innovation, and organizational ecology literature that can reduce, block, or negate the generative effects of learning on capabilities. A key contribution of the paper is to bring these disparate conditions together as common drivers of project underperformance or failure under the labels of “liabilities of incumbency” and “liabilities of newness.”
First, according to resource-based theory (Barney & Clark, 2007; Barney, 2011), firm performance is a function of internal resources, which are heterogeneously distributed across firms. Firm idiosyncrasies in accumulating and using differentiated resources drive superior firm performance and competitive advantage. Economic rent-generating firm-specific resources are variously characterized as valuable, rare, non-tradable, inimitable, non-substitutable, causally ambiguous, socially complex, and having high organizational support (Barney & Clark, 2007; Dierickx & Cool, 1989). “Capability-based theory” extends this view by emphasizing building and accumulating a subset of resources (capabilities), better and faster than competitors (Prahalad & Hamel, 1990). Capabilities are organizational resources that have potential to generate value for a firm. They comprise an intricate mix of knowledge, skills, routines, technologies, and values. A firm's effectiveness in developing and deploying capabilities, including those needed to execute projects, determines its performance outcomes. Indeed, the ability to build and leverage new capabilities is a capability in itself, called a ‘dynamic capability' (Teece, Pisano, & Shuen, 1997; Helfat et al., 2007).
“Organizational learning” is the main generative mechanism of firm-specific capabilities. Capabilities are primarily developed through learning from experience or “learning by doing” (Levitt & March, 1988). They are a “messy accumulation of learning” (Hamel, 1994). Organizational capabilities are developed and institutionalized in the operating routines, practices, and values of the firm in a way that outlives the presence of specific individuals, and are adapted over time in response to further experiential learning (Nelson & Winter, 1982). Organizations can also deliberately build capabilities through management practices (Hamel, 1994; Montealegre, 2002; Purcell & Gregory, 2000). The firm is a learning organization that builds and deploys advantageous, firm-specific capabilities and applies them to achieve superior levels of performance (Hamel, 1994). Learning takes two primary forms (Argyris & Schön, 1978). One is continuous with respect to existing organizational capabilities (termed “single-loop learning”), resulting in improvements to those capabilities. The other is discontinuous (called “double-loop learning”), resulting in fundamentally different organizational rules, values, norms, structures and routines (that is, in new capabilities). Continuous single-loop learning is particularly relevant in routine exploitation of existing capabilities, while discontinuous double-loop learning has particular application in exploration of new possibilities (March, 1991).
In contrast to these learning effects on capabilities, the literature also variously describes a range of barrier conditions that can reduce or block learning and capability accumulation or make existing capabilities obsolete in the face of new or changed circumstances. These regressive conditions can offset or negate the generative effects of learning on organizational capabilities, reducing or destroying an organization's ability to perform well. These conditions are not coherently integrated in the literature. They are brought together here under two unifying concepts adapted from the literature (“liabilities of incumbency” and “liabilities of newness”).
Liabilities of incumbency (termed ‘liabilities of age and tradition' by Tushman & Anderson, 1986) are barrier conditions that slow or block the incremental accumulation of capabilities (see examples in Table 1). These conditions are often associated with the entrenched practices of established firms (hence, they are a liability of holding an existing position in industry). Their effect is continuous, permitting various levels of flow like a water tap whose valve is progressively closed to restrict or fully interrupt the flow.
By contrast, liabilities of newness (a term introduced by Stinchcombe, 1965 and Hannan & Freeman, 1984) are barrier conditions that, in the face of newness and/or changed circumstances, make existing capabilities redundant or obsolete, reverting the capability status of the organization to that of a new start-up, creating a high propensity to underperform or fail (see examples in Table 2). Their effect is discontinuous, requiring different capabilities to those needed previously. Together, these conditions have the effect of reducing or negating the level and value of accumulated learning and capabilities to that of a less competent organization, refreshing its propensity to underperform or fail (Amburgey, Kelly, & Barnett, 1993). They turn an organization's “liability clock” back toward zero (Hannan & Freeman, 1984).
Taken together, the learning and barrier effects of these generative and degenerative mechanisms variously act as drivers impacting the capabilities available to an organization to apply to its projects, as summarized in Figure 2.
Figure 2: Capability Drivers.
IS projects can be foci of competence-destroying barrier conditions that can make established capabilities redundant “overnight,” or by the time the next project arises. Platforms, development tools, software versions and domain knowledge requirements change, as do the business and organizational contexts, motivations, drivers, stakeholders and team membership, both during and between projects (especially large projects), potentially impacting existing capabilities. Indeed, change and newness are inherent in the definition of a project as a temporary endeavor undertaken to create a unique product, service, or result as indicated in A Guide to the Project Management Body of Knowledge (PMBOK® Guide)(Project Management Institute). Projects focused on doing the right things in the right ways can easily be blind-sided by taken-for-granted entrenched attitudes, structures, and practices of established firms and unanticipated changed circumstances that fundamentally impact the capabilities needed to succeed in the project. Related barrier conditions can re-set or turn back an organization's ‘capability clock,' reducing and/or negating the value of its accumulated learning and giving it the performance vulnerability of a new or immature organization again.
|Time compression diseconomies||Limits capability stock accumulation due to long development lead-time, and absence of shortcuts.||Dierickx & Cool (1989); Knott, Bryce, & Posen (2003)|
|Asset mass inefficiencies||Low pre-existing levels of a capability make it difficult to develop and accumulate needed capabilities.||Dierickx & Cool (1989)|
|Absorptive capacity||An organization's ability to learn and innovate is a function of the level of its prior related knowledge.||Cohen & Levinthal (1990, 1994; Zahra & George (2002)|
|Transformative capacity||An organization's ability to exploit and transfer technological knowledge across time can inhibit (or facilitate) learning.||Garud & Nayyar (1994)|
|Information processing limitations||An organization's processing capacity is bounded; this and information overload inhibit new learning and development.||March & Simon (1993); Tushman & Nadler (1978); Lyytinen & Robey (1999)|
|Training and education||A lack of appropriate technical and business training/ education can limit learning and capability development.||Lyytinen & Robey (1999)|
|Learning disincentives||Lack of proper incentives inhibits learning; this can occur in a culture obsessed with success (ignores failures).||Lyytinen & Robey (1999)|
|Certain organizational designs||Organization structures, processes, and practices can create artificial boundaries that limit learning, knowledge sharing and development (especially with respect to the positioning of the Information Technology function).||Ayas (1996, 1999); Nadler & Tushman (1997); Lyytinen & Robey (1999); Schulz (2001); Mohrman, Finegold, & Klein, (2002)|
|Low aspiration levels||If aspiration level is low, learning of capabilities tends to end too soon, resulting in an inferior achievement.||Winter (2000)|
|Tacitness||A source of great value in capabilities, but the difficulty in articulating what we know limits knowledge sharing/transfer and, therefore, learning from others.||Polanyi (1966); Attewell (1992); Nonaka & Takeuchi (1995)|
|Organizational inertia||Deeply established practices (especially successful ones) resist change (especially in stable environments).||Hannan & Freeman (1984)|
|Competency traps||Learning from past successes (existing capabilities) is favored, inhibiting potentially relevant new learning.||Levitt & March (1988); Levinthal & March (1993)|
|Need for unlearning||Past learning may need to be unlearnt to enable new learning and competence development to take place.||Nystrom & Starbuck (1984); Durand (2000)|
|Interconnectedness||Extending a capability may depend on the presence of others.||Dierickx & Cool (1989)|
|Causal ambiguity||A source of great value in capabilities, but lack of detailed understanding of the makeup of capabilities can make it difficult to develop and maintain them.||Lippman & Rumelt (1982); Dierickx & Cool (1989); Reed & DeFillippi (1990)|
|Learning myopia||Organizations simplify and specialize their learning; they tend to overlook the long run, the larger picture, and failures, favoring exploitation over exploration.||Abdel-Hamid & Madnick (1990); March (1991); Levinthal & March (1993)|
|Focus diversion||New learning can reduce maintenance of existing capabilities||March (1991)|
|Core rigidities||Core capabilities retained and applied inappropriately become core rigidities and inhibit new learning.||Leonard-Barton (1992, 1995)|
|Complexity and embeddedness||Effective capabilities are socially complex and deeply embedded in the organization, which can also make it difficult to maintain and exploit them.||Kogut & Zander (1992); Hansen (1999); Garud (1997); Brown & Duguid (1998)|
|Stickiness||Knowledge is so deeply embedded in situational contexts that it cannot easily be fully explicated or transferred.||von Hippel (1994); Szulanski (1995, 1996, 1997, 2003)|
|Unjustified theories-in-use||Defensive routines prevent or greatly reduce learning when it is most needed (when failure occurs).||Argyris (1977, 1991); Lyytinen & Robey (1999)|
|Managerial cognition||Strong managerial beliefs influence new learning search processes and the development of new capabilities.||Tripsas & Gavetti (2000)|
|Certain project characteristics||Duration of a project is too short for effective capability development; projects provide a poor framework for capability development; projects are usually resourced by diverse temporary personnel (including contractors).||Leonard-Barton (1992); DeFillippi & Arthur (1998); Pettigrew (1998); Lampel (2001)|
|Recognition and progression||Lack of recognition and limits on skill growth due to progression pathways can stifle learning and development.||Leonard-Barton (1992)|
|System rigidities||Over-reliance on ISs and/or inflexible systems can inhibit organizational learning and development.||Orlikowski (1993); Gill (1995); Robey, Boudreau, & Rose (2000)|
Table 1: Liabilities of Incumbency that Reduce and/or Block Learning.
|Newness||Young or significantly changed organizations (or organizational circumstances) may have insufficient competence stocks to survive or succeed.||Stinchcombe (1965); Hannan & Freeman (1984)|
|Technological discontinuities||Major technological shifts can destroy (or enhance) existing capabilities and lead to organization failure.||Tushman & Anderson (1986); Christensen (2000)|
|Architectural Innovations||Changes in the architecture of a product (without changing its components) destroy the usefulness of embedded architectural knowledge.||Henderson & Clark (1990)|
|Radical methods||Management methods such as radical business process reengineering destroy the value of existing capabilities vested in the status quo.||Hammer (1990); Galliers (1997)|
|Technological change||Technologies are developing faster than the capabilities to effectively use them.||Leonard-Barton (1992)|
|Organizational forgetting||Unintentional loss of valuable embedded capabilities through ‘memory decay.'||De Holan, Phillips, & Lawrence (2004)|
|Asset erosion||Capability stocks may be subject to ‘ossification', decay and/or may become redundant over time.||Dierickx & Cool (1989); Knott et al. 2003)|
|Staff loss through turnover, downsizing and/or outsourcing||High staff turnover, downsizing, and outsourcing drain accumulated experience/competence and increase development time and cost.||Simon (1991); Lyytinen & Robey (1999); Fisher & White (2000); Quinn & Hilmer (1994)|
Table 2: Liabilities of Newness that Negate Existing Capabilities.
Capability-based Model of Project Performance
Based on the above theory, an alternative explanation for project performance is inherent in the generative and degenerative mechanisms underlying organizational capabilities, a subset of which is applied to projects. In Figure 3, the capability drivers from Figure 2 are shown as they impact organizational capabilities. While progressive continuous and discontinuous learning can accumulate organizational capabilities, liability of incumbency barrier conditions can retard or block capability development and liability of newness conditions can render existing capability stocks redundant. Liabilities can expose the organization to the vulnerabilities of a start-up and, thereby, subject it to higher risks of underperformance or failure than it would otherwise have. Fundamentally, learning drives project performance and ‘success' through capability accumulation, and liabilities of incumbency and newness drive project underperformance and ‘failure' through capability reduction and negation. As summarized in Figure 4, project performance is the contested outcome of these joint effects, which are difficult to predict, resulting in performance variations such as those shown in Figure 1.
Figure 3: Performance Model.
Figure 4: Performance Model.
In the proposed model in Figure 4, ‘Learning' is the process of developing capabilities through experience. ‘Liability of incumbency' is the creation of a propensity to underperform or fail through the effects of barrier conditions that deplete organizational capabilities. ‘Liability of newness' is the creation of a propensity to underperform or fail through the effects of conditions that negate existing organizational capabilities. ‘Capability' is the differentiated resources that generate operational and strategic value for an organization. Finally, ‘Performance' is the extent to which the outcome of an organizational activity (such as an IS project) meets stakeholder expectations.
The relationships between organizational capabilities and performance are accepted, a priori, as hypothesized in the literature. Consistent with conventional thinking, strong performance is associated with project ‘success,' whereas poor performance is associated with project ‘failure.'2
More formally, the performance model is defined in the following propositions. First, the relationship between learning and capability is also accepted, a priori, as hypothesized in the literature and discussed previously. Learning from experience is the generative mechanism by which capabilities are developed, institutionalized and embedded in the activities of the organization (Levitt & March, 1988; March, 1991). Here, this relationship is re-stated as a proposition for completeness:
Proposition 1: Learning develops existing and new organizational capabilities.
Figures 3 and 4 include two variables that are negatively associated with capability. The first, liabilities of incumbency, represents barrier conditions that deplete existing capabilities by reducing or blocking the learning improvement effect on the capabilities. The second (and, arguably, more powerful), liabilities of newness, represents barrier conditions that make existing capabilities obsolete or redundant in the face of new requirements. The first effect is continuous, interrupting or slowing the incremental accumulation of capabilities. Using Dierickx and Cool's (1989) stocks and flows analogy, this is equivalent to the flow. Liabilities of incumbency can turn the tap partially or completely off, reducing or stopping the flow of capability asset stocks into the organizational “tank.” By contrast, the second effect is discontinuous, making existing capability stocks in the organizational ‘tank' obsolete and, therefore, irrelevant for requirements under the new condition. Combined, these effects slow learning down, moving the organization to a lower position on the learning curve, reflecting a lower level of organizational capability. Accordingly, it is proposed that:
Proposition 2a: Liabilities of incumbency reduce or block capability accumulation (continuous effect);
2b: Liabilities of newness make existing capabilities obsolete (discontinuous effect).
Finally, based on the preceding relationships, this brings us to the central proposition of the model, which describes a dynamic that can account for highly variable performance within and across projects in the same organization:
Proposition 3: Performance is the contested outcome of the positive effects of learning and the negative effects of liabilities of incumbency and newness on capabilities.
IS projects are particularly susceptible to the disruptive effects of liability conditions - especially discontinuities, which occur both within and between projects. Hardware, software, development tools, and methods are constantly changing or becoming obsolete. These discontinuities significantly impact people, processes, and technologies in use, destroying the value of existing knowledge and expertise (capabilities). Even when capabilities are developed in current technologies during a project, they are often different or obsolete by the time the next project starts, especially in organizations whose main business is not conducting projects. Different hardware platforms and software tools are required; project managers and teams change, and; the application domain changes. Similarly, changes in organizational directions, priorities, structures, processes and senior management can set back accumulated learning and/or negate the value of accumulated capabilities, increasing the likelihood of underperformance.
In IS projects, especially those involving large-scale and transformational developments, the initial capability stocks plus the learning that occurs on the project can be less than the liability effects experienced during the project. Even with good project management in place, this can result in a net competence liability that limits current and subsequent project performance. When this persists, both within and between projects, limited learning accumulates and the organization is in no better position to take on a subsequent project than it was at the start of the previous one (as found in the case study that follows). This trade-off can explain why an organization might have an outstanding success with one project and a total failure with the next, or vice-versa. Factor and process performance approaches struggle to explain this variation in outcomes.
This model of project performance is different to that assumed by current explanations. In contrast to the assumption that factors and processes can be increasingly applied to deliver a successful outcome, the proposed model suggests that project performance is the outcome of two opposing effects on the organization's project capabilities. Rather than reflecting a functional form in which factors have a continuous positive main effect on outcomes, this model proposes a more complex form of contested outcome between two effects that have opposite signs. Furthermore, these liability effects are not simply moderators of the main effect of learning on capabilities because both drivers include discontinuous effects that change the capabilities that are held (in the case of discontinuous learning) or are needed (in the case of liabilities of newness) by the organization. The unpredictable nature of liability conditions, in both frequency and magnitude, can produce substantial variation in project outcomes, explaining the persistent variance in practice-based empirical data found in the literature. This explanatory power is illustrated in the following case study.
A case study is summarized here of a DMV (department of motor vehicles) in an Australian state that illustrates and provides initial validation of the proposed alternative explanation for project performance.
A project was initiated to replace the department's inefficient mainframe system with a new online system for administration of the State's drivers and motor vehicles. The study examined the initial development project and subsequent upgrades from 1989 to 2001 (a period of 13 years) to provide a longitudinal view of the organization's IS development project capability. The study design and analysis followed the prescriptions of Eisenhardt (1989) and Yin (2009). Four periods (phases) were examined: the initial development; stabilization and initial functional expansion; outsourcing and further functional expansion, and; reorganization. Case data sources included fifty semi-structured interviews, periods of direct observation, and a wide range of documentation. For full details of the case and research method, see Bannerman, 2004.
The design of the new system was innovative and required integration of new technologies. The initial development was an all too familiar case of a “successful failure.” That is, the system project was very late, well over budget and significantly de-scoped in functionality. On this basis, arguably, the case is not an example of good project management. However, the project ultimately achieved the department's major business objectives, including savings of $US20 million a year. As a result, the success was acknowledged with an industry award for excellence for the system project.
This was a curious outcome, because following the initial system implementation, pandemonium broke out due to myriad operational and performance issues, resulting in public outcry. The system was slow and regularly locked up, customer data records were inaccurate or missing, policy enforcement was inconsistent or inappropriate, and customer queues and delays in completing basic transactions were intolerable. It took many months (ultimately, years) to painstakingly resolve each issue. Then, a continuous program of technical and functional enhancement projects (mainly to meet ongoing government policy changes) kept the development team busy and the system in a constant state of flux. The department maintained a large team of technical contractors (approximately 50 people) to augment its small permanent internal IS staff (less than 20) throughout the study period.
Due to the anomalous excellence award and the ongoing state of development of the system, the case presented an opportunity to examine the substance of the department's excellence and performance in IS development projects. One possible interpretation of the award is that the initial project ‘failure' was an exception, and exemplary performance would dominate subsequent projects. On this basis, one would expect to see a progressive accumulation of capabilities during subsequent ongoing maintenance and enhancement projects, and perhaps application of those capabilities to other IS projects in the department. However, this was not evident. To understand why, the case was examined for evidence of learning accumulation and liability conditions over the study period.
Changes in the status of eight core IS capabilities adapted from Feeny and Willcock (1998) were analyzed in the four phases across the study period. The capabilities are summarized in Table 3. Capability strength was measured as low, medium, or high for each capability in each phase of the study. Measurement was aided by empirical indicators developed for each capability (described in Bannerman, 2004).
Analysis of the case also identified the co-presence of liability conditions from Tables 1 and 2 in each phase (6 liabilities of incumbency and 3 liabilities of newness). These liability conditions are summarized in Table 4. Again, identification was aided by empirical indicators developed for each liability condition (described in Bannerman, 2004). The liability conditions variously impacted the capabilities in each phase (up to five liability conditions were found to impact a capability in a phase).
|Leadership||Delivering business value by integrating the IS function with business purpose and activity. Applies to the CIO, CEO, and executive management team.|
|Business Systems Thinking||Envisioning the business processes that IS makes possible.|
|Building Business Relationships||Engaging with business in their needs and engaging business in IS delivery (and/or customers, as relevant).|
|Architecture Planning||Specifying, delivering, and maintaining the organization's technical architecture and infrastructure for ongoing business needs.|
|Making Technology Work||Ensuring that installed technology operates as required and expected.|
|Building Vendor Relationships||Developing and managing informal and formal relationships and value-added service delivery with external suppliers.|
|Managing Projects||Planning, executing, and controlling projects to carry out discrete IS activities, according to organizational needs.|
|Managing Change||Understanding and managing organizational dynamics to effect change involving information technology.|
Table 3: Capabilities Measured.
|Condition||Description||Type*||Origin in the Literature**|
|Influence of Past Practices||Commitment to former learning and ways of doing things limits new learning and capability development.||1||Competency traps; unjustified theories-in-use; core rigidities; need for unlearning; organizational inertia; system rigidities|
|Constrained Focus/ Focus Diversion||Focus on proximate issues leads to development and maintenance of broader and longer term capabilities being ignored.||1||Learning myopia; focus diversion; causal ambiguity|
|Knowledge Transfer Barrier||Low incentives, vested interests (on the part of contractors), and the embedded, tacit nature of capabilities limit knowledge sharing and transfer.||1||Tacitness; embeddedness; stickiness; causal ambiguity; low transformative capacity; organization design barriers|
|Limited Critical Mass||Low staff and skill levels (such as due to a dominance of contractors) make it difficult for learning and capability development to occur.||1||Low absorptive capacity; asset mass inefficiencies; interconnectedness|
|Time Compression Barrier||Long capability development lead-time can result in slow growth in capabilities and a low level of commitment to learning and development.||1||Time compression diseconomies; low aspiration levels; project characteristics; information processing limitations|
|Weak Learning Culture||Lack of structural mechanisms and encouragement for staff limit learning and capability development.||1||Learning disincentives; training and education; project characteristics; recognition and progression|
|Newness Discontinuity||New or changed situation for which there is no guiding prior experience or established operational routines to apply.||2||Newness; technological change; radical methods; technological discontinuities|
|Capability Erosion||Loss of staff and management deplete existing knowledge and skill bases.||2||Asset erosion; staff loss through turnover, downsizing and/or outsourcing|
|Architectural Fragmentation||Constant functionality improvements fragmented the system design making it increasingly difficult to maintain and change.||2||Architectural innovations; technological change; organizational forgetting|
* 1 = Incumbency; 2 = Newness
** See Tables 1 and 2 for descriptions and references
Table 4: Liability Conditions Identified.
In addition to an ongoing flow of technology changes, the study period also featured many organizational changes that occurred concurrently with, or as a direct result of, the ongoing system development (the major changes are summarized in Figure 5). These occurred in conjunction with a stream of ongoing software version upgrades, escalating design complexity, architecture fragmentation, and the movement of key people. Attending this constant change were significant incumbency and newness liabilities (in Table 4) that competed with experience-based learning in developing the capabilities in Table 3.
Figure 5: Chronology of Major Changes at the DMV.
An example of a trade-off in performance drivers is provided by the initial system development project. Key capabilities enabling the initial development were leadership, architecture (infrastructure) planning, and making technology work. The highly skilled development team chose a novel unproven system design requiring integration of many new technologies. As one senior technician said, “The system was always going to work. It just took longer than we expected to get everything to fit together and perform at the required transaction throughput rates.” Newness discontinuity, time compression barrier, and influence of past practices, in particular, offset the strong capabilities the team brought to the project, resulting in the effective failure of the initial development project (late, over budget, and under-specifications).
Another example is a discontinuity that occurred when the CEO departed, significantly eroding capability available to the system. The leadership of this CEO had championed the initial development and provided substantial executive support, without which the business objectives may not have been achieved. However, the replacement CEO had a very different attitude and agenda. He outsourced the department's data centre, resulting in the loss of many highly skilled technical resources, and created a dependency on a service provider who proved to have underestimated the effort and skill required to operate and support the system. Two years of operational turbulence ensued before both organizations adjusted to the new arrangement.
The analysis found that very little cumulative learning occurred in the capabilities during the study period. From Table 5, it can be seen that cumulative learning occurred in only one capability over the four phases of the study period (building vendor relationships); four capabilities finished at the same level at the end as at the start (managing projects, making technology work, business systems thinking, and building business relationships), although three of these did improve temporarily in at least one phase of the study and; the remaining thee capabilities diminished from their original levels at the start of the study period (leadership, architecture planning, and managing change). Overall, therefore, there was a marginal net decline in capability. Managing projects remained unchanged at a medium level of capability throughout the study period. This is surprising given the long duration of the study and the centrality of project management to the ongoing development of the system.
Furthermore, liability conditions were found to be high and significantly associated with each capability across the study. Table 6 summarizes the number of capabilities each liability condition was found to impact in each phase (the amount of data is too great to show the mapping of individual liabilities to individual capabilities in this paper). All nine liability conditions were found in each study phase, with two exceptions (knowledge transfer barrier and capability erosion were not evident in phase 1). Two liability conditions (time compression barrier and weak learning culture) were found to be generic liabilities that impacted all capabilities in each phase, so they were not explicitly included in the count. Note that the highest ranked liability of incumbency and liability of newness conditions each negatively impacted over 80% of the capabilities across the whole study period. In total, 53% of all capabilities experienced the negative effects of one or more specific liability conditions during the study period. More significantly, the incidence of liability condition impacts increased in each successive phase until the last phase, where it essentially remained at the highest level.
|IS Capability||Phase 1 Status||Phase 2 Status||Phase 3 Status||Phase 4 Status||Net Change||Summary Explanation|
|Building Vendor Relationships||L||L||M||M||+||Learning & capability development restricted to single vendor|
|Managing Projects||M||M||M||M||None||Not seen as a specialist skill; methods remained deficient|
|Making Technology Work||M||H||M||M||+/-||Challenged by constant change; mostly insourced contractor skill|
|Business Systems Thinking||L||M||M||L||+/-||Focus on technical tasks; knowledge limited to team leaders|
|Building Business Relationships||L||M||M||L||+/-||Focus on technical tasks; goodwill through strong role separation|
|Leadership||H||M||M||M||-||Original CEO/CIO vision, synergy and alignment lost|
|Architecture Planning||M||M||L||L||-||Initial skills diminished through outsourcing and focus diversion|
|Managing Change||M||L||L||L||-||Not seen as IT responsibility; focus on technical change|
Table 5: Summary of Capability Strengths by Phase.
|Liability Condition||Phase 1||Phase 2||Phase 3||Phase 4||Total||Impact|
|Constrained Focus (/Focus Diversion)||7||6||7||7||27||84%|
|Influence of Past Practices||4||4||5||5||18||56%|
|Knowledge Transfer Barrier||-||2||6||6||14||44%|
|Limited Critical Mass||5||3||2||3||13||41%|
|Time Compression Barrier||All||All|
|Weak Learning Culture||All||All|
|Total Liability/Capability Impacts||26||28||33||32||119||53%|
Table 6: Summary of Liability Conditions by Phase.
Based on this analysis, it can be concluded that any organizational learning and capability development that occurred during the study period was offset by the effects of recurrent liability conditions, resulting in the maintenance of a cumulative net competence liability rather than accumulated organizational learning and capability development. The level of capability stocks at the end of the study period was no greater than at the start (rather, it was slightly lower). This profile fits the absence of observed exemplary performance in projects over the study period. Capability accumulation was being negated by liability conditions that robbed the DMV of performance value. Accordingly, in moving forward to any other large IS development project in the future (such as the next generation administration system), the DMV was in no better position to improve its likelihood of success than it had been for the previous system project. The initial development project performance result appeared not to be an exception but rather a reflection of an underinvestment in organizational learning and capability development in the face of constant disruptive technical and organizational change and incumbency conditions that negatively impacted the organizational capabilities available to the DMV to apply to the project.
This paper contributes an alternative explanation of project performance and the commonly accepted dilemma that good project management is necessary but not sufficient for project success. By adopting an organizational learning and capability theory perspective, it has argued that a model of project performance needs to include discontinuous as well as continuous effects and a negative driver that is not just the opposite of doing the right things in the right ways. The model developed here suggests that from the perspective of also having the right resources, project performance is the contested outcome of positive learning effects on organizational capabilities applied to the projects, and the negative effects of liability conditions on learning and capability development. Incumbency and newness conditions can diminish, block, and/or obviate existing capability stocks, reverting the organization to a vulnerability to underperforming or even failing. This capability-based contest between opposing drivers can result in unpredictable outcomes on a project-by-project basis within the same organization. Furthermore, because of the high level of change and uncertainty associated with IS projects, it can account for why such a project might be more likely to fail than succeed if this learning and capability dynamic was not recognized and managed.
The research has limitations. First, it is a theoretical contribution that is only initially validated through illustration using one case study. Further empirical testing is required to establish the bounds of its relevance both within the IS application domain and in other project domains such as construction, engineering and defense. Longitudinal case studies of the kind presented offer the opportunity to investigate the dynamics proposed in the model, but other methods such as surveys and event studies could also be considered. Second, the model is not explicitly applied to different project scenarios. For example, organizations whose main business is not delivering projects versus project-based organizations and organizations whose main business is delivering projects to customers, such as IS service firms. Conceptually, the model may be applied in different project scenarios but the implications and effects may vary (see the following). Finally, the paper does not consider how capabilities are built, their inter-relationships, how they aggregate, the role of complementarities and intervening variables, or the capability threshold between project performance and underperformance. These are separate areas for research.
The performance model has implications for research and managerial practice. For research, one implication is to widen project research by challenging current assumptions and seeking models that take a different functional form, rather than only looking for more definitive critical success factors and project processes. The model developed here suggests that project performance is more complex and dynamic than a main-effects relationship with antecedent factors and processes. Second, the model provides a theoretical justification for capability-based sourcing. Capability optimization has been a motivator in sourcing decisions for many years but it has lacked a specific theoretical foundation outside of organizational economics (the ‘buy versus build' decision) and resource dependence theory. The model implies that an organization is better-off focusing on building capabilities that are fundamental to its business because these are capabilities that are more likely to be able to mature. This will improve its chances of staying in the continuous learning part of the model and minimize exposure to liability conditions. A final implication is for IS-enabled organizational change research. IS strategy research largely assumes a continuous world in which projects can be clustered and sequenced into a change program to implement strategy. By contrast, the proposed model suggests that transformational projects are quasi-independent events that are fundamentally discontinuous. There are no guarantees that projects in a program will work together to achieve the desired results. This implies a need for further research on managing strategy under conditions of discontinuity via projects.
For practice, two key implications flow for managers. First, avoid limiting managerial focus to critical success factors, processes, and methodologies. Rather, consider also the learning and capability conditions that might represent unexpected barriers to progress and performance. According to the model developed here, projects can underperform or fail despite good management and traditional project management experience. Risk management can also fall down in the face of project discontinuities because they cannot be easily identified as risks before they impact the project (Bannerman, 2008a, 2008b). Having high levels of capability in the project domain is critical to an organization's ability to respond to unexpected and discontinuous change. Second, to manage the problem, managers need to structure projects to bias the organization's position towards the learning side of the model. This can be done by choosing projects that build on the capabilities that are operationally and strategically relevant to the business, thereby limiting the likely impact of liability conditions. For example, as is widely recognized, an organization whose main business is not building information systems (such as the DMV) would be better-off outsourcing the development to a suitable service provider. This would enable it to employ and further develop its own internal service delivery capabilities in managing the delivery from the service provider. This positions the organization in the continuous learning part of the model in contrast to the position it would be in if it tried to do the work of the project itself with inadequate stocks of the required capabilities. By contrast, the service provider is able to leverage the cost of building capabilities in the work of the project across multiple clients and concurrent projects, because this is its core business, thereby also biasing its position towards the learning part of the model. The fundamental wisdom of working within one's own capabilities (or carefully stage-managing incremental development of new capabilities) is generally intuitively understood. However, it seems that because projects are one-off endeavors to produce a unique product, service or result, we tend to assume that this logic can be put aside for projects. Until better ways of managing projects under liability of incumbency and newness conditions evolve, ‘riding the learning curve' is the best way forward.
Project-based operations are pervasive in human endeavors. This trend is likely to increase rather than decrease in the foreseeable future. Therefore, improving the certainty of project outcomes is critical to human progress and the efficient use of resources. New thinking is needed to redress a tradition of variable and poor performance outcomes, especially in IS projects. The alternative explanation for project performance developed in this paper fills critical gaps in current approaches to the problem by highlighting the importance of capabilities (in addition to factors and processes) in project performance, the existence of independent drivers of underperformance, and the underlying complexity of performance in practice. Built on existing theory, the model contributes a new explanation of why projects are difficult to manage and why performance varies, and it improves our ability to explain anomalous project outcomes encountered in practice. Further work is needed, however, to improve our ability to manage projects in a world characterized by these dynamics.
NICTA is funded by the Australian Government as represented by the Department of Broadband, Communications and Digital Economy and the Australian Research Council through the ICT Centre of Excellence program.
Abdel-Hamid, T. K., & Madnick, S. E. (1990). The elusive silver lining: How we fail to learn from software development failures. Sloan Management Review, 32(1), 39–48.
Amburgey, T. L., Kelly, D., & Barnett, W. P. (1993). Resetting the clock: The dynamics of organizational change and failure. Administrative Science Quarterly, 38(1), 51–73.
Argyris, C. (1977). Double loop learning in organizations. Harvard Business Review, 55(5), 115–125.
Argyris, C. (1991). Teaching Smart People How to Learn. Harvard Business Review, 69(3), 99–109.
Argyris, C., & Schön, D. A. (1978). Organizational learning. Reading, MA: Addison-Wesley.
Attewell, P. (1992). Technology diffusion and organisational learning. Organization Science, 3(1), 1–19.
Ayas, K. (1996). Professional project management: A shift towards learning and a knowledge creating structure. International Journal of Project Management, 14(3), 131–136.
Ayas, K. (1999). Project design for learning and innovation. In M. Easterby-Smith, J. Burgoyne, & L. Araujo (Eds.), Organizational learning and the learning organization (pp. 176–193). London, England: Sage.
Ayas, K., & Zeniuk, N. (2001). Project-based learning: Building communities of reflective practitioners. Management Learning, 32(1), 61–76.
Bannerman, P. L. (2004). The liability of newness: Toward a capability-based theory of information systems performance. PhD Dissertation, Australian Graduate School of Management, The University of Sydney and The University of New South Wales.
Bannerman, P. L. (2008a). Risk and risk management in software projects: A reassessment. Journal of Systems and Software, 81(12), 2118–2133.
Bannerman, P. L. (2008b). Toward an integrated framework of software project threats. In Proceedings of the 19th Australian Software Engineering Conference (ASWEC'08), IEEE, 139–148.
Bannerman, P. L., & Thorogood, A. (2012). Celebrating IT projects success: A multi-domain analysis. In Proceedings of the 45th Hawaii International Conference on System Sciences (HICSS45), IEEE, 4–7 January, Grand Wailea, Maui, Hawaii, pp. 4874–4883.
Barney, J. B. (2011). Gaining and sustaining competitive advantage (4th Ed.). Upper Saddle River, NJ: Pearson (Prentice Hall).
Barney, J. B., & Clark, D. N. (2007). Resource-based theory: Creating and sustaining competitive advantage. Oxford, UK: Oxford University Press.
Brady, T., & Davies, A. (2004). Building project capabilities: From exploratory to exploitative learning, Organization Studies, 25(9), 1601–1621.
Bredin, K. (2008). People capability of project-based organisations: A conceptual framework. International Journal of Project Management, 26(5), 566–576.
Brown, J. S., & Duguid, P. (1998). Organizing knowledge. California Management Review, 40(3), 90–111.
Christensen, C. M. (2000). The innovator's dilemma. New York, NY: HarperBusiness.
Cohen, W. M., & Levinthal, D. A. (1990). Absorptive capacity: A new perspective on learning and innovation. Administrative Science Quarterly, 35(1), 128–152.
Cohen, W. M., & Levinthal, D. A. (1994). Fortune favors the prepared firm. Management Science, 40(2), 227–251.
Crawford, L. (2000). Profiling the competent project manager. In Project Management Research at the Turn of the Millennium. In Proceedings of PMI Research Conference, Sylva, NC: Project Management Institute, 3–15.
Crawford, L. (2006). Developing organizational project management capability: Theory and practice. Project Management Journal, 36(3), 74–97.
Crawford, L., & Nahmias, A. H. (2010). Competencies for managing change. International Journal of Project Management, 28(4), 405–412.
Davies, A., & Brady, T. (2000). Organisational capabilities and learning in complex product systems: Towards repeatable solutions. Research Policy, 29(7–8), 931–953.
DeFillippi, R. J. & Arthur, M. B. (1998). Paradox in project-based enterprise: The case of film making. California Management Review, 40(2), 125–139.
De Holan, P. M., Phillips, N., & Lawrence, T. B. (2004). Managing organizational forgetting. Sloan Management Review, 45(2), 45–51.
de Wit, A. (1988). Measurement of project success. International Journal of Project Management, 6(3), 164–170.
Dierickx, I., & Cool, K. (1989). Asset stock accumulation and sustainability of competitive advantage. Management Science, 35(12), 1504–1511.
Durand, T. (2000). Forms of incompetence. In R. Sanchez & A. Heene (Eds.), Advances in applied business strategy: Theory development for competence-based management (Vol. 6A) (pp. 69–95). Stamford, CT: JAI Press.
Edum-Fotwe, F. T., & McCaffer, R. (2000). Developing project management competency: Perspectives from the construction industry. International Journal of Project Management, 18(2), 111–124.
Eisenhardt, K. M. (1989). Building theories from case study research. Academy of Management Review, 14(4), 532–550.
Eveleens, J. L., & Verhoef, C. (2010). The rise and fall of the chaos report figures. IEEE Software, 27(1), 30–36.
Feeny, D. F., & Willcocks, L. P. (1998). Core IS capabilities for exploiting technology. Sloan Management Review, 39(3), 9–21.
Fisher, S. R., & White, M. A. (2000). Downsizing in a learning organization: Are there hidden costs? Academy of Management Review, 25(1), 244–251.
Flyvbjerg, B., & Budzier, A. (2011). Why your IT project may be riskier than you think. Harvard Business Review, 89(9), 23–25.
Galliers, R. D. (1997). Against obliteration: Reducing risk in business process change. In C. Sauer & P.W. Yetton (Eds.), Steps to the future (pp. 169–186). San Francisco, CA: Jossey-Bass.
Garud, R. (1997). On the distinction between know-how, know-why, and know-what. Advances in Strategic Management, 14, 81–101.
Garud, R., & Nayyar, P. R. (1994). Transformative capacity: Continual structuring by intertemporal technology transfer. Strategic Management Journal, 15(5), 365–385.
Geoghegan, L., & Dulewicz, V. (2008). Do project managers' leadership competencies contribute to project success? Project Management Journal, 39(4), 58–67.
Gill, T. G. (1995). High-tech hidebound: Case studies in information technologies that inhibited organizational learning. Accounting, Management and Information Technologies, 5(1), 41–60.
Haggerty, N. (2000). Understanding the link between IT project manager skills and project success. In Proceedings of the Annual Conference of the ACM Special Interest Group on Computer Personnel Research (ACM SIGCPR'00), Chicago, Illinois, 192–195.
Hamel, G. (1994). The concept of core competence. In G. Hamel & A. Heene (Eds.), Competence-based competition (pp. 11–33). Chichester, England: John Wiley & Sons.
Hammer, M. (1990). Reengineering work: Don't automate, obliterate. Harvard Business Review, 68(4), 104–112.
Hannan, M. T., & Freeman, J. (1984). Structural inertia and organizational change. American Sociological Review, 49(2), 149–164.
Hansen, M. T. (1999). The search-transfer problem: The role of weak ties in sharing knowledge across organization subunits. Administrative Science Quarterly, 44(1), 82–111.
Helfat, C. E., Finkelstein, S., Mitchell, W., Peteraf, M. A., Singh, H., Teece, D. J., & Winter, S. G. (2007). Dynamic capabilities: Understanding strategic change in organizations. Malden, UK: Blackwell Publishing.
Henderson, R. M., & Clark, K. B. (1990). Architectural innovation: The reconfiguration of existing product technologies and the failure of established firms. Administrative Science Quarterly, 35(1), 9–30.
Ingason, H. T., & Jónasson, H. I. (2009). Contemporary knowledge and skill requirements in project management. Project Management Journal, 40(2), 59–69.
Jørgensen, M., & Moløkken-Østvold, K. (2006). How large are software cost overruns? A review of the 1994 CHAOS Report. Information and Software Technology, 48(4), 297–301.
Jugdev, K., Mathur, G., & Fung, T. S. (2007). Project management assets and their relationship with the project management capability of the firm. International Journal of Project Management, 25(7), 560–568.
Keegan, A., & Turner, J. R. (2001). Quantity versus quality in project-based learning practices. Management Learning, 32(1), 77–98.
Knott, A. M., Bryce, D. J., & Posen, H. E. (2003). On the strategic accumulation of intangible assets. Organization Science, 14(2), 192–207.
Kogut, B., & Zander, U. (1992). Knowledge of the firm, combinative capabilities and the replication of technology. Organization Science, 3(3), 383–397.
Lampel, J. (2001). The core competencies of effective project execution: The challenge of diversity. International Journal of Project Management, 19(8), 471–483.
Leonard-Barton, D. (1992). Core capabilities and core rigidities: A paradox in managing new product development. Strategic Management Journal, 13, 111–125.
Leonard-Barton, D. (1995). Wellsprings of knowledge: Building and sustaining the sources of innovation. Boston, MA: Harvard Business School Press.
Levinthal, D. A., & March, J. G. (1993). The myopia of learning. Strategic Management Journal, 14, 95–112.
Levitt, B., & March, J. G. (1988). Organisational learning. Annual Review of Sociology, 14, 319–340.
Lippman, S. A., & Rumelt, R. P. (1982). Uncertain imitability: An analysis of interfirm differences in efficiency under competition. Bell Journal of Economics, 13(2), 418–438.
Lyytinen, K., & Robey, D. (1999). Learning failure in information systems development. Information Systems Journal, 9(2), 85–101.
March, J. G. (1991). Exploration and exploitation in organizational learning. Organization Science, 2(1), 71–87.
March, J. G., & Simon, H. A. (1993). Organizations (2nd ed.). Cambridge: Blackwell Business.
Melkonian, T., & Picq, T. (2010). Opening the “black box” of collective competence in extreme projects; lessons from the french special forces. Project Management Journal, 41(3), 79–90.
Mohrman, S. A., Finegold, D., & Klein, J. A. (2002). Designing the knowledge enterprise: Beyond programs and tools. Organizational Dynamics, 30(2), 134–150.
Montealegre, R. (2002). A process model of capability development. Organization Science, 13(5), 514–531.
Nadler, D. A., & Tushman, M. L. (1997). Competing by design: The power of organizational architecture. New York, NY: Oxford University Press.
Nelson, R. R., & Winter, S. G. (1982). An evolutionary theory of economic change. Cambridge, MA: Belknap Press/Harvard University Press.
Nonaka, I., & Takeuchi, H. (1995). The knowledge-creating company: How Japanese companies create the dynamics of innovation. New York, NY: Oxford University Press.
Nystrom, P. C., & Starbuck, W. H. (1984). To avoid organizational crises, unlearn. Organizational Dynamics, 12(4), 53–65.
Orlikowski, W. J. (1993). CASE tools as organizational change: investigating incremental and radical changes in systems development. MIS Quarterly, 17(3), 309–340.
Partington, D., Pellegrinelli, S., & Young, M. (2005). Attributes and levels of programme management competence: An interpretive study. International Journal of Project Management, 23(2), 87–95.
Pettigrew, A. M. (1998). Success and failure in corporate transformation initiatives. In R. D. Galliers & W. R. J. Baets (Eds.). Information technology and organizational transformation (pp. 271–289). Chichester, UK: Wiley.
Polanyi, M. (1966). The tacit dimension. Gloucester, UK: Peter Smith.
Prahalad, C. K., & Hamel, G. (1990). The core competence of the corporation. Harvard Business Review, 68(3), 79–91.
Prencipe, A., & Tell, F. (2001). Inter-project learning: Processes and outcomes of knowledge codification in project-based firms. Research Policy, 30(9), 1373–1394.
Purcell, K. J., & Gregory, M. J. (2000). The development and application of a process to analyze the strategic management of organizational competences. In R. Sanchez & A. Heene. (Eds.), Implementing competence-based strategies, Advances in Applied Business Strategy (Vol. 6B) (pp. 161–197). Stamford, CT: JAI Press.
Quinn, J. B., & Hilmer, F. G. (1994). Strategic outsourcing. Sloan Management Review, 35(4), 43–55.
Reed, R., & DeFillippi, R. J. (1990). Causal ambiguity, barriers to imitation and sustainable competitive advantage. Academy of Management Review, 15(1), 88–102.
Robey, D., Boudreau, M-C., & Rose, G. M. (2000). Information technology and organizational learning: a review and assessment of research. Accounting, Management and Information Technologies, 10(2), 125–155.
Rose, J., Pedersen, K., Hosbond, J., & Kraemmergaard, P. (2007). Management competences, not tools and techniques: A grounded examination of software project management at WM-data. Information and Software Technology, 49(6), 605–624.
Sauer, C. (1999). Deciding the future for IS failures: Not the choice you might think. In W. L. Currie & R. D. Galliers (Eds.), Rethinking management information systems (pp. 279–309). Oxford, UK: Oxford University Press,.
Schulz, M. (2001). The uncertain relevance of newness: organizational learning and knowledge flows. Academy of Management Journal, 44(4), 661–681.
Shi, Q., & Chen, J. (2006). The human side of project management: Leadership skills. Newtown Square, PA: Project Management Institute.
Simon, H. A. (1991). Bounded rationality and organizational learning. Organization Science, 2(1), 125–134.
Skulmoski, G. J., & Hartman, F. T. (2010). Information systems project manager soft competencies: A project-phase investigation. Project Management Journal, 41(1), 61–80.
Söderlund, J. (2008). The dynamics of project competence: the case of ASEA/ABB 1950–2000. In Proceedings of the Project Management Institute Research Conference, July, Warsaw, 1–34.
Söderlund, J., Vaagaasar, A. L., & Andersen, E. S. (2008). Relating, reflecting and routinizing: Developing project competence in cooperation with others. International Journal of Project Management, 26(5), 517–526.
Söderlund, J., & Tell, F. (2009). The P-form organization and the dynamics of project competence: Project epochs in Asea/ABB, 1950–2000. International Journal of Project Management, 27(2), 101–112.
Starkweather, J. A., & Stevenson, D. H. (2011). PMP certification as a core competency: Necessary but not sufficient. Project Management Journal, 42(1), 31–41.
Stinchcombe, A. L. (1965). Social structure and organizations. In J.G. March. (Ed.), Handbook of organizations (pp. 142–193). Chicago, IL: Rand McNally College Publishing Company.
Szulanski, G. (1995). Unpacking stickiness: An empirical investigation of the barriers to transfer best practice inside the firm. Academy of Management Journal, Best Papers Proceedings 1995, 437–441.
Szulanski, G. (1996). Exploring internal stickiness: Impediments to the transfer of best practice within the firm. Strategic Management Journal, 17, (S2), 27–43.
Szulanski, G. (1997). Intra-firm transfer of best practices. In A. Campbell & K.S. Luchs (Eds.), Core competency-based strategy (pp. 208–235). London, UK: International Thomson Business Press.
Szulanski, G. (2003). Sticky knowledge: Barriers to knowing in the firm. London, UK: Sage.
Taleb, N. N. (2008). Fooled by randomness: The hidden role of chance in life and in the markets. Second Updated Edition. New York, NY: Random House.
Taleb, N. N. (2010). The black swan: The impact of the highly improbable (2nd ed.). New York, NY: Random House.
Teece, D. J., Pisano, G., & Shuen, A. (1997). Dynamic capabilities and strategic management. Strategic Management Journal, 18(7), 509–533.
Tripsas, M., & Gavetti, G. (2000). Capabilities, cognition, and inertia: Evidence from digital imaging. Strategic Management Journal, 21(10/11), 1147–1161.
Tushman, M. L., & Anderson, P. (1986). Technological discontinuities and organizational environments. Administrative Science Quarterly, 31(3), 439–465.
Tushman, M. L., & Nadler, D. A. (1978). Information processing as an integrating concept in organization design. Academy of Management Review, 3(3), 613–624.
Vaagaasar, A.L. (2008, July). On the power of project competence: Triggers, characteristics, and effects. Proceedings of the Project Management Institute Research Conference, Warsaw, Poland,1–10.
von Hippel, E. (1994). “Sticky information” and the locus of problem solving: Implications for innovation. Management Science, 40(4), 429–439.
Winter, S. G. (2000). The satisficing principle in capability learning. Strategic Management Journal, 21(10–11), 981–996.
Yin, R. K. (2009). Case study research: Design and methods (4th ed.). Thousand Oaks, CA: Sage Publications.
Zahra, S. A., & George, G. (2002). Absorptive capacity: A review, reconceptualization, and extension. Academy of Management Review, 27(2), 185–203.
1 Terminology is inconsistent in the literature. Descriptors include capability, competence, strategic asset and invisible asset. In the interests of parsimony, ‘capability' is mostly used in this paper, but the terms are considered to be interchangeable, consistent with Barney and Clark, 2007 and Hamel, 1994.
2 The definitions of success and failure are not discussed here. The terms are used conceptually. For a discussion on this topic see Bannerman and Thorogood (2012).
©2012 Project Management Institute