Technology proposals are easy to overstate because benefits such as “efficiency” and “better visibility” sound valuable without defining what changes in the operation. A stronger business case connects the proposed improvement to a baseline that can be tested.
That is harder than it sounds. Most systems proposals begin with a product, a vendor conversation or a frustration that has finally reached the leadership team. The business case is then written backwards: the decision has been made, and the document exists to justify it. A credible case runs the other way. It starts with an operating problem the organisation can observe, compares realistic options for addressing it, and states in advance how the decision will be judged.
Why systems business cases go wrong
The mechanisms are fairly consistent. Benefits are described in the vendor’s language rather than the organisation’s. Time saved is counted as money saved, even though nobody leaves and no cost disappears. Implementation is priced carefully while ownership is not. And the people writing the case are usually the people who want the project, which makes optimism structural rather than personal.
Public-sector appraisal guidance treats this as a known bias rather than a character flaw. HM Treasury’s supplementary Green Book guidance on optimism bias states that project appraisers tend to be over-optimistic, and asks for explicit adjustments to estimates of costs, benefits and duration based on past or similar projects. A private business does not need to adopt government method wholesale, but the principle transfers well: if your last three system projects ran late and delivered less than promised, the next estimate should reflect that history.
Start with the current operating cost
Describe the problem in measurable terms: repeated handling, delay, rework, error exposure, manual reconciliation, missed capacity, support effort or dependency on fragile workarounds. Not every cost needs to be converted into money, but every claimed benefit should have a clear mechanism.
A mechanism is the causal chain between the change and the outcome. “The new system will improve efficiency” has no mechanism. “Orders currently re-keyed into the finance system will flow automatically, removing a daily reconciliation step and the errors it introduces” does. The second version can be checked before and after. For a practical method of costing the work itself, see how to calculate the real cost of a repetitive task.
Illustrative example: a services business wants a new project management platform because “nobody knows where projects stand”. When the baseline is examined, the real cost is a weekly status meeting, a spreadsheet that three people update by hand, and invoices that go out late because completed milestones are not visible to finance. Those are measurable. The business case now has something to stand on, and it may turn out that an integration between existing tools addresses most of it.
Separate benefit types
- Hard cost: spend that can realistically be removed or avoided.
- Capacity: time that can be redirected, not automatically treated as cash savings.
- Risk: lower probability or consequence of operational failure.
- Service: faster, more reliable or more transparent customer outcomes.
- Enablement: capabilities required for later growth, automation or control.
Keeping these apart matters because they are realised differently. Hard cost appears in the accounts. Capacity only becomes value if someone decides what the freed time will be used for. Risk reduction is real but rarely visible until something does not go wrong. Enablement benefits are the easiest to inflate, because almost any platform can be described as a foundation for something later. A useful discipline is to ask, for each enablement claim, what specific later initiative depends on it and whether that initiative is itself approved.
Include the lifecycle, not just implementation
Account for configuration, integration, migration, testing, training, monitoring, maintenance, vendor dependency and change. A cheap implementation can become an expensive operating model if those costs are ignored.
The ownership costs are where many systems cases quietly fail. Licences rise with headcount. Integrations need someone to watch them. Data migrated from an old system brings its quality problems with it. Staff need training not once but every time someone joins. If the case does not name who will own the system after go-live, it has not yet priced it. Related reading: why technology spend does not automatically create business value.
Compare options, including doing less
The Green Book frames appraisal as assessing the costs, benefits and risks of different options. That word “options” is the part most commercial cases skip. A proposal with one option is a request for approval, not an appraisal. At minimum, compare the proposed change with improving the current process without new software, a smaller or phased version, and doing nothing for a defined period. Sometimes the cheaper option wins; sometimes it confirms the larger investment is justified. Either way, the decision is stronger.
Use scenarios rather than invented certainty
Model conservative, expected and upside cases. State assumptions explicitly and identify which measures will be checked after implementation. That turns the business case into a decision tool rather than a sales document.
The assumptions are often more useful than the totals. If the expected case depends on adoption by every sales team within three months, that assumption should be visible, because it is a risk the organisation can manage. HM Treasury’s Magenta Book makes a related point about evaluation: it should be built into a programme’s design from the earliest stages, not bolted on afterwards. For systems work, that means agreeing the baseline measurements before the project starts, while the old process still exists to be measured.
Warning signs
- The benefits section uses the vendor’s terminology and could describe any customer.
- Every hour saved has been multiplied by a salary rate and added to the total.
- Only one option is presented, or the alternatives are obviously weak.
- There is no named owner after go-live and no line for ongoing support.
- Nobody can say what result would show the decision was wrong.
A practical diagnostic
- Can we describe the current problem in operating terms that someone outside the project would recognise?
- Do we have a baseline measurement, or only an impression?
- For each benefit, what is the mechanism, and which benefit type is it?
- What will this cost to own over three to five years, not just to implement?
- Which options did we compare, and why did this one win?
- Which assumptions, if wrong, would change the decision?
- Who will check the outcome, when, and against what measure?
Trade-offs
Rigour has a cost. A small, reversible change does not need the same depth as a core platform replacement, and a business case that takes longer to write than the change takes to make is itself waste. Scale the effort to the size, duration and reversibility of the commitment. Equally, quantifying everything can push teams to ignore benefits that are real but hard to measure, such as reduced key-person dependency. The answer is not to force a number onto them, but to describe them honestly as qualitative and give them appropriate weight.
What better looks like
The organisation can explain the problem, why the proposed change addresses it, what it will cost to own, how value will be measured and what would invalidate the decision.
In practice, a good systems business case is shorter than expected, specific about mechanisms, honest about ownership costs and explicit about its assumptions. It compares real options. And after implementation, someone returns to it and checks. Where the underlying problem is not yet well understood, a structured Digital Systems Audit can provide the operating evidence the case needs, and an architecture and roadmap can help sequence the options.
Sources and further reading
- The Green Book (last verified 10 October 2026)
- Green Book supplementary guidance: optimism bias (last verified 10 October 2026)
- The Magenta Book (last verified 10 October 2026)
Related Mellorca reading
- How to decide what technology problem to solve first
- How to separate urgent systems problems from merely annoying ones
- How to buy business software without letting the demo make the decision