A project receives another round of funding, even though the leadership team still cannot explain what operational benefit it will deliver. The reasoning sounds familiar: the difficult part is almost over. Stopping would undermine the investment already made. Besides, the team has put in a great deal of work.
All of that may be true. It still does not answer the decisive question: Would we approve the money and scarce team time still needed for this project if we were making the decision afresh today?
I would not stop an AI or transformation project simply because it is late. Some foundational work takes longer than expected and remains necessary. But I would not keep funding it simply because so much has already gone into it. Continuing requires a justification for the next investment that can be tested against evidence. That applies just as much to another month of testing as to a rollout into live operations.
The business cost is not limited to additional invoices. While the most experienced people are rescuing an initiative with an unclear purpose, their time may be needed for sales quotations, delivery problems or improvements whose benefits are already tangible. A project can therefore hold back growth even before it has consumed a large budget.
Money already spent belongs in the review of what went wrong, not in the next funding decision
Sunk costs are expenditure already incurred that cannot be changed by today's decision. The UK's Green Book 2026 requires them to be excluded when appraising the decision that remains open. At the same time, alternative uses of resources already paid for should be taken into account.1 This guidance concerns public investment. The underlying economic principle is useful for a business too; it is not a prescribed appraisal model for Swiss companies.
A 2015 meta-analysis by Roth, Robbert and Straus examines 62 samples specifically concerned with decisions to continue projects. On average, higher monetary sunk costs shift decisions towards further investment.3 The studies largely use hypothetical scenarios and student samples. They do not establish a failure rate for CEOs or the size of the effect in today's AI projects. The finding explains why references to past investment should be taken seriously as a warning sign in the case for continuing.
The past still matters. A CEO needs to understand why the original plan did not hold up, which assumptions were wrong and whether someone could have acted in time. Write-offs, contractual issues and communication with shareholders do not disappear. But they should not be confused with the question of whether further work makes sense today.
An explicitly illustrative example, not a Fassbender client case: CHF 180,000 has already been spent on an AI-assisted sales quotation process. A further adjustment is expected to cost CHF 60,000. Under the model assumptions, a benefit of CHF 45,000 after recurring operating, review and maintenance costs appears plausible for the following 12 months of operation. This is an assumption, not a measured result or a revenue forecast.
In this simplified assessment of the first 12 months, the benefit is therefore CHF 15,000 below the additional investment in adjustments. This is not a valuation over the project's full lifetime. The CHF 180,000 already spent does not change that shortfall. Anyone proposing further funding must provide other substantiated reasons, such as longer-term benefits or a necessary capability. The relevant timeframe, costs and risks must then be explicitly included in an expanded assessment.
The calculation alone does not settle the decision. Exit costs, work that could be reused and a viable alternative have not yet been included. That is precisely why management should establish them, rather than treating the existing budget as an obligation to continue. The model amounts represent transformation costs and assumed benefits, not Fassbender fees.
A poor interim result can have two very different causes
A project may be held up by a prerequisite that can be put right. For example, an approved pricing rule may be missing, without which a quotation assistant cannot do useful work. The next task is then clear: the responsible business function must decide the rule. Further technical optimisation might mean spending money in the wrong place, while a limited delay could be justified.
It is a different matter if closer examination shows that the originally expected benefit does not exist. Automated preparation may be faster, yet checking and rework together take more time than before. Or the process may involve so few suitable cases that the additional operation is not justified. Better project communication cannot rescue the original value assumption here.
My first distinction would be this: Is evidence missing that would enable a decision or do the results already contradict the rationale for the project?
If evidence is missing, a tightly bounded test may make sense. It needs a specific unanswered question, suitable cases, someone responsible for evaluating the results and a budget cap. If, however, the objective is no longer relevant or the results undermine the value assumption, a new decision is needed. The next version is not automatically an answer.
Even necessary foundational work should not be protected without limits. An access-control system may be required without directly generating revenue. Its benefit might be to enable a defined operation to run safely. Which applications depend on it? Who confirms the capability required? What is the smallest viable implementation? Without these answers, a necessary foundation can easily become an open-ended project that absorbs unrelated work.
When not to wait for the next steering committee
Where the risk is unacceptable, the budget discussion comes second. If a system discloses sensitive data without control, makes binding commitments beyond its authority or affects a business-critical process without a reliable fallback, the affected use must first be restricted or safely suspended.
The NIST AI Risk Management Framework 1.0, published in 2023, provides for specific mechanisms and assigned responsibilities: AI systems should be capable of being superseded, disengaged or deactivated when their performance or outcomes do not match the intended use. The framework also calls for an assessment of whether development or deployment should proceed and considers viable non-AI alternatives.2 It is a voluntary US framework, not a certification or a guarantee of legal compliance.
Suspending the affected use does not necessarily mean ending the whole programme. An assistant could continue to prepare information while automatic approval of quotations remains switched off. That restriction must work both technically and organisationally. A general warning in the handbook is not enough.
The CEO should know who has authority to intervene, who takes responsibility for operations and what evidence is required before restarting. An acute risk requires an immediate, managed response to make the operation safe. The 90-day approach described here is no reason to wait.
The next approval needs a short, sound decision brief
For an initiative at risk, I would not ask for another presentation covering every activity to date. What is needed is a short brief that the business function, finance and the responsible technology and risk leads can review together.
It starts with the business problem and the expected outcome in the actual workflow. That includes the baseline for comparison, the types of cases in which the solution can genuinely be used and the quality that must be maintained. Anyone claiming shorter quotation turnaround times, for example, must also consider checking effort, margin and incorrect commitments. Processing time alone is not enough.
Next come the costs still to be incurred and the team time required. Internal work does not disappear simply because it is absent from a supplier's quotation. Which other initiative must wait if the same people keep working on this project? Systems already paid for may also have a resale value or an alternative use. Those possibilities should be considered.1
The brief sets out at least one realistic alternative. This might be a simpler manual way of working, a smaller automation or a repaired handover. It does not have to be glamorous. What matters is whether it solves the business problem better, at a reasonable cost and effort. Nor should the existing process be made to look artificially expensive or ineffective to make the new solution attractive.
Finally, record the decision, the person accountable and the date. Further work is approved only up to the next specifically defined evidence requirement. A follow-up test also has a stated unanswered question and a limit on the new investment. A pause has a reason, someone responsible for resolving the missing prerequisite and an expiry date. A stop includes an explicit instruction to manage the exit.
Uncertainty about the benefit is not proof that a project is worthless. But it is a good reason to limit its scope and the next investment until the leadership team can make a better-informed decision.
Learning justifies more budget only if it reduces a specific uncertainty
A pilot does not have to deliver the full benefit expected later. Its purpose may be to reduce an important uncertainty. Does the intended knowledge source work? Are enough cases suitable? Is quality maintained in real use? A negative finding can be valuable if it prevents an expensive mistake.
Before the test, however, it must be clear which decision the result will enable. If each round merely adds another unanswered question, the organisation can learn a great deal without making a better investment decision. Calling it a learning project then protects work whose endpoint no one can describe any more.
At the review, I would therefore insist on a concrete change: which assumption is now better supported or disproved? What can we remove from the next step as a result? Which remaining uncertainty matters enough to justify another limited test?
How the people involved are treated matters just as much. If an honest negative finding is treated as personal failure, there is a greater incentive to play down problems. Management should recognise the quality of the decision without excusing poor project control. Whether a test was well run and whether the tested solution should be pursued are two different questions.