Abstract
Information technology (IT) a common and costly problem. While much is known about the factors that promote escalation behavior, little is known about the actual escalation process. This article uses an in-depth case study to construct a process model of escalation, consisting of three phases: drift, unsuccessful incremental adaptation, and rationalized continuation. Each phase encompasses several within-phase escalation catalysts and the model also identifies triggering conditions that promote transition from one phase to the next: project framing (antecedent condition), problem emergence, increased problem visibility, and imminent threat to project continuation (triggering the outcome deescalation). The results show that escalation is not necessarily the result of collective belief in the infallibility of a project. Rather, escalation results from continued unsuccessful coping with problems that arise during a project. Furthermore, the results suggest that the seeds of escalation are sown early: the very manner in which a project is framed contributes to whether or not the project will become prone to escalation. As problems ensue, repeated mismatches between attempted remedies and underlying problems contribute to fueling the escalation process. Implications for research and practice are discussed.