Every software proposal promises a return. Many include a neat table showing hours saved, errors avoided and a payback period of a few months. Few of those tables survive contact with reality, and most owners know it. The result is a familiar cycle: the business case is written to get approval, then quietly forgotten once the project starts, and nobody can say afterwards whether the investment was worth it.
There is a better way. Measuring the return on software honestly is less about clever formulas and more about choosing a few things you can actually observe, recording them before you start and checking them afterwards. This article sets out a practical method.
Why most ROI figures are unreliable
- Borrowed numbers. Industry averages and vendor claims describe someone else's business, not yours.
- No baseline. If you did not measure the current process, any "improvement" is a guess.
- Hours saved that never turn into money. Saving two hours a day for a clerk only has value if that time is used for something else, or if hiring is avoided.
- Costs left out. Licences and development are counted; training, data cleaning, internal staff time, support and hosting often are not.
- Benefits counted twice. The same improvement appears as "faster reporting" and "better decisions".
If you cannot measure it before the project, do not claim it after. A smaller number you can defend is worth more than a larger one you cannot.
Step 1: Name the problem in measurable terms
Start with the specific pain the software is meant to remove, and express it as something you can count or time. For example:
- Month-end closing takes a certain number of working days.
- Purchase approvals take a certain number of days from request to order.
- A certain number of shipments each quarter are delayed or sent by air because of late material.
- Stock counts differ from the system by a certain value at each count.
- A certain number of staff hours each week are spent preparing a specific report.
Two to four measures are enough. Choose ones the business already cares about, and that the software can plausibly influence.
Step 2: Measure the baseline
Before anything changes, record the current figures over a representative period, ideally a few weeks or a full month-end cycle. Use existing records where possible: approval dates in emails, dispatch logs, stock count sheets, overtime records. Where records do not exist, time the work directly with the people who do it.
Write down how each figure was measured. If you cannot repeat the measurement in the same way later, the comparison will not be fair.
Step 3: Count the full cost
Include everything, over a realistic period such as three to five years:
- Development or licence fees.
- Implementation, data migration and integration.
- Hardware, devices and hosting.
- Internal staff time for discovery, testing, training and go-live.
- Support, maintenance and future changes.
- Temporary disruption during the switch-over.
Internal time is the cost most often ignored. Senior people spending days in workshops and testing is a real investment, and should be planned for.
Step 4: Convert benefits carefully
Not every benefit needs a taka value, but those that do should be calculated conservatively and with the finance team's agreement. Three categories are useful:
Hard savings
Costs that will actually stop: overtime no longer needed, air freight avoided, a planned hire not made, write-offs reduced, fines or penalties avoided. These are the strongest part of a business case.
Capacity released
Time freed for people to do more valuable work. Value it only if you can say what that time will be used for. Otherwise, report it as capacity rather than money.
Risk and quality
Fewer errors, better audit readiness, faster answers to buyers, less dependence on one person. These are real but hard to price. Describe them honestly in words, and do not inflate them into large figures.
Step 5: Set review points and check
Agree in advance when you will measure again, for example three, six and twelve months after go-live, and who will do it. Use the same method as the baseline. Then compare:
- Did each measure move in the expected direction, and by how much?
- Were the costs in line with the plan?
- Did hard savings actually appear in the accounts?
- What unexpected benefits or problems appeared?
If a measure has not improved, ask why. Often the software works but the process has not changed: people still keep the old register, or approvals still wait for a signature on paper. That is useful information, not failure.
A simple payback calculation
For many mid-size investments, a payback period is clearer than a full ROI model:
- Total cost over the first year, including internal time.
- Monthly hard savings you are confident of, after go-live.
- Payback period equals total cost divided by monthly hard savings, plus the months taken to go live.
Show capacity released and risk reduction alongside, as supporting evidence rather than as part of the calculation. A decision-maker can then judge the softer benefits for themselves.
Questions to ask about any business case
- Where did each number come from: our own records, or someone else's?
- What is the baseline, and how was it measured?
- Which savings will appear as lower costs in our accounts?
- What internal time is assumed, and from whom?
- When and how will we check the results?
Where RAED fits
During discovery we help clients define the measures that matter, record a baseline and estimate costs fully, so the business case can be checked after go-live. We would rather agree a modest, measurable goal than promise a figure nobody can verify.
