Writing a business case finance will fund

Technology proposals get deferred more often than they get rejected. Deferral is what happens when a reviewer cannot tell whether the numbers are real, and has an easier alternative in front of them.

Make the benefit land somewhere

The most common weakness is a benefit nobody can find afterwards. “Saves 400 hours a year” is not a saving unless something changes: a role not backfilled, contractor spend reduced, capacity redirected to specific work that would otherwise have been bought.

Say which line moves, by how much, and when. If the honest answer is that nothing in the budget changes and the benefit is capacity, say that — it is a legitimate case, argued on different grounds. What does not survive is an hours figure that implies a cost saving nobody will see.

State your assumptions and test them

Every number rests on assumptions: volume, adoption rate, error rate, price. Writing them down does two things. It lets a reviewer check the ones they know about, and it demonstrates that the number was derived rather than chosen.

Then show the sensitivity. What happens if adoption is half of what you expect? A case that still works at half is far stronger than one that is precisely right at full.

Include the run cost

Build cost alone is always wrong, and finance reviewers have seen enough proposals to know it. Licences, support, maintenance, the person who owns it, and — increasingly — usage-based consumption that grows with success.

Present three years. The first year usually flatters the case, and a reviewer who has to ask about year two has already lost confidence in the rest.

Name the alternative

Every proposal should state what else was considered and why it was not chosen, including doing nothing and including the cheapest option available.

This is the fastest way to establish credibility. A case with no alternatives reads as advocacy for a decision already made. A case that explains why the cheaper option was rejected reads as analysis.

Say what happens if it is not funded

Not as a threat. As a factual statement of consequence: the manual process continues at a known cost, the risk remains at a stated level, the system reaches end of support on a specific date.

Cases without this implicitly say nothing happens, which makes deferral free.

Write for the reviewer, not for your own function

A finance reviewer does not know your systems and is assessing several proposals. Lead with what it costs, what it returns, when, and what the risk is. Detail belongs in an appendix for the people who want it.

Jargon costs credibility, because it reads as a reason to defer to your judgment rather than as an argument.

The structural point

Finance is not the obstacle. It is allocating a limited amount of money across competing uses and needs comparable information to do it. A case that provides that information gets assessed on its merits — which is all a good proposal needs.