Most AI programmes fail on data access, process clarity or accountability rather than on the technology. The assessment below scores all four dimensions in about ten minutes, and it will tell you where you actually are rather than where a vendor would like you to be.
The four dimensions
AI consulting assesses where AI will and will not pay back in your operation, then sequences the work. A readiness assessment scores data quality, process maturity, integration surface and governance, and produces a costed roadmap rather than a technology shortlist.
None of these are technology problems, and all four are visible in a two-week assessment.
Twelve slides naming platforms and zero slides naming a process, an owner or a number. Nobody can disagree with it, which is precisely why it will not survive its first budget review. A strategy that cannot be argued with cannot be executed either.
The chosen first use case produces output no one is able to verify. Six months later the debate about whether it is working is unresolvable, because it always was. Verifiability is a hard filter for us, not a preference.
An ambitious predictive project is scheduled first, and three months in it stalls because the historical data cannot be extracted without an integration nobody scoped. Ordering the roadmap around what depends on what is most of the value of doing one.
Everyone assumes somebody else has signed off on what the system decides. The gap becomes visible during the first incident, which is the worst possible moment to discover it. Settling accountability is a week of conversations and it belongs at the start. See AI governance.
Twelve questions across four dimensions. Answer honestly rather than aspirationally — the value is entirely in the low scores. Nothing is sent anywhere; the scoring runs in your browser.
Dimension 1 · Data
1. Does the operational data for this area live in systems rather than spreadsheets?
2. Could you extract a year of history without somebody exporting it by hand?
3. Does the same customer or item resolve consistently across your systems?
Dimension 2 · Process
4. Is the target process documented, and does the document match reality?
5. Do you know its handling time and its exception rate?
6. Is there one named person who can approve a change to how it works?
Dimension 3 · Integration
7. Do the key systems expose APIs you can actually get access to?
8. Is there a non-production environment to test against?
9. Do you have somewhere you could run new workloads today?
Dimension 4 · Governance
10. Do you know which categories of data are allowed to leave your network?
11. Would a named person be accountable for a decision the system makes?
12. Is there a way to review a change and roll it back if it goes wrong?
Readiness score
0 / 24
A model project here would stall on access rather than on capability. Start with something that produces value while building the foundation: measuring one process, or connecting two systems. Process measurement is the usual entry point.
Weakest dimension
Answer the questions to see this.
Talk through your scoreDocuments you can act on, including the ones that argue against spending money with us.
Every candidate we gathered, scored on value, effort and verifiability, including the ones we removed and why. The rejected list gets read more than the shortlist in most steering meetings, because it settles arguments that would otherwise resurface every quarter.
Value scoring uses measured handling data where it exists and an explicit assumption where it does not, labelled as such.
Not by ambition. If the flagship project needs an integration and a data fix, those appear before it with their own effort attached, and something smaller ships first so the programme has a result to point at.
Where a product already does the job, we say so. Our incentive to recommend a build is real and we would rather name it than pretend it does not exist.
A second opinion on an in-flight initiative: evaluation approach, security posture, provider lock-in and whether the success criteria are measurable at all.
Who decides, who reviews, who is accountable when an automated decision is wrong. Designed with our IT advisory practice.
Two to four weeks for a defined business area, feeding directly into the delivery sequence used across the AI and automation practice.
The same twelve points as the assessment above, but evidenced rather than self-reported: we look at the systems, try the exports, and read the process documentation against what people actually do. The weakest dimension usually determines what a first project can realistically be.
Workshops with operators, not only with leadership. The highest-value candidates are routinely invisible from the top of an organisation chart, because the people absorbing the cost stopped mentioning it years ago.
Value, effort, and whether the result can be verified. That third filter removes more candidates than the first two combined, and removing them early is the point. Process measurement supplies the numbers where they exist.
Foundational items land before the things that need them, and something defensible ships within the first quarter. A roadmap where nothing completes for nine months is a roadmap that gets cancelled in month seven.
Who owns each automated decision, what gets logged, how a change is reviewed and rolled back. A week of conversations at the start, against a genuinely difficult retrofit later. Covered fully under AI governance and compliance.
Four phases. Most organisations we meet want to start at Phase 2 and are actually at Phase 0, which is a solvable problem if it is named early.
Measure one process properly, get one data extract working reliably, and name who owns an automated decision. None of this is AI, and skipping it is the single most reliable predictor of a stalled programme.
Frequently this phase produces enough value on its own to fund the next, because measurement usually finds a deletable step.
Typical duration
Four to eight weeks
Exit when
You can measure a process and reach its data on demand
Pick the constraint that bites hardest. The recommendation is deliberately narrow, because a first project that is broad is a first project that gets argued about.
Start with
Scattered data is not a reason to wait, it is a reason to narrow. Connect the two systems that matter most for one decision, prove the extract runs unattended, then build something that uses it.
Sequence: integration services first, then predictive analytics.
Compare the plan most AI projects start with against how the effort distributes in the ones that reach production.
This is the shape of almost every AI plan we are asked to review. It is not unreasonable on its face, and it is wrong in a specific way that only becomes visible in month three.
Four patterns that recur by sector. Profiles are anonymised.
Documents and history are usually in good shape, and the blocker is that no single person can approve a change to how work gets done. The first project has to be one where a partner will personally own the output.
Consulting providersProcesses are well understood and often already documented to a standard. The constraint is an ERP module with no interface, which usually makes integration or a robot bridge the first line in the plan rather than a model.
Manufacturing engagementsAccountability structures already exist, which is an advantage. The assessment usually recommends an internal-facing first project so the control framework can be exercised before anything reaches a customer.
Banking and insuranceSmall teams absorbing large repetitive volumes, with limited platform capacity. The right answer is almost always the narrowest possible project on hosted infrastructure, and the assessment says so rather than proposing a programme.
Non-profit and NGOAll three are sold as AI consulting. They differ in who writes the recommendation and what happens if it is wrong.
| Criterion | Strategy-only firm | Vendor-aligned advisor | Consultant who also delivers |
|---|---|---|---|
| Knows what the build costs | Estimates from benchmarks | Estimates from their product | From having built it |
| Incentive on the recommendation | Neutral, but no accountability | Points at their platform | Points at a build, which we name openly |
| Carries the risk if wrong | No | Partly, through the licence | Yes, if we deliver it |
| Output | A strategy document | An implementation plan for one product | A ranked backlog and a sequenced roadmap |
| Best when | The question is organisational | You have already chosen the platform | You need to know what is actually feasible |
The honest caveat about our own column is in row two: we build things, so we have an interest in recommending a build. The mitigation is that we publish the rejects alongside the shortlist and hand you a roadmap you can take elsewhere. Broader technology strategy sits with our IT consulting and advisory practice.
The delivery lines in the AI and automation practice that assessments most often point at.
The measurement work that turns a readiness score into a specific, defensible first project.
Where the governance dimension of your score turns into an actual control framework.
The engineering layer for anything built on language models, including how it gets evaluated.
For roadmaps where the value is a better forecast rather than a faster process.
Where the assessment lands on the revenue side rather than in operations.
The wider programme framing, for when AI is one workstream among several.
Where the roadmap depends on a platform or cloud decision, our cloud architecture team joins the assessment. To start, tell us the business area or read the help centre.
The ten that come up in almost every first conversation.
Thirty minutes on what your weakest dimension means for a first project. No obligation, and no slide deck. We reply in under 3 minutes.
