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

net/publication/257199056

Anatomy of a Decision Trap in Complex New Product Development Projects

Article  in  The Academy of Management Journal · February 2013

DOI: 10.5465/amj.2010.0742

CITATIONS READS
48 786

4 authors, including:

Henk Akkermans Kim E. Van Oorschot

Tilburg University BI Norwegian Business School
95 PUBLICATIONS   2,265 CITATIONS    51 PUBLICATIONS   431 CITATIONS   

SEE PROFILE SEE PROFILE

Luk Van Wassenhove

INSEAD
373 PUBLICATIONS   23,558 CITATIONS   

SEE PROFILE

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

Design Science View project

Health Care dynamics View project

All content following this page was uploaded by Henk Akkermans on 27 May 2014.

The user has requested enhancement of the downloaded file.

娀 Academy of Management Journal
2013, Vol. 56, No. 1, 285–307.
http://dx.doi.org/10.5465/amj.2010.0742

ANATOMY OF A DECISION TRAP IN COMPLEX NEW

PRODUCT DEVELOPMENT PROJECTS
KIM E. VAN OORSCHOT
BI Norwegian Business School

HENK AKKERMANS
University of Tilburg

KISHORE SENGUPTA
LUK N. VAN WASSENHOVE
INSEAD, France

We conducted a longitudinal process study of one firm’s failed attempt to develop a

new product. Our extensive data analysis suggests that teams in complex dynamic
environments characterized by delays are subject to multiple “information filters” that
blur their perception of actual project performance. Consequently, teams do not realize
their projects are in trouble and repeatedly fall into a “decision trap” in which they
stretch current project stages at the expense of future stages. This slowly and gradually
reduces the likelihood of project success. However, because of the information filters,
teams fail to notice what is happening until it is too late.

In new product development (NPD) projects, per- deviations from plan as early as possible. With
formance problems such as slipping schedules, these early warning systems, organizations can
budget overruns, missed specifications, “firefight- save considerable sums of money by identifying
ing,” and “scope creep” are widespread (Bohn, failing projects while they are still in the early
2000; Mihm, Loch, & Huchzermeier, 2003). In some stages of development (Keil & Montealegre, 2000).
cases, these problems lead to the termination of But each year millions of dollars are spent on failed
projects. For example, in 2002, $55 billion was technology projects (Dilts & Pence, 2006), which
wasted in terminated information technology proj- indicates that it still takes considerable time to
ects in the United States (Pan & Pan, 2006). Bould- terminate a project. These findings motivate our
ing, Morgan, and Staelin (1997) and Hitsch (2006) overall research question: Why does it take teams
cited project failure rates of at least 35 percent so long to realize that a project is in trouble and
across different industries. Barczak, Griffin, and should be terminated, despite the availability of
Kahn (2009) found that only about 59 percent of sophisticated project management tools and
newly commercialized products are considered to techniques?
be successful. This rate of success remained largely To increase our understanding of how a project
unchanged between 1990 and 2004, even though management team uses information when making
the number of firms using formal processes, meth- decisions, and to analyze the effects of these de-
ods, and techniques to improve new product devel- cisions on project outcomes, we conducted a lon-
opment increased from 54 to 69 percent during the gitudinal, in-depth qualitative process study of
same period. Over the years, decision making has an NPD project team. Our data provide evidence
been professionalized, leading to the development that the team was indeed sensitive and respon-
of tools and procedures for guiding organizations sive to information revealing small deviations
toward desired outcomes (March, 2006). Barczak et from the project plan and that the decisions the
al. (2009) reported that the best-performing firms in team made in response to those deviations were,
their research sample used more formal processes, in fact, aimed at correcting the course of the
tools, and techniques, but their survey did not clar- project. However, these decisions turned out to
ify how and why this relationship was positive. be counterproductive in the long run. It took
Furthermore, even the best-performing firms had a 53 weeks before the team noticed that their deci-
failure rate of 25 percent. sions resulted in using up all the slack in the
Decisions to terminate a project may occur at project plan. This led to a renegotiation with the
different points in the project (Dilts & Pence, 2006). customer to postpone the final due date by a
Project management tools are intended to detect year—at the cost of increased project scope but
285
Copyright of the Academy of Management, all rights reserved. Contents may not be copied, emailed, posted to a listserv, or otherwise transmitted without the copyright holder’s express
written permission. Users may print, download, or email articles for individual use only.
286 Academy of Management Journal
without an increased budget. Yet because of the
increased scope, the extra time did not help: the
company terminated the project in week 85 after
an investment of more than €20 million.
The project was implemented by an organization
in the semiconductor industry for a customer in the
automotive industry. This context was appropriate
for our study for a number of reasons. First, the
organization had all the required project manage-
ment tools and techniques in place, and team mem-
bers were highly experienced and trained to use
them. Second, due dates of NPD projects in the
automotive industry are often, as they were in this
case, fixed to a one-year cycle, the model year
(MY): either a project is completed on time, or the
due date is postponed by one year, which usually
means that the particular design linked to the proj-
ect is doomed. Since being on time is of the utmost
importance, we expected project teams to have a
strong focus on meeting deadlines. Thus, we ex-
pected teams to be sensitive and responsive to proj-
ect information revealing even small problems in
their project that could affect the schedule.
Our analysis of the case data provides insight
into why the project was terminated, despite the
use of sophisticated project management tools
and techniques. We show how managers uninten-
tionally but repeatedly shifted the burden for-
ward by preferring short-term, symptomatic fixes
of problems rather than fundamental solutions.
Hypotheses are derived that explain why, in this
dynamically complex situation characterized by
delays, the team we studied did not realize that
the project was in trouble. We show how “infor-
mation filters” (Russo, Carlson, Meloy, & Yong,
2008) confused decision makers and describe a
“decision trap” (Russo & Schoemaker, 1989) that
led the team toward project termination. Our
analysis and the resulting hypotheses contribute
to the existing literature on project termination,
perceptual errors, and decision making in com-
plex and ambiguous environments.
METHODS
This research originated from the authors’ com-
mon interest in management decision making in
NPD projects. Any analysis of how project manag-
ers make decisions—and of how their decisions
affect project outcomes—requires an in-depth
study with a long-term perspective. Therefore, we
performed a process study using the grounded the-
ory methodology. A process study is the study of
the temporal order and sequence of change events
based on a story or narrative (Van de Ven, 2007:
196), and a grounded theory is one that is induc-
February
tively derived from the study of the phenomenon it
represents (Strauss & Corbin, 1990: 23). Thus we do
not begin with a theory that we aim to prove; rather,
we allow hypotheses to emerge from the process
study. The basic steps in such a study include (a)
observing processes of stability and change over
time, (b) sorting data into meaningful categories, (c)
developing hypotheses explaining the observa-
tions, and (d) corroborating these hypotheses using
a different sample or using the same sample at a
different time (Van de Ven, 2007). The researcher
in a process study becomes a “fly on the wall” in
order to observe closely—in this case, to observe a
project’s decision-making process.
Setting
In 2007, a multinational organization, referred to
here as “TechCo,” initiated a large NPD project.
TechCo is a leading semiconductor manufacturing
company founded more than 50 years ago. Head-
quartered in Europe, the company has about 30,000
employees working in more than 25 countries and
had net revenues of €3.1 billion in 2010. TechCo
makes semiconductors that are widely used in TVs,
mobile phones, and cars. It invests almost €400 mil-
lion annually in R&D and employs about 3,000
engineers in various countries.
The NPD project of interest, “TechCar,” which
was of strategic importance to TechCo, consisted of
six subprojects involving more than 100 full-time
equivalent employees (FTEs) located in four differ-
ent countries. Because of its size and importance,
TechCar was an excellent candidate for our process
study. Furthermore, TechCo was already at level 3
of the Capability Maturity Model (CMM)1 and as-
pired to reach the next level. As a result, during the
period of our study, the company was devoting
significant attention to examining how TechCar’s
project planning and tracking processes could be
improved. After we explained our research interest,
TechCar’s program manager invited the first author
to attend the project’s core team meetings; these
meetings were meant for discussing all important
project information and for making decisions. (The
1
Especially in the information technology industry,
the CMM is a widely adopted framework (Galin & Avra-
hami, 2006; Harter, Krishnan, & Slaughter, 2000; Paulk,
1995) that classifies an organization’s software develop-
ment process into five maturity levels. Improvements in
cycle time, costs, and quality can be simultaneously at-
tained by increasing the maturity level of a software
organization (Harter et al., 2000). An organization at
CMM level 3 is one whose processes are defined (docu-
mented and standardized).
2013 van Oorschot, Akkermans, Sengupta, and Van Wassenhove
core team consisted of the program manager, the
project leader, the project planner, and six subproj-
ect leaders.) These meetings were not meant to
discuss the project’s technical details, which were
handled in separate technical meetings within sub-
projects. The core team meetings provided us with
an excellent opportunity to examine the project’s
main issues or problems, how problems were per-
ceived, how decisions were made, and the short-
and long-term effects of those decisions. As an in-
troduction, the first author interviewed all core
team members (nine interviews), three members of
the steering committee (three interviews), and
TechCar’s strategy consultant (one interview). The
company also gave us access to project data on
staffing levels and due dates as well as to all general
e-mail messages intended for the entire project
team that announced major breakthroughs or prob-
lems regarding time, costs, or functionality (25 of-
ficial mailings). After the start of this research proj-
ect, the first author acted as a silent and discreet
observer of 29 core team meetings lasting two hours
each (there were 3 meetings that the author did not
attend because of illness or holidays). During the
research project, the four authors held quarterly
meetings with the organization’s strategy consul-
tant (who served as the core team’s representative)
to discuss preliminary findings.
Data Analysis
A prerequisite to collecting longitudinal data is a
set of core concepts that provides a selective focus
for observing a change process (Van de Ven, 2007).
These concepts can be viewed as “sensitizing cat-
egories” (Glaser & Strauss, 1967). In this study, we
use five core concepts to reflect the central factors
of concern to innovation managers (Van de Ven,
1986; Van de Ven & Poole, 1990): ideas, people,
transactions, outcomes, and contexts. Ideas reflect
the content (scope) of a project. People represent
the perceptions and emotions of the core project
team about the project’s status in terms of time,
costs, quality, staff, or the project in general. Trans-
actions describe the engagements people make
with others to implement ideas and to make the
adaptations required for achieving desired out-
comes. Context reflects the changes in the environ-
ment that may influence a project or even its firm
(here, TechCar, TechCo). Outcomes represent ac-
tual deviations from a project plan in terms of time,
costs, and quality. The Appendix more fully de-
fines these concepts.
During the study, we recorded each qualitative
datum, defined as “a bracketed string of words
about a discrete incident” (Van de Ven, 2007: 218).
287
These strings of words are either sentences that we
literally copied from the project mailings or quotes
that we recorded during the core team meetings or
interviews and then transcribed. We presented the
transcribed quotes to core team members for final
inspection before coding. This procedure led to a
final set of 344 events: 181 events (53%) from the
project mailings, 153 events (44%) from the core
team meetings, and 10 events (3%) from the inter-
views. We coded the 344 events using the concepts
defined in the Appendix. To check for intercoder
reliability (Miles & Huberman, 1994), we asked a
second coder (not part of the research team) to code
10 percent of the total set of events (34 events).
Agreement on the coding of this subset was 87.1
percent, well in excess of the 80 percent reliability
threshold suggested by Miles and Huberman. The
next steps in the research process entailed indenti-
fying meaningful events from the qualitative inci-
dent data, analyzing temporal relationships or pat-
terns of events, and developing a narrative.
THE NARRATIVE
TechCo executes over 1,500 NPD projects con-
currently. The top 50 projects consist of the 10 most
critical projects in each of the firm’s five business
lines. Our focal project, TechCar, was one of this
top 50 and therefore also one of the top 10 of its
business line. TechCar started in April 2007 with a
planned development phase of three years. At the
start of the project, a lead customer in the automo-
tive industry was identified; this customer needed
the product by mid 2010 for integration into a new
automotive product in MY2012.
TechCo employs a “stage gate” approach to man-
aging projects (Cooper, 2008). That is, a project is
divided into a number of stages, separated by
“gates,” milestones at which a steering committee
(not part of the project’s core team) reviews the
project’s overall status. At each gate, the steering
committee decides whether to continue with the
project or to terminate it (makes a go/no-go deci-
sion). Intermediate gates create a high sense of ur-
gency for a team even when the final gate is well in
the future. For the TechCar project, the planned
gates and their initial schedules were as follows:
project gate 1 was the end of the conceptual design
stage (15 weeks from start); project gate 2 was the
end of the detailed design stage (27 weeks from
start); project gate 3 was the end of the test stage
(67 weeks from start); project gate 4 was the end of
the component verification stage (85 weeks from
start); project gate 5 was the end of the product
verification stage (94 weeks from start); and project
gate 6 was the end of the project and transfer to
288 Academy of Management Journal
customer (161 weeks from start). This plan incor-
porated about four months of overall slack time that
could be used to accommodate unforeseen events.
Stage 1: Conceptual Design Phase
In the first two months after the start of TechCar,
the core team performed roughly two activities:
defining the project (e.g., defining customer re-
quirements, developing a master plan) and ramping
up the team. The ramp-up had a good start, but it
became clear that hiring the right people required
considerably more time than planned. This issue
affected the project’s progress, and thus the first
gate’s due date began to slip. Quotes are from our
various data sources, which are detailed above.
Week 4: “We have [our] eye on four to six new key
people. [The] . . . major concern is currently that the
possible candidates we interviewed for the position
of subproject leader did not sufficiently match the
required profile. Search is continuing, of course,
with highest priority.”
Week 9: “We are still looking for good people to fill
. . . several important key management roles in
[TechCar]. This is now seriously starting to hamper
project progress. . . . As a result of this, the best-case
Gate 1 date of week 15 is no longer feasible. . . .”
Week 20: “Actions to create a detailed plan for the
remainder of Gate 1 are ongoing. The current esti-
mates show that the targeted week 33 may not be
feasible.”
TechCo is a multiproject organization, and the
R&D budget of its business line must be divided
among a number of projects. The company allo-
cates the available R&D budget once each calendar
year. Thus, the budget per project in 2008 was
defined at the end of 2007. Initially TechCo
planned for both stage 1 and stage 2 to be com-
pleted in 2007, which meant that only stage 3
would require a budget in 2008. However, as the
gates started to slip, it became clear that not only
stage 3 would be implemented in 2008 but also all
of stage 2 (and a small part of stage 1). These de-
velopments created problems for the 2008 budget
planning process— especially since a multiproject
organization does not “roll over” unused project
budgets, which instead are pooled and made avail-
able again to the entire organization (i.e., so all
projects can compete for them). For TechCar to
receive more of the 2008 budget than initially
planned, the company would have to cut other
planned projects. In order to protect those projects,
the steering committee forced the TechCar team to
focus on cost cutting at the end of 2007. Thus, the
team faced two setbacks at the same time: not get-
February
ting enough work done and having their funds re-
duced. Suddenly, budget issues became the team’s
new priority.
Week 24: “The bottom-up budget indicates that we
need much more budget for 2008 than currently
available. Detailed budget reviews are ongoing and
everyone is challenged to look for opportunities to
reduce the budget within required project timing.”
Week 29: “The current budget estimate for [Tech-
Car] without any additional changes still exceeds
the imposed limit. Actions are being taken to reduce
the budget.”
These budget problems led the company to re-
structure TechCar. Seeking to increase efficiency,
TechCo took several steps: reducing the number of
sites involved in the project, using only full-time
engineers, reusing designs from earlier projects,
and reducing workload by dropping a number of
minor customer requirements from the project
plan. By the end of 2007 (and just before reaching
gate 1), the team had endured a difficult and tumul-
tuous time. Yet the new contours of TechCar were
now defined, and optimism returned.
Week 32: “It is our intention to continue [TechCar]
in such a way that the right balance is found be-
tween the various projects within the business line
and the sites involved in the project. We may not
succeed for 100% but I [the project leader] believe
we are getting very close to this objective.”
Week 35: “The past week, we have spent lot of effort
in gaining momentum in the project and to regain
focus to enable [the] Gate 1 meeting in week 40. The
current status is positive. If we can step up further,
keep the focus on fast decision making and get back
on track, then we will meet Gate 1 on time and we
will also take a good step forward for Gate 2.”
There was hardly any time to recover from this
hectic period. To pass gate 1, the team had to make
a detailed plan for the next stage. This plan re-
vealed that a further ramp-up of the team was nec-
essary. The struggle for staff started anew.
Week 36: “The gate is slipping due to understaffing.
Hiring resources . . . [are] approved but resources
are not available. This will lead to delays.”
Week 39: “More capacity is required for configura-
tion management. There is a hiring delay. I [a sub-
project leader] cannot make a job offer to a potential
candidate, and because it takes so long, the candi-
date may accept an offer from another company!”
Week 41; “There are still critical resourcing issues
pending to be solved on short term to enable achiev-
ing [the] target date for gate 3.”
2013 van Oorschot, Akkermans, Sengupta, and Van Wassenhove
Stage 2: Detailed Design Phase
The team successfully passed gate 1 in week 42,
half a year behind schedule. However, the project’s
final due date was still MY2012. Because of this
huge delay with the first gate, the team had already
consumed a large part of the overall project slack.
Any further delay in gate 2 would also endanger
gate 3, which was the critical gate for realizing
MY2012. These circumstances were a great chal-
lenge for the team, which remained understaffed.
Week 49: “Now, the gate 2 is delayed . . . [by] 6
weeks. And we are only about 6 weeks after gate 1.
So the average now is 1 week work leads to 1 week
delay! This needs to improve!”
Week 51: “There is a risk of delaying gate 3 to week
88. Delaying gate 3 is unacceptable! Gate 3 in week
78 is already on the edge of meeting MY2012.”
Week 53: “There is no slack left in the planning. To
improve efficiency and reduce costs, most of the
slack was already taken out of the planning—and
now, due to all [the] delays, all slack is gone. [If] . . .
we don’t make gate 3 in week 78, we are out of
business.”
Week (56) “With the lack of resources I [a subproject
leader] have now, gate 3 can [only] be realized in
week 103, instead of week 78! If we present this to
[our lead customer], the project will be killed. In
week 78 we can show some functionality. But when
can we show full functionality?”
About one month before gate 2, the team was
confronted with new problems. After stretching
gate 3 to the last possible date, the team had no
slack left in the plan. Any delay in gate 2 would
mean working during nights and weekends to catch
up. Furthermore, because of project delays, budgets
were tied up in TechCar for much longer than orig-
inally planned. This led to more projects in the
business line running concurrently than planned
(i.e., its planned projects and the late-running proj-
ect), which created cash flow problems. Not only
was there no slack in time, there was also no slack
in the budget, and hence all new hiring was halted.
Week 58: “Permanent vacancies are frozen, presum-
ably because of a cash flow problem at [TechCo]. . . .
Of the 46 approved vacancies, only 5 will probably
remain. Also there is a target for the reduction of
contractors.”
Week (59) “All signs for one of the subprojects are
red; passing Gate 3 this year is a no-go. Two design-
ers resigned, and there are still vacancies. The proj-
ect managers and system architects are overloaded.
People are in firefighting mode.”
Week (61) “The ‘stop hiring’ scenario is the most
likely scenario. This means that [TechCar] cannot
289
proceed as planned. The most likely scenario is that
we will focus on MY2013, which means postponing
the project, because [of] scarcity of resources but
with increased features.”
Back to Stage 1: Conceptual Design Phase
The summer of 2008 was used to restructure the
project, since TechCo had decided to postpone the
entire project to MY2013. The company could se-
cure the lead customer’s agreement to this delay
only by increasing the scope of TechCar—that is, by
accommodating additional customer requirements.
However, there was no increase in the project’s
budget. A new project plan was devised, and the
team returned to the conceptual phase. This meant
that it was necessary to clear gate 1 once again.
TechCo set week 79 as the new due date for this
gate. Yet because the conceptual work had to be
done first, the team now had a surplus of detail
designers. The team tried to cut superfluous staff by
firing contractors and reallocating detail designers
to other projects. What the team needed now was
conceptual designers, but there was a shortage of
staff with these skills.
Week 62: “However, although we shift to MY2013, it
has to be recognized that there is no additional
budget available for [TechCar] in total; timing
should be shifted not more than four to six months
to avoid adding too much risk for meeting MY2013.”
Week 74: “I [a subproject leader] am in need of [an]
extra 2 FTE, but this will be at the expense of other
projects when 2 FTE are reallocated to my subproj-
ect. If the resources don’t come, there will be a delay
of about 9 weeks. We need to focus on stability, on
freezing the specs. It . . . [will be] difficult to realize
MY2013, even without any changes.”
Week 80: “Gate 1 was planned for week 79. Now it
is week 80. Though we are nearly there, officially
the gate is not passed yet. It is planned for Monday,
week 81, so more than [a] one-week delay. Of course
gate 2 is left unchanged, for week 94. A lot of work
has to be done before gate 1. [Furthermore, TechCar]
will run out of budget. We have to think which
requirements to leave out.”
Week 85: “[TechCar] was cancelled yesterday
afternoon.”
Delaying the project’s final due date provided
some relief. However, employee costs remained
high because of the surplus of detail designers not
yet moved to other projects. At the same time, there
was a shortage of conceptual designers. Hence the
extra work that needed to be done before passing
the revised gate 1 (i.e., meeting the new require-
ments that the lead customer specified as compen-
290 Academy of Management Journal
sation for the delay) was not completed on time,
and gate 1 started to slip again. The slipping date of
the new gate 1, when combined with the high
“burn rate” (expended costs per week), was simply
too much to handle. The team members could not
find a way to cut costs and also speed up the
project, so they were no longer confident that Tech-
Car could be completed successfully. The steering
committee’s only feasible option was then to kill
the project.
ANALYSIS: BALANCING AND
REINFORCING LOOPS
Why did it take the TechCar team 85 weeks to
terminate this project? To address this question, we
will examine this pattern more closely (cf. Balogun
& Johnson, 2004). We employ the conceptual lens
of dynamic decision making and use the tool kit of
system dynamics—in particular, causal loop dia-
gramming (Perlow, Okhuysen, & Repenning, 2002;
Repenning & Sterman, 2002; Rudolph & Repen-
ning, 2002). System dynamics is especially suitable
for situations involving multiple and interacting
processes, time delays, and other nonlinear effects
such as feedback loops and thresholds (Davis,
Eisenhardt, & Bingman, 2007). The resulting anal-
ysis of our case data yields hypotheses about how
the team used information to make decisions.
These hypotheses offer explanations for what hap-
pened that are fully consistent with the facts. To-
ward this end, we also present figures showing
various behaviors over time involving different as-
pects of the project. The figures illustrate graphi-
cally the root cause of the problems encountered,
how these problems manifested themselves to the
team, and the team’s unsuccessful remedies.
FIGURE 1
Planned and Actual FTE Staff on the Project
February
The Root Cause: Chronic Understaffing
Figure 1 shows the planned staff (staff required)
versus the actual number of FTEs (available staff),
working on TechCar over time (the data are from
the plans maintained by the project’s management).
The plot illustrates the project’s two ramp-up phas-
es: the start of the first stage (conceptual design) in
week 1 and the start of the second stage (detailed
design) in week 43. (Note that Christmas caused the
dip in actual FTEs working on the project in
week 33.)
More importantly, Figure 1 shows that the proj-
ect team was chronically understaffed throughout
the project. Especially during the two ramp-up
stages, the actual FTE lagged behind the planned
FTE, leading to the staff-related problems dis-
cussed in core team meetings (see the quotes in the
narrative for weeks 4, 9, and 39). The team was not
dramatically understaffed, but the difference was
enough to create a widening cumulative perfor-
mance gap between required performance (number
of completed tasks needed to finish the stage on
time) and actual performance (number of com-
pleted tasks given the available staff). The result
was scheduling problems—namely, the risk of
missing the project’s deadline (see the quotes for
weeks 36, 41, and 56).
The causality underlying this argument is shown
in the balancing “Staffing adjustment loop” (B1) of
Figure 2. We start on the left-hand side of this
balancing feedback loop: a performance gap caused
by a difference between actual and required perfor-
mance. This led to schedule problems because
more time was required to complete the planned
tasks. The best way to resolve these schedule prob-
lems was to address the corresponding staffing re-
2013 van Oorschot, Akkermans, Sengupta, and Van Wassenhove 291

FIGURE 2
Staffing Adjustment Loop and Schedule Slippage Loopa

a
Variables are related by causal links, which are shown as arrows. Each causal link is assigned a polarity: either positive (“⫹”) or
negative (“⫺”). A positive link means that if the cause increases (decreases), then also the effect increases (decreases). A negative link
means that if the cause increases (decreases), then the effect decreases (increases). See Sterman (2000).

quirements—in other words, to hire more people
(either internally or externally). However, hiring
was subject to two kinds of independent delays:
Hiring delays reflected the time it took to hire
someone from outside the company (three months
was not unusual; see the quote for week 39). As-
similation delays occurred because new members
who joined the team had to become familiar with
the company, the team, and the project; this learn-
ing process took time. Thus, after a decision was
made to hire new team members, it took some time
before those members became experienced enough
to solve the staffing problems, boost actual perfor-
mance, and close a performance gap. This is why
the staffing adjustment loop is balancing: the be-
havior described by this loop is self-correcting (i.e.,
it counteracts change). The team definitely ob-
served the performance gap caused by the staffing
problems and tried to hire more staff, but good
people were difficult to recruit. Additionally, new
hires joined the project later than planned (hiring
delay) and were not fully productive at the start
(assimilation delay). The team was probably not
able to calibrate their hiring decisions to match
these delays. Hence they adopted an additional
tactic for solving the performance gap: gate slip-
page (see the quotes for weeks 36, 56, and 74).
The Temporary Fix: Allowing Schedules to Slip
The gap between required and actual perfor-
mance becomes smaller when a schedule is al-
lowed to slip. Postponing a gate’s due date (gate
slippage) stretches the duration of a stage (the team
is given more weeks to do the same number of
tasks), which reduces required weekly perfor-
mance. Like the staffing dynamics, this mechanism
is (in system dynamics parlance) a balancing loop,
which means that the action—namely, letting the
schedule slip—aims to correct the discrepancy be-
292 Academy of Management Journal
tween actual and required performance. This dy-
namic is shown in the “Schedule slippage loop”
(B2) of Figure 2.
Slipping schedules were observed repeatedly in
the project. depicts the planned due dates for gates
1, 2, and 3 for the project’s first 61 weeks (until the
dramatic events unfolded that would have delayed
the project by a full year). The plot reveals a set of
frequent and relatively small increments in the
planned due dates for these gates.
Small adjustments in schedules became the
team’s preferred mechanism for dealing with the
persistently widening gap between actual and re-
quired progress that staff hiring failed to overcome.
After the gate was allowed to slip and the corre-
sponding stage duration was extended, staffing
problems temporarily disappeared from the mana-
gerial agenda.
Unintended Side Effects
Increasing overall project schedule pressure.
The practice of letting the due date slip addressed
only the symptoms and did not solve the funda-
mental problem. The final due date of the TechCar
project remained fixed. Therefore, every time an
intermediate gate was delayed, the time remaining
for the rest of the project was shortened. Some slack
had been built in to the initial project plan, but that
slack decreased every time stage 1 was extended
and gate 1 postponed, reducing the probability of
finishing the project on time. However, it took the
team a long time to perceive this loss of slack. The
schedule was adjusted in small, gradual steps, and
FIGURE 3
Slipping Due Dates of Gate 1 and Gate 2
February
the team did not realize that TechCar’s final due
date was under increasing threat until after a so-
called perception delay. Any belief or perception
involves a delay because mental models cannot be
updated instantly as new information is received
(Sterman, 2000). It was not until week 53 that the
team finally realized that they had used up all the
slack (see the quote in the narrative for week 53). In
the “Overall project slack loop” R1 shows that the
unintended side effect of the “Schedule slippage
loop” (B2) is reinforcing rather than balancing. That
is, the mechanism used to reduce the schedule
pressure of one stage causes the overall project
schedule pressure (the fundamental issue) to grow
over time.
Increasing budget pressure through project de-
lay. Stages 1 and 2 were initially scheduled for
2007. However, when the gates started to slip, all of
stage 2 (and even some of stage 1) were moved to
2008. This created problems for the 2008 budget
planning. As a result, the steering committee re-
quired the team to focus on reducing costs at the
end of 2007 (see the quotes in the narrative for
weeks 24, 29, and 32). When gate 2 also started to
slip, the need to lower costs surfaced again in week
58 (see the quotes for weeks 58, 59, and 61). Given
the pressure to stay within the given budget, the
team was cautious about hiring additional team
members. In week 61, business line management
went so far as to forbid the hiring of any new team
members. In an already understaffed team, this re-
striction aggravated the personnel and schedule
problems. This reinforcing vicious cycle is shown
as the “Budget pressure loop” (R2) of Figure 4,
2013 van Oorschot, Akkermans, Sengupta, and Van Wassenhove
FIGURE 4
Overall Project Slack Loop and Budget Pressure Loop
which extends the causal structure displayed in
Figure 2.
When we combine the four loops presented in
Figure 4, a dynamic theory of what probably caused
this project’s termination emerges. Because of hir-
ing and assimilation delays that were longer than
anticipated, the team was understaffed from the
start. Hence the team could not keep up with
planned performance, which led to schedule prob-
lems. A temporary fix that entailed gate slippage
and extending stage duration circumvented these
problems. In the short run, this fix reduced sched-
ule problems (balancing schedule slippage loop); in
the long run, however, it only made matters worse.
Since the final gate of the project was immovable,
gate slippage in one stage required reducing the
available time and budget for other stages. As a
result, the temporary fix caused schedule problems
to grow even more. Because of the reinforcing over-
all project slack loop, the slack that was used dur-
ing the first stage was not available for the next,
293
thereby further increasing the schedule pressure for
those subsequent stages. The reinforcing budget
pressure loop led to tighter budget constraints,
which in turn reduced and then eliminated the
possibility of hiring additional staff, thus increas-
ing the schedule pressure even more, until the proj-
ect “burst.”
DYNAMIC COMPLEXITY: ANATOMY OF A
DECISION TRAP
Why Did They Not See It Coming?
At this point in our analysis, we had a dynamic
theory that is consistent with the facts, but this
question remained: Why did these highly educated
and rational professionals not see the project termi-
nation coming? Surely the team knew that they
could not postpone due dates indefinitely, espe-
cially in light of the project’s fixed final due date.
The core team members must also have known that
294 Academy of Management Journal
the underlying problem was slowly and gradually
gaining strength; as Van de Ven, Polley, Garud, and
Venkataraman wrote, “With time, unattended prob-
lems often ‘snowball’ into vicious cycles” (2008:
24). To understand how this system went out of
control, we needed to look much closer at how
decisions were made from week to week. Decisions
are subject to perceptual filters (Russo et al., 2008)
that can blur actual project status information and
thereby lead the team to make the wrong decision.
Hence, we examined the most likely filters as well
as how they could influence decisions made by
the team.
The mixed signals filter: Good news eases the
pain of bad news. When a team is behind schedule
and receives both good and bad news at the same
time, it is likely to attribute the delay to bad luck
that can be overcome in the future; thus, the team
focuses on the positive news. But when a team is
behind schedule and receives mostly bad news, it
is forced to acknowledge structural problems and
to admit that something drastic must be done to
alter the course of its project.
Figure 5A displays, month by month, the accu-
mulation of events that can be coded as “positive,”
“negative,” and “neutral.” From this figure, it is
clear that in most weeks the accumulated positive
events were many fewer than the accumulated neg-
ative events. It might seem that this pattern should
have clearly signaled the team that the overall project
status was negative. Yet when we look at the monthly
change in these events—that is, when we look at the
flow of events—the picture is quite different. displays
the net flow of positive, negative, and neutral events
from month to month.2 From this figure, it is much
more difficult to assess what is happening to the
project. Especially in the second half of the project,
increases and decreases in the number of negative
events were matched by like fluctuations in positive
events. Thus, the team received a nearly continuous
stream of mixed signals. The combination of positive
and negative signals about performance made it dif-
ficult for the team to make overall sense of the feed-
back received and hence to assess adequately
whether or not the project was in trouble (Van de Ven
et al., 2008). As a result, the implications of negative
information were blunted because they were not per-
ceived as being strongly indicative of a problem (Keil,
Depledge, & Rai, 2007). In particular, our case data
suggest that the pain of negative information was
2
Mathematically speaking, the net flow is the deriv-
ative of the accumulation. This means that when the net
flow is positive (negative), the accumulation increases
(decreases).
February
numbed when it was accompanied by positive
information.
Week 33: “Progress is a little behind plan, but it is
not alarming; the burn rate is also lower, so the
progress made is in line with resources used.”
Week 40: “Next week there will be a gate meeting
per subproject; two subprojects are facing a major
challenge to meet all gate requirements, but one of
the subprojects is OK.”
In any given week, the difference between the net
flows of positive and negative news was relatively
small, making it convenient to ignore that week’s
bad news. However, over time the accumulated
negative news significantly outweighed the accu-
mulated positive news. This fact appears to have
escaped the team’s attention, since these accumu-
lations were not tracked. In other words, the team
focused on flows rather than accumulations.
Prior research demonstrates that decision makers
often confuse flows and accumulations (levels) and
treat the former as a surrogate for the latter (Cronin,
Gonzalez, & Sterman, 2009). This confusion (or
misperception) is one of the primary reasons why it
is difficult to understand and manage dynamically
complex situations (Cronin et al., 2009; Sterman,
1989). We call this phenomenon the mixed signals
filter, and it caused the team to misperceive the
weekly flow of ambiguous signals as a valid proxy
for the (accumulated) status of the project’s overall
progress. The mixed signal filter was on when the
net flow of positive events was not less than the net
flow of negative events; in that case, the team in-
terpreted the feedback as positive. However, be-
cause the accumulation of negative events was
greater than that of positive events (Figure 5A), the
feedback should rather have been interpreted as
negative. The mixed signal filter was off when the
net flow of negative events exceeded those of pos-
itive events—a clear signal that the overall project
status was negative (see also This filter is the basis
of our first hypothesis.
Hypothesis 1. Teams working in complex dy-
namic environments characterized by delays
pay less attention to the accumulation of neg-
ative project information and pay more atten-
tion to the (mixed) flow of positive and nega-
tive information. As a result, teams may not
realize that their projects are in trouble.
The waterbed filter: The underlying problem
does not manifest itself consistently. To ground
the behavior of problems (and our proposed causal
loop diagram of Figure 4) more solidly on our case
data, we grouped the qualitative quotes collected
from the team meetings and project correspon-
2013 van Oorschot, Akkermans, Sengupta, and Van Wassenhove 295

FIGURE 5
Mixed Signals Filtera

a
Positive events include, for example, a successful meeting with the customer and good progress made in a particular week. These
correspond with codes PEP, PPTO, PPCO, PPOO, and PPRO in the Appendix.
Negative events include all the problems listed in Figure 6 and other negative feelings or outcomes. These correspond with codes PEN,
PPTP, PPCP, PPOP, PPRP, TTG, OTA, OCA, and OOA in the Appendix.
Neutral events include, for example, describing how the project-planning system works and identifying where information can be found
on the intranet. These correspond with codes II, IE, CI, CC, CE, TW, and TP in the Appendix.

dence into three types of topics: staffing problems,
schedule problems, and budget problems. (We used
these three categories, which comprise the vast ma-
jority of comments made in team meetings and took
up most of the time spent in those meetings. See
codes PPRP, PPTP, and PPCP, respectively, in the
Appendix.) Figures 6A and 6B show the accumu-
lation and net flow of problems, as grouped into
these categories, that the core team faced over time.
The figures allow us to infer two broad patterns
of dynamic behavior: growth and oscillation. With
regard to growth, observe that the total number of
issues the team faced at any one moment fluctuated
from month to month but, over time, grew steadily:
296 Academy of Management Journal February

FIGURE 6
Waterbed Filter

from 4 ⫹ 5 ⫽ 9 issues in month 1, to 4 ⫹ 4 ⫹ 8 ⫽
16 issues in month 6, and 7 ⫹ 9 ⫹ 10 ⫽ 26 in month
15. Miller (1956) demonstrated that increasing the
number of issues an individual must simultane-
ously process also increases the risk of compromis-
ing performance. Rudolph and Repenning (2002)
illustrated this dynamic complexity in the context
of disasters.
With regard to oscillation, it is clear from that the
focus of attention for management switched repeat-
edly from one area of concern to another. During
the first three months of the project, staffing prob-
lems were the biggest issue for the team. Of all the
quotes in our data concerning problems in the proj-
ect, about 70 percent dealt with staffing problems
in this first phase. Then, during months 4 –7 (weeks
13–25), schedule problems suddenly became the
most pressing issue and led to repeated postpone-
ment of the gate 1 due date. In month 8 (around
week 29), the focus shifted to budget problems be-
cause the team concluded that the project would be
too expensive in 2008. Efforts to reduce costs suc-
ceeded— but at the expense of even more staffing
problems during stage 2 (months 9 –11). The pass-
ing of gate 1 in week 42 (month 11) was immedi-
ately followed by high schedule pressure for real-
izing gate 2 and the associated schedule problems.
Budget restrictions resurfaced thereafter, and the
team could not hire any more staff. These problems
were followed by a complete rescheduling of the
2013 van Oorschot, Akkermans, Sengupta, and Van Wassenhove
project, including postponement of the final due
date by one year.
From a system dynamics perspective, the causal
structure mathematically needed to generate the
behavior shown in Figure 6A is similar to that of
the diagram in Figure 4. The pattern in Figure 6A
combines oscillation and amplification. The under-
lying mathematical structure for an oscillation that
arises endogenously (i.e., not in response to some
oscillating input) is one of a balancing feedback
loop with at least two independent time delays
(Sterman, 2000). In an oscillatory system, the state
of the system constantly overshoots and under-
shoots its goal. The time delays cause corrective
actions to continue even after the state of the sys-
tem reaches its goal, forcing the system to adjust too
much and triggering a new correction in the oppo-
site direction (Sterman, 2000: 114). This dynamic
corresponds to our two balancing loops B1 and B2.
The corrective action of hiring additional staff con-
tinued until the team was actually overstaffed for a
short time (see weeks 25–29 in Figure 1), which
reduced staffing problems and schedule problems
but increased budget problems (see weeks 25–29 in
Figure 6A). The causal structure that generates am-
plification or exponential growth is that of a rein-
forcing feedback loop (Sterman, 2000), such as
loops R1 and R2 in Figure 4. The budget problems
constrained the hiring of additional personnel who
were required for the next stage, which led to an
acceleration of staffing problems (see week 30 in
Figure 6A), followed by schedule problems (see
week 41). This dynamic is in precise accordance
with the causal structure of Figure 4. We can thus
view the pattern in Figure 6A as capturing case data
in a way that provides additional support for our
causal loop explanation of why events unfolded as
they did.
In a context such as this, where problems come
and go in waves, it may be difficult to see that they
are all symptoms of the same underlying root
cause. One can understand why a team busy fight-
ing these symptomatic fires might fail to notice a
small but steady increase in the magnitude of the
underlying core problem. This phenomenon is also
known as a knowledge-based mistake, which oc-
curs when people are unable to analyze a problem
properly or to recognize the relations among its
elements (Zhao & Olivera, 2006). In our study, it
was difficult for the team to identify the most im-
portant problem because the contours of the prob-
lem set kept changing. It was as if the team was
sleeping on a waterbed: when there was a heavy
weight on one part of the bed, another part jumped
up. As soon as the team focused on one problem
and managed to solve this, another problem
297
jumped up that needed attention. This new prob-
lem distracted the team from analyzing the root
cause of the first problem. This brings us to another
reason why the team misperceived events: the wa-
terbed filter.
If we assume that the team focused more on the
net flow of problems (Figure 6B) than on their
accumulation (Figure 6A), then the waterbed filter
was on when the net flow of schedule or budget
problems was not less than the net flow of staffing
problems (i.e., when the staffing problem was man-
ifested as some other problem). The waterbed filter
was off when the net flow of staffing problems was
not less than the net flow of schedule or budget
problems (i.e., when the staffing problem was ob-
viously manifested as itself; see Table 1). Our next
hypothesis is based on this filter, which follows
directly from the multiple interacting and nonlin-
ear feedback loops of Figure 4.
Hypothesis 2. Teams working in complex dy-
namic environments characterized by delays
are distracted from recognizing the steadily
growing magnitude of an understaffing prob-
lem because that problem repeatedly manifests
itself in different ways (e.g., as schedule and/or
budget problems). As a result, teams may not
realize that their projects are in trouble.
The understaffing filter. The understaffing filter
is related to a team’s actual versus required staffing
level. A team that is both understaffed and behind
schedule will likely attribute the delay (an unfavor-
able outcome) to some factor beyond their control
(Keil et al., 2007; Langer, 1975; Staw & Ross, 1978;
Zhao & Olivera, 2006). This factor is usually an
external event caused by someone or something
outside the team. A shortage of staff could easily be
blamed on a human resources department that is
not working fast enough or on the job market,
which was tight at the beginning of TechCar (see
the quote in the narrative for weeks 4 and 39).
Hence the team believed that understaffing was the
cause of Stage 1’s due date slipping (see the quotes
for weeks 9 and 36). The implication is that, with a
sufficiently staffed team, schedule problems could
have been avoided in the past and could be pre-
vented in the future. Of course, if a team is behind
schedule yet is sufficiently (or over-) staffed, then it
cannot blame a human resources department or the
job market; it must find another and possibly inter-
nal reason for the delay. This explains why we
expect that decisions made in response to schedule
pressure will differ depending on whether or not
the team is understaffed.
During periods in which the team was under-
staffed, it had to predict how productive a future,
298 Academy of Management Journal February

TABLE 1
Filters, Decisions, and Results
Project Statusa Decisionb

Filter 1—Mixed Filter 2—Waterbed Filter 3—Understaffing Decision Trap—Stretch Decision—Stretch Result—Project
Week Signals (Figure 5) (Figure 6) (Figure 1) & Squeeze (Figure 3) & Slim (Figure 3) Slack Reducedc

9    Yes No
11    Yes No
15  ⴛ  Yes No
24   ⴛ Yes No
26 ⴛ  ⴛ Yes Yes
29 ⴛ ⴛ ⴛ Yes Yes
32  ⴛ  Yes No
35    Yes No
38    Yes No
41 ⴛ  ⴛ Yes Yes
47  ⴛ  Yes No
50    Yes No
51 ⴛ   Yes No
59 ⴛ  ⴛ Yes Yes
60  ⴛ ⴛ Yes Yes

a
The symbol “” indicates a filter was on, and “⫻” indicates it was off. Filter 1—Mixed signals: On when the net flow of positive events
is not less than the net flow of negative events. Off when the net flow of positive events is less than the net flow of negative events. Filter
2—Waterbed: On when the net flow of schedule and/or budget problems is not less than the net flow of staffing problems. Off when the
net flow of schedule and/or budget problems is less than the net flow of staffing problems. Filter 3—Understaffing: On when a team is
understaffed. Off when a team is sufficiently (or over-) staffed.
b
Decision trap—Stretch & squeeze: “Yes” indicates the team decided to stretch a current stage while squeezing future stage(s).
Decision—Stretch & slim: “Yes” indicates the team decided to stretch the current stage while slimming the overall project slack.
c
Result—Project slack reduced: “Yes” indicates overall project slack is reduced. “No” indicates overall project slack is protected
(unchanged).

fully staffed team would be. These predictions tend teams may not realize that their projects are in
to downplay the communication complexity and trouble.
coordination problems that vary as a function of the
Decisions made by the team: Stretch & slim or
size, composition, and experience of teams (Troy,
stretch & squeeze. Now that we have discussed the
Hirunyawipada, & Paswan, 2008). Larger teams re-
three filters that most affected the information per-
quire more coordination (Kessler & Chakrabarti,
ceived by the TechCar team, we turn our focus to the
1999). Furthermore, as discussed in the previous
actual team decisions—which were based on that
section, managers often fail to consider the full
filtered information—to get the project back on track.
negative impact on team productivity of the hiring
From the case data, two types of decisions can be
and assimilation delays associated with initiating
distinguished; we label these as stretch & slim and
or expanding a project team. This means that the
stretch & squeeze. When suffering from high sched-
productivity forecasts for a team that will be fully
ule pressure (i.e., many schedule problems) during a
staffed in the future are higher than the forecasts for
particular stage, the team extended that stage to allow
a team that is fully staffed but is still working
more time. Such extensions are made possible by
through the assimilation process. The understaffing
postponing the stage’s due date, thereby reducing
filter was on when the team was behind schedule
schedule pressure for that stage (balancing schedule
and understaffed, and it made the team more opti-
slippage loop of Figure 4). However, the extra time
mistic about the future productivity of a fully
allocated to a current stage has to come from some-
staffed team. The understaffing filter was off when
where. The first and obvious solution (stretch & slim)
the team was behind schedule and sufficiently
is to take time away from the overall project slack that
staffed, conditions that made the team more realis-
was initially built in to allow for unforeseen circum-
tic about future productivity (Table 1). The case
stances (reinforcing overall project slack loop of Fig-
data thus led us to our third hypothesis.
ure 4). Thus the current stage is stretched, and overall
Hypothesis 3. Understaffed teams working in project slack is reduced—a risky maneuver. So to
complex dynamic environments characterized protect the overall project slack, the team invented a
by delays tend to overestimate the potential second solution to buy more time for its current stage:
productivity of a fully staffed team. As a result, squeezing the planned duration of future stages (i.e.,
2013 van Oorschot, Akkermans, Sengupta, and Van Wassenhove
stretch & squeeze). The obvious benefit of this ap-
proach is that overall project slack remains un-
changed, which protects (at least on paper) the proj-
ect’s viability. However, when the duration of future
stages is squeezed, less time is available to do the
same amount of work; obviously, this increases
schedule pressure for those future stages. Hence this
solution makes sense only if the team can boost its
productivity in future stages.
Our case data reveal that the team decided to
stretch and squeeze stages on many occasions. This
behavior is marked by the shaded areas of Figure 3.
The duration of stage 1 (the dark gray area in the
graph) gradually grew from 15 to 42 weeks. At the
same time, the duration of stage 2 (medium gray
area) was squeezed from 12 to 6 weeks during the
first 33 weeks of the project. After week 33, the
team apparently realized that a 6-week schedule for
stage 2 was too optimistic; hence the duration of
stage 2 started to increase again—this time at the
expense of stage 3 (light gray area). It seems the
team (wishfully) assumed that, during those future
stages, it would be productive enough to recover
the lost time and slack.
Week 50: “Challenging targets are being used to
create awareness of the importance of shortening
[project time]. Detailed and correct plans, however,
are absolutely required to show the possibilities for
“crunching” or “fast-tracking” while keeping the
same realism in project planning. It can be surpris-
ing to see the possible [project] time improvements
that can be achieved in this way.”
A theoretical explanation consistent with the de-
cision to stretch and squeeze is that of the illusion
of control. When faced with low performance that
was causing high schedule pressure, team members
retained their (erroneous) impression that termina-
tion would be prevented by hard work (cf. Simester
& Zhang, 2010) and that they could influence out-
comes toward their desires (Lant, 1992). Langer
defined the illusion of control as “an expectancy of
a personal success probability inappropriately
higher than the objective probability would war-
rant” (1975: 313). This illusion persists because,
even though individuals are motivated to control
their environment, they are also motivated to avoid
the negative consequences that accompany the per-
ception of having no control (Langer, 1975). A re-
lated tendency is that of individuals to attribute
favorable outcomes to their own skills (internal or
endogenous factors) while attributing unfavorable
outcomes to circumstances beyond their control
(external or exogenous factors) (Keil et al., 2007;
Langer, 1975; Staw & Ross, 1978; Zhao & Olivera,
2006). In the context of our case, this meant that
299
when a delay at the first gate was perceived as
being caused by external factors (e.g., long hiring
delays caused by the human resources depart-
ment), the next stage was expected to proceed
much faster in response to internal factors such as
efficiency improvements (much as with the “plan-
ning fallacy” described by Kahneman and Tversky
[1979]). The effect of information filters may am-
plify the illusion of control, increasing a team’s
likelihood of misinterpreting the mixed signals, the
magnitude of the underlying problem, and the po-
tential productivity of a fully staffed team.
Hypothesis 4. Teams working in complex dy-
namic environments characterized by delays
fight project problems by stretching current
project stages at the expense of future stages
(stretch & squeeze) when they do not interpret
project information correctly (information fil-
ters are on). As a result, overall project slack is
artificially protected, and teams do not realize
that their projects are in trouble.
When information filters are off, a team is more
likely to interpret information feedback correctly.
In that case, the illusion of control is therefore
anticipated to be weaker or even absent. We then
expect that a team would decide to stretch a current
stage and take time away from the overall project
slack initially built in to its project plan for unfore-
seen circumstances (stretch & slim). These remarks
lead to our final hypothesis:
Hypothesis 5. Teams working in complex dy-
namic environments characterized by delays
fight project problems by stretching current
project stages at the expense of overall project
slack (stretch & slim) when they do interpret
project information correctly (information fil-
ters are off). As a result, the overall project
slack is reduced, and teams realize that their
projects are in trouble.
Anatomy of a Decision Trap
By combining the information filters that con-
fused decision makers with the two types of deci-
sions made by the TechCar team, we can derive the
so-called anatomy of a decision trap. Table 1 gives
an overview of all filters and decisions.
The table shows under what circumstances the
team chose to stretch and squeeze stages versus
choosing to stretch and slim overall project slack.
The first choice does not explicitly reduce overall
project slack; the second decision does. In order to
establish how teams chose either of these deci-
sions, we must examine the three information fil-
300 Academy of Management Journal
ters (mixed signals, waterbed, and understaffing).
Only by examining the filters and the decisions
made can we unfold the anatomy of the decision
trap into which the team fell. When two or more of
the filters were on (weeks 9, 11, 15, 24, 32, 35, 38,
47, 50, and 51), the team decided to stretch the
current stage and squeeze future stages, thus pro-
tecting overall project slack. This provides evi-
dence for Hypothesis 4 and indirectly also for Hy-
potheses 1, 2, and 3 because they feed into
Hypothesis 4. When two or more filters were off
(weeks 26, 29, 41, 59, and 60), the team decided to
stretch the current stage at the expense of overall
project slack. This provides evidence for Hypothe-
sis 5.
The recurrent decision to stretch and squeeze
was, in fact, a decision trap that stemmed from the
team’s wishful thinking (illusion of control) and
was reinforced by ambiguous information—that is,
information distorted by the identified filters. Ac-
tions that in unambiguous conditions would be
viewed as deviant may actually become routine in
an ambiguous context (Lehman & Ramanujam,
2009). During the weeks in which the filters were
off—when the information was consequently less
ambiguous—the team exhibited less wishful think-
ing and the quality of their decisions improved (cf.
Lant, 1992). It was only during these weeks of rel-
ative clarity that the team chose not to squeeze
future stages but instead to take its losses and
thereby consume overall project slack.
Why Did the Team Fall Repeatedly
into the Decision Trap?
In the first 24 weeks of the project, stage 2 was
squeezed from an initial duration of 12 weeks to
– 6 weeks. But in week 35, stage 2 had to be
stretched again—this time at the expense of stage 3.
This should have signaled to the team that their
control was in fact an illusion and that they would
be better served by using overall project slack in-
stead of squeezing future stages. Yet the team
clearly did not learn from this experience. The
decision trap to which the team fell prey can be
characterized as a latent error (Ramanujam & Good-
man, 2003). Such errors are deviations (from a set
of expectations) that can create adverse organiza-
tional consequences via positive feedback loops.
However, latent errors are difficult to detect
(whence “latent”) because direct (short-term) ad-
verse consequences are not evident. New product
development projects usually take months or even
years to complete, so decisions made in the begin-
ning can have long-term effects. However, by the
time such effects are manifested, an original deci-
February
sion maker may be unable to identify what decision
caused this effect (or that person may have been
assigned to a different project).
Note also that projects can be successful despite
poor decisions made by a manager. In such cases, it
is probable that the manager will (wrongly) attri-
bute this success to her/his prior decision making
(Langer, 1975). Ross and Staw (1993) argued that,
given a history of personal reinforcement, it can be
difficult for a project management team to conceive
of a course of action not succeeding— especially
when the exact causes of previous successes are
unknown. Long time lags between actions and out-
comes, or causes and effects, slow down the learn-
ing cycle; this reduces the ability to accumulate
experience (Sterman, 1994). As projects become
more complex, managers cease to learn from their
experience; in some cases, this leads to the so-
called experience trap (Sengupta, Abdel-Hamid, &
Van Wassenhove, 2008). The experience trap argu-
ment suggests that even an impressive career back-
ground does not guarantee that a manager has the
ability to oversee complex projects. Absent latent
errors, decision makers can learn about a system
when given enough time, stability, and unambigu-
ous information. Otherwise, however, learning may
be difficult (Lant, 1992; Ramanujam & Goodman,
2003). In any case, learning may be compromised
because memory of past experiences decays with
time (Denrell & March, 2001).
The TechCar team suffered from all the impedi-
ments to learning described so far. The project was
dynamically complex, decisions had to be made un-
der severe time constraints, and information was am-
biguous. The team worked hard and tried to solve
problems as soon as they appeared. Not a single sub-
project leader had the luxury of being either ahead of
schedule or fully staffed. As a result, the subproject
leaders had neither the time nor the energy to focus
on the bigger picture and the root cause of the prob-
lem. This is arguably why the entire team repeatedly
fell into the decision trap described here. Research
has shown that subjects tend to assign too much
weight to available and salient features (March, 1991;
Repenning & Sterman, 2002). Thus, the easy, salient
fix of the stretched stage left the underlying problem
in the TechCar project unchanged. While the problem
symptoms cleared up, the underlying problem grew
worse (compare the systems archetype known as
“shifting the burden” as developed by Senge [1990])
and finally resulted in the project’s termination.
In a project as dynamically complex as Tech-
Car, decision makers are required to become sys-
tem thinkers—in other words, to incorporate
feedback and not be limited to linear thinking. In
a linear world, any gap between an actual and
2013 van Oorschot, Akkermans, Sengupta, and Van Wassenhove
desired situation can be resolved by a decision
that brings the actual situation closer to the de-
sired one. But in a dynamically complex world,
decisions can have unintended side effects that
aggravate the initial gap. If these side effects are
ignored or overlooked, then a team’s goals will
never be realized. The daunting complexity of the
cognitive task faced by the team in our study
becomes more obvious still if, in addition to the
complicating factors listed so far, one recalls that
any action taken by managers triggers the multi-
ple and interrelated feedback loops shown in Fig-
ure 4. In sum, it no longer seems so puzzling why
the team “didn’t see it coming”: they were in a
complex dynamic situation characterized by de-
lays that made them misinterpret project infor-
mation, causing them to fall into the deci-
sion trap.
The hypotheses we derived in this section and
the resulting anatomy of a decision trap apply to
the particular team we studied. By moving up the
ladder of abstraction by inductive reasoning (Osig-
weh, 1989; Van de Ven, 2007), we can now propose
a hierarchical theory. We extend the breadth of our
hypotheses into a more general proposition while
reducing their connotation (increasing simplicity).
Our general proposition is presented as a chain
argument.
General proposition:
a. If a system is dynamically complex, it is difficult
to see through information filters to make sense
of the information (that is ambiguous, disguised,
delayed) received from this system.
b. If it is difficult to make sense of information, a
decision trap is likely to occur, i.e. a decision
that seems to help in the short term but is coun-
terproductive in the long term.
c. If a decision trap occurs, it will take longer to
adequately assess what is actually driving the
behavior of a system.
This general proposition allows us to transfer our
findings to other complex dynamic phenomena in
which this decision trap might apply.
DISCUSSION
Research Implications
Termination of a project presents a difficult and
complex decision with strategic implications for an
organization (Green & Welsh, 2003; Markham,
2000). As a project progresses through the stages of
development, postponing the termination of a fail-
ing project becomes increasingly expensive
(Schmidt & Calantone, 1998). Previous research in-
301
dicates two main reasons for why it can take a long
time before a team realizes a project is in trouble
and needs to be terminated: escalation of commit-
ment (Staw, 1976) and groupthink (Janis, 1982).
The theory of escalation of commitment focuses on
why managers continue to invest in projects in the
face of negative information. The literature on
groupthink targets teams and interactions within
them. In his seminal study on this phenomenon,
Staw described escalation behavior as a negative
reinforcing process: “Due to a need to justify prior
behavior, a decision maker may increase his com-
mitment in the face of negative consequences, and
this higher level of commitment may, in turn, lead
to further negative consequences” (1976: 29). Thus,
instead of accepting an immediate loss and termi-
nating the project, decision makers may commit
new and additional resources in terms of funds,
personnel, or time to it. Escalation of commitment
can occur when managers have a strong sense of
responsibility for a project (Schmidt & Calantone,
2002; Staw, 1976), for example because they initi-
ated it (Green & Welsh, 2003) or because termina-
tion would have negative consequences for their
careers (Harrison & Harrell, 1993); or it can occur
when a team suffers from perceptual biases (Voss,
Rothermund, & Brandtstädter, 2008) that affect in-
formation collection. Negative project status infor-
mation is sometimes not available or not attended
to (Keil, Mann, & Rai, 2000; Simester & Zhang,
2010), or initial positive beliefs are sometimes not
updated in the face of negative new information
(Biyalogorsky, Boulding, & Staelin, 2006). Optimis-
tic biases in the interpretation of ambiguous situa-
tions have been documented (Voss et al., 2008).
Biases can lead managers to see only what they
want to see, which is any information indicating
that the project is on the right track (Balcetis &
Dunning, 2006).
Groupthink refers “to a mode of thinking that
people engage in when they are deeply involved in
a cohesive in-group, when the members’ striving
for unanimity override their motivation to realisti-
cally appraise alternative courses of action” (Janis,
1982: 9). Groupthink is characterized by self-cen-
sorship, illusions of unanimity, direct pressure on
dissidents, and reliance on self-appointed “mind
guards” (see also Whyte, 1998). Groupthink may
cause a team to agree on issues, develop a prefer-
ence for risk, and aim for uniformity. Groupthink
makes it difficult for groups to accept the “threat-
ening” contrary information that is inherent to in-
novation projects (Schmidt, Montoya-Weiss, &
Massey, 2001; Van de Ven, 1986). Whyte (1998)
argued that groupthink follows from errant percep-
tions of collective efficacy—that is, overoptimistic
302 Academy of Management Journal
judgments about a group’s capacity to perform a
specific task. Voss et al. (2008) examined judgmen-
tal biases that operate by an asymmetric setting of
thresholds regarding the amount of information
that is required to accept a positive or negative
conclusion.
However, the results of our data analysis indicate
that escalation of commitment and groupthink can-
not plausibly explain why it took the team studied
here so long to realize that their project was in
trouble. With respect to escalation of commitment,
the team did not commit to requiring (or obtaining)
additional resources in terms of either budget or
staffing. The team did commit to spending extra
time on a current stage, but this was at the expense
of the time for future stages or the overall project
slack. TechCar’s core team discussed problems re-
lated to staff, time, and budgets openly and in great
detail. Moreover, the team certainly attended to
this negative information. Staffing problems were
addressed by intensifying communication with the
human resources manager. Due dates were post-
poned to accommodate problems with the project
plan. When budget issues arose, the team tried to
increase efficiency and reused designs from former
projects. Furthermore, the members of the core
team were not the initiators of the TechCar project;
“adverse selection” (Harrison & Harrell, 1993) did
not apply; and no incentive schemes were in place.
With respect to groupthink, the team was not a
closed circle that excluded advice or guidance from
others. Peer reviews were held (people from out-
side the team were invited to evaluate the team’s
progress), and the gatekeepers (the steering com-
mittee) were not part of the team.
Because escalation of commitment and group-
think cannot answer our research question, we
need a new theory. Our anatomy of a decision trap
goes beyond the research streams of escalation of
commitment and groupthink. Our analysis pro-
vides an explanation of why it took the team so
long to realize the trouble it was in: the difficulty to
see through different information filters which
caused the team to make the wrong decision, which
in turn made it even more difficult to evaluate what
the actual status of the project was. We introduced
a system dynamics lens that allowed us to show the
periodicity and amplification of three important
and interconnected problems in NPD—namely,
staffing, time, and budget. Through this lens, we
unravel the anatomy of a decision trap that ex-
plains why this highly skilled team did not see
project termination coming. This anatomy consists
of three information filters that led the team to
misdiagnose the project’s deteriorating state: the
mixed signals filter, the waterbed filter, and the
February
understaffing filter. The mixed signal filter ac-
counts for the team’s focus on the flows, rather than
the accumulations, of positive and negative infor-
mation. Because these flows were mixed, it was
difficult for the team to perceive that the situation
was gradually deteriorating (Hypothesis 1). The
waterbed filter explains why fundamental prob-
lems that seem to be solved reemerge nonetheless
in a different manifestation (e.g., staffing problems
“disguised” as schedule problems). This oscillating
between different manifestations of the problem
further blurred the team’s view (Hypothesis 2). The
understaffing filter accounts for the difficultly of an
understaffed team in forecasting the productivity of
a fully staffed team (Hypothesis 3). Misinterpreting
project information (as a result of at least two of the
filters being on), combined with the illusion of
control, caused the team to fall into the decision
trap of stretching the current stage while squeezing
the next, supposing that overall project slack was
protected (Hypothesis 4). When (at least two of) the
filters were off and so the information was not
misinterpreted, the team decided instead (and cor-
rectly) to stretch the current stage and slim the
overall project slack (Hypothesis 5). Together, the
filters and the psychological factors discussed here
explain why it took the team so long to recognize
the true gravity of the project’s problems. Finally,
the ambiguity of information and the long time lags
between decisions and their effects in this dynam-
ically complex system could not have facilitated
learning, so the team fell repeatedly into the same
decision trap.
It is known that people have difficulty in under-
standing complex dynamic settings (Cronin et al.,
2009; Sterman, 1989) and that they often respond to
those settings by simplifying decision processes or
cognitive representations (Bourgeois, McAllister, &
Mitchell, 1978; Sherman & Keller, 2011), leading to
poor performance. However the effect of informa-
tion filters on this lack of understanding and con-
sequently, on interpreting project information and
evaluating the status of the project has, to our
knowledge, not been examined before. According
to Green and Welsh (2003), managers need to de-
vote more attention to understanding advocacy (ex-
pressing support for a project and assigning it a
higher priority) and the role it plays in project
evaluation. “Although such processes have been
long recognized in R&D management, they have not
received the systematic attention that has been
given to trying to understand the financial aspects
of new product development” (Green & Welsh,
2003: 431). The authors conclude that at present
this understanding is not well developed. Our re-
search is an important contribution to this under-
2013 van Oorschot, Akkermans, Sengupta, and Van Wassenhove
standing. The patterns graphed in Figures 5 and 6
are fairly simple and seem self-evident. However,
none of the common project management tools and
techniques that are used by researchers and practi-
tioners generate these patterns. In the absence of a
dynamic perspective and periodically tracking and
accumulating positive and negative events and dif-
ferent types of problems, information filters will
continue to prevent project teams from realizing
when projects are in trouble. Consequently, project
teams will continue to fall into the decision trap
leading to project termination.
On a more abstract level, we have developed a
proposition that allows our decision trap to travel
beyond the context of new product development
teams. This proposition states that in a complex
dynamic system, it is difficult to see through infor-
mation filters and to make sense of the system
information received. As a result, a decision trap is
likely to occur: a decision that seems to help in the
short term but is counterproductive in the long
term. When this occurs, it will take longer to ade-
quately assess the drivers of the system’s behavior.
There are other complex dynamic systems in which
this decision trap could occur. Think for example
about a weight loss struggle. Suppose someone
wants to lose ten pounds in the next ten weeks to be
ready for the summer season. It is very likely that
this person eats too much in the first weeks, but
keeps planning to make up for this in the remaining
weeks. On paper it seems possible to lose ten
pounds in five weeks; in reality it will probably
never happen, and this failure will increase the
weight loss struggle. Another application of the
decision trap is found in traffic congestion manage-
ment. A relatively short-term solution to conges-
tion is building more lanes, which temporarily re-
duces the problem. However, over the long term the
new lanes may increase the attractiveness of using
cars, leading to a growth of the number of cars on
the road, which increases congestion again.
Managerial Implications
Especially in large, complex NPD projects that
employ more than a 100 staff, cost millions of eu-
ros, and take years to complete, it seems a waste of
time to focus managerial attention on a staffing
problem that involves (say) only two FTEs or on a
stage delay of a single week. Nevertheless, our re-
search confirms the intuition that small problems
can snowball into big problems. Because complex
systems are so interdependent, a small glitch in one
place can lead to a massive failure elsewhere (Rob-
erts, Bea, & Bartles, 2001). But, as Weick and Sut-
cliffe remarked, “Accidents are not sudden, they
303
are incubated and give off daily warning signals”
(2006: 517). It is therefore dangerous to interpret
small but anomalous events as normal or accept-
able deviations. The main implication for manage-
ment is that problems—and not symptoms—should
be solved as soon as they appear (i.e., when they are
still small). This approach requires a sensitivity or
mindfulness with which a project team pays atten-
tion to the subtle as well as the dramatic (Senge,
1990) and reacts to even weak signs of a problem
(Coutu, 2003). The staffing problem that TechCar
faced is typical of many projects, so project teams
should pay close attention to even slight manifes-
tations of this problem. Perhaps management could
ask one person in each big project to keep track of
the items we tracked in this study and to generate a
simple scorecard based on some of our graphs (e.g.,
plotting the frequency with which staffing, sched-
ule, and budget problems are discussed in team
meetings).
Furthermore, hasty solutions (“patches”) should
not be tolerated; they might cause old problems to
reemerge and can even create new problems (Bohn,
2000). For TechCo, this approach would have
meant that, as soon as management realized the
TechCar project was understaffed (and given that
the project’s final due date was fixed), only three
courses of action were viable: (1) increase the bud-
get to hire more staff (and more quickly), (2) reduce
the project’s scope to decrease workload, or (3) halt
the project. However, the relationship between
higher budgets now and a greater chance of project
success (four years) later was apparently too fuzzy
to be convincing. Ironically, the actions of the core
team eventually led to a budget freeze and an in-
crease in scope: precisely the opposite of what the
team needed.
To detect problems as soon as possible, a team
should be aware of the dynamically complex situ-
ation in which it is operating. Previous research has
shown that most individuals lack the capacity to
deal with dynamic complexity (Gonzalez, 2005;
March, 2006; Van de Ven, 1986). However, this
capacity can be improved by providing participants
with cognitive feedback: information about rela-
tions in the decision environment, about relations
perceived by the person in that environment, and
about relations between the environment and that
person’s perception of it. Sengupta and Abdel-
Hamid (1993) demonstrated that cognitive feed-
back can improve performance in dynamic deci-
sion-making tasks. Gonzalez (2005) argued that
cognitive “feedforward” (information that helps de-
cision makers to analyze the effects of possible
future decisions) improves performance when dy-
namic decision-making tasks are performed in real
304 Academy of Management Journal
time. Mapping causal relationships (as in Figure 4)
also helps decision makers because it forces them
to be explicit—not only about relevant variables,
but also about their dynamic properties (Ramanu-
jam & Goodman, 2003). Causal maps provide feed-
forward-based heuristics for managing projects in a
complex dynamic environment. They indicate
what the underlying problem is in a particular set-
ting (the problem that should be addressed as soon
as it occurs) and also which problems are merely
symptoms of the underlying problem.
This list of managerial implications underscores
the dynamic complexity of managing NPD projects.
Our findings suggest that preventing project termi-
nation must begin with an understanding of a proj-
ect management problem’s underlying structure. It
is important to recognize that understaffing is not
the only underlying problem; in our case the prob-
lems began with an understaffed team, but in other
projects the problem could originate elsewhere.
Limitations and Future Research
The results of our analysis are presented with
some caveats that are often associated with longi-
tudinal process studies. First, selective bias may
result from our exclusive focus on decision making
in the studied project. Apart from this focus, how-
ever, we had no preliminary bias regarding what
kind of decisions the team would make. Our re-
search started soon after the project began and long
before any signs of severe problems surfaced, so the
data collection was not biased toward finding
causes of project termination. There was no hind-
sight bias, either, because we studied the project in
real time. Second, the study was performed in a
single organization; this limits our ability to corrob-
orate our hypotheses with a different sample and
thereby generalize the results. We were fortunate to
find a repetitive pattern of events in the same or-
ganization, because this allowed for corroborating
our hypotheses in the same sample but at a differ-
ent time (Van de Ven, 2007).
This study opens many opportunities for further
research into the conditions under which projects
are terminated and how these conditions differ
from those that promote project success. It also
suggests avenues for studies on establishing early
detection mechanisms and appropriate measures to
avoid project termination. Furthermore, the role of
slack in an overall project schedule is interesting to
investigate further. Maybe teams without any slack
pay more attention to small deviations from project
plan. As our data show, the true causes of project
termination lie far beyond the domains of skills,
tools, and techniques. Otherwise, today practitio-
February
ners and researchers would not be witnessing so
many projects being terminated.
REFERENCES
Balcetis, E., & Dunning, D. 2006. See what you want to
see: Motivational influences on visual perception.
Journal of Personality and Social Psychology, 91:
612– 625.
Balogun, J., & Johnson, G. 2004. Organizational restruc-
turing and middle manager sensemaking. Academy
of Management Journal, 47: 523–549.
Barczak, G., Griffin, A., & Kahn, K. B. 2009. Perspective:
Trends and drivers of success in NPD practices—
Results of the 2003 PDMA best practices study. Jour-
nal of Product Innovation Management, 26(1):
3–23.
Biyalogorsky, E., Boulding, W., & Staelin, R. 2006. Stuck
in the past: Why managers persist with new product
failures. Journal of Marketing, 70: 108 –121.
Bohn, R. 2000. Stop fighting fires. Harvard Business
Review, 78(4): 82.
Boulding, W., Morgan, R., & Staelin, R. 1997. Pulling the
plug to stop the new product drain. Journal of Mar-
keting Research, 34: 164 –176.
Bourgeois, L. J., McAllister, D. W., & Mitchell, T. R. 1978.
The effects of different organizational environments
upon decisions about organizational structure.
Academy of Management Journal, 21: 508 –514.
Cooper, R. G. 2008. Perspective: The stage-gate® idea-to-
launch process-update, what’s new, and nexgen sys-
tems. Journal of Product Innovation Management,
25: 213–232.
Coutu, D. L. 2003. Sense and reliability: A conversation
with celebrated psychologist Karl E. Weick. Harvard
Business Review, 81(4): 84 –90, 123⫹.
Cronin, M. A., Gonzalez, C., & Sterman, J. D. 2009. Why
don’t well-educated adults understand accumula-
tion? A challenge to researchers, educators, and cit-
izens. Organizational Behavior and Human Deci-
sion Processes, 108: 116 –130.
Davis, J. P., Eisenhardt, K. M., & Bingman, C. B. 2007.
Developing theory through simulation methods.
Academy of Management Review, 32: 480 – 499.
Denrell, J., & March, J. G. 2001. Adaptation as informa-
tion restriction: The hot stove effect. Organization
Science, 12: 523–538.
Dilts, D. M., & Pence, K. R. 2006. Impact of role in the
decision to fail: An exploratory study of terminated
projects. Journal of Operations Management, 24:
378 –396.
Galin, D., & Avrahami, M. 2006. Are CMM program in-
vestments beneficial? Analyzing past studies. IEEE
Software, 23(6): 81– 87.
2013 van Oorschot, Akkermans, Sengupta, and Van Wassenhove
Glaser, B. G., & Strauss, A. L. 1967. The discovery of
grounded theory: Strategies for qualitative re-
search. Chicago: Aldine.
Gonzalez, C. 2005. Decision support for real-time, dy-
namic decision-making tasks. Organizational Be-
havior and Human Decision Processes, 96: 142–
154.
Green, S. G., & Welsh, M. A. 2003. Advocacy, perfor-
mance, and threshold influences on decisions to ter-
minate new product development. Academy of
Management Journal, 46: 419 – 434.
Harrison, P. D., & Harrell, A. 1993. Impact of “adverse
selection” on managers’ project evaluation deci-
sions. Academy of Management Journal, 36: 635–
643.
Harter, D. E., Krishnan, M. S., & Slaughter, S. A. 2000.
Effects of process maturity on quality, cycle time,
and effort in software product development. Man-
agement Science, 46: 451– 466.
Hitsch, G. J. 2006. An empirical model of optimal dy-
namic product launch and exit under demand un-
certainty. Marketing Science, 25(1): 25–50.
Janis, I. L. 1982. Groupthink: Psychological studies of
policy decisions and fiascoes. Boston: Houghton
Mifflin.
Kahneman, D., & Tversky, A. 1979. Intuitive prediction:
Biases and corrective procedures. TIMS Studies in
Management Science, 12: 313–327.
Keil, M., Depledge, G., & Rai, A. 2007. Escalation: The
role of problem recognition and cognitive bias. De-
cision Sciences, 38: 391– 421.
Keil, M., Mann, J., & Rai, A. 2000. Why software projects
escalate: An empirical analysis and test of four the-
oretical models. MIS Quarterly, 24: 631– 664.
Keil, M., & Montealegre, R. 2000. Cutting your losses:
Extricating your organization when a big project
goes awry. Sloan Management Review, 41(3): 55–
68.
Kessler, E. H., & Chakrabarti, A. K. 1999. Speeding up the
pace of new product development. Journal of Prod-
uct Innovation Management, 16: 231–247.
Langer, E. J. 1975. The illusion of control. Journal of
Personality and Social Psychology, 32: 311–328.
Lant, T. K. 1992. Aspiration level adaptation: An empir-
ical exploration. Management Science, 38: 623–
644.
Lehman, D. W., & Ramanujam, R. 2009. Selectivity in
organizational rule violations. Academy of Manage-
ment Review, 34: 643– 657.
March, J. G. 1991. Exploration and exploitation in organ-
izational learning. Organization Science, 2: 71– 87.
March, J. G. 2006. Rationality, foolishness, and adaptive
305
intelligence. Strategic Management Journal, 27:
201–214.
Markham, S. K. 2000. Corporate championing and an-
tagonism as forms of political behavior: An R&D
perspective. Organizational Science, 11: 429 – 447.
Mihm, J., Loch, C., & Huchzermeier, A. 2003. Problem-
solving oscillations in complex engineering projects.
Management Science, 46: 733–750.
Miles, M. B., & Huberman, M. 1994. Qualitative data
analysis: A sourcebook of new methods (2nd ed.).
Beverly Hills, CA: Sage.
Miller, G. A. 1956. The magical number seven plus or
minus two: Some limits on our capacity for process-
ing information. Psychological Review, 63: 81–97.
Osigweh, C. A. B. 1989. Concept fallibility in organiza-
tional science. Academy of Management Review,
14: 579 –594.
Pan, G., & Pan, S. L. 2006. Examining the coalition dy-
namics affecting IS project abandonment decision-
making. Decision Support Systems, 42: 639 – 655.
Paulk, M. C. 1995. How ISO 9001 compares with the
CMM. IEEE Software, 12(1): 74 – 83.
Perlow, L. A., Okhuysen, G. A., & Repenning, N. P. 2002.
The speed trap: Exploring the relationship between
decision making and temporal context. Academy of
Management Journal, 45: 931–955.
Ramanujam, R., & Goodman, P. S. 2003. Latent errors and
adverse organizational consequences: a conceptual-
ization. Journal of Organizational Behavior, 24:
815– 836.
Repenning, N. P., & Sterman, J. D. 2002. Capability traps
and self-confirming attribution errors in the dynam-
ics of process improvement. Administrative Sci-
ence Quarterly, 47: 265–295.
Roberts, K. H., Bea, R., & Bartles, D. L. 2001. Must acci-
dents happen? Lessons from high-reliability organi-
zations. Academy of Management Review, 15: 70 –
79.
Ross, J., & Staw, B. M. 1993. Organizational escalation
and exit: Lessons from the Shoreham nuclear power
plant. Academy of Management Journal, 36: 701–
732.
Rudolph, J. W., & Repenning, N. P. 2002. Disaster dynam-
ics: Understanding the role of quantity in organiza-
tional collapse. Administrative Science Quarterly,
47: 1–30.
Russo, J. E., Carlson, K. A., Meloy, M. G., & Yong, K.
2008. The goal of consistency as a cause of informa-
tion distortion. Journal of Experimental Psychol-
ogy: General, 137: 456 – 470.
Russo, J. E., & Schoemaker, P. J. H. 1989. Decision traps:
The ten barriers to brilliant decision making and
306 Academy of Management Journal
how to overcome them. New York: Simon & Schus-
ter.
Schmidt, J. B., & Calantone, R. J. 1998. Are really new
product development projects harder to shut down?
Journal of Product Innovation Management, 15:
111–123.
Schmidt, J. B., & Calantone, R. J. 2002. Escalation of
commitment during new product development.
Journal of the Academy of Marketing Science, 30:
103–118.
Schmidt, J. B., Montoya-Weiss, M. M., & Massey, A. P.
2001. New product development decision-making
effectiveness: Comparing individuals, face-to-face
teams, and virtual teams. Decision Sciences, 32:
575– 600.
Senge, P. M. 1990. The fifth discipline: The art & prac-
tice of the learning organization. New York: Cur-
rency Doubleday.
Sengupta, K., & Abdel-Hamid, T. K. 1993. Alternative
conceptions of feedback in dynamic decision envi-
ronments: An experimental investigation. Manage-
ment Science, 39: 411– 428.
Sengupta, K., Abdel-Hamid, T. K., & Van Wassenhove,
L. N. 2008. The experience trap. Harvard Business
Review, 86(2): 94 –101, 137.
Sherman, J. D., & Keller, R. T. 2011. Suboptimal assessment
of interunit task interdependence: Modes of integra-
tion and information processing for coordination per-
formance. Organization Science, 22: 245–261.
Simester, D., & Zhang, J. 2010. Why are bad products so
hard to kill? Management Science, 56: 1161–1179.
Staw, B. M. 1976. Knee-deep in the big muddy: A study
of escalating commitment to a chosen course of ac-
tion. Organizational Behavior and Human Perfor-
mance, 16: 27– 44.
Staw, B. M., & Ross, J. 1978. Commitment to a policy
decision: A multitheoretical perspective. Adminis-
trative Science Quarterly, 23: 40 – 64.
Sterman, J. D. 1989. Modeling managerial behavior: Mis-
perceptions of feedback in a dynamic decision mak-
ing experiment. Management Science, 35: 321–339.
Sterman, J. D. 1994. Learning in and about complex sys-
tems. Reflections, 1(3): 24 – 49.
Sterman, J. D. 2000. Business dynamics—Systems think-
ing and modeling for a complex world. Boston:
Irwin McGraw-Hill.
Strauss, A., & Corbin, J. 1990. Basics of qualitative re-
search—Grounded theory procedures and tech-
niques. Newbury Park, CA: Sage.
Troy, L. C., Hirunyawipada, T., & Paswan, A. K. 2008.
Cross-functional integration and new product
February
success: An empirical investigation of the findings.
Journal of Marketing, 72(6): 132–146.
Van de Ven, A. H. 1986. Central problems in the man-
agement of innovation. Management Science, 32:
590 – 607.
Van de Ven, A. H. 2007. Engaged scholarship: A guide
for organizational and social research. New York:
Oxford University Press.
Van de Ven, A. H., Polley, D., Garud, R., & Venkataraman,
S. 2008. The innovation journey. New York: Oxford
University Press.
Van de Ven, A. H., & Poole, M. S. 1990. Methods for
studying innovation development in the Minnesota
Innovation Research Program. Organization Sci-
ence, 1: 313–335.
Voss, A., Rothermund, K., & Brandtstädter, J. 2008. Inter-
preting ambiguous stimuli: Separating perceptual
and judgmental biases. Journal of Experimental So-
cial Psychology, 44: 1048 –1056.
Weick, K. E., & Sutcliffe, K. M. 2006. Mindfulness and
the quality of organizational attention. Organization
Science, 17: 514 –526.
Whyte, G. 1998. Recasting Janis’s groupthink model: The
key role of collective efficacy in decision fiascoes.
Organizational Behavior and Human Decision
Processes, 73: 185–209.
Zhao, B., & Olivera, F. 2006. Error reporting in organiza-
tions. Academy of Management Review, 31: 1012–
1030.
APPENDIX
Derived Concepts and Codes
All statements and quotations refer to the Tech-
Car case.
Idea
Idea reflects the content (scope) of the product devel-
opment project.
II ⫽ Internal: An idea from the team influencing the
scope (e.g., “We are reviewing the task list to check if we
can increase the level of reuse”).
IE ⫽ External: an idea (change request) from the customer
influencing the scope (e.g., “Latest discussions with [the
lead customer] have led to potentially large changes in
the project”).
People
People defines the perceptions and emotions of the
team members related to the project.
PEP ⫽ General positive emotion about the project (e.g., “I
want to thank all of you for the excellent contribution
and dedication as well as in keeping the spirit high”).
PEN ⫽ General negative emotion about the project (e.g.,
“I am picking up some important signals regarding team
behavior. It is always easy to look at problems and issues
we have”).
2013 van Oorschot, Akkermans, Sengupta, and Van Wassenhove
PPTO ⫽ Optimistic perception of time (e.g., “The past
week we have spent a lot of effort in gaining momentum
in the project. . . . The current status is positive”).
PPTP ⫽ Pessimistic perception of time (e.g., “There is
some delay in finalizing the software”).
PPCO ⫽ Optimistic perception of costs (e.g., “The cur-
rent bottom-up budget for 2008 is close to the required
limit of €26 million”).
PPCP ⫽ Pessimistic perception of costs (e.g., “The bot-
tom-up budget indicates that we need much more budget
for 2008 than currently available”).
PPOO ⫽ Optimistic perception of output/quality (e.g.,
“Work . . . is progressing very well”).
PPOP ⫽ Pessimistic perception of output/quality (e.g.,
“Beware of unplanned interrupts!”).
PPRO ⫽ Optimistic perception of human resources (e.g.,
“Most probably we will be able to fill in at least four new
key roles during [the] next week”).
PPRP ⫽ Pessimistic perception of human resources (e.g.,
“We are experiencing growth pains”).
Transactions & Processes
Transactions & processes describe the engagements
people make with others to implement ideas and to
make the adaptations required to achieve desired
outcomes.
TTG ⫽ Adaptations in team size because of a gap be-
tween actual and planned team size (e.g., “We still need
a few key roles to be filled in”).
TW ⫽ A statement on the way of working in the team
(e.g., “I am focusing the team more and more to get the
correct planning process ongoing”).
TP ⫽ What priority is given to which task (e.g., “Gate 1 in
week 40 is top priority”).
Context
Context reflects changes in the environment of the
project that may influence the project team.
CI ⫽ Internal, within the team (e.g., “A survey was held
within the TechCar team”).
CC ⫽ Customer (e.g., “More potential customers are now
getting interested in our proposal”).
CE ⫽ External, outside the team but inside the firm (e.g.,
“This week we have had a discussion on the project with
senior management”).
Outcomes
Outcomes capture the actual deviations from the plan
in terms of
View publication stats
307
OTA ⫽ Actual project delay (e.g., “Gate 1 target is no
longer feasible and set to . . . week 19”).
OCA ⫽ Actual budget overrun (e.g., “[We] exceed the
budget by €700,000”).
OOA ⫽ Actual discovery of rework or extra work (e.g.,
“Gate 1 has been postponed by at least 3 weeks due to
new investigations that have to be closed first”).
Kim E. van Oorschot (kim.v.oorschot@bi.no) is an asso-
ciate professor of project management and system dy-
namics at BI Norwegian Business School. She received
her Ph.D. in industrial engineering from Eindhoven Uni-
versity of Technology. Her research interests include de-
cision making, trade-offs, and tipping points in dynami-
cally complex settings such as new product development
(NPD) projects.
Henk Akkermans (ha@uvt.nl) is professor of supply net-
work dynamics at Tilburg University. He holds a Ph.D. in
industrial engineering from Eindhoven University of
Technology. His present research interests are in behav-
ioral decision-making dynamics in decentralized organ-
izational networks, ranging from decision-making issues
in new service/product development via ramp-ups to
maintenance/asset management.
Kishore Sengupta (kishore.sengupta@insead.edu) is an
associate professor of information systems at INSEAD in
Fontainebleau. He received his Ph.D. in business from
Case Western Reserve University. His research examines
the role of managerial behaviors in the execution of com-
plex projects and the use of information technology at
individual, group, and organizational levels.
Luk N. Van Wassenhove (luk.van-wassenhove@insead.
edu) is professor of operations management and the
Henry Ford Chaired Professor of Manufacturing Technol-
ogy and Operations Management at INSEAD in Fon-
tainebleau. He received his Ph.D. in industrial manage-
ment from the Catholic University of Leuven. His
research is concerned with operational excellence, sup-
ply chain management, quality, continual improvement,
and learning.