PRINCE2 (PRojects IN Controlled Environments) is a structured project management method and practitioner certification program. PRINCE2 emphasizes dividing projects into manageable and controllable stages.

It is adopted in many countries worldwide, including the UK, Western European countries, and Australia. PRINCE2 training is available in many languages.

PRINCE2 was developed as a UK government standard for information systems projects. In July 2013, ownership of the rights to PRINCE2 was transferred from HM Cabinet Office to AXELOS Ltd, a joint venture by the Cabinet Office and Capita, with 49% and 51% stakes respectively.

Overview of PRINCE2

Six Aspects

These aspects are also called tolerances or performance goals. They quantify the project tolerance and are considered during decision-making processes. In some organizations, these can be key performance indicators (KPIs). In the following table project level tolerances are summarised:

Benefits can have as a target the cost of the benefit, but the cost tolerance above is related to the cost of the project, not the cost of the benefit.

Each management level is checked against these tolerances, coming from the upper level.

Seven Principles (why, or guidelines to follow)

PRINCE2 is based on seven principles and these cannot be tailored. The PRINCE2 principles can be described as a mindset that keeps the project aligned with the PRINCE2 methodology. If a project does not adhere to these principles, it is not being managed using PRINCE2.

Continued Business Justification: The business case is the most important document, and is updated at every stage of the project to ensure that the project is still viable. Early termination can occur if this ceases to be the case.

Learn From Experience: Each project maintains a lessons log and projects should continually refer to their own and to previous and concurrent projects’ lesson logs to avoid reinventing wheels. Unless lessons provoke change, they are only lessons identified (not learned).

Defined Roles and Responsibilities: Roles are separated from individuals, who may take on multiple roles or share a role. Roles in PRINCE2 are structured in four levels (corporate or program management, project board, project manager level, and team level). The project Management Team contains the last three, where all primary stakeholders (business, user, supplier) need to be presented.

Manage by Stages: The project is planned and controlled on a stage-by-stage basis. Moving between stages includes updating the business case, risks, overall plan, and detailed next-stage plan in light of new evidence.

Manage by Exception: A PRINCE2 project has defined tolerances (6 aspects above) for each project objective, to establish limits of delegated authority. If a management level forecasts that these tolerances are exceeded (e.g. time of a management stage will be longer than the estimated time in the current management stage). It is escalated to the next management level for a decision on how to proceed.

Focus on Products: A PRINCE2 project focuses on the definition and delivery of the products, in particular their quality requirements.

Tailor to Suit Project Environment: PRINCE2 is tailored to suit the project environment, size, complexity, importance, time capability, and risk. Tailoring is the first activity in the process of Initiating A Project and is reviewed for each stage.

Not every aspect of PRINCE2 will be applicable to every project, thus every process has a note on scalability. This provides guidance to the project manager (and others involved in the project) as to how much of the process to apply. The positive aspect of this is that PRINCE2 can be tailored to the needs of a particular project. The negative aspect is that many of the essential elements of PRINCE2 can be omitted sometimes resulting in a PINO project – PRINCE in Name Only

Seven Themes (what, or tools to use ) 

Seven Processes (how, or roadmap start to finish)

Starting Up A Project, in which the project team is appointed including an executive and a project manager, and a project brief is produced.

Initiating A Project, in which the business case is refined and Project Initiation Documentation assembled.

Directing A Project, which dictates the ways in which the Project Board oversees the project.

Controlling A Stage, which dictates how each individual stage should be controlled, including the way in which work packages are authorized and distributed.

Managing Product Delivery, which has the purpose of controlling the link between the Project Manager and the Team Manager(s) by placing formal requirements on accepting, executing and delivering project work.

Managing Stage Boundaries, dictates how to transition from one stage to the next.

Closing A Project, which covers the formal decommissioning of the project, follow-on actions and evaluation of the benefits.

Management products

The PRINCE2 manual contains 26 suggested templates for documentation associated with the project, which it terms management products and which are divided into baselines, records, and reports. Some examples of management products are:

Benefits Management Approach (In 2009 Edition it was called Benefits Review Plan): defines how and when a measurement of the project’s benefits, expected by the Senior User, can be made.

Business Case: used to capture financial justification for the project. It is a PRINCE2 principle that a project must have continued business justification. As soon as a Business Case fails to make sense, change or stop that project.

Checkpoint Report: a progress report created by the Team Manager and sent to the Project Manager on a regular basis to report the status of the Work Package.

Communications Management Approach (In 2009 Edition it was called Communications Management Strategy): a description of the methods and frequency of communication to stakeholders, covering the flow of information in both directions to and from stakeholders (Information required to be provided from the project and information required to be provided to the project).

Configuration Item Record: provides a record of the product History, Status, Version, Variant, Details of any relationships between items/products, and Product owner/Product copyholders.

Change Control Approach (In 2009 Edition it was called Configuration Management Strategy): used to identify how the project’s products will be identified, controlled, and protected, this document is created by the Project Manager in the Initiating a Project process.

Daily Log: used to record informal issues.

End Project Report: reviews how the project performed against the original Project Initiation Documentation (PID)

Issues Register an issue log of notes about change requests, problems, and complaints sent by all project members.

Lessons Log: a set of notes of lessons learned which may be useful to future projects

Project Brief: used by the Project Board to authorize the Initiation Stage (1st stage of the project). In the Initiating a Project process, the contents of the Project Brief are extended and refined and the Project Brief evolves to form the Project Initiation Documentation (PID)

Quality Register: details of all planned quality control activities, dates, and personnel involved.

Risk Register: a record of identified risks (threats and opportunities) relating to the project

Integration with other techniques

The 26 Management Products described by PRINCE2 are only used for the “high-level” management of the project. Within its tasks, task managers must still decide on their own project management framework. Some suggestions given in the PRINCE2 manual are product-based planning, change control, quality review technique, Gantt charts, PERT charts, and critical path analysis.

PRINCE2 can also be used to manage projects that use agile software development methods.

Quality review technique

See also: Quality assurance

The quality review technique ensures a project’s products are of the required standard (i.e. meet defined quality criteria). This takes place in a quality review meeting, which identifies errors in the product. The quality review meeting will not attempt to solve the problems it identifies. The meeting brings together people who have an interest in the project’s outputs (or products) and people on the project team able to address issues identified.