ROI (Return on Investment) is the most common and popular method for project ranking, both in IT and elsewhere. But ROI isn’t working in most companies, and as a result, businesses are making bad project decisions. In this article I’ll explain why ROI isn’t working. Then in next month’s newsletter I’ll tell you how you can improve your use of ROI, and I’ll talk about an important additional project selection criterion that should be used in conjunction with ROI.
Here are some of the reasons ROI isn’t working:
In most companies, project proposals are put together by the people who want the projects to be approved. It might be a marketing or operations department who benefits from a project, or it might be the IT group itself. In any case, proposals are going to be deliberately biased to make the projects look good because the people writing the proposals know that they have to compete against other project proposals which are similarly biased toward their own projects. Making projects look good isn’t a problem, but when these same people do the ROI analysis for their projects, the results are far from fair and objective. ROI exaggeration becomes a game, and under the rules of this game, if a benefit can be claimed, then it will be claimed, whether or not there is any probability of it actually occurring, and whether or not it will have real financial benefit to the firm. For example, if a new system has the potential to save an hour per week for 200 secretaries, then you can be sure that the average hourly wage of a secretary (with benefits) will be multiplied by 200 and then by 52 weeks to chalk up some annual financial benefit. Never mind that the hour will probably be absorbed by other tasks, and that no financial savings will actually accrue to the company.
On the other hand, if the secretaries have to be trained on how to use the new system, and if there’s a learning curve involved, then you can be assured that this training time will be minimized in the estimate (maybe an hour or less per secretary). In addition, the labor costs associated with people being trained will likely be ignored, and the learning curve will be neglected altogether. The general rule for preparing the ROI in a proposal is to maximize possible benefits and to minimize possible expenses, thus inflating the ROI beyond all reality.
Omission of Secondary Costs
But it gets worse. In their eagerness to get their project approved, the proposal writers will conveniently forget that aspects of their project will increase costs in other areas. This is especially likely if a project resource is shared with other projects or other departments. Things like increased network traffic or server usage will probably be ignored. And even more likely to be forgotten are the tertiary costs such as increased support dollars for those secondary higher resource demands.
Neglect of Transition Issues
Of course, no project will get its full payback on the first day that a new system is installed. Not only will there be a transition period while users learn a new system, but in most cases there will be a short-term decline in productivity and quality while people make mistakes and then figure out how to deal with a new environment. Yet most ROI proposals show only two worlds: the one before the project is implemented, and the vision of the perfect new world after the project is completed. The costs of the transition period are usually ignored.
Minimization of Risk
Risk is usually forgotten in ROI projections. This is particularly ironic since risk is such a large part of project management once a project gets approved. Nevertheless, it is rare that risk is considered in ROI since an ROI projection boils down to one number, not a series of numbers. Have you ever seen an ROI calculation that says “there is a 50% probability of a $100 million savings, a 40% probability of no savings, and a 10% probability of a $50 million loss”? I doubt it, since ROI proposals usually show only one outcome: the successful one. Any problems with risk are considered “implementation issues” and won’t be addressed until the project is started.
Also conveniently omitted from many project proposals is the increased risk to the business of becoming dependent on a new and less reliable process. This is the risk of the new system itself, which is over and above the risk of whether or not the project can be successfully completed.
The ultimate bit of gamesmanship for a true ROI game player is to carefully break up a project into pieces, with a separate ROI for each piece. Keep most of the costs in the earlier project pieces, or if you’re a grand master, then bury some of the costs in an infrastructure project that also includes infrastructure improvements for other projects outside your department. All you really care about is the final project piece, which now has minimal cost and incredibly high benefit because all of the major costs have been buried in other prerequisite projects. Through careful project segmentation and manipulation, you can arrive at a great-looking project with a massive ROI that is guaranteed to be approved. Of course, actually doing the project is going to require prerequisite aspects of other unapproved projects, but you can blame that problem on IT or some other convenient service department, so you don’t need to mention it in the project proposal. After all, shouldn’t it be up to the other departments like IT to get their own projects approved? That’s not your problem as a proposal writer, is it?
No Follow-up Measurement
Ok, so the project gets approved. How many companies go back after the project is complete and actually measure the costs and benefits to calculate the real ROI? I’ve never seen anyone do it (If you have, I’d like to hear about it). And even if the costs and benefits are measured, there’s a high likelihood that the numbers will be distorted and therefore unusable. Labor savings are minimized by other process changes that weren’t anticipated when the project was proposed. Costs are shared with other projects and so cost accounting is difficult. And underlying volume assumptions have changed—up or down—and this affects the measurement. It’s very difficult to say whether the project ROI was actually achieved, and so the proposal writers who inflated the estimates get away with their crime, and they will go on to use similar tactics in additional projects.
ROI isn’t working because the highest ROI doesn’t go to the best project—it goes to the most creative exaggeration of ROI by a proposal writer. But in spite of its deficiencies, I’m not saying that ROI ought to be discarded as a tool. In next month’s newsletter, I’ll give you some recommendations for improving the accuracy of your ROI calculations, and for selecting the projects which can provide the most benefit for your company.
Note: This post has been combined with another post on ROI from August, 2004, “How to Improve ROI and your Project Selection Process,” and incorporated into Chapter 5 of my book, Boiling the IT Frog. For more information about the book, click here.