A Quickstart for Measuring the ROI of an AI & Data Readiness Assessment

Key Takeaways

• Skepticism about readiness audits is earned. Plenty of them end as a slide deck that never changes a budget line.
• Most of the return shows up in what you don't build. The pilot you killed, the data gap you fixed first, the project you moved up.
• An assessment is worth exactly the decisions it changes. If your roadmap after the readout matches the one you had before it, you paid for a confirmation.
• You can measure it with four steps and one formula. Write a decision log before kickoff, diff the roadmap at readout, price the changes at day 30, and check execution at day 90.
• Shelfware has tells. No owners, no dates, no data gaps, and a first pilot that still hasn't started.

Nobody gets promoted for the AI pilot they didn't run. That is the whole problem with buying a readiness assessment. The best thing it can do for you is stop a bad project before it starts, and a project that never happened doesn't show up on any dashboard.

So the skepticism makes sense. A CFO looks at a line item for "AI & data readiness assessment" and asks the fair question: what did we get for that? A report. A score. A roadmap. All of which feel like paper.

Meanwhile, AI projects are failing in public. CIO Dive's coverage of S&P Global Market Intelligence research found that 42% of companies scrapped most of their AI initiatives in 2025, up from 17% the year before. The average organization dropped 46% of its proofs of concept before they reached production.

I think the skepticism and the failure rate come from the same place. Most assessments don't get measured, so nobody can tell the good ones from the expensive formalities. This post is a quickstart for fixing that: a way to put a number on whether a readiness assessment paid for itself, using data you already have.

The Skepticism About Readiness Audits Is Earned

Let me say the uncomfortable part first. A lot of readiness assessments are bad.

They run six to ten weeks. They interview everyone. They produce a maturity score from one to five, a heat map, and a list of 40 use cases ranked by some blend of "impact" and "feasibility" that nobody can reproduce. Then the deck goes into a shared drive, and the company goes back to doing whatever it was going to do anyway.

The firm running it often isn't the firm that will build anything, so it optimizes for looking complete. Coverage over consequence.

The failure data points the same direction. Gartner expected at least 30% of generative AI projects to be abandoned after proof of concept by the end of 2025, and named the reasons: poor data quality, inadequate risk controls, escalating costs, or unclear business value. Every one of those is something an assessment is supposed to catch before the pilot starts. When projects keep dying for those reasons, it tells you most assessments aren't catching them.

Ask what the last one changed

If your company has run a readiness assessment before, pull it up. Find the roadmap. Then look at what you actually funded in the following two quarters. If those lists barely overlap, you already have your answer about that assessment, and a useful baseline for judging the next one.

Most of the Return Shows Up in What You Don't Build

So reframe the question. An assessment is worth exactly the decisions it changes.

If you walk in planning to fund five use cases and walk out funding the same five, in the same order, with the same budgets, the assessment confirmed your instincts. Confirmation has some value. It's usually not worth the fee.

The return shows up when something moves. There are four ways that happens:

• Avoided spend. A use case you were about to fund gets killed or delayed because the data behind it doesn't exist, isn't clean, or can't be accessed. The pilot budget you didn't burn is the clearest return an assessment can produce.
• Value pulled forward. A use case you'd ranked fourth turns out to be pilot-ready with existing data, so it moves to first. Every month earlier it ships is a month of savings you'd otherwise have waited for.
• Rework avoided. A data gap or permission problem gets fixed before the build starts. Fixing it mid-pilot usually means rebuilding pipelines and retesting, and sometimes it means starting over.
• Decision speed. The time between "we should do something with AI" and "this is funded, owned and scheduled" gets shorter. Hard to price, easy to track.

The first three go into the ROI math. The fourth you track on its own, because leadership cares about it even when it doesn't convert cleanly to dollars.

Count the projects that never started

This is the hard habit to build. When an assessment tells you not to do something, write it down, along with what you would have spent. A killed project leaves no trace in your systems, so if you don't record it on the day you decide, the return disappears from the books.

A Quickstart for Measuring Assessment ROI

The framework is four steps across roughly 90 days. It works whether you're evaluating an assessment you're about to buy or one you already ran.

Then the math:

Assessment ROI = (avoided spend + value pulled forward + rework avoided − assessment cost) ÷ assessment cost

A few notes on using it honestly.

Use your own numbers. Avoided spend comes from the pilot budget in your decision log. Don't take the figure from the assessor. Value pulled forward is your estimate of monthly savings times the months gained. If you can't estimate it, leave it at zero and say so.

Discount the soft stuff. Rework avoided is real, but it's an estimate of something that didn't happen. I'd count it only when the assessment named a specific gap (a missing field, a broken sync, an access problem) and your team fixed it before the build.

Run it twice. Do the math at day 30 with estimates. Redo it after the first pilot ships with real figures. The second number is the one that matters.

Write the decision log before anyone shows up

Step one is the step people skip, and it makes everything else possible. Without a written "before" picture, every recommendation looks obvious in hindsight and nobody can say what changed. It takes an hour. Date it. Don't edit it afterward.

Shelfware Has Tells

You usually know within a month whether an assessment is going to drive decisions. These are the signs I'd watch for.

• The roadmap has no owners. Initiatives listed by function ("Finance," "Operations") instead of by a named person who will be asked about it next quarter.
• Nothing got killed. Every use case you walked in with survived. Either your instincts were perfect, or nobody tested them against the data.
• No data gaps were named. Gartner's survey of 1,203 data management leaders found 63% of organizations don't have, or aren't sure they have, the right data management practices for AI. An assessment that finds no gaps probably didn't look.
• The scores can't be reproduced. If you ask why a use case scored a 4 on feasibility and the answer is a feeling, the ranking won't survive the first budget meeting.
• The first pilot hasn't started at day 90. This is the one that settles it. A roadmap nobody executes is worth zero, however good it reads.

Treat day 90 as the real deadline

Put the day-90 check on the calendar at kickoff, with the executive sponsor in the room. It changes how everyone behaves during the assessment. The assessor writes for execution. Your team pays attention to what they'll be asked to own.

The Assessor Should Be Able to Build What It Recommends

The biggest predictor of whether an assessment changes decisions, in my view, is whether the people writing it will be around when the decisions get tested.

When the assessor and the builder are different firms, the roadmap gets written for a reader who wasn't in the room. Context about why a data source is unreliable, or which stakeholder will block a workflow change, lives in someone's notes and doesn't survive the handoff.

That's why PressW runs assessments with the same engineers who build the systems they recommend. Our AI & Data Readiness Assessment audits data, systems, workflows and teams, scores each use case on value, feasibility and risk, models expected time and cost savings, and ends with a pilot-ready first initiative. The ROI modeling is built into the work, which makes step three of the quickstart a lot easier.

We've also done this from the investor side. For a capital firm evaluating a healthcare AI target, we applied our 5 Pillars of AI Competency framework and interviewed the target's technical team, and the resulting report flagged technical strengths and risks that contributed to the firm's investment decision. That's the bar I'd hold any assessment to. Did it change a decision?

Some of the Value Won't Fit in a Spreadsheet

I want to be honest about the limits here. The formula captures the money that moves. It misses a few things.

It misses the alignment that comes from sitting with the people who do the work and mapping how it actually gets done. Sometimes the most valuable output is a COO and a CFO agreeing, for the first time, on which problem matters most. It misses the confidence an investment committee gets from seeing a scored baseline instead of a hunch. And it misses the governance decisions that get made early instead of in a panic after something leaks.

I don't have a clean way to price those. I'm not sure anyone does. What I'd say is this: if the hard numbers in the formula come out negative, the soft benefits probably aren't enough to save it. If the hard numbers come out positive, the soft benefits are a bonus.

An Assessment Earns Its Fee One Decision at a Time

I believe a good readiness assessment is one of the cheapest insurance policies in an AI budget. Most of the failure data says AI projects die from problems that were knowable upfront. An assessment is supposed to know them.

But I also think buyers should stop taking that on faith. Write the decision log. Diff the roadmap. Price what changed. Check at day 90. If the assessment can't survive that, it wasn't worth the fee, and you'll know before you buy the next one.

I don't know exactly what the right price for an assessment is, or how long one should take. It depends on how much data you have and how messy it is. If you want to work through the decision log for your own company, or pressure-test one you already ran, Book a Discovery Call.

FAQ