What a readiness assessment has to produce before anyone signs

The assessment is only useful if it can end in no

Most readiness assessments circulating inside large organisations cannot fail anyone. They return a maturity level, a coloured chart and a recommendation to proceed, which is the recommendation they would have returned for almost any input. If you are being asked to approve something on the strength of one, the first question to ask is what result would have stopped the project. If nobody can answer that, the assessment was a formality with arithmetic attached.

A useful one produces four artefacts, and they are documents rather than scores. A shortlist of candidate processes with measured volume and handling time next to each. A profile of the organisation against named dimensions, with the evidence that produced each score written beside it. A named owner who can change how the work is done, not only approve the budget for changing it. And a baseline of whatever number the project claims it will move, recorded before anything is built.

The total is the least valuable output. What people actually reread is the evidence column, because that is what someone opens when the project meets the gap the assessment already named.

• A shortlist of candidate processes with volume and handling time measured rather than remembered
• A score per dimension with the evidence that produced it recorded alongside
• A named owner with authority over the process itself, not only over spending
• A baseline of the number the project says it will improve, taken before the build
• An explicit list of what was not assessed, so nobody assumes coverage that does not exist

Six dimensions worth scoring

These six predict whether a build survives contact with the organisation. Everything else people put on readiness scorecards, model strategy, tooling preference, cloud posture, is downstream of them and easier to change.

Score each on evidence rather than opinion, which in practice means asking for the artefact instead of the answer. Process documentation is not a yes because someone believes a document exists. Ask to see it, then ask the person who does the work whether it still describes what they do.

Data accessibility is not a yes because the vendor claims an API. Ask for the documentation and for a credential that can read one record. The gap between what an organisation believes about itself and what it can demonstrate in an afternoon is where most of the project risk lives.

Weight them unevenly and publish the weights. Process documentation and integration surface move build cost more than change appetite does, and a scorecard where every dimension counts the same is one nobody thought about. Showing the weights lets the people being scored argue with them, which is a more useful conversation than an argument about a total.

• Process documentation. Is there a current written description of how the work is actually done, including the exceptions, or does it live in the heads of two people who have been here longest.
• Data accessibility. Can a system read the data it needs without someone exporting a spreadsheet, and is there a documented way to write back.
• Executive sponsorship. Is there someone senior enough to settle a scope disagreement between two departments, and have they given the project time in their own calendar rather than their approval by email.
• Measurement baseline. Does a number exist today for the thing you intend to improve, recorded rather than estimated, and does anyone already look at it weekly.
• Change appetite. Have the people who will use this asked for it, tolerated it, or resisted the last three things introduced to them.
• Integration surface. How many systems does the process touch, how many of those have a supported interface, and how many are versions old enough that upgrading them is its own project.

The gap between what an organisation believes about itself and what it can demonstrate in an afternoon is where the project risk lives.

Two answers that override the total

Two of these are not weaknesses to be outweighed by strength elsewhere. They are conditions, and a high score alongside either one is a misleading number.

The first is a process that exists only in people's heads. An automation built against an undocumented process has nothing to be accurate against, so it will be confidently wrong in ways nobody notices for months, and the errors will be discovered by a customer rather than by a test. Writing the process down is unglamorous work that no vendor wants to sell, and it decides whether everything after it holds.

The second is a project with no internal owner. Not a sponsor, an owner: the person whose job it is to settle the argument when finance and operations disagree about what the workflow should do on the fifteenth of the month. A project without one does not survive its first scope disagreement. It stalls, then gets rescoped by whoever is loudest, then quietly becomes a pilot that nobody cancelled.

If either applies, the honest recommendation is to spend a month closing it before assessing anything else. That recommendation is cheap to give and expensive to ignore. Wobble maintains a free six-question version of this at the AI Readiness Assessment, which scores in the browser, stores nothing, and applies the same two overrides.

How to run it without contaminating the result

Self-assessment inside a large organisation returns optimism, because the people filling in the form are usually the people whose department is being judged. The correction is not to distrust them. It is to change who answers which question. Ask leadership about sponsorship and appetite for change. Ask the people who actually perform the work about how the process really runs, including the workaround they use every Friday that appears in no document.

Collect artefacts as you go and attach them to the score. A screenshot of the queue. The actual spreadsheet, not a description of it. The API documentation page. A count taken over a fortnight rather than a number recalled from memory. Where two people give contradictory answers, do not average them. Go and watch the process once, because the disagreement usually means the process has two versions and only one of them is written down.

Timebox it. An assessment that takes a quarter has become a project of its own, and by the time it reports, much of what it measured has changed. Two to four weeks is enough for a defined scope, and if the scope is the whole organisation, split it rather than extending the clock.

• Ask leadership about sponsorship, and the people doing the work about the process
• Attach an artefact to every score, so a reader can check it later without rerunning the interview
• Resolve contradictions by observation rather than by averaging two opinions
• Count things over a fortnight instead of accepting a remembered figure
• Write down what you did not look at, in the same document

What the engagement looks like

A readiness assessment is a scoped project with an end date, and it should be. You are buying a decision and the evidence behind it, not a subscription. It finishes with a document, a walkthrough with the people who have to act on it, and a recommendation that is allowed to say not yet.

What moves the size of it is not the number of questions. It is how many processes and departments are in scope, since assessing one workflow in one team is a different job from mapping an intake process that crosses four; whether documentation exists or has to be created during the assessment, which is real work and is frequently most of it; and how quickly you can get access to people and systems, because the assessment stalls on calendars and credentials far more often than on analysis.

Nobody can price this responsibly without knowing those three things, so ask for the list of what will be examined. That list is the estimate. What follows is a separate decision: if the answer is proceed, the build is scoped from the shortlist, and if the answer is not yet, there is documentation and measurement work first that is worth doing whether or not the same firm does it.

• How many processes and departments are in scope
• Whether current documentation exists or has to be produced as part of the work
• How fast access to systems and to the people doing the work can be arranged
• Whether a baseline measurement exists already, or has to be built before anything can be compared

Where a readiness score tells you nothing useful

It assumes you already have candidate work in mind. If the real question is which part of the business to examine rather than whether a known process can be automated, this instrument answers the wrong question. The useful exercise there is measuring where time actually goes for a fortnight, which is duller and more informative.

It also assumes the process deserves to exist. Some of the most valuable findings in this kind of work are that a weekly report nobody reads has been produced for four years, or that an approval step was added after an incident in a system that has since been replaced. Deleting a task beats automating it, and no scorecard will surface those, because every dimension on it assumes the work is worth keeping.

It also cannot tell you whether the technology is capable of the task. Readiness is a question about the organisation. Feasibility is answered by looking at the actual inputs the process receives, and a business can be entirely ready for something that does not work yet.

Who conducts this, what you take away, and when to run it yourself

An assessment scored by the company that wants the build is worth exactly as much as its willingness to fail you. Wobble's answer to that is to publish the scoring and make the output portable rather than to claim a neutrality it does not have. You own the completed assessment, the evidence behind each score and the roadmap, in a document you can hand to a competitor and get a comparable quote from.

The scoring stops short of the decision. A total is an input, and it waits for a person in your business who can commit budget and staff time, because a readiness score presented to somebody without authority is a meeting rather than a decision. Where the assessment surfaces a legal, regulatory or employment consequence, that goes to your own advisers instead of being resolved inside a score.

Haad, the co-founder who owns growth and client solutions, runs the interviews, and Moiz Khan reviews whatever the assessment says is buildable. Wobble is based in Karachi and works across 25 engagements in six countries, which is the sample these questions were derived from rather than a framework bought in.

Running it in-house is entirely possible, and this page exists partly so that you can. The dimensions, the evidence required behind each score, and the two answers that override the total are all published here. An operations manager willing to be unflattering about their own department can run this with your own team in a fortnight and never speak to a supplier.

Common questions

What should an enterprise AI readiness assessment actually produce?

Four things. A shortlist of candidate processes with measured volume and handling time, a score against named dimensions with the supporting evidence recorded next to each, a named internal owner with authority over the process, and a baseline measurement of the number the project claims it will move.

Which dimensions are worth scoring?

Process documentation, data accessibility, executive sponsorship, measurement baseline, change appetite and integration surface. Those six predict whether a build survives inside the organisation. Model choice, tooling and cloud posture are downstream of them and much easier to change later.

Can a high readiness score still be wrong?

Yes, in two situations. If the process is undocumented, the build has nothing to be accurate against and will be wrong quietly. If nobody inside the business owns the project, it will not survive its first scope disagreement. Both override the total rather than being averaged into it.

Who should answer the assessment questions?

Split it. Leadership answers on sponsorship and appetite for change. The people who perform the work answer on how the process actually runs, including the exceptions and workarounds. Asking one group everything is how an assessment ends up describing the organisation as it is presented rather than as it operates.

How long should an assessment take?

Two to four weeks for a defined scope. Longer than that and it has become a project of its own, and the conditions it measured start changing before it reports. If the scope is genuinely the whole organisation, split it into rounds rather than extending the timeline.

Is there a free version?

Yes. The AI Readiness Assessment on this site is six questions, scores in your browser, stores nothing, publishes every weight and threshold, and applies the same two overriding conditions. It is a filter rather than a diagnosis, and it is enough to decide whether a longer assessment is worth commissioning.