A few years ago, I watched a $3 million 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 have seen versions of that moment dozens of times, and it taught me that the gap between AI excitement and AI value is strategic rather than technical. The companies that succeed with AI work through the bottlenecks in their value chain one by one. They ask which problem costs them the most before they ask what AI can do.
The problem is selection
Gartner once predicted that 85% of AI projects would deliver erroneous outcomes, and the figure is now quoted everywhere as a failure rate. It matches my experience, and may be conservative if you count projects that technically succeed but never deliver the promised value.
Machine learning works. What usually goes wrong is the choice of project. Organizations gravitate toward projects that sound impressive, such as a recommendation engine or a customer-facing chatbot, without checking whether they address a real business constraint.
I start with financial impact and work backwards to technology. What costs you the most money right now? Where is the biggest gap between what you have and what you need? Which problems, if solved, would change your competitive position? Only then do we ask whether AI is the right tool.
Three questions that survived
The framework I use now is not the one I started with. The first version had six pillars and took three hours to complete, and nobody finished it. The second had four pillars with weighted scores, which was better, but the weights were arbitrary. Why 35% for strategic alignment? Because it felt important? That was not good enough.
What works is a short set of questions that force honest answers, rather than a scoring system that people can game their way through to approval.
- Can you quantify the impact to within 25% either way? "We think this will improve customer experience" is not a business case. "We expect an 8% to 12% reduction in churn, based on industry benchmarks and our own customer dynamics" is the start of a real conversation. If the team cannot put a financial range on the impact, the thinking is not rigorous enough yet.
- Do you have the data, or do you think you have it? I have watched projects die because the "readily available data" needed eight months of data engineering. The gap between what people believe their systems contain and what they actually contain is enormous.
- What happens if it takes 14 months instead of 6? Every timeline I have seen was optimistic. If the business case works only on the optimistic timeline, it is not a business case.
Carlos and the 1987 machine
A heavy equipment manufacturer in the Midwest had been talking about predictive maintenance for three years. It appeared in every annual planning cycle and was pushed back every year.
When I walked the main production floor, the maintenance supervisor pointed to a CNC machine from 1987. "This one talks to us," he said. "The new ones?" He shrugged. "They just break."
That conversation showed me the real blocker, and it was neither data nor budget. The people who knew the machines did not trust the sensors, and the people who trusted the sensors had never touched the machines.
So we started there, with a maintenance technician named Carlos, who had been with the company for 23 years, and a young data engineer who had never seen a factory floor. Their first project together was to instrument Carlos's 1987 machine and let him check the predictions against his own intuition.
Six months later predictive maintenance was working, because Carlos trusted it. The model had not become any smarter.
Unplanned downtime fell by somewhere between 22% and 35%, depending on how you count. The efficiency gains took 14 months to appear, not the 6 in the plan. The CFO calculated $1.8 million in savings and the plant manager said $2.4 million, and both were right, using different baselines.
The project I helped kill
Last year I helped kill another $3 million initiative, and I did it enthusiastically.
A professional services firm wanted an AI-powered knowledge management system that would put the right expertise in front of the right people at the right time. The business case had been done, the numbers worked and the technology was proven. I recommended stopping it.
When I interviewed partners about how they actually found expertise, none of them mentioned the existing knowledge management system. They called people they trusted, asked their assistants or searched their email. The firm had a culture built on trust in people, not on a knowledge base, and a better search engine would not change that. It would only be a more expensive tool that nobody used.
We moved the budget to something smaller: an AI assistant that helped partners prepare for client meetings by pulling together relevant firm experience. It worked because it fitted an existing habit, meeting preparation, instead of trying to create a new one. Sometimes the best AI strategy is a smaller one.
The costs nobody budgets for
Most ROI analyses miss the costs below the surface that turn profitable projects into money pits.
The model is perhaps 20% of the work. The other 60% to 80% is data: finding out what data actually exists, cleaning it of missing values, errors and inconsistencies, combining data from systems with different schemas, definitions and update cycles, and building reliable pipelines from source systems to the machine learning environment. As a rule of thumb, multiply whatever a vendor quotes for data preparation by three or four.
Then there is the cost of running it. A financial services firm budgeted $2.1 million for a fraud detection system, an accurate estimate for the build. It had not budgeted the $800,000 a year for monitoring, retraining, incident response and compliance documentation, and that surprise soured the organization on its AI programme. Models degrade as the world changes, so they are never built once and left to run.
Use cases that delivered
Two patterns have worked consistently in projects I have implemented.
The first is lead scoring done properly. A B2B technology client saw a 23% improvement in close rate, a 31% shorter sales cycle and 40% less time spent on leads that never convert. The model found patterns across 47 variables that sales reps could not process. Leads who engaged with three specific pieces of technical content within 48 hours of a webinar converted at eight times the usual rate. Before building any model, we spent six weeks on CRM data quality. We designed the scoring to support the reps' judgment rather than override it, showed them why each lead scored high or low, and started with marketing qualified leads before expanding.
The second is automation that handles exceptions. Basic robotic process automation follows rigid rules, while intelligent automation copes with edge cases. A financial services organization automated 73% of its account opening process, using computer vision to verify documents, matching identities across databases, screening for compliance with a risk assessment, and routing exceptions to human reviewers with the context they needed. The remaining 27% are genuinely complex cases that benefit from human judgment, and the people who handle them no longer spend their time on the straightforward ones.
When not to use AI
This may be the most useful part of the article. If you make 50 decisions a year and each needs deep context and judgment, you have a process and expertise problem, not an AI problem. If you have 200 examples of what you are trying to predict, you probably do not have enough signal; you need thousands, representative of current conditions and labelled accurately. And if you can write down the decision rules and they work reliably, you probably do not need machine learning. I have seen organizations build elaborate models for problems a well-designed decision tree would have solved.
The question to ask is what AI offers that a simpler approach does not. If the answer is unclear, start with the simpler approach.
What the winners do differently
The organizations with the most AI in production did not start with enterprise-wide transformation. They started with focused pilots, proved value and expanded step by step. They invested in data warehouses, governance and data quality before the AI projects, which is unglamorous work that makes those projects far more likely to succeed. And they accepted that most experiments fail. A 30% success rate on AI pilots is good; the organizations that do well run many experiments, stop the failures quickly and put more into the ones that work.
The strongest objection
A growth-minded executive might say that starting from "what costs us the most" steers AI toward cost cutting and away from new products and revenue, and that a gate requiring a 25% estimate would have stopped most of the experiments that later became big businesses.
There is something to that. Cost problems are easier to quantify than new opportunities, so a framework like mine can undervalue growth. But "what costs us the most" includes revenue lost to slow quotes, churn and missed cross-selling, which are growth problems. And exploratory bets can still be funded as small, time-limited options with a clear learning goal. What the questions are meant to stop is the $3 million commitment made before anyone can explain how it will make money.
Getting started
- Map your value chain and find where costs accumulate and value leaks.
- Put a number on the cost of the top three to five problems, and on what solving each would be worth.
- Check data readiness for the most valuable problems.
- Run a focused pilot with clear success metrics and a 90-day timeline.
- Expand the pilots that work, and stop the others quickly and try something else.
The organizations that do well with AI have the discipline to say no to impressive demos that do not solve real problems.
Monday move
Take the AI project you are most excited about and write the answer to the CFO's question in two sentences: which cost or revenue line it moves, and by roughly how much. If you cannot do it without phrases like "strategic optionality", run it through the three questions before anyone asks it in a boardroom.