4.2 Developing, Verifying & Maintaining the Business Case

4.2 Developing, Verifying & Maintaining the Business Case

Practitioner Core Mandate: Business justification is never a one-time administrative hurdle cleared at project inception. Under PRINCE2 7, the Business Case is a living management product that evolves across defined lifecycle phases. It must be dynamically maintained, re-verified at every stage boundary, and guarded against the sunk cost fallacy by an accountable Project Executive.

---

The Lifecycle Progression of the Business Case Across PRINCE2 Processes

The development, verification, and maintenance of the Business Case is synchronized with the chronological progression of PRINCE2 processes. Each process performs specific governance checks on project viability.

                   THE BUSINESS CASE PROCESS LIFECYCLE

   PRE-PROJECT: Project Mandate triggers governance
         │
         ▼
   STARTING UP A PROJECT (SU)
   └─ Project Executive drafts Outline Business Case (supported by PM)
   └─ Confirms project is worth initiating before committing substantial spend
         │
         ▼
   INITIATING A PROJECT (IP)
   └─ PM develops detailed Business Case; Senior User commits to benefits
   └─ Baselined in Project Initiation Documentation (PID)
         │
         ▼
   CONTROLLING A STAGE (CS) ◄──────────────┐ Continuous Monitoring
   └─ PM monitors issues, risks, and      │ (Checks if tolerances
      costs against stage tolerances       │ are threatened)
         │                                 │
         ▼                                 │
   MANAGING A STAGE BOUNDARY (SB) ─────────┘
   └─ PM updates Business Case with actuals and revised forecasts
   └─ Project Board re-verifies Continued Business Justification
         │
         ▼
   CLOSING A PROJECT (CP)
   └─ PM drafts End Project Report assessing Business Case performance
   └─ Hands over updated Benefits Management Approach for post-project reviews

Detailed Process Interactions

1. Starting Up a Project (SU): The Outline Business Case

• Objective: Establish whether the project is worth initiating before committing substantial corporate funds to detailed planning.
• Action: The Project Executive drafts the Outline Business Case, drawing on the initial project mandate. If appointed early, the Project Manager assists the Project Executive in gathering data and structuring options.
• Content: Outlines the broad business rationale, initial options analysis (e.g., "do nothing", "do minimum", "do something"), preliminary cost and timescale expectations, and strategic alignment.
• Gate Decision: Submitted to the Project Board within the Project Brief during the Directing a Project (DP) process. The Project Board decides whether to authorize the initiation stage.

2. Initiating a Project (IP): The Detailed Business Case

• Objective: Build a robust, fully baselined business justification and investment appraisal that underpins the entire project commitment.
• Action: The Project Manager develops the detailed Business Case on behalf of the Project Executive. The Senior User specifies and validates that benefit targets are achievable; the Senior Supplier validates supplier cost estimates and technical deliverability.
• Content: Comprehensive investment appraisal (e.g., Cash Flow Projections, Net Present Value, Payback Period), refined cost and timescale estimates derived from the Project Plan, major risk assessments, quantified dis-benefits, and sustainability performance targets.
• Gate Decision: Integrated into the Project Initiation Documentation (PID). The Project Board reviews and formally authorizes the project during Directing a Project (DP).

3. Managing a Stage Boundary (SB): Re-verifying and Updating

• Objective: Formally confirm that the project remains desirable, viable, and achievable before committing organizational capital to the subsequent management stage.
• Action: The Project Manager updates the Business Case using actual figures from the concluding stage (costs, timelines, technical variances) and incorporates updated forecasts for the remaining stages, ongoing operational expenses, and revised benefits.
• Gate Decision: The Project Board reviews the revised Business Case alongside the End Stage Report and next Stage Plan. If continued justification is confirmed, the Board authorizes the next stage; if justification has collapsed, the Board instructs premature closure.

4. Controlling a Stage (CS): Continuous Review

• Objective: Maintain day-to-day vigilance over business justification as delivery activities unfold.
• Action: The Project Manager continuously evaluates incoming requests for change, off-specifications, operational problems, and new risks. If an event threatens to breach agreed Business Case tolerances, the Project Manager must immediately escalate via an Exception Report.

5. Closing a Project (CP): Final Evaluation & Operational Handover

• Objective: Benchmark final delivered performance against the original baselines and transition benefits tracking into business-as-usual operations.
• Action: The Project Manager prepares the End Project Report, documenting actual costs, delivery schedules, outputs delivered, and benefits already realized during delivery.
• Transition: The Project Manager updates the Benefits Management Approach, defining the schedule and resource requirements for post-project benefits realization reviews conducted by the business layer or operational line managers.

---

The PRINCE2 Technique for the Business Case: Develop, Check, Maintain, Confirm

PRINCE2 7 section 5.3.1 names a four-step technique for the business case, shown in figure 5.3. The words are precise and the exam uses them precisely:

The four points at which the project board must check the business case

PRINCE2 7 states these as a minimum:

1. At the end of starting up a project, to authorize project initiation.
2. At the end of initiating a project, to authorize the project.
3. At the end of each stage, to authorize the next stage and the continuation of the project.
4. When assessing an exception plan, to authorize the revised stage and the continuation of the project.

The project manager checks it more often: when assessing progress, risks, and issues for their impact on business justification; during the final stage as part of closing a project; and when consulting stakeholders about whether goals have changed — for example, whether the business has set additional sustainability objectives.

The three basic business options

Every options analysis starts from the same three: do nothing differently, do the minimum, and do something (the fuller investment). The "do nothing differently" option is the benchmark against which the others are judged. An option list that omits it is incomplete, and an exam scenario in which the board has never been shown what happens if the project stops is describing a governance gap.

Supporting techniques the manual names

Investment appraisal compares the costs of developing, operating, and maintaining the project product with the value of the benefits over a period, covering both project costs (producing the products and project management costs) and ongoing operations and maintenance costs. Named techniques include:

• Whole life costs — total implementation cost plus incremental transitional, operational, and maintenance costs.
• Net benefits — total benefit value minus implementation, transition, and ongoing operation cost, over a defined period.
• Return on investment (ROI) — profits or savings as a percentage of the initial investment.
• Payback — time to remunerate the investment of cash and other resources.
• Sensitivity analysis — used under check to see whether the business case is heavily dependent on one specific benefit; if it is, planning, monitoring, and risk management must actively protect that benefit.

The multi-case model evaluates an investment from four perspectives rather than financial return alone, and PRINCE2 7 says a robust investment should satisfy all of them:

• Strategic — the drivers for change, and how the investment demonstrates strategic fit.
• Economic — which option delivers best value, including wider social, environmental, and sustainability considerations.
• Financial — affordability, funding, budgeting, and cashflow over the life of the project and the project product.
• Implementation and commercial — that the preferred option can be delivered by the service providers available, with robust arrangements for delivery.

A business may add its own cases, such as an environmental case, with policies on how they are used.

Best, expected, and worst-case benefit ranges apply where delivery is iterative-incremental: with scope flexible and time and budget fixed, benefits are expressed as a range rather than a single target estimate.

---

The Nine Headings of the Business Case (A1)

The official sample papers include a matching question in which three items of scenario information must be filed under the correct business case heading. You have to know the list cold.

Four distinctions the exam pushes on

1. Expected benefits and dis-benefits are a single heading. Dis-benefits are not risks and are not filed with major risks — they are certain, measurable negative outcomes and they sit alongside benefits.
2. Sustainability targets are their own heading in Version 7. They are not folded into expected benefits and not left to the sustainability management approach alone. Note that both this heading and the benefits heading carry tolerances, which is why table 11.1 records benefits and sustainability project-level tolerances in the business case rather than the project plan.
3. Time is not the project schedule. Under this heading the business case records the period the project runs and the period over which benefits will be realized — which typically extends well past project closure.
4. Costs include operations and maintenance. A business case that prices only the project and ignores ongoing running costs cannot support a defensible investment appraisal. Watch for scenario options that compare a cheap build with an expensive one without whole-life costs.

[!CRITICAL EXAM RULE] Where a fact lands depends on its nature, not its wording. "Donors and partners must be engaged to secure the budget" is a reasons or costs/funding item, not an expected benefit. "Prosecutions will increase 20% due to increased police awareness" is an expected benefit because it is measurable against the pre-project situation. Read for the measurable-against-baseline test.

---

Governance Roles and Responsibilities in the Business Case Practice

PRINCE2 establishes strict separation of governance accountabilities. Confusing the roles of the Project Executive, Senior User, Senior Supplier, and Project Manager is a primary source of candidate error on the Practitioner exam.

                   BUSINESS CASE GOVERNANCE STRUCTURE

                          ┌─────────────────────┐
                          │  BUSINESS LAYER     │ Defines project tolerances
                          │     MANAGEMENT      │ & Strategic Priorities
                          └──────────┬──────────┘
                                     │ Commissioning & Governance
                                     ▼
                          ┌─────────────────────┐
                          │      EXECUTIVE      │ SOLE OWNER of Business Case;
                          │  (Business Interest)│ Accountable for Justification
                          └──────────┬──────────┘
                                     │
            ┌────────────────────────┼────────────────────────┐
            ▼                        ▼                        ▼
   ┌─────────────────┐      ┌─────────────────┐      ┌─────────────────┐
   │   SENIOR USER   │      │   PROJECT MGR   │      │ SENIOR SUPPLIER │
   │ Specifies &     │      │ Drafts, Models  │      │ Confirms Cost & │
   │ Validates Value │      │ & Maintains     │      │ Delivery Feas.  │
   └─────────────────┘      └─────────────────┘      └─────────────────┘
            │                        │                        │
            └────────────────────────┴────────────────────────┘
                                     │ Supported Independently by
                                     ▼
                          ┌─────────────────────┐
                          │  PROJECT ASSURANCE  │ Audits Viability & Model
                          │ (Business Assurance)│ Objectivity
                          └─────────────────────┘

Role Breakdown & Exam Distinctions

---

Business Case Tolerances & The Exception Mechanism

The Project Board governs by exception. While the Project Manager manages stages within delegated tolerances, the Project Board itself operates within Project-Level Tolerances established by the business layer.

Tolerances Governing the Business Case

1. Financial Cost Tolerance: Maximum allowable variance in total project capital or operational expenditure (e.g., approved project budget $2,000,000 with ±5% tolerance).
2. Timescale Tolerance: Maximum allowable variance against key milestone dates that directly affect commercial market entry or regulatory compliance.
3. Benefit Tolerance: Allowable threshold of under-realization for critical benefits (e.g., target operational savings of $500,000 annually with a -10% tolerance; anything below $450,000 triggers exception).
4. Payback / Return Tolerance: Maximum acceptable extension to the payback window (e.g., target payback 3.0 years, maximum allowable 3.5 years).
5. Sustainability Tolerance: Limits on environmental footprint, carbon expenditure, or energy usage thresholds.

                  THE EXCEPTION ESCALATION MECHANISM

   [Controlling a Stage (CS): Emerging risk, issue, or cost overrun detected]
                                 │
                                 ▼
   [PM calculates forecast: Will exceed agreed Stage or Project Tolerance]
                                 │
                                 ▼
   [PM creates EXCEPTION REPORT detailing options, impacts, & recommendations]
                                 │
                                 ▼
   [Project Board convenes in Directing a Project (DP) to review Exception Report]
                                 │
                 ┌───────────────┴───────────────┐
                 ▼                               ▼
   [Option A: Viability Maintained]   [Option B: Justification Collapsed]
   └─ Project Board instructs PM      └─ Project Board consults business layer
      to produce EXCEPTION PLAN          and instructs PREMATURE CLOSURE

Exception Report vs. Exception Plan

• Exception Report: Created immediately by the Project Manager during Controlling a Stage (CS) as soon as an agreed tolerance is forecast to be breached. It explains what occurred, analyzes the root cause, models the impact on the Business Case, presents evaluated options, and makes a recommendation. It does not replace the stage plan.
• Exception Plan: Created by the Project Manager during Managing a Stage Boundary (SB) only when explicitly requested by the Project Board after reviewing the Exception Report. An Exception Plan is a full-scale schedule and budget plan designed to replace the remainder of the current Stage Plan (or Project Plan). The Project Board must formally approve the Exception Plan before delivery resumes.

---

Scenario Evaluations: Loss of Justification & Mandatory Premature Closure

Under PRINCE2 7, when a project's business justification permanently evaporates, the project must be terminated prematurely. Continuing expenditure on an unviable initiative violates Principle 1 (Continued Business Justification).

The Sunk Cost Fallacy in Practice

A critical exam theme involves eliminating the Sunk Cost Fallacy. Sunk costs represent historical expenditure that has already occurred and cannot be recovered, regardless of future decisions.

$\text{Investment Viability Decision} = \frac{\text{Future Realizable Net Benefits}}{\text{Future Expenditure Required to Complete \& Operate}}$

If the future expenditure required to complete the project and operate the resulting asset exceeds the future realizable net benefits, the project must close immediately, regardless of whether $100,000 or $50,000,000 has already been spent.

Compulsory Premature Closure Governance Actions

When the Project Board instructs premature closure, the Project Manager does not simply abandon the site or delete project files. The Closing a Project (CP) process must be formally executed:

1. Orderly De-escalation: Instruct delivery teams and suppliers to stop work gracefully, stabilizing active technical environments and terminating supplier contracts in accordance with contractual terms.
2. Salvage & Preservation: Identify, test, and archive completed products or partial deliverables that hold salvageable commercial, technical, or intellectual property value.
3. Lessons Capture: Extract insights from the Lessons Log into a formal Lessons Report, analyzing why the project became unviable and what the business layer can learn to prevent future failures.
4. Handover & Residual Risk: Formally transfer completed products to operational management, record outstanding issues and residual risks in Follow-on Action Recommendations, and update the Benefits Management Approach.

---

Practitioner Exam Traps & Common Pitfalls

• Trap 1: The Project Executive Delegating Accountability to the Project Manager: Exam questions frequently describe a busy Project Executive who "delegates full accountability for the Business Case to the Project Manager due to the PM's superior financial modeling background." In PRINCE2 7, accountability cannot be delegated. The Project Executive remains solely accountable for business justification. The Project Manager merely acts as the author and operational custodian.
• Trap 2: The Senior User Abdicating Benefit Responsibility: Another frequent scenario trap portrays the Senior User as a passive reviewer who "attends meetings but states that achieving benefits is the Project Manager's job." Under PRINCE2, the Senior User is specifically accountable for specifying realistic benefits and committing operational resources to ensure those benefits are realized in business-as-usual.
• Trap 3: Nursing an Unviable Project (Sunk Cost Trap): When scenario narratives detail a project where market disruption has wiped out projected revenue, distractors will suggest "approving an emergency loan to finish delivery so past investments are not wasted." Always identify this as the sunk cost fallacy. PRNICE2 governance mandates premature closure when future costs exceed future benefits.
• Trap 4: PM Preparing an Exception Plan Unilaterally: When a tolerance breach occurs, an exam distractor often states that the Project Manager "immediately authored an Exception Plan to reschedule the remaining stage work." This is a severe process error. The Project Manager must author an Exception Report first. Only the Project Board has the authority to order an Exception Plan.