ROI is a Responsibility – Part 5

This is Part 5 in a series where we have been reviewing comments made by Jacob Varghese in a 2003 article in which he essentially claims that it does not make sense to try to measure or compare IT initiative based on ROI (return on investment) calculations. In preceding portions we have noted that Varghese called upon Ross and Beath to help him say more about how and why ROI might not be a good way to make determinations regarding IT investments:

"In 'New Approaches to IT Investment,' Jeanne W. Ross and Cynthia M. Beath break all IT investments along two dimensions: (1) strategic objectives (short-term profitability vs. long-term growth) and (2) technological scope (shared infrastructure vs. business solutions)…. Based on those two dimensions, all IT investments can be broken into one of the following four categories:

"Transformational: IT investments that aim to remove the infrastructural barriers to long-term growth across the organization (for example, integrated CRM, enterprise information portals, or end-to-end processing). Given the organization-wide impact and the imperative that such investments must be in line with organizational strategy, the CEO must own these investment decisions. The success of these projects should be his responsibility.

"Renewal: The aim of renewal IT investments (such as legacy modernization and platform conversion) is to improve the service levels of the existing shared infrastructure or reduce the cost of support and maintenance. The ownership of such projects should lie with the CIO, since the boundaries of these projects are well defined and benefits accrued can be quantified up front. Moreover, it is the CIO's responsibility to ensure the service levels from the shared IT infrastructure are constantly improved.

"Process Improvements: The end objective of IT investments that focus on short-term profitability or incremental process improvements might be to speed time to market, lower the cost of operations, or to differentiate services/product offerings. The ownership of such investments should lie with the business unit head, functional head, or the process owner, depending on how the organization is structured.

"Experiments: New technological trends that present significant opportunities for long-term growth should be the focus of IT experiments that use pilot programs to validate the technology's promise and impact. There is no fixed home for these projects. In one the industry, they might reside within the R&D organizations, in another, the enterprise architecture teams of MIS departments might take responsibility." (Varghese 2003)

I have previously concurred that there is, of course, legitimacy surrounding each of these classifications, but I wanted to take a closer look at each since it is my firm belief that business organizations really should be seeking ongoing improvement and, for for-profit organizations, real improvement should lead to making more money. In Part 3 we discussed "Transformational" IT projects. In this portion, we will try to cover, in a more brief way, the other three Ross and Beath categories for IT projects.

Process improvement IT projects

Ross and Beath tell us that "process improvement" IT projects are those "that focus on short-term profitability or incremental process improvements [such as] to speed time to market, lower the cost of operations, or to differentiate services/product offerings."

The Ross and Beath examples for IT "process improvement" projects are most enlightening. They are:

• Accelerating time to market
  
• Lowering the cost of operations
  
• Differentiating of service or product offerings
  

Now, allow me to restate these in the context of the three key metrics that we have been using repeatedly in this series:

Example Project	Key Metric Predicted Effect
Accelerating time to market	Assuming the enterprise's products or services have a market and the firm is doing a reasonably good job of selling the products prior to the "process improvement" project under consideration, then accelerating time to market should lead to increasing Throughput. All that needs to be done by the executive team is to figure out how they will leverage accelerated TTM (time to market) in order to increase Throughput, and then put numbers (estimates) to the question of how much they believe that Throughput can be increased as a result of the improvement.
Lowering the cost of operations	This is a simple exercise in reducing Operating Expenses. The question to be answered by your executive team is just how much Operating Expenses can be reduced without jeopardizing support for increasing Throughput (from other initiatives that are hopefully underway already).
Differentiating of service or product offerings	This should essentially be a ditto of what I said above in the "Accelerating time to market." After all, what is the point of investing in increasing the differentiation of your firm's products or services if doing so does not, in fact, lead to increasing Throughput. Still, managers will need to set their minds to calculations of how and how much the new differentiators will add to Throughput.

Experimental IT projects

In their article, Ross and Beath describe "experiment" IT projects as those that test "[n]ew technological trends that present significant opportunities for long-term growth" in "pilot programs to validate the technology's promise and impact." Since this is purely experimental, it would seem that it would be impossible to calculate their potential effects on T, OE or I.

However, I believe that it would be possible to apply a simple method called "profit expectation" to determine the value of potential benefits that might flow from experimental technologies. Under such an application, the standard ROI formula would be modified to the following:

ROI = ((a% * delta-T) – (b% * delta-OE)) / (c% * delta-I)
where
a% = estimated expectation (as percent) of achieving calculated delta-T,
T = Throughput, b% = estimated expectation (as percent) of actualizing delta-OE,
OE = Operating Expenses, c% = estimated expectation (as percent) of required delta-I,
and I = Investment

It would seem to me that these kinds of R&D projects would not be considered alongside other immediately accessible improvement projects. Therefore, an alternative approach for R&D should be considered. For example, perhaps before investing more than some preset and relatively small amount in any R&D project, the promoters of the project must present an ROI calculation to a review committee based on the formula above. It is up to the backers of the project to "sell" the committee on the validity of their calculations and estimates for a%, b% and c%.

Furthermore, it seems reasonable that as R&D projects move forward and more is learned, the values used in the ROI formula will change. Certainty should increase with each incremental review, but the ROI value will move up or down over time. By reviewing projects on a regular basis – weekly, monthly, quarterly, as may be reasonable for the type of organization – your executive team can maintain a clear and consistent drive toward increasing ROI through the firm's R&D efforts.

The bottom line

We must again be reminded: the bottom line is "the bottom-line." Do not succumb to accepting the concept that it is not possible to calculate ROI for so-called "process improvement" or "experimental" IT projects. There are ways to help your organization stay focused on real improvement – improvement that is most likely to have a positive effect on your enterprise's bottom line.

©2010 Richard D. Cushing

Works Cited

Varghese, Jacob. "ROI Is Not a Formula, It is a Responsibility." Journal of Business Strategy, May/June 2003: 21-23.