The software ROI conversation is one of the noisier corners of enterprise IT. Vendor business cases overstate; internal business cases overpromise; and post-investment measurement rarely happens. This framework walks through the yield categories that make sense to measure, the attribution rules that hold the measurement honest, and the common errors that turn ROI into theatre.
Most software ROI claims fall apart on attribution. The yield categories that survive attribution are narrower than the categories vendors typically claim. In our experience working with CIO and CFO teams on post-investment ROI reviews, three yield categories produce measurable, defensible numbers.
The clearest category. The new software displaces existing spend — licensing fees, infrastructure, labour. The saving is observable in the run-rate and survives attribution because the displaced spend is unambiguous. Cost-displacement ROI is the strongest case for procurement; it is also the smallest yield category for most software investments.
Time saved per user per day, multiplied by user count and loaded labour cost. Measurable only when (a) the baseline time is captured pre-deployment, (b) the post-deployment time is tracked through usage telemetry, and (c) the time-saving converts to recovered capacity that is reallocated, not absorbed into slack. Most productivity ROI claims fail (c) — the time saved is real, but the recovered capacity is not reallocated, so the financial ROI is zero.
Revenue per customer, conversion rate, win rate or retention rate improvements attributable to the software. Defensible only when a controlled comparison exists — a holdout group, an A/B period, or a pre-deployment versus post-deployment trend that controls for other variables. Most revenue-yield claims fail the controlled-comparison test.
We design ROI measurement frameworks buyer-side. No vendor partnerships.
Attribution is where software ROI most commonly breaks. The four rules below are the ones we hold to in measurement frameworks for CFO clients.
Rule one — baseline must exist before deployment. Retrospective baselines (asking users to recall how long a task took before the new tool) are not measurement. They are recall, and recall is biased toward overstating the improvement.
Rule two — recovered time must be reallocated to be ROI. Time saved that is absorbed by the user (taking a longer break, doing more of the same task) is real but not financial ROI. The reallocation has to be observable.
Rule three — counterfactual comparison required for revenue claims. If the new software is one of three things that changed in the last twelve months, the ROI attribution is shared, not exclusive.
Rule four — total cost of ownership, not licence cost. Implementation, integration, training, change management, ongoing administration. Most software ROI calculations omit 40-60% of the true cost.
The governance patterns that hold software cost programmes — and their measured ROI — across multi-year cycles.
The seven most common ROI errors we encounter when reviewing post-investment numbers for CFO clients: (1) vendor business case adopted without independent restatement; (2) baseline reconstructed retrospectively; (3) productivity gains claimed without telemetry; (4) revenue gains claimed without controlled comparison; (5) TCO understated by 40-60%; (6) attribution shared across multiple concurrent initiatives but claimed exclusively; (7) measurement frozen in time at deployment, with no review cadence beyond month three.
The combined effect of these errors is consistent: business cases claiming 200-400% ROI routinely measure at 20-60% when restated honestly. The investments still typically clear the cost-of-capital bar — but the headline numbers carried into board reviews are noise rather than signal.
We restate ROI cases buyer-side for CIO and CFO clients. No vendor partnerships.
Weekly compliance intelligence for IT leaders.