Every enterprise technology project starts with an ROI case. A spreadsheet that projects the cost of the project against the revenue it will generate or the cost it will save. These documents are necessary - you can't spend $500,000 without justification. They're also, in my experience, largely fictional. Not deliberately. But the incentive structure around ROI cases produces documents that are optimistic to the point of being useless. We can do better.
What You Need to Know
- Most enterprise ROI cases overstate benefits and understate costs because the person writing them needs approval
- An honest ROI case includes a range of outcomes, not a single projection
- The most defensible ROI cases focus on cost avoidance rather than revenue generation
- A good ROI case is a decision tool, not a sales document
Why ROI Cases Are Fiction
The structural problem is straightforward. The person writing the ROI case wants the project approved. The ROI case needs to show a positive return. Therefore, the person writing the ROI case has a direct incentive to be optimistic.
Benefits get rounded up. "The new system could save 15-30 minutes per employee per day" becomes "the system will save 30 minutes per employee per day." Multiply by 200 employees, multiply by 250 working days, apply an average hourly rate, and you've got a $1.2 million annual benefit. Impressive. Also wrong.
Costs get rounded down. The vendor quote for the software is firm. The implementation cost is estimated. The change management cost is guessed. The ongoing maintenance cost is forgotten entirely. Training? Data migration? Integration with legacy systems? They're in the appendix as "estimated" figures that are typically 40-60% of actual.
75%
of major IT projects exceed their original budget
Source: McKinsey & Company, Delivering Large-Scale IT Projects On Time, On Budget, and On Value, 2012 (still cited in 2021)
What an Honest ROI Case Looks Like
Three Scenarios, Not One
Instead of a single projection, present three scenarios:
Conservative. Minimum realistic benefit. Maximum realistic cost. If the project is still worth doing under these assumptions, it's a strong investment.
Expected. Your best estimate. Be specific about the assumptions. "We estimate 15 minutes per employee per day based on the vendor's published case study from a company of similar size. We have not independently validated this figure."
Optimistic. Maximum realistic benefit. Minimum realistic cost. This is the number the CFO wants to hear. Label it clearly as the best case.
The range between conservative and optimistic is itself informative. A narrow range means the investment is predictable. A wide range means there's significant uncertainty that the decision-maker should weigh.
Separate Hard and Soft Benefits
Hard benefits can be measured directly. "The system eliminates three manual data entry roles at a total loaded cost of $180,000/year." That's verifiable. Either the roles are eliminated or they're not.
Soft benefits are real but harder to measure. "The system improves employee satisfaction" or "the system reduces risk." These are legitimate considerations. They're not ROI. Presenting them as ROI undermines the credibility of the entire case.
List soft benefits separately. Acknowledge their value. Don't put them in the spreadsheet.
The moment you put "improved employee morale" in the ROI spreadsheet and assign it a dollar value, you've lost credibility with anyone who understands financial analysis. They're just not measurable enough to be in a financial model.
Isaac Rolfe
Managing Director
Include Total Cost of Ownership
The project cost is year one. The total cost of ownership is years one through five. Enterprise software has ongoing costs that the initial ROI case consistently underestimates:
- Licensing. Annual or monthly. Usually escalating.
- Maintenance. Bug fixes, security patches, version upgrades.
- Integration maintenance. Every integration is a long-term maintenance commitment.
- Training. Initial and ongoing, as staff turn over.
- Support. Internal or vendor support contracts.
- Change management. The organisational cost of adopting new processes.
- Opportunity cost. What the team could be doing instead of maintaining this system.
A project with a two-year payback period on the initial investment might have a five-year payback period when total cost of ownership is included.
Typical Enterprise Software Total Cost of Ownership (5-Year)
Source: Gartner, Total Cost of Ownership Framework for IT, 2021
Cost Avoidance vs Revenue Generation
The most defensible ROI cases focus on cost avoidance. "Without this investment, we will spend $X on manual processes over the next three years" is more credible than "with this investment, we will generate $X in new revenue."
Cost avoidance is measurable. You can audit the current process, count the hours, apply a rate. The projection is based on observable data.
Revenue generation from technology investment is speculative. "The new e-commerce platform will increase sales by 20%" depends on market conditions, customer behaviour, competitive response, and a dozen other variables that the technology team doesn't control. It might be true. It's not a basis for financial planning.
The ROI Conversation We Actually Need
The real purpose of an ROI case isn't to predict the future. It's to make the decision-making process visible and honest.
A good ROI case answers:
- What specifically will this investment change?
- How will we measure whether it worked?
- What are the risks that could reduce the return?
- What's the total cost over five years, not just the project cost?
- What's the minimum outcome that still justifies the investment?
That last question is the most useful one. If the conservative scenario still justifies the investment, approve it with confidence. If only the optimistic scenario justifies it, think carefully about whether the risk is acceptable.
The ROI conversation doesn't need to be perfect. It needs to be honest. An honest case with a modest return is more useful than a fictional case with an impressive one.