3.1 Continued Business Justification

What the principle means

Continued business justification — restated in PRINCE2 v7 as "ensure continued business justification" — requires that a project has a justifiable reason to start and a justifiable reason to continue at every subsequent decision point. A one-off approval at initiation is not enough: the justification is a living argument that is re-tested whenever the Project Board is asked to authorise the next management stage.

The justification lives in the Business Case practice. Two primary outputs carry it:

The Business Case is not a static artefact: it is updated at each stage boundary with actual spend and revised benefit forecasts, so the board always sees the current, not the original, case.

Why the business case drives the project

A common failure pattern is the reverse: a project starts, a team forms, and the business case is written afterwards to justify work already under way. PRINCE2 forbids this — the business case drives the project, not the other way round. Without a justifiable case there is no Starting Up a Project, no Initiation, and no mandate for the Project Board. The Executive (the role accountable for the business case) must confirm the case is viable before the project can be authorised.

Application in exam scenarios

At the Practitioner level the principle is tested at Bloom's Level 4 (analysis). Expect scenarios such as:

• A Project Board that continues authorising stages even though the projected benefits have collapsed by 60%. The correct analysis is that the board is violating continued business justification and should consider premature closure.
• A sponsor asks whether to stop or continue when a regulatory change has removed the original driver. The answer is to re-evaluate the Business Case at the next stage boundary (or via an exception) and, if the case no longer holds, recommend premature closure — not "complete what we have started".
• A question on when justification is checked: at Starting Up a Project (outline case), at Initiation (detailed case), and at every stage boundary thereafter.

Stop versus continue

PRINCE2 is explicit that stopping a project is a legitimate, controlled outcome — not a failure. Premature closure is the recommended response when the business case is no longer justified. Continuing "to protect sunk cost" is the anti-pattern the principle is designed to break.

The key analytical move is to separate the project's purpose from the team's momentum: if the purpose is gone, momentum is irrelevant.

Investment appraisal and the Business Case

The Business Case is not just narrative; it carries the numbers the board uses to judge justification. PRINCE2 expects the case to include an investment appraisal using one or more standard techniques:

The selected technique must be applied consistently at each stage boundary so the board compares like with like. A case that was justified on NPV at initiation must be re-tested on NPV at stage 2 — not silently switched to payback because the NPV has turned negative.

Output benefits versus outcome benefits

A second trap the exam probes is confusing output benefits (the project's products) with outcome benefits (the change those products create for the business). A project that delivers a new CRM system has produced an output; the benefit is only realised when sales staff actually use it to close more deals. The Business Case must argue the outcome, and the Benefits Management Approach must show how the outcome will be measured post-hand-over. A scenario that claims benefits are "delivered" at project closure because the product works is conflating output with outcome and fails the principle.

Worked scenario: SaaS migration

A finance director approves a SaaS migration with a Business Case showing £1.2m cost, £2.8m benefits over three years (NPV positive at £0.9m). At the stage 2 boundary the actual cost is £0.9m but the vendor has raised subscription fees; revised benefits fall to £1.4m and NPV turns negative. The Project Manager updates the Business Case and presents the End Stage Report. The correct board action is not to authorise stage 3 on the original case — the case must be re-justified or the project moved to premature closure. A board that waves the stage through "because we are already £0.9m in" is applying sunk-cost logic, which PRINCE2 explicitly rejects.

Exception path when justification fails mid-stage

If the business case is undermined between stage boundaries — for example a competitor launches the same feature for free — the Project Manager raises an Exception Report rather than waiting for the next boundary. The board then takes a decision (respond, re-plan, or premature closure) through the exception mechanism. The principle therefore bites continuously, not only at scheduled boundaries: the Project Board is never obliged to wait for a stage end before re-asserting continued business justification.

Common traps

• Treating the Project Brief as the justification. The Brief is an input to initiation; the living justification is the Business Case.
• Assuming benefits are realised at hand-over. Realisation is tracked through the Benefits Management Approach after the project closes.
• Letting the Executive update the Business Case alone. The PM drafts the update; the Executive owns the case and presents it, but assurance and Senior User input on benefit realism are required.