INTRODUCTION
Information System (IS) project had been being notorious for its high
ratio of failing to complete as original plan. According to an investigation
(Anonymous, 1999), only 26% of software development projects are successfully
closed on planned schedule, within budget and with fulfillment to the
all function specification. As for the other projects, 28% were cancelled
before the development process completed and 46% were delivered in a way
of behind schedule, over budget, or reduced functionality. The phenomenon
of almost three-fourth IS projects fail to be completed as plan caused
numbers of Information Systems (IS) researchers` interest in attempting
to explain and resolve it (Brooks, 1987; Keil, 1995; Ewusi-Mensah, 1997;
Keil and Mann, 2000; Sabherwal et al., 2003). IS projects that
run wildly over budget and/or far behind the scheduled completion date
have been noticed in practitioner community and described as a runaway
systems in commercial press (Mehler, 1991). On the other hand, academicians
also drew on literature from the fields of organizational behavior, psychology
and decision science to frame this problem as an escalation decision process
and give it many theoretical reviews. No matter it is called runaway systems
or escalated IS project, the consequence that occurs tremendous resources
waste and misallocated asked both researchers and practitioners to find
solutions.
Previous researches found the factors that promote IS project escalation
can be grouped into four categories: project factors, psychological factors,
social factors and organizational factors (Keil, 1995). However, with
limited empirical studies the correlation between those factors and project
escalation is still not very clear. To date the most broadly accepted
theory to explain the motive of decision maker to escalate a project is
self-justification theory that claimed the decision maker continuously
commits resource to a failing course of action for a project because the
needs to justify the previous resource allocation decision (Brockner,
1992). In IS project context the complicated organizational and political
situation even push the decision makers to be too commit to a project
to extricate themselves out of the endless journey (Keil and Mann, 2000).
Considering the results obtained from previous researches, this exploratory
study attempts to discuss the possible influences to decision makers on
deciding to escalate a IS project if a formal exit mechanism existed.
Exit mechanism could be defined as a formal or informal institution system
of an organization to allow or command decision makers to exit his/her
project. Like security exchange market, such as New York Stock Exchange
(NYSE), enforces listed company with per share price lower than one dollar
for one month be unlisted to prevent those ill-operated or low investment
value company continuously absorb valuable capital. The project exit mechanism
can play the similar role to prevent decision maker from continuously
committing resources to a failing course of action, say, escalating project.
EXPLANATION OF ESCALATION
In many situations, decision makers exhibit a behavior to allocate some
resources, in spite of negative feedback is surrounding them, in the hope
of attaining some goals after having made an investment but finally find
they went nowhere. Organizational and social psychologists and economists
called such phenomenon as escalation. By definition, escalation situations
include repeated decision making in the face of negative feedback about
prior resource allocations, uncertainty surrounding the likelihood of
goal attainment and choice about whether to continue (Brockner, 1992).
Numerous theories were picked to explain why decision makers escalate
their commitments to a failing course of action. According to a viewpoint
of expectancy theory, escalation is explained as that decision makers
compare the gains and costs after estimating the probability of the goal
attainment if additional resources allocated and the value of success.
Given the subjective expected utility associated with the decision to
allocate additional resources for attaining goal is worth, the escalation
decision therefore become reasonable to be made. Based on such theoretical
ground, Levi (1982) shown that escalation decision was more likely to
be made by decision maker if the negative feedback were seen unstable.
Explained by the same theory, Rubin and Brockner (1975) found decision
makers persisted a task even if it were failing when they sensed that
the goal is closer and the value of success is relative high.
Self-justification theory is another, could be the most accepted, theory to
explain escalation. This viewpoint posits that decision makers become entrapped
in a previous course of action because they would not like to admit that the
prior decision was in vain. Since self-justification is a psychological state,
it is rather difficult to prove the theoretical propositions. However, there
were still lots of empirical tests conducted by researchers and provide supportive
evidences. Staw`s (1976) early study orthogonally manipulated the negative feedback
and the need of justification to test the predictions of self-justification
theory. The results shown that the mean amount of resources allocated to the
previous course of action was higher in the negative feedback/personal responsibility
condition than in all other combination and hence supported the proposition
that escalation associated with negative feedback and needs of justification.
The study conducted by Bazerman et al. (1982) further supported the prediction
that escalation will be greater in the high need to justify conditions compared
to the low need to justify conditions.
Some authors who are not convinced by the explanation of self-justification
theory suggested other perspectives. Whyte (1986) explained the escalation
from prospect theory. Originated from Kahneman and Tversky (1979), prospect
theory explains individual`s risk-taking propensities under conditions
of uncertainty. Simply stated, prospect theory predicts that individuals`
risk preference will change depends on if the movement from the reference
point is perceived to be in the positive direction or negative direction.
As more and more resources are allocated to the failing course of action,
according to this theory, decision makers have two alternatives that either
they cut their losses or continue to commit themselves to the previous
course of action. Given the assumption of loss aversion, decision maker
will prefer to allocate additional resources in the hope of turning around
the situation rather than to accept the sure loss exercised right after
admitting failure. In spite of the dispute continuing, Brockner (1992)
criticized this theory did not obtained enough empirical tests` support
on explaining escalation phenomenon.
There are other few theories try to give explanation to escalation. Bowen`s
(1987) decision dilemma theory suggested that in many cases, the decision
makers have not received clearly negative feedback about their initial
resource allocation. Therefore, the escalation decision may stem not from
the need to justify but rather from the other managerial motives such
as economic consideration or curiosity to know consequence of strategic
action. Self-presentation theory was borrowed by Brockner et al.
(1981) to discuss the effects of an on-looking audience or a social opponent
on escalation (Teger, 1980). Researchers found decision makers usually
escalated their commitment to a failing course of action just want to
save their face. Therefore, self-presentation theory is potentially important
in explaining the particular psychological state in escalation decision-making.
As so many theories were contributed to the research topic of escalation,
no any particular theory can fully explain the complex phenomenon. Although
self-justification theory was mostly supported by numbers of empirical
tests, this theory still only provided partial explanation of escalating
commitment at best. Managers and scholars need to know the situational
and dispositional factors that moderate the relative influence of internal
and external justification pressures on the entrapped decision maker (Brockner,
1992).
IS PROJECT ESCALATION AND DE-ESCALATION
The tremendous losses caused by so-called runaway systems had induced
practitioners and researchers` notice and proved the necessity of resolving
it. Regarding the phenomena of over resource budget and time delay on
project completion that associated with runaway systems, especially most
of them finally are going nowhere; those IS project in fact is a kind
of escalation. A case study of a large-scale expert system development
project (named CONFIG project) was first introduced by Keil (1995) to
discuss the escalation phenomenon in information systems field. In this
case study, the author found the escalation literature provides a promising
theoretical base for explaining this type of IT failure. By using the
taxonomy provided by Staw and Ross (1987), this longitudinal study investigated
specific project, psychological, social and organizational factors that
influence IS project escalation. Besides to test the factors in previous
escalation literature, this study found some new factors such as the emotional
attachment to the project (e.g., regard the project as my baby) and the
slack resources and loose management control in IS project context.
IS project is prone to be escalating because of the invisible characteristics
and the difficulty to measure the real status of project progress. The
worst is, when the escalation phenomenon was identified, the IS project
already escalated. Nevertheless, researchers were still trying to discriminate
the projects that are prone to be escalated and those are not. Keil and
Mann (2000) used different constructs derived from self-justification
theory, prospect theory, agency theory and approach avoidance theory to
build and test various logistic regression models for their ability to
discriminate between projects that escalate and those that do not. While
the constructs derived from the four theories were all significant in
logistic models, the completion effect construct derived from approach
avoidance theory provided the best classification of project with the
correct rate over 70%. In addition to the constructs derived from the
theories traditionally discussed in escalation literature, another study
suggested that the project management constructs seem could provide higher
power of discrimination (Keil et al., 2003). According to its findings,
a model developed based on project management constructs such as project
specification, estimation and monitoring and control can be a better classifier
than the models developed based on constructs derived from various escalation
theories. For the same objective but more focus on understanding the effectiveness
of different methodologies, a comparison study shown that an neural network
approach can perform a better job than logistical regression model (Zhang
et al., 2003).
By conducting two stimulated experiments, Sabherwal et al. (2003)
systematically examined the effects of project, psychological, social
and structural factors that influence the decision makers escalating commitment
to a failing course of action during four stages of an IS project. The
results support escalation in IS project and the project and psychological
factors seem to aid escalation.
Compared to the limited studies in IS project escalation, the studies
focus on IS project de-escalation even less to see. IS project de-escalation
was described as to redirect or to cancel a troubled project (Keil and
Robey, 1999). Though literature review, the authors identified 12 factors
potentially relevant to IS project de-escalation. By conducting a field
survey, both quantitative and qualitative data were collected for analysis.
The results shown that change in top management support, external shocks
to the organization, change in project champion, consideration of alternative
uses of funds supporting a project and visibility of project costs are
not significantly different between escalation and de-escalation phases.
Like the authors mentioned, while the absence of a significant difference
does not prove that those factors are unimportant, it does suggest some
interesting possibilities for further investigation. The study also found
that the de-escalation is usually triggered by top managers, internal
IS auditors and external auditors/consultants. IS users, project team
members and IS management all were rarely to trigger the escalation process.
These findings are especially interesting because it seems that the IS
project core members are hard to extricate themselves from the entrapment
of escalation.
Though a longitudinal case study of the IT-based baggage handling system
at Denver international airport, Montealegre and Keil (2000) gathered
qualitative data on the de-escalation of commitment to a failing course
of action and developed a process model to explain the phenomenon. This
model divided de-escalation process into four phases. The first phase
is problem recognition. The decision makers should be able to recognize
negative feedback and respond to external pressure at this phase. The
second phase is reexamination of prior course of action. If decision makers
pass the first phase, they have to clarify magnitude of problem and redefine
the problem. It is a beginning to redirect or turn around the prior failing
course of action. Once the problem severity had been identified and redefined,
the process goes into third phase to search for alternative course of
action. Decision makers have to identify and legitimize a new course of
action and manage the impressions at this phase because the internal and/or
external stakeholders could oppose the new direction. After the new course
of action obtaining well support from stakeholders, the de-escalation
process comes in the last phase for implementing an exit strategy. It
is about an art to close a fail project gracefully. The key activities
should be taken by decision makers at this phase is appealing to stakeholders
to accept the results and de-institutionalizing the project. The case
of Denver international airport gives researchers a conceptual model to
understand IS project de-escalation process. Regarding the problem recognition
the first phase to initiate the de-escalation process, some researchers
start asking why the negative feedback can not be conveyed to key decision
makers for prevent IS project from escalating. Specifically discuss the
reluctance to report bad news on troubled IS projects; Smith and Keil
(2003) developed a theoretical model to explain this phenomenon.
In this section we reviewed escalation literature both in general and
in the IS project context. The various results of the previous studies
grant a theoretical understanding to this study as a basis. If an IS project
can be accomplished as originally planed, there is no escalation problem
need to be discussed. Escalation must start from a project that fails
to meet the original plan, in terms of time and budget. Therefore, here
we define IS project escalation as a decision-making problem and frame
it as this: When decision makers face a goal-unmet IS project with negative
feedback, do they want to commit additional resources to complete in the
same course of action? Since there were many studies shown the psychological
factors such as the need to self-justification will significantly promote
the decision makers escalating their commitment to a failing course of
action, this study put focus on the relationship between a specific psychological
factor, the need to self-justification and the IS project escalation decision.
Duo to the special interests in finding a potential management mechanism
to reduce IS project escalation, this paper proposed an exit mechanism
and discuss it in the latter section.
PROPOSED DESIGN OF EXIT MECHANISM
Can the presence of an exit mechanism moderate the relationship between
need-to-self-justification and IS project escalation decision? Figure
1 shows a simple model for describing the relationship among the constructs
for discussion.
Previous researches tell us that decision makers are very likely to escalate
their commitment to a failing course of action just because they need
to justify the prior resource allocation decision is right. The perception
of the need-to-self-justification comes from various sources such as the
feeling of personal responsibility, job security, or organization culture.
No matter what is the reason behind the need-to-justify, decision makers
entrapped themselves in an ironic situation: Escalating the project prevents
the decision makers from instantly admitting failure and undertaking the
responsibility and consequences that sometimes means a demotion.
 |
| Fig. 1: |
Conceptual model |
 |
| Fig. 2: |
An exit mechanism design |
However, investing more valuable resources in a failing course of action
which only have a very small possibility of success make them eventually
will face the difficult decision again with a much worse condition.
Since the need-to-self-justification is a kind of psychological factor,
one effective way to reduce its influence is to lower the necessity to
explain why the decision makers terminate the project although they decided
to initiate this project. The evidence had been provided by some research
that found an organization with higher tolerance of failure could reduce
the possibility of IS project escalation. Besides reduce the influential
power of promoting factor directly, to find a moderator that decreases
the relationship between need-to-self-justification and IS project escalation
decision can also reduce the possibility of IS project escalation. This
study suggests the exit mechanism can play the role. Figure
2 is a flow chart of exit mechanism that is designed for one of the
worldwide leading semiconductor foundry company and can be use to elaborate
the notion. The semiconductor foundry company has a project governance
policy that ask all failed projects to go liquidate when the project due
or the budget run out. The project owner hence then can choose to continue
or exit this project. If project owner decide to continue, he/she need
to seek for another resource and the escalated project will be regarded
as a new project. That means even the escalated project finally success,
its credits are nothing to do with the first round project. On the other
hand, if project owner decide to exit, although he/she will get a punishment
to downgrade but still can execute smaller project next time to prove
his/her capability.
Given the exit mechanism, all projects are identified as fail and enter
liquidation process when the project due but can not successfully closed.
In spite of the need-to-self-justification still exist in decision makers`
mind; the decision to escalate the project is no use any more because
such action is irrelevant to save face.
Although at present there is no research related to the notion we proposed
above, this study suggests that the conceptual model can be tested by
the similar research design as Sabherwal et al. (2003). In their
study, a special designed scenario was provided to participants for simulating
a specific decision situation and collecting the response as data for
analysis. In present study, the research is designed to ask participants
to play the role of project decision makers and give them the same scenario
as Sabherwal et al. (2003) but add the proposed exit mechanism
presence. Since the other conditions remain the same, we can compare the
results with the results of Sabherwal et al. (2003) for understanding
the role that exit mechanism can play in present model.
CONCLUSIONS
IS project escalation causes huge amount of time, money and labor waste
and the schedule-delayed project can even put the enterprises in dangerous
situation if it concerned with competitive strategy. According to empirical
investigation, the phenomenon of IS project escalation is not rare and
the problem will be more and more severe because the complexity of both
business environment and information technology becomes higher and higher.
Hence, finding an effective management mechanism to mitigate the probability
of IS project escalation is necessary and fruitful to IT managers and
researchers. This research reviewed most of theoretical explanations of
IS project escalation and analyzed existing IS project de-escalation solutions
proposed by other scholars and practitioners. Unlike current solutions
emphasize on identifying individual precedent factors that causes IS project
escalation and reduce the effect of factor, this paper proposed a management
process and designed a feasible exit mechanism to release the psychological
defensive attitude that might drive project manager to escalate project.
ACKNOWLEDGMENTS
The authors wish to express their most sincere appreciation to anonymous
reviewers, who read the manuscript carefully and gave valuable advice.
Subscribe Today
