What an AI readiness assessment should actually answer

An AI readiness assessment is worth doing if it changes what you do next. If it produces a maturity score and a slide with five coloured circles, it was an expensive way to feel prepared.

The test is simple: after the assessment, can leadership name what they are doing first, what they are deliberately not doing yet, and what has to be true before the second thing starts? If not, the assessment did not finish.

The five questions worth answering

Most published frameworks converge on similar dimensions — data readiness, technology infrastructure, talent and skills, governance, and organisational culture is a representative set. That is a reasonable checklist for what to look at. It is not a description of what to conclude.

Reframed as decisions rather than categories, the assessment has to answer five things:

1. Is there a business problem worth the effort? Not "where could we apply AI" — that question always has answers, and most of them are bad. The useful version is: what is currently expensive, slow, or error-prone enough that fixing it would show up in a number somebody is accountable for? If the honest answer is "nothing much", that is a finding, and a cheap one to receive.

2. Is the process underneath stable? AI applied to a process that changes every quarter produces a system that is wrong every quarter. A process being messy is fine — messy is normal and often exactly where the value is. A process being in flux is not. If the team is mid-reorganisation or the workflow genuinely differs across regions, sequence around it rather than automating a snapshot that expires.

3. Is the data good enough, and can you actually get it? These are two separate questions and the second one kills more projects. Data can be excellent and still be locked behind a system nobody controls, a vendor contract that prohibits export, or a retention policy that deletes what you need. "Good enough" is also relative to the use case — triage tolerates noise that pricing does not.

This dimension carries more weight than the others. MIT Sloan Management Review research found organisations that invested in data infrastructure before launching AI initiatives were 2.6 times more likely to hit their expected outcomes. That is a large effect for something routinely treated as a prerequisite to rush through.

4. Do the people who will own it understand what is coming? Not the sponsors — the owners. The team whose daily work changes. If they first hear about the system at launch, adoption becomes a negotiation you have already lost. This is where readiness assessments most often flatter the organisation, because the people interviewed are rarely the people affected.

5. Can the organisation absorb the change? Every deployment consumes attention: training, exception handling, a period where the new thing is worse than the old thing. An organisation running four transformations already cannot absorb a fifth, regardless of how good the business case looks in isolation.

Why scorecards fail

The maturity-score format fails for a specific reason: it averages away the thing that matters.

An organisation with excellent infrastructure, capable people, and completely inaccessible data is not "medium readiness". It has one blocking problem and four irrelevant strengths. Averaging those into 3.2 out of 5 destroys exactly the information the assessment existed to surface.

Constraints are not additive. One hard blocker outranks four soft strengths, and the output should say so plainly: this is the thing standing in the way, here is what it would take to clear it, here is what is worth doing in the meantime.

What the deliverable should contain

Four things, and it should be short:

• A ranked shortlist of use cases — three is usually right, with the reasoning for the ranking visible so leadership can argue with it
• Preconditions per use case — what must be true before delivery starts, stated as verifiable conditions rather than aspirations
• A sequence — what happens first, what it unblocks, what waits
• An explicit not-yet list — the things that look attractive but should wait, and what would change that

That last one is the item most often missing and the one that saves the most money. An assessment that only says yes has not done the harder half of the work.

How long it should take

One to three weeks for a scoped review. Assessments that run for months are usually surveying the entire organisation rather than answering a specific question — and by the time the findings are presented, the priorities that prompted them have moved.

If a scope cannot be reviewed in three weeks, the scope is wrong. Narrow it to one part of the business, finish, act, then repeat somewhere else. A short assessment that changes a decision beats a comprehensive one that arrives after the decision was made.

What we do

Our AI Opportunity Sprint is deliberately one week and deliberately narrow: a focused audit of one part of the business, short interviews with the people who own the work, and a ranked set of opportunities with the metric each should move. The output is a written roadmap and a 45-minute readout, not a scorecard.

The point of a readiness assessment is not to certify that you are ready. It is to tell you what to do on Monday — and, just as usefully, what to leave alone until something else is true.

If you are further along than this and your problem is a pilot that already stalled, that is a different failure with different causes.