AI readiness: the five things that actually predict success

Ask a vendor to assess your AI readiness and you will usually get a scorecard about data infrastructure, cloud maturity and model governance. Those things matter. They are also not what separates the companies that get value from AI from the ones that spend two years discussing it.

Across the projects we have run and the ones we have been asked to rescue, five factors do most of the predictive work. Only one of them is technical.

1. Someone in the business owns the outcome

Not the project — the outcome. There is a difference between “Lars is running the AI project” and “Lars is accountable for getting order processing time down, and AI is one of the things he is trying.” The second version survives contact with reality. The first becomes a steering group.

If your AI initiative reports into IT and has no owner in the operation it is meant to improve, that is the single highest-value thing to fix, and it costs nothing.

2. The process you are targeting is already understood

AI does not fix a process nobody can describe. If you cannot draw the current workflow on a whiteboard, including the exceptions and the informal workarounds people have built, you are not ready to automate part of it — you are ready to map it, which is a week of work and worth doing.

The good news is that this mapping has value whether or not the AI project proceeds.

3. The data exists as a by-product of work people already do

The most durable AI cases sit on data that is generated because someone is doing their job, not because someone was asked to log something extra. Order records, service tickets, sensor readings, transcripts, documents.

Where a case depends on data that someone must remember to enter, budget for that discipline eroding within a quarter. Where it depends on data that already accumulates, you have a foundation.

This is the one technical factor on the list, and note how it is framed: not “is the data clean” but “does it arrive on its own.”

4. There is a first version people can actually use in weeks, not quarters

Long AI programmes fail for the same reason long software programmes fail — the business changes underneath them, and the learning arrives too late to act on. If a case cannot produce something a real user can touch within roughly eight to ten weeks, it is usually a sign the scope is wrong rather than the ambition being admirable.

Cut it down until it can. The narrow version teaches you what the broad version would have got wrong.

5. The organisation has decided what it will stop doing

This is the one nobody wants on the list. If an AI system takes eight hours a week out of a team’s workload and the organisation has not decided what those eight hours are for, the value does not appear in any number anyone tracks. It dissipates.

Deciding in advance — redeploy to higher-value work, absorb growth without hiring, reduce lead time to customers — is what converts a technical result into a business result.

Using this

Score yourself honestly on the five, one to five. Most mid-sized companies we meet score well on three and badly on two, and the two are almost always ownership and the stop-doing decision.

That pattern is good news, because those are decisions rather than investments. They can be fixed in a meeting, if the right person is in it.

If you want a structured version of this with the follow-up questions and a written result, our TRX Opportunity Check™ takes about two minutes and we send back a written view rather than a sales call. It is deliberately not called a readiness assessment: a form collects what you tell us about yourselves, and that is a different kind of evidence from a documented analysis. Naming it honestly is part of the same discipline this article is arguing for.