Why IT ROI doesn’t matter?


Does IT ROI matter? Great many intelligent people are spending sleepless nights and countless dollars calculating IT ROI. The author argues that they are wasting their time and shareholder dollars!


You can't miss it. It is all around us. The noise, I mean. "Maximize the value of your IT investments" or "Get the biggest bang for your IT buck" or "how to get IT to do more for less" interspersed with "improve IT ROI" or "better IT ROI".

Reminds me of a joke in which a home is being burglarized and the lady of house admonishes the man of the house to action: "Don't just stand there; do something". And the man's response? He breaks into a song and dance routine.Trans Well, IT ROI is the IT community's song and dance in response to the business' question: is IT delivering value to the enterprise?

Funny or not, the joke is on us.

A lot of time and effort is being expended on something that will not generate the desired results. The irony is that in some cases this focus on IT ROI will produce the exact opposite of what we want to achieve. Don't get me wrong. There is nothing wrong with the objective. It is the means that I am questioning. The means to better IT value is not to measure and track IT ROI. To the contrary, IT ROI is one of the most flawed measures of IT value. ROI is a financial metric designed for a specific purpose. Applying it to an internal investment such as IT is counterproductive. For the sake of brevity, we will focus on only a few reasons.

What about the risk?

The focus of ROI - return on investment - is on the IT investment and its return. These calculations do not factor in risk. Risk is what derails the best "promise".

Let us say we have an IT Project proposal that will generate excellent ROI - small investment leading to a large return. Should we act on this great "promise"? Before we do, let us ask ourselves the real question - can we pull it off? Answering this question is acknowledging the risk that our IT ROI calculations completely missed. If we acted without assessing the risk, then we deserved what we got.

Bottom line, ROI should not be applied in isolation.

Some things cannot be measured

Like the "revenues" or "cost savings" produced by a new IT project! Have you ever heard of those business cases where the "payout" is described in great detail down to the last cent? Have you ever seen any of those promises fulfilled? I haven't.

No, people are not deliberately misleading. They are the victims of "irrational exuberance", on the one hand, and the IT ROI pressure, on the other, to ignore ground realities. IT projects, like other adventures known to mankind, are dependent on many things - a lot of them outside our sphere of influence.

Providing precise dollar amounts on future results - some projected as far as 3-5 years - is ignoring this fundamental fact. It is a business truth, most business leaders will admit to: at any given time, we know a fraction of what we do not. And what we do not know can, and often does, overwhelm and negate what we know.

Can we trust ROI calculations? If we cannot, then how can we trust decisions based upon them?

For argument sake, let us say we got it right. Potential benefits and investment for a project, I mean. Now, can we measure and track them to make sure we got what we bargained for?

The only thing that I have seen measured and tracked to a certain degree of accuracy is the cost i.e. the investment. Untangling the costs of a project is also a very tenuous process and in a large and complex organization these calculations are bound to be wrong. But I would agree that, with effort, we could get in the ballpark.

Tracking benefits is a different story. Because, by definition, there are no IT projects, there are only business projects. One does not - or should not - undertake an IT project till one sees a business benefit. Therein lies the problem of allocating the benefits to the various efforts - - IT's included - that went into generating them. Do we really know how much a certain project delivered in dollars and cents? Can we untangle the web of business processes to know for sure what IT's contribution was? I think not.

Let us take a simple example of a company web site. IT creates it. Marketing markets it. Operations provides fulfillment for it. Finance and Accounting do their thing. Who is responsible for which part of the revenues generated from this site? Unless this is a startup, can we ignore the fact that the traffic to this site was more a result of the existing brand and operations of the company than the marketing efforts?

Pundits will sell you activity based costing to answer all these questions. Perhaps, with deep pockets and ample time, one could get to the bottom of this. I haven't seen it being done. Before we spend shareholder dollars on this activity, shouldn't we ask ourselves: Does it really matter? After all, our objective is to demonstrate value creation. Are there better aggregate measures available that do not require boiling the ocean? Yes, there are.

Some things should not be measured

Like the "revenues" in dollars, for IT projects in a portfolio! I know the sun is far. Do I need to know the exact distance to know that I cannot make it there in a day? I know it is hot enough to burn me if I get close. Do I have to know the exact temperature to decide not to get too close?

The difference in measuring or not is in the context of the decision that will be made from that measurement. If the objective is portfolio rationalization then there are many simpler and more powerful relative metrics available to achieve that objective.

What about soft benefits?

Let me give you an example of soft benefits. Any IT Project creates intellectual capital in the form of techniques and processes discovered or created. It also trains employees. It gets team members working closely together as a team. An IT Project - successful or not - creates this embedded value that is referred to as "soft benefits"

Some organizations are disciplined in knowledge capture. Irrespective, this value is embedded in each employee who worked on the project. That employee will use this knowledge or embedded value in the next project they undertake. As a result, the next project would require less "investment" and potentially provider greater benefits.

  • How do we factor this value creation and use in our ROI calculations?
  • Could a low ROI project create substantial "soft benefits" that it is worthwhile pursuing?
  • Could a failed project have created so much embedded value that the payout is in subsequent projects?

This is one example of "soft benefits". There are many others. The point is that ROI calculations are not adequate to make project decisions as they completely miss this important benefit because it is difficult, if not impossible, to quantify.

Loss leaders

Ever wonder why car manufacturers willingly sell smaller vehicles on which they lose upwards of $1,000 on each copy sold?

They believe that these "loss leaders" will eventually generate sales of their higher margin vehicles. The theory seems to be working well for decades now. Would the negative ROI on these "loss leaders" lead these companies in the wrong direction? Or should they spend time and money on calculating a more precise ROI that includes the sales "bump" for each loss leader sold?

In the IT context, should we shelve negative ROI IT projects that provide a competitive advantage to the company? Are there other, perhaps better, metrics available for the purpose?

Residual value

IT investments are different from other investments in a key aspect: residual impact or value. What one does today, has residual impact - positive or negative - on things that follow. Take for example, software components. Once created, they can be reused ad infinitum. This is the simplest form of residual value. However, the IT value creation and residual value is more complex. Every IT decision impacts the other:

  • Buy a server and you have affected the software, personnel, and training decisions.
  • More importantly, you have affected every decision that follows this one because of interoperability considerations.

This residual value - positive or negative - is difficult to quantify. One simply does not know all the things one will do in the future. The only thing that is for sure is that those decisions will be affected by decisions in the past.

In IT this impact is more pronounced because of the price tag of both the initial investment and effort required to untangle things once they go wrong. We buy software today that does not interoperate with software that we purchase in the future - should the additional cost of "integration" be factored in the ROI of the first software purchase or the second one? Either way, our ROI calculations will be off the mark.

IT ROI is not designed to measure this residual impact. IT ROI is at best a guess at IT value. To make meaningful IT decisions based on IT value, it needs metrics of its own.


Signup for Thought Leader

Get the latest IT management thought leadership delivered to your mailbox.

Mailchimp Signup (Short)

Join The Largest Global Network of CIOs!

Over 75,000 of your peers have begun their journey to CIO 3.0 Are you ready to start yours?
Mailchimp Signup (Short)