We usually celebrate the start of a project. Kickoff meetings. Roadmaps. Timelines. Fancy slides with words like “transformational,” “scalable,” and “high-impact.” Everyone is excited.
Until reality quietly shows up a few weeks later and asks:
“So… are we still sure about this?”
Because nobody really celebrates what might be the most important decision in a project’s lifecycle:
Stopping it.
And once a project starts in most organizations, it rarely stops. It just slowly… transforms into something everyone continues “just to finish,” even when no one really believes in it anymore.
So here’s a slightly uncomfortable question: should every project have a kill switch?
Not a literal red emergency button (though honestly, some Monday meetings would justify it), but a structured way to pause or stop a project when it no longer makes sense.
Interestingly, the idea isn’t entirely new. In software development, a kill switch is often used as a safety mechanism when something isn’t behaving as expected — because experienced teams know that reality doesn’t always follow the plan. Maybe projects deserve the same kind of safety net.
Let’s talk about it.
The uncomfortable truth: projects rarely die when they should
Projects don’t usually fail loudly. There’s no dramatic shutdown, no “mission failed” moment. They fade.
“We’ve already invested too much to stop now.”
“Let’s just complete it—it’s 80% done.”
“We’ll revisit the value after launch.”
That last one is especially dangerous. It usually means: “We’ll decide if this was worth it… after we’ve already spent everything.”
And that’s how organizations slowly accumulate something dangerous…
🧟 Zombie projects
Still alive. Still consuming energy. But no longer really serving a purpose. Just… existing.
Every PM has seen one. Some of us have inherited one. Some of us are reading this and immediately thinking of one.
Why we struggle to stop projects
Stopping a project sounds logical on paper. In reality? It feels like breaking up with something that never loved you back.
1. The sunk cost illusion
“We’ve already spent three months on this.”
Yes. You have. And those 3 months are gone — they are not coming back no matter how many status meetings we schedule about them.
But psychologically, we treat past effort as justification for future effort, even when logic quietly says: “This isn’t worth it anymore.”
2. Nobody wants to be the “stopper”
Try saying in a meeting: “Maybe we should stop this project.” Sounds reasonable in your head. But somehow, what people hear is:
“Everything we did was a mistake.”
Even when that’s not what you meant. So instead… we continue. Politely. Carefully. Uncomfortably. Together.
3. The “almost done” illusion
Every project has this phase:
- 80% done
- 85% done
- 90% done (for 3 weeks straight)
At this point, “almost done” stops being a status. It becomes a lifestyle. And somehow, the project becomes immortal.
What is a kill switch in project management?
A kill switch is not about failure. It’s about clarity.
In software, a kill switch exists because teams understand that plans change, risks emerge, and assumptions sometimes turn out to be wrong. Projects are no different.
“Under what conditions do we stop, pause, or rethink this project?”
Not during a crisis. Not during panic. Not when everyone is already exhausted. But in advance — so stopping becomes a decision rather than a disaster.
Not every project needs a kill switch
This is where many people get uncomfortable, because no — I’m not suggesting that every project should be treated like an experiment waiting to be cancelled.
Some projects are mandatory. Some are compliance-driven. Some are strategic commitments that simply have to be delivered.
But there are projects where a kill switch becomes incredibly valuable. For example:
Projects with unstable requirements
Where the team is building while still figuring out what they’re building.
Projects where business priorities keep shifting
The destination changes faster than the team can travel.
Projects based on assumptions rather than validation
“We think users will want this.” Sometimes that’s true. Sometimes it’s expensive.
Projects where effort keeps increasing but clarity doesn’t
More work. More meetings. More discussions. No more certainty.
Projects driven by momentum rather than value
Perhaps the most dangerous type of all — projects that continue simply because they already started.
What actually triggers a kill switch?
A kill switch shouldn’t be emotional. It should be evidence-based.
The trigger isn’t “this feels difficult.” The trigger is “this no longer makes business sense.”
Some common signals include:
- The expected value has significantly dropped
- Requirements continue changing with no stable direction
- User validation is consistently weak
- Costs continue increasing without proportional benefit
- Business priorities have shifted
- The original problem is no longer the problem
Or put simply: continuing is no longer aligned with reality.
Real life in projects (we’ve all been here)
Let’s be honest — sometimes the warning signs are obvious.
Developer:
“Wait… are we still building this?” (silence). That silence says more than any Jira board ever will.
Designer:
12 versions later, just opens Figma and stares at it, waiting for the design to magically make sense.
QA:
Testing “final-final-v7” with emotional detachment. No longer surprised. Just… prepared.
PM:
Updating status: “We are aligning on final alignment for alignment confirmation.” And somewhere deep inside thinking: “We are not building a product anymore. We are maintaining momentum.”
What changes when a kill switch exists?
Surprisingly, a lot.
People become more honest
Because continuation is no longer automatic.
Teams prioritize better
They think harder before committing resources.
Bad ideas fail faster
Which sounds negative until you realize it’s much cheaper than letting them fail slowly.
Less emotional attachment
Projects stop becoming personal commitments and start becoming business decisions — in a way, similar to how feature flags give software teams flexibility.
The goal isn’t to switch things off. The goal is knowing you can respond intelligently when reality changes.
But won’t this create instability?
This is the common fear: “If we allow stopping projects, won’t everything feel uncertain?”
Actually, the opposite happens. A kill switch doesn’t create chaos — it creates clarity, because now everyone knows:
- What success means
- What failure looks like
- And what “stop conditions” are
The real chaos is not stopping. It’s continuing things blindly while pretending everything is fine.
A simple mindset shift
Instead of asking “how do we complete this project?”…
Start asking: “Under what conditions would we stop this project?”
That one question changes behavior immediately. It forces:
- Clearer goals
- Better alignment
- Honest expectations
- Fewer unnecessary months of “almost done”
Final thoughts
Project management is often described as the art of getting things done. And that’s true. But sometimes it’s also the art of knowing what not to continue.
A kill switch doesn’t make organizations weaker. It makes them more honest — because continuing a bad idea is not discipline. It’s just delayed decision-making dressed as progress.
The best teams I’ve worked with weren’t successful because everything went according to plan. They were successful because they knew when to adapt, when to rethink, when to change direction… and occasionally, when to stop.
Because sometimes the most professional thing a project manager can say isn’t “we’re on track.” It’s:
“This no longer makes sense.”
And having the courage to say that might be one of the most valuable project management skills of all.
