Business Case Structure
The argument format that gets technical investment funded — problem, options, quantified benefit, cost, risk and a recommendation.
Technical business cases fail on presentation more often than on merit. The recurring errors are leading with the solution, quantifying nothing, and offering a single option.
The structure that works:
The problem in business terms, with evidence. Not "our architecture is outdated" but "deployment takes three days, which delays every revenue-affecting change, and our change failure rate is 18%".
Options, including doing nothing. Presenting one option reads as advocacy. Including the do-nothing option with its cost — the cost of the status quo continuing — is what makes the case an analysis rather than a request.
Quantified benefit, in the units the audience uses: revenue, cost, risk reduction, or time. Where a number cannot be produced honestly, say so and give the mechanism, but produce numbers wherever they exist.
Cost, complete. Engineering time at a loaded rate, infrastructure, licences, training, and the opportunity cost. An under-stated cost destroys credibility for the next case.
Risks and mitigations, stated plainly. Omitting them invites the audience to find them, which is worse.
A clear recommendation. An analysis without one asks the audience to do the work.
Two things that raise the hit rate materially: align the benefit to a stated organisational priority, and propose a small first increment with a decision point, which lowers the size of the commitment being asked for.