A few years ago, I watched an AI initiative get killed in a boardroom. The technology had not failed. Nobody could answer a simple question: “How does this make us money?”
The CFO asked it. The room went quiet. The project lead started talking about “strategic optionality” and “future-proofing the value chain,” and the CFO checked her phone. Two weeks later the project was dead.
I remember the exchange because the team had a story about the technology and no clear account of the business result. I have since become much more interested in the constraint an initiative removes than the label attached to it.
That does not mean every worthwhile experiment begins with a precise return forecast. It means the request for money should explain what kind of commitment it is: delivering a result we understand, or learning whether an opportunity is real.
Start where value is constrained
Ask what costs the business money, prevents a sale or limits the service customers need. Slow quotations, repeated correction, unavailable equipment and missing information can all point to worthwhile work. So can an unmet customer need that the organization has not previously been able to serve.
Then find the cause. A quotation may be slow because information is hard to retrieve, because pricing authority is unclear, or because a specialist has too many requests. Those are different problems. Generating the document faster helps only if document production is the relevant bottleneck.
This is why I start with the process and its users. A demonstration can suggest a capability; it cannot tell you which constraint your organization needs to remove.
Three questions I still use
My first framework had six pillars and took hours to complete. People did not finish it. The next had weighted scores, but I could not justify why one concern deserved a particular weight. The worksheet was becoming more elaborate than the thinking.
I now prefer a short conversation that forces the important assumptions into view.
First, what would change if this worked? Identify the cost, capacity, service or revenue effect. For a known process, estimate a range and explain its basis. For a new service, identify what must be learned before a larger commitment makes sense. Precision that the evidence cannot support is not rigor.
Second, what do we actually have to work with? Inspect a sample of the data, its permissions and its history. Find out whether it reflects the cases the service will encounter. “The data is in our systems” leaves open whether anyone can retrieve, interpret and use it for this purpose.
Third, what happens if it takes longer or costs more? A business case that survives only its most optimistic assumptions is fragile. Discuss the scope that could be reduced, the dependencies that could delay it and the point at which the organization would stop.
The machine and the people who knew it
At a heavy equipment manufacturer, a maintenance supervisor pointed to an older CNC machine. “This one talks to us,” he said. Of the newer ones, he was much less confident.
That conversation exposed a gap between two kinds of knowledge. The people who knew the machines did not trust the sensors, and the people who trusted the sensors had little experience on the factory floor.
We brought a long-serving technician and a data engineer together so the technician could check the predictions against what he knew. I do not offer that recollection as a quantified maintenance result. What stayed with me was the practical need for the people responsible for an asset to help evaluate its recommendations.
The business case needs that work in it. Testing with domain experts, investigating disagreements and deciding how to respond to a warning are part of delivery. Treating them as an adoption campaign to be added at the end can leave a technically interesting model without an operational use.
Write down how capacity becomes money
Take this explicitly hypothetical quotation example. A team handles 1,000 requests a month. It expects assistance to reduce preparation by six minutes per request, but checking adds two minutes. Under those assumptions, the net reduction is about 67 hours a month, before support and maintenance.
That calculation is a hypothesis to test. It does not yet establish a cash saving. If the team keeps the same staffing, the immediate effect is available capacity. The business needs to decide whether that capacity helps it answer more requests, respond sooner or improve the quality of complex quotations.
If the claim is additional revenue, explain the connection. Are requests currently lost because response is too slow? Can the team serve additional demand? What evidence would distinguish the effect of the change from seasonality or a new sales campaign?
If the claim is cost reduction, explain what cost will actually change and when. Include ongoing review, integration and maintenance. Avoid counting all released time as both lower cost and higher revenue.
The arithmetic is easy. The assumptions around it are the business case.
Sometimes the right project is smaller
I once recommended stopping a proposed knowledge-management initiative at a professional services firm. The partners found expertise by calling people they trusted, asking their assistants or searching email. They did not use the existing knowledge system.
A better search interface alone would not address that habit. We redirected attention to meeting preparation, where bringing together relevant firm experience fit something partners already did. The lesson was about fit with a working practice, rather than a demonstrated return I can quantify here.
Ask whether the proposed service has a natural place in the user's day. If it requires a new habit, include the work needed to make that habit useful. An initiative can be valuable and still be too broad for the first commitment.
Leave room for growth and uncertainty
Starting with today's costs can bias selection toward efficiency. New services and markets deserve consideration too. Their initial evidence may concern willingness to use or pay, rather than an established operating baseline.
Give such work a bounded learning budget. State what the test is intended to reveal, who will interpret the result and what funding decision follows. A small test of demand does not need a fabricated three-year return forecast. It does need a reason for believing the question matters.
Also compare simpler options. If clear rules work, use them. If a workflow is broken because authority is unclear, clarify it. If evidence is too scarce for a dependable prediction, collect evidence before promising automation. There is no universal minimum number of records that can replace an assessment of the task and data.
The AI Opportunity Map helps organize candidate problems. Use it to prepare a decision, then test its assumptions with the people and records involved.
I would now answer the CFO with two things: the value we expect and the conditions it depends on. If we are funding discovery, I would say so and describe the decision the learning will enable. That gives the room something better to discuss than future-proofing.