PRINCE2® Glossary

The texts below with the quotation mark are from the official AXELOS PRINCE2® Glossary.

Acceptance Criteria

A prioritized list of criteria that the final product(s) must meet before the customer will accept them; (a measurable definition of what must be done for the final product).

A list of standards the final output of the project must satisfy for the customer to accept it. The list of criteria is arranged in order of importance and each entry should be discussed and confirmed both by the customer and the supplier. Throughout the project, the acceptance criteria can be refined and changed, but in the end only when all the criteria are met, the project can be closed.


A snapshot; a position or situation that is recorded. A baselined product is a reminder of the original state and as a comparison against the current position. Products that have passed their quality checks and are approved are baselined products.

A point of measure to which a product is compared. Once a product is baselined, it becomes a touchstone of reference for the following versions of the same product. For example, if a plan is changed during a review, the new plan replaces the old one and becomes a control document (a baseline) for the future progress of the project.

Business Case

Information that describes the justification for setting up and continuing a PRINCE2 project. It provides the reasons (and answers the question:‘Why?’) for the project. An outline Business Case should be in the Project Mandate, can be updated in Project Brief and a fuller version should appear in the Project Initiation Document.

A document that explains the reasons for the project in terms of costs, risks and benefits. It explains in detail why the project should be done, why the final outcome is desired. During the project lifetime whenever a risk appears the odds should be weighted against the Business Case to check if the benefits still exist within the expected time and cost constraints. For example, if a company is running a project to develop and implement a new client management software, the Business Case should include the improved efficiency for client management so more clients could be handled within a certain period of time. On the other hand if a new, cheaper yet as efficient software appears on the market before conclusion, the benefit of changing to the new software should be considered by comparing the potential outcomes to the desired benefits on the Business Case.

Change Authority

A person or group to which the Project Board may delegate responsibility for the consideration of requests for change or off-specifications and this role is part of the Project Management Team. The Change Authority may be given a change budget and can approve changes within that budget.

Change Authority may delegate to a number of levels, depending on the severity of the change.

Checkpoint Report

A progress report of the information gathered at a checkpoint, which is given by a team to the Project Manager and which provides reporting data as defined in the Work Package

The Team Manager uses the Checkpoint Report to report to the Project Manager. Information on the progress of the work done compared to the agreed Team Plan is also included in it. The Project Manager will agree on the frequency for these reports with the Team Manager when they are accepting the Work Package.

Communication Management Strategy

A description of the means and frequency of communication between the project and the project’s stakeholders.

A description of the flow of information between the project and its stakeholders. It defines the method and frequency of the information exchange. During the start-up, the traffic of communication and reporting may be higher. The Communication Management Strategy provides an organized approach to deliver reports on a timely basis to those who need the information for decision making and/or other purposes.

The Project Manager is responsible for creating the Communication Management Strategy during the Initiation Stage of the project. This should be reviewed during the Managing a Stage Boundary process to ensure that key stakeholders are receiving the required communication.

Usually a Communication Management Strategy template document will be provided by the Corporate or Programme environment. This can be slightly customized by the Project Manager for the project.

Communication Plan

Part of the Project Initiation Document describing how the project’s stakeholders and interested parties will be kept informed during the project.

Configuration Management

The purpose of Configuration Management (CM) is look after all documents and products that are used during the project (like asset management for all the items that that the project uses and crates).

You can also say that the purpose is to establish and maintain the integrity of work products using configuration identification, configuration control, configuration status accounting, and configuration audits.


The person or group who commissioned the work and will benefit from the end results.

The owner of the final product of the project. Representative to those who are going to use the final product.


An item that the project has to create as part of the requirements. It may be part of the final outcome or an intermediate element on which one or more subsequent deliverables are dependent. According to the type of project, another name for a deliverable is ‘product’.

End Project Report

A report given by the Project Manager to the Project Board that confirms the handover of all products and provides an updated Business Case and a Project Assessment.

Project Manager’s report to the Project Board that confirms the delivery of outputs to the customer and assesses the project with an updated Business case. It also includes reviews on overall project performance and team performance.

End Stage Report

A report given by the Project Manager to the Project Board at the end of each management stage of the project. This provides information about the project performance during the stage and the project status at stage end.

Project Manager’s report to the Project Board that provides information on project performance during each stage and the overall project status up to that point. An End Stage Report should contain all the necessary information for the Board to decide whether to continue the project or not.


The single individual with overall responsibility for ensuring that a project meets its objectives and delivers the projected benefits. This individual should ensure that the project maintains its business focus, that it has clear authority and that the work including risks is actively managed. The Executive is the Project Board chairperson, representing the customer, and is the owner of the Business Case.

The person responsible to ensure the project satisfies its goals and delivers the intended benefits. The Executive is the chairperson of the Project Board and represents the Customer. He or she is also responsible for the Business Case.

Follow-On Action Recommendations

A report that can be used as input to the process of creating a Business Case/Project Mandate for any follow-on PRINCE2 project and for recording any follow-on instructions covering incomplete products or outstanding Project Issues.

A report created by the Project Manager at the end of a project that puts together recommendations on how to handle incomplete outputs, ongoing Issues and existing risks once the project is complete.

Highlight Report

Time-driven report from the Project Manager to the Project Board on stage progress.

The Highlight Report is used by the Project Manager to report on the status of the current stage compared to the Stage Plan. The Highlight Report allows the Project Board to manage by exception between each stage end, as they are aware of the tolerances agreed with the Project Manager in the Stage Plan, so the Highlight Report should report the current status of tolerances of Time, Cost, Quality, Scope, Benefits and Risk.


A relevant event that has happened, was not planned, and requires management action. It can be any concern, query, request for change, suggestion or off-specification raised during a project. Project Issues can be about anything to do with the project.

An unforeseen event that requires management intervention. It can be any unplanned topic related with the project.

Issue Log

Contains all Project Issues including Requests for Change raised during the project. Project Issues are each allocated a unique number and are filed in the Issue Log.

Issue Register

A register used to capture and maintain information on all of the issues that are being managed formally. The Issue Register should be monitored by the Project Manager on a regular basis.

A log that keeps track of all the existing issues. It is monitored by the Project Manager regularly.

Lessons Learned Log

An informal collection of good and bad lessons learned about the management and specialist processes and products as the project progresses. At the end of the project, it is formalized and structured into a Lessons Learned Report. See also Lessons Learned Report.

Lessons Report

A report that documents any lessons that can be usefully applied to other projects. The purpose of the report is to provoke action so that the positive lessons from a project become embedded in the organization’s way of working and that the organization is able to avoid the negative lessons on future projects.

A document that lists the lessons gained during the project. It helps to avoid possible mistakes and to repeat positive actions in future projects.


A detailed proposal for doing or achieving something which specifies the what, when, how and by whom.

A Plan is a document that describes how, when and by whom a specific target or set of targets is to be achieved. A Plan must contain sufficient information to show that the targets ( time, cost, quality, scope, risk, benefits and, of course products) are achievable.

A Plan is a backbone for any project. It is created at the Start of the project and continually updated during the project to show what has been realized so far (actuals) and what is still left to do. The original plan could also be compared to the plan during the project or the plan at the end of the project to see how well the project is doing in relation to the original plan.

PRINCE2 recommends 3 levels of plan: Project Plan, Stage Plan, Team Plan

The other plans created during the project include the Exception Plan, which will replace an existing Project Plan or Stage Plan , and Benefits Review Plan.


Any input to or output from a project. PRINCE2 distinguishes between management products (which are produced as part of the management or quality processes of the project) and specialist products (which are those products that make up the final deliverable). A product may itself be a collection of other products.

Any input to a project or output produced during the project. A PRINCE2 project creates two kinds of products, Specialist products and Management products. The creation of the specialist products is the reason that the project was started and these are the products that will be given to the users. Management products are documents used solely for the purpose of communication among the project management team and managing the project. E.g. Project Plan, Business Case, so the Users are only interested in the Specialist products.

Product Based Planning

A technique leading to a comprehensive plan based on creation and delivery of required outputs. The technique considers prerequisite products, quality requirements and the dependencies between products.

A technique used to create a detailed plan that focuses on the required products. The technique is based on prerequisite products, quality requirements and dependencies between products.

The Product Based Planning has 4 steps:

  1. Writing the Project Product Description – describing the main product (Starting Up a Project process)
  2. Creating the Product Breakdown Structure – listing all products that need to be created.
  3. Writing the Product Description – done for required products
  4. Creating the Product Flow Diagram – shows product flow and interdependencies

Product Breakdown Structure

A hierarchy of all the products to be produced during a plan (during a project).

A Project Product is broken down into the major products which in turn are broken down into further products to give a hierarchical overview.

Product Checklist

A list of the major products of a plan, plus key dates in their delivery.

A list of all the major products to be produced, along with their dates of delivery.

Product Description

A description of a product’s purpose, composition, derivation and quality criteria. It is produced at planning time, as soon as possible after the need for the product is identified.

Information on the product’s purpose, composition, derivation and quality criteria. A product is defined as soon as its need is identified.

The Product Description should be created for all the products as part of the planning activities and before the Project Plan can be completed. This is not always possible in each project, therefore Product Descriptions may be created or updated in the Stage Boundary process and the Product Descriptions will be agreed and baselined before development starts.

Product Flow Diagram

A diagram showing the sequence of production and interdependencies of the products listed in a Product Breakdown Structure. (so what has to be produced 1st, 2nd, 3rd, etc…)

A diagram showing the order of production and the prerequisites for each product defined in the Product Breakdown Structure.

Project Assurance

The Project Board’s appoints persons to this role to assure that the project is being conducted correctly. This role provides assurance that the project is going according to the information provided by the Project Manager.

The Executive is responsible for Business Assurance.

They wish to ensure that the business aspects of the project are correct
They keep asking: is the project value for money?
The Senior User is responsible for User Assurance

They wish to ensure that the project will deliver the correct products and these products will meet the expected requirements
They keep asking: Will the product work as expected?
The Senior Supplier is responsible for Supplier Assurance

They want to ensure that the products will be delivered as expected and that the right materials and people are in place to do the work
They keep asking: Can it be done within time, cost, and other variables?

The Project Board’s responsibilities to assure itself that the project is being conducted correctly. The Project Board members each have a specific area of focus for Project Assurance, namely business assurance for the Executive, user assurance for the Senior User, and supplier assurance for the Senior Supplier.
The Project Board’s delegation of its assurance functions to another entity to make sure the project runs smoothly.

Project Brief

Statement that describes the purpose, time, cost and performance requirements, and constraints for a project. It is created pre-project during the Starting up a Project process and is used during the Initiating the Project process to create the Project Initiation Documentation and its components. It is superseded by the Project Initiation Documentation and not maintained.

A document that outlines the project within its time, cost and performance constraints and defines its purpose. It is used to create the Project Initiation Documentation and is not updated during the project…

Project Initiation Documentation (PID)

A logical set of documents that brings together the key information needed to start the project on a sound basis and to convey that information to all concerned with the project.

A set of documents that contain essential information to start the project. It is also used to communicate the project with its stakeholders.

Project Lifecycle

This term is used in this manual to define the period from the start-up of a project to the handover of the finished product to those who will operate and maintain it.

The time between the start of the project and the acceptance of the product.

Project Management

The planning, monitoring and control of all aspects of a project and the motivation of all those involved in it to achieve the project objectives on time and to the specified cost, quality and performance.

The conducting of the project in view of the project objectives. This includes the management of the human and nonhuman resources within the limits of cost, quality and performance.

Project Management Team

Covers the entire management structure of Project Board, Project Manager, plus any Team Manager, Project Assurance and Project Support roles.

Defines the total management structure of the project from top to bottom, from the Project Board to the Team Managers and the support staff.

Project Manager

The person given the authority and responsibility to manage the project on a day-to-day basis to deliver the required products within the constraints agreed with the Project Board.

The Project Manager manages a project on a day-to-day basis and is the only one with this day-to-day focus on the project. As a result, this role can never be shared. The Project Manager runs the project on behalf of the Project Board within specified constraints and liaises throughout the project with the Project Board and Project Assurance.

The Project Manager usually (preferred by PRINCEE2) comes from the customer. They are responsible for all of the PRINCE2 processes except for the “Directing a Project” process.

The Project Manager is responsible for the Project Support and Team Managers. In smaller projects where there are no Team Managers, the Project Manager will manage the Team Members directly, and where there is no Project Support, the support tasks fall on the Project Manager.

Project Mandate

Information created externally to the project that forms the terms of reference and is used to start up the PRINCE2 project.

Information provided by the upper management outlining what is desired from the project. This is an external document and is used as an input for the Starting up a Project process.

Project Plan

A high-level plan showing the major products of the project, when they will be delivered and at what cost. An initial Project Plan is presented as part of the Project Initiation Document. This is revised as information on actual progress appears. It is a major control document for the Project Board to measure actual progress against expectations.

Project Plan is used at the direction level and therefore is used by the Project Board. It is created during the Initiation a Project process and is a high-level plan for the whole project. It will show the major products of the project, when they will be delivered and the associated cost. It is a major control document for the Project Board. The Project Manager keeps the Project Plan up to date during the project.

Project Product Description

A special type of Product Description used to gain agreement from the user on the project’s scope and requirements, to define the customer’s quality expectations, and to define the acceptance criteria for the project.

The Project Product Description is a description of the main product that will be produced by the project. The Project Product Description is created in the Starting up a Project process and become part of the Project Brief.

The Closing a Project process to help verify that the project has delivered what was expected and that the acceptance criteria have been met uses the Project Product Description.

Project Quality Plan

A plan defining the key quality criteria, quality control and audit processes to be applied to project management and specialist work in the PRINCE2 project. It will be part of the text in the Project Initiation Document.


The totality of features and inherent or assigned characteristics of a product, person, process, service and/or system that bears on its ability to show that it meets expectations or satisfies stated needs, requirements or specifications.

A product’s ability to satisfy its intended properties by meeting expectations, requirements and specifications.

Quality Management Strategy

A strategy defining the quality techniques and standards to be applied, and the various responsibilities for achieving required quality levels during a project.

A Quality Management Strategy is a document and a plan of action that defines the Quality requirements and the Quality Control method for all the products in the project. This document also confirms how the Quality systems and standards from the customer and supplier are going to be applied in the project. In other words the Quality Management Strategy document defines how Quality will be done in the project.

This document is created at the Initiation Stage with the other strategy documents and becomes part of the Project Initiation Documentation.


An uncertain event or set of events that, should it occur, will have an effect on the achievement of objectives. A risk is measured by a combination of the probability of a perceived threat or opportunity occurring, and the magnitude of its impact on objectives.

An event that, if it occurs, may have a positive or negative effect on the project’s objectives

Risk Log

Contains all information about the risks, their analysis, countermeasures and status.

Risk Register

A record of identified risks that are faced by an organization and its exposure to those risks.

A log of possible risks that the project faces.

Senior Supplier

The Project Board role that provides knowledge and experience of the main disciplines involved in the production of the project’s deliverables. The Senior Supplier represents the supplier interests within the project and provides supplier resources.

The Project Board role that represent the interests of those who are going to deliver the desired products.

Senior User

The Project Board role accountable for ensuring that user needs are specified correctly and that the solution meets those needs.

The Project Board role that represent the future users of the project’s product. The Senior User is responsible to ensure the product satisfies the quality and functionality requirements of the user.

Stage (Management Stage)

The section of a project that the Project Manager is managing on behalf of the Project Board at any one time, at the end of which the Project Board will wish to review progress to date, the state of the Project Plan, the Business Case and risks, and the next Stage Plan in order to decide whether to continue with the project.


Any individual, group or organization that can affect, be affected by, or perceive itself to be affected by, an initiative (programme, project, activity, risk)

A Stakeholder is any person or group that can be affected by the project or have an effect on the project. This includes the Project Board and the Project Team, the potential users, others that may benefit (shareholders), as well as those who may be negatively affected.

Technical Stage

A method of grouping work together by the set of techniques used, or the products created. This results in stages covering elements such as design, build and implementation. Such stages are technical stages and are a separate concept from management stages.

There are two types of stages. In PRINCE2 a project is divided into stages to define management decision points. These are called the Management Stages. The second type, the Technical Stage, is a grouping of a certain set of techniques used in the development of the product. These two types of stages do not necessarily overlap.


The permissible deviation above and below a plan’s estimate of time and cost without escalating the deviation to the next level of management. Separate tolerance figures should be given for time and cost.

The estimated time and cost allowance in the project plan to tolerate possible deviations without the need of the Project Board intervention.


The person or group who will use the final deliverable(s) of the project.

The end users of the project’s final deliverable.

No comments yet.

Leave a Reply