Daring to cancel: when shutting down is the right call
An IT project should be canceled when the remaining cost to finish it exceeds the remaining value it can create. Money already spent is irrelevant to the decision – it's gone either way. The hard part is psychological: sunk cost thinking makes steering committees throw good money after bad. An orderly shutdown saves code, lessons, and relationships.
There’s one decision in project work almost nobody wants to make: shutting down. Canceling a project feels like throwing away everything you’ve invested, so many projects keep going long after they should have stopped. But that feeling rests on a thinking error. Money already spent is gone no matter what you do – and continuing just because you’ve already paid is throwing good money after bad.
The mechanics of sunk cost thinking in steering committees
“We’ve already spent three million, we can’t throw that away now.” The sentence sounds reasonable but is exactly wrong. The three million is spent. It won’t come back whether you continue or not, so it shouldn’t factor into the decision about the future at all.
This is the sunk cost trap, and steering committees are especially exposed to it. The more that’s been invested, the harder it becomes to make the rational decision, because shutting down feels like admitting the money was wasted. Add pride – often someone in the room has driven the project and has their reputation tied to it – and inertia, since there’s rarely a predetermined point where you actually reconsider. The result is projects that keep rolling on pure momentum.
The antidote is shifting your gaze. The question is never “how much have we spent?” but “what does it cost to finish from here, and is it worth it?”
The decision criterion: remaining cost against remaining value
The only thing that should govern the decision is the future. Weigh two questions against each other:
- Remaining cost. What does it cost, in money and time, to finish the project from now on?
- Remaining value. What is what’s left to build actually worth once it’s done?
If the remaining cost exceeds the remaining value, the project should be canceled, no matter how much has already been spent. If the value still exceeds the cost, it’s worth continuing, even if the project has been painful so far. History is irrelevant in both cases.
What makes this manageable in practice is deciding the criteria in advance. Set out, right at the start, which conditions would prompt you to reconsider: if the cost to finish passes a certain level, if the market changes, if a key assumption falls away. Then a potential shutdown becomes a factual condition kicking in, not an emotional defeat in the middle of things.
A concrete example
A company has spent SEK 2.5 million on an internal platform. It’s half-finished, and completing it is estimated to require another SEK 1.5 million. Meanwhile, a ready-made standard solution has appeared on the market that covers 80 percent of the need for a fraction of the cost.
The backward-looking steering committee reasons: “We can’t throw away SEK 2.5 million, we have to finish.” The forward-looking one asks instead: “Do we want to spend another SEK 1.5 million building something we can now buy for less?” The SEK 2.5 million is lost either way. The only open decision concerns the SEK 1.5 million not yet spent – and there, the answer is often to shut down and change course. Continuing would mean paying three times the price just to avoid admitting the first mistake.
Closing out in an orderly way
Canceling isn’t the same as just pulling the plug. An orderly close is the difference between an expensive lesson and a pure loss.
Salvage what’s been built. Code, design, and technical solutions can have value in other contexts even if this particular project isn’t completed. Document the lessons while they’re fresh: why did it go the way it did, and what will you take away? And end relationships with vendors and teams professionally – the industry is small, and how you handle a close-out says more about you than how you handle a success.
Daring to cancel in time is a sign of strength, not weakness. At Weapp, we’d rather help a client make an honest decision about direction than keep building on something that isn’t working. Want to talk through where your project stands? Get in touch with a short description, or read more about our services.
Frequently asked questions
What is the sunk cost trap?
The sunk cost trap is the tendency to keep going with something because you've already put a lot into it, instead of judging whether it's worthwhile going forward. Money and time already spent can't be recovered no matter what you do. They shouldn't affect the decision – but emotionally, they almost always do.
What criteria determine whether a project should be shut down?
Compare the remaining cost with the remaining value. What does it cost to finish from here, and what is what's left to build actually worth? If the cost to finish exceeds the benefit, the project should be canceled, no matter how much has already been invested. The decision should always look forward, never back at what's already been spent.
Why is it so hard to cancel a project?
Partly sunk cost thinking, partly pride. Shutting down can feel like admitting failure, especially for whoever drove the project. There's also often no clear, predetermined point for reconsideration, so the project just keeps rolling on momentum. Setting decision criteria in advance turns the shutdown into a factual choice instead of a defeat.
How do you close out a project in an orderly way?
Salvage what's been built – the code, design, and decisions can have value even if the project isn't completed. Document the lessons learned so the next initiative doesn't repeat the mistakes. And end relationships with vendors and teams professionally. An orderly close is the difference between an expensive lesson and a pure loss.
Is a canceled project always a failure?
No. Canceling in time can be the most profitable decision of all, since it stops further waste. A project that taught you something important, or whose code can be reused, has created value even without launching. The real failure is continuing to pay for something you already know won't work.