ROI Primer

Hey there. From time to time I’m going to use this space to write about my perspectives on IT management and strategy. With that as a warning, I’ll dive right in…

The first topic I want to discuss is one I have nerded-out on for years. It’s the issues I’ve seen when IT (and some Business) Management use Return on Investment (ROI) calculations.

ROI’s (as I understand it) are universally used in Finance to calculate investment returns. However, like so many other business practices, IT Managers have grabbed onto the concept and tried to apply it to their “project portfolios”. In theory, using core investment calculations to inform IT business decisions is awesome. However, I’ve found that using ROI’s for something as complex as IT projects often leads to some pretty bizarre behavior and findings. The worst part is that having talked with tons of IT decision-makers over the years, invariably they’ll want to talk about the ROI of the project at some point. Urgh.

OK – without sounding like too much of a curmudgeon, I think a simple ROI (what did I get, minus what did I spend) works really well for something like a stock sale.

I sold it for $8, I bought it for $5. Boo-yah – I made $3! Now I’ll account for the taxes and transaction fees, and maybe I’ll display my awesome investing prowess as a percentage…

However, IT projects are a much more complicated transactions and the simple correlations of “buy price” and “sell price” aren’t enough. There are tons of reasons why your company could have sold more products or gained employee efficiency, and trying to trace those reasons to one or two IT projects is really, really difficult (read: probably wrong).

Plus, in our line of work we are often asked to represent ROI’s as a forecast (what do I think I’ll get, minus what do I think I’ll spend) instead of actual dollars. I’ll come back to this at another time, but we’ve all seen the gamesmanship that’s brought into the forecasting piece.

This new project should save everyone in the company an hour a week – they’ll of course use every minute of that that time selling more products – so this project is actually going to make the company more money…

Regardless of how you deal with the complexities of accurately calculating and estimating Research, Development, Sales, Opps and Warranty costs against expected returns over time (adjusted for NPV), it’s my contention that the most critical question in IT projects usually goes unaddressed in forecasts…

What’s the chance the return’s going to come at all?

For example, using the simple “stock” math of cost versus return you can make a good case for buying lottery tickets.

I can make 10 million bucks, and it only costs me a dollar! Huzzah! I’m totally gonna’ get a raise!

The problem is that the chances of winning the 10 million are 1 in 100 million.

Oops! That means, I could end up spending… uhm, carry the 1… Oh…

Unless you address the core question of “What are the odds I’m going to see a return?” ROI forecasts can be totally bunk. You should at least be able to argue that the project has a reasonable chance of succeeding (or even completing) before you plunk down a single dollar in the investment.

So – more to come on this topic in the future. ROI’s seem simple, and yet more often than not I’ve seen them miscalculated, misunderstood and/or misused. IT Leaders seem to love them, and yet having worked on dozens (hundreds?) of them over the years, I am extremely suspicious of their results.

I think there’s a better way to calculate and forecast the return, cost and % chance likelihood of success. I’ll try to get on that really soon…