Escalation of commitment is the tendency to put more resources into a failing course of action, and to put in more the worse it goes, when you were the one who chose it. The concept belongs to organisational behaviour and has been measured since 1976. What makes it useful rather than merely true is the specific finding underneath it: the effect attaches to responsibility for the original decision, not to the size of the loss. So it is a question about who is being asked, and most organisations ask the author.
The answer, in one line
The tendency to commit further resources to a course of action that is failing, and to commit more of them the worse it goes, when you were responsible for choosing it.
The experiment that established it#
Barry Staw ran 240 business students through a role-played corporate funding decision, in a two-by-two design crossing personal responsibility for an earlier investment against whether that investment had gone well or badly.
Participants who had personally made the earlier decision allocated an average of $11.08 million to the division they had chosen. Where the earlier choice had been made by another officer, the figure was $8.89 million. Negative consequences drew more money than positive ones, $11.20 million against $8.77 million. And in the cell that combines both, where a participant's own earlier choice had subsequently declined, allocation rose to $13.07 million. Both main effects were significant, and so was the interaction.
It is a paper exercise with undergraduates and no real money, and it should not be asked to carry more than that. What it establishes is narrow and has held up: responsibility for the original decision changes the next one, in a known direction, before any question of competence arises.
How it differs from sunk cost#
The two are often used interchangeably and are not the same. The sunk cost effect, named by Arkes and Blumer in 1985, is the general tendency to let unrecoverable past spending influence a present choice. Escalation of commitment is the organisational behaviour that results, and Staw's contribution is the part sunk cost alone does not predict: identical sunk costs produce different decisions depending on who is deciding. That shifts the remedy. If the problem were only the money already spent, better analysis would fix it. If the problem is who is holding the question, only a change of process does.
The one prevalence figure, and its limits#
Keil, Mann and Rai surveyed information systems audit and control professionals in 2000, designing the instrument to capture projects that did not escalate as well as those that did. They report that "between 30% and 40% of all IS projects exhibit some degree of escalation". Of the four theories they tested, the completion effect from approach-avoidance theory classified best, correctly sorting over 70 per cent of both escalated and non-escalated projects, which points at the pull of finishing rather than at self-justification alone.
Three caveats belong with the number. It is a retrospective survey of auditors rather than a random sample of projects. "Some degree of escalation" is a soft threshold. And it is twenty-six years old and about information systems, not about AI: no equivalent figure exists for AI programmes, and this research searched for peer-reviewed work applying escalation theory to AI or machine-learning investment between 2020 and 2026 and found none.
Why technology programmes are a good host#
Mark Keil's 1995 case study is the paper that brought escalation into information systems research, and the case is instructive for a reason nobody notices. CONFIG was an expert system, built to help sales representatives configure quotes correctly, and it ran for more than a decade before being terminated at the end of 1992 after what Keil describes as tens of millions of dollars. Successive business cases put its net present value at $43.9 million in 1982, $55.7 million in 1985 and at least $41.1 million in 1987, each produced by people who believed in it and had been right before.
The founding case study of runaway technology spending was an artificial intelligence programme. That is worth knowing before assuming this literature is being applied to AI by analogy.
The route back down#
Escalation research is large; de-escalation research is not, and Montealegre and Keil said so at the time. Their study of the baggage handling system at Denver International Airport produced the model the field still uses: de-escalation as "(1) problem recognition, (2) re-examination of prior course of action, (3) search for alternative course of action, and (4) implementing an exit strategy".
The four phases separate noticing from being permitted to act, and that is where they earn their place. Organisations reach phase one constantly, because somebody in the room always knows. Phase two requires asking the person who chose the course to say it was wrong, in front of the people who funded it. The model is inductive, built from one case, and has never been tested for how often de-escalation succeeds. Treat it as a description of the route rather than evidence that the route is taken.
Related SuperSkills research#
The applied version of this page is which AI investments should we stop, which turns the four phases into three questions that do not require a counterfactual. On stopping for reasons other than money, deployment is not a ratchet and how to design a stop button people will use. On the measurement that would otherwise settle it, how long before you know if an AI investment worked and how to measure AI adoption properly. On who should be asking, what a board should ask about AI.
Key research and primary sources
- Staw, B. M. (1976). Knee-Deep in the Big Muddy: A Study of Escalating Commitment to a Chosen Course of Action. Organizational Behavior and Human Performance, 16(1), 27-44.
- Keil, M. (1995). Pulling the Plug: Software Project Management and the Problem of Project Escalation. MIS Quarterly, 19(4), 421-447.
- Keil, M., Mann, J. and Rai, A. (2000). Why Software Projects Escalate: An Empirical Analysis and Test of Four Theoretical Models. MIS Quarterly, 24(4), 631-664.
- Montealegre, R. and Keil, M. (2000). De-escalating Information Technology Projects: Lessons from the Denver International Airport. MIS Quarterly, 24(3), 417-447.
About this research#
Rahim Hirji is the author of SuperSkills (Kogan Page, 2026), keynote speaker on AI and human capability, and founder of The SuperSkills Intelligence Company. Escalation of commitment is Staw's, the sunk cost effect is Arkes and Blumer's, and the de-escalation phases are Montealegre and Keil's. Nothing on this page is a SuperSkills coinage. Arkes and Blumer's experimental figures are deliberately absent: their paper could not be opened at source and the versions in circulation disagree with one another, so they are credited for the concept and not quoted for a number.
Explainer · SS-2026-173 · Graded against the published rubric
Hirji, R. (2026). Escalation of commitment. The SuperSkills evidence base, SS-2026-173. https://thesuperskills.com/research/what-is-escalation-of-commitment. Last reviewed 4 September 2026.
An evidence review by Rahim Hirji, not peer-reviewed research. For a material claim, cite the underlying study as well; every study here carries its own permanent link.
How citations and IDs work