- 01
Score workloads, not the enterprise — maturity levels do not fund anything
- 02
Data reachability and write paths predict delivery better than strategy maturity
- 03
Collect artefacts and permission traces instead of survey responses
Six dimensions that actually predict delivery
Data accessibility and permission model; system-of-record write paths; workload economics; talent and ownership; governance, risk and evaluation capability; and platform and cost controls. In our assessments, the first two explain more variance in delivery success than every other dimension combined — an organisation with excellent strategy and inaccessible data ships nothing.
Collect evidence, not opinions
Survey-based readiness scoring measures confidence, not readiness. Instead pull artefacts: a real permission trace for a retrieval query, the API surface and rate limits of the target system of record, three months of transaction volumes for the candidate workload, the current change-approval path for anything writing to production data. Evidence changes the score, often downward, and always usefully.
Scoring that leads to a decision
Score each candidate workload, not the enterprise. For each: is the data reachable with correct permissions today, is there a write path, is there an owner accountable for the metric, can you write an evaluation set. Four yeses means it ships this quarter. Three means it ships after one named remediation. Two or fewer means it is a roadmap item, not a pilot.
The remediation backlog is the real output
A readiness assessment should end with an ordered remediation backlog with owners and dates — knowledge restructuring, entitlement changes, API work, data quality fixes — not a maturity level. The backlog is what makes the next three workloads cheaper, and it is the asset most assessments fail to produce.
From assessment to funded plan in six weeks
Weeks one and two: evidence collection and workload inventory. Weeks three and four: economics and scoring, plus a thin proof against the highest-scoring workload to test the assumptions. Weeks five and six: operating model, remediation backlog and business case. The proof matters — a plan that has never touched your real data is a hypothesis.
Six dimensions worth assessing
Readiness assessments proliferate because they are easy to sell and hard to act on. A useful one scores six dimensions with evidence rather than opinion. Data readiness: can a service retrieve the truth in real time under entitlement. Integration readiness: can systems of record be written to safely and reversibly. Operating model: who can approve a production change and how long does it take. Talent: is there a platform team, or only strategists and vendors. Governance: are risk tiers and evidence requirements published. Financial: is AI spend attributable to workflows and owners. Each dimension scores on observable artefacts — a working API call, a published policy, a named owner — not on a self-rated maturity slider.
Scoring with evidence, not sentiment
For every question, define what a level-one and level-five answer look like as artefacts. Level one for data readiness might be 'extracts are produced weekly on request'; level five is 'entitled, audited, sub-second API access exists in production'. Collect the evidence by demonstration during the assessment, not by survey. The scoring difference between self-reported and demonstrated readiness is consistently large, and the gap itself is the most useful finding you will produce.
Turning the score into a sequenced plan
Scores are only useful if they change the roadmap. Map each low-scoring dimension to the specific workflows it blocks, then decide whether to remediate the dimension or select workflows that route around it. In practice the fastest programs do both: they pick a first workflow that avoids the weakest dimension entirely, while funding remediation of that dimension in parallel so the second and third workflows are unblocked. Programs that insist on remediating everything before shipping anything lose their sponsor before the platform is ready.
Common failure patterns the assessment reveals
Four patterns recur. The pilot graveyard: many proofs of concept, no production path, because nobody owns the release process. The data mirage: a data lake with no entitled real-time access, so agents cannot see the truth. The governance vacuum or its opposite, the governance dead-end where every change needs the same committee. And the ownerless capability: a platform team building infrastructure no business owner has committed to using. Naming the pattern is usually more valuable than the numeric score.
Re-assessing on a cadence
Readiness is a moving target. Re-score twice a year against the same evidence definitions, publish the trend, and tie remediation items to named owners with dates. The value compounds because the assessment becomes a shared language for prioritising unglamorous platform work that would otherwise lose every funding argument to the next visible pilot.
Running the assessment without theatre
Keep the assessment small and evidence-led: a working session per dimension with the people who actually operate the systems, a demonstration rather than a description wherever possible, and a written finding with the artefact attached. Avoid enterprise-wide surveys, which reliably produce optimistic self-assessment and consume more calendar time than the analysis deserves. Two to four weeks is sufficient for most enterprises; anything longer usually indicates the exercise has become a consensus-building programme rather than a diagnostic.
Data readiness in practical terms
Data readiness is not about volume; it is about entitled, timely, accurate access to the specific facts a workflow needs. Test it concretely: can a service retrieve this customer's current status in under a second, under the caller's entitlements, with an audit record. Can it write a change back safely and reversibly. Is there a single authoritative source for this fact or three that disagree. These questions produce actionable findings; maturity models about data strategy generally do not.
Security, privacy and legal readiness
Assess whether your existing controls extend to AI workloads: identity and entitlement propagation into agent tool calls, data classification applied to retrieval corpora, retention and deletion covering derived artefacts such as transcripts and embeddings, cross-border processing positions, third-party terms with model providers, and incident processes that recognise AI-specific failure modes. Most enterprises find the framework exists and the coverage does not, which is a fixable gap if identified before the first deployment rather than during its review.
Talent and delivery readiness
Count the people who can actually build and operate: platform and integration engineers, evaluation specialists, conversation or workflow designers, and an operations owner able to take on-call. Assess whether release processes, environments and observability exist for AI workloads specifically. A high strategy score with no delivery capacity is the most common readiness profile and the most misleading, because it produces roadmaps that nothing can execute.
From assessment to funded plan
Close the assessment with three artefacts: a prioritised remediation list with named owners and dates, a first workflow selected to route around the weakest dimension, and a funding request that separates platform remediation from workflow delivery. Present the failure pattern rather than the score to executives — 'we have a pilot graveyard because no one owns release authority' lands and drives action in a way that a maturity number never does.
Worked example of an assessment finding
Consider a typical enterprise result. Data readiness scores low not because data is scarce but because access is batch-oriented: the customer master is authoritative, yet the only available interface produces a nightly extract, so no conversational workflow can confirm current status. Integration readiness scores mid: read APIs exist for three of the five relevant systems, write paths exist for one, and none propagate the caller's entitlements. Operating model scores low: four prototypes have been built, none released, because no one can name who signs off a production change. Talent scores mid: strong data science, no platform engineering and no evaluation capability. Governance scores low: a policy exists, tiers do not, so every use case queues behind the same committee. Financial scores low: AI spend sits in a single cost centre with no workflow attribution. The finding is not a number; it is a sentence — this enterprise has a pilot graveyard caused by absent release authority, sitting on top of batch-only data access. The plan that follows writes itself: publish release authority and risk tiers within a month, select a first workflow that needs no real-time customer data such as an internal knowledge assistant, fund an API façade over the customer master as the platform investment that unblocks everything else, hire or contract two platform engineers and one evaluation specialist, and instrument cost attribution before the second workflow ships. Six months later the re-assessment measures whether those specific artefacts exist, not whether stakeholders feel more ready.
Running the assessment without turning it into a project
The assessment should take three to four weeks, not a quarter. Week one: interview twelve to fifteen people across business, data, engineering, risk and finance, using the same question set so answers are comparable. Week two: verify claims against artefacts — call the APIs, read the policy, look at the pipeline, check whether the inventory exists — because stated readiness and demonstrated readiness diverge most in exactly the dimensions that matter. Week three: score, identify the binding constraint rather than listing every gap, and draft the sequenced plan with named owners and dated artefacts. Week four: socialise, adjust for what the organisation will actually fund, and publish. Keep the output to a short document plus a one-page scorecard, and schedule the re-assessment for six months out with the same instrument so progress is measurable rather than narrated. Assessments that expand into discovery programmes lose the momentum they were commissioned to create.
- Score workloads, not the enterprise — maturity levels do not fund anything
- Data reachability and write paths predict delivery better than strategy maturity
- Collect artefacts and permission traces instead of survey responses
- The ordered remediation backlog is the assessment's most valuable output
- Score data, integration, operating model, talent, governance and financial readiness against demonstrated artefacts.
- Define level-one and level-five answers as observable evidence, then collect it by demonstration, not survey.
- Route the first workflow around your weakest dimension while funding its remediation in parallel.
- Name the failure pattern — pilot graveyard, data mirage, governance dead-end, ownerless capability — not just the score.
Questions leaders ask us
- What is an AI readiness assessment?
- A structured evaluation of whether an enterprise can actually deliver specific AI workloads — covering data accessibility and permissions, system-of-record write paths, workload economics, ownership, governance and evaluation capability, and platform cost controls.
- How long should an AI readiness assessment take?
- Four to six weeks. Two weeks of evidence collection, two weeks of scoring and a thin proof against real data, and two weeks to produce the operating model, remediation backlog and business case.
- What does a good readiness assessment produce?
- A per-workload shipping verdict for the next two quarters and an ordered remediation backlog with named owners and dates — not a maturity score or a radar chart.
- What does an AI readiness assessment measure?
- Data access, integration safety, operating model and release authority, platform talent, published governance tiers, and whether AI spend is attributable to workflows and owners.
- How long should an assessment take?
- Two to four weeks for an enterprise scope. Longer assessments usually indicate the exercise has drifted from evidence collection into stakeholder consensus building.
- Do we need to fix everything before starting AI work?
- No. Select a first workflow that avoids your weakest dimension, ship it, and fund remediation in parallel so subsequent workflows are unblocked.
- How often should we re-assess?
- Twice a year against identical evidence definitions, with the trend published and remediation items owned and dated.