Putting ROI and Cost-Benefit Analysis in Perspective

The costs of IT projects are often less clear than Six Sigma projects in manufacturing. The savings figures provided by vendors tend to be overblown, while in-house staff will give the best ROI they can to get approval for a project. How should you address the problem of maintaining realistic proportion of ROI and cost-benefit analysis in your IT projects?

Include all of the costs. What is the cost of training new users? How much does it cost to dispose of old hardware? What is the drop off in productivity while employees learn the new tool? How much overtime does the help desk incur while handling hyper-care, the first weeks after implementation that they need to hold the customer’s hands while making the transition? Many ROI calculations are unrealistic because they don’t factor in all of the associated costs.

Don’t forget the cost of the project itself when calculating the ROI of the project. For example, the cost of a Six Sigma expert may come from corporate overhead or get paid by another department’s budget. The time and effort spent implementing the project, such as line downtime during equipment installation, should be included when calculating the ROI.

Don’t tie financial incentives for projects to the stated financial benefits of the project. Provide rewards based on projects completed, measurable process improvements or observed financial statements.

Involve all stakeholders in the cost-benefit analysis. Finance, engineering, HR and shop floor staff may bring related costs to light that project planners have missed. Conversely, they may be able to identify side benefits as well that improve the project’s ROI.

Recognize the value of realistic cost-benefit analysis and ROI calculations. Overstating gains will cause anger when the tool doesn’t deliver the wonders they were promised. Overstating financial savings can blow a budget. One division I worked for saw incredible cost-benefits and financial savings from various Six Sigma ideas. Yet their actual expenditures only dropped modestly after the projects were completed, while throughput and quality improved incrementally. They adopted a new policy that expected cost savings would be taken out of the group’s budget after the project was completed. Far fewer projects were proposed after that mandate, and the promised ROI figures for the new projects were far less fantastic. And some projects shifted from ROI to quality and defect rate reduction as a stated goal.

Recognize that ROI is not the only way to measure the success of a technology. There are indirect measures of the benefit of tools in IT. The adoption rate is a rough indicator of the value or usefulness of an IT product or service. The rate of adoption is a more direct correlation, since things tend to be rapidly adopted when they are so useful that customers cannot afford to wait to adopt it.

Cost-benefit analyses need to maintain a sense of proportion. Don’t neglect small projects with clear benefits in pursuit of the very large projects with more financial gain but lower ROI and higher risk.

Understand your process and all of its cost drivers before you implement a project. The money saved by a project or process improvement may be tangible and immediately understood, such as hardware costs and installation costs relative to a reduction in the monthly electric bill. In other cases, the productivity gains from installing software or altering business processes is more theoretical. If your organization adopts a new tool and then sees 20% more throughput, how much of this is due to the new system and how much is due to other changes?