PRINCE2® in a nutshell

Introduction

This document aims to describe in a nutshell what the PRINCE2® methodology is about. This
description was written in 2007 but is still current under the current version of PRINCE2® because the
approach is described on the level of unchanged principles. The audience for this document is:

• Senior management; policy and decision makers who focus on giving direction rather than on
managing or participating in projects.
• Members of steering committees (Project Board); decision makers in projects within the mandate
given to them by the group described above
• Project managers; managing the project under the control of the Project Board.

It is important that on all levels people have the same perception of what PRINCE2® is. This document
avoids going into detail. Details can be found in the official PRINCE2® Manual. PRINCE2® terms in this
document are printed in Italic font.

Key message

PRINCE2® is theoretically described as a comprehensive system to keep a project under control. Key
to using the approach is the realisation that PRINCE2® needs to be tailored down to the requirements
of the individual projects.

Processes

The PRINCE2® approach describes eight high level processes that in their detailed sub processes guide
the project management through the start (preparation and initiation), middle (execution, control and
escalation) and closure of a project. In this short overview only two processes are mentioned here:
Starting Up a Project (SU, preparation) and Initiating a Project (IP, definition and planning).

Preparation - Starting Up a Project (SU)

A project is usually started after an idea for a change. This results in the Project Mandate which can
be very vague. During the first process of PRINCE2® the following questions should be answered:
• Who should be involved in this project?
• What should be done in this project? What deliverables including their acceptance criteria should
be created by this project? Obviously, this should be described on a high level. This is the Project Brief.
• How should the deliverables be created? Again, high level: e.g. are we doing this with own staff or
will (parts of) the project be outsourced? This is described in the Project Approach.
• Most importantly: why should this effort be undertaken: The Business Case, the justification and
ongoing driver of the project. The answers to the questions asked above are derived from and should
be related to the justification.

This should lead to a common understanding on basis of which the effort for planning can be
authorised.
Initiation - Initiating a Project (IP)

The result of the Initiation Stage is the so-called Project Initiation Document (PID). This is a misleading
name as the so-called document is essentially the assembly of the information needed to decide if a
project is worth commencing. For any significant size project, the PID may need to be divided into a
set of linked documents to aid navigation and address the multiple audiences involved in the project.

The more practical approach could well be to work with the individual documents that together form
the PID. These include (not an extensive list):
• Business Case
• Project Plan
• Communication Plan
• Project Quality Plan
• Information from SU (see above), probably with more detail

The PID will be the "contract" between the Project Board and the Project Manager and will together
with a Stage Plan (for the first part of the work, see page 3 chapter Plans and Stages) be authorised
leading to commitment of resources by the Project Board.

Business Case

PRINCE2® is a result driven approach which makes the Business Case the most important piece of
information. The Business Case drives the project by constantly focussing on the question: why are
we doing this? The heart of the Business Case is the balance between the expected benefits of the
change versus the expected cost of the project and the expected cost of the operational support of
the results. A PRINCE2® Project Manager should constantly focus on the Business Case of the
Customer of the project.

It is important to realise that the Supplier of a project have their own conflicting Business Case. When
working with an external supplier this is obvious: the more the project will cost, the more benefits the
supplier can expect. It is less obvious but still usually an issue with internal suppliers.

The issue of conflicting Business Cases is the reason behind the PRINCE2® organisational concept.

Organisation

The PRINCE2® organisational concept is based on the conflicting Business Cases between the
Customer and Supplier. The Customer and their Business Case should drive the project.

But also, within the customer side conflicting interests can be found. The Business Case is about
balancing expected benefits against the cost but future users of the results of the project are usually
not really interested; they will be interested in getting the right results out of the projects, no matter
what the cost are.

This results in a Project Board where the customer is represented by the Business in the role of the
Executive and by the user community in the role of Senior User. The Project Board should not manage,
but only direct the project. The role of Senior User should therefore not be confused with the roles of
the real users. The Senior User should be a manager representing the interest of those whose work
will be affected by the results of the project, voicing their views and committing to resources to play
a part in the project, e.g. for defining the expected quality of the results and for testing. Commitment
should be given on basis of the plans submitted by the Project Manager.
Within the PRINCE2® approach a number of roles must be assigned. In some cases, it will be
appropriate to combine the roles of Executive and Senior User. In larger or more complex projects it
may be required to have multiple people filling the roles of Senior User and/or Senior Supplier.

The Project Manager should focus on the Customer's Business Case. PRINCE2® recommends that the
Project Manager should come from the Customer side of the project because of the conflicting
Business Cases between Customer and Supplier potentially leading to a conflict of interest and
priorities.

The Executive will be appointed by the management level that ordered the project as part of their
Mandate: Corporate Management or Programme Management. The Project Manager (probably
appointed by the Executive) will design the rest of the Project Management Team in close liaison with
the Executive. The Executive will be ultimately accountable for the project and its results and therefore
owns the project's Business Case.

Plans and Stages

Projects can be relatively unpredictable, especially when they are sizeable. Commitment to plans is
therefore difficult to give for Project Board members. This also makes the task of control difficult.
These are issues that PRINCE2® suggests to handle by splitting a project up in Management Stages. On
basis of risks there will be key milestones in a project where the Project Board needs to evaluate and
show ongoing commitment. These Management Stages should not be confused by technical phases;
again, the Project Board is not there to manage details; that is the job of the Project Manager.

As a result, the Project Manager will only receive authorisation for one Stage at the time. As a
delegated task the Project Manager will also report to the Project Board about the status of the overall
project and the Business Case.

A result of the above is that there will be a high-level Project Plan and per stage a detailed Stage Plan,
enabling the right levels of control (right, not tight!). Whatever the level of the plan is, a plan should
consist of:
• A clear description of the Products delivered by the plan. These Product Descriptions can be tested
for measurable quality criteria.
• The schedule of the plan, based on the Products showing the activities and resources to deliver the
Products.
• Risks and their results:
o Revised activities to keep the risks under control,
o Tolerances. Risks make the work deviate from the plan but there should not be an escalation
for every deviation. Tolerances include time, cost, quality, scope, benefit and risk.

During the execution of a stage the Project Manager has three main responsibilities:
1. Assigning the work to Team Managers or individual team members and tracking their work.
2. Assessing issues and, when they cause a threat to the tolerance levels, escalation (Exception
Report). This includes proposals to deal with the exception.
3. Reporting progress against the plan to the Project Board and thus showing them that the stage,
project and Business Case is under control. This is the Highlight Report.

At the end of a stage the Project Manager will present a next Stage Plan, proposing how to continue
and asking for commitment of the Project Board. This includes the overall status of the project
including the revised Business Case and Project Plan
Closure

PRINCE2® defines evaluations during the project to keep control: e.g. Highlight Reports and End Stage
Reports. The final evaluation will take place during the closure. This includes the Post Project Review
Plan, a plan for the evaluation of the Business Case (responsibility of the Executive, this can only take
place after a period of usage of the Products). There will also include confirmation that all Products
are accepted and supported for operational usage.

Any still open issues and / or risks will also be reported to the Project Board to guarantee that they
will be handled after the project.

Refer below link for additional reading information: