Stop Wasting Time on the Wrong Things

Time to read: 7 minutes
Time to apply: 30 minutes

You have 7 active projects. Only 3 are delivering value. But you keep funding all 7 because "we've already invested so much."

Killing a project feels like failure. But continuing a project that won't succeed is worse. It wastes money, team morale, and opportunity cost. The best leaders know when to stop.

What You'll Learn

• 5 signals a project should be killed
• How to calculate sunk cost vs future cost
• How to communicate the decision
• Template kill-list document

Why We Don't Kill Projects

Three psychological biases keep bad projects alive:

1. Sunk Cost Fallacy

"We've already spent £500k. We can't stop now." But sunk costs are gone whether you continue or not. The question is: Should we spend another £300k?

2. Political Pressure

Someone senior championed this project. Killing it means telling them they were wrong. So you keep funding it to avoid conflict.

3. Optimism Bias

"It's just taking longer than expected." "The next sprint will turn things around." We overestimate probability of success and underestimate time to completion.

The result: Zombie projects that drain resources for years without delivering value.

5 Signals to Kill a Project

Here are the warning signs. If you see 2 or more, it's time to seriously consider stopping:

Signal 1: No Measurable Progress in 3 Months

Progress isn't activity. It's results. If you can't point to concrete deliverables or measurable improvements in the last quarter, the project is stalled.

Example: "We've had 12 sprint reviews but still no working prototype. The team keeps refining requirements instead of building."

Signal 2: Team Morale Dropping

When good people start asking to move to other projects, something is broken. Teams can sense when they're working on something doomed.

Example: "Three senior engineers requested transfers in the last 2 months. Exit interviews cited 'lack of clear direction' and 'constantly changing requirements.'"

Signal 3: Original Problem No Longer Exists

Markets change. Customer needs shift. The problem you set out to solve 18 months ago might not matter anymore.

Example: "We started building an integration for a platform our customers use. Since then, 60% of customers switched to a competitor platform."

Signal 4: Better Options Emerged

Technology moves fast. A build-it-yourself project might be obsolete if a vendor now offers the same capability at lower cost.

Example: "We've been building custom analytics for 8 months. A vendor just launched the exact features we need for £50k/year vs our £300k build cost."

Signal 5: Cost to Complete > Expected Value

The business case assumed £200k total cost and £500k annual value. You're now at £300k spent with another £400k to go. The math no longer works.

Example: "Original estimate: £200k build, £500k/year value. Revised: £700k total cost, £300k/year value. ROI went from 2.5× to 0.4×."

Sunk Cost vs Future Cost

The decision to kill a project should only consider future costs and value, not past spending. Here's how to calculate it:

The Kill Decision

Once you've identified the signals and run the numbers, ask these questions:

1. Risk If We Continue

What happens if we keep funding this project and it fails anyway? We waste more money, delay other priorities, and damage team morale.

2. Risk If We Stop

What happens if we kill this project and we were wrong? We lose the sunk cost (already lost) and potential future value (which may not materialize).

3. Opportunity Cost

What could we do instead with those resources? Could we fund a higher-value project? Redeploy the team to something with better ROI?

Frame the decision as: "Is this the best use of our next £X and Y months?" Not: "Should we waste the £Z we've already spent?"

Communicating the Kill

How you communicate matters. Frame it as good stewardship, not failure:

Real Example: £500k Project Killed, £300k Saved

Context: A fintech company building a custom fraud detection system. 6 months in, £500k spent, £800k estimated to complete.

The Signals:

• Signal 1: No production deployment after 6 months. Still in prototype phase.
• Signal 2: Lead ML engineer left for "better opportunities." Team morale low.
• Signal 4: Market vendor launched similar solution at £200k/year (vs £800k build + £150k/year maintenance).
• Signal 5: Total cost now £1.3M vs original £600k estimate. Expected value unchanged at £400k/year.

The Decision:

• Future cost to complete: £800k build + £150k/year maintenance
• Vendor alternative: £200k/year
• 3-year cost: Build = £1.25M, Buy = £600k
• Probability of build success: 50% (given current challenges)

The Outcome: Killed the build project. Bought vendor solution. Saved £300k over 3 years. Team redeployed to revenue-generating features.

Kill-List Template

Summary

Projects should be killed when:

• No measurable progress in 3+ months
• Team morale is declining
• Original problem no longer relevant
• Better alternatives now exist
• Cost to complete exceeds expected value

The decision should only consider future costs and value, not sunk costs. Frame kills as good portfolio management, not failure.

Communicate clearly: What we learned, why we're stopping, what we're doing instead, and how it affects the team.

Ready to Apply This?

Review your current project portfolio. Identify 2-3 projects showing kill signals. Run the future cost vs expected value calculation for each.

---

Need Help Applying This to Your Situation?

We use these frameworks with our clients every month to make priority decisions in 30 days (or less).