
In my last piece we took a closer look at the purpose IIA’s Returned Business Value (RBV) framework—a corrective for applying traditional ROI models to analytics and AI—and one of its key pillars: assessing strategic alignment. Now, let’s dive into the intricacies of calculating commercial value.
Commercial value is a much clearer and far more quantitative set of calculations than those we employ to characterize the strategic value. The commercial value of anything that we might do in analytics and AI is calculated by taking the benefit, subtracting the cost of delivering that benefit, and multiplying the result by a risk factor: the risk that the project doesn’t get home. Benefit minus cost, times risk factor. (B-C)*(1-R).
We’ll unpack the benefits and costs variables of the equation in this article and explore risk in the next installment.

Beyond ROI: A Practical Guide to Communicating Analytics Value
Take a practical approach to proving ROI on analytics—read our expert designed eBook for a step-by-step guide on communicating the value of your projects.
Benefits
When you start to look at the benefit dimensions on the commercial value side, there is, first of all, straight up financial benefit. The project produces measurable cost savings, produces measurable revenue enhancement, and impacts some operational KPIs that eventually make their way up to the income statement or the balance sheet in a material and measurable way: “We’re trying to reduce our cost of goods sold in this product line by 20 percent in 12 months.”
And then there are a number of technical benefits. For example:
- “This project is going to solve certain of our cross-project data management problems. And that problem today adds three months and $50,000 to every project that we do. And if we do this one, that will effectively be reducing every subsequent project’s cost and time by that amount.”
- It might be unlocking some kind of existing dark data assets that the company has. “We’re going to finally go after all those reported conversations between our customer support people and our customers, and we’re going to do speech-to-text conversion, the sentiment analysis and the schematization required to make that information available to others.”
- It could introduce an entirely new data asset into the economy. “We’re going to pull in outside market data, and subsequently it will be available to everybody.”
- It could introduce some kind of cross-project technology or service. “We’re going to install XYZ technology as part of this project, and after XYZ technology is installed, everybody will be able to use it for every subsequent project, and we will have these kinds of acceleration effects on all those projects.”
The technical value could also be about building new skills in the analytics team, the IT team, the data team, etc. But ultimately, the technical value tends to be either bringing new assets into the information economy, righting one or more technical wrongs or deficiencies within the infrastructure, building new reusable skills, or in some other fashion reducing the time or cost of subsequent planned activities—and the project that accelerates or enables future projects ought to get explicit credit for that.
Costs
There are several orders of cost in technology projects. But the simplest way to think about it is there are always a) first-order costs, the cost to acquire and implement technology, and b) second-order costs, the cost to integrate and operate the technology that’s been acquired and implemented.
(A more precise model would also include third-order costs—the costs to integrate newly implemented technology with other, already-in-place technology—and fourth-order costs—the costs to migrate, sunset or retire the technology acquired, implemented, operated and integrated at the end of its useful life.)
First-order costs usually include the costs of acquiring and implementing technology, and the associated costs to acquire and onboard new human skills associated with that technology. You would also typically put the costs of the initial design-develop-testing into that first bucket: everything that costs, before production cut-over.
However, no organization should think of those as being the only costs or even the most important costs. There are second-order costs associated with the integration, operation and management of the technology you acquire and implement, including the cost of enhancement over time, supporting it as it is used, etc. Those second-order costs of integration and operation are often far higher than the first-order acquisition and implementation costs, in most cases, depending on what you traditionally think the life cycle of a project is (e.g., three or five years are good rules-of-thumb). And those second-order costs often come home to roost in a traditional IT run-and-maintain burden, which means that political coordination with IT is going to be incredibly important to your success, if you expect IT to operate in production what you can build and pilot.
To this point in particular keep in mind the problems that IT organizations will have with taking on new cost-based activities because 100 percent of their budget is already aligned to running and maintaining what is already in place.
In operationalizing your effort, you may also find that you have to actually deploy new projects to the demand side—your internal customers—and that means you’re going to spend time shepherding that demand, training those people, supporting them while they use it, etc. And if you’re lucky enough to have been successful in the first year, then what is going to come back from the demand side is a request for modification and enhancement, which takes further time and incurs more cost.
Lastly, at the end of a second-order integration and operation cost bucket, really good RBV models will actually consider the costs to revamp, remodel and perhaps retire that analytics effort at the end of its useful life. In particular, with advanced analytics and AI projects existing as constantly moving targets, that’s something that we can’t ignore. Unlike a transaction processing system that might very well stay in the portfolio for a decade or even a conventional data warehouse that might stay in the portfolio for five-plus years, in many cases advanced analytics deliver the business value they were intended to deliver and either submerge into the infrastructure, or they’re rebuilt, revamped, replaced or even abandoned.
And, finally, opportunity costs need some consideration in any good RBV model. We will be deploying capital and human resources and consuming the organization’s most precious currency: its time and attention. That means we’re not doing something else. What is that cost? That cost may express itself in terms of deferred realization of some strategic value, or deferred realization of concrete benefits from other projects that are being, effectively, deprioritized. These days, with shadow IT commonplace, we also have to ask: if we defer a project, will a determined business unit do it themselves—outside the guardrails—only to saddle us with downstream costs when we’re eventually called in to rebuild, scale, or operationalize a well-intentioned but under-resourced prototype?

Why Analytics Value Gets Lost—and How to Fix It
Explore our all-in-one resource hub for analytics ROI. Don’t let outdated ROI math understate your impact. Check out our smarter tools and frameworks for measuring value in analytics and AI—aligned to strategy, outcomes, and real enterprise conditions.