Appendix A: PRINCE2’s management products
PRINCE2 defines a set of management products that will be required as part of managing the project and establishing and maintaining quality. These management products are not necessarily text documents; rather, they are information sets that are used by the PRINCE2 processes and which can be tailored to the requirements and environment of each project. This tailoring may include their composition, format, quality criteria and naming.
Management products can be documents, slides, spreadsheets or data in information systems which are brought together, either on screen or as outputs, to form reports.
Some management products may not be used unless there is a specific requirement for the additional information they provide. These are:
• configuration item record
• lessons report
• product status account.
Types of management product
There are three types of management product: baselines, records and reports.
Baseline management products are those that define aspects of the project and, when approved, are subject to change control. These are:
• A.1 Benefits management approach
• A.2 Business case
• A.3 Change control approach
• A.5 Communication management approach
• A.16 Plan (covers project plans, stage plans, exception plans and, optionally, team plans)
• A.17 Product description
• A.19 Project brief
• A.20 Project initiation documentation (PID)
• A.21 Project product description
• A.22 Quality management approach
• A.24 Risk management approach
• A.26 Work package.
Records are dynamic management products that maintain information regarding project progress. These are:
• A.6 Configuration item record
• A.7 Daily log
• A.12 Issue register
• A.14 Lessons log
• A.23 Quality register
• A.25 Risk register.
Reports are management products providing a snapshot of the status of certain aspects of the project. They do not need to be documents. They could be emails, notes of meetings, wall charts or entries in a daily log. Where verbal reports are used, the information could be incorporated in other reports. PRINCE2 reports are:
• A.4 Checkpoint report
• A.8 End project report
• A.9 End stage report
• A.10 Exception report
• A.11 Highlight report
• A.13 Issue report
• A.15 Lessons report
• A.18 Product status account.
Although records and reports are not subject to change control, they are still subject to other aspects of configuration management, such as version control, safe storage, access rights, etc.
A.1 Benefits management approach
A benefits management approach defines the benefits management actions and benefits reviews that will be put in place to ensure that the project’s outcomes are achieved and confirm that project’s benefits are realized. If the project is part of a programme, the benefits management approach may be contained within the programme’s benefits realization plan and executed at the programme level. Post-project, the benefits management approach is maintained and executed by corporate, programme management or the customer.
A business case is used to document the business justification for undertaking a project, based on the estimated costs (of development, implementation and incremental ongoing operations and maintenance costs) against the anticipated benefits to be gained and offset by any associated risks. It should outline how and when the anticipated benefits can be measured.
The outline business case is developed in the starting up a project process and refined by the initiating a project process. The directing a project process covers the approval and re-affirmation of the business case. The business case is used by the controlling a stage process when assessing impacts of issues and risks. It is reviewed and updated at the end of each management stage by the managing a stage boundary process, and at the end of the project by the closing a project process.
A change control approach is used to identify, assess and control any potential and approved changes to the project baselines. It describes the procedures, techniques and standards to be applied and the responsibilities for achieving an effective issue management and change control procedure.
A checkpoint report is used to report, at a frequency defined in the work package, the status of the work package.
A.5 Communication management approach
A communication management approach contains a description of the means and frequency of communication with parties both internal and external to the project. It facilitates engagement with stakeholders through the establishment of a controlled and bidirectional flow of information.
Configuration item records are only created if required by the project’s change control approach. Their purpose is to provide a record of such information as the history, status, version and variant of each configuration item, and any details of important relationships between them. The set of configuration item records for a project is often referred to as a configuration library.
A daily log may be used to record informal issues, required actions or significant events not captured by other PRINCE2 registers or logs. It can act as the project diary for the project manager. It can also be used as a repository for issues and risks during the starting up a project process if the other registers have not been set up.
An end project report is used during project closure to review how the project performed against the version of the PID used to authorize it.
An end stage report is used to give a summary of progress to date, the overall project situation, and sufficient information to ask for a project board decision on what to do next with the project. The project board uses the information in the end stage report in tandem with the next stage plan to decide what action to take with the project: for example, authorize the next stage, amend the project scope or stop the project.
An exception report is produced when a stage plan or project plan is forecast to exceed tolerance levels set. It is prepared by the project manager in order to inform the project board of the situation, and to offer options and recommendations for the way to proceed.
A highlight report is used to provide the project board (and possibly other stakeholders) with a summary of the management stage status at intervals defined by them. The project board uses the report to monitor management stage and project progress. The project manager also uses it to advise the project board of any potential problems or areas where the project board could help.
The purpose of the issue register is to capture and maintain information on all the issues that are being formally managed. The issue register should be monitored by the project manager on a regular basis.
An issue report is a report containing the description, impact assessment and recommendations for a request for change, off-specification or a problem/concern. It is created only for those issues that need to be handled formally.
The lessons log is a project repository for lessons that apply to this project or future projects. Some lessons may originate from other projects and should be captured on the lessons log for input to the project’s approaches and plans. Some lessons may originate from within the project, where new experience (both good and bad) can be passed on to others.
A lessons report may be produced to support the lessons log if more information is required. It can be used to pass on any lessons that can be usefully applied to other projects. The purpose of the report is to provoke action so that the positive lessons become embedded in the organization’s way of working, and the organization is able to avoid any negative lessons on future projects.
A plan provides a statement of how and when objectives are to be achieved, by showing the major products, activities and resources required for the scope of the plan. In PRINCE2, there are three levels of plan: project, stage and team. Team plans are optional and may not need to follow the same composition as a project plan or stage plan. An exception plan is created at the same level as the plan that it is replacing.
A plan should cover not just the activities to create products but also the activities to manage product creation, including activities for assurance, quality management, risk management, change control, communication and any other project controls required.
A product description is used to:
• understand the detailed nature, purpose, function and appearance of the product
• define who will use the product
• identify the sources of information or supply for the product
• identify the level of quality required of the product
• enable identification of activities to produce, review and approve the product
• define the people or skills required to produce, review and approve the product.
If required by the project’s change control approach, a product status account is used to provide information about the state of products within defined limits. The limits can vary. For example, the report could cover the entire project, a particular management stage, a particular area of the project or the history of a specific product. It is particularly useful if the project manager wishes to confirm the version number of products.
A project brief is used to provide a full and firm foundation for the initiation of the project and is created in the starting up a project process. In the initiating a project process, the contents of the project brief are extended and refined in the PID, after which the project brief is no longer maintained.
A.20 Project initiation documentation (PID)
The purpose of the PID is to define the project, in order to form the basis for its management and an assessment of its overall success. The PID gives the direction and scope of the project and (along with the stage plan) forms the ‘contract’ between the project manager and the project board.
The three primary uses of the PID are to:
• ensure that the project has a sound basis before asking the project board to make any major commitment to the project
• act as a base document against which the project board and project manager can assess progress, issues and ongoing viability questions
• provide a single source of reference about the project so that people joining the ‘temporary organization’ can quickly and easily find out what the project is about, and how it is being managed.
The PID is a living product in that it should always reflect the current status, plans and controls of the project. Its component products will need to be updated and re-baselined, as necessary, at the end of each management stage, to reflect the current status of its constituent parts.
A.21 Project product description
The project product description is a special form of product description that defines what the project must deliver in order to gain acceptance. It is used to:
• gain agreement from the user on the project’s scope and requirements
• define the customer’s quality expectations
• define the acceptance criteria, method and responsibilities for the project.
The product description for the project product is created in the starting up a project process as part of the initial scoping activity, and is refined during the initiating a project process when creating the project plan. It is subject to formal change control and should be checked at management stage boundaries (during managing a stage boundary) to see if any changes are required. It is used by the closing a project process as part of the verification that the project has delivered what was expected of it, and that the acceptance criteria have been met.
A.22 Quality management approach
A quality management approach describes how quality will be managed on the project. This includes the specific processes, procedures, techniques, standards and responsibilities to be applied.
A quality register is used to summarize all the quality management activities that are planned or have taken place, and provides information for the end stage reports and end project report. Its purpose is to:
• issue a unique reference for each quality activity
• act as a pointer to the quality records for a product
• act as a summary of the number and type of quality activities undertaken.
A risk management approach describes how risk will be managed on the project. This includes the specific processes, procedures, techniques, standards and responsibilities to be applied.
A risk register provides a record of identified risks relating to the project, including their status and history. It is used to capture and maintain information on all the identified threats and opportunities relating to the project.
A work package is a set of information about one or more required products collated by the project manager to pass responsibility for work or delivery formally to a team manager or team member.