Sunk Cost Fallacy in Projects: How to Avoid It

What is the sunk cost fallacy?

The sunk cost fallacy is the tendency to continue an endeavor because of resources already invested, rather than because of the expected future outcome. The investment is gone either way; letting it influence the next decision is the error.

Economics calls the correct behavior the bygones principle: past costs are bygones, and a rational decision compares only the options still available. If a factory was budgeted at $100 million for $120 million of value, and after $30 million the value estimate falls to $65 million, completing it for another $70 million destroys value. Abandoning it does too — but by less.

That framing matters because popular advice overshoots. “Never let sunk costs influence you” is read as “quit when it hurts,” which just lets the past decide in the other direction. The rule is narrower: ignore what you spent, then compare what remains to spend against what remains to gain.

> Important note: Sunk cost reasoning is not always irrational from an individual’s perspective. If abandoning a project would destroy a manager’s credibility and trigger a costly leadership crisis, that manager may rationally persist. The behavior is a governance problem, not just a cognitive one.

Why does the brain insist on continuing?

The effect is well documented and stubbornly consistent. In their 1985 paper “The Psychology of Sunk Cost,” Hal Arkes and Catherine Blumer found that people show “a greater tendency to continue an endeavor once an investment in money, effort, or time has been made” — even when the investment is irrelevant to the outcome.

Four mechanisms do most of the work:

Loss aversion. Prospect theory, Kahneman and Tversky’s 1979 model, shows that losses feel roughly twice as painful as equivalent gains feel good. Stopping converts an ambiguous hope into a definite, countable loss. Continuing keeps the loss theoretical, and the brain prefers that.

Self-justification. Admitting the project should stop means admitting the earlier decision was wrong. Most people will spend real money to avoid that conclusion, because the cost lands on their identity rather than the budget.

Personal responsibility. This is the strongest predictor. In a study by Barry Staw and Jerry Fox, business students who believed they had personally made the earlier disappointing investment committed an average of $12.97 million to a hypothetical failing division, versus $9.43 million for those told a predecessor had made the call. Same data, different ownership, 38% more money committed.

Public commitment. Once you have announced a date, a budget, or a benefit case, backing down has a social price. That is why escalation is easier in organizations with strong “delivery culture” and no vocabulary for a well-run stop.

Two more findings are worth keeping. Knox and Inkster’s 1968 study of 141 horse bettors found that people who had just placed a $2 bet rated their horse’s chances at 4.81 on a seven-point scale, against 3.48 for those about to bet — a small commitment shifted belief within thirty seconds. And a 2004 NASA review found “plan continuation bias,” a close relative, in 9 of 19 accidents studied.

Which costs actually count?

Sorting a project’s numbers into sunk and relevant is the most useful exercise in a stop-or-continue review. Most disagreements disappear once the classification is explicit.

The test is not “did we spend it?” but “does this number change depending on what we do next?” If it does not change, it belongs on the sunk side of the page and out of the argument.

How do you run a stop-or-continue review?

You run it as a comparison of two futures, with the past deliberately excluded from the model.

Three questions structure the conversation:

1. What does finishing cost from today? Not the original budget, not the remaining budget line. A fresh estimate of the work left, including testing, rollout, training, and the support tail.
2. What does finishing return from today? A probability-weighted benefit, discounted for time, with the assumptions written down. If the benefit is “$2 million” with no probability, it is a hope, not an input.
3. What does stopping free up? Salvage, avoided costs, and — most often forgotten — the capacity of the team, which can be redeployed.

Then compute the net of each future. If continuing has a higher net than stopping, continue, and say so clearly. A review that always recommends stopping is as broken as one that never does.

Example 1: the ERP rollout that should have stopped

A distributor is implementing a new ERP. The approved budget is $2.0 million. $1.2 million has been spent, and a fresh estimate says $900,000 remains to finish. The expected benefit, probability-weighted and discounted, is $1.35 million.

• Continue: $1.35M − $0.90M = +$450,000
• Stop: salvage $0, avoided spend $900,000, and the implementation team of six can start Project B, which has a net value of +$700,000

On those numbers, stopping is better by $250,000. Notice that the $1.2 million already spent does not appear in either calculation. It is the same in both futures, which is exactly why it cannot break the tie.

Now change one input: if the ERP benefit were $1.75 million, continuing would be worth +$850,000 and would beat Project B. The discipline is not “stop failing projects.” It is “re-run the numbers with today’s estimates, then choose.”

Example 2: replacing a legacy application nobody wants to touch

A logistics firm spends $180,000 a year maintaining a custom application, and that cost is rising about 8% annually as the original developers become harder to find. A rebuild costs $450,000 and would cut running costs to $60,000 a year.

Cumulative five-year cost:

• Keep: 180 + 194.4 + 210.0 + 226.8 + 244.9 = $1,056,100
• Rebuild: 450 + (5 × 60) = $750,000

The rebuild saves about $306,000 over five years. But look at the early years: after two years, keeping costs $374,400 against $570,000 for the rebuild. The project only crosses over in year four.

This is where sunk cost thinking usually wins. The team has spent $260,000 customizing the old system over three years, and that number makes the rebuild feel like writing off work. It should not. The $260,000 is identical in both futures. What matters is the crossover point and whether the organization will still be running the application in year five.

Example 3: the numbers that fail a kill criterion

A programme has a budget at completion of $4.0 million, earned value of $2.4 million, and actual cost of $3.0 million. Cost performance index: 2.4 ÷ 3.0 = 0.80. Forecast final cost at the current efficiency: 4.0 ÷ 0.80 = $5.0 million, leaving $2.0 million still to spend.

A pilot then cuts the expected benefit to $1.7 million. Compare the futures, not the history:

• Continue: $1.7M of benefit − $2.0M of remaining spend = −$0.3M
• Stop: $0 of benefit, $0 of remaining spend, plus about $300,000 recovered from assets and licences = +$0.3M

Stopping is better by $600,000. The $3.0 million already spent sits in both columns, so it cancels out.

What are kill criteria, and how do you write them?

Kill criteria are pre-agreed conditions that trigger a stop-or-continue review, converting an emotional argument into a scheduled event.

Write them at kickoff, when nobody is defensive, and make them specific enough that a stranger could apply them. “If the project is failing” is not a criterion. “If CPI falls below 0.90 for two consecutive months” is.

Three design rules make kill criteria survive contact with reality:

• Few and numeric. Six criteria with thresholds beat twenty aspirations. If everything is a criterion, nothing triggers.
• Owned by someone outside the delivery team. The project manager has an incentive to keep going. The portfolio office or finance function does not.
• Reviewed on a fixed date. Put the review in the calendar at kickoff. Unscheduled reviews only happen after a crisis, and by then the options are worse.

> Practical tip: Add a “pre-mortem” line to the business case: “This project will be stopped if ___.” Writing the sentence before you are invested is much easier than writing it in month twelve, and it gives the sponsor permission to act later.

How do you make stopping politically survivable?

Stopping is a governance problem before it is an analytical one. People resist because the personal cost of a visible stop exceeds the organizational cost of continuing.

Four practices change that calculus:

Separate decision quality from outcome quality. A good decision made with the information available can still produce a bad outcome, and a bad decision can get lucky. Review the reasoning, not just the result.

Reward well-run stops. Publish the number of projects stopped at a gate and the money redeployed. If the only visible metric is delivery, stopping looks like failure by definition.

Give the sponsor a script. “We set these thresholds at approval, we hit them, and we are acting on them” is a defensible sentence. Without it, the sponsor improvises and loses.

Use an independent reviewer. Someone with no history on the project can ask “would we start this today?” without implying that anyone was stupid. That question — the reset test — is the cleanest single instrument in this whole area.

The reset test has a companion: the fresh-manager test. Ask what a manager who joined last week, with the same budget and the same information, would do. If the answer is “they would cancel it,” you have your answer, and the only remaining question is how to do it well.

When is persistence the right call?

Persistence is correct more often than the internet’s version of this advice suggests. Three conditions justify continuing past a bad quarter.

The remaining cost is genuinely below the remaining benefit. This is the only condition that matters financially. Everything else is commentary.

Option value is real and increasing. Some projects build a capability that opens further options — a platform, a certification, a market entry. If stopping forecloses those options permanently and the option value is measurable, include it in the benefit side rather than waving at it.

The stopping cost is prohibitive and temporary. Regulatory obligations, safety requirements, and contractual penalties can make continuation the cheaper path even when the project’s own return is negative. Say so explicitly; a documented “we are continuing because the penalty is $2 million” is not a sunk cost error.

What is never valid is the reason you hear most often: “we have come too far to stop.” Distance travelled is a fact about the past, not a benefit.

Common mistakes

• Treating every continuation as a fallacy. Sometimes finishing is right. The test is arithmetic, not attitude.
• Confusing sunk cost with sunk effort. Emotional investment is real, but it belongs in the conversation about morale, not in the business case.
• Setting kill criteria after the first warning sign. Criteria written under pressure are written to be survived.
• Letting the delivery team self-assess. The people with the most to lose should not be the only source of the numbers.
• Using “lessons learned” as the only follow-up. A stop review should produce a decision, an owner, and a date.

Where does Doitify fit?

Sunk cost decisions depend on three things being visible at once: what was planned, what has been earned, and what remains. When those live in different spreadsheets, the loudest voice in the room wins the argument.

Doitify holds tasks, sub-tasks, milestones, dependencies, budgets, and work reports in one workspace, so a stage-gate review can look at planned versus actual progress and remaining scope without a week of preparation. Project documents and meeting notes keep the decision log next to the plan, which matters more than it sounds: the strongest defense against escalation is a written record of what you agreed to check, and when.

Transparency: Doitify is our product. It will not tell you whether to stop a project — that is a judgment about future costs and benefits. It only makes the evidence easier to assemble.

Conclusion

The sunk cost fallacy survives because it protects something real: the desire not to have been wrong. That is why arguing with it using logic alone rarely works, and why structure does.

Three habits carry most of the weight. Classify every line item as sunk or relevant before the discussion starts. Write numeric kill criteria at kickoff and let someone outside the team monitor them. Run the reset test out loud — “would we start this today?” — and accept the answer even when it costs you the work you have already done.

The measure of a healthy project portfolio is not how few projects are stopped. It is how quickly the ones that should stop, do.

If this post on sunk cost fallacy was helpful, you might also enjoy Meeting Productivity Statistics (2026): What the Data Actually Shows and How to Stop Projects From Falling Behind.