ROI is a Responsibility – Part 2

As I said in Part 1 of this series, I have, of late, been challenged in my thinking from two quarters: first, in a LinkedIn discussion I had an entrepreneur tell me that entrepreneurs had to be too much "right-brained" and could not be cornered into decisions based on such things as calculated ROI (return on investment).

And next by this excerpt from a May/June 2003 article by Jacob Varghese:

"Basing IT priorities on ROI rankings is a fool's game, a game in which the biggest liar wins. By relying solely on ROI figures to approve a project or decide between projects, managers are shirking their responsibility for understanding how technology will affect their businesses. ROI numbers do not ensure that technology initiatives will be in line with business strategy. The success of any technology initiative depends on whether the person responsible for implementation has the required incentives, authority, and credibility across the span of the organization that would be affected by that initiative. ROI figures should merely be used as a means to ensure that the planning is as comprehensive as possible and the totality of impact has been considered. And managers should avoid approving the entire funding up front. Rather, funding should be an ongoing contingent upon the project team meeting key milestones and realization of planned benefits." (Varghese 2003)

"ROI numbers do not ensure that technology initiatives will be in line with business strategy."

Of course, Mr. Varghese is absolutely correct in this. It is quite possible to calculate an ROI for a project that has nothing to do with your business strategy. In fact, this is eminently possible if you use formulas provided by software vendors and resellers. All you need for some of those formulas are numbers like:

• Number of employees
  
• Number of salespeople
  
• Current Revenues
  
• Number of orders per month
  
• Number of SKUs and so on, ad nauseum. 

Unfortunately, one of the things that you will note about these numbers supplied to standard ROI formulas used by salespeople is that everyone has employees, everyone (or almost everyone) has salespeople, everyone has revenues, and so forth. None of these figures say anything about your business strategy or what will actually make your business better.
If you use these kinds of generic formulas to calculate the ROI of your IT initiatives, then there is no assurance whatsoever that the there will any alignment between IT efforts and your business strategy. So the answer is, do not use such ROI calculations. Go back to Part 1 in this series and see how you and your management team should calculate ROI in order to compare business opportunities that may be supported by IT investments.

"The success of any technology initiative depends on whether the person responsible for implementation has the required incentives, authority, and credibility across the span of the organization that would be affected by that initiative."

Now here is where I'd have to ask Mr. Varghese for the definition of "success." If you ask the typical software vendor or VAR (or, unfortunately, maybe even your own IT manager) the definition of the "success of [a] technology initiative," you are likely to get an answer along these lines: "If the project is completed on-time, within the budget, and delivers the quality anticipated to the end-users, then the project is a 'success.'"

What is missing in this all too typical definition of IT project success is anything having to do with delivery of business value. If that is true – if your IT manager does not relate every effort to delivering business value that is a failure of executive management. Either they hired the wrong kind of person for the job, or they have not taken time to convey across the whole organization – IT staff included – that every expenditure of time, energy or money should be focused on delivering business value.

If, on the other hand, your executive management team is "responsible for implementation" of each IT initiative and if they have prepared their ROI calculations for the project as I have described in Part 1 of this series, then they will have and know everything they need to help guide the project to full business value-delivering success.

"ROI figures should merely be used as a means to ensure that the planning is as comprehensive as possible and the totality of impact has been considered."

I confess that Mr. Varghese has me confused at this juncture. If "planning is as comprehensive as possible and the totality of impact has been considered," then what is wrong with using the ROI figures altogether? I think most readers will concur with me that the ROI in the example presented in Part 1 of this series is "comprehensive" and considers "the totality of impact." So, if such numbers exist, why not use them in a comprehensive way to set IT priorities?

"And managers should avoid approving the entire funding up front. Rather, funding should be an ongoing contingent upon the project team meeting key milestones and realization of planned benefits."

I certainly concur with the general notion that, if proof of concept can be achieved without expenditure of the full budgetary allowance for any given IT initiative then, by all means, get to the proof of concept and make a go/no-go decision at that point. This is common sense.

However, planning, that goes well beyond the IT department, should be responsible for all of the other things that must occur in order to "realize planned benefits." Technologies are tools and only tools. They represent costs, expenses and investment and do not, in themselves, ever represent revenues, Throughput or profit to the organization. It is up the business organization itself to leverage the tools in order to achieve more of the firm's goal – to make more money today and in the future. Executives and managers must have laid the functional groundwork during the planning that was used to calculate the ROI (see Part 1). They must already know what must happen to reach the estimated increase in Throughput, for example. That factor is not in the purview of the IT department.

[To be continued.]

©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.