One of the first things that is asked of any new project in a modern IT department is that a cost benefit analysis be created to determine if the investment of time and resources makes sense. This takes many forms, but at many companies the idea of return on investment, or ROI, is king.
Management’s goal in asking for an ROI analysis is simple: explain why an open source project (or any other project) is going to help the organization succeed by increasing revenue or saving money. Technologists frequently are annoyed by the request to analyze ROI, for several reasons:
It is hard to create a defensible approach. The results of almost any ROI analysis can be changed massively, by adjusting assumptions.
Intangible benefits, such as flexibility or creating a simpler architecture, are frequently undervalued or are not included.
Besides reducing technical costs, technologists have difficulty making reasonable estimates about how the new technology will increase revenue.
Despite these difficulties, ROI is here to stay, and almost every IT department that intends to use open source must figure out a way to determine the ROI of open source. Reasonable managers will not give open source a pass on faith. This chapter will provide an informal guide to analyzing the ROI of using open source.
The need for ROI comes and goes. In boom times, when IT is being asked to support more business activity as quickly as possible, ROI is no longer king. It gets deposed and becomes a proletariat. However, when the return is out there for the taking, if you can execute a business strategy quickly, the investment in IT to speed execution is not scrutinized nearly as closely. During times such as these the CEO or VP of sales might be most influential in promoting IT investment. But when times are sour, the CFO emerges as the most important gatekeeper—and CFOs love ROI analysis.
Most managers know that ROI is difficult to create. When something makes sense but is hard or impossible to quantify, managers are inventive when it comes to finding ways to justify investments without ROI. One common approach is to call something a
strategic investment, meaning the investment makes sense and will improve the company’s position despite the fact that a hard dollar analysis is nebulous. Billions of dollars are spent on strategic projects.
Technology vendors are very hip to the value of an authoritative ROI study. Most software vendor web sites contain and prominently feature ROI studies for specific uses of the software or for specific industries. Microsoft, for example, has commissioned several ROI studies about Linux. They all show—surprise, surprise—that Linux is more expensive, using assumptions that match few real-world situations. Some of the commercial companies promoting the ROI of Linux have also created studies showing that Linux costs less than the alternatives, but they use assumptions that apply to only a few companies.
For most uses of open source, there is no vendor preparing an ROI study. Even a specious ROI study can be adjusted with assumptions that match more closely the conditions at your company. Getting ROI correct is always a “do it yourself” proposition. With that in mind, let’s discuss how you can determine the ROI of an open source project.
At a high level, calculating ROI for open source is pretty much the same as for commercial software. The equation looks something like this:
Of course, for such an equation to make sense we must understand many things:
What is the time horizon for the analysis? How long will we get to count revenue or savings against this investment? One year? Two years?
Is it possible to compare alternatives? Should we choose the fastest time to payback or the largest savings over the long term?
What are the interest rate assumptions? What is the
hurdle rate--that is, the minimum return—for any investment for the company?
What costs will be included and what will be assumed to be born as infrastructure costs? ROI analyses frequently don’t include the extra costs of electric power or bandwidth. Sometimes ROI analysis includes hosting, and other times it doesn’t.
Should reduced costs in the future, or costs than can be avoided, be included? How can such costs be reasonably estimated?
Are the same costs between the alternatives being compared? Has the analysis for one product assumed away costs, or underestimated them? What costs are vendors concealing or disregarding?
The answers to these questions can vary widely, and they illustrate why ROI calculation is much more an art than a science. The vendor ROI studies sponsored by Microsoft carefully tune the assumptions against Linux by comparing mainframe-like machines from IBM running Linux with large PCs running Windows. Microsoft is not unique in its manipulation of assumptions. Almost all vendors do this to some extent. No defensible set of assumptions applies to all situations.
Other questions are of great significance to how an ROI analysis is constructed. Is there a minimum payback period for all IT investments? How much will it cost the company, and how much can it earn from alternative investments? If interest rates are high or a company has profitable businesses that need money to grow, the bar for investing in IT can become high indeed.
The last point in the list about using equivalent costs is the one that makes comparing commercial and open source software most difficult. The costs of open source have a different shape than the costs of commercial software.