Program Business Case: 7 Things Approvers Need to See

A program business case justifies a group of related projects together and commits the organisation to outcomes step by step. A project business case justifies one set of deliverables. A 2010 PMI Global Congress paper by Manon Deguire frames the difference this way: at program level the case supports decisions that progressively commit the organisation to outcomes or benefits, and at project level it supports commitment to outputs (PMI Learning Library).

HM Treasury's 2026 guidance, in its chapter on programme business cases, adds three points. The program case treats the constituent projects as a collective. It does not set out how to deliver each one. Each project usually still needs its own case, approved before it is delivered. And because projects start at different times, delivery runs in tranches (HM Treasury, Guidance on Developing Business Cases, 2026).

Our recommendation: use the program case to decide whether to start and how much to release. Leave detailed delivery options to the project cases.

Outcomes, not just outputs

An output is what the projects deliver, such as a system live in three plants. An outcome is the changed result, such as invoices collected faster and fewer disputes. The program case has to argue for the outcome. If it only lists outputs, the approver has nothing to hold the program to once the projects finish.

Business case vs program charter

The business case answers whether the organisation should fund the program. The charter authorises the program once that answer is yes. The case comes first and feeds the charter. For the charter's own questions, see our guide to the program charter.

A program business case is built during program definition, before the program is authorised, and it must stay live after approval. Projects start at different times, assumptions age, and most benefits arrive after delivery. A case that is approved once and then filed stops describing the program being run.

HM Treasury's guidance calls the program case "an iterative and living document". It runs from the start of the first project to the end of the last, and it is reviewed regularly to confirm the program is on track and still offers value for money (chapters 3 and 5).

Treat the approved version as the baseline. Record every later update as a dated revision that shows what changed and why. The sections below cover how those revisions are triggered at gates. The phases themselves are in our guide to the program management life cycle.

A funding committee typically needs seven things: the problem, the options, the cost, the benefits, the risk, the cost of inaction, and how delivery will be governed. The table below is a structure to adapt, not a download. Each row carries a test the approver is likely to apply.

Options: do nothing, do minimum and the preferred option

Do nothing is the baseline, and it is never free. HM Treasury's guidance requires the shortlist to include business as usual, a do-minimum option that only just meets the objectives, and the preferred option. It also warns against assuming the organisation does nothing, because business as usual still has costs, benefits and risks (chapters 7 and 8).

That baseline gives you the cost of inaction for the table above. For each option you set aside, say why in a sentence. In a program, the options are often about the mix and sequence of projects, such as two plants first instead of three. HM Treasury's guidance says program options should focus on the best mix of constituent projects (chapter 8).

Before approval, describe each benefit by its category, beneficiary, metric and baseline. HM Treasury's guidance asks for these four (chapter 7). We add a target, a date and a named business owner who will still be in post after the projects close.

The owner must sit in the business, not the program, because the benefit arrives after the program team has dispersed. Ask each owner to agree to the target in writing before the committee meets. A benefit with no owner who has accepted it is an easy line for a finance reviewer to challenge. This section covers claiming benefits before approval only. Tracking them afterwards, including the register and the handover at program closure, is covered in our guide to benefits realisation management.

Cash-releasing and non-cash benefits: how finance reads them

Finance reads benefits in four classes, and only the first changes the cash position. The guidance's examples (chapter 7) are public-sector, so the corporate reading below is ours.

• Cash-releasing: changes cash in or out, such as lower operating costs or higher fee revenue.
• Non-cash-releasing: has a money value but does not change cash, such as redeploying existing staff.
• Quantifiable: can be counted but not priced, such as satisfaction scores or staff retention.
• Qualitative: can only be described in words.

Our recommendation: put only cash-releasing benefits in the ₹ return, so the figure matches what finance can see in the accounts. List the other three beside it so the committee still sees them.

Ask the committee to approve the whole envelope, then release it in tranches. Each tranche is tied to a gate where the case is re-tested and the committee chooses to continue, change or stop. HM Treasury's guidance requires the program case to be reviewed and validated before each new tranche begins, and lets the approving authority review it at other points, such as the end of a tranche (chapter 5).

Releasing funding at gates

Write four things for every tranche: the amount, what it buys, the test that releases it and who releases it. Make tranche 1 small and make it buy evidence, such as a pilot. At each gate, judge the remaining spend against the remaining benefit. What has already been spent should not decide the vote. Once the tranches are approved, the program management plan sets out how each one is delivered.

Continue, change or stop

Continue when the re-forecast still meets the release test. Change when the forecast has moved, but a different scope or sequence still gives a positive case. Stop when the remaining spend cannot earn back its cost under any sensible re-shaping. Agree on the variance that triggers a re-test at approval, not at the gate, so nobody argues the threshold when the numbers are bad.

This example is illustrative. The program, the figures and the thresholds are invented to show the method.

A manufacturer asks for ₹18.0 crore over three years to consolidate order-to-cash across three plants. Order-to-cash covers the steps from receiving an order to collecting payment. The sponsor approves the envelope. Each plant is forecast to deliver ₹3.0 crore a year in cash-releasing savings once it is fully live. Funding is released as follows.

Our model, years 1 to 6, in ₹ crore. Spend is 6.0, 8.0 and 4.0 in years 1 to 3. Run cost is 1.0 a year from year 3.

Cash-releasing benefits are 0.5, 4.0, 7.0, 9.0, 9.0 and 9.0: the pilot plant goes live at month 3 and ramps up through its first year, and the other two plants go live between months 15 and 21.

Net cash flow is −5.5, −4.0, +2.0, +8.0, +8.0 and +8.0. Redeployed finance staff time is listed but not counted.

The model discounts year-end cash flows at an assumed 12%, with year 1 discounted one period. The net present value (today's value of those cash flows) is +₹7.00 crore, and cumulative cash turns positive in year 4.

Stress test. Scale every benefit down by the same percentage. At 10% below forecast, net present value falls to +₹4.60 crore and the pilot just clears the gate. At 20% below, it is +₹2.20 crore, but the pilot fails the gate. The case turns negative at about 29% below forecast: discounted benefits of ₹24.00 crore against discounted spend and run cost of ₹17.00 crore give a break-even of 71% of forecast. The gate is deliberately stricter than break-even, so the committee gets warning while change is still possible, for example by rolling out to one more plant and holding the rest. Stopping at Gate 1 would cap the exposure at the ₹3.0 crore already released.

Reviewers work from checklists, and a gap on the list is where a case stalls. HM Treasury's Annex A reviewer checklist covers a described baseline, a shortlist that includes business as usual and do minimum, sensitivity analysis, a funding statement with contingency, and governance and benefits arrangements.

NZTA's self-assessment questions ask whether the rationale for choosing among alternatives is clear, whether the options are feasible, and whether the benefit measures can be measured and attributed to the investment (NZTA).

Our inference: a case missing one of these gives a reviewer grounds to return it.

Run these checks before you submit.

This week, take your current draft and write the one-line release test for its first tranche. Then ask the person who will own the first benefit to sign its target. If either step is hard, the committee will find the same gap.

If you are moving from project to program work, Program Management Essentials is our foundation course for it. It is not exam preparation for a PMI certification. The price is US$99 per enrolment. A free eligibility consultation is available before you enrol.