3.2 Core Workflows and Decision Points

Business Case — Is It Worthwhile?

The Business Case practice establishes mechanisms to judge whether the project is, and remains, desirable, viable, and achievable — the three tests of continued business justification. The Executive owns the Business Case (though they may delegate its drafting to the Project Manager or business assurance).

It evolves through defined points: an outline Business Case is created in Starting Up a Project, the detailed Business Case is produced in Initiating a Project, and it is reviewed at every stage boundary. PRINCE2 7 uses a four-step technique — develop, check, maintain, confirm — and three standard business options: do nothing (the baseline), do the minimum, and do something.

Outputs, Outcomes and Benefits

Distinguish the benefits chain: a project creates outputs (the products), which enable outcomes (the change), which deliver measurable benefits (and possibly dis-benefits). The Benefits Management Approach, also owned by the Executive, defines how benefits will be measured — often after the project closes.

Organizing — Who Does What

The Organizing practice defines the project's structure of accountability and responsibility. It recognises three project interests that must all be represented on the Project Board: business (value for money — the Executive), user (will use the products — Senior User), and supplier (provides resources/skills — Senior Supplier).

PRINCE2 defines four levels of management: corporate/programme/customer (outside the project), directing (Project Board), managing (Project Manager), and delivering (Team Managers). A key rule: the Executive and Project Manager roles cannot be shared or combined, although other roles may be.

Quality — Fit for Purpose

The Quality practice captures the user's requirements and defines how products will meet them. Two activities are separated: quality planning records acceptance criteria and quality tolerances in Product Descriptions and the Quality Management Approach; quality control then checks products and logs results in the Quality Register. The product register/Quality Register tracks every quality activity from planned to complete.

Plans — How and When

The Plans practice facilitates communication and control by defining the products to be delivered and the means to deliver them. PRINCE2 mandates product-based planning: identify products first (via a Product Breakdown Structure and Product Descriptions), then the activities. Plans exist at three levels — Project Plan, Stage Plan, and Team Plan — with an Exception Plan replacing a plan that is forecast to breach tolerance.

How These Four Practices Interlock

The first four practices are not independent silos; PRINCE2 deliberately chains them. The Business Case justifies the project and names the benefits. To realise those benefits, the Quality practice defines what 'fit for purpose' means through acceptance criteria in each Product Description. The Plans practice then sequences how those products will be built, and the Organizing practice assigns the people accountable for building and approving them. A weakness in any one weakens the others — for example, vague acceptance criteria make it impossible to prove the Business Case benefits later.

Project Assurance and Project Support

Two Organizing roles are commonly tested. Project assurance is the Project Board's independent check that the project is being run properly — it covers the three interests (business, user, supplier assurance) and cannot be delegated to the Project Manager, because the Project Manager is the very person being assured. Project support is an optional administrative function (tracking products, maintaining registers, configuration management) that can be performed by the Project Manager if no one else is available.

Product-Based Planning Steps

The Plans practice uses a defined product-based planning technique. Memorise the sequence:

1. Write the Project Product Description (the overall end product and its acceptance criteria).
2. Create the Product Breakdown Structure (a hierarchy of all products).
3. Write Product Descriptions for each identified product.
4. Draw the Product Flow Diagram (the sequence and dependencies of creating products).

Only after products are identified are activities, dependencies, and resources added. The exam trap here is starting with activities or a Gantt chart — PRINCE2 always starts with products, reflecting the principle focus on products. The Project Product Description is created during Starting Up a Project, while the detailed Product Descriptions are produced as plans are developed.

Finally, note that the Quality Management Approach and Digital and Data Management Approach are agreed during the Plans/Quality work and become part of the PID. The planning horizon principle explains why detailed plans only cover the immediate stage: it is impractical to plan distant work accurately, so PRINCE2 plans the current stage in detail and the rest of the project at a high level, refining each stage plan as its boundary approaches. This is why a Stage Plan is produced near the end of the previous stage, during Managing a Stage Boundary, rather than all at once at the start.