How to Kill a Software Project Before It Kills You
The 5 signals that tell you to stop, and the playbook for actually doing it
By Steele Consulting
Every business owner who has been in a failing software project has been in this meeting.
It’s the quarterly review. The project was supposed to ship two quarters ago. The team asks for three more months. It’s the third time you’ve heard that. Everyone in the room knows it. Nobody says it. You approve the three months anyway, because the alternative — killing a project that’s already consumed a year and mid-six-figures of budget — feels worse than continuing.
Three months later, you’re back in the same meeting.
In our 24 years at Steele Consulting building custom software, one of the more painful conversations we have is with clients who’ve kept a project alive for two extra years past the point where killing it was obviously the right answer. The money spent on those extra years is almost always a multiple of what an honest kill decision would have cost.
Killing a software project is a decision. Not killing one is also a decision — the more expensive one, in most cases.
This post is about the five signals that tell you it’s time, and the playbook for actually pulling the trigger without turning a difficult decision into an organizational disaster.
Why projects don’t get killed when they should
Software projects have unusually strong survival instincts. Three reasons.
The first is sunk cost. Every dollar already spent feels like it will be wasted if you stop now. This is a fallacy — economists have been writing about it for 60 years — but knowing it’s a fallacy doesn’t make it feel less real when the number is $850K.
The second is politics. Somebody championed this project. Killing it is implicitly declaring their judgment wrong. That’s uncomfortable at the executive level and can be career-limiting at the middle-management level. The people closest to the decision have the strongest incentives to keep it alive.
The third is optimism. Software teams are structurally optimistic — you have to be, to build things. The team believes the next three months will be different, because the team has to believe that to keep working. The founder often believes the team, because the alternative is admitting the project was misjudged from the start.
None of these three are dishonest. All of them are expensive.
The 5 Kill Signals
Here’s how to override the survival instincts. Any two of these signals appearing together is worth serious consideration. Three or more is a decision.
Signal 1: Timeline has doubled without an equivalent scope increase
Original estimate was six months. You’re now nine months in with six months remaining. Scope hasn’t materially expanded. Something is fundamentally off — either the original estimate was wrong (in which case the current estimate probably is too), or the team is losing velocity, or both.
Timelines slip. That’s normal. Timelines that double are a signal, not a slip.
Signal 2: The team can’t articulate what “done” looks like
Ask the project lead: “in one sentence, what does ‘done’ look like?” A healthy project has an answer. A dying project has three answers, or a paragraph that includes phrases like “we’re aligning on that” or “phase one will be…”
If nobody in the room can finish “the project will be complete when ___” in a single sentence, you don’t have a project. You have an ongoing burn.
Signal 3: Every milestone triggers a new revelation
“We didn’t realize the integration needed X.” “We need to add Y before we can ship Z.” “The database migration turned out to be harder than expected.”
A well-scoped project uncovers less as it progresses, not more. If new fundamental discoveries are still happening in month nine, the discovery work was never really done — which means you’re paying delivery prices for what should have been discovery work. We covered why this happens in Discovery vs. Delivery: it’s the classic pattern of a partner that was strong at one skill and weak at the other, and it kills projects reliably.
Signal 4: The business case has changed
You started building this because the revenue was going to be $X, the competitor didn’t have Y, or the regulation required Z. Nine months later, revenue projections are flat, the competitor shipped, or the regulation changed.
The original business case has to survive the build. If it hasn’t, you’re now finishing a project whose ROI has quietly collapsed. This one is particularly hard to see, because the team is heads-down building and hasn’t been tracking the outside world.
Signal 5: The team has silently disengaged
Standup energy is low. The people who used to push back on scope now nod at everything. Meetings that used to run over now end early. Your best engineer has been “considering some things” for a month. Turnover is quietly ticking up.
Teams know when a project is failing before leadership does. Silence in the standup is often the earliest signal you’ll get. It’s also the one leaders most consistently miss, because low energy doesn’t show up in a status report.
The playbook for actually killing
Deciding to kill a project is the hard part. But executing the kill without turning it into an organizational disaster takes real work too. Four steps.
1. Reframe the decision as strategic, not as failure
The message is not “we screwed up.” It’s “the business has changed, and the right investment now is different.” Both sentences are usually true. The second one is dramatically easier to lead through.
2. Salvage what’s genuinely salvageable
A killed project isn’t zero-value. Discovery work, architecture decisions, partial implementations, and — often most valuably — the lessons about what didn’t work all have residual value. Do a serious salvage pass in the two weeks after the kill decision. What data can be exported? What partial code can be repurposed? What did the team learn that they can carry into whatever comes next?
3. Protect the people, then the process
The most common way a kill goes badly is that the team members most associated with the project feel their careers are being ended alongside it. They aren’t — but they’ll assume they are unless you say otherwise clearly and quickly. Talk to them individually within 48 hours. Move them to work that matters. If some of them do need to leave, be direct about it. Ambiguity is worse than clarity, even when the clarity is hard.
4. Decide what happens next
The vacuum after a kill is dangerous. If you don’t fill it with a specific decision about what to do instead, the same problem you were trying to solve is still there — and the team’s instinct will be to propose a slightly-different version of the same project. Kill the project AND decide what replaces it, in the same week if possible.
Preventing the next one
The best time to make it easier to kill a project is at the start, when you set it up. Three things help.
- A named business case with numbers, revisited quarterly. The original ROI assumption has to be a live document. If it stops looking real, you find out fast — before the team has burned another six months.
- Milestone reviews that actually can result in kill decisions. Most companies have “milestone reviews” that are functionally check-ins. A real milestone review asks: “given what we now know, should this project continue?” and takes yes as a real answer alongside no.
- An explicit sponsor. Every project needs a specific named executive who owns the decision to continue. Distributed accountability is how projects survive past their expiration date. The same accountability question we wrote about in our software partner post — “who owns this?” — applies to internal projects.
How we approach this at Steele Consulting
We’ve been on both sides of this. Some of our best client engagements started with a call where the client had just killed a project they should have killed six months earlier — and we picked up the salvage, reframed the problem, and shipped the actually-right version in a third of the original time. Some of our best conversations have been ones where we told a prospective client that the project they wanted us to take over wasn’t worth continuing — that the honest answer was to kill it and start fresh with a different scope.
If you’re in the meeting where the project is asking for three more months and it’s the third time you’ve heard that, that’s the conversation we’re happy to have. We won’t tell you it’s fine if it isn’t. Reach out and we’ll walk through the five signals with your specific situation.