Understanding the Nature and Extent of IS Project Escalation:

Results from a Survey of IS Audit and Control Professionals

Mark Keil
Dept. of Computer Information Systems
College of Business Administration
Georgia State University
PO Box 4015
Atlanta, GA 30302-4015
(404) 651-3830
MKEIL@GSU.EDU
Abstract
Runaway IS projects continue to be reported regularly
in the trade press, but surprisingly little is known about:
(1) how widespread the problem actually is, and (2) the
factors that cause it to occur. Many runaway IS projects
appear to represent what can be described as escalating
commitment to a failing course of action. A survey of
Information Systems Audit and Control Association
(ISACA) members was undertaken in order to understand
more about the prevalence of IS project escalation and
the factors that cause it.
The results are startling:
Escalation occurs in 30-40% of IS projects and projects
that escalate are rarely completed and implemented
successfully. What is more, escalation appears to be
caused by a combination of project management as well
as psychological, social, and organizational factors.

1. Introduction
Recent estimates suggest that runaway information
systems (IS) projects are costing U.S. organizations
billions of dollars each year in both cost overruns and
failed projects [7]. The problem of runaway projects was
first observed back in the early 1970s when Stephen
Keider, in industry consultant, observed that some IS
projects never seem to terminate. "Rather," he said, "they
become like Moses, condemned to wander till the end of
their days without seeing the promised land" [8]. More
than twenty years later we still have software projects
that fit Keider's description. In this paper, the term
runaway is used to describe an information systems
(IS) project that seems to take on a life of its own,
continuing to absorb valuable resources without ever
reaching its objectives [8, 13, 14].
While runaway systems projects have been the focus
of numerous press reports [1, 4, 6, 12, 16, 18], little
is

Joan Mann
MIS/DS
College of Business & Public Administration
Old Dominion University
Hughes 2096
Norfolk, VA
(757) 683-3488
JEM100F@ECONOMY.BPA.ODU.EDU
known about how commonly this problem occurs or what
can be done to identify and prevent runaway projects.
The Standish Group--a Massachusetts-based consulting
organization--estimates that in 1995 alone, U.S.
companies spent $81 billion on canceled software projects
and an additional $59 billion in cost overruns for software
projects that would eventually be completed [7]. Since
literally billions of dollars may be at stake, preventing
runaway IS projects should be of great concern to IS
professionals.
While it is true that most runaways are eventually
terminated or significantly redirected, there is evidence
suggesting that these projects are allowed to continue for
too long before appropriate action is taken. While the
monetary costs associated with these runaways is quite
visible, less tangible costs include: (1) the failure to solve
real business problems for which the system was
intended, and (2) the opportunity costs associated with
spending valuable resources on a failing IS project when
these resources could have been put to alternative uses.
For all of these reasons, it is important to understand
more about the actual frequency of this phenomenon, the
factors that promote runaway projects, and the steps that
IS professionals can take to minimize the risks to their
organizations.

2. Background
Many runaway IS projects represent what can be
described as continued commitment to a failing course of
action, or "escalation" as it is called in management
1

literature [2]. Escalation of commitment to an IS project

Escalation does not necessarily imply an increasing rate of investment

over time, but rather, refers to a growth in the cumulative amount of
resources

Proceedings of The Thirtieth Annual Hawwaii International Conference

on System Sciences ISBN 0-8186-7862-3/97 $17.00 1997 IEEE

1060-3425/97 $10.00 (c) 1997 IEEE

has been documented in the literature [9, 10], but little is

known about the actual prevalence of this phenomenon
among IS projects.
Previous research suggests that escalation is a complex
phenomenon that may be influenced by many different
factors. Figure 1 groups these factors into four categories
based on a typology proposed by [17].
Project
Factors

Psychological

Project

Factors

Escalation

Socia
l
Factor
s

Organizationa
l
Factors

Figure 1: Typology of factors that influence

escalation behavior

justification, and social norms that dictate what is

considered as socially acceptable behavior [15]. Projects
are more prone to escalation, for example, when
competitive rivalry exists between the group that is
funding the software development project and the group
that is to serve as the targeted customer or user.
Escalation is also more likely to occur when external
stakeholders have been led to believe that the project
is (or will be) successful or when social norms of
behavior favor "staying the course" in the face of
adversity.
Finally, organizational factors--those involving
the structural and political environment that
surrounds a
project--can also promote escalation.
These factors
can
include political support for the project from powerful
managers, the extent to which a manager's power or
political fortunes are tied to the success of the project, and
the degree to which the project becomes institutionalized
with the goals and values of the organization [17].
invested over time. Thus, escalation can be thought of as
continued commitment.

Project factors include the costs and benefits

associated with the project as well as the expected
difficulty and duration of the project. Projects are more
prone to escalation when they involve a large
potential payoff, when the project requires a long-term
investment in order to receive any substantial gain, and
when setbacks are perceived as temporary problems
that can be overcome [17].
Psychological factors are those that cause managers to
become convinced that things do not look so bad after all,
or that persistence will eventually pay off [2]. Two such
factors include the manager's previous experience in
handling similar projects and the degree to which the
manager feels personally responsible for the outcome
of the project [17]. Generally speaking, projects are
more prone to escalation when there is a previous
history of success and when there is a high level of
personal responsibility. Another psychological factor is
the human tendency to "throw good money after bad" in
an effort to turn around a failing project, or the so-called
"sunk cost effect" [5]. Finally, managers may also
engage in a type of self-justification behavior in which
they commit additional resources because to do
otherwise would be tantamount to admitting that their
earlier decisions were incorrect.
Social factors can also promote escalation.
These
factors include competitive rivalry that may exist
between different groups in an organization, the need for
external

Proceedings of The Thirtieth Annual Hawwaii International Conference

on System Sciences ISBN 0-8186-7862-3/97 $17.00 1997 IEEE

1060-3425/97 $10.00 (c) 1997 IEEE

3. Research objectives and methodology

The purpose of this study was:
(1) to gather
information concerning the frequency of IS project
escalation (that is, headlines aside, how often does this
problem occur in practice?), and (2) to identify the factors
that may cause IS project escalation to occur.

3.1. Approach used to gather data

To gain insight concerning these questions, a survey
was developed and administered to a large sample of IS
audit and control professionals selected from the U.S.
membership database of the Information Systems Audit
and Control Association (ISACA). IS auditors were
chosen as subjects for the study because it was felt that
was to motivate people to feel rewarded by returning
the survey.
To provide anonymity for participants and to maintain
control over the membership database, the ISACA
research organization handled the addressing of both the
letters and the outgoing envelopes. Survey recipients
were instructed to return their completed survey
directly to the researchers in a pre-addressed businessreply envelope, but the identities of the individual
respondents were withheld from the researchers, thus
encouraging a candid response to the survey questions.
To further improve the response rate
(while
maintaining subjects anonymity), a follow-up postcard
was sent to all survey recipients) reminding individuals to
complete and return the survey if they had not already
done so. The follow-up reminder was timed to arrive two
weeks after the initial mailing.

they would provide an unbiased perspective given their

prescribed job role.
A mail survey was chosen as the most cost effective
means of collecting data on a large number of projects.
To guard against low response rate, which is viewed as
the major risk of conducting a mail survey [11], we
followed several key steps from Dillmans Total Design
Method (TDM) [3]. TDM is a widely accepted approach
for maximizing survey response rates, thus minimizing
the potential bias that can result from non-response. The
cover
letter
accompanying
the
survey was
carefully crafted to meet TDM guidelines.
The
paragraphs of the letter, for example, were designed
to convey the importance of the research question,
the value of the results that could be obtained, and the
critical importance of each individuals input. The goal
behind doing this
The survey itself was based on a careful review of
both the software project management literature and the
escalation literature aimed at determining the set of
factors most likely to be associated with project
escalation. Based upon this review, the survey included
both project management related factors as well as a set
of psychological, social, and organizational factors
derived from the escalation literature.
The project
management related factors included in the survey are
shown in Table
1.
The six project management related factors included
in the survey represent common themes found in our
review of the software project management literature.
While there are other project management related factors
(e.g., staffing problems), that could have been
included, we

3.2. Sample selection

The sampling design used in this study was to select a
sample of ISACA members who would be most likely to
be involved in information systems development.
Toward this end, the study was focused on internal and
external IS auditors. By using the ISACA membership
database which contains self-reported job category
information, we were able to limit the pool of
potential participants to those individuals who were
likely to have the greatest exposure to information
systems development projects. This pool of individuals-representing all U.S. ISACA members who described
themselves as an IS Audit Manager, IS Auditor, Internal
Auditor, or External Auditor--included approximately
2500 ISACA members in the U.S.

3.3. Survey development and pre-testing

Proceedings of The Thirtieth Annual Hawwaii International Conference

on System Sciences ISBN 0-8186-7862-3/97 $17.00 1997 IEEE

1060-3425/97 $10.00 (c) 1997 IEEE

chose to focus only on those factors that could most

reasonably be linked to escalation behavior.
Table 1: Project management factors included in
the survey
Factor
Specification

Definition
The degree to which the project team
adequately understood user needs.
Estimation
The degree to which the project team
adequately projected the timeframe of the
project and the resources needed to complete
the project.
Planning
The
degree to which the project team
adequately addressed issues of scheduling, risk
identification and manpower assignments.
Resources
The degree to which there were sufficient
resources allocated to complete the
project.
Monitoring
The degree to which the project team was
able to spot problems in the project.
To increase theThereliability
of the
survey
Control
degree to which
the project
teaminstrument,
was able
get developed
the project toback
on track
multiple questions towere
measure
eachwhen
of the
problems arose.

The psychological, social, and organizational factors

derived from the escalation literature and included in the
survey are shown in Table 2.
Table 2: Psychological, social, and
organizational factors included in the survey

The survey was pre-tested during Spring 1995 with a

sample of seven IS audit and control professionals
selected from the ISACA membership. Each member
who participated in this pre-test was interviewed inperson for a period of approximately one hour during
which s/he was asked to complete the survey in the
presence of one of the researchers.
During these
interviews, participants were encouraged to identify
questions that did not make sense as worded, were
difficult to interpret, or could not be easily answered.
Interviewees were also encouraged to suggest additional
factors that might cause escalation to occur, but which
were not captured on the survey. Both versions of the
survey were pre-tested in the same manner. The pretesting was concluded after seven interviews when it
became apparent that no new wording problems or
escalation factors were surfacing. The pre-testing with
ISACA members resulted in several modifications to the
survey instrument based on the comments and feedback
that were received.
Following the pre-test, a pilot test was conducted in
which the survey was administered to a sample of
approximately 300 IS audit and control professionals.
The size of the pilot was determined based upon an
estimate of survey response rate and the number of
variables on the survey that would be subjected to
statistical analysis. The purpose of the pilot, which was
conducted during Summer 1995, was to evaluate the

underlying factors identified in the literature search. Two

different versions of the survey instrument were then
developed: one focused on gathering information about
cases of IS project escalation and the other focused on
projects that did not escalate. The purpose of the latter
version of the survey was to provide a reference point, or
baseline, to determine whether the pattern of factors
Factor
Definition
associated with projects
that escalate is significantly
The degree to which the Primary DecisionNeed for
different
from theMaker(s)
pattern
of factors
associated
Justification
are likely
to feel responsible
for the with
of the project and the extent to
projects that do notoutcome
escalate.

which withdrawal would cause them to lose

and tovalidity
of the
instrument and to
face.degree
Sunk cost/ reliability
The
which the amount
already
completionfine
level tune
invested
or the
percent completed
the
instrument
beforeinfluences
administering it on a
the decision
large- scale
basis.to continue.
The pilot also provided information
Goal
The degree to which the projects Primary
on
expected
response
was useful in
Congruency
Decision-Maker(s) and rates
Senior which
validating
the estimated
sample
Management
share the same
goals. size that would be
Informationneeded The
which Senior
Management has of the survey.
in degree
the to
full-scale
administration
Asymmetry
same project status information as the
For thethe
pilot,
the
Primary Decision-Maker(s).
300 members
were
split
Research and
The degree
to which
theevenly
project isbetween
perceived those asked to
select an
escalated
project
thosepayoff
asked to select a
Development
to have
a large up-front
cost,and
long-term
Perspectivenon- escalated
structure, orproject.
large potential
payoff
This
wasif done to determine if
successfully completed.
the potential
response rate would be similar for both
Strategic
The degree to which the project is perceived
the survey
to insureability
that tothere would be
Importanceversions
as of
critical
to the and
organizations
or survive.
enoughcompete
completed
surveys to compare the reliability

and validity of the two versions. The results of the pilot

revealed that both
versions
of
the
survey
instrument
had
good reliability and validity and
similar response rates. There were, however, several
measurement items that were reworded or dropped
based on the results of the pilot. These changes were
made in an effort to further improve the quality of the
survey instrument.

3.4. Administration of the full-scale

survey
Following the pilot study, the administration of
the full-scale survey took place during Fall 1995. The
full-

Proceedings of The Thirtieth Annual Hawwaii International Conference

on System Sciences ISBN 0-8186-7862-3/97 $17.00 1997 IEEE

1060-3425/97 $10.00 (c) 1997 IEEE

scale administration involved 2,231 ISACA members and

represented those individuals who met one of the four job
categories described earlier and who had not participated
in either the pre-test or pilot phases of the study. For the
full-scale administration of the survey, a decision was
made to split the sample 70:30 so that 70% of the
participants would receive the escalation version of the
survey and 30% would receive the non-escalation version
of the survey. This was done to maximize the size of the
escalation sub-sample while insuring an adequate number
of projects in the comparison group. In all cases, the
decision was random as to whether a participant received
an escalation or a non-escalation survey.
Participants who received the escalation survey (n =
1,549) were asked to select a project that they were
familiar with that fit the definition of project escalation
(i.e., a troubled project--either abandoned or completed-that continued to receive resources even though the
respondent believed that the project should have been
discontinued or redirected). In contrast, participants who
received the non-escalation version of the survey (n =
682) were asked to select a completed project that
progressed smoothly enough that the respondent never
thought it should be discontinued or redirected. Having
selected a project that met the desired criterion,
respondents in both versions of the survey were then

asked to answer more than 50 questions designed to

measure whether certain factors that might be associated
with escalation were present and, if present, the
importance of the factor in explaining why the project
was continued. It is important to note that the two
different versions of the survey were identical except
for the instructions regarding what type of project to
select, thus allowing the non-escalation survey group to
serve as a baseline for comparison purposes. In addition
to questions that were to be completed about a
specific project (one that escalated or one that did not),
both versions of the survey contained an identical set of
questions designed to:
(1) gather demographic
information, and (2) gauge the frequency of escalation
based on the observations and experience of the
respondents.

4. Results and discussion

4.1. Response statistics and non-response bias tests
Table 3 summarizes the response rates for the two
different versions of the survey.
In total, 579
surveys were returned, yielding a 26% response rate
overall. Nearly sixty percent of the surveys received
were fully

completed.
In this and the next three sections of the
paper (i.e., sections 4.1-4.4) we discuss the results of the
combined analysis which includes both versions of
the survey.
Table 3: Survey response rates for the two different
versions of the survey
Survey Type
Escalation survey
Non-escalation survey
(control group)
Total

#
Sent
1,549
682

#
Retrnd
420
156

Rspns.
Rate
27%
23%

2,231

576

26%

# Fully
Completed
243
91
334

As mentioned earlier, non-response bias can be a

significant hindrance in the interpretation of results from
a mail survey.
Non-response represents a threat
when those individuals who respond to the survey differ
in a systematic way from those who choose not to
respond. If this happens, any extrapolation from the
sample to the population becomes suspect because the
sample may no longer be representative of the population
from which it was drawn.
One method of testing for non-response bias is to
compare attributes of the survey respondents with
attributes of all individuals receiving the survey. In this
study, the state of residence was known for everyone
in the sample.
Regional non-response bias was
calculated by first assigning each state to a region
and
then comparing the regional frequencies of

Using non-parametric statistical tests (e.g., MannWhitney and Kruskal-Wallis), there was no discernible
difference between the two waves on any of the
above variables.
While the above tests cannot guarantee the absence of
any non-response bias, they strongly suggest that the
responses
received
are representative
of
the
population that was surveyed.

4.2. Survey respondent demographics

Survey respondents had an average of 8.7 years of
experience as an information systems audit and control
professional.
Seventy-two percent of the respondents
described themselves as IS auditors or IS audit managers.
The remaining respondents were external auditors or
carried some other job title. The survey sample included
organizations of various types and sizes. Figure 2 shows
the different types of organizations included in the survey
and Figure 3 indicates the size of the organizations in
terms of number of employees.

res
de
to
reg
al

Proceedings of The Thirtieth Annual Hawwaii International Conference

on System Sciences ISBN 0-8186-7862-3/97 $17.00 1997 IEEE

1060-3425/97 $10.00 (c) 1997 IEEE

fr
nc
of
fu
maili

g
usi
the
squ
tes

The chi-square test

indicated there was no
significant difference

between the respondents and the full mailing list on

region.

Other
22%

Transp
2%

Financial
39%

Mfg
13%
Health
3%

Using the date that a survey was returned, an

alternative to the chi-square test was used to evaluate
non-response bias based upon several other demographic
fields including:
experience, industry category,
number of employees, and number of IS employees. By
grouping
the surveys that were received into two waves (n= 366,
n=210, respectively) based on the date returned, it was
possible to determine whether later respondents were
significantly different from earlier respondents on any of
3
these variables. In this type of wave analysis, responses
from later waves are considered to be surrogates for nonrespondents.

Govt
17%

Figure 2: Types of organizations in the survey

sample (valid n=484)

500-999
7%

100-500
9%

<100
1%

5,0009,00 0
19%

Surveys that were partially completed generally included demographic

information as well as estimates of escalation frequency. Fully
completed surveys included this information as well as complete answers
to a series of

Consistent with the broad size range of organizations

surveyed, the survey sample included organizations with
both large and small IS organizations.

Figure 3: Size of organizations in the survey

sample in terms of number of employees
(valid n=485)

stages of a project (as opposed to the end of a project)

will be in a better position to observe escalation and to
understand the factors associated with it.

4.3. Respondents level of exposure to information

systems projects
As mentioned earlier, survey respondents had, on
average, considerable job experience in the IS audit and
control area, suggesting that they would be in a good
position to have observed escalation even if it occurs
infrequently.
However, given that auditing IS
development projects is but one of many job tasks
undertaken by IS audit and control professionals, one
concern in a survey of this type is whether the
respondents have a sufficient level of exposure to
IS
projects to answer questions concerning the factors that
may cause project escalation. To address this concern,
the survey included two questions designed to gauge the
respondents degree of association with IS projects.
The first question concerned the respondents role in
IS projects. A reasonable assumption is that IS audit and

>10,000
36%

1,0004,99 9
28%

more than 50 questions pertaining to a particular project selected by the

respondent.
3
For this analysis, returned surveys were split into two waves,
those
received within two weeks of the initial mailing (i.e., before the followup mailing could have been received and acted on) and those received
after the follow-up mailing.

Trade
4%

Test ing
13%

Imp
l
10%

Cod ing
7%

Post -Impl
7%

Desig n
15%

Planning
24%

A nalysis
24%

control professionals who have more contact with a

project will be in a better position to observe
escalation and to understand the factors associated
with it.
The survey results, shown in Figure 4,
revealed that approximately half of the respondents
were associated in a very significant way with the IS

Proceedings of The Thirtieth Annual Hawwaii International Conference

on System Sciences ISBN 0-8186-7862-3/97 $17.00 1997 IEEE

1060-3425/97 $10.00 (c) 1997 IEEE

projects they reported on.

At a minimum, these
individuals were responsible for evaluating projects on a
regular basis and sometimes served as a member of the
development team or even the project manager.

Figure 5: Phase at which respondents

become involved in IS projects (valid n=329)
The survey results, shown in Figure 5, suggest that
approximately half of the respondents became associated
at a very early stage (i.e., during planning or
requirements analysis) with the projects they reported on.
Therefore, based on both their role and the phase at
which they became involved, the majority of the
respondents should have been well-positioned to provide
knowledgeable answers to escalation-related questions.

4.4. Frequency of escalation

Other
22%

Evaluated
Once or
Twice
30%

Project
Manager
5%

Team
Member
11%

Regularly
Evaluated
32%

Figure 4: Survey respondents role in IS projects

(valid n=335)
As a second means of assessing the degree of
association with IS projects, respondents were asked
to indicate the phase when they first become associated
with a project. A reasonable assumption is that IS audit
and control professionals who become involved at the
early
escalation can be derived from a survey question that
asked of the last 5 projects with which you have been
associated . . . how many were cases of project
escalation? To examine this question, a restricted
view of the dataset was prepared which included only
those respondents who had experience with at least five
projects coupled with three or more years of
relevant job experience (n=361). Respondents with
little job experience or those with exposure to less
than five projects would not have been able to answer
the question in a meaningful way. Thus, this approach
was believed to be necessary in order to insure that
the escalation frequency estimates derived from the
dataset reflect the experience of subjects who have had
enough exposure to IS projects to comment on the
frequency of the escalation phenomenon..

One of the primary purposes of this research was to

determine whether or not project escalation was a
frequently occurring phenomenon. Before presenting the
results on this point, it should be noted that relying on IS
auditors as a means of estimating the frequency of
escalation represents a possible limitation of this study. It
is possible, for example, that auditors may be called in
more frequently on large, complex, or troubled
projects. If so, the estimates that auditors provide
regarding the frequency of escalation may be somewhat
inflated. Based on both pretest and follow-up interviews
with approximately a dozen IS auditors, however, it
would appear that many firms routinely assign auditors to
the majority of their system development projects
without
much regard as to the relative size or health of the
project. Moreover, as the survey data suggest, it is often
the case that IS auditors are assigned to a project from the
outset before there could be any real signs of trouble.
Recognizing the above as a possible limitation, both
versions of the surveys contained an identical set of
question items designed to measure the frequency of
escalation. One indication of the actual frequency
of
Of the last 5 projects with which you have
been associated, how many were cases of
project escalation?
30%

28%

25%
19%
20%
15%
10%
5%
0%

Proceedings of The Thirtieth Annual Hawwaii International Conference

on System Sciences ISBN 0-8186-7862-3/97 $17.00 1997 IEEE

1060-3425/97 $10.00 (c) 1997 IEEE

20%
16%
10%
8%

Respondents included in this analysis had an average

of 10.5 years of work experience as an IS audit and
control professional. The results of the analysis are
shown in Figure 6. As shown in Figure 6, 81% of th e
respondents indicated that on e or more of th e last five
projects they had been associated with were cases of
project escalation.
The mean response was 1.92,
suggesting that escalation occurs (on average) in 38% of
all IS projects.
As a means of cross-checking, or triangulating, to
gauge the frequency of IS project escalation, respondents
were also asked: Of all the projects with which you
have been associated during your years as an
information systems control professional, what
percentage would you classify as cases of project
escalation?
To remove any ambiguity in the
question, escalation was clearly defined as troubled
projects which continued to receive resources even
though you thought the project should have been
discontinued or redirected. Using the same sub-sample
of experienced IS audit and control professionals (n=361),
the mean response to this question was 0.304 indicating
that escalation occurs in 30% of all IS projects.
Finally, as an additional means of triangulation, the
question was asked in a slightly different way: In your
judgment what percentage of all IS development
projects are cases of project escalation.
The mean
response to this question was 0.383 indicating that
escalation occurs in 38% of all IS projects.
Taken together, the three measures described above
provide a remarkably consistent view of how frequently
IS project escalation occurs; the data strongly suggest that
30-40% of all IS projects involve some degree of
project escalation.

Figure 6: Observed frequency of escalation

based on last five projects (n=361)

4.5. Duration of escalation

Having determined the frequency at which escalation
occurs, it is appropriate to ask: How long is the duration
of escalation? This was operationalized by calculating
how long projects were allowed to continue after the
point at which an IS auditor believed they should have
been terminated or redirected. By capturing key dates in
the escalation survey, it was possible to calculate the
number of months of escalation. Escalation time among
the projects surveyed ranged from 1 mon th
to 255
months (i.e., 21 years!). As shown in Figure 7, nearly
75% of the projects escalated for two years or less.
Among projects that escalated, the average escalation
time was 21 months with half of the projects escalating for
15 or more months.

40%
35%
30%
25%
20%
15%
10%
5%
0%
112
mo

1324
mo

2536
mo

3748
mo

4960
mo

>60
mo

Figure 7: Duration of escalation (n=243)

Proceedings of The Thirtieth Annual Hawwaii International Conference

on System Sciences ISBN 0-8186-7862-3/97 $17.00 1997 IEEE

1060-3425/97 $10.00 (c) 1997 IEEE

4.6. Comparison of projects that escalated and

those that did not
Having established that escalation occurs rather
frequently and with some duration, it is important to ask
whether projects that escalate are really different from
projects that do not escalate. To answer this question, we
focus on the results that were obtained from the sample
of fully completed surveys on escalated projects (n=243)
and compare these results with those that were obtained
from the sample of fully completed surveys on nonescalated projects (n=91).
The comparison reveals
that projects that escalate are significantly different
(from non- escalated projects) along dimensions that
are managerially relevant. Figure 8, for example, shows
the degree to which escalation and non-escalation
projects exceed their budgets and schedules.
As
shown in the figure, projects that escalate run between 23 times their original budgets and schedules, whereas
projects that do not escalate exceed their original
budgets and schedules by an average of about 20%. As
another point of comparison, more than 82% of the
projects that escalated also exceeded their budgets,
whereas only 48% of the non-escalation projects
exceeded their budgets.
In addition, 91% of the
projects that escalated exceeded their original schedule as
compared with 58% of the non- escalation projects.
160%

7
6
5
4
3
2
1

Escalation projects

Non-escalat ion p ro ject s

Figure 9: Comparison of escalation and non4

escalation projects
The severity of the escalation problem comes into
clearer focus when one examines the final outcome of the
projects that escalated, as shown in Figure 10. As
indicated in the figure, less than one quarter of the
projects that escalated were completed and implemented
successfully. In contrast, 84% of the projects in the nonescalation sample were completed and implemented
successfully. This suggests that reducing the incidence of
project escalation is one way to achieve higher success
rates in IS projects.

140%

Abando
n

120%
100%

Escalation projects

80%

Completed
and
Successf
ul
23%

Non-escalat
ion projects

60%
40%

Othe
r
5%

20%
0%

%Over
B
udget

%Lo
nger
than
Exp ect
ed

Complete
d,
thenWithdraw
n
8%

Figure 8: Degree to which escalation and

non-escalation projects exceed their budgets
and schedules

Figure 9 compares escalation vs. non-escalation

projects along these and other dimensions. As shown in
the figure, escalation projects were larger in size, more
complex,
and more costly than
non-escalation
projects. They were also judged to be significantly less
successful than projects that did not escalate.

before
Completio
n
18%
Complete
d, never
Impl
5%

Complete
d, Less
than
Successf
ul
18%

Partiall
y
Complete
d
23%

Figure 10: Final outcome of escalated projects

(valid n=243)

All questions were similar to the following: Compared to other IS

projects undertaken in your organization was this project . . .
smaller in size 1 2 3 4 5 6 7 larger in size

4.6. Factors associated with escalation

Having established that escalated projects are different

from non-escalated projects, it is important to understand
what factors are associated with project escalation. As

mentioned earlier, the survey included a number of

project management factors as well as psychological,
social, and organizational factors that might be associated
with escalation. The purpose of this portion of the survey
was to determine the degree to which these various
factors were believed to be associated with escalation.
Table 4 shows the most frequently cited project
management factors that were judged to be present in
cases of project escalation. The percentages reflect the
fraction of respondents who indicated that a particular
factor was present. As indicated in the table, there were
seven different project management factors that were
commonly present in the sample of projects that
escalated. Each of these factors was cited by at least
70% of the respondents. Moreover, each factor was
judged to be important (averaging 4.0 or higher on a 5point scale that ranged from not important to
extremely important) in explaining why an escalated
project continued.
The list of project management
factors associated with escalation suggests that better
estimation of time, scope, and required resources, better
monitoring and control, and better planning, would go a
long way toward reducing the incidence of project
escalation.
Table 4: Most frequently cited project management
items associated with escalation
1. Underestimation of time to complete the project (83%)
2. Senior management did not monitor project closely enough (78%)
3. Underestimation of necessary resources (77%)
4. Size or scope of project underestimated (75%)
5. Inadequate project control mechanisms (72%)
6. System specifications kept changing (71%)
7. Inadequate planning (71%)

Table 4, alone, however, doesnt reveal the whole

story, as there also appear to be a number of
psychological, social, and organizational factors
associated with the projects that escalated. Table 5 shows
the most frequently cited psychological, social, and
organizational factors that were judged to be present in
cases of project escalation. The percentages reflect the
fraction of respondents who indicated that a particular
factor was present. As indicated in the table, there were
nine different psychological, social, and organizational
factors that were commonly present in the sample of
projects that escalated. Each of these factors was cited
by at least 50% of the respondents. Four of the nine
items were judged to be important (averaging 4.0 or
higher on a

5-point scale) in explaining why an escalated project

continued.
Table 5 contributes to our understanding of escalation
by confirming that there are in fact psychological, social,
and organizational factors that contribute to escalation; in
other words escalation involves more than simple
mismanagement of projects.
The list
of
psychological, social, and organizational factors suggests
that escalation is exacerbated by situations in which:
abandonment would make the primary decision-maker
look bad, completion is seen as important to the
organizations ability to compete, the primary decisionmaker distorts or conceals negative information
concerning the project, or the organization has a
loose/informal process for justifying projects.
Table 5: Most frequently cited psychological,
social, and organizational items associated with
escalation
1. Primary decision-maker repeatedly expressed support (85%)
2. Abandonment would make the primary decision-maker
look bad (76%)*
3. Senior management provided continued funding or protection
(75%)
4. Primary decision-maker expressed a we have come too far
to quit now attitude (70%)
5. Primary decision-maker initiated project or was
extensively involved with it (70%)
6. Completion seen as important to organizations ability
to compete (64%)*
7. Failure would have a negative impact on primary
decision- maker (57%)
8. Primary decision-maker distorted or concealed
*denotes
thatinformation
item was rated
as important (i.e. > 4 on a 5-point scale)
negative
(55%)*
9. Loose/informal process for justifying projects (54%)*

5. Conclusions
The results of this study indicate that IS project
escalation is a frequent occurrence and that it is driven
by a combination of project management as well as
psychological, social, and organizational factors. Armed
with this knowledge, IS professionals should not
underestimate the important role that psychological,
social, and organizational factors can play in the
successful management of IS projects. In the past, IS
managers have relied upon traditional project
management techniques to control IS projects. While the
traditional approaches are useful, they are based on a
rational approach to project management and thus tend to
ignore some of the other dimensions that seem to be
associated with project escalation.

6. References

[3] Dillman, D.A. Mail and Telephone Surveys, John Wiley &
Sons, New York, 1978.

[1] Betts, M. "Feds Debate Handling of Failing IS Projects,"

Computerworld, November 2, 1992, p. 103.

[4] Ellis, V. "Audit Says DMV Ignored Warning," Los Angeles

Times, August 18, 1994, pp. A3-A24.

[2] Brockner, J. "The Escalation of Commitment to a Failing

Course of Action: Toward Theoretical Progress," Academy
of Management Review (17:1), 1992, pp. 39-61.

[5] Garland, H. "Throwing Good Money After Bad: The

Effect of Sunk Costs on the Decision to Escalate
Commitment to an Ongoing Project," Journal of
Applied Psychology (75:6), 1990, pp. 728-731.

[6] Gibbs, W.W. "Software's Chronic Crisis," Scientific

American, (273:3), September 1994, pp. 86-95.
[7] Johnson, J. "Chaos: The Dollar Drain of IT Project
Failures," Application Development Trends (2:1), 1995, pp.
41-47.
[8] Keider, S.P. "Why Projects Fail," Datamation, December,
1974, pp. 53-55.
[9] Keil, M., Pulling the Plug: Software Project Management
and the Problem of Project Escalation, MIS Quarterly,
(19:4), December 1995, pp. 421-447.
[10] Keil, M., Mixon, R., Saarinen, T. and Tuunainen, V.
"Understanding Runaway Information Technology Projects:
Results from an International Research Program Based on
Escalation Theory," Journal of Management Information
Systems (11:3), 1995, pp. 67-87.

[11] Kerlinger, F.N. Foundations of Behavioral Research, Holt,

Rinehart and Winston, New York, 1986.
[12] Kindel, S. "The Computer That Ate the Company,"
Financial World, (161:7), March 31, 1992, pp. 96-98.
[13] Lyytinen, K. and Hirschheim, R. "Information Systems
Failures--A Survey and Classification of the Empirical
Literature," In Oxford Surveys in Information Technology,
P. I. Zorkoczy (Ed.), 4, Oxford University Press, Oxford,
1987, pp. 257-309.
[14] Meredith, J. "Project Monitoring For Early Termination,"
Project Management Journal (19:5), 1988, pp. 31-38.
[15] Ross, J. and Staw, B.M. "Organizational Escalation and
Exit: Lessons From the Shoreham Nuclear Power Plant,"
Academy of Management Journal (36:4), 1993, pp. 701732.
[16] Rothfeder, J. "It's Late, Costly, Incompetent--But Try
Firing a Computer System," Business Week, November 7,
1988, pp. 164-165.
[17] Staw, B.M. and Ross, J. "Behavior in Escalation
Situations: Antecedents, Prototypes, and Solutions," In
Research in Organizational Behavior, B. M. Staw and L.
L. Cummings (Ed.), 9, JAI Press Inc., 1987, pp. 39-78.
[18] Tomsho, R. "Real Dog: How Greyhound Lines ReEngineered Itself Right Into a Deep Hole," The Wall Street
Journal, October 20, 1994, pp. A1-A6.