6.4 Business Case Application & Tailoring Scenarios

Tailoring Principles for the Business Case

The Business Case practice scales with the project. A six-week internal tool migration does not need a 40-page investment appraisal; a regulated safety-critical programme does. But tailoring changes the form and depth of evidence, not the discipline. Three rules hold at every scale:

1. The three tests (desirability, viability, achievability) are always applied — they can be answered in a paragraph, but they must be answered.
2. The Executive remains the single owner; accountability cannot be devolved to the Project Manager to 'keep it simple'.
3. The case is versioned and revisited at each stage boundary, even if the boundary review is a 15-minute conversation rather than a formal workshop.

For small projects the Project Brief may be the Business Case, with the Benefits Management Approach captured as a one-page table. For low-risk projects the risk section may be a short list rather than a register. The tests, the ownership, and the lifecycle checkpoints are the non-negotiables.

Worked Scenarios

Scenario A — Cost overrun breaches viability

A project to launch a customer self-service portal has a Stage Plan budget of £420k. At the stage boundary the Project Manager reports actual spend of £460k and a forecast next-stage cost of £180k against a planned £120k. The revised investment appraisal now shows payback slipping from 18 to 31 months, beyond the organisation's 24-month threshold.

Analysis. The Business Case is no longer valid because viability has broken — the cost trajectory pushes payback outside the accepted horizon. The correct response is not to re-baseline quietly and continue. The Project Manager raises an exception report, the Executive re-tests the three tests, and the Project Board chooses between (a) reworking the Business Case with a reduced scope that restores payback inside 24 months, (b) escalating for continued funding with an explicit tolerance waiver, or (c) premature closure. Letting the case drift invalidates the funding decision for every subsequent stage.

Scenario B — Sponsor wants to skip the Business Case

A new Senior User joins an in-flight project and argues that 'the Board has already approved the strategy, so a separate Business Case is bureaucracy'. They ask the Project Manager to drop the document and proceed straight to delivery.

Analysis. This is not an acceptable tailoring decision. Strategic approval at portfolio level is not the same as a project Business Case — strategy says what the organisation wants; the Business Case tests whether this project is the desirable, viable, achievable way to deliver it. Removing the Business Case removes the project's self-correcting control: there is no longer a documented justification to re-test at stage boundaries, so cost overruns and benefit erosion become invisible. The Project Manager should escalate to the Executive (the case owner) and to Project Assurance. A proportionate response is to lighten the case (one-page summary, simple payback appraisal), not to remove it.

Scenario C — Benefits not measured post-project

Twelve months after closure, a benefits review finds that three of the five benefits in the Business Case have no recorded measurement. The operational area argues 'we were never given a way to measure them'.

Analysis. The root cause is a missing or unused Benefits Management Approach, not a failure of benefit realisation as a concept. Each benefit should have had an owner, a metric, a baseline, a target, and a measurement timing captured at initiation and handed over at closure. The remediation is to reconstruct those attributes now with the operational owner, baseline from current data, and schedule the missing measurements. The lesson for future projects is to verify at Closing a Project that every benefit has a live owner and a measurement plan — a benefits review that finds nothing to measure means the practice was applied in form only.

Scenario D — Sustainability targets omitted

A public-sector project included carbon-reduction commitments in its funding bid but the Business Case filed at initiation lists only financial benefits. At stage 2 a Project Assurance review flags the gap.

Analysis. v7 expects sustainability/ESG targets to be recorded in the Business Case where relevant and tracked through a linked sustainability management approach. Commitments made to secure funding but not written into the case cannot be audited during delivery or reviewed at closure. The corrective action is to update the Business Case at the stage boundary to include the carbon-reduction target (with owner, baseline, measure, and timing) and to create the sustainability management approach, so the target is monitored with the same rigour as financial benefits for the remaining stages.