Most AI projects pay off, and very few pay off the way their business case said they would. That gap is mostly about how the case was written. A case written to get a project approved and never opened again gives you permission to spend, and that is about all it gives you. If you are about to fund an AI project, write the case so someone can check it against what happens, and put the date of that check in the case itself.
The size of the gap is the reason to bother. Only 13% of the organizations BearingPoint surveyed in August 2026 had grown their AI work to the size the original case described. Most of the ones that had put AI into operations still reported a measurable effect on revenue or costs. So the money is buying something, on cases that did not hold up the way they were written.
Can anyone check your AI business case against a number?
A case built backward from the answer has a tell. It promises an outcome but names no measure anyone plans to look at again, so it can never turn out wrong. Testing claims is most of what I do, and that is the first thing I look for in a case: a number that someone has agreed to be checked against.
The most mature group in the survey, the organizations whose AI runs through most of their operations, does this far more often. Seventy percent of them have a measurable financial target on most of their AI projects, against 34% in the larger group one stage behind them. Tying the case to a number is the cheapest habit those organizations have, and the easiest one to copy this quarter.
A missed forecast is useful if someone goes back to it
For almost three-quarters of the organizations in the survey, the plan moved: the scope was rewritten or the rollout stayed smaller than the case had said. That does not bother me much. A forecast is a claim about the future, and some of them will miss. When you study a miss, you find out which assumption broke: the data, how fast the team took to the tool, or what it cost to run at full size.
What wastes money is the miss nobody studies. Nine in ten organizations told BearingPoint a weak expected return would not stop their AI spending. Going on can be the right call. Going on without reopening the first case means nobody learns which assumption broke.
Put four things in the case before you sign it
BearingPoint's own recommendations point the same direction as mine, and my test for a case is short: does it have these four things in it?
- The one number the project should move, measured today, so nobody argues about the starting point later.
- What "scaled" means for this project: one team, every location or the whole process, and by when.
- The date the case gets reopened, and the person who answers for the result. That person works for you, not for the vendor.
- What happens on that date: scale it, fix it or stop it, with a rough sense of what each would take.
A small trial does not need a business case
If you are giving a handful of people a tool for a month to see what it does, a written case is more paperwork than the trial is worth. Set a day to look at what happened and leave it there. The case earns its keep when a project needs its own budget line, changes how a team works or would be hard to back out of.
Read your last AI case next to its results
Find the last AI project you approved and put its business case next to what has happened since. If you cannot find the case, or it holds no number you could check, you already know how the next one will go unless something changes.
Two earlier posts go further on the number itself: why to score AI on growth and why a first-time CEO needs a forecast they can be held to. Reading AI cases before they get signed is part of my work with mid-market leaders. If one is on your desk now, send it over and I will read it with you.
Source: BearingPoint, "AI delivers value, but only 13% of organizations scale it as planned," Oct 1, 2026; online interviews in August 2026 with 1,050 C-suite executives and senior leaders in 13 countries across Europe, the United States and China.
John Wyatt · John Wyatt's page · All posts · RSS