Abstract
ABSTRACTInformation 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.
Talk to us
Join us for a 30 min session where you can share your feedback and ask us any queries you have
Disclaimer: All third-party content on this website/platform is and will remain the property of their respective owners and is provided on "as is" basis without any warranties, express or implied. Use of third-party content does not indicate any affiliation, sponsorship with or endorsement by them. Any references to third-party content is to identify the corresponding services and shall be considered fair use under The CopyrightLaw.