AI ROI Numbers That Don't Survive a Board Meeting

A board approves an AI program based on a payback period. Eighteen months later, the program is over budget, adoption is patchy, and the productivity gains the model promised are sitting in a pilot deck rather than the income statement. The numbers were not fraudulent. They were incomplete.

The accounting error hiding in plain sight

The Standish Group has tracked IT project outcomes since the mid-1990s. The original CHAOS survey found that only 16.2 percent of software projects finished on time and on budget. Cost overruns averaged between 178 and 214 percent of original estimates. For the largest projects, the success rate fell to 6 percent. These numbers predate generative AI by decades, but the structural failure they document is identical to what happens in AI programs today: organizations model build costs, treat scope as stable, and then run into integration complexity, user resistance, and governance requirements that were never in the budget.

The run costs come next. Advisory research on enterprise AI documents large gaps between vendor quotes and real three-year program costs, once you include refresh cycles, model retraining, compliance overhead, and eventual retirement. These costs do not appear on the day of deployment. They accumulate. By the time a board sees them, the original ROI model is a historical artifact.

When strong AI economics don't rescue a broken cost model

The counterargument worth taking seriously is this: AI economics research documents genuine task-level productivity gains and firm-level profit improvements. A well-run operator deploying AI across sales, operations, and customer support simultaneously generates enough aggregate uplift to absorb hidden costs that a single-function deployment cannot. Under this view, the measurement gap is a precision problem. The investment decision was right even if the model was wrong.

This argument works for the 6 percent. It does not work for the distribution.

Standish data shows that 94 percent of large projects are challenged or fail outright. The firms with strong operational discipline and multi-function AI deployment are the exception the counterargument selects for, not the population boards are actually approving programs from. A measurement model that works for the best-performing minority while systematically overstating returns for everyone else is a selection problem, not a rounding error.

The second failure is structural. AI economics research confirms that productivity gains only convert to realized ROI when workers change how they work. Change management investment drives that behavior change. It is "almost never" included as an explicit cost item or benefit attribution in ROI models. An operator claiming the aggregate uplift will materialize has not budgeted for the investment required to produce it. The projected return is structurally unreachable on the terms the model describes.

Three questions that close the gap

The fix is not a new framework. It is three questions asked in sequence, answered with numbers from your own operation.

What did you measure before AI? Not a vague description of the process. A number. Tickets resolved per agent per day. Contracts reviewed per lawyer per week. Orders processed per hour. If you did not measure it before deployment, you cannot claim a change after. Boards and lenders evaluating against capital budgeting norms need a baseline, not a narrative.

What changed? Same metric, same period length, same population of workers. If the baseline was tickets per agent per day, the post-deployment number is tickets per agent per day. Not a different metric selected because it moved more favorably.

How much did it cost? Build cost plus integration work plus training plus adoption support plus the first two years of run and refresh. Not the vendor quote. The full number. If change management spend is not in this figure, the ROI calculation will overstate returns by the amount required to produce the behavior change the benefit projection depends on.

These three questions do not require sophisticated measurement infrastructure. They require discipline about what gets counted before a program starts and what gets included when the bill arrives.

What a defensible business case actually looks like

An AI program whose ROI model answers all three questions will produce a smaller number than the vendor's slide deck suggested. That is the point. A smaller number built on a real baseline, a real outcome, and a full cost figure survives scrutiny. A larger number built on partial accounting does not, and the moment it fails under board or lender review, the credibility problem attaches to every AI program the organization runs afterward.

The productivity gains AI economics research documents are real. The question is whether your business case is built to capture them or built to claim them before the work of capturing them has been funded.