See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/223925054

Why projects fail? How contingency theory can provide new insights – A
comparative analysis of NASA’s Mars Climate Orbiter loss

Article  in  International Journal of Project Management · October 2009

DOI: 10.1016/j.ijproman.2009.01.004

CITATIONS READS

183 6,747

3 authors:

Brian Sauser Richard R. Reilly

University of North Texas Stevens Institute of Technology
118 PUBLICATIONS   2,262 CITATIONS    115 PUBLICATIONS   4,067 CITATIONS   

SEE PROFILE SEE PROFILE

Aaron Shenhar
Diamond Leadership Institute
113 PUBLICATIONS   5,928 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Managing the Development of Complex Product Systems View project

Determining the canonical forces affecting cooperate/defect decisions made by autonomous organizations in systems of human activity systems (my PhD topic) View
project

All content following this page was uploaded by Aaron Shenhar on 10 February 2018.

The user has requested enhancement of the downloaded file.

This article appeared in a journal published by Elsevier. The attached
copy is furnished to the author for internal non-commercial research
and education use, including for instruction at the authors institution
and sharing with colleagues.
Other uses, including reproduction and distribution, or selling or
licensing copies, or posting to personal, institutional or third party
websites are prohibited.
In most cases authors are permitted to post their version of the
article (e.g. in Word or Tex form) to their personal website or
institutional repository. Authors requiring further information
regarding Elsevier’s archiving and manuscript policies are
encouraged to visit:
http://www.elsevier.com/copyright
 Author's personal copy

Available online at www.sciencedirect.com

International Journal of Project Management 27 (2009) 665–679

www.elsevier.com/locate/ijproman

Why projects fail? How contingency theory can provide new insights – A
comparative analysis of NASA’s Mars Climate Orbiter loss
Brian J. Sauser *, Richard R. Reilly, Aaron J. Shenhar
Stevens Institute of Technology, School of System and Enterprises, Castle Point on Hudson, Hoboken, NJ 07030, USA

Received 30 January 2008; received in revised form 9 January 2009; accepted 15 January 2009

Abstract

When important projects fail, the investigation is often focused on the engineering and technical reasons for the failure. That was the
case in NASA’s Mars Climate Orbiter (MCO) that was lost in space after completing its nine-month journey to Mars. Yet, in many cases
the root cause of the failure is not technical, but managerial. Often the problem is rooted in management’s failure to select the right
approach to the specific project. The objective of this paper is to enrich our understanding of project failure due to managerial reasons
by utilizing different contingency theory frameworks for a retrospective look at unsuccessful projects and perhaps more important,
potential prevention of future failures. The evolving field of project management contingency theory provides an opportunity at this time
to re-examine the concept of fit between project characteristics and project management, and offer deeper insights on why projects fail.
After outlining several existing contingency studies, we use three distinct frameworks for analyzing the MCO project. These frameworks
include Henderson and Clark’s categorization of change and innovation, Shenhar and Dvir’s NTCP diamond framework, and Pich,
Loch, and De Meyer’s strategies for managing uncertainty. While each framework provides a different perspective, collectively, they
demonstrate that in the MCO program, the choices made by managers, or more accurately, the constraints imposed on them under
the policy of ‘better, faster, cheaper’, led the program to its inevitable failure. This paper shows that project management contingency
theory can indeed provide new insights for a deeper understanding of project failure. Furthermore, it suggests implications for a richer
upfront analysis of a project’s unique characteristics of uncertainty and risk, as well as additional directions of research. Such research
may help establish new and different conceptions on project success and failure beyond the traditional success factors, and subsequently
develop more refined contingency frameworks. The results of such research may enable future project managers to rely less on heuristics
and possibly lead to a new application of ‘‘project management design.”
! 2009 Elsevier Ltd and IPMA. All rights reserved.

Keywords: Project management; Contingency theory; Project failure

1. Preface Climate Orbiter (MCO) was perhaps one of the most

unfortunate examples. MCO was part of NASA’s Mars
Space exploration involves enormous risk and poses Surveyor Program, which was initiated in 1993 and
unprecedented scientific, engineering, and managerial chal- included the missions of MCO and Mars Polar Lander
lenges. Almost every mission is ‘‘first of its kind,” and is (MPL). MCO was supposed to circle Mars and collect
often characterized by extensive media coverage and public the planet’s weather data as well as act as a relay station,
interest. Successful programs produce valuable scientific assisting in data transmission to and from MPL, which
information as well as create great national pride. But was designed to land on Mars’ South Pole. MCO was
space research and exploration is highly risky, and some- launched on schedule on December 11, 1998 and traveled
time involves painful failures. The failure of NASA’s Mars in space nine and a half months before it approached the
vicinity of Mars. As soon as it began its insertion maneu-
ver, however, the orbiter’s signal was lost, and never recov-
*
Corresponding author. Tel.: +1 201 216 8589; fax: +1 201 216 5541. ered again. A retrospective peer review committee
E-mail address: bsauser@stevens.edu (B.J. Sauser). confirmed engineers’ assessment that small forces of

0263-7863/$34.00 ! 2009 Elsevier Ltd and IPMA. All rights reserved.

doi:10.1016/j.ijproman.2009.01.004
 Author's personal copy

666 B.J. Sauser et al. / International Journal of Project Management 27 (2009) 665–679

velocity changes used in orbit insertion were lower than Contingency theory is not a new concept in organiza-
expected by a factor of 4.45. Later on, a Mishap Investiga- tional research. Classical contingency theory has gradually
tion Board (MIB) concluded that the root cause of MCO’s evolved since the late 1950s. Dealing mostly with enduring
loss was a failure to use metric units in the coding of a organizations, the theory suggests that organizational effec-
ground software file. The failure of MCO was defined by tiveness is dependent upon the organization’s ability to
NASA as a technical error and its investigation produced adjust or adapt to the environment, and that there is a need
a collection of lessons learned and recommendations [9]. for congruency between the environment and structure
But often project failure goes beyond technical reasons. [24–26]. The contingency theory view started perhaps with
A retrospective look at MCO suggests that management Woodard [28] who argued that technologies directly deter-
could have prevented this failure by a better upfront assess- mine differences in such organizational attributes as span
ment of the program’s uncertainty and complexity, and by of control, centralization of authority, and the formaliza-
installing the proper managerial systems that would detect tion of rules and procedures. This was shortly followed
such errors ahead of time. But how can one know what to by Burns and Stalker’s famous research [29] that intro-
do ahead of time? That is the focus of this paper. duced the concepts of mechanistic versus organic organiza-
tions, and suggested that the more turbulent dynamic
2. Introduction environments should be addressed by an organic organiza-
tion. Three of the most influential works in the develop-
Projects have clearly become a central activity in most ment of this theory appeared simultaneously in the mid
organizations and companies are investing increasing 1960s. They included Lawrence and Lorsch [25] who
resources in projects such as new product development, showed how different rates of change can effect the organi-
process improvement, or building new services. Many stud- zations ability to cope; Thompson [33] who showed that
ies have demonstrated, however, that most projects do not coping with uncertainty is a core problem for complex
meet time and budget goals, or fail to satisfy customer and/ organizations; and Perrow [35] who used an integrated
or company expectations [11–16]. Yet, project success viewpoint on technology and complex organizations to
means more than just meeting time and budget goals. It identify four types of organizations. In 1977, Galbraith
involves additional success dimensions such as business [36] published his landmark book in organizational design,
results or preparing for the future [40]. Regardless of the which paved the way for a stream of followers in studying
success criteria, researchers have tried for years to find organizational contingency theory (e.g., [24] or [26]). Dra-
the reasons for project success or failure. One of the most zin and van de Ven explained the context-structure–perfor-
common approaches is the search for critical success fac- mance relationships in structural contingency theory to
tors [17–20]. The assumption in these studies is, that pro- show that fit is an important interpreter of performance.
jects succeed or fail because of similar reasons and the While the concept of structural contingency has been
researcher’s objective is to identify these reasons. These well established in the organizational theory literature, only
studies produced list of typical factors such as, project mis- recently has it been applied to project management
sion, planning, communication, politics, control, top man- research [39,40,42]. In this paper, we provide an overview
agement support, technical tasks, etc. Yet, in spite of their of project management contingency frameworks that have
popularity, critical success factors studies have had little been mentioned in the literature over the past 25 years and
impact on project management practices and few organiza- discuss their relevance. We then use three of the leading
tions or managers are actually using the findings of these contingency frameworks to analyze the management of
studies to improve their managerial processes. NASA’s Mars Climate Orbiter. We show how these differ-
This paper utilizes a different stream of research – the ent frameworks demonstrate the power and richness of
adoption of organizational contingent theory to project contingency theory, not only for a better explanation of
management. The contingency approach to project man- project failure, but also for an upfront analysis of project
agement investigates the extent of fit or misfit between pro- characteristics and adaptation of a preferred project man-
ject characteristics and project management approach. agement style. We will conclude with a discussion of future
Potentially, in analyzing real cases, the detection of misfit research direction and its potential contribution to theory
may help better explain project failure. More important, building and managerial practices.
understanding the elements of such misfit may provide rec-
ommendation for a preferred managerial approach before 3. Mars Climate Orbiter story
a project is launched, or for bringing a troubled project
back on track. Thus the objective of this paper is to enrich Mars Climate Orbiter (MCO) was to be the first in a ser-
our understanding of project failure due to managerial rea- ies of missions in the next steps of Mars exploration. Jet
sons by utilizing different contingency theory frameworks Propulsion Laboratory (JPL) in Pasadena, CA was com-
for a retrospective look at unsuccessful projects. Our goal missioned to lead this program, and it selected Lockheed-
is to demonstrate the power of contingency theory beyond Martin Astronautics as an industry partner to develop
traditional success and failure studies and to offer avenues the spacecraft. The intensive competitive contract would
for further contingency research. give Lockheed-Martin the opportunity to compete for
 Author's personal copy

B.J. Sauser et al. / International Journal of Project Management 27 (2009) 665–679 667

eight spacecraft for Mars exploration. The intention was Schedule and cost pressures led to decisions not to retest
that by duplicating the spacecraft for every mission, the some critical systems. While the project followed the stan-
spacecraft development would become ‘‘carbon copies” dard technical development and review process, it did not
for subsequent opportunities. JPL believed that this could have adequate resources to support a full detailed review
result in immense cost savings in the long-term. NASA at process. As one of the team leaders stated: ‘‘It was manda-
that time was greatly influenced by the hallmark of ‘‘faster, tory that we cut corners, primarily in the review and the
better, cheaper” (FBC) policy, which advocated smaller quality engineering processes” [43].
and cheaper missions compared to any previous time in MCO was launched on time on December 11, 1998, and
the agency’s history. spent the next nine and a half months traversing through
As a project, MCO was to design, develop, test, launch, space toward Mars. Upon arrival at Mars, MCO started
and operate an orbiter that would collect weather data its orbit insertion trajectory, but 4 min later, the spacecraft
from Mars. MCO was to have mission duration of two signal was lost and never recovered again.
years where it would accomplish its entire science objec- Immediately after the loss, the operation’s navigation
tives. It was then planned to operate as a relay station team and the spacecraft engineers discovered that the small
for the Mars Polar Lander (MPL) for an additional period forces of velocity changes used by the spacecraft for orbit
of three years. MCO was jointly developed with MPL, insertion were low by a factor of 4.45. A JPL peer review
which was designed to land on the South Pole of Mars committee confirmed these as the likely cause of the Orbi-
and follow shortly after MCO. Under the policy of BFC, ter’s lose. The MCO MIB would look independently into
a team of 300 people from JPL and Lockheed-Martin were all aspects of the failure of the mission, and identified the
given a financial cap of about $184 million (covering devel- root cause for the loss of the spacecraft as the failure to
opment of the spacecrafts, scientific payloads, and the use metric units in the coding of a ground software file.
ground operations systems). The project was also con-
strained by a schedule of 37 months before launch, dictated 4. Project management contingency theory
by celestial mechanics.
All budgets were structured by fixed-cost contracts, The study of contingency theory in project management
which included the planning and engineering development has gradually emerged during the last two decades. Specific
of MCO and MPL, (and were about half of those spent frameworks for project management have often been influ-
some years earlier on the successful Mars Pathfinder pro- enced by research from disciplines such as innovation,
gram). Using a predetermined launch vehicle and compet- organization theory, management, computer science, prod-
itively selected payloads, the technical requirements were uct development, and engineering. Among some of the
frozen early on to make sure time constraints were met. early writers in defining a typology of projects were Blake
The team’s perception was, that even slight changes would [44], who suggested a distinction between minor change
result in significant cost and time overruns. The MCO team (alpha) projects and major change (beta) projects, and
worked under extreme combined constraints of cost, sche- Steele [45] who looked at innovation types in big business.
dule, and technical requirements that were unheard off in Wheelwright and Clark [46] introduced a well-recognized
any new interplanetary mission before. In addition, MCO typology for product development projects, which included
had to adopt a cumbersome ‘‘earned value” technique used derivatives, platforms, and breakthroughs; and more
by the defense department. While such technique may recently, several other authors have suggested additional
work well on a standard, less risky program, its use in frameworks in an attempt to categorize and distinguish
MCO only complicated things since the program was far between different project types [7,23,10,34,3]. Notably,
from being standard, with its high levels of uncertainty, much of this literature was focused on a single industry
complexity, and risk. and often on small projects [47,48]. Finally, the Project
To lower technological uncertainty, MCO tried to use Management Institute (PMI) has recognized the need for
many subsystems, including computers, attitude control, identifying unique and project-specific project management
and propulsion technology from previous programs such principles for different project types, particularly with the
as Mars Global Surveyor. As it turned out, the dependence development of government, Department of Defense, and
on these systems eventually became a contributing factor to construction extensions to the Project Management Body
the failure of MCO. Inheriting subsystems from previous of Knowledge (PMBOK") [49–51].
missions, allowed for a reduction in time, cost, and uncer- To summarize some of the existing frameworks, Table 1
tainty in development, but it did not reduce the need for presents a collection of noteworthy studies that have
elaborative integration of such inherited subsystems. attempted to theoretically ground a classification, categori-
Indeed, the root cause of MCO’s failure as stated by the zation, or framework system for project management.
Mishap Investigation Board (MIB) was related to model- While not all studies mentioned are empirically based,
ing of the spacecraft’s velocity changes. Inadequate verifi- many of these frameworks were developed independently,
cation and validation of the ground software contributed sometimes under the separate but highly relevant realms
to excessive uncertainty and ultimately to the loss of the of innovation or technology management and often in
spacecraft. ways that were unique to their particular environment
 Author's personal copy

668 B.J. Sauser et al. / International Journal of Project Management 27 (2009) 665–679

Table 1
Studies on project classification, categorization, typology, and frameworks.
Author(s) (Year) Study description Findings
Peart [1] Observed many organizations, in order to understand their Reported that most projects use unique numbering systems.
reporting and assessment of information on past projects Categorization can be further sub-divided into contract type, or
similar sub-categories
Henderson and Demonstrated that the traditional categorization of innovation Presented a 2 ! 2 matrix that indicated four categorizations of
Clark [4] as either incremental or radical was incomplete and potentially innovation, and distinguish between the components of a
misleading product and the way they are integrated into the system that is
the product architecture
Bubshait and Selen Developed a relationship between the number of project Indicated a positive relationship between the number of project
[7] management techniques used and selected project management techniques used and the level of complexity
characteristics involved in the project
Clark and Fujimoto Described the various rationales for project organization and Specify the significance of ‘‘heavy-weight” project management
[8] structures structures in the automotive industry
Turner and Grouped projects based on how well defined both the goals Proposed that projects be classified using a 2 ! 2 matrix and a
Cochrane [10] and the methods are for achieving them definition given of all four types with three breakdown
structures
Lindvist et al. [21] Used a case study methodology to demonstrate how a project Suggested a model identified by four different project
typology model can detect error in a systematic complexity organization logics related to the importance of ‘technological’
context aspects of the project context
Payne and Turner Tested the hypothesis that it is better to use a single approach Showed that people more often report better results for their
[22] to managing all projects projects when they tailor the procedures to the type of project
they are working on, matching the procedures to the size of the
project, or the type of resources working on the project
Floricel and Miller Described a conceptual framework for project strategy systems Showed that high project performance requires strategic
[23] systems that are both robust with respect to anticipated risks
and governable in the face of disruptive events
Shenhar [27]; Showed how different projects are managed in different ways Proposed a four-dimensional categorization tool based on
Shenhar and and proposed a multidimensional categorization scheme for novelty, complexity, technology, and pace (NCTP) for adapting
Dvir [30,31] projects the proper managerial style to the specific needs of a project
Lewis et al. [32] Explored the nature, dynamics, and impacts of contrasting Found that styles can differ but are interwoven to monitoring,
project management styles with a conceptual framework evaluation, and control activities; use of these activities
fluctuates over time; blend of styles enhances performance; and
uncertainty moderates project management–performance
relationships
Youker [34] Contends that the most important and useful breakdown of Suggested that projects grouped based on their product bear
project type is by the product or deliverable of the project highly similar characteristics, and therefore require similar
approaches
Terwiesch et al. [5] Demonstrated a classification model for determining Presented a model that allows for determining best project
alternative strategies based on the adequacy of information in planning approaches while distinguishing among project
concurrent engineering activities strategies and reasons for choosing them
Pich et al. [3] Identify three fundamental project management strategies Present a four quadrant model based on these three strategies
related to information adequacy (uncertainty): instructionism, that determines a project’s style and approach
learning, and selectionism
Archibald and Developed of a practical scheme for categorizing projects with Proposed a project categorization and sub-categorization based
Voropaev [38]; similar life cycle phases and one unique process management on end product or service of the project
Archibald [37] process
Crawford et al. [41] Identified a system for categorizing projects to determine their Two hierarchically ordered presentations resembling a decision
purposes and attributes tree. The first presents the multiple organizational purposes
served by such systems and the second presents the many
different attributes or characteristics organizations use to divide
projects into groups or categories

[52]. Collectively, the research represented in Table 1 sug- industry type; Bubshait and Selen [7] examined the rela-
gests that not all projects are the same, nor should they tionship between project characteristics and management
be managed in the same way. The following discussion is techniques and presented a categorization where projects
a brief summary of some of these studies. are grouped based on industry sector and application area;
One of the early writers in this area was Peart [1], who Turner and Cochrane [10] proposed a categorization
observed that many organizations, in order to better facil- matrix that the authors theorized provided a benefit to
itate reporting and access information on past projects, use practitioners in selecting start-up and management tech-
numeric tagging systems; Henderson and Clark [4] pro- niques; Lindvist et al. [21] used a case study methodology
posed a four factor framework for defining innovation to demonstrate how a project typology model can detect
and how this impacts an organization, independent of error in a systematic complexity context; Payne and Turner
 Author's personal copy

B.J. Sauser et al. / International Journal of Project Management 27 (2009) 665–679 669

[22] showed that people more often report better results for This selection was based on the following criteria: First,
their projects when they tailor the procedures to the type of unlike most categorization systems, these theories go
project they are working on; Floricel and Miller [23] were beyond just a classification system. They actually discuss
some of the first to present a categorization of projects a preferred management approach for different project
based on their strategic perspective; Shenhar and Dvir types. Second, they present potential causes for failure in
[27,30,31] developed a typological theory of project man- case of an incorrect classification. Third, all three are based
agement and a four dimensional framework for project on extensive empirical research and supportive data.
analysis; Lewis et al. [32] proposed a framework that Fourth, these frameworks provide richer insights to man-
showed that project management styles fluctuate over time agers and researchers about the complexities and difficul-
and blending of styles enhances performance; Youker [34] ties of modern projects. Finally, these three frameworks
suggested that the most important and useful breakdown have only a minimal amount of overlap, which potentially
of project type is by the product or deliverable of the pro- enables distinct and different points of view. For example,
ject; Archibald and Voropaev [38] claimed that project cat- Henderson and Clark, while fundamentally about innova-
egories and sub-categories serve an essential part in project tion, focuses on the management of the technical complex-
portfolio management processes; Pich, Loch, and De ities of product development, fundamental to and often
Meyer [3] demonstrated a strategy model based on com- overlooked in project management; Shenhar and Dvir
plexities and uncertainties of information; and Crawford add additional dimensions to the concepts of Henderson
et al. [41], studied project categorizations and their pur- and Clark of complexity, pace, and novelty (market uncer-
poses and attributes, as used by companies around the tainty); and Pich, Loch, and De Meyer address the more
world and proposed a framework for determining a project recently accepted dimension in successful project manage-
management categorization system. ment of strategy. Table 2 includes a summary of the con-
The diversity of project management frameworks as cepts of these frameworks, and indicates the strengths
depicted by Table 1 demonstrates, perhaps, that there is and weaknesses of each one. In the following sections we
currently no accepted common framework to address and will further describe these frameworks in detail and discuss
analyze project contingencies. In fact, as claimed by Gati- how they may contribute to the understanding of project
gnon et al. [53] there is still substantial empirical confusion failure based on a contingency approach.
on the effects of different kinds of innovation on organiza-
tional outcomes. Furthermore, while most organizations 4.1. Henderson and Clark’s framework for innovation and
use a project classification or categorization system [41], change
not may of these systems are based on rigorous empirical
research. According to Henderson and Clark, products are com-
As mentioned, the objective of this paper is to apply a posed of core technology components and their linkages
diversity of project management contingency frameworks (architecture). They argue that different types of techno-
for the study of a project failure (i.e. MCO) to reveal logical change have fundamentally different organizational
how applying different contingency approaches may pro- consequences. Fundamental to Henderson and Clark’s
vide deeper insights in the analysis of project success and framework for innovation is the distinction between the
failure, and lead to additional questions for future research relationships between the components and the architec-
and challenges in project management. To achieve this ture. This distinction requires two types of knowledge:
objective we selected three of the frameworks in Table 1 component knowledge and architectural knowledge
– Henderson and Clark’s [4] framework for the analysis (knowledge on how the components are integrated). With
of innovation, Shenhar and Dvir’s [27,30,31] NTCP contin- this fundamental distinction, they have theorized a frame-
gency framework for project classification, and Pich, Loch, work that classifies innovation on two dimensions (see
and De Meyer’s coping strategies model for uncertainty [3]. Fig. 1).

Table 2
Strengths and weaknesses of the three frameworks.
Henderson and Clark Shenhar and Dvir Pich et al.
Key concept Categorization based on components of Categorization based on initial Project as a payoff function that depends on the
a product and the way they are characteristics of project on adequacy of information to choose an appropriate
integrated into the system independent dimensions project strategy and infrastructure
Dimensions Component technology and linkages Novelty, technology, complexity, Learning and selectionism
pace
Strengths Simple 2 ! 2 model; clear identification Context-free categorization to Simple 2 ! 2 model; focus on process of reducing
of product uniqueness select the right project uncertainty and learning
management style
Weaknesses Static model, no specific indication of Complex model, with many No specific focus on other managerial issues such as
project process possible classifications scheduling, budgeting, etc.
 Author's personal copy

670 B.J. Sauser et al. / International Journal of Project Management 27 (2009) 665–679

Core Concepts on the projects technical evolution, organizational

Reinforced Overturned experience, recurrent tasks, and technical knowledge
Incremental Modular
as they relate to component knowledge and less
Linkages Unchanged Innovation Innovation impact on product architecture and communication
between Core
channels as they relate to component linkages.
Concepts and Architectural Radical
Components Changed Innovation Innovation
(d) Architectural innovation (e.g., the introduction of a
portable fan) influences a project’s knowledge of link-
Fig. 1. A framework for defining innovation [4].
ages between core concepts and components. This has
an impact on the projects technical evolution, organi-
The two dimensions in Fig. 1 represent the usefulness of zational experience, recurrent task, and technical
the knowledge of an organization. The horizontal dimen- knowledge as they relate to the component linkages
sion captures an innovation’s impact on components and in addition to the product architecture, communica-
the vertical dimension captures innovation’s impact on tion channels, and problems solving strategies.
linkages or integration between components. Based on this
framework, a classification is then related to an organiza- The importance of Henderson and Clark’s work to pro-
tion’s existing architectural and component knowledge. ject management is in the realization that in addition to
These individual innovation dimensions are defined as: new technology, the understanding the interplay among
modules, subsystems and systems is greatly important to
(a) Radical innovation (e.g., changing from a ceiling fan the success of projects.
to a central air conditioning system) influences an
organization’s existing project management capabili- 4.2. Shenhar and Dvir’s NTCP diamond framework
ties, requiring greater attention to a project’s knowl-
edge of core concepts and linkages between these core Extending classical contingency theory to projects,
concepts and components. This significantly impacts Shenhar and Dvir suggested a ‘‘Diamond Typology” based
a project’s technical evolution (e.g., design cycles, on four dimensions, novelty, technology, complexity, tech-
experimentation, product design), recurrent tasks, nology, and pace (NTCP) [54,30,40,27]. This typology
organizational experience, information processing, assesses the product, the task, and the environment, and
product architecture, problems solving strategies, suggests what may be the optimal project management
and communication channels. style that would fit a project type. Table 3 describes the
(b) Incremental innovation (e.g., improvements in blade four dimensions, and Fig. 2 shows how they are described
design or the power in the motor) has a minimal in a diamond-shaped graph that represents of the level of
impact on an organization’s standard project man- risk associated with a project.
agement operations and requires no advanced knowl-
edge of core concepts or component linkages. 4.3. Pich, Loch, and De Meyer’s coping strategies model
(c) Modular innovation (e.g., replacing an electric motor
with a solar powered motor) influences a project’s Mihm, Loch, and Huchzermeier [55] have shown that
knowledge of core concepts. This has the most impact executing projects requires an aptitude to coordinate multi-

Table 3
NCTP model definitions.
The NTCP model
Novelty: The product newness to the market and the customers. It has an impact Technology: The extent of new technology used. It impacts product
on product requirements definition and market related activities: design, development, testing and technical skills needed:
– Derivative: Improvement in an existing product (e.g., a new color option in a – Low-tech: No new technology is used (e.g., house; city street)
MP3 player; the addition of a search feature in a software program) – Medium-tech: Some new technology (e.g., automobile;
– Platform: A new generation on an existing product line (e.g., new automobile appliances)
model; new commercial airplane) – High-tech: All or mostly new, but existing technologies (e.g.,
– Breakthrough: A new-to-the world product (e.g., the first Post-it Note; the first satellite; fighter jet)
microwave oven) – Super high-tech: Necessary technologies do not exist at project
initiation (e.g., stealth bomber; Apollo moon landing)
Complexity: The location of the product on a hierarchy of systems and Pace: Project urgency and available timeframe. It impacts time
subsystems. It impacts to coordination, organization and formality of project management activities and team autonomy:
management: – Regular: Delays not critical (e.g., community center;)
– Assembly: Subsystem, performing a single function (e.g., CD player; cordless – Fast-competitive: Time to market is important for the business
phone) (e.g., satellite radio; plasma television)
– System: Collection of subsystems, multiple functions (e.g., spacecraft; cars) – Time-critical: Completion time is crucial for success-window of
– Array: Widely dispersed collection of systems with a common mission (e.g., opportunity (e.g., mission to Mars; Y2K)
New York transit system; air traffic control) – Blitz: Crisis project- immediate solution is necessary (e.g., Apollo
13; September 11, 2001)
 Author's personal copy

B.J. Sauser et al. / International Journal of Project Management 27 (2009) 665–679 671

complexity increases, different approaches are needed.

When information is lacking (or changing) and when prob-
lems become complex, a ‘‘selectionism” and learning strat-
egy is needed instead. They have established a terminology
and framework to determine the sufficiency of available
information, choose the appropriate combination of strat-
egies, and set a supporting project infrastructure for plan-
ning, coordination, incentives, and monitoring. Fig. 3
shows the four-quadrant strategy framework for coping
with uncertainty.

5. Our methodology

A descriptive case study research methodology was cho-

sen. It allowed for the characterization of real-life events,
Fig. 2. NTCP framework. such as organizational and managerial processes, and there
was no requirement for control over behavioral events,
ple organizations in parallel (e.g., concurrent engineering) thus allowing for the capture of holistic and significant
and the ability to deal with the uncertainty of events or experiences [2,56,57]. Eisenhardt [2] described a fundamen-
influences. To address the ambiguity between complexity tal difference in case study research as compared to exper-
and uncertainty, Pich, Loch, and De Meyer [3] have devel- imental research and suggested that cases should be chosen
oped a time-dependent model for determining strategies for theoretical reasons, not statistical reasons. Case study
based on coping with uncertainty in terms of information research provides a conduit to go from theory to data
adequacy. As projects increase in complexity, there is an and back to theory. To address any threats to validity as
increase in ambiguity of the information that may influence defined by Yin [57], multiple sources of evidence should
a project and create an environment that goes beyond the be supported by data source triangulation [57–59], and a
capabilities of the project team. In complex projects, Pich, study protocol has to be established for future replication
Loch, and De Meyer contend that tasks are interdependent and to reduce any bias in the collection of data. To some
and coordinated in parallel; therefore, engineers cannot extent, our study followed Eisenhardt’s [2] recommended
afford to wait for complete information, and will often con- steps for such studies as described in Table 4.
tinue through the project lifecycle while coordinating these
activities with preliminary and ambiguous information. 6. Framework analysis
Project teams must ‘‘actively incorporate” new information
and re-plan a project in relation to new activities or policy In this section we analyze the MCO program using the
that require the team to be flexible. three contingency theory frameworks that we selected. Both
Pich, Loch, and De Meyer contend further that tradi- projects (MCO and MPL) used a single project budget with
tional project management that structures all projects the extreme managerial pressures for low cost and timely deliv-
same assumes adequate information, which is handled by ery. The MCO project manager would later state, ‘‘There is
what they call an ‘‘instructionist strategy,” when no learn- a fine line between success and failure in these one-of-kind
ing is needed or takes place and simple problems allows for missions.” Analyzing the MCO project with these frame-
an optimized solution. They showed how this does not works demonstrates how the challenges imposed upon the
work in modern project management and as a project’s project were perhaps impossible to achieve. Indeed, man-

Optimization Selectionism

Learning Strategy Learning and Selectionism

Learn about unforeseen uncertainty Project may be stopped based on favorable progress
Learning Learn about complex causal effects of another candidate
Discover new discernable patterns Exchange information among candidates to increase
Respond to new event; original problem solving learning: candidate projects become complements

Instructionist Strategy Selectionist Strategy

Decision adequate causual mapping Plan multiple trial projects
No Include buffers in plan Performance of trial projects versus hurdles
Learning Plan project policy Variants selected by complex environment
Monitor project influence signals Variants selected after catastrophic unforeseeable
Trigger contingent action events

Fig. 3. Strategies for coping with uncertainty [3].

 Author's personal copy

672 B.J. Sauser et al. / International Journal of Project Management 27 (2009) 665–679

Table 4
Study design as defined by Eisenhardt’s recommended steps [2].
Eisenhardt’s recommended steps Study design
(1) Define research question with a priori constructs Using constructs from the literature, a research question was defined: ‘‘Can
contingency theory provide new insights for explaining project failure”
(2) Select case(s) based on specific population and sampling to replicate or MCO was used as the sample case because it represented the rise and fall of
extend emerging theory FBC, was well documented for its success and failure, and although it was
well known in the public and the scientific and engineering communities for
its failure, major questions remained, which could be summarized as; ‘‘How
could this happen?”
(3) Craft instrument to promote triangulation among data sources and Data Collection Plan:
investigators Interviews: Interviews were planned in a semi-structured, open-ended
conversational format, which included only leading questions such as ‘‘tell
me about . . .” Interviewees were allowed to speak freely and openly about
their experiences. Six key personnel related to the project were interviewed.
These people represented program management, project management,
systems engineering, team members, and customer. Notes were taken during
the interview, which had also been recorded and transcribed
Documentation: Formal studies, evaluations, journal articles, survey data,
mass media, and physical artifacts (samples of work done)
Archival and Historical Information: Letters, memoranda, policy statements,
regulations, proposals, guidelines, procedures, summary reports,
organizational records, and personal records
Participant Observation: NASA gave permission for participation of our
researcher in its advanced project management classes to gain further
familiarity with NASA’s culture and procedures
(4) Enter field in such a way as to overlap data collection analysis Data was collected in an iterative process; documentation and archival
information was extensively analyzed before interviews were conducted;
collected verbatim transcriptions; after each interview, data was compared
against documentation and archival information to determine if additional
data was needed from any data sources (e.g., follow-up interviews,
additional documentation) before the next interview was conducted
(5) Analyze data within and across case(s) A 40 page case summary was written based on a predetermined case format
[6]. Once the case study was completed, the data was coded and analyzed
using the three previously described frameworks. A second analysis report
of 30 pages was then prepared
(6) Shape hypothesis by looking for replication not sampling logic; As the analysis with each framework unfolded, the investigators conducted
iterative tabulation of evidence for each construct; refine definition of numerous discussions, which created new insights and required additional
constructs analysis to shape the emerging relationships between constructs and
establish theoretical statement(s)
(7) Enfold literature by comparing results with conflicting and similar Compared our conclusions based on the three frameworks with an extensive
literature review of the literature on contingency theory for project management and
frameworks for project management
(8) Reach closure about when to stop iterating between theory and data Once the final analysis was completed, a final iteration was performed to
develop and refine the final theoretical statements about the findings and
conclusions

agement later admitted to compromising key issues as a in an established product. While Lockheed-Martin and
result of these pressures. It seems that success in this project JPL were well-established firms with long histories of space
may have been impossible to achieve under the combined exploration success, according to Henderson and Clark,
requirements of FBC and high project risk. even established firms often have difficulty in adapting to
architectural innovation. The architectural knowledge of
6.1. Henderson and Clark’s framework for innovation this type of innovation often involves subtle challenges
and difficulties in recognizing what is and is not required
Our analysis of MCO using Henderson and Clark’s when applying new knowledge.
framework, classified MCO as an architectural innovation In addition to the architectural change, MCO also had
[4]. Much of the technology or concepts for MCO were to implement the BFC approach as a new way of doing
borrowed from previous missions like Mars Global Sur- business. NASA at that time had no clear guidelines or
veyor and the failed Mars Observer. While the technology standard protocol on how to perform FBC missions. In
or core design concepts were considered proven, the link- an architectural innovation, this creates an environment
ages or architecture of the design were new. With minor that the organization has to determine what core design
changes in components (e.g., navigation system), it created concepts must remain, and be wary of what it believes is
new interactions and new linkages with other components not relevant but may actually hinder the organization.
 Author's personal copy

B.J. Sauser et al. / International Journal of Project Management 27 (2009) 665–679 673

Typically, there are two key concepts for understanding (both formal and informal). For any NASA mission this
the ways in which components and architectural knowl- represents the communication between elements, the for-
edge should be managed within an organization. The two mal review process, the technical review process, and the
concepts are summarized in Table 5 with a representative interaction with subject matter experts. For MCO, commu-
statement of how MCO misrepresented these concepts. nication between project elements was perceived by most to
The first concept is that of dominant design. According be inadequate. There was a lack of early and constant
to Henderson and Clark, ‘‘emergence of a dominant involvement of team members and the communication
design, which signals the general acceptance of a single lines, as identified by the MIB, were not open for real-time
architecture, firms cease to invest in learning about alterna- decision-making. MCO followed the standard NASA tech-
tive configurations. . . New component knowledge becomes nical review and approval process, but there were no ade-
more important than new architectural knowledge. . . Suc- quate resources to support this processes. A project
cessful organizations therefore switch their limited atten- manager stated, ‘‘It was mandatory that we cut corners,
tion from learning a little about the many different . . .. It was mandatory that we didn’t get a second set of eyes
possible designs to learning a great deal about the domi- on everything we needed to. Otherwise we could have never
nant design.” Since the contract called for the development met the cost goals.”
of eight Mars exploration spacecraft, Lockheed-Martin Some of the most recognized experts in deep space
believed that duplicating much of the dominant design of exploration are employed by JPL. The use of subject mat-
the successful and already in progress, would allow for ter experts can validate requirements to which a design is
reduced development time and the need for acquiring built. The MIB contends that this internal expertise and
design knowledge. capability was not effectively utilized. Also, an organiza-
The consequences of MCO’s early decisions to fully tion’s architectural knowledge is usually rooted in these
commit to this dominant design were reflected in the ulti- channels, filters, and strategies, and the discovery process
mate technical failure – the integration of the navigation usually takes time, which MCO had very little. Therefore,
system. Some of the people working on the navigation sys- the organization may be attracted to modifying channels,
tem were working halftime on MCO and halftime on filters, and strategies that already exist. For MCO, not only
another project. These people would be working the same some of the components were new, but as mentioned, also
type of subsystem for each project while the process in each FBC was still an unproven way of doing business. NASA,
project was different. This was identified as causing confu- at that time, was clearly still pushing the envelope. As Dan
sion for the engineers, and resulted in engineers applying Goldin, former NASA administrator said after the failure
the wrong process to MCO. The use of the navigation sys- of MCO, ‘‘We pushed the boundaries like never befor-
tem on MCO was the introduction of a new subsystem to a e. . .And had not yet reached what we thought was the lim-
dominant design. A challenge with architectural innovation it” [60].
is that new linkages are much harder to identify since the In summary, Henderson and Clark defined two prob-
core concepts of dominant design are unaffected. The lems created by architectural innovation. They are: (1)
recourse of this is that organizations mistakenly believe established organizations require significant time (and
that they understand the new technology. resources) to identify innovation as architectural, since
The second key concept in addressing architectural architectural innovation can often initially be accommo-
innovation is that of organization’s building knowledge dated within old frameworks, and (2) the need to build
around the recurrent task through communication chan- and apply new architectural knowledge effectively. Table
nels, information filters, and strategies. Henderson and 6 depicts the sources of problems created by architectural
Clark state, ‘‘The strategies designers use, their channels innovation, the problems they create, and how these prob-
for communication, and their information filters emerge lems were reflected in MCO. Based on this analysis our
in an organization to help it cope with complexity.” Com- conclusion is that MCO was indeed an architectural inno-
munication channels are related to an organization’s inter- vation, but was it treated as an incremental innovation.
actions within the organization that are critical to its task Henderson and Clark assert that in architectural innova-

Table 5
Concepts in the way architectural innovation is managed.
Architectural innovation Mars Climate Orbiter
Dominant design: signals the general acceptance of a single architecture Inheritance from past systems was assumed to reduce uncertainty, but it did
and product technologies do not emerge fully developed at the outset of not reduce the uncertainty of integration
their commercial lives
Organizations build knowledge and capability around the recurrent task The Mars Program Independent Assessment Team stated that there were
that they perform inadequate resources to accomplish the requirements. NASA Headquarters
had applied pressure on JPL and Lockheed-Martin to be successful with
the concern for loss of business this resulted in knowingly cutting proven
engineering practices to meet the cost and schedule demands
 Author's personal copy

674 B.J. Sauser et al. / International Journal of Project Management 27 (2009) 665–679

Table 6
Problems in architectural innovations.
Sources of problems Problems created Mars Climate Orbiter
Established organizations require significant Information that might warn the organization MCO required a significant level of insight and
time (and resources) to identify innovation as that a particular innovation is architectural may creativity both technically and managerially,
architectural, since architectural innovation be screened out by the information filters and built around a core of talented, experienced
can often initially be accommodated within communication channels that embody old people, but cost constraints forced these
old frameworks architectural knowledge. The company may requirements to be compromised
mistakenly believe that it understands the new
technology
The need to build and to apply new architectural Simply recognizing that a new technology is When MCO started, they attempted to embrace
knowledge effectively architectural in character does not give an the reduction in policy and procedure of FBC,
established organization the architectural but NASA provided little guidance on what
knowledge that it needs. It must first switch to a policy was critical for FBC success
new mode of learning and then invest time and
resources in learning the new architecture

tion, ‘‘established organizations may invest heavily in the 6.2.1. Novelty

new innovation, interpreting it as an incremental extension Novelty is related to a product’s uniqueness to the mar-
of the existing technology or underestimating its impact on ket and uncertainty in requirements. Although NASA had
their embedded architectural knowledge.” been successful with missions to Mars (e.g., Mariner, Vik-
ing I and II, Mars Global Surveyor, and Mars Pathfinder)
6.2. Shenhar and Dvir’s NTCP framework not one successful mission had been repeated, and each
mission had a great degree of unproven mission require-
In our analysis of MCO with Shenhar and Dvir’s NTCP ments. Furthermore, four of the seven Mars missions since
framework [24,40], we tested whether the project type Viking – Mars Observer, MCO, MPL, and Deep Space 2 –
was consistent with the actual project management have failed. Thus MCO had to be treated as a break-
approach on the four dimensions of the model. Fig. 4 rep- through project. Yet, MCO believed that they were build-
resents the analysis of MCO based on these dimensions. It ing upon the success and technology of past missions and
also presented the difference between the preferred style approached this project more as a platform project. This
and the actual style. As seen in Fig. 4, our analysis suggests gave the perception that MCO would be a next generation
that MCO had to be managed as a breakthrough, high- in existing set of missions. Fast prototyping, one of the
tech, system, and time-critical project. While the project requirements Shenhar and Dvir define as important for a
was clearly focused on meeting the time-critical mission, breakthrough project, was compromised by inadequate
we found that the project management had difficulty testing and streamlined reviews. For example, the naviga-
in the other dimensions – novelty, technology, and tion software system was the most novel and uncertain of
complexity. all the systems on MCO, but it received no more testing
or review than any other system. In addition, the interac-
tion with customers was less than optimal and was some-
times defined as ‘‘confusing.” A senior manager said,
Technology ‘‘We were ‘lean and mean’ at the time. We essentially
Super had no checks and balances on the program as we do
Mars Climate Orbiter High
Tech today. I could not possibly execute that program under
High
Tech
the environment that we live in today.”
Medium
Tech
6.2.2. Technology
Complexity
Breakthrough Platform Derivative Although some of the technology on MCO had been
-
Assembly System Array
developed prior to the project’s inception and building an
Novelty Regular -
orbiter spacecraft was not new, MCO was the first of its
Fast/Competitive
Time-Critical
kind in integrating all these technologies into one space
Blitz
vehicle. For example, MCO combined two different instru-
ments: a pressure modulator infrared radiometer to pro-
Pace
vide detailed information about Mars’ atmospheric
temperature, dust, water vapor, and clouds, and a Mars
Fig. 4. NTCP classification of MCO. The solid line represents the color imager that would observe the interaction between
preferred classification for MCO and the dashed line represents the actual
approach. While there is not a linear relationship between the area of the
the atmosphere and the surface of the planet. One can thus
diamond for correct and incorrect project risk, it does represent a conclude that MCO was a high-tech project. Shenhar and
qualitative difference in the degree of risk. Dvir describe a high-tech project as requiring long periods
 Author's personal copy

B.J. Sauser et al. / International Journal of Project Management 27 (2009) 665–679 675

of design, development, testing, and redesign with multiple design in response to these observed events. Pich, Loch,
design cycles. With the extensive testing that is required for and De Meyer state that project managers have to plan
a high-tech project like MCO, in-depth, technical reviews for variation or they will resort to ‘‘firefighting” to keep
are mandatory, and in conjunction with these reviews, a project on target, which becomes an exhaustion of
communication has to be frequent and active. However, resources. Because the coping strategy model deals with
the pressures, constraints, and challenges to push the adequacy of information, uncertainty can be defined by
boundaries of FBC on a limited budget restricted MCO’s the knowledge of the problem solver as well. That is, do
ability to fully recognize its technological challenges, thus they understand the structure of the problem, but lack
MCO was managed more as a medium-tech project. There the knowledge concerning the value of its variables? In a
was not enough testing, reviews, communication, technical learning strategy a project manager will increase testing
skills, or flexibility for design changes to manage a high- and implement training of inexperienced engineers to
tech project. Many of these key elements were reduced to address future uncertainty.
meet cost and schedule constraints, while some were just One of the uncertainties for MCO involved the software
overlooked. related to the navigation system. Limited actions were
taken to understand such uncertainties. Indeed, in retro-
6.2.3. Complexity spect, inadequate verification and validation of the soft-
As a complex collection of interactive elements and sub- ware contributed to loss in performance. Post failure
systems, jointly dedicated to a wide range of functions to analysis indicated that an extensive testing program should
meet a specific operational need, MCO was a system pro- have been implemented to fully integrate the navigation
ject. As the first in a series of Mars missions, MCO was software. But MCO could not afford a learning environ-
to integrate some mature technology into a new and ment and thus relied on inheritance of technology. While
untested spacecraft. In addition to its own complexity, inheritance allows for a reduction in the time, cost, and
MCO was designed to work with the Mars Polar Lander effort in technology development, it does not reduce the
when it arrived at Mars. MCO had multiple key customers uncertainty associated with the integration of inherited
from industry, public, government, and the scientific com- components.
munity that were all vested in MCO’s development and In an instructionist strategy, a project assumed to exhi-
success. As a system project, MCO required extensive inte- bit very little uncertainty and there is typically no competi-
gration of hardware and software, hundreds or thousands tion of alternate solutions, which can respond to an
of activities, tight and formal control, financial and sche- environment that is amenable to change. Sometimes in an
dule issues, reviews with customers and management, and agile instructionist strategy, a project will allow some
extensive documentation. Unfortunately, cost constraints degree of variation up to a certain threshold, and then only
limited control of subsystem integration and there was an respond when the threshold is crossed. For MCO, there
absence of end-to-end verification and validation, key in was not much flexibility to begin with, and although the
a systems classification. While much of the project was project approached the development as a series of itera-
treated as a system, certain subsystems with high levels of tions, there was no true modularity in the design. This
uncertainty were managed as assembly projects (i.e. navi- was evident in the decisions to use much of the science from
gation), and key people were balancing time with multiple the failed Mars Observer, and to award a contract for
projects. This was compounded by a lack of communica- spacecraft development that would result in up to eight
tion and transition between phases and subsystem opera- identical spacecraft. A contractor program manager said
tions. Key to any system is an understanding of the that the potential success of MCO could have been judged
impact change and risk has on any subsystem. To treat falsely had it worked on Mars and got tremendous science
any part of a system as an assembly is to treat the entire results. ‘‘If MCO had been successful and MPL had failed,
system as an assembly. you would say 50/50, we got one out of two. Faster, better,
cheaper approach can work and you would cruise on. . . [to
6.3. Pich, Loch, and De Meyer’s coping strategies model the next identical crafts]. So the failures said to people,
Whoa, this faster, better, cheaper, is not all that it is
Understanding MCO’s failure with Pich, Loch, and De cranked up to be, at least not the way we are trying to
Meyer’s [3] uncertainty coping strategy model suggests yet implement it.”
another perspective. Since MCO faced extensive uncertain- Pich, Loch, and De Meyer state that the challenge of
ties, we believe that a learning strategy would have been many projects is finding a balance between planning and
appropriate for managing the program. However, the chal- learning. While the two require distinct management styles
lenging environment of FBC, administrative pressures, and and infrastructure, it is the balance that can have great
resource restrictions forced the management team into an impact on project success. For MCO the cost of duplica-
instructionist strategy. tion should have been less than the cost of starvation,
A learning strategy is based on signals that come from because for a Mars exploration project, starvation means
incongruence with a project team’s calculations, and which termination and rarely do projects that are put on hold
can allow for the modification of policy, practices, and get done later. A second project manager stated that when
 Author's personal copy

676 B.J. Sauser et al. / International Journal of Project Management 27 (2009) 665–679

Optimization Selectionism

Learning Strategy
The Mishap Investigation Board stated that the navigation
Learning team was inadequately trained, did not understand the Learning and Selectionism
spacecraft, and did not pursue known anomalies.

Instructionist Strategy
There was a heavy reliance on the inheritance of
technology from previous missions. MCO used many
No
subsystems, computers, attitude control, and propulsion
Learning technology from other missions, but the project manager
Selectionist Strategy
stated that the dependence on these systems eventually
became a contributing factor in the loss of the MCO.

Fig. 5. MCO strategies for coping with uncertainty.

he entered the project around critical design review ‘‘they novelty, technology, and complexity. Pich, Loch, and De
had excessive hardware development problems and Meyer’s model illustrated that an incorrect strategy of
extreme weight challenges, which meant a lot of new devel- learning was used to deal with highly uncertain and com-
opment. This became very difficult on an already bare plex information. As valuable as information flow and
bones budget. . . Don’t you dare go back to headquarters quality is in an organization, there is limited focus on many
and ask for more money because you are not going to other key managerial issues.
get it. . . [although] I had strong company backing because Collectively, these frameworks showed that an incorrect
this was important in getting us back into the Mars busi- perception of MCO’s difficulties resulted in an improper
ness.” But the backing did not come in resource managerial approach, and they provided a rigorous way
allocations. to analyze a failed project to explain the failure in more
In summary, MCO used an instructionist strategy when depth than before. But more importantly, these frame-
a learning strategy would have been more effective consid- works provided a strong support for the strategic impor-
ering the lack of knowledge and experience, the resource tance of an upfront identification of the right approach
constraints on testing, and the need for emergent behavior to any project, with the ability to predict potential difficul-
to cope with unforeseen uncertainty. The two coping strat- ties if such approach is not selected.
egies are summarized in Fig. 5 with a representative state- In summary, the three frameworks revealed that an
ment of how MCO expressed these concepts. incorrect approach was used in managing the MCO pro-
ject, which led to its failure and reaffirmed that it was
6.4. Comparing the analysis based on the three frameworks impossible to succeed under the project’s given constraints.
MCO affirmed that an attempt to use the FBC approach
Based on our analysis we may conclude that the failure within an organization that was built for taking high-level
of Mars Climate Orbiter was managerial, not technical. In risk is doomed to fail when the organization sacrifices its
retrospect, management did not (or could not) correctly previous practices, which were designed to address such
appreciate the level of complexity, uncertainty, and time high-levels of risk in the first place. Indeed, this finding
pressures involved with MCO. With a new mindset of ‘bet- reinforces the view that perhaps FBC cannot be used in
ter faster cheaper’ at NASA’s executives assumed that cases of extremely high risk [61,62]. In retrospect, one
some previous successes indicate that such policy could should note that NASA, as an organization dealing with
work for all projects. Yet some projects are always more extreme risks, has not been immune to managerial chal-
uncertain, more risky, or more complex than others, and lenges and failures (e.g., Space Shuttle [61–66], Hubble
such constraints may not work for the every case. The [67], scram jet [68], and numerous others [69]). The analysis
assessment of MCO with the selected three frameworks of MCO under the FBC policy may provide some sugges-
verified this both in their independent and collective tions on how to deal with some of this risk in future
assessment. programs.
Independently, the selected three frameworks gave us
different prospects on the managerial issues. Henderson 7. Conclusion
and Clark’s framework revealed problems and cautions
that can result from an architectural innovation that was 7.1. The contingency approach and future research
overlooked because of organizationally imposed con-
straints. Alternatively, it was not able to give any specific Project management research is still in its early stages.
indication of what would be project success. Shenhar and While much research has been devoted to critical success
Dvir’s NTCP framework showed a misfit between project factors, not many studies have been focused finding alter-
type and project management style on three dimensions, native frameworks that allow us to understand why pro-
 Author's personal copy

B.J. Sauser et al. / International Journal of Project Management 27 (2009) 665–679 677

jects fail and what can be done about it. This study showed developing their own organization-specific frameworks for
that project management contingency theory can provide project categorization and teach project managers how to
new insights for a deeper understanding of project failure, adopt the right approach to the right project. A possible
but more importantly, it suggests implications for addi- way to approach this is using Crawford, Hobbs, and
tional theory development in project management. First, Turner [41], distinction between two types of categoriza-
it established a new and different direction for further stud- tion systems, doing the right project (strategic alignment)
ies of project success and failure beyond traditional success and doing the project right (capability alignment). Doing
factors. Furthermore it can stimulate additional success the right project will be used for project selection and port-
and failure studies by identifying specific contingency the- folio management and doing the project right will be used
ory success factors [70]. Second, this study provided for adapting project management to specific project type.
another demonstration that ‘‘one size does not fit all.” In NASA is no exception [71,72]. As this research shows,
studying project success or failure we need not just asking, the agency would greatly benefit from developing its own
‘‘was it good or bad management,” but ‘‘was it the right way for project management categorization and
management to the situation, the task and the environ- adaptation.
ment.” What works well in one situation may not work As with any approach or model, it is not perfect. With
in another. Future investigations could seek additional the frameworks we demonstrated, we are still left with
variables of situation and management and explore richer some key questions unanswered:
and wider opportunities for analyzing the fit of managerial
styles. Third, this paper shows that there is more than one " How do you know when you have correctly classified a
dominant contingency theory. Each of the three frame- project and how can this be verified to some level of
works used have strengths and weaknesses (see Table 2), confidence?
thus, independently they may not be as valuable as they " How do you determine the most effective and efficient
were collectively. Therefore, coming research may continue cost and resources to a project classification?
to identify strengths and weaknesses of existing theories " How can a correct or incorrect classification quantita-
and offer more developed theories that would serve differ- tively correlate to project risk?
ent research goals. Fourth, new and more effective frame- " What is the consistency in using the framework among
works built on a contingency approach may enable different practitioners?
project managers to rely less on heuristics and help estab- " How do you address discrepancies in a classification,
lish a new field of ‘‘project management design.” If we and who is held accountable?
could better understand what works and what does not " What is the significance or impact of an incorrect classi-
in what situation, we may be able to provide the rules for fication on any single dimension?
priory selections of the right approach, thus preventing
failure before it may happen. Defining the project and pro-
viding a fundamental framework for planning and manag- References
ing a project with a correct approach may open up
numerous new directions of research. Finally, while we [1] Peart AT. Design of project management systems and records.
Boston: Cahners Books; 1971.
have used three existing frameworks for analyzing a project
[2] Eisenhardt KM. Building theories from case study research. Acad.
and determining an appropriate management style, these Manag. Rev. 1989;14(4):532–50.
frameworks are clearly not the only ones. Further research [3] Pich MT, Loch CH, De Meyer A. On uncertainty, ambiguity, and
may look into project categorization of other factors such complexity in project management. Manag. Sci. 2002;48(8):1008–23.
as application area (e.g., software, or hardware), client [4] Henderson RM, Clark K. Architectural innovation: the reconfigura-
tion of existing product technologies and the failure of established
and customer (consumer, industrial, and government), geo-
firms. Admin. Sci. Quart. 1990;35(1):9–30.
graphical area, etc. In summary, more research is needed to [5] Terwiesch C, Loch CH, De Meyer A. Exchanging preliminary
better correlate project management categorization systems information in concurrent engineering: alternative coordination
to appropriate management styles and practices or help in strategies. Organ. Sci. 2002;13(4):402–19.
potentially predicting success, or failure, and even provide [6] Shenhar AJ. Real life project analysis – guidelines. Stevens Institute
of Technology; 1999.
warning signals in an on-going project.
[7] Bubshait KA, Selen WJ. Project characteristics that influence the
implementation of project management techniques: a survey. Project
7.2. The contingency approach: potential contributions and Manag. J. 1992;23(2):43–7.
challenges to project management [8] Clark K, Fujimoto T. Product development performance. Boston:
Harvard Business School; 1991.
[9] Griner CS, Keegan WB. Enhancing mission success – a framework
At this stage the current project management practice
for the future: a report by the NASA chief engineer and the NASA
has not adopted an explicit, well-accepted way to identify integrated action team. National Aeronautics and Space Administra-
project uniqueness at project initiation and select the right tion; 2000.
management style. Since almost no project is done in isola- [10] Turner JR, Cochrane RA. Goals-and-methods matrix: coping with
tion and most organizations are involved in more than one projects with lll defined goals and/or methods of achieving them. Int.
J. Project Manag. 1993;11(2):93–101.
project, this suggests that organizations would benefit from
 Author's personal copy

678 B.J. Sauser et al. / International Journal of Project Management 27 (2009) 665–679

[11] The Standish group: the chaos report. West Yarmouth, MA: The [39] Atkinson R. Project management: cost, time and quality, two best
Standish Group International, Inc.; 2001. guesses and a phenomenon, its time to accept other success criteria.
[12] Evans M. Overdue and over budget, over and over again. The Int. J. Project Manag. 1999;17(6):337–42.
Economist; 2005. [40] Shenhar A, Dvir D. Reinventing project management: the diamond
[13] Hammer M, Champy J. Reengineering the corporation: a manifesto approach to successful growth and innovation. Boston: Harvard
for business revolution. New York: Harper Collins; 2003. Business; 2007.
[14] Roush W. R deficit = D inflation. Technology Review, July 27; 2005. [41] Crawford L, Hobbs JB, Turner JR. Project categorization systems.
[15] Tishler A, Dvir D, Shenhar AJ, Lipovetsky S. Identifying critical Newtown Square, PA: Project Management Institute; 2004.
success factors in defense development projects: a multivariate [42] Williams T. Assessing and moving on from the dominant project
analysis. Technol. Forecast. Soc. Change 1996;51(2):151–71. management discourse in the light of project overruns. IEEE Trans.
[16] Zhang L, Lee KO, Zhang Z, Banerjee P. Critical success factors of Eng. Manag. 2005;52(4):497–508.
enterprise resource planning systems implementation success in [43] Sauser BJ. A case study of Mars Climate Orbiter. Hoboken, NJ:
China. In: Proceedings of the 36th Hawaii international conference Stevens Institute of Technology; 2004. p. 1–40.
on systems sciences; 2003. [44] Blake SB. Managing for responsive research and development. San
[17] Belassi W, Tukel OI. A new framework for determining critical Francisco: Freeman and Co.; 1978.
success/failure factors in projects. Int. J. Project Manag. [45] Steele LW. Innovation in big business. New York: Elsevier Publishing
1996;14(3):141–51. Company; 1975.
[18] Morris PWG, Hough GH. The anatomy of major projects: a study of [46] Wheelwright SC, Clark KB. Revolutionizing product development.
the reality of project management. New York: Wiley Press; 1987. New York: The Free Press; 1992.
[19] Munns AK, Bjeirmi BF. The role of project management in achieving [47] Tatikonda MV, Rosenthal SR. Technology novelty, project com-
project success. Int. J. Project Manag. 1996;14(2):81–7. plexity, and product development project execution success: a deeper
[20] Pinto JK, Slevin DP. Critical success factors across the project life look at task uncertainty in product innovation. IEEE Trans. Eng.
cycle. Project Manag. J. 1988;19(3):67–74. Manag. 2000;47(1):74–87.
[21] Lindkvist L, Soderlund J, Tell F. Managing product development [48] Soderlund J. Developing project competence. Empirical regularities in
projects: on significance of fountains and deadlines. Organ. Stud. competitive project operations. Int. J. Project Manag.
1998;19(6):931–51. 2005;9(4):451–80.
[22] Payne JH, Turner JR. Company-wide project management: the [49] PMI. Government extension to a guide to the project management
planning and control of programs of projects of different type. Int. J. body of knowledge (PMBOK" Guide). 2000 ed. Newtown Square,
Project Manag. 1999;17(1):55–9. PA: Project Management Institute; 2002.
[23] Floricel S, Miller R. Strategizing for anticipating risks and turbulence [50] PMI. Construction extension to a guide to the project management
in large-scale engineering projects. Int. J. Project Manag. body of knowledge (PMBOK" Guide). 2000 ed. Newtown Square,
2001;19:445–55. PA: Project Management Institute; 2003.
[24] Drazin R, van de Ven AH. Alternative forms of fit in contingency [51] PMI. United States Department of Defense Extension to: a guide to
theory. Admin. Sci. Quart. 1985;30:514–39. the project management body of knowledge (PMBOK" Guide). 1st
[25] Lawrence PR, Lorsch JW. Organization and environment: managing ed. Newtown Square, PA: Project Management Institute; 2003.
differentiation and integration. Boston: Graduate School of Business [52] Dvir D, Lipovetsky S, Shenhar AJ, Tishler A. In search of project
Administration, Harvard University; 1967. classification: a non-universal approach to project success factors.
[26] Pennings JM. Structural contingency theory: a reappraisal. Res. Res. Policy 1998;27:915–35.
Organ. Behav. 1992;14:267–309. [53] Gatignon H, Tushman ML, Smith W, Anderson P. A structural
[27] Shenhar AJ. One size does not fit all projects: exploring classical approach to assessing innovation: construct development of innova-
contingency domains. Manag. Sci. 2001;47(3):394–414. tion locus, type, and characteristics. Manag. Sci. 2002;48(9):1103–22.
[28] Woodward J. Management and technology. United Kingdom: H.M. [54] Shenhar AJ. From theory to practice. toward a typology of project
Stationary Office; 1958. management styles. IEEE Trans. Eng. Manag. 1998;45(1):33–47.
[29] Burns T, Stalker G. The management of innovation. London: [55] Mihm J, Loch CH, Huchzermeier A. Problem-solving oscillations in
Tavistock; 1961. complex engineering projects. Manag. Sci. 2003;46(6):733–50.
[30] Shenhar AJ, Dvir D. How projects differ, and what to do about it. In: [56] Gillham B. Case study research methods. New York: Continuum;
Morris PWG, Pinto JK, editors. The Wiley guide to managing 2000.
projects. Hoboken, NJ: Wiley and Sons; 2004. p. 1265–86. [57] Yin RK. Case study research: design and methods. Thousand Oaks,
[31] Shenhar AJ, Dvir D. Toward a typological theory of project CA: Sage Publications; 1994.
management. Res. Policy 1996;25:607–32. [58] Denzin N. The research act. Englewood Cliffs, NJ: Prentice Hall;
[32] Lewis MW, Welsh MA, Dehler GE, Green SG. Product development 1984.
tensions: exploring contrasting styles in project management. Acad. [59] Stake R. The art of case research. Newbury, CA: Sage Publications;
Manag. J. 2002;45(3):546–64. 1995.
[33] Thompson JD. Organizations in action. New York: McGraw-Hill; [60] Goldin DS. When the best must do even better: remarks by Daniel S.
1967. Goldin at the Jet Propulsion Laboratory. Pasadena, CA: National
[34] Youker R. The difference between different types of projects Aeronautics and Space Administration; 2000 [March 29].
(Revised). In: Proceedings of PMI 30th annual seminar and sympo- [61] Perrow C. Normal accidents: living with high-risk technologies.
sium. Philadelphia, PA; 2002 http://www.maxwideman.com/guests/ Princeton: Princeton University; 1999.
index.htm. [62] Vaughn D. The challenger launch decision: risky technology, culture,
[35] Perrow C. A framework for the comparative analysis of organiza- and deviance at NASA. Chicago: University of Chicago; 1996.
tions. Am. Sociol. Rev. 1967;32:194–208. [63] CAIB. Columbia accident investigation board report. National
[36] Galbraith J. Organization design. Addison-Wesley; 1977. Aeronautics and Space Administration; 2003.
[37] Archibald RD. Managing high-technology programs and projects. [64] Lewis RS. The voyage of Columbia, the first spaceship. New York:
3rd ed. New York: John Wiley and Sons; 2003. Columbia University Press; 1984.
[38] Archibald RD, Voropaev VI. Commonalities and differences in [65] Webster F. The space shuttle challenger incident: showcase project.
project management around the world: a survey of project categories Project Manag. J. 1987;18(2):41–68.
and life cycle models. In: Proceeding of the 17th IPMA world [66] Guthrie R, Shayo C. The Columbia disaster: culture, communication
congress on project management. Moscow, Russia; 2003. and change. J. Cases Inform. Technol. 2005;7(3):57–76.
 Author's personal copy

B.J. Sauser et al. / International Journal of Project Management 27 (2009) 665–679 679

[67] Chaisson EJ. The Hubble wars. Cambridge, MA: Harvard University [70] Balachandra R, Friar J. Factors for success in R&D projects and new
Press; 1998. product innovation: a contextual framework. IEEE Trans. Eng.
[68] Marshall LA, Corpening GP, Sherrill R. A chief engineer’s view of Manag. 1997;44:276–87.
the NASA X-43A scramjet flight test. In: Proceedings of 13th AIAA/ [71] Sauser B. A return to the moon: a system engineering management
CIRA international space planes and hypersonic systems and framework and the success of lunar prospector. Syst. Res. Forum
technologies conference; 2005. p. 1181–200. 2006;1(1):27–33.
[69] Newman JS. Failure-space. A systems engineering look at 50 space [72] Shenhar A, Dvir D, Milosevic D, et al. Toward a NASA-specific
system failures. Acta Astronaut. 2001;48(5–12):517–27. project management framework. Eng. Manag. J. 2005;17(4):8–16.

View publication stats