PRINCE2 2017 Management Products Reference
Use management products as controlled decision information, not paperwork: baselines define what is authorised, records preserve live evidence and reports summarise the right information for the next management interface.
Executive summary
Baselines and approaches
These define the authorised project, products, plans and management methods against which work is controlled.
Records
Registers, logs and configuration records preserve current detailed evidence for issues, risks, quality, lessons and product status.
Reports
Reports package information for a management interface or decision, such as checkpoints, highlights, exceptions, stage ends and closure.
Tailor the form, keep the function
The source permits integration with organisational tools and different formats; what matters is that the required purpose, ownership and decision information remain available.
How to use this reference
The supplied 2017 material introduces management products across the seven themes and seven processes rather than as isolated templates. Their value comes from how they support decisions and control. A plan establishes a baseline. A register maintains live detailed evidence. A report summarises selected information for a management interface. An approach explains how a discipline will be managed.
The method can be tailored so the information may live in documents, workflow systems, dashboards, registers or integrated corporate tools. A “management product” should therefore be understood primarily as a defined set of information with an owner and purpose. Creating separate files for every item is not inherently better management.
This page consolidates the products evidenced across the supplied source. Detailed content should still be tailored to project context and organisational standards, and the source material—not this summary—remains the boundary for any edition-specific requirement.
Project definition and justification baselines
| Management product | Primary purpose in the supplied material | Key lifecycle use |
|---|---|---|
| Project Brief | Consolidates the early project definition produced during start-up, including approach, outline justification, initial team information and Project Product Description. | Used by the Project Board to decide whether to authorise initiation. |
| Business Case | Explains why the project is justified, including need, costs, timescales, benefits, dis-benefits and risks. | Developed from outline to detailed form and reviewed/updated at key decisions and stage boundaries. |
| Project Initiation Documentation (PID) | Integrated baseline for how and why the project will be managed and delivered. | Assembled during initiation and used by the Board for project authorisation and subsequent control. |
| Benefits Management Approach | Defines expected benefits/owners, measures, baselines, timing and review arrangements. | Created/refined during initiation, reviewed during the project and updated for post-project benefit reviews at closure. |
| Project Product Description | Defines the overall project product and customer acceptance basis. | Created early, refined during initiation and used to support acceptance and closure. |
These products answer different questions. The Project Brief asks whether there is enough definition to initiate. The Business Case asks whether the investment remains justified. The PID establishes the management baseline. The Project Product Description describes the overall output and acceptance basis. The Benefits Management Approach explains how results will be measured after products are used.
Combining them into one corporate project record is possible, but do not merge their decision purposes. A single “project charter” that says what will be built but omits benefit review and management controls would not preserve the same functionality.
Management approaches
| Approach | What it defines | Important interface |
|---|---|---|
| Risk Management Approach | How threats and opportunities will be identified, assessed, responded to, owned, reviewed and communicated. | Risk Register, Business Case, progress reports and exception decisions. |
| Change Control Approach | How issues, baselines, configuration information and change authority will be controlled. | Issue Register/Reports, product status and authorised baseline updates. |
| Quality Management Approach | How quality control, project assurance, quality communication and responsibilities will operate. | Product Descriptions, Quality Register, quality/approval records and acceptance. |
| Communication Management Approach | Who needs project information, what they need, format, frequency and timing. | Checkpoint/Highlight reporting, stakeholder communication and closure notification. |
The source builds these during initiation so the project does not invent control rules after problems arise. The approaches should use organisational policies and systems where suitable and should be reviewed when project context changes.
An approach is not the activity itself. A Risk Management Approach may say how risks are scored and reviewed; the Risk Register contains the actual project risks. A Quality Management Approach defines how quality will be managed; the Quality Register records planned and completed quality activities.
Plans and Work Packages
| Product | Control level | Purpose |
|---|---|---|
| Project Plan | Whole project | High-level baseline of major products, management stages, timing, cost and resources used by the Project Board. |
| Stage Plan | Current management stage | Detailed baseline for day-to-day Project Manager control and stage tolerances. |
| Team Plan | Optional team level | Detailed specialist plan used by a Team Manager for one or more Work Packages. |
| Exception Plan | Replacement project or stage baseline | Replaces the plan forecast to exceed tolerance after upper management requests and approves replanning. |
| Work Package | Project Manager–Team Manager interface | Authorised information/agreement for creating one or more products within constraints and tolerance. |
These products implement progressive planning and delegation. The Project Plan does not need current-stage task detail. The Stage Plan should be detailed enough to manage the stage. A Team Plan is optional because some delivery teams can control their Work Package without a separate formal plan.
Exception Plans are particularly important to distinguish from routine reforecasting. Approval creates a replacement authorised baseline. Work Packages sit below stage control and make specialist assignments explicit even when the Project Manager and Team Manager roles are combined.
Product descriptions and product status
The source uses two different description levels. The Project Product Description defines the overall project product, customer quality expectations, acceptance criteria, acceptance methods and responsibilities. An individual Product Description defines a controlled product’s purpose, composition, derivation and detailed quality criteria/methods/responsibilities.
Configuration Item Records maintain controlled information about product items and their state. A Product Status Account provides a snapshot of the status of products within a project, stage or selected area. Together they help answer “what exactly exists, in which version and state?” rather than relying only on task reports.
Product status becomes especially useful during progress review, change assessment, Work Package receipt and closure. If an Issue Report proposes a change to a product, configuration/product information helps identify the affected baseline and current version.
Registers and logs
| Record | Information purpose | Typical owner/use |
|---|---|---|
| Risk Register | Threats and opportunities, analysis, responses, ownership, status and history. | Maintained throughout the lifecycle for risk decisions and reporting. |
| Issue Register | Formal issues and decisions, including requests for change, off-specifications and other problems/concerns. | Supports issue/change control and traceability. |
| Quality Register | Planned and completed quality-management activities. | Supports product control, stage/end-project reporting and quality evidence. |
| Lessons Log | Lessons identified throughout the project. | Feeds immediate improvements and later Lessons Reports. |
| Daily Log | Actions, informal issues and observations that do not yet require formal register treatment. | Working record for the Project Manager. |
| Configuration Item Record | Controlled information and status for individual configuration items/products. | Supports product/version control and Product Status Accounts. |
Registers should remain live. A risk workshop that creates a register and never revisits it does not satisfy the management purpose. Likewise, a Quality Register should reflect actual planned and completed activities, not be reconstructed at stage end.
The Daily Log provides a useful lightweight capture route. Not every observation needs formal escalation. If a matter becomes material, it can move into the appropriate Issue or Risk Register without losing the original context.
Progress and decision reports
| Report | Direction of information | Use |
|---|---|---|
| Checkpoint Report | Team Manager → Project Manager | Periodic progress against a Work Package, including forecasts and concerns. |
| Highlight Report | Project Manager → Project Board | Periodic concise progress view for the project/stage while the Board manages by exception. |
| Exception Report | Project Manager → Project Board (or equivalent escalation level) | Event-driven escalation when a management-stage or project tolerance is forecast to be exceeded. |
| Issue Report | Project Manager / control system → authorised decision-maker | Detailed information about a formal issue requiring assessment/decision. |
| End Stage Report | Project Manager → Project Board/project team | Performance and status information supporting the decision whether to authorise the next stage. |
| End Project Report | Project Manager → Project Board | Evaluation information supporting closure authorisation. |
| Lessons Report | Project → organisation/future projects | Consolidated lessons for reuse and organisational learning. |
| Product Status Account | Control function → requester | Snapshot of product/configuration status for a defined scope. |
Reports should be generated from controlled underlying information where practical. A Highlight Report does not replace the Issue Register, Risk Register or Stage Plan; it summarises what the Board needs to know. An End Stage Report does not replace the next Stage Plan; the two are considered together for a continuation decision.
The distinction between time-driven and event-driven information is also useful. Checkpoint and Highlight Reports are typically periodic. Exception Reports are triggered by a forecast loss of tolerance. End Stage and End Project reporting occurs at defined lifecycle events.
A lifecycle map of management products
Start up
Mandate → Project Brief, outline Business Case, Project Product Description, Lessons Log, Initiation Stage Plan.
Initiate
Detailed Business Case, Project Plan, four management approaches, controls, Benefits Management Approach and PID.
Control stage
Work Packages, Stage Plan updates, risks/issues/quality/configuration records, Checkpoint and Highlight Reports.
Boundary
End Stage Report, next Stage Plan, updated Project Plan/Business Case/PID; Exception Plan when directed.
Close
Acceptance evidence, End Project Report, Lessons Report, updated Benefits Management Approach, follow-on actions and archived records.
Tailoring rules for practical information management
Use one source of truth where possible. If a corporate project system already stores risks, do not create a duplicate “PRINCE2 risk spreadsheet” simply to match terminology. Configure the existing system so it provides the information and ownership required by the Risk Management Approach and Risk Register purpose.
Merge products only when the merged format remains usable. A combined weekly dashboard can contain checkpoint and highlight views if audiences and permissions are clear, but a Team Manager’s detailed work information should not overwhelm the Board’s decision view. Similarly, an integrated PID can link to controlled plans and approaches rather than copy them and create version conflicts.
Make ownership explicit. Every important product should have someone responsible for maintaining it and defined events for review or update. Management products become bureaucracy when they have no decision owner, no update trigger and no connection to work. They become control when they are current, trusted and used.
Practical verification checklist
- Identify which management-product information already exists in organisational systems.
- Keep Project Brief, Business Case, PID, Project Product Description and Benefits Management Approach purposes distinct even if integrated.
- Define the four management approaches during initiation.
- Maintain the correct planning level for Project, Stage and optional Team Plans.
- Use Work Packages as explicit specialist-delivery agreements.
- Maintain live risk, issue, quality, lessons and configuration/product records.
- Use reports to summarise controlled information for a specific management interface or decision.
- Keep periodic Checkpoint/Highlight reporting distinct from event-driven exception and boundary reporting.
- Assign owners and update triggers for every important management product.
- Tailor format and tooling without losing purpose, traceability or authority.
Common mistakes to avoid
- Creating a separate file for every management product even when existing systems can provide the information.
- Combining products so aggressively that their decision purposes become unclear.
- Using reports as the only source of truth instead of maintaining underlying registers and baselines.
- Treating an Exception Plan as a routine updated plan.
- Letting registers become stale between governance meetings.
- Producing management products that no identified decision-maker actually uses.