Why you should always estimate ROI before buying enterprise software
Nothing else matters. Erik offered very sage advice because all complicated prioritizing schemes eventually reduce to this. When managing a portfolio of enterprise software projects, you can use the ROI to prioritize:
This article describes how to estimate the ROI for cloud or off-the-shelf enterprise software projects using the risk-adjusted value method. An example illustrating the process follows.
The risk-adjusted value method is based on pioneering work done by David A Fields and his company, The Ascendant Consortium. For a more in-depth treatment of the subject, see his book: The Executive’s Guide to Consultants: How to Find, Hire and Get Great Results from Outside Experts, available on Amazon. This article is an updated version of a white paper originally published by Wayferry.
Normally enterprise software per se has no value to an organization; rather the value comes from the outcomes that flow from using the software. Start by considering all usage outcomes as potential sources of value and combine them to estimate the gross value of the project being considered.
The first step is to examine hard benefits that flow from the desired outcomes, i.e. the benefits where a dollar amount for the outcome can be estimated. Using the table of Software Implementation Outcomes below, for each outcome that applies, estimate the dollar benefit that will accrue once the software is operational. Then sum all the benefits to estimate the total value of the hard benefits.
While all outcomes on the table should be considered (and you may even add a few), not all will apply to any particular project. Sometimes most of the value flows from just a few or even just one outcome. For example, a local government client had tax collection software that was no longer supported and needed replacing. They were afraid the software might become unusable at some time in the future and prevent the county from collecting taxes. In this case, most of the value of this project was the taxes that would be lost in the event of a software failure. All other benefits were secondary.
As you work through the above table, watch out for underestimation errors. Keep asking yourself “Is that all” You may uncover more areas of value than originally anticipated.
One common error flows from reducing headcount. Usually, these estimates are based on employee costs. For example, if an average fully loaded salary was $100k per employee, a cost saving of $100k per year is used for each person eliminated. While some would argue this is a conservative estimate, it is incorrect because you are looking for the VALUE of the employee’s contribution, not the COST of that contribution. If the company averages $300k annual revenue per employee, on average, every employee is worth $300k per year to the company. Therefore, every position eliminated by the efficiencies gained from a new software package is worth $300k per year, and not $100k. (You could further refine this by adjusting for actual salaries, but that may not be worth the effort.)
Here you look for anything that multiplies the value of the benefits. Where else will this particular software project have an impact Look for core benefits, parallel benefits, related benefits, and similar benefits. You want to do hard benefits estimates for each department (or division, section, etc.) that will be affected by the new software, and add them to the total. Again, keep asking yourself “What other areas of the organization will benefit from this software and what will those benefits be worth”
For example, if you were considering a new helpdesk application for IT support, could you also use the same software for facilities support or customer support This would be a parallel benefit. You may also find the new software allows better forecasting of support needs, which can lead to savings. Likewise, better reporting may reduce management time. Those would be related and similar benefits respectively. After uncovering all the multiplier benefits, you might find the value of the software project is increased substantially.
Total value of hard benefits = sum of hard benefits + sum of multipliers
All enterprise software goes through implementation before being used in production. For example, implementation can include the following:
For any investment, the time over which the investment generates returns must be considered. That is called the time horizon of the investment. The idea is to use the software implementation period as a guide to estimating the time horizon.
Some software markets develop rapidly. Software that can be rolled out quickly is more likely to be replaced sooner than software that takes a long time to roll out. The reason is that a short rollout has less work, cost, and business disruption, and that makes it easier to move to a better product if needs change.
For example, for software that is operational in 1 to 3 months after initial deployment, you might use a time horizon of 3 years. On the other hand, for software like ERP that may take a year before being fully operational, you might use a time horizon of 5 years. Bear in mind that there will be minimal returns for the first year if the software takes a year to roll out, so a 5-year time horizon only has about four years of returns.
Whatever time horizon you select, multiply the total value of the hard benefits by the time horizon to generate the gross value.
Gross value of hard benefits = total value of hard benefits * time horizon
In part 1 we estimated the gross value of hard benefits for the project. In the interests of being conservative and realistic, we now reduce that value.
When enterprise software is bought, what is really being bought are the benefits that flow from using that software. This is done in the context of a larger project, e.g. improving operational efficiency, launching new customer services etc.
The egocentricity error occurs when you over estimate the value that a particular software implementation will contribute to the overall project value. Ask yourself what else is required to achieve the overall value, and then use your judgment to reduce the contribution the software makes by an appropriate amount, e.g. the software itself may contribute only 75 percent of the project's value.
Every cloud or off-the-shelf enterprise software project has some risk of failing or achieving only a fraction of the expected ROI. The last step in estimating the risk-adjusted value of the project is to account for that risk.
The simplest way to estimate the risk is to make a judgment call, e.g. to estimate there is a 75% chance that the project will generate the planned ROI. You would then multiply the total by 75% to get the risk-adjusted value. Alternatively, you can use a “risk profile” approach where you segment the risk into different levels, with different risks allocated for each level. Either way, the output of this step is an estimate of the risk-adjusted value of the project.
Risk-adjusted value = gross value * egocintricity * project risk
Since the software has not yet been selected, the total cost over the time horizon must be estimated. For cloud software, this is the cost of the subscription; for off-the-shelf software, this is the purchase price plus annual maintenance. In addition, the costs of implementation, training, business disruption etc. must be added. The ROI can now be estimated using the formula:
ROI = (risk-adjusted valuet / total cost of software -1) * 100%
This is where you eliminate projects of marginal ROI. Those are the ones with the greatest risk of being canceled before they are completed. On the other hand, if the ROI estimate is conservative and the project is still clearly worth doing, you have a compelling case for that project.
To illustrate estimating the ROI using the risk-adjusted value, we will use the example of Acme contemplating a new CRM system as part of a sales development program. All values are per year, except where stated. Dollar amounts are rounded to the nearest million. We start by estimating the gross value of the hard benefits. Then we eliminate the egocentricity bias and adjust for risk. Finally, we factor in the costs and estimate the ROI. (Note that this is a simplified example to illustrate concepts.)
Acme expects the new CRM will reduce the administrative work the sales people need to do, and effectively reduce sales headcount by 3 people. Acme does not plan to reduce the salesforce headcount, rather anticipating a rapid gain in revenue as sales efficiency improves. Sales people average $12 million per year revenue each, with other Acme revenue from existing contracts. Thus, the outcome of the new CRM is an effective increase of three sales people:
3 effective extra sales people = $12 million * 3 = $36 million
Acme estimates the new CRM software will provide better visibility and management of the sales pipeline. In particular, the improved reporting will help resolve problems faster, and accelerate sales opportunities through the pipeline. Sales management anticipates this will improve the odds of winning business in competitive situations and estimates the annual value to be $4 million.
Total hard benefits = 36 + 4 = $40 million
The new CRM will integrate with the existing customer support system. Acme conservatively estimates this to be worth $4 million per year by reducing customer churn.
Adding the multiplier effect (+$4 million) = $44 million
Acme feels a time horizon of 3 years is reasonable for this project as it will take about 3 months to implement the new CRM system:
3 year time horizon * $44 million = $132 million
Gross value of hard benefits from the CRM software project = $132 million
A large part of the value of this project will come from sales training and customer support training. (Note: that is separate from the CRM user training, which forms part of the software implementation) Acme estimates the new CRM will deliver one-third of the Sales Development program value.
$132 million / 3 = $44 million
Acme estimates the project has a 75 percent chance of delivering the planned ROI:
$44 million * 75% = $33 million
The Risk adjusted value of the proposed Acme CRM system is $33 million.
At this stage, Acme has not yet selected the software so they must estimate what the actual costs would be for the 3-year time horizon, and then use this to estimate the ROI:
Risk adjusted value = $33 million
Estimate of total cost = $6 million
Total ROI = (33/6 - 1) * 100% = 450%
Average annual ROI over time horizon = 150%
This article describes how to estimate the ROI of an enterprise software project using the risk-adjusted value method. Breaking the numbers down in this manner helps achieve a much more accurate and defensible ROI estimate. To uncover potential problems, it is always a good idea to test your assumptions by inviting others to play the devil’s advocate and disagree with you. If this is going to be a large purchase, critics will not be hard to find!
Once you have the ROI for all the potential software projects in your portfolio, you can eliminate those projects where the return is too small. Then you can prioritize the remaining projects by ROI. That puts you on the path to success and maximizes the value of IT to your company.