Slide fourteen was green. It listed eleven artificial intelligence initiatives, four of them marked complete, three marked scaling, and a chart with a line climbing left to right that nobody in the room could tie to a single figure anywhere in the general ledger. The chief financial officer let the slide sit for a moment. Then she asked what it returned.
Nobody had it. What came back instead was adoption: seat counts, weekly active users, a satisfaction survey, and an hours-saved figure assembled by asking people to estimate their own saved hours. That was real work and some of it was genuinely useful, but not one line of it answered the question that had actually been asked, which was a question about money arriving somewhere a controller could count it. Adoption is not return.
Nobody failed. The program was well run: good engineers, a competent vendor, eighteen months of honest effort, and nobody in that room trying to fool anybody. The return was unanswerable for a duller reason, which is that nobody had written it down, before the money moved and before a single model was chosen, what the return was even supposed to be. That is not a finance failure. It is a requirements failure that took a year and a half to become visible.
Why don't most AI investments pay off?
Because most of them were never handed a definition of paying off. That reads like semantics right up until you try to audit one, at which point you find that the target was a sentence in a funding deck, the baseline was never captured, and the horizon moved quietly every time a quarter closed. Not semantics. It is the whole problem.
Read that phrase again. The expected return on investment. Not "a return" and not "no return", a distinction almost every retelling of this number flattens, and it matters, because three quarters of these initiatives missed an expectation, and an expectation is a thing somebody wrote down at some point in some room. So where was it written? Usually in the deck that won the funding. Almost never in the backlog that spent it.
The reflexive fixes are two, and both are expensive. Buy more tooling. Run more pilots, on the theory that the eleventh pilot is the one that converts and that the model scoring two points higher on last month's public benchmark is the missing ingredient in a program that has never once agreed on what success would look like. Wrong lever. Neither fix touches the input, and both enlarge the denominator you are trying to divide into.
One honest caveat before I go further, because I have watched this argument get oversold in rooms where it should have been made carefully. Talent gaps, unusable data and change management are all genuinely part of why programs stall, and anybody who tells you requirements are the only variable is selling something. They are simply the cheapest variable to move. And they move first.
Is the model really the problem?
Almost never. The evidence that moved me here came from consultants rather than researchers, which I would normally discount, except that this particular finding is uncomfortable for the people who published it.
Sit with the shape of that for a second. More than half of these chief executives can name the problem out loud, and one in seven has done the thing that fixes it. Knowledge is not the constraint and neither is budget, because a company clearing half a billion dollars in revenue can afford the two afternoons it takes to write down what an initiative is supposed to change and how anyone would know. Nobody owns the sentence. That is the constraint.
What I find genuinely striking is BCG's own remedy. Their third recommended move reads: define the expected profit and loss impact and value logic before each initiative launches, with finance validating results from day one. Before it launches. That is a requirements activity, described precisely, by people who would never use the phrase, and it surfaced in a strategy report about artificial intelligence execution because the money forced it to surface somewhere.
Careful, though. A better model does sometimes move the number, and I have watched a single retrieval change turn a dead internal assistant into one people actually opened, so the model is not nothing. It is just not where the variance lives, and I made the longer version of that case in the piece on why AI pilots produce no return.
What does requirements intelligence change in the ROI math?
Three terms. The obvious one is the weakest.
It shrinks the rework line. Everybody has heard this argument, which is exactly why it persuades nobody in a finance review. Fixing a misunderstanding while it is still a sentence costs a conversation; fixing it after the code, the tests, the training material, the integration contract and somebody's quarterly commitment have all been built on top of it costs every one of those artifacts plus the coordination to change them. Measured, repeatedly, for decades. I went through the strongest version of that measurement in the 29x rule.
It makes benefit provable. This is the term nobody puts in the model, and it decides whether the program survives its second budget cycle. A return you cannot measure is a return you cannot claim, and a return you cannot claim does not get booked, defended or renewed by anyone. Defining what done means, in advance, with a baseline attached, is not documentation hygiene. It is the mechanism that turns an effect into a number a controller will sign.
It discounts the risk. Requirements traceable to a named decision, a date and an owner are the same artifact an auditor asks for, which means discovery work you were going to expense anyway does double duty the moment a regulator, a customer security review or an internal model-risk committee comes asking for evidence. That is the governance dividend. Most business cases forget to claim it.
How do you build the business case?
Four line items. Order matters, because the order is what keeps the case alive in front of a finance partner who has read a hundred of these and stopped believing most of them.
One: the cost of clarity, at full price. Analyst days, stakeholder hours, calendar time, all of it. Do not round it down to flatter the case, because the first thing a good controller does is test whether you shrank your own denominator, and once they catch that, nothing else on the page gets read. Full price. Every time.
Two: the late change you did not have to make. Use your own history instead of an industry benchmark. Pull the last four projects, find the changes that landed after the build started, and price them properly: the engineering, the retest, the redeployment, the delayed revenue, the two weeks a team spent waiting. A finance team will argue with an analyst firm all day. Not its own ledger.
Three: the value of a defined done. Price the option. Not the outcome. What is it worth to be able to prove, at the first quarterly review, that one specific thing moved by a specific amount against a baseline captured in week one? For most programs that is the entire distance between renewal and a quiet wind-down, and the honest way to size it is the cost of the program itself.
Four: the governance dividend. Count the audit preparation, the security questionnaire answers and the model documentation you will not have to reconstruct from memory eleven months from now, under time pressure, from people who have since changed teams.
One exclusion. If the benefit column of your case contains a percentage lifted from a supplier's marketing page, an experienced reviewer will discount the whole document, and they will be right to do it.
DBS Bank in Singapore is the counterexample worth studying, and not for the reason people usually cite it. The scale is large. In its 2025 annual report the bank describes more than 2,000 models and more than 430 use cases delivering economic value of approximately one billion Singapore dollars.
The number is not the interesting part. The interesting part is that the number exists at all, and that it decomposes. Back in 2022, when the figure was 180 million Singapore dollars, DBS published the split: 150 million in revenue uplift and 30 million from cost avoidance and productivity gains. Two categories. Stated separately.
You cannot decompose a figure like that after the fact. Not honestly. It means somebody decided, per use case and before the build, which of those two buckets that use case was supposed to fill and how the movement would be observed. Most organizations running comparable programs cannot produce the equivalent sentence, which is why they end up reporting adoption instead. DBS counted use cases the way an accountant counts line items, because that is what they were treated as from the beginning.
One caveat, stated plainly: these are the bank's own disclosed figures in its own reporting, not an independent audit of AI attribution, and DBS does not publish its full attribution methodology. Read them as a company's stated results. Not an audit. The habit is still the lesson.
Sources: DBS Annual Report 2025, Letter from the Chairman and CEO and DBS, "AI-Powered Digital Transformation". Industry: banking. Company-disclosed figures, labelled as such.
What is the cheapest place to move the number?
The sentence. Before the sprint, before the model choice, before the platform decision, before anybody has written a line of code that somebody will later have to defend in a meeting because they wrote it.
The compounding runs one direction only. A clarity dollar spent in week one buys a decision that every downstream artifact then inherits for free, which makes it the only investment in the whole chain whose return grows the longer the program runs. A dollar spent in month fourteen buys a correction, and a correction has to be bought again in every artifact that already assumed the old answer. Same dollar. Opposite sign.
Which brings this back to slide fourteen. That chief financial officer was not asking a hostile question and she was not really asking a finance question either; she was asking a requirements question eighteen months too late, and the only reason it was unanswerable is that nobody had been asked to answer it while it was still cheap. I put numbers on that lateness in the hidden cost of missed requirements. Ask it in week one instead. It costs a meeting.
You cannot book a return you never defined. The business case for requirements intelligence is written above the code, before the spend.
Only 25% of artificial intelligence initiatives deliver the expected return, and only 14% of chief executives have clearly defined the profit and loss impact of all of theirs. Two surveys. Two samples. Read together they describe one condition: programs are being judged against a target that nobody in the room ever wrote down before the money moved.
Requirements intelligence moves three terms in the ROI model at once. It shrinks rework, it makes the benefit provable, and it discounts risk by producing the traceability an auditor was going to ask for anyway, on a schedule you do not control. Talent, data quality and change management matter too. Genuinely. Clarity is just the cheapest of them, and the only one whose return compounds the longer the program runs.
What are the most common questions about requirements intelligence ROI?
