Software spend is uncomfortable to justify because the value is real but rarely lands as a single number on a single line. A machine has a price and a throughput; a piece of software has a price and a diffuse cloud of benefits — time saved here, an error avoided there, a customer kept who would otherwise have left. Leaders asked to sign off on the spend want a return they can defend, and the honest truth is that most of the difficulty is not in measuring the return. It is in deciding, before anything is built, what return you were buying in the first place.
Decide the measure before you build
The single most valuable thing you can do for the ROI of a software project happens before a line of code exists: name the outcome the project is supposed to move, and how you will know it moved. There are only a few honest shapes. Time saved — hours of manual work removed, translated into cost. Revenue enabled — sales you could not make before, or could not make fast enough. Cost or error reduced — fewer mistakes, less rework, lower spend on something the software replaces. Risk avoided — an outage, a compliance failure, a dependency on one irreplaceable person.
Pick the one or two that actually drive the decision and write them down as the reason the project exists. This is not bureaucracy. A measure chosen up front does two things at once: it tells you whether the project succeeded, and it tells the team what to optimise while they build. A project with no agreed measure cannot fail — which sounds comfortable until you realise it also means it cannot be shown to have succeeded.
An example shows how much the choice of measure changes the project. Two companies build what looks like the same internal tool. The first says the measure is hours saved in the finance team's month-end close; every design decision then bends toward removing manual steps, and success is a stopwatch anyone can read. The second builds the same tool with no agreed measure, and a year later cannot say whether it helped, because nobody wrote down what better would look like. Same software, same cost — one has a defensible return and one has an anecdote.
Acknowledge the benefits you cannot quantify
Some of the most important returns on software resist a number, and pretending otherwise fools no one. Speed — the ability to ship a change in a day instead of a quarter — compounds in ways no spreadsheet captures. Morale: engineers who are not fighting a brittle system do better work and stay longer. Optionality: a clean system lets you say yes to an opportunity that a tangled one would force you to decline.
The honest move is not to invent a euro figure for these. It is to name them explicitly, argue for them in plain language, and let the decision-maker weigh them knowingly. A board can absolutely fund a project whose main return is "we will be able to move faster on whatever comes next" — but only if you say that is the return, rather than manufacturing a fake number and hoping no one checks. Credibility is itself an asset, and false precision spends it.
Baseline before, measure after
You cannot show that something improved if you never recorded what it was like before. This is the step almost everyone skips, and its absence is why so many successful projects cannot prove they were successful. Before you build, capture the current state of your chosen measure: how many hours the manual process takes today, how often the error happens now, what the current conversion rate is, how long a change currently takes to ship.
The baseline does not have to be perfect. A rough, honestly-gathered number recorded before the work is worth far more than a precise one reconstructed afterward, because the reconstructed one is always suspiciously flattering. Then, after the software has been live long enough for behaviour to settle — not the week after launch, when everything is either novelty or teething — measure the same thing the same way. The comparison is your return, and it is only available to people who thought to take the first reading.
The discipline of baselining is easier than it sounds, and its payoff is disproportionate. Before a support tool is built, spend a week noting how many tickets an agent closes in a day and how long the average one takes. It costs almost nothing and it can be gathered by the people who already do the work. Skip it, and after launch you are left comparing the new number against a memory, and memory of how bad things used to be is the least reliable instrument in any business — it always improves the story in whichever direction the teller prefers.
Be honest about attribution
When the number improves, the temptation is to credit the software with all of it. Resist. Rarely is software the only thing that changed. The team also got better at the process, the market shifted, a pricing change landed the same quarter, seasonality did some of the work. Claiming the full delta for the software is how ROI cases lose credibility the moment a skeptic on the board starts pulling threads.
The stronger position is to state the improvement, then name the other plausible causes and explain why you still believe the software drove a meaningful share. Where you can, isolate: roll out to one team or region first and compare against one that has not changed. You will rarely get a clean laboratory result, and you do not need one. You need an honest estimate a reasonable person will accept — which is a far more durable thing than an inflated one that invites attack.
One practical habit keeps attribution honest: write down, at the start, the other things you expect to change in the same period. When the results come in, you already have the list, and you are grading yourself against a prediction rather than reverse-engineering a flattering story. It is a small act of intellectual hygiene, and it is the difference between an ROI case that survives scrutiny and one that only survives a friendly audience.
Why the lowest-cost build is not the best ROI
ROI is a ratio, and a ratio has two sides. The instinct under budget pressure is to shrink the denominator — build it as cheaply as possible — as if cost were the only lever on return. But the cheapest build routinely destroys the numerator. Software that is slow, unreliable, or unpleasant does not deliver the time savings, does not enable the revenue, does not avoid the risk — it just costs less to produce while producing less. A build that costs half as much and delivers a third of the value is not a bargain; it is a worse return dressed as a saving.
A worked comparison makes the false economy visible. One vendor quotes to build an order system for half the price of another. The cheaper one delivers something that works but takes fifteen seconds to load an order and drops one in a hundred under load. The staff route around it, keep the old spreadsheet alongside, and the time saving the project was bought for never arrives. The more expensive build loads instantly, loses nothing, and the team abandons the spreadsheet for good. The first cost half as much and returned nothing; the second cost more and paid for itself. Price was the visible number, and it was the wrong one to optimise.
The right question is never "what is the cheapest way to build this?" It is "what is the smallest investment that actually captures the return we identified?" Sometimes that is indeed a lean build. Often it is a little more than the minimum, spent precisely where the return lives — and refusing that marginal spend is how organisations optimise their way into a project that was affordable and pointless.
Tie scope to the outcome that pays
Once you know which measure justifies the project, scope becomes a tool rather than a negotiation. Every proposed feature can be tested against one question: does this move the measure we are being paid to move? Features that do are the core of the build. Features that do not — however appealing — are candidates to cut, defer, or fund separately with their own justification. This is how a project stays honest under the inevitable pressure to add "just one more thing."
Tying scope to outcome also protects the ROI from the slow inflation that kills it. A project that starts aimed at a clear return and accumulates unrelated features ends up expensive enough to sink the ratio even if the original core would have paid for itself handsomely. Guarding the link between scope and the paying outcome is the discipline that keeps a good idea from becoming a bloated one.
Frame it simply for a board
A board does not want a model with thirty assumptions. It wants a claim it can believe and interrogate. The simplest honest frame is three sentences: here is the measure and where it stands today; here is where we expect it to be, and why; here is roughly what that is worth against what it costs, with the softer benefits named separately and not dressed up as figures. State your confidence plainly — this part we are fairly sure of, this part is a judgement call. Numbers stated with false confidence invite a board to test them to destruction; numbers stated with honest uncertainty invite it to trust the person behind them. A board will fund a modest, credible return far more readily than a spectacular one it does not trust, because the modest one comes with something the spectacular one lacks: the sense that the people asking for the money have thought honestly about what it buys. That honesty is the real return, before a single feature ships.