How to kill an innovation project without killing the culture

Every innovation leader I work with agrees on one thing: you need to kill innovation projects that are not working. The evidence is clear, the logic is sound, and the board presentation makes a good case for disciplined portfolio management.

Then a real project needs to die. And nobody pulls the trigger.

I have facilitated over 100 portfolio sessions with industrial companies across 25+ years. Manufacturing companies, chemical processors, equipment makers, B2B enterprises across Europe. The pattern is consistent: companies that say they are willing to kill projects and companies that actually kill them well are almost never the same group.

The difference is not courage. It is not leadership strength. It is governance. Organizations that build termination into their process from day one treat killing a project the same way they treat any other portfolio decision. Organizations that do not build it in treat every kill as a crisis, a failure, or a political event.

This article covers how to set kill criteria before projects start, the four political dynamics that keep bad projects alive, how to build termination into governance so it becomes normal, and what to do with the team after a project dies.

Why most companies cannot kill innovation projects

The inability to kill innovation projects is not a character flaw. It is a structural problem.

In most organizations, starting a project is easy. Someone writes a business case, gets budget approval, assembles a team. There is a process for that. There are templates. There is organizational muscle memory.

Stopping a project has none of that infrastructure. No templates. No process. No precedent that makes it feel normal. Every termination becomes an ad hoc decision, which means every termination becomes a political negotiation.

I worked with an industrial automation company that had 14 active innovation projects. When I asked leadership which ones they would kill if they had to cut the portfolio in half, the room went quiet. Not because they did not know which projects were weak. They did. But nobody wanted to be the person who said it out loud, because saying it meant owning the decision. And owning the decision meant being accountable if the killed project would have succeeded.

That fear, the fear of killing something that might have worked, keeps more bad projects alive than any amount of sunk cost.

Set kill criteria before the project starts

The single most effective thing you can do to make innovation project termination work is to define what failure looks like before the project begins.

This is the same principle that drives fail criteria in business experiments. You agree upfront: if we do not see X evidence by Y date, we stop. The decision is made in advance, when nobody has emotional attachment to the outcome yet.

Good kill criteria have three characteristics:

They are specific. Not “if the market is not big enough” but “if we cannot identify 15 potential customers in the target segment willing to participate in a paid pilot within 6 months.”

They are measurable. Not “if the technology does not work” but “if our prototype cannot achieve a unit cost below €45 by month 9, based on validated production estimates.”

They are time-bound. Every kill criterion includes a deadline. Open-ended criteria become open-ended projects.

At a specialty chemicals company, I helped the portfolio governance board set kill criteria for a new bio-based adhesive project. The criteria were: validate demand with at least 8 potential customers from 3 different application segments within 5 months, and confirm technical feasibility at production scale within 9 months. When the team reached month 5 with only 2 interested customers, both from the same segment, the kill criterion was triggered. The conversation was not “should we stop?” It was “the evidence says stop. Does anyone have new information that changes this?”

Nobody did. The project was terminated in a 30-minute meeting. No drama. No blame. The team was reassigned within two weeks.

Compare that to the companies where kill criteria do not exist. Those termination conversations take months. They involve escalation, political maneuvering, and eventually a decision that nobody owns. By the time the project finally dies, it has consumed six to twelve more months of resources and, worse, damaged trust in the innovation process.

The four political dynamics that keep bad projects alive

Even with kill criteria, politics can override evidence. I have seen four dynamics repeatedly across industrial companies, and they are worth naming because you cannot fix what you do not recognize.

1. Sponsor attachment

A senior leader championed the project. Maybe they presented it to the board. Maybe they recruited the team personally. Their reputation is now tied to the project’s survival.

I saw this at a chemical company where a division president had staked his credibility on a new materials project. The original business case had been disproven. Customer interviews showed weak demand. The technology partner had pulled out. But the project continued for another 18 months because killing it meant the division president losing face. The total cost exceeded €1.200.000 before someone finally had the conversation.

The fix: rotate project sponsors every 12 months. When no single person is permanently attached, termination becomes a governance decision instead of a personal loss.

2. Sunk cost narrative

“We have already invested €800.000. We cannot walk away now.”

Yes you can. And you should, if the evidence says the remaining path to market is not viable. What you spent is gone. The only question that matters is whether the next euro invested will generate enough evidence or revenue to justify itself.

But sunk cost arguments are powerful because they feel logical. The antidote is discipline: every portfolio review should evaluate projects based on forward-looking evidence, not backward-looking investment. I coach governance boards to literally remove the “total investment to date” column from their review dashboard. It is irrelevant to the decision. What matters is: what did the last round of testing reveal, and does the path forward still make sense?

3. Career risk

In many organizations, the person who kills a project carries more risk than the person who lets it linger. If you kill a project and the market later proves it could have worked, your judgment gets questioned. If you let a mediocre project continue indefinitely, nobody notices. The cost is invisible.

This is a system design problem, not a people problem. Organizations that reward “smart kills” the same way they reward successful launches create a different incentive structure. One manufacturing company I worked with started including “projects terminated based on evidence” as a positive metric in their innovation dashboard. Within a year, the number of zombie projects dropped from 9 to 2.

4. Organizational inertia

Some projects survive simply because nobody reviews them. They are small enough to stay under the radar. They have a modest budget line that gets auto-renewed. The team keeps working because nobody told them to stop.

This is the quietest and most common dynamic. I have found zombie projects at almost every company I have done a portfolio review with. Not big failures. Small, persistent drains. Three engineers spending 20% of their time on a project that lost strategic relevance two years ago.

The fix is simple: mandatory portfolio-wide reviews on a fixed cadence. Every project gets reviewed. No exceptions. No “too small to bother.” If a project cannot justify continued investment based on current evidence, it stops.

How to build termination into your governance process

Killing projects should not be an event. It should be a feature of how your innovation portfolio management system works. Here is how to make that real.

Make kill decisions part of every portfolio review

Every quarterly portfolio review should ask three questions about every project: What evidence was generated since the last review? Are kill criteria still on track? Should this project continue, pivot, or stop?

When “stop” is always on the table as a legitimate outcome, it stops being dramatic. It becomes one of three possible results of a normal governance process.

Use evidence dashboards, not pitch decks

This connects to one of the most common innovation portfolio mistakes: reviewing projects based on presentation quality rather than evidence quality. Standardize the format. Every project reports the same metrics: assumptions tested, results per assumption, kill criteria status, next experiments planned. No narratives. No selling.

When every project uses the same dashboard, the governance board can actually compare them. The project with strong evidence and a nervous presenter gets the same fair evaluation as the project with weak evidence and a polished deck.

Create a “sunset protocol”

A formal process for winding down a project removes the improvisation that makes kills feel chaotic. The protocol should cover:

• Team reassignment: Where do the people go? Have the next assignment identified before announcing the termination
• Knowledge capture: What did the team learn that the organization should keep? Customer insights, technical findings, market data
• Communication: Who needs to know, and what is the message? Transparency builds trust. Secrecy destroys it
• Budget reallocation: Where do the freed resources go? This should be a portfolio-level decision, not a political scramble

At one equipment manufacturing company, the governance board created a one-page sunset template. Every terminated project went through the same steps. Within six months, the team told me that kills had become “boring.” That was exactly the point.

What to do with the team after a project dies

This is the part most companies get wrong, and it matters more than the kill decision itself.

When a project is terminated and the team is scattered, left without clear next steps, or worse, treated as if they failed, the entire organization gets a message: taking on risky innovation projects is career-dangerous. Do not volunteer.

I have seen this happen at a packaging company. A team of four engineers spent 14 months testing business assumptions for a sustainable packaging concept. The evidence came back negative: the target customers were not willing to pay the premium required for the unit economics to work. The right decision was to stop. The wrong decision was what happened next: two engineers were reassigned to unrelated maintenance projects, one was moved to a different site, and the team lead was given a vague “strategic projects” role with no clear mandate.

Within three months, the team lead left the company. Within six months, two other innovation project leads asked to return to core engineering roles. Not because they had failed. Because they saw what happened to people whose projects got killed.

The alternative is straightforward:

Treat the team as a resource, not a problem. They have skills that are hard to build: customer discovery, rapid prototyping, business model design, assumption testing. Reassign them to projects that need those capabilities.

Celebrate the learning, not the outcome. A project that generated clear evidence of “this will not work” has saved the company from a much larger investment. That is valuable. Say so publicly.

Make reassignment fast. The worst thing you can do is leave people in limbo. Have the next assignment ready before the kill announcement. “Your project is stopping. Here is where you are going next and why we need you there.” That is a sentence that protects both the person and the culture.

When a kill goes right and when it goes wrong

I have seen both. The difference is always governance, never courage.

A kill that went right. A B2B sensor manufacturer had an explore project testing a predictive maintenance service model. After 8 months of customer discovery and two pilot deployments, the team concluded that the target segment, mid-size food processors, did not have the IT infrastructure to support the service. Kill criteria triggered. The governance board reviewed the evidence, agreed with the recommendation, and terminated the project. The team was reassigned to a related IoT project that needed their embedded systems expertise. The customer insights from the terminated project informed the new project’s go-to-market approach. Total time from kill decision to full team reassignment: 10 days.

A kill that went wrong. A specialty materials company had a new application project running for three years. No formal kill criteria. The project had consumed over €900.000 with no validated customer demand. When a new VP finally forced a termination, it was done abruptly, in a Friday afternoon email. No explanation of the evidence. No team reassignment plan. No knowledge capture. The project lead described it as “being fired from a project I had given three years of my life to.” Two other innovation project leads scaled back their ambitions within months. The portfolio became more conservative, not because of strategy, but because of fear.

Same action: kill a project. Completely different outcome based on how it was done.

Connecting kill decisions to your portfolio strategy

Kill decisions do not happen in isolation. They connect to every other part of your innovation portfolio management system.

Your portfolio allocation determines how many explore projects you fund. More explore projects means more potential kills. That is not a problem. It is the system working as designed.

Your explore vs. exploit balance depends on the willingness to kill explore projects that do not validate. If you cannot kill, you cannot explore, because every failed explore project becomes a permanent budget drain.

Your framework for evaluating the portfolio should include termination as an explicit stage. Projects move forward, pivot, or stop. All three are legitimate outcomes.

And the testing discipline from Testing Business Ideas provides the evidence that kill criteria depend on. Without rigorous assumption testing, kill criteria are just opinions with deadlines.

The pivot-or-persevere decision is closely related: sometimes a project should not be killed but redirected. See pivot or persevere for how to make that call at the portfolio level.

For a complete governance system including review cadence, dashboards, and decision criteria, see innovation portfolio governance.

Evidence-based kill decisions require innovation accounting to measure what matters at each stage.

If your organization struggles to make kill decisions stick, the problem might be deeper than governance. An innovation readiness assessment can reveal whether your culture, leadership support, and organizational design are set up for the kind of honest decision-making that portfolio management requires.

Frequently asked questions

When should you kill an innovation project?

Kill an innovation project when it hits the kill criteria you set before the project started. Those criteria should be specific and evidence-based: customer demand not validated within a set timeframe, unit economics that do not work at a defined threshold, or technical feasibility not confirmed by a milestone. The key is that the decision should already be made before the evidence arrives. If you are debating whether to kill a project without predefined criteria, you are already in political territory where sponsor attachment, sunk cost thinking, and career risk will dominate the conversation.

What are kill criteria in innovation?

Kill criteria are predefined conditions that trigger project termination. They work the same way as fail criteria in business experiments: you agree upfront what failure looks like, so the decision is evidence-based rather than political. Good kill criteria are specific (“find 10 customers willing to pay €X”), measurable (based on evidence, not opinion), and time-bound (every criterion has a deadline). Setting them before a project starts removes the emotional and political dynamics that keep bad projects alive.

How do you kill a project without damaging team morale?

Three things matter. First, separate the team from the outcome. A killed project is not a failed team. It is a team that generated evidence the organization can use. Second, have a plan for the people before you announce the kill. Reassign them to projects that need their skills, not to random roles. Third, make the kill public and explain the evidence. When teams see that termination is based on data and that the people land well, they trust the system. When kills happen behind closed doors and people disappear, nobody will take risks again.

What is the sunk cost problem in innovation portfolios?

The sunk cost problem is when organizations keep funding a project because of what they have already spent rather than what the evidence says about future potential. In innovation portfolio management, this is amplified by career risk: the person who approved the original investment does not want to admit the money was wasted. The antidote is governance that evaluates projects based on forward-looking evidence, not backward-looking investment. I coach governance boards to remove the “total investment to date” column from their review dashboards. It is irrelevant to the decision.

How many innovation projects should be killed per year?

If your portfolio has not killed a single project in the past 12 months, your governance is not working. A healthy innovation portfolio terminates 30-50% of early-stage explore projects because that is the nature of innovation under uncertainty. Most ideas should not survive contact with real customer evidence. If everything survives, either you are not testing rigorously enough or political dynamics are protecting projects that should be stopped. The goal is not to kill projects for the sake of it. The goal is to reallocate resources from projects without evidence to projects with evidence.