ROI 101: Making the Business Case for Technology Investments

Return on investment (ROI) is a textbook methodology for financial managers - and is rapidly being recognized as a critical metric for understanding the value of a technology investment. But you don't have to be a financial wiz to build a business case for technology - you just need to know how the financial Wizzes do it.

First of all, no finance officer can compare their planned investment in a factory, airplane, or new division to an identical project at another company to determine what their returns will be - nor can they "baseline" the project before they start and then travel back in time with the data to justify the investment. What they can do is identify what they expect the benefits and costs to be, assess the likelihood of them occurring, and determine how far they can diverge from expected costs and benefits without losing money. IT projects can - and should - be evaluated in exactly the same way.

Without opening a spreadsheet, you can use some key criteria to assess a project and the likelihood of a positive ROI:

  • Breadth. How many people will be helped by the application? The greater the number of people, the greater the potential ROI.
  • Repeatability. How often will people use the application? The more often an application is used, the greater the ROI.

Secondary factors to consider include the following:

  • Cost. The more costly the task, the greater the benefit from automation or appropriate technology support.
  • Knowledge. The greater the potential to reuse the information in the system, the greater the potential ROI.
  • Collaboration. Communication between employees is costly, so the greater the collaboration component, the greater the potential ROI.

Once you've passed the text on the five factors, you'll want to gather and validate data to support your ROI calculation. Nucleus Research uses a 3-year time horizon to evaluate projects. Costs and benefits can be either one time or recurring, so be sure to include them appropriately. Follow these basic rules when gathering and including costs in the calculation:

  • Count everything that is directly associated with the project. For example, "I purchased a Web server for this project."
  • Don't count infrastructure items not associated with the project. For example, "I used the existing Web server."
  • Do count infrastructure items that were driven by the project. For example, "The company purchased a Web server because of this project and two others like it" means you should include one-third of the cost.

Benefits are more difficult to assess and can be either directly quantifiable or indirect productivity-based gains. It's easy to claim that productivity gains should not be included because there are no direct benefits or reductions in budgets from increased productivity. However, you should consider the additional employees you would need to hire to do the same work or the increase in output from the same number of employees. The challenge is to fairly account for gains in productivity. To do this, correct for inefficient transfer of time - which simply means that the total time saved rarely equals the total additional work performed. To measure, follow these rules:

  • Measure based on fully loaded cost.
  • Correct for inefficient transfer of time using a value of 1.0 for line workers to 0.5 for general employees.
  • Find a corroborating measurement that supports the change. For example, if the legal department saves 10% of its time, do you expect it to fire 10% of the lawyers or increase its productivity by 10%?

When in doubt, you may want to survey your users and average their estimates, look for case studies or similar examples to get an idea of the scale of benefits, or look for industry benchmarks that can provide guidance on an appropriate estimate for your company. If you choose a conservative estimate, consider calculating the ROI twice: once for the expected ROI and once for the worst-case scenario. In fact, running different scenarios (what if the consultants don't finish on time? What if one division refuses to participate?) will give you and the finance folks a clear view of how closely you need to track key elements of the project as you deploy.

Once you've gathered the data, you can make the calculations. There are a number of different financial metrics - and some are more useful than others. Following are the primary calculations and their value to the decision-making process:

  • ROI is the most important metric to use for choosing an application and prioritizing projects within a company during budgeting. ROI = average benefit over 3 years/initial cost.
  • Payback period is the time it takes for benefits returned to equal the initial cost of the project. This is a key measurement of risk - in the rapidly changing technology area, look for payback periods of less than 1 year and don't be afraid to discard a solution in favor of a better one once it's past its payback period.
  • NPV is net present value - the value of the ongoing benefits discounted back to the present year. NPV tells you if the project should not be undertaken, but it doesn't tell you to proceed. If the calculation is less than 0, you shouldn't proceed with the project (you'd be better off putting the money in the bank). A project with a value greater than 0 can't be compared with other projects unless the time horizons and the magnitude of the investment are the same, so don't use that as your metric to proceed - turn to ROI instead.
  • TCO, or total cost of ownership, provides a good metric for budgeting purposes but can't be used to judge the bottom-line benefits of a project because it calculates only lowest cost rather than greatest return. Cost is a factor in the ROI analysis, so use ROI instead.
  • IRR, or internal rate of return, calculates the effective interest rate of a project but has a serious flaw: It assumes a reinvestment rate equal to the IRR. In most cases, the calculation is misleading, and it should NEVER be used for evaluating technology. Use MIRR if you need to.
  • cROI means cumulative ROI over a 3-year period and is used by some research firms, but it is primarily a marketing metric because it dramatically overstates the ROI by using the sum of the benefits over 3 years. Do not use it as a metric.

When a good project has bad ROI

If your initial calculations yield an ROI less than expected, don't panic - take a closer look at the calculation. If the ROI is drastically negative, there are probably breadth and repeatability issues or unreasonably high costs. If the ROI is simply lower than you need to proceed, it's likely you can fix it - and gain appropriate benefits from your investment - by considering the following:

  • Change cost timing. Move costs out of the initial year by spreading training or consulting investment over one or two years.
  • Negotiate on price. A small percentage decrease in price can dramatically increase the ROI depending on the magnitude of the project.
  • Ramp costs with employees. Gradually increasing costs for training and other areas as employees begin to use the technology may be more accurate and will improve the ROI.
  • Change deployment strategy. Using the technology to support a smaller key (high-ROI) return group first or looking at outsourced solutions or consulting can drive a positive initial ROI - and the technology can be deployed more broadly later.
  • Re-examine your correction factors. If you've been overly conservative with your correction factors and productivity gains you may be passing up technology that can help your company. The objective is not to be conservative or aggressive but as accurate as possible.

Calculating ROI isn't difficult, just structured. Done correctly, a ROI analysis serves as the perfect road map for a successful deployment that delivers clear returns to your organization.

Copyright © 2003 IDG Communications, Inc.

7 hot cybersecurity trends (and 2 going cold)