Most AI readiness assessments produce a score and a slide. The score is reassuring, the slide gets presented, and the program proceeds exactly as it would have without the exercise.
A readiness assessment earns its place when it changes a decision. That happens when it is scoped to a specific initiative rather than the whole enterprise, when it produces a weak result the organization is willing to act on, and when each weak dimension names the work required rather than a maturity label.
The twenty questions below are structured for that. They cover five dimensions, and any dimension scoring low is a blocker for the initiative under review, regardless of how the others score. Averaging across dimensions is what turns an assessment into a slide.
Key takeaways
- Readiness is a property of a specific initiative, not of an organization.
- Five dimensions matter: business framing, process visibility, data and technical foundation, governance and risk, and adoption and ownership.
- The lowest dimension governs. A strong average with one weak dimension is not readiness.
- Process visibility is the dimension most often assumed and least often tested.
- A weak result is the useful outcome, since it names work that would otherwise surface during delivery.
- Reassess when the initiative changes scope, not on a calendar.
How to use the assessment
Pick one initiative. Not the AI program, not the function, one initiative with a defined scope and an intended outcome.
Answer each question with yes, partial, or no. Yes means the answer is documented and someone could produce it today. Partial means someone could probably find out. No means nobody knows.
Count the results per dimension. A dimension with two or more answers that are not yes is a blocker. Do not average across dimensions, because the point of the exercise is finding the one that will stop the initiative rather than producing a number that looks acceptable.
Dimension 1: Business framing
Whether the initiative is tied to a decision the business is already trying to make.
- Can you name the business metric this initiative should move, and its current value?
- Can you name who will make a different decision because of this, and what decision?
- Is there an executive sponsor accountable for the outcome rather than for the delivery?
- Would this initiative still matter if the technology worked perfectly and nothing else changed?
Question 4 is the one that separates initiatives from experiments. If a perfectly functioning system would leave the operation unchanged because a downstream approval, policy or handoff is the real constraint, the initiative is aimed at the wrong step.
If this dimension is weak: the work is a framing exercise with the business owner, not a technical one. Establish the metric and its baseline before anything else.
Dimension 2: Process visibility
Whether anyone knows what the affected process actually does.
- What proportion of volume in this process follows the documented path?
- What are the exception types, and roughly how often does each occur?
- Where does the process vary by market, team, or customer segment?
- Which approvals in this process happen outside any system of record?
This is the dimension most often marked yes without testing. The test is specific: ask two people from different teams to describe a typical case, then compare their descriptions to each other and to the documentation. Divergence between the three is the answer.
Question 5 is the single most informative number in the assessment and the one least often available. An initiative scoped without it is scoped against an assumption about coverage.
If this dimension is weak: the work is process discovery with the people who handle exceptions, not a documentation review. Everything downstream depends on it, so this is the dimension to fix first when several are weak.
Dimension 3: Data and technical foundation
Whether the technical path is known rather than assumed.
- Do you know which data this initiative needs, where it lives, and who owns access?
- Has anyone verified the quality and completeness of that data, rather than assumed it?
- Is the integration path into the systems where work happens defined?
- Do you know what the system does when its inputs are missing or malformed?
Question 10 fails more often than teams expect. Data readiness is frequently treated as a footnote after the roadmap is approved, and it is a common reason a convincing prototype does not become a production system people trust.
If this dimension is weak: the work is a data assessment scoped to this initiative, covering availability, quality, permissions, sensitivity and update frequency.
Dimension 4: Governance and risk
Whether the boundaries are decided rather than inherited.
- Have you classified this initiative by risk tier, and does the tier determine the review path?
- Is there a defined list of actions the system may take without a person?
- Are the escalation conditions specific enough to implement?
- Is there a named owner for the boundary between permitted and escalated actions?
Question 14 is where governance most often turns out to be implicit. If the system can take an action because the integration supports it, the boundary was set by an engineering convenience rather than a risk decision.
If this dimension is weak: the work is a boundary-setting exercise scoring each decision in the initiative on cost of error and reversibility, with a named owner attached.
Dimension 5: Adoption and ownership
Whether the workflow will change.
- Do you know which roles change and how, at the level of specific tasks?
- Is there a business owner accountable for adoption after launch, distinct from the build owner?
- Do managers have a defined role in reinforcing the new way of working?
- Have the people who do this work seen the proposed change and had a chance to object?
Question 18 is the most predictive question in the assessment. A build owner is accountable for the system working. A business owner is accountable for the operation improving. Initiatives with only the first produce working systems and unchanged operations.
If this dimension is weak: the work is assigning ownership and running the change impact analysis before the build starts, not after.
Readiness reading
What each weak dimension means
| Dimension | If weak, the initiative will | Fix first |
|---|---|---|
| Business framing | Produce output nobody uses to decide | Establish the metric and the decision |
| Process visibility | Be scoped to a process that does not exist | Discovery with exception handlers |
| Data and technical | Stall in delivery on unverified assumptions | Scoped data assessment |
| Governance and risk | Inherit its boundary from the architecture | Score decisions on cost and reversibility |
| Adoption and ownership | Launch and change nothing | Name the business owner |
The lowest dimension governs. A high average with one weak dimension is not readiness, since the weak one is where the initiative will stop.
Interpreting the result
| Pattern | What it means | What to do |
|---|---|---|
| All five strong | The initiative is scoped and owned | Proceed, with a defined stop condition |
| One weak, four strong | A specific, addressable gap | Fix the one dimension, then reassess |
| Process visibility weak, others strong | The most common enterprise pattern | Run discovery before anything else |
| Business framing weak | The initiative is a technology exercise | Return to the sponsor before spending |
| Three or more weak | The initiative is premature | Reduce scope to something assessable |
The third row deserves emphasis because it is the most frequent outcome in large organizations. Data foundations, governance and executive sponsorship are often in reasonable shape, and the process the initiative targets has never been described from evidence. That combination produces confident programs aimed at the documented version of the work.
What this assessment does not cover
Worth being explicit, because readiness assessments tend to expand until they are transformation diagnostics.
This assesses whether one initiative is ready to build. It does not assess organizational AI maturity across functions, model selection, vendor comparison, or portfolio prioritization. Those are separate exercises with different scopes, and running them together produces a document too large to act on.
The output here is a decision about one initiative: proceed, fix a specific gap, or reduce scope.
Where Horizon fits
Horizon is an AI-powered continuous discovery platform. It addresses dimension 2 directly, and dimension 5 partially.
Discovery Cycles run AI-led interviews across the roles that operate a process, asynchronously and at census scale, adapting to each role and following up on gaps. The Process Library structures the result into navigable documentation covering which exceptions recur, who owns each decision, which approvals happen outside any system, and how the process varies by market. The Insights Dashboard ranks findings by impact and effort with traceability to source, and the Initiatives Dashboard converts priorities into business cases with owners, which is the artifact dimension 5 asks for.
Trafilea, an eCommerce group with more than 400 employees working fully remote across several countries, is a clear example of a dimension 2 failure that would have gone undetected. Its process documentation had not been updated in more than two years, teams ran on tribal knowledge with no standardized source of truth, status was duplicated across two tools at 80 to 100 requests per month, and the creator pipeline ran across seven or more tools with parallel updates and unclear ownership.
Any assessment of that organization would have shown reasonable technical foundations and executive sponsorship. Question 5 would have had no answer.
Horizon ran 43 asynchronous interviews across two tribes in two weeks without blocking a calendar. It produced 10 or more actionable findings, quantified 218 hours per month of operational waste in duplicate status tracking alone, identified 50 to 90% automation potential across key workflows, and generated standardized process documentation. It eliminated more than 129 hours of discovery work against traditional process mapping, and returned 310% day-one ROI at a 4.1x return multiple. The internal estimate for the manual equivalent was about a year against four weeks.
That is one engagement under specific conditions rather than a projection for any organization. What it illustrates is that dimension 2 can be answered in weeks, which makes it a practical prerequisite rather than a reason to defer the initiative.
Reassessment triggers
Do not reassess on a calendar. Reassess when one of these happens:
- The initiative changes scope or moves to a new function
- A system in the affected workflow is replaced or upgraded
- A policy or regulatory requirement in scope changes
- The team operating the process reorganizes
- The business owner changes
- An incident reveals a case the scope did not anticipate
FAQ
What is an AI readiness assessment?
A structured evaluation of whether an organization can successfully deliver and adopt a specific AI initiative. A useful one covers business framing, process visibility, data and technical foundation, governance and risk, and adoption and ownership, and it produces a decision about that initiative rather than a maturity score.
How do you know if your company is ready for AI?
Readiness is not an organizational property. The same company can be fully ready for one initiative and not ready for another in a different function. Assess a specific initiative with a defined scope and an intended outcome, and treat the weakest dimension as the governing result.
What is the most common AI readiness gap?
Process visibility. Data foundations, governance and executive sponsorship are often in reasonable shape in large organizations, while nobody can say what proportion of volume in the target process follows the documented path. That gap produces initiatives scoped to a version of the work that no longer exists.
Should you average readiness scores across dimensions?
No. Averaging hides the dimension that will stop the initiative. If governance scores well and process visibility scores poorly, the average suggests moderate readiness and the initiative will fail on the second. The lowest dimension is the result.
What should you do if the assessment comes back weak?
Treat it as the useful outcome. Each weak dimension names specific work: a framing conversation with the sponsor, a discovery cycle with the people handling exceptions, a scoped data assessment, a boundary-setting exercise, or an ownership assignment. Fix the weakest dimension, then reassess that initiative rather than the whole program.
A score that changes nothing was not worth running
The value of a readiness assessment sits entirely in whether the organization is willing to act on a weak result. An assessment run to confirm a decision already made produces a document and a delay.
Scope it to one initiative, let the lowest dimension govern, and treat every weak answer as work that would otherwise have surfaced halfway through delivery.
See it. Fix it. Own it.