When to Kill It¶

Uncomfortable Reading

Why Projects Don't Die When They Should¶

Projects continue past their expiration date because:

1. No one wants to admit failure - especially not the sponsor who championed it
2. It's always "almost there" - just one more sprint, one more fix
3. The alternative is undefined - killing the project means explaining what instead
4. Careers are attached - someone's performance rating is tied to this
5. Budgets are allocated - unspent budget raises uncomfortable questions
6. Hope beats evidence - maybe it'll turn around
7. No one has authority - everyone's waiting for someone else to call it

The result: zombie projects that consume resources but produce nothing.

The Kill Criteria Framework¶

Before starting any AI project, define your kill criteria. What conditions would trigger a stop decision?

Template: Pre-Defined Kill Criteria¶

## Project Kill Criteria

This project should be stopped if ANY of the following occur:

### Technical Kill Triggers
- [ ] Model accuracy below [X%] after [Y] iterations
- [ ] Data quality issues unresolved after [Z] months
- [ ] Core dependency unavailable with no alternative
- [ ] Technical architecture proven infeasible

### Business Kill Triggers
- [ ] Executive sponsor withdrawn with no replacement
- [ ] Business process it supports is changing/cancelled
- [ ] ROI falls below [threshold] based on revised estimates
- [ ] Priority overtaken by [specific alternative]

### Timing Kill Triggers
- [ ] Original deadline missed by more than [X]%
- [ ] Pilot results not achieved by [date]
- [ ] No production deployment by [date]

### Resource Kill Triggers
- [ ] Budget overrun exceeds [X]%
- [ ] Key team members leave with no replacement
- [ ] Dependent team unable to support

### External Kill Triggers
- [ ] Regulatory change makes project non-viable
- [ ] Technology obsoleted by market shift
- [ ] Vendor/partner failure

If trigger occurs: [Named person] has authority to stop the project
                   without further approval.

12 Signs Your Project Should Already Be Dead¶

Sign #1: You're Solving Yesterday's Problem¶

Symptoms: - The business process the AI was supposed to improve has changed - The problem you're solving is no longer the biggest problem - Stakeholders talk about the project in past tense

The test: If you started from scratch today, would you build this?

Why it persists: No one wants to admit the world moved on while we were building.

Sign #2: The Goalposts Keep Moving¶

Symptoms: - Success criteria have been revised 3+ times - Original scope would have been "done" by now - Each milestone completion is followed by "but now we also need..."

The test: Can you state clearly what "done" means, and has that changed?

Why it persists: Moving goalposts lets everyone avoid admitting the original goal wasn't achieved.

Sign #3: The Champion Has Left¶

Symptoms: - Project sponsor has moved to another role - New leadership is "supportive" but not actively involved - No one is protecting the project from competing priorities

The test: Who would fight to save this project if budget cuts came?

Why it persists: Orphan projects continue on inertia until someone actively kills them.

Sign #4: The Team Has Given Up¶

Symptoms: - Key people are leaving or asking to transfer - Team meetings are about managing stakeholders, not building - Everyone's updating their LinkedIn

The test: Does the team believe this will succeed?

Why it persists: Teams often know before leadership does. But they're not asked, or not heard.

Sign #5: Pilot Purgatory¶

Symptoms: - Pilot has been extended 3+ times - "Lessons from pilot" keep informing new pilot designs - Production deployment keeps being deferred for "readiness"

The test: What would have to happen to move from pilot to production?

Why it persists: Pilots feel like progress. They're safe. Production is scary.

Sign #6: Success Has Been Redefined to Mean "Completion"¶

Symptoms: - Original business outcomes no longer mentioned - "Success" = delivered something, anything - Focus on outputs (features built) not outcomes (value delivered)

The test: What business outcome will this produce, and do we still believe it?

Why it persists: It's easier to claim success for delivery than to admit failure to deliver value.

Sign #7: More Time on Governance Than Building¶

Symptoms: - Steering committees, risk meetings, stakeholder updates consume most energy - Team spends more time explaining than executing - Every decision requires multiple approvals

The test: What percentage of project hours are governance vs. delivery?

Why it persists: Governance is visible activity. It looks like progress.

Sign #8: The Technology Isn't Working¶

Symptoms: - Model accuracy plateaued well below target - Integration with other systems keeps failing - Technical debt is mounting faster than features

The test: Based on current trajectory, will this ever meet technical requirements?

Why it persists: "We just need more data / time / tuning" - the eternal optimism of technical teams.

Sign #9: Nobody Is Actually Asking For It Anymore¶

Symptoms: - Stakeholder engagement sessions are poorly attended - Users aren't interested in the pilot - Business has found workarounds

The test: Who is waiting for this to launch?

Why it persists: The project creates its own constituency (the project team).

Sign #10: The Vendor Is The Only Enthusiast¶

Symptoms: - Vendor is driving meetings - Vendor has more energy than internal team - Vendor keeps adding "opportunities" rather than delivering core

The test: If the vendor disappeared, would we continue?

Why it persists: Vendor has incentive to keep project alive. Their enthusiasm masks internal fatigue.

Sign #11: Strategic Alignment Has Evaporated¶

Symptoms: - Department priorities have shifted - New leadership has different agenda - The strategy this supported has been replaced

The test: Does this project appear in current strategic priorities?

Why it persists: No one wants to admit strategic pivots make previous investments worthless.

Sign #12: You're Embarrassed to Describe It¶

Symptoms: - When asked "how's the AI project?" you change the subject - Project updates are filled with qualifications and explanations - You wouldn't cite this as a success to a future employer

The test: Are you proud of this?

Why it persists: Admitting embarrassment means admitting failure.

How to Kill a Project (Without Killing Careers)¶

Step 1: Frame It Right¶

Don't say: "The project failed because..."

Do say: "We learned that the approach wasn't right for this problem. Here's what we learned and how we'll apply it."

Step 2: Document the Learning¶

Capture genuinely useful insights: - What assumptions proved wrong? - What would we do differently? - What did we learn about the problem space? - What can be salvaged (data, relationships, knowledge)?

Step 3: Propose the Alternative¶

Don't just stop - redirect: - What should the resources work on instead? - What problem should we solve with what we've learned? - How do we serve the original stakeholders differently?

Step 4: Protect the People¶

• Team members should not be blamed
• Sponsors should be given face-saving narrative
• Document that stopping was a rational decision, not a performance issue

Step 5: Celebrate the Kill¶

Reframe project termination as positive: - "We saved $X by not continuing down the wrong path" - "We freed up resources for higher-value work" - "We demonstrated discipline and judgment"

The Kill Conversation: A Script¶

Setting Up the Conversation¶

Choose the right setting: - Private conversation first, not a committee meeting - With sponsor, not just steering committee - With recommendation, not just problems

Opening¶

"I need to share an honest assessment of where we are on [Project]. I've been thinking hard about whether continued investment is the right call, and I think we need to discuss stopping."

Presenting the Evidence¶

"Here's what I'm seeing: - [Factual indicator 1] - [Factual indicator 2] - [Factual indicator 3]

I've tried to make this work. But I think continuing would be throwing good money after bad."

The Alternative¶

"If we stop now, we could: - [Redirection 1] - [Redirection 2]

The team and the learning wouldn't be wasted - they'd go to something with better odds."

The Ask¶

"I'd like your support to wind this down gracefully. I think that's the right call, even though it's hard."

Managing Reactions¶

If pushback: "I understand this is disappointing. What would you need to see to change your assessment?"

If blame: "I'd rather we focus on making the right decision now than on how we got here."

If delay: "What would we learn in another [time period] that we don't know now?"

The Sunk Cost Exorcism¶

When someone says "but we've already spent $X on this..."

Response Options¶

Option 1: The Hole Analogy "When you find yourself in a hole, the first step is to stop digging. The money we've spent is gone regardless. The question is whether we should spend MORE money."

Option 2: The Forward Value Test "Pretend we hadn't spent anything yet. Would we invest $[remaining budget] to get [expected outcome]? If no, we shouldn't continue just because of past spending."

Option 3: The Explicit Comparison "If we had $[remaining budget] free right now, would we invest it in this, or something else? Let's make that choice consciously."

Option 4: The True Cost "The sunk cost is actually bigger than the money. It's also [X] months of team time, [Y] of stakeholder attention, [Z] of organizational energy. We can't get that back. But we can stop spending more."

Permission to Kill¶

You have permission to kill an AI project if:

• It no longer solves a problem that matters
• The approach isn't working after reasonable effort
• The world has changed and the solution doesn't fit
• The team has lost faith
• Better uses for the resources exist
• Continuing requires believing something you don't believe
• You would advise a friend to stop if it was their project

You don't need: - Permission from the sunk cost - 100% certainty it won't work - Someone else to blame - A failure to point to

The best time to kill a failing project was three months ago.

The second best time is now.

The Kill Decision Canvas¶

Kill Decision Canvas¶

| Decision Maker | _______________ | Date | _______________ |

"The cost of being wrong is lower than the cost of being indecisive."

Kill early. Kill often. Kill honestly.

That's not failure - that's learning.