An AI initiative can be stopped without the technology failing at all. A simple question from the CFO is enough: “How does this make us money?”
The pattern is easy to recognize. The project lead answers with “strategic optionality” and “future-proofing the value chain,” the room loses interest, and the funding does not survive the next review. The team has a story about the technology and no clear account of the business result.
That is why I pay more attention to the constraint an initiative removes than to 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 know it
Predictive maintenance is a good illustration. A maintenance supervisor may trust an older CNC machine because years of sound and behavior tell them when something is wrong, while being much less confident about what the sensors on newer equipment report.
That points to a gap between two kinds of knowledge. The people who know the machines may not trust the sensors, and the people who trust the sensors may have little experience on the factory floor.
One practical response is to pair a long-serving technician with a data engineer, so the technician can check the predictions against what they know. The point is not a quantified maintenance result. It is that the people responsible for an asset need 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
Knowledge management in a professional services firm is a familiar example. Partners often find expertise by calling people they trust, asking their assistants or searching email, while the existing knowledge system goes unused.
A better search interface alone would not change that habit. A narrower project can work better: support for meeting preparation, where bringing together relevant firm experience fits something partners already do. The lesson is about fit with a working practice, not a return anyone can promise in advance.
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.
My answer to the CFO would have two parts: 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.