When to shut down an innovation project that won't scale
Shut down an innovation project when it stops answering the question that started it, not when the budget runs out. The decision stalls because almost no initiative is born with a written stop criterion, a defined owner and a date on the calendar for review. Without those three things, ending depends on someone's judgment, and personal judgment loses to money already spent.
Why is shutting down an innovation project so hard?
Because the decision was designed as a personal one when it should have been structural. Whoever approved the pilot is almost always the person who has to admit it is going nowhere. In that configuration, each extra month of survival costs less than the shutdown conversation.
The literature calls this escalation of commitment, the habit of continuing to invest in a course of action that no longer holds up. The study by Mark Keil, Joan Mann and Arun Rai published in MIS Quarterly measured how often the phenomenon appears in information systems projects and found some degree of escalation in 30% to 40% of them. It is a paper from 2000, and the number keeps getting cited because the mechanism has not changed: what keeps the project alive is not the evidence in favor, it is what has already been spent.
Add the typical design of an innovation function. The pilot has a small budget, a short timeline and high visibility. Nobody has to approve a formal renewal, because no formal ending was ever scheduled. The project simply continues, consuming a status meeting, a tool license and a slice of the calendar of someone who could be unblocking something else.
What does keeping a non-scaling project actually cost?
The cost is the attention of whoever decides. In an established company, managerial attention is the scarcest resource: it is what secures people, signals priority and mobilizes the organization. If the project is not important to someone who matters, it does not scale.
Most of what an innovation function starts never becomes an operation. That is expected in a portfolio of experiments. What is not expected is for that majority to stay open.
The measurement from S&P Global Market Intelligence, covering more than a thousand respondents across North America and Europe, shows the other side of the movement. The share of companies abandoning most of their AI initiatives rose to 42% in 2025, against 17% the year before, and the average organization discarded 46% of proofs of concept before production. Reading that as failure is reading it wrong. Discarding a proof of concept is the design working. The useful question is how long each one stayed open before being discarded.
How do you know it is time to end it?
Three signals are enough, and none of them depends on an opinion about the quality of the idea.
The first is the original question. Every innovation project starts to answer something: whether a specific bottleneck gives way, whether an audience uses the thing, whether the cost falls. When the answer has arrived, the project is over — including when the answer is positive. From there it is a different project, with a different scope and a different budget, and it needs approving as such.
The second is where the movement comes from. A project that only advances when someone pushes is a project with no owner in the operation. Measure it simply: over the last four weeks, how many of the project's actions came from the department that will use the system, and how many came from the innovation function. When the second number is the only one above zero, you have a pilot the operation tolerates, not one it wants.
The third is the path to production. Before renewing anything, ask who pays for support next year, who is accountable when the system goes down at 10pm, and which budget the ERP integration comes out of. If nobody has an answer, the project is not behind schedule. It has no destination, and with no destination it will not arrive, however good the test result was.
How do you decide the ending before you begin?
By writing four lines at approval time, not during the crisis. The question the project answers. The criterion that authorizes continuing. Who has the authority to end it. The date that conversation happens regardless.
Those four lines change the nature of the decision. Ending stops being somebody admitting a mistake and becomes the fulfilment of an agreement made when nobody had ego invested. It is the logic of a contract clause: you negotiate the exit while the relationship is good.
A hypothetical scenario at realistic scale helps show the mechanism. An innovation manager at a mid-sized manufacturer has eleven initiatives on the board. Applying the three signals, she finds four that answered their original question months earlier, two that only move when she chases them, and one no department has agreed to support. She ends seven. The budget released is modest, roughly licenses and vendor hours. What actually changes is the calendar: the fortnightly status meetings for those seven projects added up to nearly a full working day a month for her and two department managers. That day goes to the most advanced of the four that remain, which had a path to production and was stalled for lack of people.
What survives a project you shut down?
More than usually gets recorded, because shutdowns rarely have a defined deliverable. Three things survive when someone takes the trouble to keep them.
The first is the data. A pilot that ran six weeks in one unit usually produces the first reliable measurement of that process. The software was discarded; the time series was not, and it is what supports the business case for the next attempt. It is worth storing it to a quality standard, because a measurement loose in a dead project's spreadsheet disappears with the project.
Next comes the integration. Connecting a legacy system to an external service is usually the expensive part of the pilot, and the connector keeps its value even when the hypothesis under test does not hold. It is the same logic we apply to inherited platforms, as in the work with Colo Saúde: what already existed became an audited base rather than debris to discard.
Last, the specification. A provisional artifact that went through real use describes the right system with a precision that requirements-gathering in a meeting room rarely reaches, and that holds both for the pilot that died and for the improvised solution that hit its limit. At SuperVida, contract management ran on an improvised Airtable base, and the data and flows already running there were the starting point for the bespoke ERP. At UniTrust, the first system went live in two weeks under deadline pressure, after the founders broke with their previous provider, and it was real use of that system that defined what the platform needed to become.
Frequently asked questions
Doesn't shutting down a project demoralize the team that worked on it?
It does when the shutdown arrives as a verdict on quality. It does not when the rule was written from the start and the team took part in applying it. It helps a great deal to separate two things in the communication: the project ended, and its learning went into the next one. A team that sees its own data used further along understands the ending as a cycle.
How do I justify to leadership that we invested and are now stopping?
By presenting the shutdown as the result of the decision process leadership approved, with the number of what was learned and the number of what was freed. Leadership reacts badly to a project that dies quietly after two years of optimistic reporting. It reacts well to a portfolio with a review date, because that is exactly the control it asks for when approving the budget.
What if the stop criterion is wrong and the company kills something good?
That is a real risk, and the protection is writing the criterion together with whoever will use the system, not only with the sponsor. Plan for reopening too: a project ended with its data and specification preserved can come back later without repeating the discovery cost of the first round. What does not come back is the attention spent keeping ten projects half alive.
An innovation portfolio is defined by what it ends
The ability to shut things down is what separates a portfolio from a list of open projects. It does not come from individual discipline or from a culture tolerant of failure. It comes from architecture: a written question, a continuation criterion, an owner for the decision and a date on the calendar, all defined before the first kickoff meeting.
If your initiative board grows every quarter and never shrinks, the bottleneck is not in project execution. It is in the design of how they end. A 30-minute Operational Architecture Diagnostic exists to look at that design with you and identify where the decision is stalling.
Related case studies
Did you recognize your operation in this article?
Book the Operational Architecture Diagnostic: 30 minutes to map where your operation's bottleneck is. No strings attached.
Book a diagnostic