Five workstreams, one business case: project or programme?

Test it against the definitions. A project is a temporary endeavour that delivers defined outputs to specific requirements; each workstream (data platform, loyalty, contact centre) individually satisfies that test, with its own lead, budget and deliverables. The entity actually being governed, however, is a set of interrelated components managed together to deliver benefits that no component can deliver alone: the benefits require the data platform and loyalty workstreams to be live simultaneously, under one business case and one funding envelope, with one board arbitrating priorities and dependencies. That coordinated, benefit-driven grouping is the defining characteristic of a programme.

It is not a portfolio. A portfolio is a collection of projects, programmes and other work that need not be related, managed together to optimise strategic objectives and resource allocation. Customer 360 would be one item inside Northwind's portfolio, not the portfolio itself.

What is lost by the 'big project' framing: the business case and benefits become nobody's accountability; dependencies between workstreams lose their management mechanism (hence the conflicting data model requirements); each component optimises its own budget line and can close early; and the board loses the consolidated view it needs to arbitrate. Classification follows how the work must be governed, not its size or vocabulary.

The request should be declined as formulated, but not by refusing closure altogether. Her deliverables are outputs, not benefits. Benefits arise in the receiving organisation after transition, and here they are conditional on a second workstream going live later. Reporting 'benefits delivered' in November would misstate the business case and break the benefit chain.

Correct handling:

• Close the workstream formally against agreed acceptance criteria: outputs verified, documentation handed over, residual issues and risks transferred with named owners.
• Maintain the dependency: a named interface contact and continued attendance (or a defined reporting line) at the board until the dependent workstream goes live and benefits can be tracked.
• Release people only under an agreed transition plan that shows which support obligations survive closure, and record those obligations in the closure documentation.
• Capture lessons from the workstream while the team is still assembled.

Judgement on the coordinator: the 'just a big project' position removes the only mechanism that manages the cross-workstream dependency and benefit realisation, and should not be accepted. The board, chaired by the sponsor, is the right place to record the decision and the residual obligations.

The business case is a living instrument, not an approval formality. It should be reviewed at decision points and whenever a material assumption changes. A nine-month delay in a component that gates the shared benefits is exactly such a trigger, and the review must cover the whole case, not just the affected budget line.

Steps:

1. Re-assess the shared benefits: timing, magnitude, and whether any remain achievable if loyalty is re-sequenced.
2. Quantify credible options for the sponsor and funding authority - re-sequence the rollout, re-scope the loyalty component, stop it, or accept reduced benefits - each with cost, schedule, risk and benefit consequences.
3. Make the decision at the level that owns the funding, record it, and update the business case, benefit profiles and the benefit owners in the receiving business.
4. Reflect the revised position in board and portfolio reporting so that funding decisions elsewhere are not made on stale claims; update the risk register with the consequences of the delay.

Why this matters: the exam-relevant point is that benefit accountability sits above the individual workstream, and a component manager cannot unilaterally restate the benefits of the whole.