PRINCE2 Management Products

PRINCE2 management products are the documents and records that a project creates, updates, and uses to control itself. They are not optional paperwork; they are the project's 'nervous system'. Without them, no one knows the budget, the schedule, the risks, or even the reason the project exists. PRINCE2 has roughly 26 management products, but the exam focuses heavily on about 8-10 key ones.

Every management product falls into one of four categories: baselines, records, reports, or the project mandate. Let us define those terms.

Baselines are documents that define what you plan to do. They are fixed in place once approved, and any change to them must go through a formal change control process. The four baseline management products are: the Project Brief, the Business Case, the Project Plan, and the Project Initiation Documentation (PID). For the exam, remember that the Project Brief is created in the 'Starting up a Project' process, and it is the initial skeleton of the project. Once you get approval, you develop it into the full PID during 'Initiating a Project'. The Business Case is the justification — it answers 'why are we doing this?' The Project Plan is the high-level schedule and budget for the whole project.

Records are documents that track what is happening in real time. They include the Risk Register, the Issue Register, the Quality Register, the Lessons Log, and the Configuration Item Records. A 'register' is a simple list. The Risk Register lists every identified threat and opportunity, their probability, their impact, and the planned response. The Issue Register lists any problem, question, or request for change that arises. The Quality Register tracks all the quality checks — inspections, reviews, tests — to prove the product actually works. The Lessons Log captures what you have learned so far (good and bad) so you can repeat successes and avoid mistakes. Configuration Item Records are like an inventory list of every single part of the final product (e.g., a software module, a document, a piece of hardware).

Reports are documents that communicate the project's status to specific audiences. The key ones are: the Highlight Report (sent to the Project Board regularly — typically weekly — to summarise progress, budget, and issues), the Checkpoint Report (created by the Team Manager to report progress to the Project Manager, often weekly), the End Stage Report (produced at the end of each management stage to summarise what happened and get approval to move to the next stage), and the End Project Report (produced at the end of the whole project to evaluate performance and close the project).

The Project Mandate is the initial trigger — it is just a one-page document from corporate management saying: 'We need a new website. Here is the idea. Invest something roughly like £100k.' It is not a management product you create; it is the input that starts the whole process.

Why does PRINCE2 have so many? Because it is designed for large, complex projects where dozens of people need to know exactly what is happening without constant meetings. Each management product has a specific purpose, a specific owner (the person responsible for creating or maintaining it), and a specific timing. For example, the Project Brief is created in 'Starting up a Project', reviewed and approved before 'Initiating a Project' begins. The Business Case is created during 'Starting up a Project' but refined during 'Initiating a Project' and then updated at every stage boundary.

In the exam, you will be asked to match a management product to its definition, its timing, or its owner. You will also see questions about which product replaces another — for example, the Project Brief is replaced by the Project Initiation Documentation once the project moves into the initiation stage. You must also know that the 'Business Case' is owned by the Senior User (the person who will use the final product) because they are the ones who will benefit (or lose out) if the project is not worth it.

A beginner's trap: do not confuse the 'Project Plan' (the whole-project, high-level plan covering all stages) with a 'Stage Plan' (a detailed plan for just one stage). The Stage Plan is also a management product, but it is created at the start of each stage, and it is owned by the Project Manager, not the Project Board.

Finally, remember that management products are living documents. The 'Risk Register' is updated whenever a new risk is identified. The 'Lessons Log' is updated whenever someone learns something new. The 'Quality Register' is updated when a quality check is completed. PRINCE2 expects you to keep them current, not file them in a drawer.

Meet Nadia, a Project Manager at a logistics company called 'SwiftShip'. The company wants to build a new mobile app for drivers. Nadia has never run a formal project before; she usually just sends emails. But her boss insists on PRINCE2 because the app budget is £1.5 million.

First, Nadia receives a 'Project Mandate' from the CEO: a single email saying 'We need a driver app. Here is the idea. Approve up to £50k for investigation.' Nadia uses this mandate to start the 'Starting up a Project' process. She writes the 'Project Brief' — a one-page document that says: 'The app will let drivers scan packages, log delivery times, and navigate. It will cost roughly £1.2 million. It will take 8 months.' She asks the Head of Operations (the Senior User) to write the 'Business Case' — a spreadsheet that calculates the app will save £300k per year in manual data entry costs, giving a payback period of four years.

Nadia presents the Project Brief and Business Case to the Project Board (the CEO, the Head of Operations, and the Head of IT). They approve it, and she moves to 'Initiating a Project'. Now she writes the 'Project Initiation Documentation' — the big plan. She creates the 'Project Plan' — a detailed Gantt chart showing design, coding, testing, and rollout over 8 months. She sets up the 'Risk Register' — listing risks like 'App crashes on Android 12' (high impact, low probability) or 'Driver resistance to new tech' (medium impact, high probability). She writes the first draft of the 'Quality Register', listing all tests: 'Unit test each module', 'User acceptance test with 20 drivers', 'Security penetration test'.

During execution, Nadia's life is reports. Every Tuesday, the development team gives her a 'Checkpoint Report' — a short email saying 'We completed the package scanning module. Next week: navigation. We are on budget.' Nadia then writes the 'Highlight Report' for the Project Board every Thursday — a one-page summary of progress, budget, and issues. She also updates the 'Issue Register' when a driver requests a new feature (voice input for the navigation). She logs that as an 'issue' and calls a change control meeting to decide whether to add it.

At the end of Stage 1 (Design), Nadia writes an 'End Stage Report' summarising what was delivered, what was spent (£180k vs planned £175k), and what lessons were learned (e.g., 'Design meetings take longer than expected; schedule bigger buffers'). The Project Board reviews this report and approves Stage 2 (Coding).

When the app is finally live, Nadia writes the 'End Project Report'. It states: 'The app was delivered on time and within budget. The driver training took an extra week. The quality checks passed. The app achieved 99.9% uptime in the first month. Recommend we do a similar architecture for the warehouse app next year.' She archives all management products in the company's SharePoint site for future reference.

Nadia did not just 'run a project' — she ran it with control. Every decision was recorded, every report was read, and every lesson was captured. If a new Project Manager took over, they could read the management products and understand exactly what happened.