How to make an ROI calculator and impress finance (an engineer’s guide to ROI)
Think back to the last time you wanted to purchase software for your organization. The software solves real problems and makes your team’s life easier. Then, finance delays or rejects your proposal. What’s going on?
When petitioning for a software purchase, especially an expensive one, speak the language of finance. They may not understand the technical benefits, so include the business benefits, such as engineering hours saved, increase in customer satisfaction, or reduction in infrastructure costs. One number that speaks volumes is the return on investment (ROI).
We recently launched an ROI calculator for Gremlin and we’ll break down how we came up with the formula as an example so that you can build something similar in a spreadsheet for the software you want to purchase. This Google Sheet provides a framework you can build on.
Before starting, pick a length of time for the software to prove its value. Typically, this is three to five years, but some go as far as ten years. For Gremlin’s calculator, we chose four years. From our experience, Chaos Engineering practices take about two years to fully develop and we added two years of steady-state usage. At that point, Chaos Engineering is an embedded practice and the value is self-evident. This seems like a long time to project, but finance and procurement teams often think in terms of these timelines, despite the reality that benefits are realized much faster.
Project the revenue gained and costs saved
Projecting the benefits is the hardest part, so we’ll tackle it first. We break down every assumption into as many components as is necessary until we can back each one with historical data or numbers supported by third parties. If we are justifying purchasing an observability product, for example, we could calculate additional revenue by the time saved detecting an issue and the engineering and operations hours saved trying to find the causes of incidents through logging and tracing. We’d need to break those down further until they are measurable and comparable.
For example, at Gremlin, our software helps customers save money by reducing downtime and shortening the mean time to recovery (MTTR). We broke the cost of downtime down into a few primary components: lost revenue, lost productivity, and the cost of time spent troubleshooting. Lost revenue can be broken down into per-hour revenue directly tied to the services we manage multiplied by the number of hours of downtime last year. Lost productivity comes from multiplying the fully burdened salaries of all employees impacted by the number of hours of incidents they faced last year and the percentage of their productivity impacted by an outage. For many of our customers, the average employee may lose 20-50% productivity during an IT outage, as they can work offline for some period of time. Finally, the cost of time spent troubleshooting comes from multiplying the fully burdened salaries of employees with the hours spent troubleshooting those high severity incidents and the hours spent on day two work like creating patches and performing post-mortems. Gremlin reduces all of that by an average of 20-30%.
Total cost of downtime
- Lost revenue: Revenue per hour x number of hours of downtime per year
- Lost productivity: Fully burdened salary of average employee impacted by an outage x number of incidents x hours per incident x percentage of productivity lost
- Cost of troubleshooting: Fully burdened salary of architects and engineers troubleshooting x number of incidents x (time spent troubleshooting + “day two” time creating patches and performing post-mortems)
For other software, we want to break the benefits into concrete components. The benefits include both increased revenue and decreased cost and add them together. If it’s a portion of a larger component, include as much detail as possible, such as if the software will help decrease development time by X%, then take the salaries of developers and multiply that by the percent savings. For revenue growth, take the additional customers earned or reduced churn and multiply that by the yearly customer value. Each software tool’s benefits are different, so this will have to be customized to the benefits of the tool.
Costs of the investment
For the denominator, we’ll need to compute the cost of the software. This is not just the per year price of the product. It includes the implementation costs and any professional services we need to purchase to get up and running. For very complex software like CRMs, if we want to highly customize a solution, the benefits increase, but so do the costs. All of this needs to be factored into the ROI calculation.
For example, at Gremlin, our key tenant of simple means many of our customers perform Chaos Engineering without professional services, reducing the costs to our fees and the time spent by engineers running chaos experiments. However, we do have customers who want deep customization, such as embedding chaos experiments into homegrown observability or CI/CD tools. Professional services fees get added to the cost of the software to come up with the final costs.
Hurdle rate or cost of capital
The final component we need to gather is the hurdle rate or cost of capital. This is essentially the value of the opportunity costs for a business. The idea of the cost of capital is that if the company didn’t invest in our project, they could invest in other projects and expect that level of return. For example, as of January 2020, the total market weighted average cost of capital hovers around 6%. This means that for the average company, on a weighted average cost of capital basis, the return of our purchase should be higher than 6% every year for the investment to be worth it.
Most companies will have an internal cost of capital, just ask Finance. If we want to calculate that value on our own, we can calculate our company’s weighted average cost of capital (WACC), which is a mix of our cost of equity and cost of debt, look up our WACC if our company is public, or use a similar public company’s WACC if our company is not public.
Now that we have all of the components, we can calculate ROI. ROI is the profit from an investment, which is the revenue and savings minus the cost of the investment per year, discounted back to today’s value using the cost of capital. For example, year three will be divided by one plus the cost of capital to the power of two. Here is the full equation for a four year investment.
Now we have our ROI for our software investment! Take it to finance and show them that investing in the software will return more than their hurdle rate by a high percentage. Data like that will speak volumes, especially if all of the components are backed by validated numbers.
Of course, if you want a more customized version, reach out to our sales team and they can create a much more detailed model for you to share with your procurement team.
Gremlin's automated reliability platform empowers you to find and fix availability risks before they impact your users. Start finding hidden risks in your systems with a free 30 day trial.sTART YOUR TRIAL
What is Failure Flags? Build testable, reliable software—without touching infrastructure
Building provably reliable systems means building testable systems. Testing for failure conditions is the only way to...
Building provably reliable systems means building testable systems. Testing for failure conditions is the only way to...Read more
Introducing Custom Reliability Test Suites, Scoring and Dashboards
Last year, we released Reliability Management, a combination of pre-built reliability tests and scoring to give you a consistent way to define, test, and measure progress toward reliability standards across your organization.
Last year, we released Reliability Management, a combination of pre-built reliability tests and scoring to give you a consistent way to define, test, and measure progress toward reliability standards across your organization.Read more