Call 1300 950 251     Follow us :

How Do You Write a Business Case That Gets Approved?

How Do You Write a Business Case That Gets Approved?

How Do You Write a Business Case That Gets Approved?

Tuesday, 18 August 2026

A business case gets approved when it gives the decision maker something they can defend later. That means an evidenced problem, a genuine range of options including doing nothing, costs and benefits with the uncertainty shown rather than hidden, and named owners for the benefits after approval.

Key takeaways

  • Write for the approver’s accountability, not to sell. The question they are answering (at least in their own mind) is whether they could defend this decision in three years.
  • The most common weakness auditors find is that the preferred option was actually chosen before the analysis, leaving the options assessment unconvincing.
  • Single point cost estimates read as naive. Show the range, name the assumption driving the number and test what happens if it moves.
  • Match the depth of the case to the size of the decision. Over specification wastes money and signals poor judgement.

What is a business case actually for?

To start with an example; two proposals reach the same investment committee. The first runs to ninety pages, opens with a preferred solution and spends the remainder justifying it. The second runs to twenty, opens with the problem and what it costs to leave the problem alone, then compares four options against that base, one of which is doing nothing at all. The committee approves the second and sends the first back for options analysis. The first document was better written. It was not a business case.

The distinction matters because a business case is not a persuasive document, whatever it feels like to write one. It is the record that allows an approver to explain the decision later to an auditor, a board, a minister or a journalist. When people say a case was approved, what they usually mean is that somebody was willing to attach their name to it. That is a different test from whether the argument was compelling on the day.

Reframing the reader changes what goes in. The question stops being whether the proposal sounds convincing and becomes whether the reasoning survives being examined by someone who was not in the room and who already knows how these things tend to turn out. Everything below follows from that shift.

Why do business cases get rejected?

The reasons are consistent and mostly structural rather than presentational. Asked by a parliamentary committee to identify common weaknesses across its audits, the Audit Office of New South Wales listed several. Programs and projects announced before a business case was developed had little or no opportunity to consider a genuine range of options, and the process used to eliminate other options was not transparent. Some major programs and procurements began without a business case or economic analysis at all. Objectives were often unclear. Costs and risks were underestimated, and where risks had been identified they frequently were not quantified, so nobody could see what they would do to the case.

Read as a group, most of those failures share one root. The answer arrived before the analysis, and the document was assembled afterwards to support it. Approvers and auditors are unusually good at spotting this, because it leaves a signature: a shortlist of options where the alternatives are obviously unserious, a base case that nobody would ever actually choose, a benefits section that grew to match a cost that was already fixed. The remedy is not better writing. It is doing the options work before deciding.

Why are the numbers in a business case usually wrong?

Cost and benefit estimates are not randomly inaccurate. They are wrong in a consistent direction, and the pattern has been measured. Bent Flyvbjerg, Mette Skamris Holm and Søren Buhl examined 258 transport infrastructure projects worth roughly US$90 billion and found that the cost estimates used to decide whether to build were systematically understated rather than scattered either side of the outcome. The authors argued that strategic misrepresentation explained the pattern better than honest error, a causal claim later researchers have contested, though the underlying pattern of underestimation is not seriously in dispute.

Whatever the cause, the practical consequence for a writer is the same: the person reading your case has seen this before and is discounting accordingly. A confident single figure now reads as naive rather than authoritative. A case is more credible, not less, when it shows the range rather than the point, names the one or two assumptions the whole number rests on, and demonstrates what happens to the conclusion if those assumptions are twenty per cent out. Stating your uncertainty is how you signal that you looked for it.

What should a business case contain?

There is an accepted Australian structure, and following it removes most arguments about format. The Department of Finance sets out the essential elements of a business case in the Commonwealth Investment Framework, adapted from Infrastructure Australia guidance. First, identify the problem or opportunity with evidence: its scale expressed in monetary terms where possible, its timing, and its underlying causes rather than its symptoms. Second, analyse options, starting from a wide longlist including a base case and narrowing to a shortlist through a documented process. Third, develop the shortlisted options in detail, covering costs, benefits, delivery and risks for each.

The ordering is the substance, not the bureaucracy. Problem first, options second, preferred option last, which is the reverse of how most rejected cases are built. Infrastructure Australia applies the same logic across its staged assessment process, requiring problem definition and options analysis to be completed and assessed before a business case is developed at all. Adopting that sequence has a side benefit worth having: if the problem cannot be evidenced, you find out before spending months on the solution.

How do you make the benefits credible?

Benefits are the weakest section of most business cases, because they are the part nobody owns once approval is granted. The Finance guidance asks pointed questions on exactly this: for each benefit component, how was the benefit estimated, what are the characteristics of the underlying demand model, what sensitivity analysis was undertaken, and what is the post completion review approach. That last question is the one that separates a credible case from an optimistic one, because it commits the proposal to being checked.

Practically, every benefit should carry four things: a measure, a baseline, a date at which it will be assessed, and a named person accountable for delivering it. A benefit without an owner is a hope with a dollar sign attached, and experienced approvers read it that way. It is also worth separating benefits that release cash from benefits that release time, because the two are frequently added together and only one of them shows up in a budget.

How much detail does a business case need?

Proportionality is now an explicit policy concern, because over specification has a cost of its own. In September 2024 NSW Treasury overhauled its business case rules, raising the threshold for recurrent proposals from $10 million to $20 million, allowing lean business cases or short form assessments for lower risk proposals, and shifting detailed procurement and technical work to after approval rather than before it. The Treasurer noted the changes would have avoided more than 1,200 business cases over the preceding five years, and pointed to $134 million spent on business cases for two dams, at Dungowan and Wyangala, that were never built.

The lesson for anyone writing one is to match depth to the size and risk of the decision. Ninety pages behind a $200,000 proposal does not signal rigour, it signals an inability to judge what matters. The disciplined version is short: a problem the reader can see, options they would recognise as a real set, a preferred option with its costs and risks stated at the accuracy actually available, benefits with owners, and an honest account of what would make you stop.

The recurring difficulty is that most people writing a business case are experts in the thing being proposed rather than in the reasoning an approver needs, and they do it perhaps once every few years, which is not often enough to get good at it. That gap is what AcademyGlobal (AG) built its Building a Credible Business Case training around, working through the structure using the proposal participants are actually preparing, so the options analysis and the benefit measures get tested before a committee tests them.

One question is worth asking before you submit anything. If this decision were reviewed in three years and the project had not been fully delivered, would this document make the approver look careless or reasonable? Write for that reader.

Frequently asked questions

What is the difference between a business case and a project plan?

A business case argues whether something should be done and which option is best. A project plan sets out how the chosen option will be delivered. Confusing the two is a common reason cases are sent back, since detailed delivery planning belongs after approval, not before it.

Do you have to include a do nothing option?

Yes, and it should be a real analysis rather than a formality. Australian guidance consistently requires a base case, because every other option is measured against it. A base case constructed to look obviously unacceptable is one of the clearest signals that the preferred option was chosen first.

How long should a business case be?

As long as the decision warrants and no longer. Australian jurisdictions are actively moving towards lean or short form business cases for lower risk proposals, having concluded that over specification wastes money and slows decisions. Depth should track the value and risk of what is being proposed.

Who should write the business case?

Someone close enough to the problem to evidence it, working with whoever will be accountable for the benefits afterwards. Outsourcing the whole document tends to produce a case the organisation cannot defend under questioning, and several Australian jurisdictions are deliberately bringing this work back in house.

What makes a business case fail at approval?

Most often a weak options analysis, because the preferred option was settled before the work began. Close behind are unquantified risks, benefits with no owner or measure, and costs presented as a single confident figure. Presentation problems are rarely the real cause of rejection.

References

Audit Office of New South Wales (2024). Answers to additional supplementary questions, Public Accounts Committee. Parliament of New South Wales.

Australian Government Department of Finance. Developing a Business Case. Commonwealth Investment Framework.

Flyvbjerg, B., Skamris Holm, M. K. and Buhl, S. L. (2002). Underestimating Costs in Public Works Projects: Error or Lie?. Journal of the American Planning Association.

Infrastructure Australia. Assessment Framework Stage 3: Developing a business case.

NSW Treasury (2024). Business case overhaul to fast-track key infrastructure proposals. NSW Government.