Introduction
PRINCE2 specifies 26 management products. Management products in PRINCE2 can take any form. They can be documents, presentations, or spreadsheets. They can take any form, such as paper, electronic, verbal, or written on a whiteboard.
PRINCE2 classifies its management products into 3 types: baselines, records, and reports.
Management products are created within one of the 7 PRINCE2 processes. The responsibilities for creating, maintaining, and approving them is described in the 7 PRINCE2 themes.
All 26 management products are covered in detail in a PRINCE2 training course. For the PRINCE2 exams, PRINCE2 Foundation students need to learn the purpose of each of them. PRINCE2 Practitioner students are also required to demonstrate how each of the management products can be tailored on a project.
Baseline management products
What are baseline management products in PRINCE2?
Baseline management products are those that once they have been approved, are subject to change control. Typically, a baseline product will have a version number assigned to it. There are 12 baseline management products in PRINCE2 that are described below.
How many baseline management products does PRINCE2 recommend?
PRINCE2 recommends the use of twelve baseline management products on a project, but the number used in practice depends upon how the project is tailored to the project environment. The recommended records include:
- Benefits management approach
- Business case
- Change control approach
- Communication management approach
- Plan
- Product description
- Project brief
- Project initiation documentation
- Project product description
- Quality management approach
- Risk management approach
- Work package
Benefits management approach
The primary goal of the benefits management approach is to identify the benefits in measurable terms and, devise ways to measure them to demonstrate they have been achieved. Consequently, they are compared against baseline measurements taken at the start of the project to understand the quantity of benefits realised.
The benefits management approach necessitates details about the anticipated timeline for these benefits, namely, the timeframe within which the benefits are projected to materialize and can be quantified, and who will be responsible for compiling the data.
Business case
The business case compiles the information needed for the customer organization to decide whether the proposed investment in a project is desirable, viable, and achievable.
- Desirable means verifying the actual need for the products by weighing the benefits against the costs, timescales, and risks.
- Viable means evaluating if the project is feasible and if the organization possesses the capacity for delivery.
- Achievable means assessing whether the benefits can indeed be delivered.
A business case provides the ongoing business justification for the project, and it must remain valid throughout the project life cycle.
The executive usually creates business case, often with the aid of the project manager. The business case is created during starting up a project and is maintained throughout the project by the project manager.
Change control approach
A change control approach serves as a blueprint for determining how the project’s products will be managed and safeguarded throughout the project, encompassing both change and issue management. This strategy typically addresses the following aspects:
- Locations and methods for the project’s product storage.
- Security measures implemented for safe storage and retrieval of products.
- Methods used to identify different versions and variations of these products.
- Procedures for controlling modifications to products.
- Assignment of responsibility for configuration management.
Communication management approach
The communication management approach serves as a guide for coordinating communications with stakeholders, both inside and outside the project, throughout its duration. This approach covers things such as: the distinct stakeholder groups involved in the project, their stance towards the project, the format of information to be shared, the timing and frequency of communication, and so on.
The communication management approach fosters stakeholder engagement by orchestrating a structured and two-way exchange of information.
Plan
A plan provides an overview of objectives, how they will be achieved, and when they are expected to be completed. It outlines the scope of the project, the products to be delivered, and possibly the activities and resources necessary. Within the PRINCE2 framework, there are three distinct levels of plans:
- Project plan – This encompasses the entire project and is primarily utilised by the project board and the project manager.
- Stage plan – This covers a specific stage of the project and is used day-to-day by the project manager.
- Team plan – This covers a work package and is formulated and used by the team manager.
A project plan provides the business case with an estimated cost for the project. It also identifies the various management stages and other significant control points. The project plan serves as a baseline for the project board to monitor the project’s progress, facilitating questions such as “how are we performing relative to the baseline project plan?”
Stage plans detail the products to be delivered, the resources required, and sometimes even the activities, if necessary. They should also include specific controls used to display progress and enable higher-level monitoring against a baseline.
Team plans, which are optional, could merely consist of a schedule attached to the work package(s) allocated to the team manager.
PRINCE2 asserts that a plan should cover not just the activities needed to produce products, but also the managerial activities related to product creation, including assurance, quality management, risk management, configuration management, communication, and any other necessary project controls.
Product description
A product description is created when planning either the project, stage, or work package. They are incorporated into plans and should be written at the level of detail required by the plan. That means for a team plan, product descriptions will be detailed, but for a project plan, they can be high level.
A product description is typically crafted for each of the identified products in the product breakdown structure, if necessary. Here are some points to bear in mind when generating the product descriptions.
A product description serves to:
- Clarify the product’s purpose and its function.
- Identify who will utilize the product and possibly its method of use.
- Determine the quality standard expected of the product.
- Specify the skills necessary to create, review, and approve the product.
Project brief
The project brief offers a concise summary of the project, primarily intended for the project board. It serves as the foundational document for launching a project and is assembled during the starting up a project process by the project manager. The project brief is further utilized in the initiating a project process when it is expanded into the project initiation documentation.
In the context of the PMBOK® Guide, the closest equivalent to the project brief is the Project Charter.
Project initiation documentation
The project initiation documentation (PID) defines the project, enabling the project board to evaluate the project’s overall performance. The PID outlines the project’s scope and direction and, in combination with the stage plan, establishes the ‘contract’ between the project manager and the project board.
The PID serves three primary functions:
- Guarantee that the project is thoroughly understood before the project board commits substantial financial resources to the project to produce the deliverables.
- Function as a baseline document that allows the project board and project manager to evaluate progress, address issues, and contemplate ongoing viability.
- Serve as a comprehensive reference point for the project, enabling new members to easily understand the project’s purpose, the rationale behind it, the business justification, major risks, and how it is being managed and controlled.
Project product description
The project product description outlines the primary deliverable that the project will produce. Authored by the project manager with input from the senior user, it describes what the project must deliver to gain acceptance. The project product description is used to:
- Obtain consensus from the users regarding their desired outcome (project’s scope).
- Establish the customer’s quality expectations, enabling the project to produce a product that is ‘fit the purpose’.
- Determine the acceptance criteria, method, and responsibilities used to accept the product.
Quality management approach
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.
The quality management approach addresses these key points:
- The choice of quality management system to implement, i.e., from the customer, supplier, or a blend of both.
- The quality standards to be adopted.
- The tools and techniques to be employed.
- The methods for conducting quality assurance.
- The individuals responsible for documenting the customer’s quality expectations and acceptance criteria.
- The persons in charge of quality assurance, approval of the quality management approach, and confirmation of acceptance of the project product.
- The type of quality records to be maintained.
Risk management approach
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.
If a project is part of a program, then the risk management approach is likely to be provided.
Work package
A work package forms an agreement between the project manager and team manager about the work to be done by a team to deliver one or more products. A work package contains product descriptions for the products to be delivered, the specialist techniques to be used, tolerances for cost, time, and scope, and reporting arrangements for the team manager.
A work package passes responsibility for the delivery of products formally to a team manager. IT represents the interface between the customer, represented by the project manager, and the supplier, represented by the team manager.
Records
What are records in PRINCE2?
Records are used to maintain status information about the project on a regular basis. There is no need for these to be kept under version control because they are continuously being updated to reflect the current status.
How many records does PRINCE2 recommend?
PRINCE2 recommends the use of six records on a project, but the number used in practice depends upon how the project is tailored to the project environment. The recommended records include:
Configuration item record
Configuration item records are used only if mandated by the project’s change control approach. These records offer details such as the history, status, version, variant of each configuration item, and any relationships among them.
A collection of configuration item records for a project is typically known as a configuration library.
PRINCE2 does not specify the structure, format, presentation, or quality standards for these records.
Daily log
The daily log is used by the project manager to record informal issues, notes, and other information that is not captured in other management products. It is created during the starting up a project process.
A team manager may also have their own daily log to record information about their work package.
Issue register
An issue register captures and keeps track of all formal issues. It is regularly monitored by the project manager throughout the project. Typically, an issue register contains information such as issue identifier, issue type, date raised, raised by, description, status, and closure date.
Lessons log
The learn from experience principle in PRINCE2 mandates that the project team must learn lessons throughout the project. This requires that all useful experiences (both the good and the bad) must be recorded. The lessons log is used to do this.
Captured lessons may be acted upon by the project manager during the remainder of the project but can also affect a wider audience outside of the project itself.
Learned lessons should be applied to all the management activities within the project and should be addressed when planning and managing issues and risks.
During the project, lessons are transferred from the lessons log into reports which are sent to the project board. The project board can then disseminate these to a wider audience within the organisation.
Quality register
The quality register is a record of the quality activities that take place during the project, such as reviews, testing, and acceptance. The quality register provides a summary of all the quality management activities that are planned or have taken place and provides information for the end stage report and end project report. A quality register does four things:
- Provides an overview of the planned quality activities and provides a unique reference for each quality activity.
- Provides an overview on the status of all quality activities and a pointer to the quality records.
- And at the end of the project, it provides a history of all quality activities that have taken place and their results.
- Enables the project manager to review and control the quality activities during the project.
Risk register
The risk register captures and maintains the information about the project’s identified threats and opportunities. It provides a record of risks, including their status, probability, impact, proximity, mitigation activities, and details of the risk owner and actionee.
Reports
What are reports in PRINCE2?
Reports contain information about the status of the project at a point in time. They form a snapshot of the current progress.
How many reports does PRINCE2 recommend?
PRINCE2 recommends the use of eight reports on a project, but the number used in practice depends upon how the project is tailored to the project environment. The recommended reports include:
- Checkpoint report
- End project report
- End stage report
- Exception report
- Highlight report
- Issue report
- Lessons report
- Product status account
Checkpoint report
A checkpoint report is used by the team manager to report the progress of a work package to the project manager. It summarises the progress of the work done compared to what was agreed in the team plan. The frequency and format of checkpoint reports is agreed with the project manager when the team manager accepts a work package.
The checkpoint report is the primary way for the project manager to monitor and control the work done by teams.
End project report
The end project report is produced by the project manager during the closing a project process It is used by the project board to evaluate the project before it authorizes the project closure. It reports on the performance of the project compared to the targets set out in the baseline project initiation documentation, for example for cost, time, quality, scope, benefits, and risks.
It also confirms delivery and acceptance of the products to the customer and provides an overview of what went well and not so well.
End stage report
The end stage report is created by the project manager towards the end of the stage and compares the performance of the stage against the targets in the stage plan. It is used by the project board to decide whether to continue with, or close, the project.
The end project report provides the project board with information on the performance of the stage and the project status until that point. It includes a review of any benefits achieved so far and a review of issues and risks. The end stage report also contains a forecast for the next stage.
The project board uses the information in the end stage report and the next stage plan to decide whether to authorise the next stage or close the project.
Exception report
An exception report is written by the project manager when a stage plan or project plan is forecast to exceed its tolerance levels. It provides options for resolving the situation, and recommendations for the best way to proceed. It is then used by the project board to decide the next steps.
The three options to be considered include:
- Close the project because the exception means the project is no longer worthwhile.
- Re-plan the project and/or stage by adjusting scope, timescales, or costs. This requires an exception plan to be produced by the project manager.
- Grant a concession, which means continue with the current plan, but accept that the issue will remain.
Highlight report
The highlight report contains a summary of the stage progress. It is written by the project manager on a regular interval and is given to the project board for consideration. The frequency of highlight report is indicated in the communication management approach.
The report summarises progress during the period of the report and gives early warning of any issues which might in the future cause exceptions. It reports the status of the targets for time, cost, quality, scope, benefits, and risk.
The highlight report enables the project board to manage by exception between each stage end.
Issue report
An issue report describes in detail an issue being managed formally. There will be one issue report for every issue contained in the issue register.
An issue report contains information such as the unique identifier, issue type, date raised, the person who raised it, the impact assessment on the project targets, the actions needed to resolve it, the person(s) responsible, and the closure date.
Lessons report
A lessons report documents lessons that might be of value to future projects, or to the current project. A lessons report is created at the end of the stage during the managing a stage boundary process, and at the end of the project during the closing a project process.
The aim of a lessons report is to initiate actions so that the organization (or project) can avoid any negative lessons in future and can also embed the good lessons in the organization’s (or project’s) ways of working.
Product status account
The project’s change control approach will specify whether a product status account is required on a project. If it is, it is used to provide information about the state of products. It can be useful if the project manager wants to confirm the version number of one or more products.
