Don’t gamble when prioritizing enterprise software projects. See why you should prioritize by ROI, and how to do it using the risk-adjusted value method. Erik Nelson, an accomplished IT professional, once said in the course of a conversation with me that when it comes to prioritizing IT projects there are really only two things to consider: Should a project be done at all? In what order will selected projects be done? 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: Eliminate projects with a poor ROI. They are the ones that should not be done. Prioritize the projects worth doing by ROI for maximum value to the organization. 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. Acknowledgements 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. Part 1: Discover the value 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. Hard benefits 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. Wayferry Table of Software Implementation Outcomes Underestimation errors 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.) Multiplier effect 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 Time horizon All enterprise software goes through implementation before being used in production. For example, implementation can include the following: Installing and configuring the software System validation User acceptance testing Setting up support (i.e. training the help desk) Training users 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 Part 2: Reduce the value 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. The egocentricity error 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. Risk-adjusted 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 Part 3: Estimate ROI 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. Example 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.) Increased revenue 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 Speed 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 Multiplier effect 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 Time horizon 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 Eliminate egocentricity bias 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 Risk adjustment 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. ROI 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% Conclusion 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. Related content feature How to calculate TCO for enterprise software Determining the total cost of ownership (TCO) of a software purchase is a complex process, rife with follow-on and hidden factors that must be taken into account. Here’s how to achieve a more accurate TCO estimate. By Neal Weinberg 01 Feb 2024 9 mins Budget IT Strategy ROI and Metrics opinion How IT can both deliver business value and 'keep the lights on' IT teams spend too much time on u201cdaily churnu201d rather than delivering real value to the organization. Read how Mike Guggemos, CIO at Insight Enterprises tackled the problem. By Chris Doig 16 Feb 2018 5 mins CIO IT Leadership opinion 15 places to use requirements when selecting enterprise software Not understanding how important requirements are and where they are used is the root cause of most problems with implementing software. By Chris Doig 29 Jan 2018 9 mins Enterprise Applications opinion The backward way of gathering enterprise software requirements Organizations ask users for their requirements, only to find that when enterprise software goes live, it doesnu2019t meet user expectations. It turns out that we have been doing this backward for years. By Chris Doig 05 Oct 2017 5 mins IT Governance Frameworks SaaS IT Governance PODCASTS VIDEOS RESOURCES EVENTS SUBSCRIBE TO OUR NEWSLETTER From our editors straight to your inbox Get started by entering your email address below. Please enter a valid email address Subscribe