Every transformation post-mortem I have sat through eventually arrives at the same conversation. Someone suggests the technology was wrong. Someone else says the vendor over-promised. A third person defends the methodology. And almost nobody says the thing that was actually true, which is that the programme was already in trouble on the day the platform was chosen, because nobody could yet articulate the problem it was meant to solve.
Sequencing is the most expensive mistake in transformation, and it is the one least likely to appear in the lessons-learned deck.
The pattern is old. The evidence is new.
This is not a new observation. It has been true of ERP rollouts since the nineties and of operating-model redesigns for at least as long. What is new is how visible it has become, because AI has compressed the whole cycle into something you can watch happen inside eighteen months.
Gartner forecasts that 40% of agentic AI projects will be cancelled by the end of 2027. MIT’s Project NANDA found that 95% of enterprise generative AI pilots show no measurable impact on the P&L. S&P Global’s adoption data points the same way, as does Studio Graphene’s 2026 UK research.
Those numbers get quoted as an indictment of AI. They are not. Read the failure descriptions rather than the headline percentages and the common thread is consistent: organisations reached for a platform before the business problem was defined precisely enough for anyone to say what success would look like.
Swap “AI model” for “ERP system” or “target operating model” and the same sentence describes programmes that failed in 2011.
What “problem before platform” actually means in practice
It is easy to nod at this and change nothing, because the phrase sounds like a truism. It isn’t. It implies a specific and slightly uncomfortable discipline.
A problem statement is not a business case. A business case says what you expect to gain. A problem statement says what is currently happening, to whom, how often, at what cost, and what would have to become true for that to stop. If you cannot write that in five sentences without naming a vendor, you are not ready to shortlist one.
“We need to be more data-driven” is not a problem. It is an aspiration with a budget attached. “Six systems hold customer records and no two agree on which is current, so the finance team reconciles by hand for four days at every month-end” is a problem. The first one buys you a platform. The second one tells you which platform, or whether you need one at all.
The definition has to survive contact with the people doing the work. Problem statements written entirely at ExCo level tend to describe the symptom that reached the board, not the mechanism that produced it. That is how organisations end up automating a process that should have been removed.
Success criteria come before selection, not after. If the measures are agreed after the vendor is chosen, they will, entirely honestly and with the best intentions, be shaped by what that vendor can deliver.
Why the sequencing goes wrong anyway
Nobody sets out to do this backwards, which is worth taking seriously, because it means the cause is structural rather than a failure of intelligence.
Platform decisions are legible. They have vendors, demos, reference calls, a price, and a date. Problem definition has none of that. It produces a document, it takes six to ten weeks, and for most of that period it looks like nothing is happening, particularly to a board watching a competitor announce something.
There is also a genuine commercial asymmetry. An enormous amount of professional effort is funded to help you choose a platform. Almost none is funded to help you decide whether you need one. That imbalance is not a conspiracy; it is just where the money is. But it means the pull towards premature selection is constant, and resisting it has to be somebody’s actual job.
That is the honest reason this is a leadership problem rather than an analysis problem. The sequencing discipline survives only where someone senior enough to absorb the pressure owns it, and is not the same person whose revenue depends on the platform being bought.
The cheap test
Before the next platform decision, try this. Pick four people: the sponsor, someone from the function that will use it, someone from finance, and someone from technology. Ask each of them, separately, to write down in two sentences the problem the investment solves.
If the four answers describe the same problem, the sequencing is probably sound and you can proceed with some confidence.
If they describe four different problems, you have not found a technology question. You have found an operating-model question wearing a technology question’s clothes, and buying the platform will not resolve it. It will distribute it.
That exercise costs an hour. The programme it saves costs rather more.
One caveat, stated plainly
Sequencing discipline can itself become a way of never deciding anything. There are organisations where “we need to define the problem better” is the standing excuse for another quarter of inaction, and that failure mode is real, if less expensive than the alternative.
The test is whether the definition work has an end date and a named owner. Six weeks to a problem statement the board can interrogate is discipline. Six months of workshops is avoidance. Both look identical in the first fortnight, which is precisely why somebody has to be accountable for telling them apart.