“We need to do an ROI analysis.” I have either heard or said that phrase thousands of times throughout my career. I have performed hundreds of them — some extremely complex, some not as detailed, and even one on a Post-It note. It is likely you’ve had similar experiences. Return on investment analysis has become a key component of decision-making in business, mathematically confirming that the proposal is a good idea.
But it’s not just in business that ROI is used. As rational humans, we frequently look to justify some of the most important things in our life. We evaluate colleges and look at the starting salaries of graduates compared to the cost of attending. We do quick math to figure whether the tax deduction on mortgage loan interest will make buying a home cheaper than renting. I even had a co-worker tell me that the engagement ring he bought had gone up in value so it was a good investment (he had to be reminded that if he was put in a position to cash in on that gain, something else in his life had gone terribly wrong). More often than we realize, we use the principles of ROI as a logical justification to spending money.
So how do you perform a ROI for purchasing software?
Today’s business software tools usually aim to deliver some combination of the following benefits:
• Productivity- Automate the flow of a business process so that it takes less time to do it
• Centralization- Enable access to various information sources from one common point
• Visibility- Combine data sets to identify magnitude, trends, or cause-effect relationships
In deciding whether to buy the software, someone will inevitably ask for validation that the benefits are greater than the tool’s cost. But accurately predicting the future benefits of productivity, centralization, and visibility is most likely guesswork. And it is at that point where we begin making assumptions: This process currently takes 4 people 10 hours each; the tool will reduce that to taking 2 people 5 hours. Lack of visibility has meant our success rate is 20%; the visibility features in the tool will increase our success rate to 40%. And if the math still doesn’t pencil out, many times we just change the assumptions. And therein lies the danger of this approach- we focus on making the assumptions work rather than asking some very important questions.
Over-reliance on ROI analysis can create a false sense of security going into the purchase and unfulfilled expectations after the purchase.
Let me be clear — – I am by no means advocating relying solely on gut feel, or using the Star Wars “Force” to make decisions. Large purchases should be financially analyzed and verified. Speaking of Star Wars, can you imagine if the following exchange actually took place?
Imperial CFO: Um Darth, you have this budget item “Death Star?” You say it’s going to cost how much?
Darth Vader: [Sigh] You can’t put a price on galactic intimidation, Walter.
CFO: But still… is it going to generate more revenue for the Empire? I’m going to need an ROI analysis.
Vader: I find your lack of faith disturbing.
CFO: Is it just me or is it suddenly harder to breathe in here?
I am suggesting, however, that organizations also consider some non-analytical questions before heading down the numbers path and building an ROI case. Some of the questions may seem like common sense, but they surprisingly are often not part of the conversation:
- Is this tool addressing a mission critical part of my business, or is it more ancillary?
- Am I comfortable with the amount of people, effort, and steps that a process takes, or does it seem like it takes longer than it should?
- When asked by management, can I readily provide a synopsis of the issues and drivers, or do I scramble?
- When it’s time to make a decision, can I confidently use the data to intelligently make that decision, or do I have doubts?
The answers to the above questions may legitimize the need for a tool before an ROI analysis is performed. And then the ROI question becomes not one of whether to buy a tool, but one of which tool makes the most sense.
Lastly, in constructing the purchase analysis, it is good to rely on known or generally accepted data points and benchmarks instead of internal assumptions. Similar to a university providing graduates’ starting- salary averages, ask the software vendor to provide references to customers that can verify benefits of the tool. This establishes 3rd party data as the foundation of the analysis, and also enables the outcome of the analysis to be compared against the value that other tool purchasers have gained in the past. As a result, you will avoid a natural “confirmation bias” of building the ROI on unrealistic assumptions – and give you the confidence to know that your software purchase is indeed a good idea.
