The idea behind it
The sunk-cost fallacy is the tendency to keep investing in a failing course of action because of what has already been spent. Economists treat past spend as irrelevant to a forward decision: only future costs and benefits count. Barry Staw's research on escalation of commitment showed that the people who started a project are the most likely to keep funding it after bad news, because stopping would admit the original choice was wrong. Hal Arkes and Catherine Blumer later documented the same pull in everyday choices. Large IT programs are prone to it. Their costs come early, their benefits come late, and status reports can stay green until late in the schedule.
Kill criteria are the countermeasure. They are stop conditions agreed before the program starts, while nobody has spend to defend. Each one names a measurable threshold, such as a schedule slip or a cost overrun, and what happens when it is crossed. Agreeing them in advance moves the hard judgment to a time when it is easy to make. A crossed threshold does not end the program. It removes the default of continuing and requires a fresh decision by a named owner: pause, descope, pivot or abandon. Annie Duke's book Quit describes the same practice for individuals and organizations.
What's inside
- A program details block: name, sponsor, start date, approved budget, planned end date and the date the checklist was agreed.
- Six stop conditions with a definition, an example threshold, a space for your own threshold, an Active/Triggered/Waived status and the date and reason for any change: schedule overrun, cost overrun, value erosion, technical risk, vendor or dependency failure, and stakeholder confidence.
- A decision governance table: review frequency, named decision owner, escalation path and review quorum.
- An action table for when a condition trips, with four choices: pause, descope, pivot or abandon.
- A sign-off block for the program sponsor, the CIO or CTO, and the finance lead.
- In the Excel version, a Status dropdown, with Triggered and Waived rows highlighted.
Format: PDF (3 pages) and Excel workbook.
A look inside
Pages 1 and 2 of 3 of the PDF. Select an image to enlarge it.
Who uses it
- CIOs and CTOs, to agree in writing with the sponsor and finance when a migration or transformation will be stopped or re-decided.
- Program sponsors, to have agreed grounds for stopping a program that do not depend on admitting personal failure.
- Finance leads, to tie continued funding to thresholds on spend, schedule and value.
- PMO leads and program board chairs, to check the stop conditions at each review and record the status of each one.
When to use it
- A data center exit, ERP replacement or core platform migration is going for final approval.
- A program is about to sign a multi-year vendor contract with milestone payments.
- A program has slipped once and the board is asked to approve a re-baselined plan.
- A new sponsor inherits a program and needs agreed terms for continuing it.
- The business case depends on a vendor or third-party service that the program does not control.
How to use it
Complete it before the program is approved, then check the thresholds at each review. A crossed threshold requires a new decision to continue.
- Fill in the program details block, including the approved budget and the date the checklist was agreed, so later reviews can show the thresholds were set in advance.
- Write your own measurable figure in the Your Threshold column for all six stop conditions, using the example beside it as a guide. The checklist treats a blank row as a gap in governance.
- Complete the Decision Governance table: how often the conditions are checked, who can call a stop, who decides if that person is unavailable, and who must be present for a stop decision to be valid.
- Use the Rationale / Notes column of the action table to agree what pause, descope, pivot and abandon would mean for this program.
- Have the program sponsor, the CIO or CTO, and the finance lead sign the sign-off block before the program is approved.
- At each review, set each condition's Status to Active, Triggered or Waived, and record the date and reason for any change. When one is triggered, the decision owner chooses an action and documents and communicates it within 5 business days.
You leave with: A signed set of stop conditions with measurable thresholds, a named decision owner, escalation path and quorum, and an agreed set of actions for when a threshold is crossed.
Where it goes wrong
- Writing thresholds nobody can measure, such as "significant delay". Each threshold needs a number or an observable event, like the checklist's examples.
- Setting the conditions after the program is in trouble. By then every threshold is negotiated against the money already spent.
- Treating a triggered condition as automatic cancellation. The checklist asks for a choice among four actions; the trigger removes only the default of carrying on.
- Waiving triggered conditions without a recorded reason, which restores the default of continuing.
Get the checklist
It is free. Enter your work email and we send the download link.
Questions
What is the sunk-cost fallacy in IT projects?
It is continuing to fund an IT project because of the money and time already spent rather than the value still to come. Past spend cannot be recovered whatever is decided next, so it should not affect the decision. At program boards it sounds like "we are too far in to stop".
What are kill criteria?
Kill criteria are conditions, agreed before a project starts, that trigger a formal decision on whether to continue. They are specific and measurable: a cost overrun above a set percentage, a schedule slip beyond a set number of weeks, or a vendor missing consecutive milestones. Each is paired with a named decision owner, so a breach leads to a decision rather than a discussion.
Who should have the authority to stop a failing IT program?
A named individual, usually the program sponsor with the CIO or CTO's concurrence, agreed before the program starts. There should also be an escalation path for when that person is unavailable and a quorum for the decision to be valid. Without a named owner, a stop decision drifts from meeting to meeting.