Escaping the ROI Trap, Part 2

My post on "Escaping the ROI Trap" has gotten a lot of feedback, especially after it was included in last week's Carnival of the Capitalists. Overall, the feedback was positive. But a few writers provided additional perspective.

For example, Enrico Camerinelli of Meta Group provided a description of Meta Group's model and where he sees the ROI trap fitting into it:

At META Group we use an IT investment portfolio model, where we segment IT investments along 3 layers:

Run the Business (RTB) investments. IT investments that cover core enterprise day-by-day operations (e.g., electricity, heating/air conditioning, payroll, data center operations for specific services).

Grow the Business (GTB) investments. IT investments covering business processes that allow the enterprise to expand its reach. Such processes are not too distant from the traditional way the enterprise manages its ordinary business (e.g., a bank wanting to implement a user self-service application for online account status checking).

Transform the Business (TTB) investments. IT investments covering brand new processes adopted by the enterprise. New business models and new disciplines are introduced to manage new business streams (continuing with the bank example, Unicredito, one of Italy's largest banks, is offering supplier sourcing and procurement services to its clients).

For RTB investments, the evaluation system is mostly related to cost elements. Surveyed organizations declare they reference the total cost of ownership (TCO) model as the most used evaluation methodology to drive investment choices.

In the context of GTB, the level of discretionary spending and the "knowledge" of the supported business processes require widely available technology and know-how. The software solution is thus viewed as a "features & functions black box" that supports the company strategy, and the organization perceives value in the full exploitation of the resources invested in the software. Interviewed participants confirm they find in "return on investment" models the appropriate cost/benefit estimation support. Such models "check-list" the features and functions against the business processes and operations the software is expected to support.

For TTB spending, the lack of historical memory and experience in controlling such projects demands a "risk of investment" approach. Interviewed enterprises envision the software solution as an aggregation of components that build the appropriate IT portfolio/ ecosystem. While the organization well knows and is able to anticipate business objectives and adoption risks, the same cannot hold true for what functionalities of packaged software solution must be adopted to cover those processes. The value is thus in minimizing the risk of the software investment through evaluation models that "configure" the building blocks of the enterprise software solution around focused processes and a calculated (and accepted) level of risk....

In my opinion, the "ROI trap" occurs at the TTB investment level. Therefore, I see a perfect integration between my Risk of Investment model and your four actionable items in "How to escape the ROI trap."

Dr. Joseph Smolira at Belmont University points to options analysis as a way to overcome the ROI trap. Smolira writes on his weblog,

I was particularly interested in Frank Scavo's post on capital budgeting, although I am not sure I completely agree with him. He makes an behavioral argument why capital budgeting projects are not undertaken. Astute financial managers (at least those who have taken my class) know that the application of NPV techniques, or in the situations given in Scavo's post, real options analysis, would solve the problem.

Framing of Risky Decisions
My main point regarding the ROI trap was not to spell out how investment decisions SHOULD be made. It was to describe how such decisions, frequently, ARE made. The problem is that decision makers often refuse to approve an investment made on the basis of ROI, no matter how sound the financial analysis. That's why I call it the ROI trap. The trap, to the presenter, is in thinking that a dispassionate ROI analysis will lead the decision maker to the "right" decision. Sometimes it does. But too often it does not. As Max Bazerman points out in his book, Judgment in Managerial Decision Making, people are "naturally risk-averse concerning gains and positively-framed questions" and "risk-seeking concerning losses and negatively framed questions." In other words, the way many investment decisions are presented--guaranteed costs and uncertain benefits--is precisely the opposite of the natural bias of the decision maker. Read my original post on the ROI trap for a full explanation.

I have come to the conclusion that management bias against uncertainty is at the root of many failed attempts to sell new information systems. In a section entitled "The Framing of Risky Decisions," Bazerman writes, "People value the creation of certainty over an equally valued shift in the level of uncertainty." Merely reducing the level of uncertainty does not carry as much weight to a decision maker as elimination of uncertainty altogether. Therefore, according to Bazerman, risky decisions should be framed in such a way that certainty is created, especially in respect to benefits.

Example
If elimination of uncertainty is the key to escaping the ROI trap, then the business case for new systems ought to be structured less like a bet on future benefits and more like an insurance policy against bad things happening.

For example, suppose you are proposing a new ERP system to replace a legacy system. Following the conventional wisdom, you would first estimate the future benefits, both tangible and intangible. For example, the new system might help reduce inventory, improve administrative productivity, or speed up collections. You would then estimate the costs of the new system, such as the cost of the software, hardware, and implementation. You would then calculate the return on investment. If you keep it simple, you calculate a payback period (e.g. 24 months). If you are more sophisticated, you calculate a net present value for the discounted cash flow, which takes into account the cost of money. If you are really sophisticated, you include options analysis, as Dr. Smolira suggests, to take into consideration the risks that future benefits might not be realized.

But whether simple or sophisticated, the ROI approach does not address the fact that decision makers hate uncertainty when it applies to benefits. Many times I have heard executives say, in effect, "Yes, but can you guarantee that inventory will be reduced, productivity will be increased, or collections will improve?" This, after presenting the ROI using the very assumptions on benefits that the decision maker himself provided!

Often you can sense the ROI trap before it is sprung. If so, perhaps a different approach in presenting the business case will have better success. Instead of starting with the benefits, start with the costs. Risk-averse decision makers won't hear anything about benefits anyway until they find out what are the costs, so get that out of the way early. But present the costs as an insurance premium. Insurance against what? Against bad things happening. For example, the legacy system might be unsupported by the vendor, or poorly understood by existing IT staff, or unreliable. Therefore, business continuity might be threatened. The costs of continuing to support the legacy system might become exorbitant. The company may be at risk for regulatory non-compliance, such as insufficient internal controls under Sarbanes-Oxley, or 21 CFR Part 11 compliance under FDA regulations. The legacy system may not be able to keep up with increased customer demand, or it may not accommodate new products or international expansion. If you look at risk broadly, nearly everything that you consider as a benefit of the new system can be translated into a risk of a bad thing happening if the legacy system is retained.

Escaping the ROI trap means clearly presenting the case that staying with the current situation is not an option. As long as the decision maker believes that nothing bad will happen if the legacy system is retained, the new system will never be approved. The promise of uncertain future benefits is not enough to overcome the guaranteed cost of the new system.

Does this mean that an ROI calculation should not be presented? Of course not. In many companies, an ROI calculation must be submitted as part of any capital expenditure request. But the ROI calculation is usually only the formal justification for what the executive wants to do. The key is to understand the executive's natural bias against uncertainty and to frame the investment decision so that it offers some form of certainty instead of merely accounting for uncertainty. Only then can you escape the ROI trap.