What It Actually Means
For software it is a genuinely useful discipline and a genuinely unreliable number, and holding both of those at once is the practical skill.
Why The Number In The Proposal Is Usually Wrong
Software ROI calculations tend to be built on a time saving multiplied by a salary. Twelve hours a week saved, times an hourly rate, times fifty-two weeks, produces a large and satisfying figure.
The problem is what happens to the saved time. If the person now does higher-value work, the saving is real but it is not the number quoted, because their salary is unchanged. If nobody was going to be reallocated, no cash is released at all. The hours reappear as slack, absorbed into other tasks, and the business is better to work in without being measurably richer.
This is not an argument against building the software. It is an argument against believing the arithmetic, and against approving a project on the strength of a figure that nobody will revisit afterwards.
What Can Honestly Be Forecast
Some returns are firm enough to plan around.
Cash out that stops. A licence you stop paying, a temp you stop booking, a service you bring in-house. This is real money and it appears in the accounts.
Revenue that is currently being lost in a visible way. Orders that fail at checkout, enquiries that go unanswered past the point people buy elsewhere, work that cannot be taken on because a process caps throughput. Where you can count what is being lost now, you can reasonably forecast recovering some of it.
Cost of a known failure. If an outage, a compliance breach or a data loss has a describable cost and a plausible frequency, reducing that exposure has a value.
Capacity that unblocks growth. Harder to quantify, and often the largest. A business that cannot take on more clients without hiring has a ceiling, and software that raises it changes what is possible rather than what is cheaper.
What To Ask
- Does this release cash, or does it release time? Both are worth having. Only one appears in the bank.
- If it releases time, whose, and what will they do instead? An answer here converts a soft claim into a real plan.
- What are we losing right now that we can count? This is the strongest basis for any forecast.
- How will we check afterwards? Deciding the measure before you build is the only way the number means anything later.
The More Useful Question
For most businesses of moderate size, the honest framing is not a percentage return. It is whether the thing becomes possible.
Plenty of the best software decisions do not show up as a return at all. They show up as work that no longer depends on one person, a service level that can be promised without anxiety, or a capability that was not available before at any price. Those justify spending on their own terms, and forcing them through a return calculation produces a fabricated number that satisfies a process and informs nobody.
Where a return genuinely can be measured, it is worth doing properly: our guide on measuring ROI on custom software covers how to set the baseline before the build rather than reconstructing it after.
More terms are in the glossary.
