ABSTRACT: Measuring the business value of analytics investments remains one of the most persistent challenges in our field. This article examines why, presents a six step framework for defining measurable outcomes before the build begins, and introduces a formula for calculating analytics ROI against verifiable business outcomes.

You have probably sat in a meeting where you felt confident because all the analytics processes were running seamlessly. The dashboards are live. The data pipeline is running, and the reports go out every Monday. Suddenly, someone from the C-suite leans forward and asks how much revenue the newly built solution generates or what it saved the business last year.  

The room goes quiet. You take a gulp and scramble to pull up everything you have: active users, query volumes, dashboard adoption rates, pipeline uptime, data quality scores. Anything that could save you in that moment. But none of it answers the ROI question. So you promise the board you will come back with a figure at the next meeting. But deep down, you do not know what that will take or if coming up with a number is even possible. You and your team might try to trace revenue back through the solution, isolate the contribution from everything else happening in the business at the same time, and put a defensible number on something nobody defined upfront.  

All your projects have a business process in mind before they start. What they rarely have is a clear structure for measuring whether that process delivered a financial return. Accountability for the outcome sits somewhere between the analytics team and the business, which usually means it sits nowhere. And there is almost no mechanism for knowing whether the solution is still generating value two years after deployment. This article gives you a practical framework for calculating and tracking analytics ROI — one that ties measurement to real business outcomes and makes the cost of delay visible as a number you can act on. 

Why Analytics Investments Miss Their ROI Potential 

In 2015, Art McDonald wrote about a distinction that still holds today. Organizations that treat analytics as an expense minimize their investment in it. They skip the roadmap, limit the infrastructure, and cut the training. Measurement gets deprioritized because measurement creates accountability, and accountability is uncomfortable when the objectives were never clearly defined. The result is predictably low ROI because the conditions for success were never established. 

Organizations that treat analytics as an asset operate differently. They build a roadmap. They integrate data sources. They train users to act on what the data tells them. They define what success looks like before the project starts. The ROI from that approach is categorically different. 

The same pattern is playing out now with AI. Organizations are committing significant budgets to AI platforms, agents, and infrastructure. But as Matt Gordon, who builds agentic AI platforms for enterprise clients, observed in a recent Datalere webinar, enterprises have spent years over-promising and under-delivering by chasing what is new rather than what solves a defined business problem with a measurable outcome. The technology has changed. The mistake has not. 

Treating AI as an asset means asking hard questions. What business process will this change? How will we measure that change? Who is accountable for the outcome? Without answers to those questions, the C-suite meeting from the opening of this article is not a one-time awkward moment. It is a recurring event. 

The Mindset Shift That Changes How You Measure Analytics ROI 

Bob Conway, a data warehousing consultant with thirty years of experience, has a name for projects that get funded without answering those questions. He calls them “self-licking ice cream cones” — built to produce data for its own sake, with no clear business outcome attached. The objective is to have data so that you can have more data. Nobody in the room can answer what will actually change because of it. 

His broader argument is more fundamental. Data has no intrinsic value. It sits on servers, spins on disk, waits in pipelines. By itself, it does not generate a dollar of revenue or save a dollar of cost. The value comes from what people decide to do differently in response to what the data reveals. As Conway put it at a recent Denver Data Dialogues meetup: "The value of data is in the doing, not the having." 

That distinction matters because it tells you where to look when an analytics investment is not delivering. Not at the data. Not at the platform. At the decision that was or was not made because of it. 

Carlos Bossy, CEO of Datalere, framed the expectation clearly in his discussion with Matt Gordon: “You are not building an analytics solution for a 10% efficiency gain. The returns from a well-structured analytics investment should be large — three to ten times cost savings or effectiveness gains, millions of dollars for mid-market organizations, or a process that was previously too complex to manage now running automatically and delivering immediate results. If you are not seeing that kind of return, something in the structure is wrong.” 

The following case studies, drawn from Conway's Denver Data Dialogues meetup, show what that scale of return looks like in practice. 

Revenue generation 

A Chicago-based industrial supply company had been growing steadily by opening regional offices across the country. Sales eventually flattened. A new senior vice president came in and asked a simple question: “Why are we organizing our sales force geographically?” An oil company and a hospital in the same city have nothing in common as customers. He proposed reorganizing around industry market segments instead. They invested approximately $1,000,000 in a CRM system and external market data to identify and map their customer segments. The system enabled a fundamental rethinking of how the sales force was structured and deployed. One year after reorganizing around those segments, revenue increased by $200,000,000. A $1,000,000 investment that enabled a $200,000,000 return. That is a 20,000% ROI. 

Cost avoidance 

A microelectronics fabricator was carrying six months of inventory in a remote warehouse, paying interest on idle stock. The question was whether they could move to a just-in-time system — but only if their suppliers could be trusted to deliver reliably. They built a $500,000 analytics solution to analyze supplier performance, tier their procurement, and renegotiate contracts with on-time delivery incentives. The system made it possible to identify which suppliers could support a leaner inventory model and on what terms. One year after implementing the new approach, inventory holding costs dropped from $20,000,000 to $12,000,000. An $8,000,000 annual saving against a $500,000 investment. That is a 1,600% ROI. 

Process improvement 

A mortgage bank during the 2008 financial crisis was watching loan defaults erode its portfolio. Annual default losses were running at approximately $500,000,000. They invested $1,000,000 in an analytics solution to identify high-risk loans earlier in the review process. The system surfaced the predictive variables — credit rating, employment status — that made earlier intervention possible. By acting on those predictions, the bank reduced default losses by approximately $125,000,000 annually. A $1,000,000 investment that enabled a $125,000,000 annual return. That is a 12,500% ROI.

Three different industries. Three different problem types. Three different scales of investment. The same principle in every case. The technology enabled the decision. The decision generated the return. As Conway puts it: "Having access to data gives you the capacity to make better business decisions. That is not the same thing as making better business decisions." 

The Six Step Sequence for Defining Analytics ROI Before You Build 

Knowing that value lies in business process change rather than in the data itself is the starting point. But it raises an immediate practical question: how do you structure an analytics investment so that the business outcome is clearly defined and measurable before a single line of code is written? 

Conway's answer is a sequence that inverts the way most projects start. Most analytics projects begin with data — what do we have, what do we need, what sources do we integrate? The business case gets assembled afterward, usually to justify a decision already made. Conway's sequence starts at the opposite end. The last step is worth pausing on. Determining what data you need only after the business outcome is defined is not just good practice. It is the only way to avoid building something that costs as much as a purposeful solution but delivers the value of a self-licking ice cream cone. The Agile Manifesto calls this principle maximizing work not done — identify the critical data for the problem at hand and deliver it. Nothing more, nothing less. 

When Conway arrived on the project, he found a team of analysts who could not answer the most basic question: what are we trying to change? They knew how to query the data. They did not know what the data was supposed to produce. He stopped the data modeling session and stepped out.  

Walking down the hall, he ran into the director of risk management. In that conversation, everything the analysts could not answer came out in under an hour. She knew exactly what the problem cost the business and what a realistic improvement would be worth. A default rate of 8% across two million loans. Annual losses of approximately $500,000,000. A realistic improvement range of 10% to 25% — worth between $50,000,000 and $125,000,000 annually. Two critical data variables: credit rating and employment status. A $1,000,000 system. An actual outcome near the top of the range. 

The sequence did not guarantee that outcome. It made it possible to define, pursue, and verify it. 

Matt Gordon expresses the same discipline in engineering terms. Define the anticipated outcome before writing a single line of code. Know how the process will be instrumented and measured. Establish observability so the team knows whether they are getting the right results and why they are not. In Gordon's framing, this is not a quality assurance step. It is what keeps technical work tethered to the business outcome it was built to serve. 

The sequence and test-driven design are the same principle in different languages. One is the business conversation that has to happen before the project starts. The other is the engineering discipline that keeps the project honest once it is underway. 

A Practical Framework to Calculate Analytics ROI 

The concepts in this article are only useful if they translate into something measurable. Several frameworks exist for calculating analytics ROI. Avinash Kaushik's Return on Analytics model examines the value of analytical outputs relative to the cost of producing them. Stephen Tracy's work at Analythical measures the operational efficiency of the analytics function through time-based metrics. The formula below incorporates both dimensions and adds a third — tying measurement to milestone-based business outcomes and making the cost of delayed value realization visible as a number you can act on. 

It is one approach among several. But it is designed around the sequence and principles this article has laid out. When milestones are hit, it tells you what the investment returned and how efficiently it got there. When they are not, it surfaces where in the sequence the breakdown occurred — whether the outcome was never clearly defined, the business did not act on the insight, or the deployment never happened. 

Part two puts it to work with real numbers across three industry scenarios. Stay tuned.