6.3 Business Case Lifecycle & Management Products

The Business Case Across the Processes

The Business Case changes shape as the project moves through PRINCE2 processes. It starts as an outline inside another product, becomes a standalone management product, is re-verified at every stage boundary, and is closed out with a benefits review.

Management Products Involved

Three core management products carry the Business Case practice:

• Project Brief — the early product assembled in Starting Up a Project. It contains an outline Business Case, plus the Project Product Description, project definition, and the initial Project Plan. It is the input to Initiating a Project.
• Business Case — the standalone management product developed in Initiating a Project. It carries the full reasons, benefits, dis-benefits, costs, timescales, risks, investment appraisal, and (in v7) sustainability targets. It is updated at every stage boundary.
• Benefits Management Approach — created alongside the Business Case. It records how each benefit will be realised and measured: the benefit owner, the metric, the baseline measure, the target, the measurement timing, and how the benefit will be handed over to operational management.

The Benefits Management Approach in detail

A benefit that is not measured is a claim, not a benefit. The Benefits Management Approach forces every expected benefit in the Business Case to be paired with:

1. A named benefit owner accountable for realisation.
2. A measure (financial or non-financial) and a baseline value.
3. A target value and the timing of when it should be observed.
4. The mechanism for measurement (e.g., quarterly report, system telemetry).
5. An explicit handover to the operational area that will own the benefit after the project closes.

v7: Sustainability management approach

Where sustainability targets are recorded in the Business Case, v7 expects a linked sustainability management approach — a document that tracks the environmental and social commitments (carbon reduction, community impact, governance changes) with the same rigour as financial benefits: owners, measures, baselines, and review timing. This closes the gap between commitments made to secure funding and outcomes delivered after go-live.

What Happens at a Stage Boundary

Managing a Stage Boundary is the critical checkpoint for the Business Case. The Executive, supported by Project Assurance, must confirm the case is still valid before authorising the next Stage Plan. Concretely, the Project Manager updates the case with actual costs and benefits-realisation progress from the closing stage, re-runs the investment appraisal, and re-tests desirability, viability, and achievability. If the case no longer holds, the recommended action is exception or premature closure, not continued spending under an invalid justification.

Stage Boundary Walkthrough — A Concrete Example

Consider the stage boundary at the end of stage 2 of a customer-portal project. The Project Manager assembles the End Stage Report: actual costs were £460k against a £420k Stage Plan, 92% of planned products were delivered, and two open risks have been escalated. The Business Case is then updated — the investment appraisal is re-run with the new cost baseline, and payback moves from 18 to 22 months (still inside the organisation's 24-month threshold, but tighter than at initiation). Benefits-realisation progress from stage 2 is recorded against the Benefits Management Approach: one benefit (faster customer onboarding) is already showing a 15% improvement against its baseline measure. The Executive, supported by Project Assurance, reviews the updated case: desirability still holds (strategic alignment unchanged), viability holds (payback inside threshold), achievability holds (team capacity confirmed for stage 3). The Executive confirms the case is valid and the Project Board authorises the next Stage Plan. If payback had moved to 26 months instead, the Executive would request an exception assessment or recommend premature closure — the case would be invalid, and an invalid case cannot authorise further spending.

Exam Traps for the Business Case Lifecycle

• Confusing the Project Brief with the Business Case. The Project Brief is the container assembled in Starting Up; the outline Business Case is one component inside it. They are not the same document, and an option that says 'the Business Case is created in Starting Up' conflates the outline with the standalone product.
• Placing the Benefits Management Approach in Starting Up. It is created in Initiating a Project, alongside the standalone Business Case — not in Starting Up, where only the outline case exists inside the Project Brief.
• Treating stage-boundary verification as a rubber stamp. The Executive must actively re-test the three tests against current information; a stage boundary where the case is not re-verified is a process failure, not a valid tailoring choice.
• Assuming closure ends benefit tracking. The benefits review plan is handed over at closure; measurement continues post-project under operational ownership. The project's job is to set up the measurement, not to deliver every benefit itself.
• Forgetting the sustainability management approach. Where ESG targets are recorded in the Business Case, v7 expects a linked sustainability management approach with owners, measures, baselines, and review timing — an option that tracks only financial benefits is incomplete.
• Misnaming the closure review. At Closing a Project a final benefits review is performed and the benefits review plan is handed to operational owners; this is distinct from the ongoing benefits measurement that happens after the project has closed.