Business continuity: the sensible approach to ROI - Business of Technology

Computer Technology Review, Dec, 2002 by Jason Buffington

This seems to be the "Year of ROI." I believe this is due in large part to a prevalent attitude among IT organizations throughout 2000 and early 2001 that technology was good enough just because it was "new and innovative." In today's marketplace, however, the state of the economy has necessitated a return to a more sensible approach to IT. For those who are beset by consistent requests from management to compile ROI analyses for your latest IT projects, but have yet to get one passed on the first submission, consider two recent industry events with completely different audiences that remind us of this phenomenon.

On the West Coast, a panel of CEOs at a Lehman Brothers event fielded questions from the audience. One of the more interesting discussion points noted that every significant project now required an ROI; and if the ROI was incomplete to the degree that it had to be resubmitted, the likelihood of management excepting the project decreased significantly. In fact, if the ROI was returned with new information more than twice, purchasing would start to question the validity of the expense--and the project would summarily die.

On the East Coast, a group of IT professionals met at the Storage Networking World conference. There, one of the better sessions was presented by IDC and dealt with purchasing trends in 2002. Robert Gray, the presenting analyst, described the growing expectation by IT professionals and executives that most projects need to deliver a return on investment within a three-month timeframe.

What I found interesting about IDC's supposition is how dramatically the ROI window has decreased. Most of us would agree that the idea of appreciating a computer resource over three to five years is no longer realistic, since the technology changes so quickly. My personal rule of thumb for the life of a production server is 18 to 24 months, but I also recognize that technology projects should have a return on investment of less than one year and ideally pay for themselves prior to the end of the existing fiscal year in which they were acquired. This is obviously more easily done in March than it is in October. The idea of saying that this project will "save money in this fiscal year, and cost nothing for the remainder of the life of the resources that are involved" is an extremely strong statement. One can also appreciate how the bean counters want to be able to close the books with a positive result against any negative expense.

But the idea of a three-month ROI suggests the concept that the fiscal window of concern is perhaps the active quarter. With so much riding on the short-term changes to a company's bottom line (particularly of publicly traded companies), maybe this is not so surprising.

The bottom line is that ROI should definitely be considered as part of every project--from the eyes of senior management, purchasing, legal and therefore IT.

Make Your Vendors a Part of the Solution

It seems to me that "solution" vendors, as opposed to "product" vendors, recognize the same purchasing trends and requirements that you are experiencing. And, more importantly, they understand the intricacies and potentials of where their products can add value to your environment and therefore reduce costs. I personally, have worked on the vendor side for one data-protection company or another for over 10 years, and I genuinely believe that most upscale vendors want to have a "partner" relationship with their clients. We want you to be successful. We also want to sell our product(s) and be profitable. The best way to do that is to help you accomplish your goals. If you believe that deploying a solution can improve some part of your job function or enable some capability for your organization--and can save costs, then your vendor wants to help you prove that.

Most vendors use industry-standard statistics as assumptions (such as the average cost of a component or manpower resource) to determine ROI. If a vendor truly understands your needs, and you have worked together on creating the vision of a solution that accomplishes your goals, it is relatively easy to compare the cost of a project against those industry assumptions and deliver a baseline ROI.

And with just a short amount of additional effort, where you adjust those assumptions to the actual realities of your specific environment, the ROI benefits both the vendor and the client. To the vendor, it gives more realistic data. To the client, it is almost exactly what you need to justify your project--to your management and purchasing.

More Thoughts on-ROI

First, I have never seen a worthwhile project that couldn't be justified with only a brief amount of effort. The depth of the ROI should be to prove "how quickly" the payback is, not to determine if the payback will occur. So industry standards and assumptions should be able to--on their own--validate the legitimacy of a project. Your specific cost models should hopefully validate it even quicker and hopefully, in under three months.