6.2 Core Workflows and Decision Points

When Each Product Appears

Management products are not created all at once. PRINCE2's seven processes each create or update specific products, and the exam often asks which process produces a given product.

The spine: Brief to PID

The Project Brief is created in Starting up a Project. It is a baseline that summarises what the project is, why it matters, and what is expected, including an outline Business Case and the Project Product Description. The Brief is deliberately lightweight — it exists to give the board enough to authorise initiation.

During Initiating a Project, the Brief is expanded into the Project Initiation Documentation (PID). The PID is the master reference for the project: it bundles the full Business Case, the Project Plan, the project controls, the roles, and all the management approaches. Crucially, the PID becomes the baseline against which the project's success is later assessed — at the end, the board compares actual results to what the PID promised.

Who Owns What, and the Reporting Chain

Ownership matters because the exam tests who is accountable for each product. The general pattern:

• The project manager creates and maintains most working products: the PID, Plans, Work Packages, Highlight Reports, End Stage Reports, End Project Report, Exception Reports, and the registers.
• The project board (Executive, Senior User, Senior Supplier) owns the Business Case at a governance level — the Executive is accountable for it — and approves baselines such as the PID.
• Team managers create Checkpoint Reports and deliver the products described in their Work Packages.
• Project assurance and project support help maintain quality and records but do not own decisions.

The reporting chain (memorise the direction)

Reports flow upward through defined channels:

1. Checkpoint Report — from team manager to project manager, at a frequency set in the Work Package. It reports team-level progress against the Work Package.
2. Highlight Report — from project manager to project board, at a frequency set in the PID. It lets the board manage by exception between stage boundaries.
3. End Stage Report — from project manager to project board at the end of each stage (via Managing a Stage Boundary), giving the board what it needs to authorise the next stage.
4. Exception Report — from project manager to project board when a stage or the project is forecast to breach tolerance. It is not a routine report; it is triggered by a forecast exception.
5. End Project Report — from project manager to project board at closure, reviewing how the project performed against the PID baseline.

Records run continuously

The Daily Log and Lessons Log open early and run throughout. The Risk Register, Issue Register, and Quality Register are created in Initiating and updated continuously as risks, issues, and quality activities arise. The Product Register tracks every product's status across stages. Unlike reports, these records are never "finished" until the project closes.

Decision Points the Products Support

Management products exist to support decisions, and the exam often frames a process question as a decision the board or project manager must make. Tie each major decision to the product that enables it.

Why the Business Case threads through everything

The Business Case is updated and re-verified at every major decision point. It is developed in Starting up, detailed in Initiating, maintained through every stage boundary in Managing a Stage Boundary, and confirmed during and after Closing a Project. The board's recurring question — "is this project still worth doing?" — is answered from the Business Case. This is why PRINCE2 calls continued business justification one of its core principles: if the Business Case ever fails verification, the project should be stopped, however far along it is.

Updating versus baselining

A subtle point the exam tests: baselines such as the PID and Business Case are updated at stage boundaries, but each update is itself re-baselined under change control. You do not casually edit a baseline; you create a new approved version. Records, by contrast, are updated freely without re-baselining. Knowing which products require formal re-approval and which can simply be amended is a frequent discriminator between two otherwise-similar answer options.