The point of an assessment is not the report. It is the decisions the report lets you make, and the fact that you can explain them afterwards.
This is what the weeks after one actually look like, what you are holding at the end, and the three ways organizations most often waste the work they have just paid for.
The findings presentation, and the part that stings
Everything begins with presenting findings to the people who can act on them. That means leadership as well as technology staff, because most of the significant findings are organizational rather than technical.
Expect two categories. There will be things you knew and now have evidence for, which are useful mainly because evidence moves budget in a way that opinion does not. And there will be at least one finding you did not expect, which in our experience is usually one of three: the volume of AI already in use across the organization, the fact that a system everybody assumed could be integrated cannot be, or that nobody owns a data set that several departments depend on.
That second category is where the value is, and it is uncomfortable in the room. A good assessment is specific about it rather than diplomatic, because a finding softened into vagueness cannot be acted on. If a report tells you only what you already believed, ask what it examined.
Agreeing what you disagree with
The step organizations skip, and the one that determines whether anything happens next.
Go through the findings and mark each one accepted, disputed, or accepted with a different priority. Disputes are legitimate and often correct: an assessor sees a snapshot, and you know that a system is being replaced in six months or that a policy gap is already being addressed. Record the disagreement and the reason rather than arguing it away, because the record is what makes the eventual decision defensible.
Do this within a fortnight. Reports lose authority quickly, and a set of findings nobody formally responded to becomes a document that gets cited selectively by whoever wants to cite it.
Sequencing: dependencies first, then value
The prioritized use cases in a report are a starting position, not a schedule. Turning them into one means separating three different things.
Foundation work is what other things depend on: access review, data ownership, a governance position, an integration that several candidates need. It is unglamorous, it produces nothing a council can see, and skipping it is the most expensive decision available. It goes first because everything else waits on it.
Quick wins are candidates that are genuinely independent of the foundation work. Some exist in most organizations and none exist in some, and an assessment that promises them where they are absent has told you something comfortable rather than true. Where they exist, run one early: the value is as much in the organization learning what these tools do badly as in the outcome.
The substantial candidates follow, in an order determined by which foundation work has completed rather than by which is most attractive.
The roadmap as a document
What you should be holding is a sequence, not a wish list: phases built around dependencies rather than quarters, a budget for each phase including what it costs to run afterwards, a named owner per phase, and decision gates that can genuinely stop the next phase.
The gates are the part that gets diluted. A gate that has never stopped anything is a status meeting. Write the criterion in advance, in numbers where you can, and agree explicitly what happens if it is not met, because the moment to decide that is before anyone is invested in the answer.
How to construct one, in detail, is in building an AI technology roadmap, which covers dependency mapping, phasing and budgeting properly. If the strategy underneath it is not settled either, how to build an AI strategy comes first.
Governance before the first tool, not after
If governance came out weak, and it usually does, it belongs in the first phase regardless of how it scored relative to everything else.
The reason is sequencing rather than severity. A governance position is what tells you how to evaluate the tools you are about to look at, so establishing it afterwards means re-examining decisions you have already made. The proportionate version for a public body is in an AI governance framework for public-sector organizations, and the first four weeks of it are genuinely achievable alongside other work.
Proof of concept, pilot, production
Three distinct things that organizations run together and then cannot tell whether they succeeded.
A proof of concept answers one technical question: can this be done at all with our data, in our environment. It is short, it is thrown away, and its output is an answer rather than a system. Judge it on whether the question got answered.
A pilot answers a different question: does this help the people doing the work, at a scale small enough to stop. It needs real users, real work, a defined period, and criteria agreed before it starts. The commonest failure is the pilot with no end date, which becomes production without anyone deciding it should.
Production is a different engineering exercise: integration, identity, monitoring, support, a named owner, and a plan for what happens when the supplier changes the model. Something that worked in a pilot is not thereby ready, and the gap between the two is where most of the cost lives.
Decide in advance what you would do if the pilot succeeds but the running cost is higher than modelled. That is the most common awkward outcome and the one nobody plans for.
What the work actually costs
We do not publish a price for an assessment, because the honest range is wide enough that a published figure would mislead more readers than it helped. What drives it is straightforward, though, and you can estimate your own position against it.
The main drivers are the number of systems in scope, the number of departments or sites involved, how many stakeholders need interviewing, whether the data question can be answered from documentation or requires investigation, and whether governance is being assessed or written. An organization with four systems and one site is a different exercise from a district with twelve schools and eight platforms, and no fixed figure describes both.
The implementation cost that follows is a separate question and the assessment should give you a range for it. Be wary of any estimate that omits the running cost at realistic volumes, which is frequently larger than the build.
Where cooperative purchasing is the route, AI readiness consulting for TIPS members sets out how that works and what is determined by whom.
Three ways organizations waste an assessment
Treating it as a procurement document. A report that gets forwarded to a supplier as a requirements list produces proposals against findings rather than against outcomes. Decide what you are trying to achieve first; the findings tell you what stands in the way, not what to buy.
Doing the interesting recommendations and not the foundational ones. This is the most common failure and it is completely predictable, because the foundation work produces nothing visible. An organization that runs the pilot and skips the access review has bought a demonstration.
Letting it go stale. A readiness assessment describes a moment. Systems change, staff leave, suppliers add AI features to products you already own without asking. Findings older than a year should be re-checked before being acted on, and re-scoring against the same framework is cheap.
Measuring whether it worked
Re-score against the same seven dimensions after six or twelve months. Because the framework is stable, the comparison is meaningful, and improvement in the dimensions you invested in is the most direct evidence available that the money did something.
Track the operational number you agreed for each use case, separately. And keep the record of what you decided not to do and why, because a year later somebody will ask, and an organization that can answer that question is in a much stronger position than one that can only point at what it bought.
Where to start
If you have not assessed anything yet, the AI Readiness Self-Assessment scores you across the seven dimensions in about eight minutes and returns recommendations for the weakest. It is self-reported, which is its limitation and is stated on the results page.
To work through it more thoroughly with your own team, use the public-sector readiness checklist.
Where the findings need to be evidence rather than impression, the assessment itself examines your systems, records, policies and people, and produces the report and roadmap described above. Tell us where you are and we will tell you honestly whether you need one yet.