Introduction
PRINCE2 management products help the project management team plan, manage, and control the project. They may be documents, presentations, spreadsheets, or some other output created by a software tool. They can take any form suitable for the needs of the project, such as paper, electronic, verbal, or even written on an ‘information radiator’ written on a whiteboard.
There are three types of management product in PRINCE2. These are baselines, reports, and records.
Management products are created and maintained within the PRINCE2 processes. The responsibilities for creating, maintaining, and approving them is described in the PRINCE2 practices.
When preparing for your exams to get your PRINCE2 certification, be aware that for the PRINCE2 Foundation you must be able to recall the purpose of each management product. For PRINCE2 Practitioner, you must demonstrate how each of management product can be tailored to a specific scenario.
In the PRINCE2 manual, the management products are listed in detail in Appendix A. For a full set of templates for the management products, these can be downloaded from the PRINCE2 templates page.
Baseline management products
Baseline management products are those that define aspects of the project and once they have been approved, are subject to change control. Usually, baseline products have a version number assigned to them to identify the baseline.
Most baseline management products evolve during pre-project and during the initiation stage. The baseline management products of PRINCE2 are described below. Many of these form part of the project initiation documentation (PID) which is also indicated below.
- Benefits management approach
- Business case
- Change management approach
- Communication management approach
- Commercial management approach
- Digital and data management approach
- Issue management approach
- Plan (project, stage, team, exception)
- Product description
- Project brief
- Project initiation documentation
- Project product description
- Quality management aproach
- Risk management approach
- Sustainability management approach
- Work package description
Benefits management approach (part of PID)
The purpose of the benefits management approach is to identify the benefits management actions and reviews that will be performed to ensure the outcomes of the project will be achieved, and to confirm that the benefits are realized.
Business case
A business case contains all the information needed for the business to decide whether the proposed project is desirable, viable, and achievable.
A business case serves as the continual rationale for the project, and its validity must persist throughout the entire project life cycle. Typically, the outline business case is developed by the executive, and then is refined in more detail by the project manager during the project’s initiation phase, who then maintains it throughout the project’s duration.
Change management approach (part of PID)
A change management approach serves as a blueprint for the target organizational state required for the project to meet its objectives and describes how the business will move from the current state to the future state.
Communication management approach (part of PID)
The communication management approach describes the communications with stakeholders, both inside and outside the project, throughout its duration. The approach fosters stakeholder engagement by orchestrating a structured and two-way exchange of information.
Commercial management approach (part of PID)
A commercial management approach describes any processes, standards, and techniques to be used, and the responsibilities for commercial management, including things such as procurement and contract management.
Digital and data management approach (part of PID)
A digital and data management approach describes how data will be managed across the project, and after the project closes.
Issue management approach (part of PID)
An issue management approach describes the processes for managing issues, and how changes to the project baseline will be controlled.
Plan (project plan, stage plans, team plans, exception plans)
A plan provides an overview of the objectives, how they will be achieved, when they will be completed, and with what resources. A plan outlines the scope of the work, the products to be delivered, and the activities and resources responsible. PRINCE2 recommends three levels of plan – project plan, stage plan(s), and team plan(s).
Product description
Product descriptions are created during planning. They are attached into plans and are written at the level of detail required by the plan. For example, for a team plan, a product description will be detailed, but for a project plan, it will not contain the same level of detail.
A product description is often written for each product contained with a product breakdown structure.
Project brief
The project brief is a short summary of the project and is used by the project board to authorize the initiation stage of the project. It is assembled during the starting up a project process by the project manager. The project brief is then used in the initiating a project process as the basis for creating the project initiation documentation.
If you are familiar with the PMBOK® Guide, the Project Charter serves a similar purpose as the project brief.
Project initiation documentation
The project initiation documentation (PID) defines the project and enables the project board to evaluate the overall performance of the project. It outlines the project scope and direction and with the stage plan forms the ‘contract’ between the project manager and project board.
Project product description
There is one project product description which outlines the main deliverable created by the project. It is created by the project manager with the help of the senior user and describes what the project will deliver to gain acceptance.
Quality management approach (part of PID)
A quality management approach lays out the strategy for ensuring quality throughout the project. It includes specific quality processes, methods, standards, and responsibilities for quality activities. The quality management approach is established in the project initiation stage, and forms part of the project initiation documentation.
Risk management approach (part of PID)
A risk management approach defines the procedures for risk management and covers how risk will be identified, assessed, controlled, and communicated in the project, and the responsibilities for performing risk management activities. The risk management approach is established in the project initiation stage, and forms part of the project initiation documentation.
Sustainability management approach (part of PID)
The purpose of the sustainability management approach is to identify the actions, reviews and controls needed to ensure that sustainability performance targets for the project are achieved.
Work package description
A work package description is an agreement between the project manager and a team manager about what work is to be done by a team to deliver the required products. A work package description contains one or more product descriptions, the specialist techniques to be performed, tolerances for cost, time, scope, and risks, and the reporting requirements for the team manager.
A work package description passes formal responsibility for the delivery of products to a team manager. It forms the interface between the business, represented by the project manager, and the supplier, represented by the team manager.
Reports
Reports form snapshots of progress containing information about the status of the project at a point in time. There are seven reports recommended by PRINCE2, but depending upon how the method is tailored, fewer may be used on a project. The recommended reports are described below.
- Checkpoint report
- End project report
- End stage report
- Exception report
- Highlight report
- Issue report
- Lessons report
Checkpoint report
A checkpoint report is written by a team manager to report the progress of a work package to the project manager. It summarises the progress compared to what was agreed in the work package description. The format and frequency of checkpoint reports are agreed when the team manager accepts a work package from the project manager.
The checkpoint report is used by the project manager to update the progress within the current stage plan.
End project report
The end project report is created during the closing a project process by the project manager. The project board uses it to evaluate the project before authorizing its closure. It summarizes project performance by comparing it to the targets in the baseline project initiation documentation.
It also confirms the products have been accepted by, and delivered to, the users and summarizes any lessons learned during the project.
End stage report
Every time a management stage (except the final stage) reaches its end, the project manager creates an end stage report. This compares the performance of the current stage against the targets in the original stage plan. It summarizes current issues and risks, any benefits realized so far, and contains a forecast for the next stage.
The end stage report (and the next stage plan) contains all the information the project board needs to decide whether to continue or close the project.
Exception report
The project manager creates an exception report when requested by the project board in a situation when a stage plan or project plan is forecast to exceed its tolerances. The report provides options for resolving the exception and recommends the best way to proceed. The information it contains is used by the project board to decide its next steps.
Highlight report
A highlight report is written by the project manager at a regular interval during a stage. It contains a summary of the stage progress. The report summarises progress during the period it is reporting and gives early warning of any issues which might cause exceptions in the future.
The highlight report enables the project board to ‘manage by exception’ between each stage end.
Issue report
For every issue in the issue register, an issue report is created by the project manager to describe in detail the issue.
An issue report contains information to uniquely identify the issue, its type, the date raised, the person who raised it, the impact assessment on the project targets, the actions to resolve it, the person(s) responsible for these actions, and the closure date.
Lessons report
A lessons report documents any lessons that might be of value later in the current project, or to future projects. It is created by the project manager either at the end of a stage, and/or at the end of the project.
The purpose of a lessons report is to initiate actions to enable the organization (or project) to avoid any negative lessons in the future and to embed any good lessons within the organization’s or project’s ways of working.
Records
Records are dynamic management products used to maintain regular status information about the project. Records do not need to be kept under version control because they are continuously updated to reflect project progress.
Collectively, these are referred to as the project log and contain the items listed below.
Project log
The project log is used to record all the continuously changing information about issues, lessons, products, quality, and risks, and any other informal actions or events. Because it is dynamic it contains both the current and historic record of project progress.
Daily log (part of project log)
The daily log is used by the project manager to record notes, any informal issues, notes, and information not captured in the other management products.
Team managers may also have their own daily log to record information about their work package.
Issue register (part of project log)
An issue register is used to capture and manage formal issues. An issue register contains information such as unique issue identifier, type of issue, date raised, raised by, description, status, and closure date.
Lessons log (part of project log)
The lessons log records all useful experiences (both the good and the bad) that might be useful later in this project, or to other projects. Information from the lessons log is incorporated into lessons reports.
Product register (part of project log)
The product register is a list of the products required for a plan and their status.
Quality register (part of project log)
The quality register records all the quality activities during the project that have been planned or completed. A quality register contains information such as unique identifier for the quality activity, product identifier, quality method, activity dates, responsibilities, the activity results, and any further records associated with the activity.
Risk register (part of project log)
The risk register captures and maintains information about all the project’s risks. It contains information such as unique identifier for the risk, description, probability, impact, proximity, velocity, risk response(s), risk owner, risk action owner, and relevant dates.
