PRINCES 2 Revised Edition 2005

(Revised edition 2005)
Proiecm
«
‘Hie
mien
WI!
by Colin Bentley
Prni,pM<: the PRINCE2
This book has been revised in line with the to the PRINCE2
in Nov
.......<&llu.oU, )J'...UlJ''''-'" ....
4th edition Nov 200S
© Colin Bentlev Nov 2005

All reserved. No may be stored
in a retrieval system, or in any form or by any means,
without the permission of the author.
First in 2001 by:

Colin Bentlev. 42 The Hants P07
Protec, The Old Boathouse, 12 Bank Rd, Hill

Faneharn, Hants P014
ISBN
lVlaIlagmg the PRINCE2
Acknowledgements
PRINCE2™ is a Trade Mark of the Office im!PM'lrt'lpnt Commerce
PRINCE ® is a a
COlIlIlllUlUty Trade Mark the Office
cr,.L""""Lcuin theU.S.
-ll
Managing the PRINCE2 Way
(revised edition
~--~~---------------------------
Preface
nT'Pc.....t" the revised version

method based on the CAI'CLJ.<;;ll\.<;;
.u..w.u"'iS....LU"....
lVlanagt:Ui who have some from their mistakes or
V.I..U.1""'.lUll", others from their success. It can be to any kind of
project, however or i.e. the basic the
same. The method should be tailored to suit the and
environment of the Common sense PRlNCE2 says, "Don't use a
sledgehammer to crack a walnut", but equally don't agree important
things where there is any chance of a later over
what was
-m
Table Contents
Preface ...................................................................................................... m
Table of Contents ..................................................................................... N
Introduction ................................................................................................ 1
An Overview of PRlNCE2 ........................................................................ 4
a ....................................................................... 12
24
35
44
........................................................... 58
64
............................................................................ 73
........................................................................................... 79
Business Case ........................................................................................... 89
96
Plans ....................................................................................................... 106
Controls .................................................................................................. 115
144
Risk ........................................................................................................ 151
vll<lJ.!I".C Control ...................................................................................... 167
).u.<>uQI'.,,>llv'....................................................................... 176
Product·Based 203
Review ...................................................................................... 209
lVii:lJli:l.!:;Clll,IJU, Team Roles .......................................................... 220
Product .............................................................................. 239
Forms...................................................................................................... 300
- IV
!"ll1.lL"<;;1lle; the PRINCE2
edition June
Introduction
What PRINCE2?
PRINCE2 is an acronym, standing for IN Controlled
Environments.
owns
The method is owned by the OGC ofGovernment COlrnnJlerce)
T-a""'~'department of the V.K. The OGe has an
on-:I!:OlIlg commitment to the currency of the method. Use of
is free to end users. Those to offer such as
products have to for a licence.
History
l1l.i:!.Ill1gc:ruc:m
was based on IT
evelopme:nt and so on. The
me'thOIi10ilogy for made
Me:tbcldS) set ofIT

it did introduce the technique of
~"".-'_•• II •• stood for IN the
"'''..1<111I':I;;Uto make it more suitable for
use.
In 1996 there was a revision that saw the emergence
now a generic method with the set ofnrocesses that we see
Who uses
and the Far East.

have mcorporated
standards.
- 1
Managing Projects the PRlNCE2 Way Introduction
(revised edition June 2005)
Users in u.K. include the AA, The London Stock Exchange, Tesco
Stores, ECGD, Rolls Royce, Post Office Counters. The Royal Air Force,
Glaxo Wellcome, the National Westminster bank, most police authorities,
water companies and other utilities. There are many more. Over 100,000
people have taken the PRINCE2 Practitioner examination in the U.K.
alone.
Benefits of the PRINCE2 project management method \'c
• The method is repeatable;

• The method is teachable;
• It builds on experience;
..,.,
• Everyone knows what to expect;
~~
• If you take over a project in the middle, you know what documents
to look for and where to find them;
• There is early warning ofproblems;
• It is proactive not reactive (but is prepared to be reactive to events
- illness, pregnancy, accident, external event).
.;I;;
Organisations are becoming increasingly aware of the opportunities for
adopting a "project" approach to the way in which they address the
creation and delivery of new business products or implement any change.
They are also increasingly aware of the benefits which a single, common,
structured approach to project management - as is provided through
PRINCE2 - can bring.
What does it cost?
Use of the method is free. No licence fee is required. It is owned and Io "'-:!""II
maintained by the Office of Government Commerce, so use of the

PRINCE2 logo requires their approval. Anyone wishing to use material
contained in the manual must apply to HMSO.
Costs of implementing the method would be mainly in paying for training
in the method There are over 30 training organisations that offer training
in the method. Most of them include the cost ofthe manual, £55, in the
training charge. Apart from the manual there are other books available
that describe the method. Some cover the whole method, others tackle
specific areas or uses of the method.
Examinations
Examinations in the method are available. There is a Foundation exam, a
75 question multi-choice paper of one hour's duration. This is mainly for
-2
Prn,,,('hl the PRINCE2 Way Introduction
those on the assurance

and internal audit or PRINCE2.
But it is also for those who more minor roles in a than the
manager, such as project staff or those for whom the
is a solution.
manaj:~ers there is a Practitioner exam, a three-hour paper,
Quc~sn,ons based around a scenario. Success in the
a orereouisite for entry to this exam.
All the accredited training offer the exams. The papers are
set and marked the APMG for
which the examinations and accredits traltnlIllg
",,!;£l...''''''''UVI..., on behalf ofthe OGe. The examinations are recogJl1SE~
v"'~;.uv,.." the world and advertisements for
managers ask for in the method.
More InTrU"lm
Websites with more information are and

There is also a very active chat group at
-3
Managing Projects the PRINCE2 Way Introduction
An Overview of PRINCE2
PRINCE2 is a scalable, flexible project management method, suitable for \.

use on any type and any size of project. It has been derived from
professional Project Managers' experiences and refined over years of use
in a wide variety of contexts.
~ey Princip-!es
There are two key principles of PRINCE2 that you should grasp as the
basis for your understanding of the method. =
o A project should be driven ~~its Business Case
You shouldn't start a project unless there is a sound Business Case
for it. At regular intervals in the project you should check to see that
the project is still viable and stop the project if the justification has
disappeared.
<2> PRINCE2 is prQctuct-based
."!
PRINCE2 (Q9.us~S on the products to b_e Pt:p.Quce<;Lby ilit( proj!:ct,
'._npt the activities to producetb.em--:'\This affects its method of
planning, many of its controls and its approach to ensuring quality.
PRINCE2 gives:
• controlled management of change by the business in terms of its
investment and return on investment;
• active involvement of the users of the final product throughout its
development to ensure the business product will meet the functional,
environmental, service and management requirements of the users;
• efficient control of development resources;
• active management of risk and quality throughout the life of the
project; (i·iif;
~
• active control of all products and changes to those products;
• a controlled start, controlled progress and a controlled close. .~~~
So that is how its users derive the benefits mentioned in the Introduction.
,,- A key approach of the method is that it firmly distinguishes the
", management of the development process from the techniques involved
\ in the development process itself.
4
.~
Managing Projects the PRINCE2 Way Introduction
'.'l~
Structure of the PRINCE2 Method
There are three parts to the structure oftb~ method itselfr.
it • Proce§~
- -
• Components _
• Tec~!!.~~_
~
.
PRlNCE2 offers a set of Pr~s_ses that provi.4~ JL@lltrolled.start, - ~~~~

controlled progress and a controlled close to any P!"9ject. T.he_ processes~- wy;
explain y.rhat should happen, wn en it si:to!Jld be dolle and by ~hjc4 role.
PRINCE2 has a number of~omponents to explain its pJlllosophy a.b.out _ .,!"/' .'
various project aspectsL~uch.as...OIganisation,...risks..andplans,-w.h.y-.they - h0 vJ
fA
.".
are n~.eded and.ho."Y' th~y ~~~.used. 'D¥s p,hilo.sophy is imJ2leIl1~nte(L
t:lll'Oue the p~~Jia
~ '"4 _ _ _ _
PRlNCE2 offers onlY,..~.J~w Iecbniq~. The use ofmost of them is
P' optional. You may already have a technique that is covering that need
satisfactorily, such as quality checking and change controL PRINCE2
.,'.' works happily alongside such in-house techniques . The exception is the
,='''-:-:' product-based planning technique. This is a very important part of the
PRINCE2 method. Its understanding and use bring major benefits and
every effort should be made to use it.
{f,{
~
'l CHANGE BUSINESS

CONTROL CASE 1
~
ORGANISATION
_. PLANS
CONTROLS
'1
Figure Ovl PRINCE2 Componen.!,L

~)s'
5
'"
the PRINCE2 Way Introduction
The of project management are described in processes, vvhich

are summarised in Figure Ov2.
Project MaMa'"
Project Brief
~
,End SllIge R_rt
LssSlOrtS Laemed
~g~~~1 . """,
PRINCE2 Processes
run under PRINCE2 vvill need to address each of these

processes in some form. the to successful use ofthe
process model is in it to the needs of the individual Each
process should be with the question "How should
this process be on this
... a
This process is aimed at the senior managemem
_ the decision-makers. These are
should be involved in the process of a project.
PRINCE2 them achieve this adopting the philosophy of
. The DP process covers the to be taken
6
Mam8.!~g 1J.."" .....t< the PRINCE2 Way
the
fiUUlUIJlilllg the of a Plam amd Business Case for the
remains justifiable at in the
• advice as reClUlJred
comes to a controlled close.
2-~''''''iin ...
This is intended to be a very short pre-project process with five
• and the project ma:na~:emlent

• Ensure that the aims ofthe project are
• Decide on the approach which win be taken within the to
provide a solution; .
• Define the Customer's Quality Expectations;
• Plan the work needed to draw up the PRINCE2 "contract" between
customer and supplier.
Inithlltin" a Project UP)
~-
a there will be mamy of:

• work to be done;
7
the PRINCE2 Way
progress information about that

n'''~'''h;,"n for 1,;1l~Wgl,,~
the situatton:
/!'
~ noting useful lessons in the Lessons Learned

r. any necessary action.
The process covers these the work of
manag;ement of risk and
_ Managing Product Delivery
ofwork
The process covers:

sure that work allocated to the team is authorised and
)'! plannmg the team
• that the work is done;
/"" that meet the
," on progress and to the Project Manager:
• of the finished products.
(" Managing Boundaries
The of this process are to:
• on the outcome and of the which has just
ended;
• the next
• update the Plan;
• the Business
• the risk assessment;
• obtain Board to move into the next
8
IVUU1"~.Ille, Pr01ects the PRINCE2 Introduction
t(m~Callt. the Board may

Plan (See the
LA\,o;;;PI.iUll
"Controls" This process also covers the

needed for that.
""1- Closing a (CP)
The process covers the work to
Board's to close the either at its natural end or at a
premature close decided the Board. The are to:
- note the extent to which the set out at the start of the
have been met;
.. confirm the customer's satisfaction the products;
- confirm that maintenance and BUllDort are in
/111 make any recommendations for foUow-on .:u.;t.lUlJ.lj;
ensure that aU lessons learned the are annotated for the

benefit of future
/- on whether the itselfhas been a
success or not;
- prepare a to check on achievement of the claimed
benefits.
2.. (PL)
'~"J~~!;.O"', used several of the other processes
process makes use of the PRINCE2
product-based and covers:
/ uCSlgmng
.. and analysing the
.. the necessary activities and dependenCIes;
.AI estimating the effort
- resources;
.. l'Inl'llv";\lna the
its and the steps.
rI..li'lvnk are:
9
Introduction
PRINCE2 is on that a Business

The essential contents are defined and linked
processes when the Business Case should be UDdatecl or
Organisation
PRINCE2 nroVldes the structure ot a nrOlect management team. DIUS a
definition
involved in the . v
and of a these roles can be combined or

Plans
PRINCE2 offers a series levels that can be tailored to the size and
and an approach to planning based on oroducts rather
PRINCE2 has a set of controls which facilitate the

_ _ the _ .
and make decisions on problem resolution. For senior
manall:em.ent PRINCE2 controls are based on the of
, i.e. if we agree a plan, let the
on with it unless is forecast to go wrong.
o Risk
Risk is a factor to be considered the life of a
PRL""JCE2 defines the key moments when should be reviewed
outlines an to the and and tracks
these all the processes.
r
i.;
PRINCE2 and ;,.,,,,,,....,,,,,",,t.,.
U:::CIIWI.;(U processes. It
EXDec:tatiom and follows these up

ill~,IJC\';UL'J.j methods to be used. and
'\
orcdulct and their versions for release
Illi1lli:1gclm:m. There are many methods of
Corl11gura1t1.0D .!..U.Q.w>~;vU.Jl"'llL
available. PRINCE2 does not to
defines the essential facilities and information
10
Introduction
irements for a management method and how it should

with other PRINCE2 components and teclm.!qUE~ .
•n""nn,,,, Control
PRINCE2 emohasises the need for change control and this is enforced
control techniQue olus identification ofthe processes that
Book
gone an Introduction and Overview of the llil;;W.VU,
book will focus on the processes as the main theme. This will nr(',V'irlp
skeleton and a general project timeframe. Where lIrn"l'fOnri::ltf>
be links to the Components and to ofForms
used in the processes. The book also LU.'"'" ........"
PRINCE2 roles.
11
the PRINCE2
Up a Project (SU)
Top-Level
OUTPUT
SUl ExecutlV8
Project Manager
Projeet Mandate
the Project Manager
Project Manager
Job Descriptions
t.A!III"I~1'T'WCII
and names
SU4 Project Brief

Projed Mandate
Risk Log
PI'<ljec:tSrlei ProjeetApproach
SU6
Happens
process. It is not a Its job is to make sure
have to start a and someone who can
if that information is sufficient starting.
12
edition
• instruction or is
Mandate);
• Semor~m~geInelrt someone with sufficient authority to
be resl)onSlDl ' the project and its
• Semor lillIJ.Ili~t:illt:.m to the

Executive
controlling the
• The and Project Manager and the
remainder of the management team;
• The completes (or confirms the existence
terms of reference for the project with the
~w,~~~ofthePv'~~.~~~'
• The Customer's tx:pect2Itl(lDS are iripnht,pri'
• Themethod DrOVlCl1nI!: a solution to the problem

AOOK)aClllisl~~u~u~~,
• The and enters into it any risks

ofthls process;
• The olans the imtiation
To establish:
• What is to be
• Who will make the deciSIOns;
• Who is the project;
• Who will say what is needed;
• What aualitv standards are ''"'''ll~''''''
• Whowill the resources to do the work.
13
Startinl!: up a
- Appointing a PB Executive and a Project

Manager
What in the ::iW'-PI"OCIElSS
• ~or programme management
prclgr:mnne) --~~.-~- the Executive and
Why
Corporate manag~ement
But every ,.,,.,,,,irl.,.,.
dell;:gate this role to a
this person is also too
Ga,\(-toH12lY basis. So we need a
and control. We need to
anvthinl! can MDDen (in a controlled "'''''' .......,
a
·...,.,,,...."'t,, or programme should appoint these two roles.
14
the PRINCE2 Way upa
Links to
other
of the
... corporate or management the
Executive to resnonsible for the
... Either management or the

Executive or both identify a suitable Proiec1 lYUI.Ilii/!,t:l
... The standard PRINCE2 role are tailored I Team Roles
discussion between senior mana2ement. the
Executive and
In g
..' " - ; ....'''
The Executive should have strong links with the senior ~t:melll
group responsible for this appointment. Ideally for major the
Executive should be one of that senior mana!~errlenl
of the programme management team. It is necessary to
bond of confidence between cOI'Polrat~~/PIorora.rrtme mana~:emlent
Executive. This person will be
the level of management wants to check every decision made
the Executive. this will slow down the whole process.
and bark The between the
be similar to
Le. "As as
work is prclgn~ssJmg on with it. We
back you up."
For Small Projects
A small project is more to be stand~alone. There may be no
or prograntme involved with the In this
case the sponsor becomes the Executive default and would annoint the
Project Manager J.1",.,"VJJ-UU.J
SU2 - DeSigning a Io"rl"lIDI""
What Happens in the

The Executive and Manager:
15
Managing Projects the PRINCE2 Way Starting up a Proj ect
• Propose the other Project Board members (unless these have (,
already been selected by corporate/programme management);
• Discuss with the prospective Project Board members whether they
will need help to carry out their Project Assurance responsibilities;
• Design any Project Assurance roles that are to be delegated;
• Identify candidates for any delegated Project Assurance roles;
• Identify any required Team Managers;
• Identify any Project Support requirements, particularly a
Configuration Librarian.
Why 1""0
The complete project management team needs to reflect the

interests, and have the approval of:
o Corporate/programme management;
o The users of the final product, those who will specify details of
the required product;
o Any other stakeholders;
o The supplier(s) of that product.
Project Board members must decide whether they want independent
checks on their particular interests in the project as the project
progresses (the Project Assurance part of the role), or whether they
can do this verification themselves
The Project Manager has to decide if any administrative support is

needed, such as planning and control tool expertise, configuration
management, filing or help with specialist techniques.
Responsibility ( -c;.
The Executive is responsible for the work of the sub-process, but is "
likely to delegate much of the work to the Project Manager.
How I Links to
other parts
of the book
• Identify customer areas that will use or control the end I Organisation
product, the commitment required and the level of
authority and decision making which is suitable for
the criticality and size of the project (Senior User) I......
)
16
• who will provide the end (Senior
,,~.I;~p\ and the level of commitment and authOlity
ltA.J'IJ.ll~;U from them
• candidates for the roles

• Check out their availability and agreement
• Check whether the Project Board members will carry IVl:~<L.lll:S~UJUU
out their own Assurance respollSU)1l1ty
• lTV to find out what volume
the Ifit is I Control
proIPO!~edProject Board ifthev want to appoint a
L-nange to han'dle
• candidates for any IRoles
functions which are to be ..."'''5'''......
• Check out their i:l.Vi:lWi:lJOlilLY
• Decide if any staff will be n;;'luu ..... Roles

• Identify resources for any required
In Practice
;oflPorate.!PI1:lgramme llli:l.llU~~Cli.lCllL may have defined some
particularly where the
is
If the is of a programme, the use of the

assurance and functions may be lDl'DOSiea,
of many different user areas is

IIl,wagf;:lllf;:]1l1 for
ret)re:sen:tation, it may be more effective to form a user
"'''T'T''''''''nt~ all their interests on the
In theory the Board should decide on what action to take

Issues. lithe volume of submitted is likely to
be the board may choose to appoint a to
assess all Issues on their behalf. This
for as those cbare:ed with
17
Managing Projects the PRINCE2 Way Starting up a Project
(revised edition June 2005) ~
as 'No more than X on anyone change, no more than Y spent in any ' .':";"
stage without reference to the Project Board.'

""<I
For Small Projects
It would be normal for Project Board members to carry out their
own Project Assurance. In very small projects the Executive and <""
Senior User roles will often be combined. If a department is
developing a product for its own use and all the. project's resources
are from that department, the Senior Supplier and Senior User may
also be the same person as the Executive.
SU3· Appointing a Project Management Team
~
What Happens in the Sub-process?
• The other Project Board members, any required Project Assurance
and Project Support roles are appointed. There may also be Team ~
Managers to be appointed, particularly for the early stages.
Why
A job description for each member of the project management team
needs to be agreed with the individual.
After the project management team has been designed, the

appointments need to be confirmed by corporate/programme
management.
Responsibility 'J"fJ.."
Executive, assisted by the Project Manager.

How Links to
other parts
of the book ""'"
The project management team design is presented to
corporate/programme management for approval (
The Executive informs each project management team
member of their appointment
The Project Manager discusses and agrees each Team Roles
member's job description with them.
In Practice
Each project management team member signs two copies of the . ~
agreed job description. The person concerned retains one copy, the
. ,,":",
18
·;i.
thePRINCE2
files. This ensures that there is no

:poIlSible for what.
There may be no need to get approval from any

,,"t'hn,.. tv than the Executive. There may be no
funCtiOIlS. Board roles are to be amalg.am,ated,
sufficient to use the standard role t1f'~:C'T1nt1,,",n~
n§,rl"n a Project Brief
Haooens in the Sub-process?
• Fills in any gaps in the Mandate that was handed down.
To eIlSure that sufficient information is available for the

Board to decide if it wishes to oroceed into initiation.
The is respoIlSible for the

Mandate and collecting any missing details.
I links to
other parts
of the book
compare the information available about the re nll ,,.,,,Ji
_ the information the
Board in order to approve
Advise the Board how DPI
for the
Gather any information
Create the Risk Log for the and add to it any Forms
risks shown up in the Project Brief
Check the outline Business Case with the Executive Business Case
Product
Description
Practice
Mandate is a term to describe the for the
The Project Mandate handed down to the Project Manager
may be a full soecification of the problem. a written reauest to
19
I ,._ •• y-~ _~"V.L ~"VJ
.......- J
"""'''WI,,", about .... " or even a verbal

l
l<O\.l,,""L. The tasks of the SU4 will be to tum this
whose fonnat there may have been no control by the
into a Proiect Brief. a set of terms of reference.
ofa have
~Vl<W4,""! should remember that it is a of

the to the
UHwal-;"l should check out the Brief

members to ensure there are no before
For Small .. rt'lIIRII'!T~

There may be pressure on the to on with the
and start with terms of reference. This should be
resisted as it opens up the later on what
the was to do The also
needs to know how much the solution is worth in order to make
annronriate occur later.
- Defining IIo"r,..,..""'·T
.. Decide on what kind of a solution

.........,,,;.rt,,rl and the method
.. Iflp,nhtv the skills the
.. Iflp,nhtv any of the Approach.
The main to be considered are:
.. Build a solution from SC;UI.WU;
.. Take an oroduct and it;
.. Give to another to do for you;
..
Why a solution off the
Approach will affect the timescale and costs of the

its scope and This information should
20
In~ll.l~ the PRlNCE2 Way upa
be made available to the Board in deciding whether to

initiate the
A check should be made that the proposed is in
line with the customer's (or nr;IO'r~!mlnf'1 CTr<.TPC."
Responsibility
The for the assisted
any and ",~..,...,,,.u,,,.
How Links to
other
of the book
WC:DtllY any money, resource, support or extension
Check for direction or on Project

earlier documents such as the
Mandate
any constraints
Check for any statement of
direction which choice
Consider how the might be into use and

whether there are any which would impact the
choice Approach
Produce a range of alternative
loennry the needs of the alternatives
Comp'are the alternatives against the gal:helred
information and constraints
a recommendation Project
In Practice
The customer needs to think very about the
";;~"IJ.,nn.ll.I of the above information can avoid the
into a Approach which is favoured
21
,
Managing Projects the PRINCE2 Way Starting up a Project
by a supplier, but which twns out to have later problems for the
customer, such as lack of flexibility or maintenance difficulties.
~
For Small Projects
The question is equally valid for small projects. The pressure to start
work on a solution may lead to pressure to not perform this sub ""
process, but this should be resisted.
SU6 • Planning an Initiation Stage

• Produces a plan for the initiation stage of the project
~
Why
~
Investigating and establishing a foundation for the project and
preparing a document to get approval to start the project is important
work. It needs planning, and since initiation will consume some
resources, the Project Board should approve the plan for it.
Responsibility
,~
The Project Manager.
How links to
other parts 3€ '\iII
of the book
Examine the Project Brief and decide how much work is PIDProduct (i!,::.
needed in order to produce the Project Initiation Description
Document
Evaluate the time needed to create the Project Plan Planning (PL)
Evaluate the time needed to create the next Stage Plan C
Evaluate the time needed to create Or refine the Business
Case ..~iii.
\,,"
',:. ,r:,;
Evaluate the time needed to perform risk analysis Risk

Create a plan for the initiation stage Planning (PL)
Get Project Board approval for the plan DPI
In Practice
The initiation stage should be short and inexpensive compared to the
,t.~~.
cost and time of the whole project, say 2 or 3 percent of the whole.
22 , ~.
StSlrhrlO' up a Project
ll-WoU"'f,"""''''''''' team and risk

a refinement of the Business Case and the Plan. The
_ Plan should show the effort and resources to
generate the extra information and the plan for the next
Ifinformal communication with members of the Board is to

be this can reduce the need for formal
reporting.
For Small D .....I.. ,...+",
Initiation take a matter of an hour or two and therefore

may not plan.
23
Managing the PRINCE2 Initiating a Project
(revised edition June
a (IP)
Authorised
Plan
IPl
'" The tl~IJUIl:SlOl1l{Y and methods and tools to be used

are aennea;
'" Thewhole is Planneo

'" The controls for the are eSralJllS.m::~
.. The existence of a viable Business Case is cOlllfiJrnl!ed;

'" The risks the are re-assesseit
'" All the decision-makers agree to continue the
All stakeholders with interest in the project should reach a."...,.",.",..,t

before starts on what is to be done and
done.
24
Managing Projects the PRINCE2 Way Initiating a Project
"'. (revised edition June 2005)

How
r---------------------~
: IP Initiating a Project
I
I
....
"".
~
no"
~P1an
PID
Figure IP2
~~ IP1 - Planning Quality
• The quality expectations of the customer, the quality standards of
both customer and supplier are taken, plus the Project Approach
and the necessary standards identified of how the quality expected
by the customer will be achieved.
" Why
To be successful, the project must deliver a quality product, as well
as meeting time and cost constraints. The means of achieving quality
......... must be specified before work begins.
..- Quality work cannot be planned until the customer's quality
,0 ' expectations are known.
The time and cost of the project will be affected by the amount of
quality work that has to be done; therefore quality planning must be
Q,:
done before a realistic Project Plan can be produced.
~ .
25
...
InitiatiJ:lg a
Responsibility
Assurance
Links to
other parts
of the book
Establish the customer's expectat
144)
Establish how will be achieved
Establish links to any or programme
assurance function
Establish what the customer's quality lil<lJ..UU,,;;WC"llL
is
or set
what
H.1"'ilLl.I ¥ set of techniques, nrocedures and
standards best suit the needs
Decide ifthere is a need for an mdtep~~ndlent
assurance function to have on the
=""-"'-l5".l."""'LIL team
quality
.A"",;«uu ¥ for Team Roles
both the Senior User and Senior 1.>",)1)"""1
Create the
Librarian's
role
In 1I:)..12...+i .....
For in-house there may be no doubt about the
standards to used, but where customer and are
different it is to agree and document which
standards will be used. In such it is that the
nu.....a6"'1 sp~:cnles how the of the from the
this would be done
26
Man8jlpng I'''''>lPl''r", the PRINCE2 J.U5
LlliU..... a
renlemlber that the Senior .::IU~'IJIl!Cl

ofproducts from
reslPoIliSible for the quality and COllllDh~teIlless ofuser-
supplied such as the and test
plans. The Executive is for the quality Business
Case. ofthese help Dersuade the
Board members to take their duties
consideration must be
furthe~v~~lall~~nT{'ffi'M~
either
group may use a

want you to be cornpliltible with that for ease ofhand-over. The way
to meet the ofthe
should be in IPS). Part
who will have the role
For Small Projects

Even if the customer leaves the quality "1.1'_"AJ.U5
there should be customer involvement in
environment and the test situations with
successfully cope.
Even in small
" .. -~ .... ,.- even role is taken on a "'''''T_''''''''''
member - or even the Proiect nULll<l,5""
IP2. PUmn a Project
• Produce the Plan
Why
of its decision on whether to proceed with the the
Board needs to know how much it will cost and how long it
win take. Details of the Plan also feed into the Business Case
to indicate the of the
27
The Proiect is res~ollSi'ble
maybe any
be checked with those out
Assurance narticularlv in terms ofthe aualitv work.
How
Use the process to create the Plan
Review any constraints

the
Decide on a suitable breakdown of the into
Check that the Plan meets the ofthe !PI
Plan
Check the plan with the Board
In PrJi!lr.tir.~
Plan is needed. If you don't know what you are

IJlQJlJJJ.ll)!; to do and when you are planning to do it, you have no
control.
for Small Prl'lOiail'te:
If the Plan can hold sufficient detail to allow """-",-",,,,

control it may not be necessary to produce Stage Plans. The
Ln'1LI.<I)!;t;1 should decide at what point the inclusion of sufficient
makes the Dian too large to grasp in

IP3 - Dafini the Business and KI!UCS,S
Happens in the 5L1b-ClrOlce,e~?
• Take whatever outline Business Case exists for the

the and create a full Business Case for mCIUSlon
the Prolect Initiation Document:
• and plan the risk management for the
28
.I.ll!Ua.I.!lll'; a Project
L_'"
Before commitment to the project it is to ensure that there

............."',u jllstific~ltion for the resource It is also
irl''Il"n1''i,,,,.,t to check that the risks involved the are
or that plans have been made to reduce or contain
the
Responsibility
The for the Business Case rests with the Executive,
probably with of reasons from the
How Links to other
of the
If an outline Business Case was included in the Business Case

!,,!/lLllU<:I,U;;, check if its circumstances and
assumptil)ns have "'Ll411,1;;"'U

illY':;;).!,1;;"." the work reasons for the with the
customer
y,",o.L1JO',a<", the business reasons for the project with
the bXleculllve
,<W1.UU1Y the benefits wherever VV1>1>1UlC Business Case
Ensure that the claimed benefits will be measurable
after the enters its useful life
Measure the situation today so that accurate IPPR Plan
can be made when it comes to the Post- Product
Review
nN)rn.'\n:!'tp the costs from the Plan
Risk
Plan to reflect any caused
In PI'JIIl'!til'!A
llVHlla11Yhave the work

to the Business Case and risk
If the is part of a programme, the nffi,arnrnnlP

the overall Business Case. In such cases it may
29
-,

Project Initiation Document to point to the programme's Business
Case.
For Small Projects
It is easy to start small projects without confirming that there are
good business reasons for doing it. It is important, however small
the project, to go through the exercise ofjustification. Otherwise,
late in the budget year, it may be found that several unjustified
v'-'
projects have consumed the budget now needed for an important ,...
larger project.
IP4 - Setting Up Project Controls

1'!'
:i)lI
• Establishes control points and reporting arrangements for the
project, based on the project's size, criticality, risk situation, the ....,
customer's and supplier's control standards, and the diversity of
interested parties.
The most important control is the breakdown of the project into
stages. The end stage assessment is the key control for the Project ~
Board to decide if there is still justification to continue with the
project. Linked to stages are the tolerances for that stage, so that the ""'~
'-'t·;
Project Manager can give early warning of any serious deviations
that are likely to exceed these tolerance levels. This should have a
reference to the exception procedure to be followed if a deviation is
''''<;
forecast. Highlight Reports are another control for the Project Board.
If external suppliers are to be involved in the project, it is worth
writing into the PID how suppliers will be controlled. This covers ("~
the agreement on Work Packages, updating of the Quality Log, the "
creation of Project Issues, Checkpoint Reports, procedures for the
....,
return of work and the involvement of the Senior User's Project
. '~~J'"
Assurance function in checking supplier work.
Why
In order to keep the project under control it is important to ensure (0;:,
that:
• the right decisions are made by the right people at the right time; ,.
• the right information is given to the right people at the right
frequency and timing.
~':,
30
~~:
}I
The breakdown of the project into stages may be encouraged by
other considerations than just the project size. Examples might be
risk assessment, major cash flow moments (invoice payment,
invoice submission), and Project Board membership changes.
Responsibility
,:,.1 The Project Manager is responsible for establishing the monitoring
and reporting necessary for day-to-day control, and agreeing the
correct level of reporting and decision points for the Project Board
to ensure management by exception.
How Links to other
parts of the
book
Agree the stage breakdown with the Project Board Project Controls
(~ Agree the format of reports to the Project Board Highlight Report
Agree the frequency of Project Board reports Project Controls
Create a Communication Plan covering required input
and output information during the life of the project
Check that there are sufficient risk and Business Case I Risk
~.
".
monitoring activities in the plans
In Practice
If there are comprehensive control standards in existence it may be
"s' sufficient to point to the manual containing them, mention any
which will not apply or detail any extra ones. The frequency of
reports and controls should still be agreed for the project.
i~,
" For Small Projects

It may be acceptable to the Project Board that many of the reports
are given verbally. But there should always be a formal initiation
and a formal close.
<".
IPS - Setting Up Project Files
• Sets up the filing structure for management records for the project.
Filing or storage needs for the specialist products will depend on
the type of products being produced.
31
1lllmmng a
lmt'll""rtll"t to retain details

agreements. These details may
to the Lessons or
record of what when and This is
rel:aU<lnSnIt)S between customer and o,,~~l;~
because example, Olspmes on scope or costs.
Responsibility
The is may do the
work if such resources have been made available.
How Links to other
parts of the
book
Create the Issue vllalll';'" Control
Create Droiect and stage files
lmplement the ofthe Confil~·atJ(m

MaJrlagl~me.nt
Plan
Set up a blank Lessons Learned to record useful Lessons Learned
LilL'JU".uV''''' the
In .....'....~il ...'"
This is the time to set up the identification scheme. It will be
needed as soon as uroducts are identified in or()du.ct-bal';ed p ...u.u .....o.
For Small Projects
A full-blown method may not be
to some kind of version
control.
• Assembling a Project Initiation Document
What HaDDens in the
• Gather the information from the other IP Su[J-plrocess,es,
Initiation Document and invoke the
Boundaries (SB) process, which will create the
next Plan.
32
The Initiation Document all the information
needed for the Board to make the decision on whether to go
ahead with the or not. It also forms a formal record of the
information on the decision was and can be used after
the finishes to judge how successful the oroiect was.
Board makes a general decision to with the

it needs to have more detailed information about the costs
and time of the next stage before the reQuired resources.
The
the next _
and the advice of those with
How Links to other
_ of the
book
Assemble the information PID Product
Description
Decide how best to present the information
Create the Initiation Document
Invoke Mana!rin2 Stage Boundaries to
the initiation
Plan
Distribute the two documents to the Communication
those with Assurance and any others as Plan
directed bv the Proiect Board
Discuss with the Board whether it wants the

Initiation Document to all the information in full, or whether
certain sections, such as Product and job
can be referred to but not included.
The PID the baseline which the achievements of

the project will dynamic, so that
occur as the lifecycle will the PID
changes that the user has
33
Vrn,,,,,,t,, the PRINCE2 mmal:mg a Project
edition June
For Small Prt"lieo,l"'tet
The Initiation Document should be a small document. The

Uescrlptlon ap[)endlx describes a Initiation
can be used for small prol1ects
If the oroject is so small that there is only one after initiation, it

1-.I1.}0'"11.}1''' to the detail of the next stage in the
it is a seoarate
34
Top-Level ~~~~~~~~~~----
Corporate or programme
management
Happens in the Process?

The Board
II Confirms project tolerances with COI:poratl::lpJrog;rarnrnle
II Authorises
.. Liaises with <"Cm-nnrnt,f'!/nmll'TllTnrrle llJaDagl;mIlent;
external business events
II Aonroves Stage
II stage
II Decides on any to ",.,..,rl'l1JPr\ D!CIOUI:;ts:
II any Exception
II Gives ad hoc advice and direction the project;
.. the interests of the customer and supplier;
.. closure .
3S
lYla:nagmg the PRINCE2
I"V'_rn_I1~'v
management is left to the Project but the
_ Board must exercise overall control and take the
decisions.
DP2
or programme
DP1·
Happens In the Sub-process?
The Board:
• Checks that adequate terms of reference exist
• Checks and approves the initiation Stage Plan
• Commits the resources to carry out the initiation
work
The initiation confirms that a viable exists and that

concerned agrees what is to be
"'Vf.rv,nn.IV Like all project
the effort to do this needs the approval ofthe Proiect Board.
Responsibility
The Project Board is based on information by
the Project ManlU!er and those with Proiect Assurance
36
Managing Projects the PRINCE2 Way Directing a Project
How Links to other
parts of the
','(.,1 book
!\.
Confirm the terms of reference, checking if necessary Project Brief
with corporate/programme management Product
Description
Check the initiation Stage Plan and approve it if
satisfied
'"
Confirm project tolerances with corporate/programme I Controls
management
.,.,., Agree tolerance margins for the initiation stage IControls
Agree control and reporting arrangements for the
initiation stage
.,":'
Commit the resources required by the initiation Stage
Plan
In Practice
The Project Board should expect to be heavily involved in the
initiation stage's work, and therefore should check on and advise the
:.t;;~ Project Manager of its own availability during the stage.
For Small Projects
This can be done infonnally if the Project Board feels that that is
suitable. The stage may be so short that no reporting during the stage
is required.
~
DP2 - Authorising a Project
The Project Board:
• Decides whether to proceed with the project or not
• Approves the next Stage Plan
Why
The sub-process gives the Project Board a decision point before
major resource commitment.
37
,.'
--
Managing Projects the PRINCE2 Way Directing a Project
Responsibility
The Project Board with advice from those with Project Assurance
responsibility.
How I Links to other
parts of the
book \
.....
Confinn that the project' s objectives and scope are Project Brief
clearly defined and understood by all
Confirm that the objectives are in line with
corporate/programme objectives
Confirm that all authorities and responsibilities are Team Roles '.~
agreed
Confirm that the Business Case is adequate, clear and, I Business Case
wherever possible, measurable Product
Description
Confirm the existence of a credible Project Plan which I Plans
is within the project constraints
Check that the plan for the next stage is reasonable
and matches that portion of the Project Plan ~~
'.'.'~
Have any desired changes made to the draft Project
Initiation Document
Confirm deviation limits for the project and the next I Project Controls ,;\2:'
stage
Give written approval for the next stage (or not, if
unhappy with any of the details) ....
Arrange a date for the next stage's end stage Project Controls
assessment
In Practice ~
The Project Manager should have been in regular informal contact ~
with the Project Board to ensure that there will be no surprises when :,1
the Project Initiation Document is presented. If this contact has been

maintained, the above list should be a quick confirmation.
~
~-;;
If some minor item in the Project Initiation Document needs further
work, but in general the Project Board is happy, approval to proceed
can be given with the proviso that the corrective work be done
usually with a target date. ~
38
Managing the PRINCE2 Way a Project
'CC_ -- - - _____e ~'____ _ _ _ _ _ _ _ _ _ _ _ _ _ _
edition J__un_____ ___.J
often the with day-to-day

duties that it is not easy to arrange an end assessment at short
notice. It is better to DIan the next end staee assessment date at the
end ofthe nrpv1r\11
For Small D_A_'_."
The Initiation Document details may have heen discussed
and to of time. It may be
sufficient for the when the last
of information presented without a full presentation.
to should still be confirmed in as an
imnnrt<lnt document.
a Stage or EXJCe~'tl(l.n
What nall.lLlltUI'l:>
authorises each
n..n.rn(',P';!" llllUilLiUll) and any
Plans that are needed.
Why
An control for the Board is to approve Only one
at a time. At the end of one the Project Manager has to
both progress so far and the for the next stage before
allowed to continue.
The ""h.nr""""" based

on information proVloea
from any separate
How Links to other
parts of the
book
CO:lIlpare the results of the current the
Plan
Assess progress the Plan
----"-'-'''''-. of the next Stalle Plan
Review the ........,..,,,•.,,t.;, achieving the Business Case

Review the risks the Risk
39
Get direction from management Controls
if the is forecast to
is a to the Business Case
Review tolerances for the next
Review reporting for the next stage
Give approval to move into the next (if satisfied)
11'1 Practice
The Board can for any reason, e.g. if the
Business Case becomes tolerances are to be
exceeded, nroduct unacccpuwle. or the risks beC;OITle
assessment date was some time and

actual end of the Project can
pr01cee:d. based on one or more target dates
current
If the stage fmishes before the assessment date, interim

approval Cart be to do some of the next stage work before
formal approval is In such a case, the Project Board would
clarify what work was to be done before the assessment, rather than
give carte blanche to the
For Small Projects
The decisions Cart be made lIllullllauy Board should
still carry out the above activities
- Giving
" Advises the lVlaJl!t}.!;er about any external events which

the
" Gives direction to the lVl3Il.ager when asked for advice or a
decision about a
" Advises on or approves any to the project management
team;
" Makes decisions on the actions to take on Exception
40
AJ ......'.. w;uJO; a
edition June
Why
There may be a need for occasional Board direction outside
end stage assessments.
Responsibility
The Board.
How links to other
parts of the
book
Check for external such.as business changes,
which affect the Business Case or risk
exposure
Monitor any allocated risk situations
Make decisions on any .t;;xcej:ltlOin Controls
Ensure that the project remains focused on its
()hi~rrivp_<,'l and achievement of its Business Case
corporatel'prclgI1llI11lJne rrtanl~geJmellt advised of

progress
Make decisions about any necessary to the
mama,gelnellt team
Make decisions on Issues to the ,-,ua..u~~C Control
attention of the
In Practice
The kev activity in this what action should
!Cl.luc"""for and off-
~p"',",Hjl,",a.'.J.VLl"'. The to be followed should have been
and docummted in the Initiation DOCUnlmt.
This encourage interference with the

work of the Project The need for Project Board direction
either a probleJm in a
or an Keport, or an external event that it is momU)TIIl
behalf
For Projects
It may be sufficient for the Project Board and to
agree informallv how to action a Proiect Issue as soon as it is
documented.
41
gll"""ial"'t
What Happens in the ~lIh_rlrl"l,"'''~u:.?
• Checks that the have been

• Checks that there are no loose
• Advises senior of the project's tennination;
• Recommends a for on achievement of the ext)ected
benefits.
There must be a defined end in a in order to its

success. The Board must assure itself that the .
~..nA",...." have been handed over and are acceptable. Where contracts
there must be agreement between
".,,,'nl"llPn
""'~IIJH'iA that the work contracted has been -----'_..._-1
Responsibility
The Project Board is advised by the lVlana",t:I
and any Assurance responsibility.

How I links to other
of the
The SUlJipuc;:r acceutance from the customer that Controls

all the been delivered and the
Check that there has been a sau:mu;mI hand-over of

the finished to those responsible for its use
andf."l1l1lTU"\.n.......
Check that there are no Project Issues \."lli:I.IU!t: Control
Approve the Follow-On Action Recommendations Product
and pass them to the group
Approve the Lessons Learned Report and pass it to Product
the aPl:lrotmate
the End Product
Release the resources allocated to the

Advise management of the
42
Du·ecting a
closure
The Board disbands the
team
In Practice
It is sensible for the to obtain written confirmation
from the users and those who will the final that they
have accented the outcome of the
For Small Pr«"Iiili!J~~
Not all the may be but there should still be a fonnal

Board to close the
43
J.YL"J.A.Q./:,ll..l5 ...,.n,,,,,,TO the PRINCE2 L-Omrolllng: a
Controlling A Stage (CS)
Top-level Diagram
projadend
44
Mall8gmg Projects the PRINCE2 Controlling a
CS2
Happens in the Sub-process?

The
• Allocates work to be done to a team or individual, based on the
needs of the current Stage Plan
• Ensures that any work handed out is acc:oDlparue:d.
measurements such as
and 1"P!nnrtlna
ag:J:eelnellt has been reached on the reasonableness of
aeDJan4JS with the
Why
The must control the sequence of at least the
activities of a stage and when This ensures that the
what those on the are
Plan correctly reflects the work and
progress.
45
for the authorisation ofWork
Work must agree with the
and constraints before the authorisation can be considered
The process 'Managing Product
ofa Team lYHW4l;;wl
comtJleUon of a Work
How Links to other

parts of the
book
Ensure that there is a Product for the work
to be done and that this is ,",Ul.l1I1Jt"'"
-- . '''' skills needed and
olanned dates and Plan
resources. Project
Assurance role
Make up the Work and decide what Work
tolerances should be Product
Discuss the Work with the Team .lVJ.<W4l6"1

team member ifthere is one tea
assess any risks or and the
Work and Risk
Ensure that sufficient resources and time have been

allocated for the work
Record the of the Team in the
Work 1l~r'V~'TO
the Plan with any made as
of the agreement
In Practice
If the Team a different company this sub
process should be with atltltrot)riate
both the Work
46
.... v'u..... vUJLL.ljo; a
In such cases it is sensible to refer to the manner

allocation in the contract
If the Plan were to be a summary of the start and finish

deliverables from a number there would be
r>1L"I.,''''';; for each of these deliverables. There should
be definitions the relevant Product of who will check
the nroduct on behalf of the Project (and/or Project
in the nroduct's development qualitv is to be
M~LnaJ~er must assess what tolerances to

from the amounts available in the Stage
If a Team uses contractors to deliver any of a Work
"''''''"''''6''', it is recommended that this is also handled in the same
way, Le. as a Work between the Team and the
third
For
sUl}-n:rocess can be used if the work is allocated to
than to a team, but it can be done less '~"~-'1
however, consider if a record is needed
of an individual's Where the
IV!i;llliIJgC! is also personally the sub-
not be needed.
CS2 - AS:se!!iS&r.g PII'nnll'A

Information is gatltlen~d Plan to reflect actual
progress, effort "'AL'v,u...""" carried out.
Why
In order to control the and make sensible decisions on what, if
any, need to be it is necessary to
information on what has and be able to compare
this alZainst what was
Responsi bllity
The is but may the actual
collection of data to
47
How Links to other
parts of the
book
Collect I;''''"n"" Product
progress infonnation in
Obtain estimates on time, cost and effort needed to

CmnpJlete work which is in progre:;;s
Check whether sufficient resources are available to
the work as now estimated
...Ullll-/Jll;;.1;;
Check the on quality activities

the Plan with the information
Note any or real,,,,-,ul~;lll~
In Practice
AC'COImIllg to size and environment of the oroiect. the
may be written or verbal.
In contracts the may not be interested in

gathermg of costs or the of team any
"U<lu.t.JI',\'''' to estimated start and completion dates.
For Small Drt'lli.....tCt
The may be verbal.
- Capturing Project ."""",....,.<3

What in the Sulil-DlrOCI9SS
New Issue:;; are logged and ...a.I;;j;\JU"",U.

Why
At any time the a problem
re(jues:ted or the answer to a may are
llll''''''''u., it may mean that the fails to deliver what is reauired.
the may run into some other trouble
have been had the issue been noted at the time it arose.
There must be a process to these so that they can be
presented for the and answer.
48
Managing Projects the PRINCE2 Way Controlling a Stage
~ Responsibility
The Project Manager is responsible. If the project warrants it, help
may be given by Project Support.
""' How Links to other

parts of the
book
The Project Manager ensures that all possible sources
of issues are being monitored
....,..
~. New issues are entered on the Issue Log and given a
unique identifier.
Product
Description
~
A copy is returned to the author to acknowledge Change Control
:, .. . receipt.
In Practice
?:;~ "
A check should be made to ensure that the procedure covers not only
requests to change the specification, but also potential failure to
meet the specification; potential deviations from objectives or plans;
l~~
~I and questions or information about some aspect of the project which
require an answer or may lead to an issue or risk.
For Small Projects

Requests for change or failures on the part of the supplier still need
to be documented as part of the audit trail of the project.
CS4 - Examining Project Issues

~;
• Each new Project Issue is analysed and a course of action
recommended
• Each open Project Issue is reviewed for any change to its
circumstances or impact and action recommended
• All open Project Issues are reviewed for any impact on the project
risks or the Business Case.
49
\L.
1
Managing Projects the PRlNCE2 Way Controlling a Stage
Why
')
Having captured all issues in the sub-process 'Capturing Project
Issues' (CS3), these should be examined for impact and the
appropriate body for any extra information and decision identified.
Responsi bility
The Project Manager together with any staff allocated Project
I. l /
Assurance responsibility.
How Links to other

J
parts of the
book
Assemble all pertinent information about the Project IChange Control
Issue
Carry out impact analysis on the technical effort J
required to resolve the Project Issue
Update the Risk Log if the Project Issue reveals a new
risk or a change to a known risk
Assess whether the Project Issue or its resolution
would impact the Business Case
Prepare a recommended course of action
Update the Issue Log with the impact analysis result
~
In Practice
.-";;',."
The Project Manager may ask a Team Manager or team member to
carry out the analysis, depending on the expertise required. It will be
necessary to analyse the financial impact as well as the technical
impact. This is part of the Project Assurance role of the Executive.
Thought should be given to the time required to do this analysis
o
when designing the project management team, or at least the
Executive's Project Assurance role. When producing Stage or Team
Plans, an allowance should always be made for the time that the
senior specialist people are likely to spend in performing impact
analysis on Project Issues. When planning, thought should be given
to the likely volume of Project Issues.
50
Managing Projects the PRINCE2 Way Controlling a Stage
• ~\o
~.
For Small Projects
The Project Manager may be able to carry out impact analysis as
.~'!\ soon as the Project Issue is presented and get a decision on the
action to take. Thus, in practice, it may be possible to combine the
capture and examination processes with the taking of corrective
action or the escalation of the Project Issue to the Project Board for
decision.
0'"
CS5 - Reviewing Stage Status
}~
-:..:.: What Happens in the Sub-process?
• Provides a regular re-assessment of the status of the stage;
• Triggers new work;
• Triggers corrective action for any problems;
A~. i"
• Provides the information for progress reporting.
Why
It is better to check the status of a stage on a regular basis and take
"".::' action to avoid potential problems than have problems come as a
surprise and then have to react to them.
@. Responsibility
The Project Manager, who may seek guidance from the Project
Board ('Escalating Project Issues' (CS8)) for any problems that
appear to be beyond hislher authority.
How Links to other

parts of the
book
Review progress against the Stage Plan
Review resource and money expenditure
Review the impact of any implemented Project Issues I Change Control
on stage and Project Plans
Check the entries in the Quality Log to ascertain the I Quality
status of the quality checking
Assess if the stage and project will remain within I Tolerances
tolerances
r-\
"
51
Managmg Projects the PRINCE2 Controlling a
edition June 2005)
Check the continuing of the Business Case
Check for chanl!es in the status risks I Risk
Check what work is due to start to ensure that
pn;:pm:atllcms for it are Satllstactolty
Check for any changes external to the which
may it
In PI'~I ....tii""D
The sub-process should be viewed as one that is hat)Oenm:g

throughout a rather than one that is
every two weeks. Each may not need to be done each
but the Manager ensure that there are sufficient
allocated to do
an extra momlOnng
situation were to
remedial work.
A that affects the Business Case or the risk situation may

come at any time. As wen as to such a as it
occurs, it is useful to review the on which the Business
Case and risks are based on a formal. remUar basis.
gwdance on any Project Issue from

do so if there is a threat to the
For
These activities are still Manager should make
a decision about their frequency to the project situation
and environment.
Highlights
What in the Sut)-DrOCess7
• Produces llgnugllt l'i..t:Dons for the BoaJCrl.
52
The Board needs to be kept informed if it
is to exercise proper control over the Rather
DI'()2t'es.S me:erulgs. reports at intervals are
re(:oD1D1lencwd "P1I4tv",.'n assessments at the end of each stae:e. The
Board decides. the frequency of the at
initiation.
Responsibility
The IVlanager is responsible. This covers the
Manager has to back and take stock
How
Collate the information from any Checkpomt RPnnrt!;!

made since the last Report
lOennlty any Plan revisions made

since the last
lUt:U\,UY current or p01ten1tial
Assess the Issue for any potential
Board attention
A ....".uLU} any to other risks
a summary of this information to the
Board
In Practice
should come from sub-process CS5 Status' .
.U5J..lllj;;llL a progress update

It can be used to
to in resources not WIder
the direct control of the Project and to warning
of any nroblems that with Proiect attention can be
avoided.
53
'-'~'J."'Vj.JJ.L'l'. a
i (revised edition June
The should be briefin order to hold the attention of busy
senior ma:nag;ement.
It does not informal contact between Project <UOUJ."',~"L

Board if there is an need for infonnation to be
For Small g ..... ia..... CIt
The nlgIlllgru need not be in ifthe Board
What HaDDens in the Sub-process?

• Within the limits of the tolerance margirus established the
the takes action to any
prCIOle:ms that arise.
Why
to take action when the project is away from the
Plan invites loss of control.
The IVlanager assisted by any ~Hn·nf'lrt and
How Links to other

_ ofthe
book
Create new Work or existing ones to
reflect the rewwre:d
The Board for
Ut:CIUlllg on corrective action
The situation to the need to take corrective action should be

.~ . .~. 1 recorded as part of the project audit and the Issue
is the easiest and most available means of doing this. of the
reasons for corrective action will be Issues raised other
54
Managmg the PRINCE2 Way Controlling a
It is still to log were ~=geu.
CS8 - Project
What in the Sub-process?
Where an issue threatens to go beyond tolerances and the Project
""-......15,". feels that helshe cannot take corrective action within the
authOl:1ty limits the the situation must be
I:>ro,Ug:Jtlt to the attention of the Proiect Board for advice.
Why
Part of the concept is that the Project
<A5,"" will
H ...... to the immediate attention of the Board
anything that can be forecast to drive the beyond the tolerance
limits with the Project Board. This of the
Board in overall control.
Responsibility
..."u....._."" is responsible, assisted by any ilIJIJVill.I.CU
Assurance staff.
How ILinks to other
parts of the
book
Carry out an of the deviation.
and evaluate for recovery.
Select a recommendation.
to the
In Practice
There are
come under
resources may not be at I;;XI}I;;"~Ii:lU
activities or events such as illness may have arisen. The onnn"it..
may also be true, that the work will fmish earlier than the
time tolerance or cost less than the budget tolerance.
55
Managing Proiects the PRlNCE2 \..,UllITUllllll!. a
(revised edition Jllile
The most cause of a deviation tolerance is the
one or more Project Issues. Let's be
IV1~LIlgl~r stands here. Tolerances are not
(or Team Manager) to "fit in"
change are there because planning is not an exact
science. If the customer wants to add new facilities or change those
that were this should lead to the pr.ovision of more cash
and time from the Board S.o the Exception Report w.ould
say, y.ourmind. These are the This is
what it will cost you. D.o y.ou want t.o or.ovide the extra cash and
time?"
An.other reason for a forecast deviati.on may be an UI:Hj'peC:lm;anon,

of the current soluti.on t.o meet part of the ~r'~~'~U.UV".
is on the find a within the
current tolerances. if this cann.ot be done sh.ould the
For Small
will relate t.o the
1"1.1'\,1"(\,.:1',,,, of sub·
process Highlights'. Both will often be informal
and brief.
CS9 ~ Completed Work Package

What HaDDens in the
Where work has been rec.orded as approved to a team or

there should be a sub-process to record the return of the
pr()Ciuct(:s) and its/their acceptance
Responsibility
lUa.U<1J<;"l is responsible, assisted by anYaUIJ'U111.U;;U
".-,-~ ... staff.
56
How
Check the the of the

Work
Obtain quality confirmation
Check that the have accepted the products
Ensure that the delivered products have been
baselined
Document any relevant team member "....,..."'"'''''' 1
infonnation
Pass infonnation about to the
Plan
In "'I'~~"''''I'''A
This process is on-going throughout the
lUHl.Il:IJ.lLy ofthis sub-process will relate to the of sub

lthoM",;na Work Packae:e'. Both will often be
In Practica
Board should be
For Projects
The may be small enough that the Project Plan contains

sufficient detail to manage each thus Stage Plans are
not needed
57
U'""""'''ErU'"5 P1'"i",~t" the PRINCE2 MlUlllging Product n"liv"I"V
Managing Product Delivery (MP)
Top-Level Diagram
Work closure
What Happens in the

.. work with the
.. Does the work
. the !YJ.i:WJ1ji;Cl infonned on progress, and any
.. Gets approval for the finished work

.. Notifies the Proiect Manru:!er that the work is finished.
Where the work, there must be aDl)roll)ri2lte

the team or person to whom the work is to ll1Ulll.i"L..
unlieIl~tarldi!lg and of the work. While the work is
there may be a need to progress and confirm
When the work is there should be an
the satisfactor
58
l".I4l~lU.!; Proiects the PRINCE2 MlIDII.giIllg Product Deliverv
How
CS2
Assessing
Progl1lSS tlmesheets
MP1 - a Work Package

in the Sut,-process?
• the details ofa Work with the
• Plans the work necessary to the Work P"...h"""
59
respOIlSlOlIUY will lie with a Team to agree a
If the person who win do the
lYJ..<lLli<l.,,,-"l. then this person would be
How links to
other parts
of the book
with the IVlanager on what is to be Work Package
delivered Product
Description
Ensure that the are clear Product
Description
PD
who must be involved Project
Assurance
~-'~~'.l any dates and/or constraints for the work
~~~'~"'J any requirements Checkpoint
Report
Understand how the Configuration
to be handed over Management
Make a to do the work PBP tPl"hni,,"
Check the DIan al!ainst the Work
Performs the of risk the Work
suitable tolerance for the Work t'l'I~IC:Hrp. Controls

In 1I:I.... rtl.......
Where the Team works for an external contractor, care should
be taken to ensure that all the work requirements, as defined are
understood. A Team Plan for the work will have to be created before the
Team can confirm the to meet target dates. A Team
lVUWi1,~"l should avoid pressure from the
hislher own company to agree to a commitment
that the can be achieved. This may include contmnation with the
Senior SUDDlier that the necessary resources will be made available.
60
rM;;;;;;;;;-;:;~p;;:~t;rl;the PRINCE2 Way Product Delivery j
If it is a team directly under the then

the CSI-MPI processes about work that
have done will be an between the
the individual team member. This can either be done rorm.al1y or
informally. The same need to be but common sense will
indicate how much should be documented. The should
consider whether a record of the work needs to be for any future
""'T7.....,.,.""·",,.. apl)raJlsal of the individual.
MP2 a Work Package

What HaDDens In the Sub-process?
• of the products/services defined
in
Why
and committed to work in sub-process covers
the of that work until its
Responsibility
The is the responsibility of the Team ~".L
.L.......
How I Links to
other parts
of the book
Allocate work to team members
and record the effort C.II.PCllUCU
Monitor progress the tolerances for the
work
Monitor and control the risks Risk
Evaluate progress and the amount of effort still
to the product(s) of the Work
Ma:aag1er at the Checkpoint
Reports
Ensure that the reqiUm~d checks are carried out
Ensure that any personne
Package are involved in the
Raise Issues to advise the !V1iUli:1.~CI of
61
~
Managing Projects the PRINCE2 Way Managing Product Delivery
any problems I Control
In Practice
Depending on the size of the Work Package, this is a continuous, cyclic
process. The emphasis is on being aware of the status of team members'
work and keeping the Project Manager up-to-date on that status.
For Small Projects \
Where the project is too small to have Team Managers, the Project
Manager will carry out this sub-process.
MP3 - Delivering a Work Package
• Obtain approval of the products developed/supplied
• Hand over the products to whover is responsible for configuration
management
• Advise the Project Manager of the completion of the work
Why
There has to be a process to deliver the requested product(s) and
document the agreement that the work has been done satisfactorily.
~
Responsibility
Team Manager
How Links to "
"
other parts
of the book
~
Confirm that the Quality Log has been updated with Quality Log
details of a successful check on the quality of the
product(s)
Obtain approval from whoever is defined in the Work tJ~, '·'
Package as the end user of the product(s) ~
Transfer the products and control their release to the Configuration
project's Configuration Librarian Management
Advise the Project Manager that the Work Package is
complete
'.,;
Where necessary, obtain a documented appraisal from
the Project Manager of the performance in completing
the Work Package ,
62 l;~
;' '."
. '~~
Managing Projects the PRINCE2 Way Managing Product Delivery
In Practice
This can be done formally or infonnally. The original Work Package
should say how it is to be done. The formality usually depends on the
criticality of the product and the state of the relationships between the
customer and the supplier.
For Small Projects
" '
This is usually a very simple, informal process of passing the work back
to the correct recipient and telling the Project Manager that the work is
done. If the team member expects the work to form part of a later
appraisal of work, the team member should ensure that the Project
Manager documents how well the work was done. The team member
should be shown or given a copy of the appraisal.
1)-:':"
'I~
·~,~"6 ,I
w.:~
(r
~
. .~
c 63
)
Managing Projects the PRINCE2 Way Managing Stage Boundaries
~
Managing Stage Boundaries (58) .../
Top-Level Diagram
J,)
CS5 DP3
Reviewing thorlslng a Stage
Stage Status
Stage end
or Exception Plan
:J
trigger Stage or
ceptlon Plan
5B
Managing
Stage Boundartes Lessons Learned Log
request for
exception Plan
CS8 CP3
Project
J
Escalating
Project Issues Evaluation
Review
FigureSBl
What Happens in the Process?

• Confirms to the Project Board which products planned to be
produced in the current Stage Plan have been delivered;
• Gives reasons for the non-delivery of any products which were
planned (in the case of deviation forecasts); ('I_.J
• Verifies that any useful lessons learned during the current stage
have been recorded in the Lessons Learned Log; ,.--;.
• Provides information to the Project Board to allow it to assess the \i...v
continued viability of the project;
• Obtains approval for the next Stage Plan or the Exception Plan;
• Ascertains the tolerance margins to be applied to the new plan
Why ' ' .~ , ;
The ability to authorise a project to move forward a stage at a time is

a major control for the Project Board. There is also a need for a
process to create a plan to react to a forecast deviation beyond
64
., ./
n ............E''-'-'5 Pm""",t" the PRINCE2 Manall:mg Stage Boudarles
tolerances. This process aims to the information needed by

the Board about the current status of the
Business Case and risks to enable them the "'U""WII..L!.LL~
worth of the oroiect and commitment to a new
How
L . .' ' ' " , , , Il•• Learned Log
Project"- - - - ,
Plan SB5 DP3
SB1 Plans
Authorising a
Planning Stage or
a Stage Plan
Plans
uslness
Case
SB2
SB1 • Planning a ~T~lnA

What HaDDenS in the Sub-process?
• a plan for the next
aoequauay control a the Project needs a

activities go down to the of a
l\llanager is but may help from

Assurance functions should review the plan to
65
~
ensure products have suitable and timely quality checks with ~
appropriate resources assigned.
How Links to other
parts of the
book
Check the Project Approach for any guidance on how
the products of the next stage are to be produced
Check the Issue Log for any issues which will affect Change Control
the next Stage Plan ,-)
Use the common Planning (PL) process to create the Planning (PL)
draft plan -)
Document any changes to the personnel of the project Organisation
management team
Discuss the draft plan with those who have Project
Assurance responsibility in order to include Stage
Quality 1)
Quality Plan requirements
,~
Add any formal Quality Reviews and any other
quality checks required for Project Assurance
Quality Review
...
~\ .~
purposes
m
,'. .'>,li"I;
Identify (as a minimurri) the Chairman of each formal

Quality Review
Identify with those with Project Assurance Stage Quality .'.
responsibility the required Reviewer skills and Plan
authorities required for each formal quality check
I
Ensure that the plan includes all required management Product-based
-.
products Planning
Check the plan for any new or changed risks and Risk
update the Risk Log
Modify the plan, ifnecessary, in the light of the risk
()
analysis
SB2 - Updating a Project Plan
~
• The Project Plan is updated with the actual costs and schedule
from the stage that has just finished, plus the estimated cost and
schedule of the next Stage Plan.
66
Cz, Managing Stage Boundaries
Managing Projects the PRINCE2 Way
Why
As one stage is completed and the next one planned, the Project Plan
must be updated so that the Project Board has the most up-to-date
information on likely project costs and a schedule on which to
partially base its decision on whether the project is still a viable
business propositioR
Responsibility
c How
The Project Manager is responsible, but may have help from project
support
Links to other
parts of the
book
Ensure that the current Stage Plan has been updated CS2
with final costs and dates
Create a new version of the Project Plan ready to be Configuration
updated management
Update the Project Plan with the actual costs and dates
of the current Stage
~ ...•;~ ..."
Update the Project Plan with the estimated costs,
resource requirements and dates of the next stage
Update any later stages of the Project Plan on the
basis of any relevant information made available since
the last update
Check to see if events mean that the Project Approach I SU5
has to be modified
In Practice
Text should be added to the new version, explaining why any
changes have occurred. This is an important part of the Project
Manager's audit trail of documents covering the management of the
project.
For Small Projects
All the activity detail may be in the Project Plan with no separate
Stage Plans. The Project Plan should be updated with the
information described above.
( 67
SB3 - Updating a Project Business Case
Modifies the Business Case, where appropriate, on the basis of
information from the current stage and the plan for the next stage.
.J
Why
)~
,~)
The whole project should be business-driven, so the Project Board
should review a revised Business Case as a maj or part of the check
on the continued viability of the project.
Responsibility
3
The Project Manager and whoever has responsibility for the ~
LJ
business assurance for the project.
How I Links to other lD

-.
parts of the t'i
book .c ;
Create a new version of the Business Case ready to be Configuration .~

updated management J
Review the expected costs in the investment appraisal }
against the new forecast in the updated Project Plan } r:: ~,
Review the financial benefits in the investment }

appraisal against any new forecasts }
Review the reasons in the Business Case and check } Business Case
that there has been no change or that no new reasons
have come to light
... ') .
Modify the new version of the Business Case in the }
light of any changes to forecast
In Practice I. ~·
\~:" t)"...
The Business Case should be reviewed minimaUy at each stage end,
but more frequently if the stages are long or the Business Case is at
all at risk.
For Small Projects
:J:
It should not be assumed that the Business Case is unimportant for a
small project.
68 .';
lVlanagmg the PRlNCE2 Way Managmg Boundaries
edition June
l"W'f~tin" the Risk
It Checks the known risks to project success for any to their
circumstances and looks for any new risks.
Why
Part of the assessment of the is an examination of
the likelihood and
collates the information on

,,,..<w.,,,I';"" but each
been allocated to an 'owner', the person
to monitor that risk.
How , Links to other
oftha
Ensure that the Risk is un-to-date with the latest I Risk

information on the identified risks
Ensure that any new risks identified in creating the
next Plan have been entered on the Risk
Assess all open risks to the as defined in the
Risk
Decide if the next Stage Plan needs to be modified to
avoid, reduce or monitor risks
Create for any serious risks which
cannot be avoided or reduced to !:;'"'u,,,'"
J..I.A<&.......
In Practice
An assessment of the risks should be Report.
In the Manager should discuss any
Board so that the risk situation and any
extra costs incurred in rea!cti.IJlll; to those risks do not come as a
n.. --:n~ at the end stage assessment.
For Small Pr(~ialet!C;o
Continuous risk assessment and are to all

levels
69
)
']
.....
SB5 - Reporting Stage End
• Reports on the results of the current stage;
• Forecasts the time and resource requirements of the next stage, if
applicable;
• Looks for a Project Board decision on the future of the project. o
Why
Normally the Project Board manages by exception and therefore
")
only needs to meet if things are forecast to deviate beyond tolerance
levels. But as part of its control the Project Board only gives
approval to the Project Manager to undertake one stage at a time, at
the end of which it reviews the anticipated benefits, costs, timescale
and risks and makes a decision whether to continue with the project
or not.
Responsibility
The Project Manager is responsible.
How Links to other
parts of the
book
Report on the actual costs and time of the current End Stage
stage and measure these against the plan which was Report Product I ·~\
approved by the Project Board Description

Report on the impact of the current stage's costs and
time taken on the Project Plan
Report on any impact from the current stage's results
on the Business Case
t,
Report on the status of the Issue Log Change Control
Report on the extent and results of the quality work Quality Log
done in the current stage
Provide details of the next Stage Plan (if applicable)
Identify any necessary revisions to the Project Plan
caused by the next Stage Plan
Identify any changes to the Business Case caused by
the next Stage Plan
70
edition June
Report on the risk situation
Recommend the next action annroval of the next
In Practice
Board should be aware of what will be in the End
'VUUW..LY receives it.
For Small PI".~IAI~JI.
The may be if this has the of the

Board.
In Practice
Board should be
Droblems discussed and advice
Ad Hoc Direction' before oresentatlon
For Small pn~ID~'!!I;
The may be small that the Project Plan contains

sufficient detail to manage each thus separate Plans are
not needed
• Producing an Exception Plan

What Happens in the Sllh_ru'n!I'!A~Ul
l¥lanager prepares a
The Project Board approves a Plan on the that it

within its defined tolerance margULS.
indicates that the current tolerances are to be exc:eecled,
Project Board may ask for a new to reflect the "'''<lCU",''''
situation and which can be within newly soc:cified
tolerance ......"....,,'nO
Responsibility
The Project is in consultation with the
Assurance function.
71
......

How Links to other l~)
parts of the
book
A Exception Plan has exactly the same format as a IPlans
Stage Plan SB 1
\
A Exception Plan covers the time from the present .~
moment to the end of the current stage

In Practice
1)
Reasons for the deviation forecast can be many, such as:
• work on approved requests for change cannot be done within
current tolerances; . '.~
• the supplier has discovered that it cannot supply part of the

solution;
• the stage cannot deliver all its products within the current
tolerances.
~.
For Small Projects :Y
There is the temptation not to re-plan, but only to 'remember' that .'1
changes have occurred. It is, however, important to advise the
Project Board of any potential deviation beyond tolerances, to have
a record that the Stage Plan was changed to accommodate the
change and that the Project Board approved the new targets.
The same concept can be applied to Team Plans if they are forecast
to deviate beyond tolerances. ~
ttt -", J
;.../
.
l~.·
~
,); -;
I,:y;
.-~,
Prr.ip.M" the PRINCE2
Closing A Project (CP)
Top-Level Diagram
project flies
1 pmmi!ll:Unl.
DP5
Confirming
Stage Closure
Product acceptance
Follow-On Action
Recommendations
lessons learned Report
End Project Report
What Happens In the Process?

• Checks that all products have been delivered and al..'''''''lJu;u
• Checks that all Issues have been dealt with
• Records any for subsequent work on the 1-'".1'\'''''''''
• Passes on any useful lessons learned the
• Recommends closure of the proiect to the Proiect Board
• Plans to measure the achievement of the Business Case
should come to a controlled COlDplletioon.
In order to have its success measured, a must be to a

close when the Manager believes it has met the
obiective...; set out in the Project Initiation Document.
73
thePRINCE2 a
How
CP1 • Decommissioning a Project

Happens in the ;::iUD-c;roc::es,s
• Gets from the customer that the ",..,..p,.,t"n criteria have
been met
from the customer
its ooerationallife
• Checks that all Issues are closed
• archiving for the oroiect files.
Why
The customer and must agree that a has met its
before it can close.
There must be a that there are no outstandmg or
OOICUInellta:nolll, oartJ,cullarJy a:greell'lents and "nnrn""l
74
Managing Projects the PRINCE2 Way Closing a Project
Responsibility
The Project Manager and any Project Support staff assigned to the
project.
parts of the
book
Check that all Project Issues have been closed Change Control
Get the customer's agreement that the acceptance SU
criteria have been met
Ensure that all products have been completed and
accepted by the customer
Ensure that, where applicable, those who will be Configuration
responsible for maintenance and support of the management
products are ready to accept the product
Complete and archive the project files
In Practice
This sub-process may be abridged if the Project Board brings the
project to a premature close. There will need to be a carefully
managed hand-over of the products between the project and
operational and/or support staff unless one central group handles
configuration management methods for both parts of the product's
lifespan - development and use.
If any acceptance criteria have not been fully met, the customer and
supplier may agree to record this as a Project Issue (Off
Specification) to be dealt with in a later project.
The final product may be handed over to a new third party to operate
and maintain, and there may be contractual arrangements involved
in the acceptance of the product.
For Small Projects
Notification of the release of resources may be very informal, if
required at all.
75
"""""",,;L.U.5 Prrl,1I"("t<t the PRINCE2
edition June
What in the Suh-rlfOle95ts
• Identifies any work which should be done the

• a for when the realisation ofthe nmip('t'~ pvnpf'tprl
benefits should be checked

Why
of unfinished business at the end ofa
doc:un:len1ted, checked with the Board and
for action.
The N1<ma2~isresprn~1I)le. should be sought from

any Assurance roles used.
How Links to other
of the
book
Check for any omissions in the .....".,-In.,.... the
Definition in the PID or .,U~~I;;"U'Jlll)
,,,,,.,rr,,'" the pr(lldul~t
Ensure that any omissions and are ".A.1l:W.'~1;; Control
recorded as Issues
Check the Issue for any Project Issues that were
not '"'UJ.1.lJ.'J........y.
Check the Risk for any risks that may affect the IRisk
in its onerationallife
nrntlllN
Draw up Follow-On Action IFollow-on Action

Recommendations
Product
when measurement can be made of whether

has delivered its and prepare a IReview
to carry Qut that measurement
76
!Uall"'l!l"",,Eb "","""""t" the PRINCE2 Way II
The Review should be
external ~111"1'" Ii,.,.
Where the is of a programme, any recommendations for

follow-on actions should be nassed via the Proiect Board to the
programme management.
Where the of a progranune, the project's work may

have been ofthe Business so
there may requIDem.ent for a Post-Prolect Review.
There may be no IeClIWIem.ent the Senior User for a Post-Project

Review.
CP3
What in the Sub-process?
• Assesses the results its
• Provides statistics on the of the
• Records useful lessons that were learned.
Why
One way in which to management is
to learn from the lessons
As Board needs to assess the

ManaQer. This may also
form of the customer's to see if the
contract has been Cotnpl.eteO, summer should be used
The and any Assurance

roles used.
parts of the
book
Write the End Proiect Renort. the lEnd
77
1
I
Managing Projects the PRINCE2 Way Closing a Project

~i
management, quality and technical methods, tools and I Report
processes used
Examine the Risk Log and actions taken and record I Risk
any useful comments
Examine the Issue Log and actions taken and record IChange Control
any useful comments
Examine the Quality Log and record any useful I Quality
comments
I
Turn the Lessons Learned Log into a Lessons Learned Lessons Learned
Report Report PD
In Practice
The Lessons Learned Log should have been updated throughout the
project.
If there are suggestions that the quality management system used by

the project needs modification. it should be made clear that such
comments are directed to the appropriate quality assurance function.
For Small Projects
The Project Board may not require an extensive End Project Report.
'}
78
Managing Projects the PRlNCE2
Planning (PL)
Top~Level
SUS IP1
Defining Planning
sue Project
Planning an
Initiation MP1
Acc::epltlng a
1P2 Work Pac:kacle
Planning 1_,- - - +
a
SB6
Prc:~duclnl!:l an
• Defines the levels needed for the n1n',,('t·

• Decides what pli1Illllllt; esumaung methods will be
• Identifies the oro ducts whose has to be ptannea;
• Identifies the activities needed to deliver those and the
"""j''''.1.1'''''''''''''I''''' between
• Estimates the effort needed for each activity;
• Allocates the activities to resources and schedules the activities
a timeframe;
• the risks inherent in the plan;
• Adds exolanatorv text to the final
79
)
Managing Projects the PRINCE2 Way Planning
Why ,_.J
PRINCE2 offers a standard way in which to produce any level of plan.
This means that all plans will have the same format and method of
development. The process is based around the PRINCE2 technique of
-J
Product-based Planning.
How ,)
~
PL2
Defining and
analysing products ""';;
PL7 PL6
Completing
a plan
Analysing
risks
4)
Product completed
Checklist plan
SU6 Planning an initiation smge
IP2 Planning a project
SB I Planning a stage ~
SB6 Producing an Exception Plan

MPI Accepting a Work Package
"~""'~" "
FigurePL2
PL 1 - Designing a Plan
• Decides on how many levels ofplan are needed by the project;
• Identifies any planning tools to be used; r ',~.
V
• Identifies the methodes) of estimating to be used.
Why
This sub-process is carried out only once per project, the first time that
the Planning process is used. It defines the standards to be used in all
future plans. The result should be a consistent set ofplans.
Responsibility
The Project Manager.
I)
80 J"')
<nau"!!:,.lll5 ......,.,'.. "T" the PRINCE2
How Links to
other
oftha book
Decide on what levels are needed for the I Plans
i.e. Proiect Plan. Stage Plans. Team Plans
pf()gr:amme uses a
nllIUcwar P"'CUU1Ul5
1.1",.LlUlllj:,tool to be used in the

Initiation Document Initiation
Document
lae:nn:rv what mewoo\ are available and
suitable for the
Ensure that the esti:rru:ltirlg 1l.........V'""\ <I J
allowances for ad
hoc meemlgs, !eaJlTIl!Ilg
Discuss with the Board whether there should be
a set aside Controls
Discuss with the Project Board whether there should be Risk
a separate allowance for any 4.ULl"'!~Il1''';U \..-·VU •.w.j:5,<;;lll,y
Plans
In Practice
Where the project is of a progr:amme, the progr:amme will have made
most of these and it is just a out what the
standards are. Beware of any resource, unn.. ~ ..l
lOO% of its time to an No one is 100% <;;~L'''l<'Ul.

be such as telephone ad hoc and
"f'I_.n..,~""... work demand your time. These should be allowed for
in your estimate of how much time can commit to the work in
your Even the most efficient workers is to
devote more than 70% of their time to work. At least 50% of a
time should be The
M~ma:ger of a project should not any of the
;)IJ";""'H;)' work at all.
For
may not need a tool, but a little thought
should be to the other before in and you can
hold it all in your head. The comments about how efficient are still
holds true for the smallest
81

PL2 - Defining and Analysing Products
• Identifies the products whose delivery has to be planned; -l
• Describes each of the products in terms of purpose, composition
and quality criteria and ensures that these descriptions are agreed
by all concerned;
l.ii 'j
• Identifies the sequence of delivering the products and the
dependencies between them.
Why
By defining the products and their quality requirements everyone can see
and understand the required plan result. It means that whoever has to
deliver a product knows in advance what its purpose is, to what quality it
has to be built and what interfaces there are with other products.
Responsibility
The planner is responsible. This will be either the Project Manager or a
Team Manager, depending on the type of plan being produced. The users ·!W
of any of the products to be delivered within the plan should be involved .,'.'
in writing the Product Descriptions, particularly in defining the quality
criteria.
How Links to
other parts
of the book
Identify the products required Product-based
Planning
·~
.'C';. '.
Write Product Descriptions for them . :.....;.
>.
Draw a diagram showing the sequence of delivery and

dependencies between the products
Optionally produce a Product Checklist Product
Checklist
In Practice
This is a key point in PRINCE2. If you are not doing this step, then you
are not really using PRINCE2. It is an ideal method of involving users,
specialists and Project Assurance roles in the creation of a plan, without
the normal problems of 'design by committee'.
( "':
82
Managing Projects the PRlNCE2 Way
edition June 2005)
For Small Projects
It is very tempting in small projects to assume that use of Product-based
'~~'5 is not needed Experience has sho'Wll me that it is very easy to
do in the wrong order or fail to consider a
when you dive in and do it.' It doesn't take much time
and it win alwavs pay dividends.
• Identifies all activities necessary to deliver the

• Defines the deoendencies between the activities.
and Team Plans the Product Flow in sub

process a level for the pmposes of
estimation and control. This sub-process allows a further
<OaA.UU"'.H based on the PFD until each activity will last only a handful
respOllSit)le. This will be either the Project or a

'W."l,;''', "'''lJo;;U_Ull'!5 on the
! .... of plan being produced.
How Links to
other
oftha book
Consider if a in the PFD is too to estimate or
would need such a effort that it would be difficult
to control against that estimate.
break it do'Wll into the
it. This shoul.d continue
.,,..,.;,,;..,, is less than ten
nrnrl'lct has been broken do'Wll into several

the activities into their correct sequence.
dep1en(len(;leS between and refine
deJ)enderlci~lsbetween the new activities.
For went from the
end of one to the start of the next is there now an
83
-~

opportunity to overlap, or start some activities on a
(0 _)
product before all the activities on its preceding product
have been done.
In Practice
You may decide not to do this step, but simply extend the previous step,
i.e. continue thinking about products, rather than activities, down to the ,)
level where you have all the detail you need for your plan. This step was
originally included because all planning tools used Work Breakdown
Structures and assumed you would be working with activities and tasks.
This sub-process was inserted as a bridge from PRINCE2's product
approach. Other people found it convenient to use this sub-process to
J
draw a line below which Product Descriptions were not needed. -)
For Small Projects
Following the above comments this sub-process may not be needed for a
small plan. The previous step may give enough detail for estimation and 1
control.
PL4 - Estimating
oJ
l'";:\
• IdentifY the types of resource needed for the plan;

• Estimates the effort for each activity/product
Why
i0f:'"/
The objective is to identifY the resources and effort required to complete , '\}
each activity or product.
Responsibility
The Project Manager. Possibly there will be expert help available from
()
Project Support.
How I Links to
other parts
of the book
to
Examine each activity/product and identifY what
resource types it requires. Apart from human resources
there may be other resources needed, such as equipment.
o
With human resources, consider and document what
level of skill you are basing the estimate on.
Judge what level of efficiency you will base your
estimates on, what allowance for non-project time you
84 ~)
Estimate the effort needed for each actlV11ty!lJrodU(;t.
Understand whether that is an estimate ofunintem
. to which the allowances must be or
whether the estimate includes allowances.
Document any you have e.g. the use
of nanled resources, levels of skill and
eXJlerienc:e, the of user resources when you
need them. Check the with those who have
such such as the Senior Supplier and Senior
User.
In Practice
The for standard
true for standard PRINCE2
OrcdUicts. For example, the amount of time to
~~t,.~O"". Report, and to prepare and hold a
Beware an estimate for the before you have gone

this
th"''',.e.h It seems easy to give a offthe top
head for a small But once the Board will hold you
to this. It is how many unchecked
assumptions and 100% effective lie waiting: to
be discovered by this in the smallest
Pl5 - Scheduling
What HaDDenS in the Sub-[lrolce!~s1
• ~tchesresourcesto
• Schedules work to sequence and de]perldenciles;

• AI'1m"U: the schedule to avoid over- or unlt1er-us,ed.:
• Nl'"l1ntHltes a solution with the such as
resources, too many resources or to meet fixed
• Calculates the cost of the resources used in the plan.
85

Why )
A plan can only show whether it can meet its targets when the activities
are put together in a schedule against a timeframe, showing when
activities will be done and by what resources.
Responsibility
~"
The Project Manager. V: )
How links to
other parts
of the book
'}
Draw a planning network
Assess resource availability. This should include dates of
availability as well as what the scale of that availability
C)
is. Any known information on holidays and training
courses should be gathered.
Allocate activities to resources and produce a draft
schedule. --;"
Revise the draft to remove as many peaks and troughs in

resource usage as possible
Add in management activities or products (Stage and
Team Plans only)
Calculate resource utilisation and costs
In Practice
This may be the point when you transfer the plan to your planning tool.
For Small Projects
You may not need a planning tool. You should remember to add time and
effort for any management products. ~
PL6 - Analysing Risks

I, .
• Checks the draft plan for any risks in it.
Why
You should not commit to a plan without considering what risks are
involved in it and what impact the plan might have on risks already
known.
86
The is responsible. This will be either the ~ma;gerora
IV1~Illl1:gt;;;r. detlendmlll on the being uroduced.
How Links to
other
of the book
Look for any external These always
reuresent one or more risks. Products from other
_ not arrive on time. be
or be wrong in some other way
Look for any you have made in the
e.g. the resources available to you. Each assumution is a
risk.
Look at each resource in the Is there a risk
involved? For example, that a new resource doesn't
"~rform at the or that a resource's
_AO~U~.'UJ is not achieved.:
Are the tools or ..--... -~,-
Take the risk actions. Where ap]:)rolrJriElte, Risk
revise the plan. Make sure that any new or ...,'U................
risks are shown in the Risk
In Practice
Depending on the size of the Work Package, this is a cyclic
process. The aware of the status oftearn members'
work and Manager on that status.
For Small D ......I..........
Where the is too small to have Team the
IV.l~Ula:gt:r will carry out this sub-process.
a Plan
• Add text to the plan
Why
A plan in form is not It needs text.
87
~
I
Responsibility
)
The planner is responsible. This will be either the Project Manager or a
Team Manager, depending on the type of plan being produced.
How Links to
other parts ,~
of the book
Agree tolerance levels for the plan Project
Controls )
Document the expected working environment, what
work the plan covers, the approach to the work and how
the quality of its products will be checked
)
Document any assumptions you have made
Add the planning dates to the Product Checklist (if used) I PL2
-,
Publish the plan
In Practice ~
The majority of the material for the text will evolve from the previous
..J
planning steps. Some of it will already be known because of local
standards.
For Small Projects
Even if you don't have to publish a plan, you should still document the
assumptions.
'"1
'~
88 '..J::".'"
thePRINCE2
I"£l.e:!'e:!' Case
a business need. Ifit has no

busmess, it should not be undertaken.
The Business Case is a vital tool. It should be
considered before any ideally at a level
such as the strategy group, and as part of any '_'~'V'LH'J'
• A high-level Business Case should be included in the

Mandate. Ifit is then one should be added as of
Brief.
• The contents of a Business Case should include the reasons for the
the the selected and reasons for
business benefits and costs of
nIClnOlsed solution and risks.
• Well-constructed Business Cases will have assessed the of
doing and will the differences to be achieved
implementing the "'.....,,",,'.1"1'1
The Business Case should be formally reviewed at the start of a
and again at boundaries and at project closure. It also be
reviewed when maior change are made. It should be monitored
If a project is of a programme, at the

Business Case of the nrogramme. In such a case, the may have no
but contribute to achievement of the
programme Business Case. In this case, the reviews mentioned above
will refer back to the need for the nroiect within the nerceived
needs for the plX)gnurume.
Overview
will describe the content of the Business Case and establish
the to review the Business Case as a exercise at the start of the
and on an omwinl!: basis throughout
Detail
The Business Case contains the fonowin!! comnonents.
89
Managing Projects the PRlNCE2 Way Businl!$S Case
Reasons )
This is a narrative description of the justification for undertaking the
project. This may have been initially defined in a feasibility study (where
one has been done) and/or the Project Mandate, and should ideally
describe the reasons why the system is needed. This may be the only
i
information available until the Business Case is revised as part of project
initiation. I. 1
Options
The 'do nothing' option ""
In every Business Case the 'do nothing' option should be
considered. Indeed in a lot of cases it is the ' do nothing' option that
justifies the need for change and hence the project.

Examples of this are where the 'do nothing' options results in:
• the loss of market share; )
• large maintenance costs;
• heavy legal penalties for non-conformance to law.
.~
. ." .,~
It is important to remember that the ' do nothing' option should be ' "' ,
calculated by assessing the implications of staying with the current

mode of operation for the anticipated life of the new .~",~~
product/service/system. It should be calculated from the planned
date of the start of the proposed project for the expected life of the
new/replacement product, with estimates for inflation and cost
increase included. { ...
The 'do something' Option
Estimates of the implications of implementing the project's solution
need to be made in a similar way and over a similar time period to
the 'do nothing' option above. The effects on running costs and
benefits need to be assessed. It is not relevant here to go into ~
i.,-~j;
lengthy discussion on benefit quantification. Suffice to say that an
effective Business Case is one that gives the most accurate estimate
of direct benefit resulting from implementation.
Benefits and Savings
A narrative description of what the expected benefits and savings are, ,.
plus estimated figures over the life of the product. It is important to look 'I(~:'~:
ahead to the judgement of whether benefits and savings have been
achieved after the end of the project. Benefits and savings should be
defined in terms that are
~
90 fO
Managing Projects the PRINCE2 Way
• measurable at the start of the
• measurable when the final is in use
This information comes from the Plan. It the estimated

development and costs for the prolect and the exoected ,-l",HvP1"'U'
date.
Risks
The risks facing the should be summarised from the Risk
Log.
Investment AIlPraisal
This illustrates the balance between the de,rel()pIJlleItt,
"'""""rt costs the financial value of the """.Lv""", ,,,,,,,nne,,, over a
of time. This may be a fixed number or the useful
life of the nroduct.
The baseline for investment Le. what
would the picture of costs
undertaken? This is compared
the
Wherever possible, benefits should be in ways. To
start with. the customer, user or Executive may define many benefits as
e.g. staff. It is worth the effort to think
about intangible benefits to see can be in more
umglOle ways. For example, staff may translate into less staff
turnover andlor less time oiffor stress-related problems. Both of these
can be converted into a
often make the mistake, when "'"""",,l'IJI-1J.ll1';
the Business of quantifying benefit and cost irnlPli(:ations
themselves. This is not usually wise. Costs and are
estimates and it is important to get the customer to provide these
estimates. It is the role of the Project Manager to seek out the
and ensure their involvement. They may need a little from you, but
the should be recognized as theirs. When the product's real
benefits are finally measured, you don't want the users or the Executive
accusing you of overestimating its value.
The assessment of benefits (and reduced costs) should follow a natural
I-'rn,l/'~t<:: have objectives which, when achieved, realize benefits. In
to meet objectives, detailed requirements have to be identified and
met. Solutions are built to meet these requirements that will. in
91
')
Managing Projects the PRINCE2 Way Business Case
")
achieve the objectives and hence realize the benefits. The I ..........
implementation and operation of the solution start to deliver the benefits.

Maintaining this link, throughout the project, is a vital task in refining the
Business Case.
There are many ways to evaluate the claimed benefits and investment
appraisal. Two worth mentioning are sensitivity analysis and GAP
analysis.
, ~
Sensitivity Analysis
The aim is to see if the Business Case is heavily dependent on a
particular benefit. If it is, this may affect project planning,
n
monitoring and control activities and risk management, as steps
would need to be taken to protect that benefit.
Gap Analysis
:J
GAP here stands for good, average and poor. It is sometimes known
as best, worst and most likely cases. It consists of taking these three
views of the achievement of the benefits, i.e. what are we really
expecting, what might we achieve if things went well, what might be ~
the worst-case scenario? The latter might be affected by building
into the costs an allowance for estimating inaccuracies, tolerances
and risks. This usually reveals ifbenefit expectations are reasonable
or are really over-optimistic. The result of this analysis can lead to
revision of the decision to go ahead with the project. This would
form a basis for setting benefit tolerance.
Cash Flow
The Business Case is calculated by establishing the difference between
the 'do something' option and the 'do nothing' option and comparing thi s
with the investment cost required for the project.
The most straightforward way of expressing this is via the cash flow
model. (~
"-../
Each organisation has its own standards, but they are all loosely based on
the concept of a cash flow model. A simple table to illustrate this would
assume a development period of one year (year 0) and a system life of
four years (years I to 4). The table would have four 'rows' or entry lines.
The costs row within the table then represents the development costs in
year 0 and the predicted running costs of the delivered system over years
1 through 4.
The benefits row represents the benefits predicted from the operation of ~
the delivered system. The net benefits row represents the benefits minus ....}j)
92 7)
( ,' Managing Projects the PRINCE2 Way Business Case
the costs for each year. The cash flow row is the cumulative running total
of the net benefits.
YrO Yr 1 Yr2 Yr3 Yr4

Costs 60 5 5 5 5
Benefits 0 20 25 30 25
Net Benefits -60 15 20 25 20
Cash Flow -60 -45 -25 0 20
"-
This is about the simplest possible representation of a cost benefit
analysis.
The problem with this example is that it does not account for the 'time
value of money'. This concept states that money received in the future is
not as useful as money received today, therefore it must be considered as
being worth less.
If the reader were to be asked whether they would rather have £100 now
or £ 100 this time next year, the answer will probably be liNow". Why?
.l'"
Because it could be invested in order to gain interest, or it could be used
to buy something that will cost more next year.
r;;,~
~j How much interest depends on the interest rate being used. If an interest
rate of6% is assumed, then giving someone £1.06 one year from now is
~'
equivalent to giving them £1 now. Equally, it can be said that giving
someone £1 next year is equivalent to giving him or her 94p now. Thus
the discount factor (as it is known) is, in this case, 0.94.
This 'discounting factor' is arrived at by the following fonnula:
_1
(l + i)n
(Where' i' is the interest rate used - e.g. 0.06 - and 'n' is the number of
'--.'
years hence).
Every organization has a standard interest rate that they use and it is
usually held in the finance department. The finance department will also
hold tables of discount rates against various numbers of years and interest
rates. This avoids the necessity for working them out. (If a rough
estimate is required, just use the current bank loan rate.)
Net Present Value
Discounting can be incorporated into a cash flow model.
~
93
Managing Projects the PRlNCE2 Way Business Case
(revised edition June 2005) . ( -'I
Each net benefits value is multiplied by the appropriate discount factor to )
arrive at the discounted net benefits.
Application of discounting can reduce the NPV (Net Present Value) of a
benefit quite substantially over a period of time. Ifwe take the example
above and apply a discount of 6%, the cumulative profit after four years
reduces from 20 to 8.7. ')
YrO Yr 1 Yr2 Yr3 Yr4 ')

Costs 60 5 5 5 5
Benefits 0 20 25 30 25
Net Benefits
Discount Factor
-60
1
15
0.94
20
0.89
25
0.84
20
0.79
9
Discounted
Benefit
-60 14.1 17.8 21.0 15.8
)
Net Present Value -60 -45.9 -28.1 -7.1 +8.7
Another way of expressing the time value of money is through Internal )
Rate of Return (IRR).
Internal Rate of Return
As the interest rate used to calculate NPV gets higher, there comes a point
where there is an interest rate that would give an NPV of zero over the
period of time given. T\.
That rate is known as the Internal Rate of Return (IRR), and is used to
Y
compare one project with another (to see which is the better investment),
and against the company standard (to see whether the money could be put
to a better use). IRR can be understood as follows . If all of the money
for the project development was borrowed, and the project broke even,
then the interest rate paid on that borrowed money would be the IRR
If IRR is used, then the accountants will have a formula, or more likely a
()
spreadsheet model, to calculate it. What is required to calculate it is an
interest rate that gives a positive NPV, and one that gives a negative one,
along with the values of those NPVs derived.
Links
As mentioned earlier, a basic Business Case should appear in the Project
Mandate, or be developed as part of Preparing a Project Brief(SU4).
There is a major link with the initiation process, which will refine and
expand the Business Case; Authorising a Project (DP2) in which the \~
94
Managing Projects the PRINCE2 Way Business Case
.f
Project Board should review the Business Case before it decides whether
the project should be undertaken.
The Business Case should be reviewed at the end of each stage in SB4,
Updating the Business Case. This forms part of the end stage assessment,
which is a review by the Project Board in DP3, Authorising a Stage or
Exception Plan, as part of its decision on whether to continue with the
project.
The impact on the Business Case is assessed for each major Project Issue
( as part of the sub-process CS4, Examining Project Issues.
Achievement of the Business Case will be finally judged in the post
-"",
project review some time after the project has finished.
Do's and Don'ts
Do examine the Business Case if those who will use the final product put
it up. Be sure that the Business Case fi~s are genuine, not just pulled
out of the air. Many impressive Business Cases are put up to endorse a
political wish or whim, but they do not stand up to close scrutiny.
If you are the supplier, beware of the temptation to write the customer's
Business Case. The customer has to 'own' the Business Case. The
customer may need some help in thinking in financial terms of how to
'''- justify the project, but if the project shoulp run into cash trouble, you
~r;", ....;
don 't want the customer saying "But you 'said it was justifiable."
If it's a Large Project
The Business Case is likely to take some time to prepare. There should
have been at least the outline of a Business Case in the Project Mandate
that triggered the project. It is likely that there was a feasibility study that
should contain a Business Case.
If it's a Small Project
r ;;; Don ' t ignore the philosophy that there sh\Juld be business justification for
o every project. A lot of small projects undertaken without business
justification can waste as much as one large project. It may be satisfactory
to carry out a short, informal Business Case appraisal, but the Executive
should still be convinced that a genuine Business Case exists.
~
C
C' 95
I -)
Managing Projects the PRINCE2 Way Project Organisation

Project Organisation
")
Philosophy
The organisation for any project should be based on a customer/supplier
relationship. The customer is the person or group who wants the end
product, specifies what it should be and, usually, pays for the
,}
development of that product. The supplier is whoever provides the
resources to build or procure the end product. This is true even if the
customer and supplier work for the same company. If this is the case they
may still, for example, report to different lines of management, have
_J
different budgets and therefore have a different view of the finances of
the project. The customer will be asking, "Will the end product save me
money or bring in a profit?" The supplier will be asking if the providing
of appropriate resources will earn a profit.
Establishing an effective organisational structure for the project is crucial )
to its success. Every project needs direction, management, control and
communication. Before you start any project you should establish what ~,
the project organisation is to be. You need to ask the questions even if it
is a very small project. Answers to these questions will separate the real
decision-makers from those who have opinions, identify responsibility
and accountability, and establish a structure for communication.
Examples of the questions to ask are:
• Who is providing the funds? _.
• Who has the authority to say what is needed?
• Who is providing the development resources?
• Who will manage the project on a day-to-day basis?
• How many different sets of specialist skills are needed?
• Who will establish and maintain the required standards? t)
• Who will safeguard the developed products?
r
• Who will know where all the documents are?
• What are the limits to the Project Manager's authority and who sets
those limits?
~~;,
A project needs a different organisation structure to line management. It
needs to be more flexible and is likely to require a broad base of skills for
a comparatively short period of time. A project is often cross-functional
and may need to combine people working full time on the project with ,
96 TV
C'."...". Managing Projects the PRINCE2 Way Project Organisation
others who have to divide their time between the project and other duties.
The Project Manager may have direct management control over some of
the project staff, but may also have to manage staff that report to another
management structure.
The management structure ofthe customer will very often be different to
that of the supplier. They will have different priorities, different interests
to protect, but in some way they must be united in the common aims of
the project.
Four Layers of Management
~
Corporata or
Programme
Management
Proj9CI
~::.: . Decfslon Board
ProJsct Manager
::;•....
Team Manager
~i.i\2\~) Figure Org 1
The PRINCE2 philosophy when designing what the project organisation

should be is to consider four layers of management. According to the size
and importance of the project, you may not need all four to be
represented, but that should be a decision you take when you understand
the philosophy and can compare it to the needs of a specific project.
Layer Three
Layer three is the Project Manager role, the day-to-day planning,
c~~ monitoring and control of the project. The work of this role is reasonably
easy to understand. But very often the Project Manager is not the person
providing the funds. The bigger the project, the more likely it is that the
Gv Project Manager will have to go to a higher level of management for

decisions and commitments on money, the specification of what is
needed, commitment of the resources required to do the job and
acceptance ofproducts developed by the project.
Layer Two
This thinking takes us to level two in the diagram, a layer called the
c- Project Board. This consists of those roles that are needed to take those
() 97
')
decisions that are too big for the Project Manager' s authority level. (.)
Examples of questions this Board would answer are:
• Does the Project Manager fully understand what we are looking I;)
for?
• Does this look a good way of spending our money?
• Is the proposed solution in line with company strategy? " )
• The project is not sticking to its planned timeframeand/or budget.
Should we continue or close the project?
• Do we want to pay for this major change request?
,D
• Are we prepared to accept the product being offered by the Project ~
.: '
Manager? V
• Does it meet our requirements?
Layer One )
A project may be part of a much larger programme or it may be a major
investment for a corporation, a key part of that company' s strategy. What
I am saying is that a project may be of concern to the very top level of
P:!)
management in the corporation. This would be the top layer in the
diagram. This layer is concerned with the business strategy. This layer .~I
provides a vision of what the company should look like and what it
should be doing in the future. It has to co-ordinate all the projects going
on to change the company to the vision that they have for it. There will
:~\\i.';
come a point when this layer says , "Hang on, we haven ' t enough time to !l'~,'
handle all the detail, we need to delegate." So for each project they
appoint a Project Board to act on their behalf within certain constraints. I
will address these constraints in the chapter on Project Controls.
Layer Four
()
There are two simple examples of projects that might need layer four.
l'-1
!.'""'· :;-
One is where the skill sets needed are so varied and/or the numbers of \-:'-, f"
0',
1:::»
resources are so large that the Project Manager needs help to manage the
whole thing. Geography may be a factor in deciding whether you need
Team Managers. If the developers are in groups some distance away from : '1
each other, it is very difficult to manage them all personally.

The other case is where the solution is to be provided by a third party.
~
.
The external supplier will want to manage its own resources . ,;~
';
,
.......
:1\
~ J9
98 I; J
)
~- .., Overview
To fulfil the philosophy described at the start of this chapter, I offer
for your consideration the PRINCE2 project management team
Corporate or Programme Management I

I
Project Board
@ll Customer
:
Supplier
Senior User I executive Senior Supplier I
t .~--=:..-=---=- --
Project
Assurance
-- IProject Manager
.....
- -. :>lIProject SUPPOI
[Team ManagerJ--' SuPPO~ [
,~., '," .... ,
structure.
FigureOrg2
The structure allows for the possible inclusion of the four layers of
management. Whether they are all needed depends on the specific
project.
It would be good ifwe could create a generic project management
structure that could be tailored to any project. Without knowing anything
about a project's size or complexity we could understand the same
G organisational terms and by fitting names to these understand quickly
who does what. But if we were to have one structure for all sizes of
project, it would be important that we made it flexible, a structure that
would be adequate for large as well as small projects, The only way in
which we can do this is to talk about roles that need to be filled, rather
than jobs that need to be allocated on a one-to-one basis to individuals. In
order to be flexible and meet the needs of different environments and
different project sizes, our structure will defme roles that might be
c··, allocated to one person, shared with others or combined according to a

project 's needs. Examples are given later in the chapter.
( 99
.)
Corporate or programme management hand the decision-making for a
')
project to the Project Board The Project Board members are busy in their
own right and haven't the time to look after the project on a day-to-day
basis. They delegate this to the Project Managers, reserving to themselves
the key stop/go decisions. If they are too busy or do not have the current
expertise, they can appoint someone to a Project Assurance role to
monitor an aspect of the project on their behalf. A typical example here ()
would be the participation of a company's quality assurance function on
behalf of the Senior User or the Senior Supplier. Another example oftbe
Project Assurance role would be a role for internal audit. ! ~)
Depending on the project environment or the Project Manager's
expertise, he or she might need some Project Support. This might be
purely administration, such jobs as filing or note taking, but it also
includes specialist jobs such as configuration management or expertise in
the planning and control software tool that is to be used on the project.
Links
()
Controls
There are many links between the roles in the project management
structure and the controls they exercise. The following are fully described
I. "
in the Controls chapter. This is just a summary.
Layer 1 - Corporate/programme management
Corporate/programme management controls the Project Board. They
exercise control in a number of ways.
They are responsible for the original terms of reference (project Mandate)
for the Project Board and therefore control the statement of what the
J~
project is to deliver, the scope and any constraints.
They can define the overall targets of the project in terms of delivery
,CJ
dates and budget.
They provide the Project Board with the limits of cash and time at a
project level beyond which the Project Board must return to them for a
lJ
decision on what to do (tolerances).
They appoint the Executive (very often a member of corporate/
programme management) to head the Project Board. They have the power
to appoint other members of the Project Board, if they wish to do so.
They indicate what reports at what frequency they want from the Project
Board.
t J)
100 ~
(:
Layer 3 - The Project Board
The Project Board has to approve that the project contract (Pill) drawn up
by the Project Manager is in line with the terms of reference handed down
to them (Project Mandate).
Within the project limits set by corporate/programme management the
Project Board sets limits of time and budget deviation for each stage of
the project. The Project Manager cannot go beyond those limits without
fresh authority from the Project Board.
c: The Project Board has to approve the products of one stage before the
Project Manager can move into the next stage.
The Project Board has to approve any change to the original specification.
This is more fully discussed in the chapter on Change Control.
A project cannot close without the Project Board confirming that it is
prepared to accept the results.
The Project Board stipulates what reports it wants from the Project
Manager, their content and frequency.
"~" The Project Board can appoint people to an independent Project

Assurance role to monitor various aspects on its behalf.
Layer 3 - The Project Manager
:,iW"
The Project Manager agrees all work with Team Managers (or if that role
is not used, with the individual team members).
The Project Manager can set deviation limits (tolerances) for a team's
work beyond which it cannot go without the Project Manager's approval.
These limits are set within those handed down by the Project Board for
the stage.
The Project Manager receives a regular report on each team's progress.
The Project Manager can monitor the quality of work being produced by
'c., reference to the Quality Log and the quality file, which have to be
updated by the Team Managers.
The Project Manager is responsible for the Project and Stage Plans and
~ monitors progress against these.
Layer 4 - The Team Manager
The Team Manager plans the team's work and agrees it with the Project
Manager.
The Team Manager holds regular checkpoint meetings with the team.
I I' 101
l
"

Plans
The Project Manager creates and maintains the Project and Stage Plans.
If there is a need for an Exception Plan, the Project Manager creates this. {~)
Team managers create Team Plans where required.
Risk ,J
The Project Manager maintains a Risk Log.
The Project Board and corporate/programme management are responsible
for the identification of risks external to the project.
?)
The Project Manager is responsible for the identification of internal risks.
An owner is appointed from the project management team to keep an eye
on each risk.
Quality
The Executive is responsible for the quality of the Business Case, at the
'1
., .." .\
~\ ,
outset and as the project progresses.
The Senior User role is responsible for the quality of the original
specification, for any user acceptance testing, and for confirming that the
solution's design and development continue to meet the user needs.
The Senior Supplier role is responsible for the quality of the developed
products.
A company's independent quality assurance function may be represented
on a project as part of the Project Assurance group. ~i~~
~_.J
Activities
Filing
A copy of the signed job descriptions for every member of the project
o
management team should be kept in the project file, together with an
organisation chart of the structure.
Do's and Don'ts
Don't just use the generic structure slavishly. Use common sense and
tailor it, when necessary, to the project.
Don't drop responsibilities. Do move them to another role if that makes
more sense for the project in hand.
Do make sure that all responsibilities are given to an appropriate role.
:.t',
102 ~
.'. ~
S~}
c~,
.:I
The larger the project the more likely it is that the project organisation
structw'e will need a person to fill each role. In fact the role of Senior
User may have to be shared between two or three people in order to get a
representative view of the user needs. It would be sensible to control the
number of people filling this role. I have seen projects with fifteen people
clamouring to have a share of this role. The phrase that always comes to
mind at such times is "It will take us half an hour to get the coffee order."
If you are faced with lots of "volunteers" for the role, organise them into
a user committee, which meets and appoints 'a spokesperson to represent
them all. The user committee can instruct the spokesperson on what they
are to ask for, then get feedback from the spokesperson after any Project
Board meetings. Do make sure that you are dealing with the decision
makers, those who can commit the required resources. Opinion-holders
should not be on the Project Board.
~?:.
",
Similarly a large project might have lots of suppliers. I do not recommend
large numbers of them to share the Senior Supplier role. Two or three
might be workable as a maximum, but it shouldn't be allowed to get out
:: ,~~"
of hand. If there are lots of external suppliers, organize the contracts so
that there is a main supplier who is responsible for the relevant minor
suppliers. Another possibility here is to appoint the company's
procurement manager to the role and make that person accountable for
obtaining the supplier resources. Before walking away from these ideas
on how to restrict the numbers taking these two roles, let me emphasize
that a key part of each role is their accountability for quality. The Senior
User role is accountable for the quality of the specification. The Senior
Supplier role is accountable for the quality of the products supplied as
part of the solution. Make sure that you have someone in the roles who
picks up this accountability.
There will normally be only one person as Executive. Remember the
L· Executive is the key decision-maker. The other roles advise and support
the Executive. The Executive is always the person in charge of the purse
strings. There may occasionally be projects where the supplier puts up
some of the development cash. In such circumstances the supplier would
quite correctly take a share of the Executive role. The division and
balance of the decision-making would need to be carefully thought out in
such cases.
Large projects are more likely to need to appoint people to the Team
Manager role. This may be because the project is using external
C contractors, has people working in different geographical areas or is using

a mix of skills beyond the Project Manager's scope.
( I 103
, ~)

(revised edition June 2005) ,""'\
If it's a Small Project ... ..J
Let's take an example. Your boss wants you to organize the department's
Christmas lunch at one of six restaurants in town for, say, 100 people.
Common sense says you don't want a huge number of people in the
project management structure. Your boss is paying, so he or she is the
Executive. The boss is also defining, or at least approving the
arrangements, and so will also take the Senior User role. In terms of ,.J
supplier the major resource used is going to be you. Who can commit
your time? Right, the boss again, so your Project Board consists of your
boss. In terms of Project Assurance, no doubt your boss is capable of
-,
checking that personally, so no extra people needed there. You will
probably do most, ifnot all of the work yourself, so no call for Team .~~
Managers. You might get someone to write to the restaurants or ask the
staffwhat their choice of menu is, but that would be the extent of the
"team" that you would need . The remaining question is whether you need
any Project Support and in a small project such as this, the answer is
,
likely to be "No". So although we began by considering the full project
organisation structure, we end up with a structure that looks like this:
. ' v~
," "
I I
PROJECT
ASSURANCE ,,~"Y.
"i'"!'~'
PROJECT SUPPORT
Your boss
You
TEAM
You
(and an administrative
clerk?)
()
Figure Org3
All responsibilities are covered without unnecessary numbers or people

being involved in their management.
There are two important things to remember:
• Use your common sense. Remember that roles can be combined
and ask yourself the question "OK, who can make that
commitment on behalf of the project?"
104 ~
(
• However small the project may be, you can 't drop any of the roles
or their responsibility and accountability. All you can do is move
these to another role .
...
(~
~;~
\....
105
Managing Projects the PRINCE2 Way Plans
~
Plans
Philosophy
A plan is the backbone of every project and is essential for a successful
-)
outcome. Good plans cover all aspects of the project, giving everyone
involved a common understanding of the work ahead. My friends at
)
Xansa use the following picture to provide a formal definition of a plan.
~)
'A plan is a document, rramed in accordance with a pre-d.eflned:
scbeme or metbod, d .. cr\bln~, ~ and by wbom a speclllc
target or set or targets is to be achieved'
(pRINCE)
----
')
Figure PI "
:I':\';i':
A plan defines:
• the products to be developed or obtained in order to achieve a ',)','
'. ,I,f,'
specified target;
• the steps required in order to produce those products;
• the sequence of those steps; rj
• any interdependencies between the products or steps;
• how long each step is estimated to take; ( ~~-,~)
• when the steps take place;
• who will carry out the steps;
• where controls are to be applied.
A plan:
• shows in advance whether the target is likely to be achievable;
• shows what resources are needed to accomplish the work;
,~\~
.~
• shows how long the work will take; I
106 -)
n ;.··,~
\(
. .'t
• shows who is to do what and when;
• provides a basis for assessing the risks involved in the work;
• provides the base against which progress can be measured;
• provides the information on the Project Manager's intentions to be
communicated to those concerned;
• can be used to gain the consent and commitment of those who
have to contribute in some way.
r;: A plan is, however, only a statement of intent. Because something is in
\~
our plan does not necessarily mean that it is cast in concrete. There will
always be uncertainties.
'~ It is commonly accepted that one of the most common causes of
projects failing to deliver benefit is a neglect of the planning process.
~:f, There are many reasons advanced for this, one of the most common being
that there is 'no time to plan'. What is really being said is that there is a
strong desire to start the 'real' work, especially if there is a deadline to be
met. The other side of this is where senior management does not
recognize the importance of planning, and will not make the necessary
time available.
The next excuse given for failure to plan is that there is 'no need'. This is
~
perhaps where:
• the job has been done before;
• the project is expected to take only a short time
• the Project Manager prefers to keep all the details ' in the head'.
:r.
'~':',~ There are, of course, dangers in these 'reasons' for not planning. Projects
are always different, with different people, size, complexity and
environments. Short projects can become very long when you realize that
you have forgotten something vital. The human brain can retain only a
very small number of linked events over a period of several days. When
you start adding the details of what is actually happening to what you had
planned, it doesn't take long for a required event to get lost somewhere in
the brain cells. Project Managers who say that they keep all the details in
their head are simply "fire-fighters". They lurch from one crisis to the
next, always having to put fires out. Sometimes they are hailed as whiz
kids because they solve (or waste everybody's time working around) a
problem. Most of the problems that they go around solving would not
have been there if they had planned properly in the first place!
Undertaking a project without planning is just leaving things to chance .
C"
.
1 107
lV.1<W.~eWe the PRINCE2 Way Plans
edition June
Often are to a
go about it. Sadly it is often the case that
necessary education and to allow them to do

needs to be leamed. It is not an inherent skill with which
UU..I.LU.Ul5
are born. There are Path resource

use of a that need to be leamed. Without
pll;1lDners are unlikelv to do a
The last excuse is that is What this means is that

is hard work. There is a great desire to 'get going' with the
»WJ..LLULQ..ll'" business of the technical challenge.
Plans
P2
This introduces the PRINCE2 meran:hy

At the outset of a it is always difficult to in detail the
reqlll.n:me:nts for the of all the produc:ts
your own activities that
months from now? we
the work for one or more teams of
however the may take)? It is
nevertheless necessary to overall estimates for the in
terms of duration and cost so that to can be
LJu.w.,LLL5Ievels within the
of detailed plan in order to dischan!:e their '''''VUJ''''..JLllLY
108
: !<,.,\\~.
Project Board and Project Manager need to assess the continuing viability
of the project and therefore require a plan of the total project in overview_
..,,", The Project Manager needs to apply control on a day-to-day basis and
therefore requires a detailed plan with activities broken down to a small
handful of days covering the next period of, say, a few weeks. This is OK
as long as there is a longer-term view available in less detail - i.e. the
Project Plan.
c
Similarly, if our project uses several teams, the Team Manager will need
.a detailed plan for the work of the team members. Again it would be
sensible to limit this to a short period of time.
We also need to create a new plan, and get it approved by the Project
~~~ Board, if the original plan goes wrong.
These will now be examined in more detail.
Detail
Project Plan
The highest level is the Project Plan, which is created at the start of the
project. The initial Project Plan is a part of the Project Initiation
Document. The Project Plan is a mandatory plan in PRINCE2.
The Project Board does not want to know about every detailed activity in
the project. It requires a high level view. This allows the Project Board
to know:
(, ,
• how long the project will take;
• what the major deliverables or products will be;
• roughly when these will be delivered;
• what people and other resources will have to be committed in
order to meet .t he plan;
(
• how control will be exerted;
,-
• how quality will be maintained;
• what risks are there in the approach taken.
The Project Board will control the project using the Project Plan as a
yardstick of progress.
It is worth remembering the Business Case at this point. The Business
Case details (amongst other things) the costs of development and
c operation of the completed product. The predicted development costs are

taken from the Project Plans. These plans are therefore essential to the
( 109
.'j
(revised edition June 2(05)
decision as to whether the proposed system is a viable proposition in (~
business terms.
Stage Plan
Having specified the stages and major products in the Project Plan, each
stage is then planned in a greater level of detail. This is done, as I just
said, just before the end of the previous stage. ~~
l
Stage Plans are also mandatory. If a project is very small you may wish to
physically include the detail needed for Stage Plans in the Project Plan,
but unless a project is very small it will be easier to plan in detail one ")
stage at a time. Another part of the philosophy that makes stage planning
easier is that a stage is planned shortly before it is due to start, so you
have the latest infonnation on actual progress so far available to you. )
The procedure at stage planning time involves taking those major
products in the Project Plan that are to be created during that stage, and
breaking these down (typically) a further two or three levels of detail.
Given that each stage is planned at the end of the preceding one, the
D
planner should now have a clearer view of:
~~
• what has to be produced;
• how well the people perform;
• how accurate previous estimating has been; ~
than would have been the case earlier in the project.
Stage Plans have the same format as Project Plans. ,Wi
,~
The Project Manager uses the Stage Plans to track progress on a daily
basis through regular progress monitoring.
Plan Narrative
() -"
The Project and Stage Plans should have a narrative section. Suggested
headings for the narrative are as follows: 1.7\
·0
• Plan description;
• Project (and stage) identification;
• The plan level, e.g. project or stage;
• Summary of the plan and its background;
,~!
• Intended implementation approach;
I
How do you intend to implement the plan? Is there anything in the

Gantt chart that might need explaining? Some examples might be: ~
.:J
110
o
Managing the PRlNCE2 Way Plans
! , ... -.-----------------J
You are not work on X as soon as you could because you
are waiting for the release of another
The construction work looks shorter than normal because we are taking
current product Y and it;
The testing work looks than normal because we will be the
product in a hazardous environment.
" Constraints or obiectives that have affected the
" Quality
Plans are shown in the
• Plan """"...."nh,,..n,,
On what assumptions is the plan based? are actual staff to
be allocated, help or from othel; sources at times. It is
essential to list your If the Project Board the
the Board is your as reasonable.
goes wrong because an asS:ruIlotilon
Board can't throw rocks at you it with the
assumptlC)Ds. It also the Board the chance to say if it
Qil'.i.ll1ll>< about the t1tat would make them
example here would be where you create a based on
old Fred wiU be your senior technician. If
the Senior Supplier that he or she,has already committed Fred
to another project, you can be told and re-plan. Ifno one knew of
your assumption and you went ahead with the feU behind and
came up with the lame excuse, "1 would have been alright ifvou had
me Fred", no-one is swing to be
• Plan prereqUlslltes
:n;m;;qwsnes are similar to on
one of the plan in order for the to for examole
trained and arrangements.
• External dependencies
• If the depends for its success on elements
the Proiect Manager's as deliveries
these would be identified here.
• Risks
111
)
This might be a copy of the entire Risk Log or the Project Board
may ask to see only the high probabilitylhigh impact risks and the
actions you have taken or plan to take.
• Tolerance
What tolerance levels are agreed for the plan?
• Reporting
J
The methods, recipients, frequency and formats for reporting during
the life of the plan may have been laid down by the Project Board as
part of the PID, but may vary according to the duration of a stage.
-)
Whatever the case, they should be stated as part of the plan ' s text.
Team Plan ... ,
Team Plans are optional. Their use or otherwise is dictated by the size,
complexity and risks associated with the project.
Team Plans are the lowest level of detail and specify activities down to
the level of a handful of days, say ten at most. Team Plans mayor may #.fi't'f.~.J
not contain the narrative sections associated with the higher levels. Ifthey
cover a large amount of work, it is sensible for them to have the same
format as the Stage Plans.
Team Plans will be needed when internal or external teams are to do
portions of the work. Part of the Project Manager's job is to cross-relate
these plans to the Project and Stage Plans.
_.'_1
Exception Plan
Finally, there is the Exception Plan. This is produced when a plan is
predicted to exceed the time and cost agreed between the planner and the
next higher level of authority. If a Team Plan is forecast to deviate
beyond tolerances, the Team Manager must produce the Exception Plan
and get approval for its introduction from the Project Manager. If a Stage
Plan is forecast to deviate, the Project Manager will produce an Exception t_)
Plan and ask the Project Board to allow the Exception Plan to replace the
current Stage Plan. If the Project Plan threatens to go beyond its
tolerances, the Project Board must take the Exception Plan to corporate or
programme management
The Exception Plan takes over from the plan it is replacing and has the
same format.
. ..,-,..,
112
~)
Links
There is a link between the structure of plans and the controls described
~
in the Controls chapter. For example, at an end stage assessment the
Project Board will examine the performance of the current Stage Plan and
be asked to approve the next Stage Plan. The Team Manager will prepare
a Team Plan and agree this with the Project Manager as part of accepting
a Work Package.
Do's and Don'ts
~ By all means use a planning and control tool. It is much easier to modify
a plan electronically rather than reach for the eraser. But don't let the tail
wag the dog. I have known Project Managers shut themselves in their
office for two or three days a week, adjusting the plan to reflect the last
set of time sheets. By the time they emerge, things have changed (slightly)
again and back they go to tune the plan again. By all means update the
plan regularly with actuals. But then stand back and look at what the
latest situation is telling you. If you have broken the plan down into
sufficient detail, you should be getting warnings of slippage or faster
progress than expected. Go out and have a word in the right ears. Can we
"
recover? Can we take advantage of the progress? Is anyone struggling and
in need of help? Project progress is often a case of swings and
'1\
roundabouts. We have a good week followed by a bad week or vice versa.
By all means update the plan with actuals every week, but the plan itself
should only be modified every two or three weeks on the basis of definite
corrective actions we need to take to put the plan back on an even keel.
Naturally if an event comes along that we know will require a major
change, don't wait. But a lot of small hiccups will sort themselves out if
.
;.:
the team knows that you know and have taken an interest in putting
~"'. I things right.
c You really will need to use a planning and control tool, a software
package. There may already be a standard tool that you are expected to
use. Think very carefully about whether you have the time to update it
with actuals. In a large project it may well be worth delegating the
L maintenance of plans to Project Support. Do you have expertise in using
the package? Can you afford the time to become an expert?
Many Project Managers struggle to create and update the plans
themselves. Many of them have had to learn how to use the tool as they
go along . In consequence they know about ten percent of the tool's
C capabilities, are ignorant of many shortcuts and easier ways of doing
( , 113
......,
1
things with the plan. The Project Manager's job is to generate the )
information to build the plan in the first place, use the updated plan as a
guide to the status and look ahead for problems or risks.
l)
You may be prepared to put enough detail into the Project Plan to allow
you to monitor and control the entire project. If so, no other plans are ~)
needed. But remember that in a small project you need to have broken
down the creation of each product to a small handful of days, otherwise
you will have insufficient detail against which to monitor progress. P]
-.:;/
Weigh this need for detail against the Project Board's desire to be able to
see the entire project on one page.
~
.§ I
:~!.
.;-,~r·~t
_. '
, ;,~
:..
\W
':;,1
.\.
".j,
.".
114 "0
Nlanagmg the PRINCE2 Way
Controls
Philosophy
Good control doesn't by accident - the control needs of a
need to be assessed and mechanisms in
Control needs - You can't tell whether you are behind or
ahead of ~"'l:~'l;;UI.uv, unless you have a
which you can COinpll.re. controls is part
process. Failure to activities means
won't get done.
Effective IWllnU:orilDg
Without accurate, is DlUD!lenng
about in the dark and to problems rather than
nre~V!"lnnTla or them in advance.
Control needs to be appropriate to - as with all other
of the level and of control should
In control system we will need to

is answer
What was to This is where lire vital.

Without them it is not to
What status information is
QUf~st1(lDis to be
answered.
What is the difference? actuals
us this.
How serio liS is it? - Without ~ome benchmark which defines
"serious" this cannot be decided.
is the here. See the later
What can be done about it? . reliable information about all

\JIC'=~Wl~ QUeSt:lons, sensible
decisions at the proper level
can now be made.
llS
"")
Managing Projects the PRINCE2 Way Controls
Introduction
Project control is perhaps the key element in project management. Some
J~
would say that risk is the cornerstone of project management, but, .~ j
although I deal with risk in its own chapter, I see it as one part of contro!' '"
Whatever your opinion is, I think we can all agree that it is vital. I have
di vided "control" into the various areas shown in the diagram below. ,)
:)
Stages
Tolerance
Dallv Lo
Team Manager
\,~'1
Figure Cl
;',.J
I shall take each one in turn and discuss it under the same headings used
for other project management components.
Stages
Philosophy ~
The Project Board only gives approval to the Project Manager to proceed
one stage at a time. At the end of each stage the Project Board verifies ~)
that the project's continuation can still be justified by examining the
status of:
• The Business Case;
• Risks;
• The Project Plan ~.
before it approves a detailed plan to produce the products of the next

stage.
~
J
116 :c,~
Ii:,
~>
A re-examination of the project at the end of each stage allows the Project
Board to ask these questions before deciding whether to proceed with the
next stage.
Stages give the Project Board these opportunities at formal moments in
the project to decide that the project is no longer viable and close it down.
The Project Board wants to be in control without spending all its time on
the project. It needs to feel it is making the big decisions, that it will be
' warned of any major problems in advance, and doesn't want to feel that it
t "
.•~~i has' a tiger by the tail', in that, once started, the project cannot be stopped
if it turns sour.
. Project Life Cycle and Product Lifespan

~ A project has a life cycle; the major activities through which it has to pass
in order produce the final product. A product has a lifespan, running from
the original idea through its development and use, until it is finally
withdrawn from use. The two are often confused. The diagram. below
shows the two together to clarify the differences.
,·',:'V
Ifii.,\",~~~i.,. \ Idea
e Study
"'"'' '''''' ,Tr.i.~~~~"., , "",.
Specify
Product
Design Project
Lifespan
Develop Life
Test Cycle
.""".~~~~~.~,q~~~",,,,
c.
Assess val ue
Use
Scrap
Figure C2
Technical Stages
The project life cycle consists of a set of technical stages, each of which
is distinguished by the production of one or more specific end products.
p-,' These products serve as the input for the next stage until we have
(:3 developed the final products of the project.
) 117
! 7'\.
:.' )

Management Stages
)
What have been described so far in this chapter are technical stages, those
parts of the project identified by their use of different techniques to
produce the various technical products. But now consider the division
into stages from the view of the Project Board. The Project Board is
driven by the need to control and approve the gradual progress of the
project, confirming that the Business Case still exists as well as assuring \.' o
li'
... .
itself that the various products meet the identified needs. This gives a
different perspective on the use of stages. )
What is a management stage? A management stage is a collection of
activities and products whose delivery is managed as a unit. As such, it is
a section of the project, and it is the element of work that the Project
\'.: ,
Manager is managing on behalf of the Project Board at anyone time. ,
,
,iI);'
WHY PLAN IN STAGES?
How can I make sure I stay in control?

How can I limit the risks?
How can I stop it if it goes wrong?
1;.,:",
Too much time planning

Too far ahead r)
Too many unknowns
Too much guesswork ~~
Lld
Figure C3
Project Board Reasons for Stages

The Project Board wants to be in control without spending all its time on
the project. It needs to feel it is making the big decisions, that it will be
warned of any major problems in advance, and doesn't want to feel that it ...,;-,\;;
has "a tiger by the tail", in that once started, the project cannot be stopped
if it turns sour. ,(\'
.. ~
118
t:J
,,:,'r;J. With risky projects there is the need to pause and make sure that the risks
are still controllable, so risky projects are likely to have more, smaller
stages.
~
The reasons, therefore, for breaking projects into management stages are
to give the Project Board opportunities for conscious decision-making as
to whether to continue with the project or not, based upon:
• A formal analysis of how the project is performing, based on
information about results of the current stage;
• An assessment of the next Stage Plan;
• A check on what impact the next Stage Plan will have on the
overall Project Plan;
• A check to confirm that the business justification for the project
and product is still valid;
.~:...
..l
~ • Confirmation that the risks facing the project are manageable.
A re-examination of the project at the end of each stage allows the Project
.~ "
Board to ask these questions before deciding whether to proceed with the
L\~ next stage.
Stages give the Project Board these opportunities at formal moments in
the project to decide that the project is no longer viable and close it down.
:.M~
They key criterion for decision making in business terms is the viability
of the Business Case. Is the justification for what we are doing still valid?
c, Ifnot, the project should be in jeopardy. Ifit is, then it should go forward.
These decisions are made in the light of the strategic or programme
~
objectives.
~~.' Unless the project is broken into management stages to provide suitable
points at which to make the decisions, the Project Board cannot be fully
in control of the project and its resources. The figure above i11u~trates the
C., benefits ofplanning in stages from the perspective ofboth the Project
Board and the Project Manager.
Project Manager Reasons for Stages
c For his or her part, the Project Manager does not want to spend huge
amounts of time at the outset trying to plan a long project in sufficient
detail for day-to-day control. Trying to look ahead, say, nine months and
plan in detail what will happen and who will dowhat is almost certain to
be wrong. How much easier it is to plan just the next few weeks in detail
and have only a high-level plan of the whole project.
119
=0
Stage ends are needed to obtain from the Project Board the required
commitment of resources, money and equipment to move into the next
stage.
Stage-limited commitment: At the end of each stage the Project Board
only approves a detailed plan to produce the products of the next stage.
The Project Plan is updated, but this is mainly for the guidance of the
Project Board and will become more accurate as more stages are
,)
completed.
Sign-offofinterim end-products: At the end of each stage, the interim
end-products are reviewed by all affected organisational functions, .... ~
particularly those that will use the end-products in order to develop the
products of the next stage. Throughout the life cycle, the concept of
feedback is important The end products from any stage must be )
compared with that of previous stages to ensure that a correct translation
has been made. The general trend through the life cycle is towards a
progressively more explicit, more detailed, more accurate, and more )
complete end product
In theory, at the end of each stage, the Project Board can call for
cancellation of the project because of the existence of one or more
possibly critical situations. For example, the organisation's business needs
may have changed to the point at which the project is no longer cost
effective. A project may also be cancelled if the estimated cost to
complete the project exceeds the available funds. In practice, however,
cancellation of a project becomes progressively more difficult to justify
as increasing amounts of resources are invested
In-stage reviews: As each product of a stage is produced it should be
reviewed for completeness and quality. All major product reviews should
include representatives from the user community as well as the relevant
technical experts. Other reviewers might come, for example, from an
independent quality assurance function. As a result, the final end stage
assessment by the Project Board is more of a formality because most (~
problems and mistakes have been spotted early on and corrected.
The in-stage reviews can be carried out formally as walkthroughs or
inspections or can be informal peer group sessions. How they are carried
out depends a great deal upon what is appropriate for the specific project
and upon the degree of rigor imposed by the methodology being used.
Generic task lists: No matter how different the systems being developed
are and how different the end products for identical stages, there is one
generic set of tasks to be carried out, regardless of the methodology ·
chosen. Therefore, if the same methodology is used to develop different
120
Controls
~<r~+",,",,~,
this set tasks varies little, if at
Since there is little variation in the set
consistency is ensured and activities are not omltt~:1,
oversight or
Technical versus MliJIlna,lll!'!mlmt StelQe,S
There mayor may not be an exact match between technical and
stages. For in a small the Project Board
may be to approve a that combines two or more technical
On the other if one technical will take many months to
complete, the Board may ask for it to be broken into two or more
for the purposes of"lanning and control.
Project Initiation Stage
it is sensible to a project with
what is referred to as an initiation stage. This is where the Project Board
and Manager decide if there is on:
.. what the is to "I'h;",,,,,·
.. why it is undertaken;
.. who is to be involved and in what
.. how and when the nroduets will be delivered.
This information is documented in the which is then frozen and used
as a benchmark the and at the end by the
Board, to check the focus and progress of the
Even in a with a Board of one person it is sensible to
begin with an initiation a small project it may take half an
hour or so to this but an number
into trouble because outset. It is very easy
to make assumptions on what you think is and get it wrong. If
ll....UU"1' off in the wrong direction, then you
wrong to waste a lot money and effort. It is

also easy for a member of a Board to forget the VU~llJ.a.
am:eeJnelLlt and to think quite different was
~ ...''''...,.,''''< and scope and who
was committed to do what can save the from many
arguments and headaches later on in the
Links
The links to end assessments the
Board.
121
~
Managing Projects the PRlNCE2 Way
Controls
There is also a link to risks. As mentioned before, the riskier the project,
the shorter and more frequent the stages may be to enable a formal risk
-,
review to be done by the Project Board as part of the decision whether to
-
I~
._-,.
continue.
Another link is to the tolerance levels, described next in this chapter. It
gives the Project Board tighter control to set Exception limits for the next
stage than simply to have exception limits for the entire project.
Do's and Don'ts
Always have an initiation stage, however short the project. ------
Don't split a project into more stages than Project Board control requires.
Don't have a stage that is longer than you can comfortably plan in detail.
Remember, a Stage Plan is going to be the Project Manager's main basis
for control. This means that you need to get each piece of work that you
hand out down to a few days. This will allow you to monitor whether the
work is slipping or not. A fact of life is that people only realise they will
not finish on time when they get near the target date. If the pieces of work
are twenty days or more in duration, then by the time the person tells you
~
they will be late, it is usually too late to put any exception actions in ;;
place.
The stage-limited commitment, which is sometimes referred to as a
"creeping commitment," is especially important for large projects with a
rapidly changing environment that makes it almost impossible to develop
an accurate plan for the total project at the outset. However, this type of
commitment requires that the provider of funds for the project must
accept that the estimate for the completion of the system will inevitably
change with time.
}
,~
Even in a tiny project with a Project Board of one person it is sensible to
begin with an initiation stage. In a small project it may only take half an
\J
hour or so to get this understanding, but an amazing number of projects
get into trouble because of misunderstandings at the outset. It is very easy
to make assumptions on what you think is needed - and get it wrong. If
you start the project by heading off in the wrong direction, then you only
need to be slightly wrong to waste a lot of time, money and effort. It is
also easy for a member of a Project Board to forget the original
agreement and begin to think that something quite different was
requested. Documenting the initial agreed objectives and scope and who ! 5{
122
c Managing Projects the PRINCE2 Way Controls
was committed to do what can save the Project Manager from many
arguments and headaches later on in the project.
"~ Tolerance
Philosophy
• Tolerances are the permissible deviation from a plan without having to
(,
-.;. refer the matter to the next higher level of authority.
No project has ever gone 100% to plan. There will be good days and bad
c days, good weeks and bad weeks. If the Project Board is going to
'manage by exception' it doesn't want the Project Manager running to it,
saying, "I've spent a pound more than I should today" or "I've fallen half
r' a day behind schedule this w.eek". Butequally the Project Board doesn't
~ want the project to overspend by a £million or slip two months behind
schedule without being warned. So where is the dividing line? What size
.;.t\:
of deviation from the plan is OK without going back to the Board for a
decision? These margins are the tolerances.
The second philosophical point about tolerances is that we don't wait for
.~;~'~ "::. tolerances to be exceeded; we forecast this, so that the next higher level
of authority has time to react and possibly prevent or reduce the
deviation.
@~) Overview
The two main elements of tolerance are time and cost. Other elements
that may be considered are scope and quality.
(j Ifwe remember the four levels ofproject management:
• Corporate/programme management sets the project tolerances
within which the Project Board has to remain;
• The Project Board agrees stage tolerances with the Project
Manager;
• The Project Manager agrees tolerances for a Work Package with a
' Team Manager.
c
( 123
~\

The diagram below will help to explain the concept. )
MaximumUme
'J
I,'"
'. ,
, & cost tolerance

I
I
I
I Actual Plan
Minimum time &

~
cost tolerance
Cost /
/
/
~)
./
""
- ./
TIme
Figure C4
)
As long as the plan's actual progress is within the tolerance margins, all is
well. As soon as it can be forecast that progress will deviate outside the " ",\\~
tolerance margins, the next higher level of authority needs to be advised.
Detail
Project tolerances should be part of the Project Mandate handed down by
corporate/programme management. If they are not there, it is the
Executive's job to find out from corporate/programme management what
they are. ..~.;\
The Project Board sets stage tolerances for the Project Manager within
the overall project tolerances that they have received. The portion
allocated to a stage should depend on the risk content of the work, the
extent of the unknowns (such as technologies never used before,
:)
resources of unknown ability, or tasks never attempted before).
"
The Project Manager negotiates appropriate tolerances for each Work t , .)'
Package with the Team Manager. Again these will be tolerances within
'"---,"
the stage tolerances set for the Project Manager.

Links
There is a link to the Controlling a Stage process that will bring any
forecast deviation to the notice of the appropriate level of authority.
Do's and Don'ts
What do we do if a project has such a tight deadline that our shortest plan
can only just achieve that date, i.e. we are offered no time tolerance? We ~
fjI
124 ')
.-.,;'.
try to enlarge the cost tolerance. This wou1d allow us to pay for overtime,
extra resources, better equipment, better resources, anything that might
save time if the target date was threatened.
If the converse was true and no cost tolerance was offered, we would ask
for a greater time tolerance. This would allow us to not use overtime,
drop some resources, use cheaper resources.
If both time and cost tolerances are tight, this is where we look at the
other two elements, scope and quality. For scope we list everything we
c: have to deliver in order of priority. Then if the going gets tough, we take
the list to the customer and say, "You can't have everything within the
tolerances. What products can we drop?"
c-· Quality is the dangerous aspect of tolerance. This is because quality
reduction can happen without your knowing. If a team knows that it is
under time and/or cost pressure, the easiest thing to do is relax on the
i qUality checking, carry out fewer tests, let things slip through that you
know aren ' t exactly right. Occasionally there may be quality concessions
that can be made in order to stay within other tolerances, such as "You
can have all the products, but you can't have the colours you wanted."
It is very important to establish tolerances at all the levels described. The
~~:; Project Manager shou1d consider carefully any tolerances for scope and
quality that may be called upon. Priorities for the various elements of the
product need to be agreed at the beginning so that they can influence the
sequence of design and development. There wou1d be no point in trying
to down-scope late in the project if all the minor 'nice-to-have's' have
already been developed.
There will probably be no Team Managers. In that case the Project
Manager may still wish to allow a small tolerance for an individual's
G I Work Package. The danger in telling an individual that they have a
certain tolerance is that the tolerance becomes the expected target. For
example, if you tell a person that they have until Thursday to do a job
with a tolerance of one day, in their mind the target becomes Friday.
Some managers prefer to set tolerances but keep these to themselves.
Management Controls
Management controls work around the three areas of getting a project off
to a controlled start, controlling progress and bringing the project to a
controlled close. Let's take a look at the necessary management controls
following our concept of up to four levels of management;
c 125
Controls
Manager and
Team LUu.u""""""
Corporate/Programme Management Controls
~n1T\nTl'It/';/nrnOTl'Immp.
management will have many
the minimum of time on
This is the start
agree the overall project time and cost ro""p,....,,,,·,,
Executive of the Board and say "Get on with it. As as you
are on course, just send us the odd But come back to us
forecast that you are limits we have
with you."
Overview
For the maximum amount
"'1J~'VlliC one of their
members to be the Executive. can people to other
Board roles or leave the selection to the Executive.
Detail
Project Mandate
:ol1)Orate/pDOgI:aITune .l.I.J4Wl.l!;"J..LJlvJ.U will be for the creation of
Mandate, which they win pass to the Executive of the
Board. This them control over the scope and
constraints.
Mandate should
ext:)ect:ati<)ns of the final This should cover
perfon:naI1Ce, "ua;uHn,y. and maintJlinshility
Project Closure
It is a for the Executive to confirm with corpOl:ate:/progI~an:une
management its Project Mandate has been by the detail
the brief and later the PID.
;oIJporate/pr.ogramme llUllllit:gerneIlt set the tolerances. This allows

them to define the circumstances under which the Board must
refer to them for a go rather make the
decision itself.
126
There will be entries in the Communication Plan to descnoe how the
Project Board, or at least the Executive, will keep corpomte/programme
management informed.
,\~;. !
A higher-level architecture group may prescribe the project approach
where the project is part of a programme. It will have to conform to the
same architecture as the other parts of the programme. The Project Board,
especially the Senior Supplier, has to check this.
Do's and Don'ts
( Do keep reports and meetings to a sensible minimum. Try to avoid the
monthly progress meetings where your project is one item on a crowded
corpomtelprogramme agenda.
Do avoid appointing the Project Board from below, i.e. without reference
to corpomte/programme management. This only leads to mistrust of the
Project Board by corporate/programme management. If this happens, any
-,: ".~
so-called "decision" by the Project Board will ping-pong between them
and corpomte/programme management for approval by the latter. What
you are looking for is a Project Board that has the confidence of
corpomte/programme management, so that once the Project Board has
taken a decision you can move on.
.0" ~, I
f'''I
;\01
The controls and reporting should be documented and copies kept by the
Project Manager.
It is unlikely that a small project will interest corporate/programme
,':
management. In this case the Executive will assume the role.
Project Board Controls
Philosophy
c The Project Board wants to 'manage by exception' , i.e. agree a Stage Plan
with the Project Manager and them let himlher get on with it without any
interference or extra effort - unless the plan looks like going wrong.
Overview
The Project Board 'owns' the project. Its members are ultimately
{.7 accountable for the success of the project, not the Project Manager. This
~ is why the Project Board members must have the requisite authority to
commit resources and make decisions.
Project Board members will be busy with their other jobs, and therefore
will want to spend the minimum amount of time controlling the project
(, 127
-'')

commensurate with making sure that the project meets its objectives
')
within the defined constraints. Like corporate/programme management, it
wants to 'manage by exception' .
Detail
Controlled Start
Project MandatelProiect Brief ,.)
The Project Mandate should contain the project objectives,
Customer Quality Expectations and Project Approach, among other
things. One of the first tasks in PRINCE2 is to add any missing
information, turning the Project Mandate into the Project Brief. It is
therefore very important for the Project Board to examine this
document and be satisfied with its contents before agreeing to
initiate the project.
Initiation Stage Plan
The Project Board examines the plan to see if it is appropriate to the
work needed to initiate the project. This will be affected by any
'~
previous work done if the project is part of an overall programme. ~
Project Tolerances
Corporate/programme management sets tolerances for the whole
project. It is the Executive's job to ensure this information is made
available at the outset of a project as part of the Project Mandate. ,"-,
Project Initiation Document

The Project Initiation Document (PlD) is the internal 'contract' for ~)
the project, documenting what the project is to do, why it should be (
done (the Business Case), who is responsible for what, when and
how products are to be delivered. There has to be agreement by
cus~mer and sup~lier on its conte~ts before.commitment to the
project by the Project Board. If a VIable Busmess Case does not
to '
.
exist, the Project Board should not proceed with the project.
Controlled Progress
Stage Tolerances
The Project Board defines the maximum deviations allowed from
the Stage Plan without the Project Manager having to return to the
Board for a decision on action to be taken. Ibis is the key element of
'management by exception'.
128
Controls
The best way of is the

defined by the
Uo<:ument, the
confmn achievements tn"Jl>TI1" mleeimg
rugnuglll is determined by the

Pfoduced
The Manager prepares J.""!5ll',.!5ll' ... "",,,.,.,.,..

information provided by the team members and
The principal focus of the Highlight is to identify:

DroOUCLS COlffit:,lelted the current reporting
proouCLS to be completed in the next period;
any real Of potential pr()bll:ms.
Other limited narrative such as the budget and risk
status, can be added up to a total of one page of paper.
H
and products in the project

it is only right that the Project Board
Illll.lil.UUIl. have to
changes to them. Once have been
estimated for the effort and cost
decide on their whether should be done and whether
the money to do them can be found. As for all the other it
needs an assessment of the on the the Business
Case and the risk situation.
If the will end outside its

tolerance must be sent to
the Project problem. OPtions and a
recommendation.
It should be stressed that if the is not reliable

progress it will be to know when that point has
been reached..
129
;..
':'-)
Exception Plan )
If the Project Board, on reading the Exception Report, decides to
accept a recommendation to proceed on the basis of a modified plan,
it will ask the Project Manager to produce an Exception Plan, which
replaces the remainder of the plan.
The technical term for exceeding (or predicting that you will exceed)
1
tolerance is 'exception'. When the project is facing an Exception,
the formal approach dictates that the Project Manager should
prepare an Exception Plan and present it to the Project Board for
approval. The less formal approach says that there may not be a
~
meeting, but the Project Manager still needs to get hislher plan of
remedial action approved by the Project Board. )
End stage assessment
The end stage assessment happens, surprise, surprise, at the end of
each management stage, where the Project Board assesses the
)
continued viability of the project and, if satisfied, gives the Project
Manager approval to proceed with the next stage. .~
The Project Board must be aware of the need to avoid technical or
irrelevant discussions and to focus on the management aspects ,\\
which, when taken as a whole, inform its decision on whether to
proceed or not. As a rule of thumb an end stage assessment should
not last more than 2 hours, even for a large project. A sensible ;;.~
Project Manager will have been in touch with the Project Board,
either verbally or in Highlight Reports, making sure that the
members know what is coming and finding out what they think
about the future of the project. "No surprises" is the best way to .,~"'
J
ensure short end stage assessments.
Of course, the 'bottom line' is whether the project is still predicted

to deliver sufficient benefits to justify the investment, i.e. is the ~)
Business Case still sound?
The other aspects of the end stage assessment are:

J Current progress checked against Project Plans;
IJ Current stage completed successfully (all products delivered
and accepted);
~ Next Stage Plan examined and authorised;
::\.
130 b,'\
lJ
edition June 2005)
Confinnationthatruldeliv~ have
their pre-defined quality ".u","'•...,.
to proceed form bv ill Board
members.
The the tltt"\1"\TV'\'tl"<\) 1
the
next cannot
approves its Plan.
The detail of the next Plan may often cause modification of

the Plan. The Board checks the both
the version of the Project Plan and the revised version to
""U"'6"" have been made. Any changes should
l1nlun'I!~r1 requests for change) before "nT,""',,,,,
Controlled
As of its decision on whether the project may close the

Board receives an End Report from the Project In,wal;\Cl
",,,,rfnrrn<>nI'P in meeting the
ctl2lllg(~S that were made.

It is
"uu....6'~"that were made after the Initiation Document

are and their Business
risks is assessed.
Issues and their on
statistics on the of work carried out. It is
.lY""'U<1~"1 and submitted to the Project Board.
The Board uses the Initiation Document to

confirm that the has achieved its originru objectives,
l.U,""UAUI.lll'; the
131
~
Issue Log I .~
..
This is used together with the Project Initiation Document to check
how the original objectives ofthe project were modified. It is also \
used to match against the Follow-On Action Recommendations to
ensure that there are no loose ends.
Quality File ,,~~
...: ').
The Quality File gives the Project Board an assessment of whether
the appropriate quality work was put into the project's products and
whether there is an audit trail available. ~)
Follow-on Action Recommendations
The Follow-On Action Recommendations document any unfinished )
business at the end of the project.
For example, there may have been a number of requests for change ~
that the Project Board decided not to implement during the project,
but which were not rejected. Not all expected products may have
been handed over, or there may be some known problems with what '·'.".. .
lJ 1 .1\;",
,
has been delivered.
The Follow-On Action Recommendations allow the Project Board to

direct any unfinished business to the person or group whose job it
will be to have the recommendations considered for action after the
current project has ended.
ii?\'~;';\',·
The Project Board is presented with a list of all outstanding actions

that are to be handed to the group that will support the product in its
operational life. These may be change requests that the Project
Board decided not to implement during the life of the current project 'J
or risks identified during the project that may affect the product in
use. The Project Board has to confirm that all outstanding issues
have been captured, and satisfy itself that nothing on the list should
have been completed by the project.
Post-Project Review Plan
Nonnally many products need time in use before the achievement of
their expected benefits can be measured. This measurement after a
period of use is an activity called a Post-Project Review. The
Executive on the Project Board will be responsible for ensuring that
these measurements take place. The Project Manager has to provide
,}
132
J
Con1:ro1s
whom these measurements are to be
The Review occurs outside the and, as is

not oart of the
corrective work the Review would be

use and maintenance. Any oroblems mav not
n"",ilnM but or!~anlsational
The Review can

after the oroiect has finished
the
The should seek confirmation of customer

of the end
""''''Pnt"T'lt'.. before the Proiect Board to
allow the to close.
Links
There is a link to the tolerances.
Another link is to the control because the Project
Board makes the decision on whether are to be implemented or
not.
confirming
Initiation Document has been
IJH,)'U .... '~. a(;ceptea. However small the proiect has
never assume has been acc:epl:eci
133
Don't allow the Project Board to let the project drift on into modifying
'j
the end product or creating extra products outside the scope of what was
agreed during initiation. Any such work thought up by the customer when
you deliver what you believe to be the end product should form part of
another project and another Project Initiation Document. You will not be
able to measure the success of the project fairly if you allow time and cost
to be added for work that is not covered in the Project Initiation
Document. Remember, project success is measured against the Project
'- ,)
Initiation Document plus any approved change requests. It is your own
Business Case that will suffer if you allow last minute "wouldn't it be )
nice if" tinkering to creep in.
All of these controls should be used and documented.
Many of these controls can be done informally, but the Project Board
should always consider what documentation of its decisions is needed in
case things turn sour later.
Project Manager Controls ~
Philosophy
A project is broken down into stages. The Project Manager is in day-to
day control of a stage based on a Stage Plan that the Project Board has
J
approved. The Project Manager carries on with a stage until its end
without needing another approval from the Project Board unless either:
".
.'-.',":l• .
• There is a forecast of a exception beyond tolerance limits or;

• Changes have been requested for which extra resources are needed. ~)
Overview
The basic idea is to:
• Agree with the Project Board what is to be done and the
constraints within which the job has to be done;
'0
• Get approval from the Project Board for a plan to do the work;
• Direct teams or individuals to do the necessary work;
• Confirm with the customer that the products meet requirements;
• Report back that the job has been done.
t.)
134
9
'-'~QW.<ll!;J.J..1" Projects the PRINCE2 Way Control!!
eclition June 2005)
into stages, using tolerance levels and 0""",,,,,,,,...,,.,
"U~>-,U1~1 Reports with the Project Board ,",Ulll)J-'<;;Ul<;;U.I.l>
logeml;:r all the

justification for the
The must ensure that the expectations have been

defined before the initiation This is the start point for quality
in the are it is the customer's job to obta.in
them.
The defines the method of providing the solution

needs. of a Approach are:
Do we do it ourselves from scratch?
Do we an existin2 oroduct to make the new oroduct?
Do we ask another company to make it for us?
Can webuva
Aj:!pf()ach may have
of a programme, e.g. "We have
to use IBM mainframes for our so
don't suggest a design for your of the programme uses
" The has to decide
Annroach to be nrovided
135
~
Project Brief ~
The Project Manager adds any missing information about the
project's objectives to the Project Mandate.
Project Plan
The Project Plan is a high-level view of the whole project created at
the outset as part of the information required by the Project Board on
)
whether to commit to the project.
Acceptance Criteria ~
Acceptance criteria should be agreed with the Senior User at the
outset. This list defines a checklist of criteria. If at the end of the .::::..
project it is agreed that all criteria have been met, then the Project
Manager can ask for closure ofthe project as having met its targets.
Controlled Progress )
Quality File
'-',j
The Project Manager enters details of all planned quality work in the
file. Those responsible for carrying out the quality work update it
with actual results; The Project Manager then monitors this on a
regular basis. '"
Work Packages
A: Work ~ac~~e is an agreement between the Project M~ger and (f:.\
eIther an mdiVldual or a Team Manager to undertake a pIece of ,.~"
work. It describes the work, agreed dates, standards to be used,
quality and reporting requirements. No work can start without the
Project Manager's approval via a Work Package, so it is a powerful
schedule, cost and quality control for the Project Manager.
Team Plans ©
Where the Project Manager is dealing with several teams, as part of
agreement on a Worle Package, the Project Manager has to agree the
team plan to produce the products involved. This is then reflected in
the Stage Plan. The Project Manager can use this to confirm that the
plan is reasonable, will fit within the stage tolerances given by the
Project Board, and that it contains adequate quality work.
Checkpoint Reports
This is a Highlight Report from a team to the Project Manager. It is
sent at a frequency agreed in the Work Package.
136
Controls
is to check all aspects ofthe

Plans to ensure that there
_ to answer are: 'What
is not and 'What is not to go to plan?' The
crucial that underlies the of the meeting is "Are
we still likely to the stage within the tolerances laid down
by the Project '''CU'''''''-'
Checkpoints should be taken as tteClu€:mtlv

may coincide with the
re;)Ummmg. thechec~'omt
occurs
The information at a checkpoint is recorded for the Project

Manager and forms the basis of the Highlight
The Issue is a
1cc(;~llJtg track of all prOl)leDlS
contains the answer to Board qU\;;SlIons
to cost more/take
initiation?"
lU<lJ..lal';'" monitors this to check that

and also to check for
IJ'QJlA.U"'U,
The status of risks should be monitored regwarl)l

but should also be checked
The activity network shows what is on the critical at the

moment and how much float an activity has. This is useful to the
Manager in what to check on, which are
serious and which are not.
which the
is \AJlllWlillll!.
137
Configuration Management
-,
Configuration management is the identification of the products to be
created/used by the project, their tracking and control. This provides
the Project Manager with the status of products.
Daily Log
Philosophy
)
Apart from the Stage Plan a Project Manager often needs a diary to record
significant events or remind him or herself oflittle jobs to do in the
coming week.
J
Overview
The Project Manager keeps a Daily Log in which to record important Q
events, decisions, happenings or statements. This is partly a defence
mechanism in case some time later the other person forgets that they said
something, but also to become part of the project manger's monitoring ')
/
that what was said actually happens.

It is also useful for the Project Manager to set up a number of monitoring ~. ,,~
activities for the coming week. J:J
Detail .,
Before the start of each week the Project Manager should take a look at
the Stage Plan, the Risk Log, the Issue Log and the Quality File. This
should provide a number of monitoring points for action during the week, §)_
, ._
such as: h .·
--~",.
• What is on the critical path of my plan that is supposed to finish

during the week? Is it going to finish on time? (Or else?) Did it ( '"
~oo~ .~
• Should the status of any risks be checked this week? Is it time to
give a risk owner a nudge to follow up on the risk's status? (: ' )
• Are there any outstanding Project Issues that I should be chasing -./
which are out for impact analysis or for consideration by the
customer?
Control/ed Close
Acceptance Criteria
If all acceptance criteria can be ticked, this puts the Project Manager
in a strong position to say that the project has achieved its objectives
and can close.
()
138 ()
PTf\;....... tc the PRINCE2 Controls
The Librarian does a check on all products produced

and their status. This confirm.s that all have been <In.,,·,,'uPri
a necessary check before work to close the can begin. This
area win also be for the end nroduct to the
group.
Issues should have either been dealt with or have

held over and passed to the operational
M~~ger must checkthe status of all
issues as
lYUmager must obtain some form of customer ac4:::QW1Ce

Board can be asked to confirm project closure.
this may be formal or informal.
The who will take over responsibility for the end in

its life must agree that they are prepared to so, i.e.
that the is in ~ state.
Links
Controls link to the on project organisation as of the "who
does what".
There is a link to the work needed. in Starting up a Project
There are links to Control and Configuration l"J.<Wa..15I;;;LUC.lll.
There is a link to the Daily
Do's and Don'ts
Do check the need for all these the environment ofthe
the comfortable at the start of a

cornmitted, and behind you. This is the direction
oru~.K-stabbJlng occurs! That "togetherness" feeling can evaporate as
problems and/or crulDgj~S
139
Managing Projects the PRlNCE2 Way Controls
would be little need for controls and documentation of who agreed to do
what and why. But life has a way of changing, people change their minds,
forget things, unexpected events occur. Just in case things tum sour you
need to have the controls mentioned in this chapter available to you and
to be able to lay your hands on documentation to support why the project
did what it did. ~
All of these items should be considered for use. Their documentation and
safe filing should also be considered as they will form a key part of the "'"
Project Manager's audit trail of why things happened and who decided ....J
what.
If it's a Small Project -"D
Many of the controls can be done informally. There may be no tea.ms or
only the one reporting direct to the Project Manager with no Team
Managers appointed. This shortens the checkpoint control. The Project
Manager would hold the checkpoint meetings with the team and write up
the Checkpoint Report personally.
Team Manager Controls
Philosophy
I:,:,
The Team Manager may work for an external supplier. Even when the
Team Manager works for the same organisation as the Project Manager,
they may have different line managers. Therefore there has to be a means
of agreeing work to be done, reporting progress and returning the ~",~, .
completed work.
Overview
The controls between Project Manager and Team Manager, Team ('
Manager and team member are based around the Work Package.
Detail i·,"M
\'~~j)
Work Packages
A Work Package is an agreement between the Project Manager and
a Team Manager to undertake a piece of work:. It describes the
products to be delivered, agreed dates, standards to be used, quality,
reporting and approval requirements. The Team Manager has to
ensure that the requirements of a Work Package are realistic before
accepting it on behalf of the team. If agreement cannot be reached
with the Project Manager, the matter would be referred to the Project
Board.
(J
140 l ;J
p
~-~
Team Plans
As part of agreement on a Work Package, the Team Manager has to
prepare the Team Plan to produce the involved products. The Project
Manager should agree tolerances for the work that are within the
stage tolerances.
Quality Log
The Project Manager enters details of all planned quality checks for
c the Work Package in the log. The Team Manager has to ensure that
it IS updated with actual results from the team's work.
Checkpoints
(J
~! A Checkpoint is a time-driven, team level control mechanism, where
the status of work in a stage or of a team is ascertained. It mayor
may not be a formal meeting.
It involves the people carrying out the work and is triggered by the
Team Manager. In larger projects the participants might be the
Project Manager, Team Manager and Project Assurance people. In
smaller projects it might be just the Team Manager and the team
members themselves.
,~,.,( ,
A specific aim of a checkpoint is to check all aspects of the
teamwork against the plans to ensure that there are no nasty
surprises hiding. Useful questions are: "What have we delivered?"
and "What is not going according to planT' The crucial question that
underlies the objective of the meeting is "are we still likely to
complete the work within the tolerances laid down by the Project
Manager?".
A checkpoint can also be used for the downward dissemination of
c/ information from the Project Board and corporate/programme

management by having them attend occasionally and talk to team
members.
Checkpoints should be taken as frequently as the Project Manager

requires in order to maintain control over progress. They may
coincide with the Project Manager's need to consider re-planning.
Overall, the checkpoint's frequency is determined at project
initiation and stage planning time, but usually occurs weekly.
'
(~, 141
\ :.J. !
;~,,~

Timesheets ')
In support of Checkpoint Reports, the Project Manager may ask for
timesheets, giving information on product start and completion dates
or revised dates. This is used to update the Stage Plan.
Time sheets are the standard method of recording time spent on

project work and are a prime source of project progress data capture.
r~
They are generally familiar to most people and their use is

~.'\
understood. However, a few points need to be remembered if their '1
~.
use as a monitoring devise is to be effective.
In order to gain a clear picture of all time (hence costs) spent on the
project, it is important that everybody involved fills in time sheets. ID~~,
:-, .
One of the historical problems with time sheets is that they tend to
be inaccurate. Accurate monitoring information is a prerequisite to G
sensible control decisions.
Time sheets also need to be returned regularly and promptly. The .~

later monitoring information is received, the later vital control '..
decisions will be made.
Time sheets should also be capable of being accurately filled in. ')
Often, people do not do this because there are, for instance, no codes
for particular types of work or products.
The above point is reinforced by the concept that time sheets should
allow for non-project work to be entered.
How often should time sheets be collected? The answer is (of (j

course) as often as the Project Board has specified in the Project and
Stage Plans. The typical interval is one week. Clearly, once the
1', ",'\.
effort expended has been recorded, then the cost of production can . )
be derived.
-.
"
Very often too much data is collected on time sheets. The more you
ask for, the less likely the figures will be accurate. On a Friday
a~emoon I have often seen people staring at the ceiling, musing
"Now what was I doing on Monday?" If you do want to track
genuine effort used, I believe that the Proj ect Manager should spot
check daily completion of the timesheet. But unless there is a
genuine need to collect actual effort as part of improving estimating
o
142 (J
c Managing Projects the PRINCE2 Way Controls
.~;
ability, I think that time sheet information can be reduced to three
questions:
When did I start this product?
Is it finished?
If not, do I need to revise the end date?
Links
c There is a link to quality. Another link is to the Plans chapter.

The Product Delivery process includes detail of the Team Manager's
work and should be read in conjunction with this section of the Controls
chapter.
Do's and Don'ts
Do read the Managing Product Delivery (MP) process.
Do think about the environment of the project, the political situation, and
the relationship between customer and supplier.
Do tune the needs of Team Manager control to the environment.
The Team Manager may work for different management to that of the
G Project Manager. This presents the problem of different objectives, a
different Business Case to which the Team Manager must work. To avoid
being caught in the squeeze between customer and supplier, or between
one supplier and another, the Team Manager should follow the guidelines
in the Managing Product Delivery (MP) process.
There will probably not be more than one team, and therefore this section
will be merged with that for the Project Manager.
c:
l,.
c
-
c 143
I'f'n,p,",r(: the PRINCE2
Quality
Any or actions about

out what the Customer's _
assume that the customer will want a
will last forever. Have a look at the products in your store
and you will see what I mean. Let me you two different examples
of customer aualitv from in my past.
COlnp~InY had bid for a switching
were the favoured ","","""~..
~ a
to fix any faults out there. Have we

the tender was recalled and when it it contained a
,...,."l1i,."t'nPTIt that said all and :su.vvm-;u
to have a mean time between failure of three years. This was backed
up by clauses in the event of failure. The '.a'U,ULlJ'p,
Telecommunications looked at its
included work "to a commercial level" and realised that this was
not So lots more such as each hardware
to the
"'i''"'I-''''''''''''L'' to take over in case and so on. The of their bid
lost the contract saved themselves
IO.ihl"Ul<U.!\}ll arm of an oil came to their data prC'Ce!'SlIlg

section with the results of a survey carried out in the mountains
of a South American They had a very short time in which to
the results and decide if there were oil or gas reservoirs there .
...V1"I,........ t".,... contract had to be renewed or they would lose their
favoured position. Their need was for accuracy

they a fast turn-around. weren't worried about
the result . The was to be used once
and then thrown away. There is a difference in the to
needed by these two
144
e Managing Projects the PRINCE2 Way Quality
Overview
So project quality tlrinking starts with the customer's quality
expectations. After that it is likely that both the supplier and the customer
will have quality standards already in place - a quality management
system (QMS). Both may also have staff responsible for ensuring that
... these standards are used. Depending on the environment into which the
final product will be delivered, there may be other standards to be
reached. An example here would be a car's emission levels if we were
"..
building a new car. All of these need to be matched against the
customer's quality expectations, the anticipated project timeframe, the
cost and the solution method. Out of this comparison we should get a list
of the development standards, the testing methods and the tools to be
used.
These quality requirements need to be related to the various products that
\f' the project will create or use. We then need to get down to putting into
our detailed plans the work necessary to ensure that quality is built in,
who will do this and when.
'il..' L,'~\I After this we need to consider an audit trail of our quality work. How do
we prove to the customer that the necessary quality work has been done?
Detail
~'~',
\::,'
STEP PRODUCT PROCESS/
TECHNIQUE
Ascertain the Project Mandate or Starting up a Project
c) customer's quality
expectations
Write a Project
Project Brief
Project Initiation
(SU)
Initiating a Project
r Quality Plan Document
\'-"";
Write a Stage Stage Plan Managing Stage
Quality Plan Boundaries
w Define a product's
quality criteria
Product
Descriptions
Product-based
Planning
Explain the quality Work Package Controlling a Stage
QJ requirements for
each piece of work
Report back on the Quality Log Managing Product
( J quality work Delivery
c) 145
.~
"J
.- .~\
Managing Projects the PRINCE2 Way Quality
I
performed ()
Check that quality Quality Log Controlling a Stage
work is being done
correctly
Control changes Project Issue Change Control
Keep track of Configuration Configuration '.-)
changes to products records -
Management
- .': )
Customer's Quality Expectations
The customer's quality expectations should be made clear in the Project
Mandate at the very outset of the project. Ifnot sufficiently clear, the
Project Manager should clarify the expectations when preparing the
Project Brief (during Starting up a Project (SU)). The expectations should
be measurable. ' Of good quality' may sound fine, but how can it be
measured? Expectations ofperformance, reliability, flexibility,
maintainability and capability can all be expressed in measurable terms.
Quality is one corner of a triangle as shown in Figure Q 1. The customer
has to decide where, within the triangle, the project's main focus is to be.
~
Does it incline more towards the cost, the time or the quality? This simple ,l,)'
exercise shows that the three items are inter-linked. If you want the
product to be cheap, that may have an adverse effect on the quality, and
so on.
'. ,)
!. '.. '
Cost Time
Figure Ql The Quality, Cost and Time Triangle

o
The Project Quality Plan
The next step is to decide how the project is going to meet the customer's
quality expectations for the product. Other inputs to this should be the
standards to be used to guide the development of the product and test its tj
146 (~
17·
~~"~'
Managing Projects the PRlNCE2 Way Quality
ability to meet the quality expectations. The supplier should have
standards, but the customer may also have standards that it insists on
being used. Such standards have to be compared against the quality
"(,~~, expectations to see which are to be used. There may be gaps where extra
standards have to be obtained or created. The customer has the last say in
c what standards will be used to check the products. There may also be
regulatory standards to be met
The Project Quality Plan identifies the standards to be used and the main
quality responsibilities. The latter may be a reference to a quality
assurance function (belonging to either the customer, the supplier or
both). There is a cross-reference here to the Project Board roles. These
roles contain Project Assurance responsibility, many of them affecting
quality. If these have been delegated, there must be a match with the
responsibilities defined in the Project Quality Plan.
The Project Quality Plan refers to the establishment of the Quality Log,
the quality file and their purposes.
The plan also identifies the procedures that will be used to control
~~. changes and the configuration management plan.
Product Descriptions are written for the key products shown in the
Project Plan. These include specific quality criteria against which the
products will be measured
The Stage Quality Plan
Each stage has its own quality plan containing lower level detail than the
Project Quality Plan. This identifies the method of quality checking to be
used for each product of the stage. The plan also identifies responsibility
for each individual quality check. For example, for each Quality Review
the chairman and reviewers are identified. This gives an opportunity for
those with Project Assurance roles to see each draft Stage Plan and input
c..
its needs for checking and the staffwho should represent it at each check.
Any major products developed in the stage have Product Descriptions
written for them if they were not done as part of the Project Quality Plan.
Product Descriptions
A Product Description should be written for each significant product to
be produced by the project. The description should contain:
~ • Title;
• Purpose;
• Composition (what are the components of the product);
( I 147
( ~)
• Derivation (what is the source of the components);
• Format (what does the product have to look like);
• Allocated to (What skills are needed for the product's creation)
• Quality criteria (what quality does the product have to display);
• Quality method (how will the product be tested that it meets the
quality criteria);
\)
• Quality checking skills required (what skills are needed to test the i)
quality of the product) <J
The Product Description should be written as soon as possible after the
need for it is recognised. Writing the description helps the planner
understand what the product is and how long it is likely to take to build it.
The Product Description is also the first place where we start thinking
.'
about the quality of the product, how we will test the presence of its
quality and who we might need in order to test that quality.
:)
It is very sensible to get the customer to write as much of the Product
Description as possible, particularly its purpose and quality criteria. This
(1,).,
I '
helps the customer define what is needed and is useful when delivering a
product to be able to confirm that a product meets its criteria.
The Product Description is an important part of the information handed to
a Team Manager or individual as part of a Work Package.
Any time that a product that has been approved by the Project Board has
to be changed, the Product Description should also be checked to see if it
f?t\
l'~"")J
needs an update.
Quality File
)
The Project Manager should keep a file of all the quality checking
information that is generated by the project. This forms an important
audit trail for use by such bodies as either customer or supplier quality t··)
_ _ ,-,J
assurance.
The quality file should contain the master copy of the Product
Description, plus details of individual product test plans and a Quality
Log. The Project Manager is responsible for setting up the quality file and
Quality Log and checking that either Team Managers or individuals are
feeding information into the log. I ~
~
Quality Log
The Quality Log is a summary of tests planned and carried out and test 'V'
{I~',
results. The initial entry is by the Project Manager when a Stage Plan is
~)
148
0.4
"""
created. The Team Manager or individual adds the actual results as the
quality checking is done.
,~.\\ Links
There is clearly a link to the project organisation. If the customer or
supplier has an independent quality assurance function, how can they
neatly fit into the project organization? The answer is via the Project
Assurance role. Both customer and supplier could appoint someone from
their quality assurance function to carry out part of their Proj ect
c Assurance role. This gives them access to the detailed planning, when
they can ensure that satisfactory testing with the correct participants has
been planned They can get feedback from these participants either
( •.~-I directly or through the Quality Log about the results of quality work.
~ The Project Assurance function can do a valuable job by checking that
the Product Descriptions are correct.
':j,.:'~: Clearly change control has an impact on quality. Ifuncontrol1ed changes
are made this is likely to destroy the quality of the project in terms of
schedule and costs, as well as making it unclear what is being delivered.
This means that there would be no connection between what was
originally requested and what is finally delivered
In the same way configuration management has links to quality. If you do
. ..~;;~~ not keep control over what version of a product you are using, the quality
is likely to suffer.
Do's and Don'ts
~
Do treat the need for quality very seriously. The customer may, over time,
forgive you for delivering late and may forgive you for coming in over
budget. But the customer will never forgive you for delivering a poor
quality product.
Don't miss out on any ofthe quality steps.
( If it's a Large Project
Quality is like carpet underlay. It enhances the feel and life of the
() product, but it is very difficult to put it in afterwards. In a large project,

you can't check everyone's work. Make full use of the Project Assurance
role to check for you. Your job is to define the quality required, plan for
it, monitor people who are checking for it and react quickly if there is a
I
( , I quality problem.
Where you have several teams working for you, ensure that the Project
('I Assurance roles check the quality work intentions in the Team Plans and
get customer people in there, checking that the supplier is delivering good
( I 149
quality. Finding out during acceptance testing that a poor quality solution 'l)
has been delivered is far too late. All too often this leads to litigation and
only the lawyers win there. Remember, the customer doesn't want large
penalty payments. The customer wants a product that will meet the -fJ
requirements.
If it's a Small Project ')
It is very easy to think that quality in a small project will look after itself.
"It's such a small project, we can check the quality when we ' ve finished."
Delivering a quality product from a small project is easy", they will say. ')
"Only an idiot could get it wrong". Well, if you don't go through the
quality steps mentioned above, it could be "welcome to the idiot's club."
)
~.'
).
,~.;.~. :;"
()
(-J<·" 0
1'..,;.:'
, ,~.
I ~
J:P
~~.
"
150 I )
Managing Projects the PRINCE2 Rbk]
edition June
of outcome
l1t'1t'P'r-t<lintv
or Some amount
project is to achieve its Projects
incurs risk. is about moving Tnrur>l,-n
often means the use of new new technology. These can increase
the risks.
Risk can also be defined as:
'the chance of to the adverse consequences of future events.'
It is riot uncommon to hear say "This is a risk "This
statement itself is of limited interest or value. We need far more detaiL
What are the actual risks? What are their causes? What is the
of the risk occurring? How serious would the impact of that occurrence
be? What can be done about it?
There are many methods of risk a
few software packages that will you with a standard set
and 'forms' to come to a view of the risk situation
far more than which method you choose is when
out assessment of risk. Too many projects look at the risk
suuanon at the of a then about it for the rest of
comes up and smacks them on the
In summary I that you:
.. out risk assessment at the start of a project. Make ".~"I
T\......' ...
on what should be done about the risks. Get agreement on whether

to start the project or not
.. Review the risks at the end This includes t:;u:suug
risks that have and new risks caused the next
Plan. Get ru.!t'eement on whether to continue into the next
.. an owner for every risk. Build into the Stage Plan the
moments when the owners should be the risks. Check
on the owners to see that are the job and the
risk status up-to-date.
.. Review every request for for its on Py,,,nl1lO
the creation of a new risk. Build the time and cost
151
\
Managing Projects the PRINCE2 Way Risk

avoidance or reduction, for example, into your recommendation on )

the action to be taken.
• Inspect the risks at the end of the project for any that might affect !~
the product in its operational life. If there are any, make sure that
you notify those charged with looking after the product. (Use the
Follow-On Action Recommendations for this.) ...1)
These points should be enough for you to keep control of the risk
situation. If you have very long stages (which I do not recommend) and
very few requests for change, you may decide to review risks on a
monthly basis. ~
i0
\,
There is one other point of philosophy about risk. When considering

actions, you have to consider the cost of taking action against the cost of
not taking action.
(:)
Overview
The aim of management of risk is to assess a project's exposure to risk ")
(that is, the probability of specific risks occurring and the potential impact
if they did occur), and manage that exposure by taking action to keep
exposure to an acceptable level in a cost-effective way.
Identification and decisions about risks at project level form an important
part of the Business Case. Where suppliers and/or partners are involved, "\'.
for example, it is important to gain a shared view of the risks and how
they will be managed.
Where the project is part of a programme, there must be a common view I'Jr\
~I ?:' :)
of all risks at programme level. A risk or an action to counter a project
risk might have an undesired effect on the programme or another project
in the programme.
Risk tolerance
)
Before deciding what to do about risks, a project must consider the
amount of risk it can tolerate. The view of how much the project is
prepared to put at risk will depend on a number of variables. A project
may be prepared to take comparatively large risks in some areas and none
at all in others, such as risks to company survival, exceeding budgets or
target date, fulfilling health and safety regulations. Another name for risk
tolerance is 'risk appetite'.
~\
Risk tolerance can be related to the four tolerance parameters; risk to
completion within timescale and/or cost, and to achieving product quality
and project scope within the boundaries of the Business Case.
Ij}
152 )
I' ,;j:~·...
( ,. ,
Risk tolerances have to be considered carefully to obtain the optimum
balance of the cost of a risk occurring against the cost of limiting or
preventing that risk. The organisation's overall risk tolerance must also
c' be considered as well as that of the project.
Risk Responsibilities
The management of risk is one of the most important tasks of the Project
Board and the Project_Manager. The Project Manager is responsible for
ensuring that risks are identified, recorded and regularly reviewed. The
,::-.... Project Board has four responsibilities:
1. Notifying the Project Manager of any external risk exposure to
the project
r~!> 2. Making decisions on the Project Manager's recommended
reactions to risk
,'//:. 3. Striking a balance between level of risk and the potential
\1·.~"\
.•.~(
benefits that the project may achieve
4. Notifying corporate or programme management of any risks
1&:.'.' that affect the project's ability to meet corporate or programme
.""+
constraints.
The Project Manager modifies plans to include agreed actions to avoid or
(i) reduce the impact of risks.
Risk analysis requires input from the management of the organisation.
The organisation's management, in tum, is kept informed by the Project
,
Board of the risk status.
Risk Ownership
The person best situated to keep an eye on a risk should be identified as
its 'owner'. The Project Manager will normally suggest the 'owner' and
the Project Board should confirm the decision. Project Board members
c may be appointed 'owners' of risks, particularly risks from sources

external to the project.
The Risk Management process
Risk Analysis
Risk identification
( This step identifies the potential risks (or opportunities) facing the
project. It is important not to judge the likelihood of a risk at this
early time. This is done in a controlled manner in a later step.
( , Attempting to form judgements whilst 'brainstorming' a list of
153
)
potential risks may lead to hurried and incorrect decisions to exclude "
some risks.
Risk Management Risk Analysis
\,.i)
Identify the risks
.:J
Monitor and
Report I~
•
Evaluate
the risks
0
Identify suitable
Plan & Resource responses to
risk
I
•~~ I
J)
Figure Rl the management ofrisk cycle
Once identified, risks are all entered in the Risk Log. This is a
summary document of all risks, their assessment, owners and status.
The Risk Log is a control tool for the Project Manager, providing a
quick reference to the key risks facing the project, what monitoring
activities should be taking place and by whom. Reference to it can
lead to entries in the Project Manager's Daily Log to check on a risk.
~.
154
J
I ,;.~~
"1\4
+
"1)',,,
Evaluation
Risk evaluation is concerned with assessing probability of a risk
occurring and the impact if it does occur.
Impact should ideally be considered under the elements of:

o Time
o Quality
c-..
.:.
o Benefit
o People
For example, a major fire in a building is relatively unlikely to

happen, but would have enormous impact on business continuity.
o Conversely, occasional car breakdowns are fairly likely to happen,

but would not usually have a major impact on the business.
Some risks, such as financial risk, can be evaluated in numerical
~~ terms_ Others, such as adverse publicity, can only be evaluated in
subjective ways. There is a need for some measurement of risks.
This manual uses high, medium and low.
'.;t}
When considering a risk's probability, another aspect is when the
risk might OCCllI. Some risks will be predicted to be further way in
time than others, and so attention can be focussed on the more
@f immediate ones. This prediction is called the risk's proximity. The
proximity of each risk should be included in the Risk Log.
Identify suitable responses to risk
There are five types of action:
Prevention Terminate the risk - by doing things differently and thus
removing the risk. Countermeasures are put in place that
either stop the threat or problem from occurring, or
c
prevent it having any impact on the project or business
Reduction Treat the risk - take action to control it in some way
where the actions either reduce the likelihood of the risk
developing or limit the impact on the project to
(.! acceptable levels
Transference This is a specialist form of risk reduction where the
'_I Acceptance
impact of the risk is passed to a third party via, for
instance, an insurance policy or penalty clause
Tolerate the risk - perhaps because nothing can be done
C-'- j
at a reasonable cost to mitigate it, or the likelihood and
c) 155
(revised edition June 2005) ;)
impact of the risk occwring are at an acceptable level ""'~-,"'"
Contingency These are actions planned and organised to come into !

force as and when the risk occurs rl)
A risk may have appropriate actions in more than one of the above
categories.
, 0'~;~' )
The results of the risk evaluation activities are documented in the

Risk Log. If the project is part of a programme, project risks should
be examined for any impact on the programme (and vice versa).
._}
Where any cross-impact is found, the risk should be added to the
other Risk Log.
~>~
Selection
The selection step involves identifying and evaluating a range of
options for treating risks and preparing and implementing risk
management plans. It is important that the control action put in place
is proportional to the risk. Every control has an associated cost. The
control action must offer better value for money than the risk that it "~
;J.
is controlling.
Possible Possible
action 2 action 3
CosutJme CostJIIme
.-,.
\.J
Figure R2 Risk action selection

:.
There may be several risk acnons.
effects. The choice may be one of these or a combination of
two or more. We then have to consider the of (a) the risk
occ:u.rring (b) the risk action on:
o The and/or Plans
o The business or prognumne
o The Business Case
o Other of the project.
The consideration bas to be done in the ofthe risk tolerances.
made the the lDllllexneIltatlon

and and is likely to include and new or
modified Work
1.
o lOentl1V1I12 me auannrv ana tVDe of resources required to
o
o
o
2. which will and the actual resources
to be used to do the work to carry out the risk counteractions.
These will be shown in and Team Plans.
Note that resources required for the reduction and
transference actions will have to from the project
are actions the is committed to carry
COlltrrlge:llt actions will normally be funded from a
There must be mechanisms in for and on

the actions selected to address risks.
Some of the actions may have only been to monitor the identified
risk for of a in its status. however, may
consist of:
1. that execution of the actions is the
desired effect
157
Managing Projects the PRINCE2 Way Risk "
2. Watching for the early warning signs that a risk is developing ,)
3. Modelling trends, predicting potential risks or opportunities
4. Checking that the overall management of risk is being applied
effectively.
-1
Nonnal\y the risk 'owner' will have the responsibility of monitoring.
If the owner is a Project Board member, the actual task of I)
monitoring may be delegated, but the responsibility stays with the
owner. The Executive, for example, has ultimate responsibility for
monitoring any risks or opportunities facing the Business Case,
particularly any external ones, such as changes in company policy.
The Project Manager has the job of keeping a watching brief over all
risks and checking that the defined actions, including monitoring, I t)
are taking place and are having the desired effect.
Risks owned at team level should be reported in the Checkpoint
Reports. The Project Manager includes some form of report on any
I)
significant risks in the Highlight Report. The End Stage Report also
summarises the risk status. Where a risk or opportunity actually
occurs, a Project Issue should be used to trigger the necessary
actions.
hD
Budgeting for the management of risk ':.T',:,-'
A project needs to allocate the appropriate budget, time and resources to

the management of risk. The cost of carrying out the risk process and the
level of commitment and time, such as contingency plans, risk avoidance
or reduction, needs to be recognised and agreed Whilst budget may be
allocated to actions relating to risk treatment, there is often a failure to
provide sufficient budget to the earlier parts of the process, such as risk
assessment that can require a diverse range of skills, tools and techniques. C)
Experience has shown that allocating enough budget to the risk process
early on will pay dividends later. f)·
\.
Mapping the risk management process to the
PRINCE2 processes
At key points in a project, management of risk should be carried out.
o
158 C)
(
I) ,
,\ ,.~
..,'r,
Project Mandate
Project Brief
Project Approadl
Au1horising
Initiation
<.
Project Plan
PID
,)'m¥:,
'
... '
(j Figure R3: Riskflow, showing key points in a project when managerr;ent is necessary
Preparing a Project Brief (focusing on business risks) (SU4)

() The Risk Log needs to be created by this time. The Project Mandate may
have referred to a number of risks facing the potential project. These may
be such risks as competitor action, impending or mooted legislation,
company policy changes, staff reorganisation or cash-flow problems.
Certainly, the preparation of the Project Brief should give rise to an early
study of such risks. Creation of the Project Approach may also have
c' introduced some extra risks.
159
'}
Authorising Initiation (DP1)
')
This is the first formal moment when the Project Board can examine the
Risk Log as part of deciding whether project initiation can be justified.
Pragmatically, the Project_Manager should have discussed informally
with board members any known risks that seem to threaten the project
viability. ~J
Refining the Business Case and Risks (focusing on both
business and project risks) (IP3)
The Project Manager examines risks again as part ofprepariog the Project
Initiation Document. At this time the Project Plan will have been created,
)
and this may identify a number of project risks, such as lack of resources,
contractor ability and any assumptions being made in the plan. New risks , IW
~
.:
may also come to light as a result of adding detail to the Project Brief. At
the same time all existing risks are reviewed for any new information or
change in their circumstances.
Authorising a Project (DP2)
J
The Project Board now has an updated Risk Log to examine as part of its "
decision on whether to go ahead with the project. As a result of refining

the Business Case, a number of extra risks may have been identified.
Very often the 'owners' of these risks will be members of the Project
"
Board, and they should confirm their ownership and the actions required
of them.
Planning (PL) .~,:~~J:~ ~
Each time a plan is produced, elements of the plan may identify new
risks, modify existing ones or eliminate others. No plan should be put
forward for approval before its risk content has been analysed. This
analysis may lead to the plan being modified in order to take the G1 '"-"
appropriate risk action(s). The Risk Log should be updated with all such
details.
Updating the Risk Log (584)
(~)
As part of his preparation for a new stage, the Project Manager updates
the Risk Log with any changes to existing risks.
Authorising a Stage or Exception Plan (DP3)
Before authorising a plan, the Project Board has the opportunity to study
~~
the risk situation as part of its judgement of the continuing viability of the
project.
I-ID
160 ,r,V)
1
(
A•.
Authorising Work Package (CS1)
Negotiation with the Team_Manager or team member may identify new
risks or change old ones. It may require the Project Manager to go back
·t.
and amend some part of the original Work Package or change the Stage
Plan. Examples here are the assignee seeking more time or needing to
change resources.
Accepting a Work Package (MP1)
This is the point when the Team Manager makes out a Team Plan to
( J ensure that the products of the Work Package can be delivered within the
constraints of the agreed Work Package. Like any other plan, it may
contain new risks or modify existing ·ones.
Examining Project Issues (CS4)
Assessment of a new Project Issue may throw up a risk situation. This
oj";'" may stem from either the technical impact analysis or the business impact
analysis. For example, the proposed change may produce a risk of
pushing the stage or project beyond its tolerance margins.
Reviewing Stage Status (CS5)
This brings together the Stage Plan with its latest actual figures, the
Project Plan, the Business Case, open Project Issues, the tolerance status
and the Risk Log. The Project_Manager in conjunction with the Project
Assurance roles looks for risk situation changes as well as any other
warning signs.
The Project Manager's Daily Log can be very useful in monitoring risks .
Entries can be made in it for the Project Manager to check on the status of
any risks where he/she is the owner. Other entries can be made to remind
the Project Manager to check that other owners are monitoring their risks
and feeding the information back.
Escalating Project Issues (CS8)
() As well as Project Issues, a risk change may cause the Project Manager to
raise an Exception Report to the Project Board.
lL) Reporting Highlights (CS6)

As part ofthis task, the Project Manager may take the opportunity to raise
any risk matters with the Project Board. Examples here would be
G) notifying the board of any risks that are no longer relevant, warning about
new risks, and reminders about business risks that board members should
be keeping an eye on. The suggested format of a Highlight Report is
included in Appendix A Product Description outlines.
(r l
161
IVli:111~;mgProjects the PRINCE2 Way Risk
IVI<IJ.Il1)!,CI advises the Project Board situations via

The board has the opoortunitv to react with advice
the
or the The Project
mSl:tgate ad hoc advice on the basis of information to it
r..... rnnr·AtE' or programme or another external source.
Follow-on Actions (CP2)
At the end of the project a number ofrisks may have been identified that
will affect the product in its life. These should be transferred
to the Follow-on for the information of those
who will support the
It should be that it may be desirable to
order to obtain additional benefits to the
no action may sometimes be apJ)rOlpmlte.
made that the level
How a risk can be on the identification of
its causes and the amount of control that the
mana~~emlent team can exert over those causes. It is more effective to
pOlten't1a.1 cause of a risk than to wait for that risk to materialise
and then its impact.
of a risk that materialises should not be mistaken for the
nPT,'VlTl;('cause of the risk. For cost escalation on a is
ev<::r-tJlres:ent risk should be monitored to
costs are ""'~.<11<I.I.J.ll,!';.
It is that the ofrisk is considered as a continuous
thr~()UjlnOll1t the life of a Once risks have been
need to be monitored until such time as either cease
.u=,,,UaJ or their effect has been reduced or mitigated as a result of
I.lIl;Iw,,":gelneIu intervention. The for new risks introduced

or in consequence of actions also needs to be considered
Ull'"Up;UV,,"' the life cycle.
Illustrative Risk Analysis Questions
This section contains an illustrative list
...o.oLUa,5"'. may require to have answered for a P<'l.1I.1I¥Wru
based on the OGC
162
Managing the
fit into the overall business
2. When is the due to deliver: how was the date determined?

3. What would be the result oflate aellvery
4. What would be the result oflimited success
5. What is the of the business area?
External 'f=a...·tn'·Q
exposed to requirements due to international interests?
implicaltiollS from overseas, or are
2. Could there be of the

what constraints are set for
Procurement
1. Has the a reputation for goods?
2. Is the contract detailed to show what the supplier is
to
(CC)DS1.Cler3t1<)u should be
isational factors
1. What consideration needs to be ""'''''IDty for this nrni"'M"
2. Does the have wholehearted from senior management'!
3. What is the commitment of the user man~~elllent'!
4. Have training requirements been identified? Can these requirements
be met?
are the ...... "~~'"'''4~ defined?

be ron a well-documented to
3. Does this approach cover IillUl.ugC;;Illc;;m, Risk and

in sufficient
163
Risk
team understand the chosen illt:UlUUUlOlI!Y

5. What is the CUlTent state of Project Plans?
6. Is of this on the of other
7. Are the tasks in the can the critical

th.rlrmll~ tasks be luo:::mUi\;;UI
",VCu.la'UlllLY " . "~'nr'''T''I1'i "tp

resources? are the skills
eXi)eti.em:e team? What is the make-uo of the
9. Will be available for IS this includes the

team, users and operations
10.How many user functions are involved?
will there be to the users' or
Technical
1. Is the accurate and feasible?
2. How have the technical
3. What is the of the IT, for this is
the hardware/software emrir\JIIllIJlen1t.)
4. Does the cover a similar
5. Is this a new i:lppilCi:lLLUil

6. What is the of the ~ ..~.__.'J
7. How many sites will the system be imDlemented in?
8. Is the "'..n",,,~,,,A
9. Who is for U\;;illWi~

1O.Who is resDorlsible
12.What access will the facilities?

13.wm the user or ~IJC:"'li11IlSL
14.Have for maintenance and
been identified'
164
PrOiects the PRINCE2 Risk
links
There are many links to the PRINCE2 processes, as described under the
'He'VIJ"'''' the risk process to the PRINCE2
n,.f',"""'c.>c • In addition we can consider the following links:
""-LLUllLY llaUL''''ll':>, t:l:'8Dl!fel:riDlg the risk to a Project Issue
the necessary action. The reason is There is

eu··ae!Jlle:aaction process to handle in the
control create another one for risks? The Risk
Log is marked with a cross-reference to the Project Issue. The
Issue is cross-referenced to the risk in the Risk Then on
we go with and the various in change
control.
If a risk status becomes worse, the may be able to

take corrective action within the tolerance limits,
Do's and Don'ts
Do examine every for risks before it.
Do an owner for every risk:.
Do try to as of these as When
Daily for actions to next do look at the Risk
should be reporting on the status of risks.
Don't to wam the Board risk deterioration that
go beyond the tolerance mrurgirLS.
Don't be about a member of the Board as owner of
a risk.
If it's a Project
Vll'a..lU"'lW~'ll.:> now a Risk IVJAl.Ii:l.l;;!;;!
"Vl1.:>u-naJ~L who advises all and
vVJ..... ,J1UUl:. risks.
165
thePRINCE2 Risk
It is sensible to set aside some time to consider the risk

situation. lbis will be a natural of each but in a
it is also worth this time say, every two weeks.
If it's a Small g .., ... ,o,..,
Risks are still an important factor.
166
Change Control
edition JWle
Change Control
No matter how well a project has if there is no control over

",",,;!.ill!:;"", this will any chance the in on
schedule and to In any project there will be changes for many
reasons:
.. Government and this must be reflected in
the procluct
.. The users their mind on what is wanted:
.. Because the the user think more and
more about the themselves for
.. There is a merge
company merger or take-over
.. The suvolier finds that it will be to deliver ;.>vl'TVthina

agreed schedule or cost;
.. The cannot meet an acceptance rritPrinn such as
.. A product delivered by an outside contractor or another

fails to meet its SJX~c111ca,tJ.o:n.
All of these need a to control them and their effect on the
project, This must make sure they are not but that
nothing is the level is
unaware. Board.
A Issue is the formal way into a

or the of a Quality Review Question
be with the project about tlnvthina
example:
.. a desired new or ..a.L4I.l!:,"'..... .LW.L""Wll,
.. a failure of a in me1etnllg
In such cases the
i,.".rnp.nts.
of the failure where sufficient material
to allow someone to recreate the
167
Control
• a with a
• a failure of communication.
In other words, there is no limit to the content of a Issue beyond
the fact that it should be about the
normauy goes on a Action
• where an error is found

different product than the one under
Review
Issue as the way them into
~.~,,,,,,,,..,,,,,,,to close the issue

is concerned and transfer it to a de])artrmmtil
if the is of a programme
and an error is found in a Review t hat affects other projects in the
programme.
All possible control
qU~lSnC)ns or
Detail
We shall consider three Issue:
• KequeSl:S For "-'llWl~v;
•
• 4Ut'lSLllJillS or sugg~j:iolns.
Control t"rc)ceaulre
now classed as
168
UJ."LI.J.A!;J.lll'; Proiects the PRINCE2 Change Control
The allocates the issue to the person or team best suited

to examine it. The issues are evaluated with the aim
recommendations to the on their resolution. The
outcome is normally one of the following:
--------------------------------~
" The issue has been raised because of a the

The misunderstandinc: should be exolained to the
originator and the issue
" The issue is a to a baselined item.
The Issue is a Request For and the decision can
be made the Project Board Authority if one has
been - See
" The issue "''''''''"''''~''
" A does not meet its specification. The Project Issue is an
" The issue be deferred to a later enhancement ",,."'pM·

" The issue was received too recently for any evaluation.
169
l.Vli:lU.~~lli~ the PRINCE2 Change Control
"A.<..uo""", should review all open issues. He or she may do this

a senior technical member of the team and! or with those
Assurance The of such
U.<OIJ"lJlU on the but it
Vo'~-'J and with sufficient freQuency to ensure that no
inordinate action.
All Issues have to be closed the end of the or
transferred to the Follow-On Action Recommendations. The transfer of a
Issue to these recommendations can only be done with the
of the Board.
"U"4U'g~L for
,.".m"o:t for modification to the user
The
_..... .c.:_~_ ..! __
Iw1l<wgc. This is because

of those items. The
vVLllP!"'L\'JL!
approve any to such items.

The identified work is costed and the Plan's
and schedule assessed For the next the
want to know of the work could be done within the tolerance levels
of the current For this reason it is best that a batch are
studied, to a wider view of the effect on the
In for the next the For have to be
awarded a Priority This can be one of four:
•
• medium
• low
• cosmetic
It should be of the users to provide the ....... "'·..1'"
imlDle:mented, it must be
Proiect Board. Whose
decision it is d~len(is
170
Change Control
.. If it is not a to a item that has

baselined and the work can be done within the current
tnl,p"!IID""MI the can make the decision to
can be to the Project Board
'-'''''......)';" Autnonlty if one has been ~ See SU2) for its
eXJ)erilen(;e shows that there will be a lot of
the It IS a idea to make the Project
Board decide on any other than trivialities. This keeps the
Board aware of how many are and their
cumulative on the and cost. Plan runs
into trouble it is usually too late for the
any about a claim that lots
actioned without for more or answer will
be didn't you ask us? We could have cancelled or
delayed some of them."
" The decision must be made the Project Board
AlJltn()nty if one has been ~ See if the is to
one or more items that the Board has
been told are (to any not the final
one). More than this is to retain the confidence level of
the Board. If it has been told that is finished and later
finds out that it has been its sense of
in control eVllPorat(~s
" If the work to do the
must submit an Exce~)ti(J,n

showing the new schedule and cost
Ifthe Project Board retains the
that have not been the Project Manager are passed to
Board.
The Board's decision may be to:
.. the ...~~~.....
then this means the J.jA\Ai~'L1V'll
.. aelay the to an enhancement after the current one is
.. defer a decision until a later lllo;;o;;W1!;;,

.. ask for more UllVHU""",,/l.l,
171
Managing Projects the PRlNCE2 Way Change Control
• cancel the request. ....
If the Project Board has delegated the responsibility for decision on
Project Issues to a Change Authority, then the Change Authority will play
the role described above. The decision should be documented on the
Project Issue and in the Issue Log.
Whenever its status changes, a copy of the updated Project Issue should "
.~~
be sent to the originator.
The Project Manager is responsible for scheduling any approved changes.
This work will possibly involve the issue of a new version of one or more
products by the Configuration Librarian.
On receipt of a completed Request For Change the Configuration
Librarian should ensure that any amended products have been re
submitted to the configuration library. The finalised request should be
stored in the quality file, and the originator advised.
Off-Specification
An Off-Specification is used to document any situation where the product
,;1 tl'
is failing to meet its specification in some respect.
The Configuration Librarian allocates the next unique Project Issue
identifier from the Issue Log and sends a copy of the issue to its author.
"'.;,
Senior team members carry out an impact analysis with the help of the
Configuration Librarian to discover which products are affected by the
Off-Specification, and then assess the effort needed.
As with Requests For Change, the decision on action is taken by either
the Project Manager or Project Board (or a Change Authority appointed
by the Project Board). If the error is because of a failure within the
Project Manager's responsibility, the onus is on the Project Manager to
correct the problem within tolerances. Similarly, if the error is from a
Team Manager's failure to fulfil an agreed Work Package, the onus is on
the Team Manager (or the supplier if the team is from an external '"
t,~
company) to correct the error without asking the Project Manager for
more time or money.
• If the Off-Specification does not involve a change to a
configuration item that has already been base lined and the work
can be done within the current plan's tolerances, the Project
Manager should make the decision to implement it.
• If the Off-Specification requires changes to one or more
configuration items which the Project Board has already been told
172
n~""-""l:;<llo Prr.iPl'tc! the PRINCE2 Way Change Control
(....,.,";"....1 edition June
any not the final one). the
Board must make the decision.
• If the work to do the _
tolerance levels ofthe current the decision on action
must come from the The Project win write
an Report and send it to the Project the Off-
i~:;lUCatl!On, "hn'W1"'" the new schedule and cost for the rest of
The Board's decision may be to:

• correct the fault. If the work a Plan. then this
means thenxc~)tiCln
• delay correction ofthe fault to an enhancement after the

current one is u.u.,.:>u'.......
• defer a decision until a later mt::t::ung;
.. ask for more information.
The decision should be documented on the and the
Issue Log, and an filed. a
copy of the
The Proiect Manae:er is resoonsible for any work to
_ involve the issue of a
new version of one or more products Librarian.
On of a corrected the Librarian
should ensure that any amended have been re-submitted to the
The Issue Log should be updated with the final
and the advised.
The Quality File
It is the reSJPonslb:lllt)l
Project If a Librarian has to the
YI"I"".,.rt<lnt that the duties with reflard to the
....".............. between this role and the _

Colltil5W"aticm Librarian will be allocated the duties and
all the documents.
The file contains the and the forms that are produced
of the quality controls applied during the life of the project. It is an
of the audit trail that can be followed the user or an
assurance body to assess what has
173
IVliWi:1gWg the PRlNCE2
edition June
been carried out and how effective it has been. As it is a deliverable
Wherever the of documents filed in the

file. A copy can be filed if the has to be circulated for
or comments, but on its return the original should be in
file.
The aualitv file should have sections for:
" I lIullltv
Each check should have a

basis statistics on how many
out.
Review Invitations
"
this document there should be a check that there is no
uru-eD()rt~rl date to the review date. If
be notified.
• Review Results
When all corrective actions on the Action List have been taken and
the list the chairman of the it is filed in the
file. If the review was terminated
documents such as follow up Action annotated prclduct
Ouestion Lists should all be filed here in the crualitv file.
" Issue
Links
link between control and COIllt1g1LJIa110n
new version ofa should have a link to the
Issue that caused the creation of the new version. It is sensible to
the same person or group for control and
There is another link with and the

process. Before the there should be a deClSlon on
the control is to be and what of the
Wj111i:1~~\;;n:l\;;I1l team will administer control. Will it be a member of
the team, time? Will an administrative clerk come in for half a day a
week? Does it need a small group Librarians?
174
Managing Projects the PRlNCE2 Way Cbange Control
Another link is between Starting up a Project, the organisation, plans and
change control. At the outset of a project a decision is needed on whether
a change authority is needed and how changes will be funded.
Do's and Don'ts
Do think about the stability ofthe customer's specification before you
dive in to a project. The less stable it is, the more change control will be
required and the higher the cost of authorised changes is likely to be .
.Don't underestimate the importance of change control. There is no project
control without it.
'~, There may be many changes, so many that the Project Board cannot find
the time to consider them all. They can choose to appoint a change
authority, a group of people representing the Project Board, particularly
the user side. The change authority will meet at a frequency based on the
volume of changes coming through. In order for the change authority to
operate, the Project Board will allocate it a change budget and provide
~~,,\: certain restrictions. These may be the maximum amount of the budget to
be spent in one stage and the maximum amount of the budget that can be
spent on one change.
Change control will still be important.
.......
175
Jargon Abbreviations
,-,onngurauon carries with it a certain amount and
more than its share The should common
terms and initials that win be used in the text.
This is the set of all that form of the fmal Because

of the effort needed to record and track all the " ..."rlll"1-,,
refers to all from the
!iiVSrerrlS the be broken down to level
manuals and test data.
{,;OIDfil~ur;ati(1D Item
A Droduct that the wants to track
Configuration Ubrarian
This is a person to the 1.AJ11111'~W~1LHJIU
management activities.
Baseline
A a status that is recorded. different versions
may be created later. the baseline remains unchanged and
can be retrieved at any time.
No can be efficient or effective unless it manages its

if the assets are vital to the of the
assets likewise have to be manag;ed.
that it The name for
assets is a of
is the sum total of its oroducts.
Within the context
In the foreword to its Product

Somllare wrote "If the product you has more than
more than a few or more than one person
Configurati()D Nfanagerrlent. The
176
IVJjj..u~~llij!,Projects the PRINCE2 Way COIBfi~rorlltio.n Management
edition June 2005)
The is to achieve a controlled and

traceable evolution authorised spl~ci1fic!ltie,ns.
development and
This is met and
• The issue and control ofproperly authorised spe:cl1ilcatlons;
• The issue and control authorised UVI.;UllJCll~,
authorised to the
SP(!CI1QQiUe'n or
• The control of the various versions of a product and their
relationship with its current state.
Co.ntlguratlon J..LIJO.u.<1~C!llCJ'" is also the process
An u-u',I-'U,,,,,,"WlVll
is that any
.LU.<I.ll"'J!,>"'LU<;iL" of the and any revision
COInp()nents that make up that version of the can be retrieved at
any and that the will be built in an
identiQU manner. Product and variants create the
need to control versions and releases of the All these
have to be handled by COIlll1gJllratlon llI.<LJl14j!,CllI.,;;.ul.
discipline which:
• Records what or are reauired in order to
build a product;
• Provides identifiers and version numbers to all products
• Controls access and to of a product once
have been declared complete the developer:
• Provides information on the
• information on the links between the various of a
pro'Qm:t, e.g. what coIlllpOneIJLts CClmpnse
X
• Provides information on the status
who is for the
• Is the sensible storage place for Product

• Gives project the assurance that are
in the correct sequence.
177
the information to construct a release either
a one or a one, and then records the issue of a release.
items are valuable assets in themselves. Co'ntIguratlon
nlalllagernelCit know what its assets are to
saltekee)Jing and whether the actual ;n",,,"1
such as
-h-,p,nl1 i3'Mth, f"'hp,"!,,~""'U in
"''''''''duct is to be used in more than one
or~:anlsala01lS to control the distribuuull
these sites. Where there is any volume
be the need to decide between nutting a 'release pru~1\a:ge'
prOIQu(:t. The
more controlled and cost-efiectIve means
pOO4iuct than sem1mg
control mechanisms
,-,v.u."'5u.,a1J'VU llUlw,o,,5"!1l"J"" SlllPt)Orts the maintenance of information on
proven reliable releases to users can revert in case
The data held in the to recreate a release after
any disaster and their
Because all are under the control
once thev have been develoned. it makes it more for them to be
Detail
I...-onngurauon managenClem covers all the technical
It can also be used to record and store J..LlLIu.J.a,5"".LJ.""e... n'l"c\{illl"'Jt~
details and arn'll'Cl1l!a
management are on a number of factors
such as:
.. Effort involved:
.. Resource
. LapaOllitY of any other current method for U""~ULIll!5 manalg;ernerlt
178
M~magu:Jlg "',"'F'C'T" the Configuration Management
•
COlm!~ati()ll .u.w.u.'~5'"'1.U"'u, software.
Costs
There are the costs
Librarims, If a central office (say
been set up to
pflJjelcts, there may be a need for a manager.
If software is to be used to record and track the data, there will be the cost
of its any hardware bought to run it, the staff
difficult to the conilpr,ehensl'ile
records database and
software. costs here are far the increase in
and detail of information. The increase in of reaction
cO:n1l1~atl()ll Librarian reduces the number
needed to cover all the site's nrr,(1HM"
The need to go the management tasks may slow
down the hand-over of a finished item or the lID]pleme:nta~tion
is very small when we:jg:i:led
the latest a
...r",rlnM or that is from an incorrect or has not been
che:cke:<1 out. Without it there is also the risk: of more than one person
"''-''''''6'Lll6 a in all but the final
lost.
Possible nrnhlAm~
products are defmed at too Iowa the co:nnl~auc)ll

be overwhelmed the amount of data to be
______.; a where no management
used.
If products are defmed at too a the information for
may be too vague and result in a than necessary prc,du,ct
lllUl\idILCu,. e,g. a whole set when
one product is affected.
Procedures must cater for emergency where an emler~~e!Jlcy
•__,~' __ in order to let the product cOIltinue.
Where is new, de~vellopInelnt
terrlpted to view its controls as bottlenecks and <JUl,"''''''''!
been used in for many years and is rel!:ar(1ed
as essential. It is also regarded as an essential
179
]
for
lVV.l.'U-UC; under such standards as ISO
re~:ar(1ed
as essential because of the control it and
eXl)eniem:e over many years, which has shown its value and the cost of
when it is not used.
Management Plan
be on and issued. Part of this plan must

"U".......5.~'" win be controlled and implemented.
The Plan is of the
the
sections:
• Purpose of I...,.onngur
There should be a of what
and its purpose in the
• Role Librarian
The first element is to allocate the role of librarian. The ideal is one
individual to do but where resources are or the
is it can be combined with another role. Another pOSSU:llllly
that one person may the role for more than one
time.
• Tools to be Used
is to what tools or card or
son:WaJre P"Iv",,,c;'r;;;} will be used. This most of the
decisions on of the such as method will be
used and to what level the will be recorded. The normal
decision for the latter is to record down to the level
.... ~'L_v<W••" n:roducts. Other important
much resource effort is

software is available.
•
will include definition of the scope
What
iYl.<IJ.J.(1,I;;CtUo;;11t. will be covered? Are
LU<l.U~;",w,r;;;li' prcldu,cts, such as to be included? Will all
l:ecnm,cat I.nv',-,u... ", be included or only the key deliverables?
• Product Atitntlut\;)S
180
lVlanagmg the PRINCE2 Way
Which attributes are to be recorded?

• Identification Scheme
prc~UICts, l.l.lyU............. EO how version
• Product Submission Procedure

nr"tlnM" are to be submitted to the Ilnr"TI>ITI
UU'''ll''u" moved back to

1.IJ.U'uu...""
• Product Issue Procedure

What and form will be used to request the issue of a
prc)dUlct held the Librarian? What details will be
of issue be identified? What
will be done to recover copies they are obsolete?
• Baselines
When baselines will be taken and for what reasons.
Identification Conventions
In order to track of each a clear identification scheme must
be Each must be identified in a manner that is
The identifier should consist of:
• nmied identifier
• nmrlnN identifier
• version number
Version Numbers
The first version of a comes under cOlm~~atl()n u.u.&.Uu!S"a.u,vd....
control when it is submitted to the librarian as
review. It usually this version number as it moves t1:moullch
verification and checks and becomes declared '"",,·n1'r1.vp,cl'
Whenever the is later LUV ...... "',."..,
This must have the same name \.lU'",.nU'''·l}

a new version reference. So a new version
For orurr-~·p~:1n.canlon
it or any product of which it consists.
time the the version number is incremented. This
simple should be used whenever I-'",.","L-...."
181
Managing Projects the PRlNCE2 Way Configuration Management
[ (revised edition June 2005)
------------------------~
It is best to stick with the simple chain of sequential versions. This

strategy has simple rules:
• there is only one 'latest version'
• modifications may be applied only to the 'latest version'.
Physical labels
Every configuration item needs to be physically labelled in some way to
proclaim its identity. For documents, the label is usually just the name
and version number written in the header. For a physical component it
may be an identification tag or an identifier etched into it during
manufacture.
• All hardware must have physical labels with the product name,
number, model, version and copy/serial number
• cables should be tagged at both ends with a label
• software modules should carry the product name, number, copy
number, version number at the head of the file.
• approved documentation should have a coloured label. It should
contain product name and number, copy number, version number
and its shelf-life.
Configuration Item Attributes
The detail to be kept about the products will depend to some extent on the
complexity of the end product, the number of products, the resources
available to keep the records and the information demanded by the
maintenance and support groups. Below is a list of potential information
about a product that should be considered against the needs of the project.
Part Number - a unique configuration identifier allocated by either the
configuration management software or the librarian. This consists of the
first four fields described below.
Project -- a mnemonic that identified the project

Product Type - an indicator or name that classifies the type of product,
e.g. M=Management, S=Specialist
Product Title - the name of the product
Current version - number of this particular version of the product. This
is usually linked to a baseline. You may wish to divide this into version
and sub version number, if you want to use, for example, '3.1'.
182
nJ."~il11!;; "Tn"""~~ the PRINCE2
Variation - sometimes there is a variation of a e.g.
lanlgulilge variation of the instructions. If there are
this field would also be identifier.
des.cnl,tton. This would be a link to the full
PRINCE2.
'Owner' of the prCluuct
Allocated to - Person on the product
Date Allocated - date on which work on the was allocated to
someone.
or Location - where the is
Source from where the is obtained
Parent - If a has several components,
and the 'children'. A 'child' can have Only one
ensures that when you build a bill a common component is
listed once.
Children - This shows links to any 'children', other sut)-C()mpOIlen.ts
which form part of it. and where this product is the one
Used in from the , this identifies any other item of which it
forms a
Status current status of the configuration item
Product in progress
Draft version available
Product under review
Product "...nr""",rl
Product urithrlr<lurn
Product "'.... I->"'l"",'"'U.'u
Other data that should be held under the 'status' are:
• start date of the current status
• nmiP.ct in which it will be ,-1",,,,,,11"\1"1...-1
• officer
- details of those who hold a I}lUUUlil." reason
for the copy and any date when the copy returned.
"-'Ill....,'!!.'" - Cross-references to Issues that affect it.
183
lVlani:l./5rng the PRINCE2
COlrrj~spOD:dellCe - cross-reference to any relevant documentation about
Baselines
A baseline is the moment when the nrc,l'l"",t
after a successful Review.
'freezes' the content. It can now be used as a finn basis for the
later If the item itselfis to be at a
the baselined version remains a copy is issued with
the next version number and all the the reasons for the are
recorded in the cOl1fi~!;J.lr.atl(m
and has been it is into the and a new
baseline established. The old baselined version is never discarded. The
l..ULIW.a..l'>l;'tlll;"L1L method must the recreation of
any baselined version of the protCIw:;t.
Project
A baseline is a and coru;istent set
records that fann a fixed reference in the end 1l1\J'UU''-,
de1{el!Jprnerlt. The most obvious baseline is to be
over at the end of the It is normal to establish
intermediate baselines to
later at natural UH;;i:lAl"V1'-'","
Products as a
tlm[lU~:n its life later on, in life of the
A will need to know the aru;wer to many qUestloru;.
as:
" What is the latest level sm~ijt'ic,lti(m to which we are
" What exact are we lIn]plementllllgl

" What did we release to site X last Ji2JJ.U4.L'y
A baseline is created for one of a number of reasoru;:
" To nrovide a sound base for futll1re
" As a to which you can retreat if goes wrong;
" As an indication of the and numbers of a
" As a bill of material the variants released to a
184
g the PRINCE2 Way
edition June 2005)
paJuu...."" and documentation at the current baseline to
represent a standard configuration Product De:SCll0tion

which supplies can be obtained nllrch.R!':e ofners;ona
computers for a
• To indicate the state the oroduct must reach before it can be
released or lInarnnl"i!·
• As a of one baseline another in terms of the
nrMni'tQ contained and their
configuration items to another
VCmpll1Cnt to production, from the "... Ift".....'
the end of the project;
• To obtain a on what of the baseline are not of
status 'X'.
The baseline record itself should be a so that it can be controlled
in the same way as other products. It is a baseline .U".ll.. . U".
and list of all the products and their version numbers that
baseline. Because of its different format it is often held in a seoarate file.
Status Accounting and Auditing
Product status accounting provides a statement of the current
status and history of the products within the
Configuration checks whether the recorded rI"""l':Mlnt;('m
nroducts matches their and whether items
been built to their "p",,,,u,,,,,,.vu.
Product Status Accounting
The pUIpOSe of this is to a on:
• The status of one or more cOIlfi~p.rr:atl(m
• All the events which have imnacted those I.JlUUU'-'~.
This allows """tnn"ri with the and orovides fT<Ic·I,;ncr
to products.
In order to this information it is necessary for the Wll.lll;;w,mVll
management method to record all the transactions each
configuration item. At the level this means that we can tell the
status of each item and version. If we can afford to
records, our will have broken the down into parts,
which are linked to desi!!l1 items. which in turn link to constructed
185
conlpollenl:s. All "nnrnv,·r! cbLanges
l1.ll.r""~"::O and dates the baselines mC:Ort)or:atillg
"ll'1ll,,;<;;::O. Our records win show who was and the
costs.
For the pW:P013e
method as:
.. What is the of develooment of a oarticular item?
.. How many For were approved last month?
.. Who is for this item?
.. What items in the baseline have been since it was
.. On what items have been but not
.....r"'9'i ...... Auditing

There are two purposes
that the records match
COlm!~an()D records show that we are
I want to be sure that the has not
without my and without any documentation to say
ver:sions 4 and 5 have been created. The second nln"'l"lf\'~"
any differences between a delivered and its VHi!5ll1'''''
SP~:Cl!lca.tto:n, In other words, can the COlm~~lOOln
oroduct
.. All authorised versions con:fiwl1'ation items
. connguranon items
.. All records and release records have been ,..,.,.,.,..",..1"
authorised
• are as authorised
This is defined as an of the recorded item
and the current of that item to ensure that the
latter matches its current The also checks that the
"1."""Wl"""J.Vli of each item is consistent with that of its parent in the
structure. In a sense, it can be as similar to stock control. Does
the book descriotion match what we have on the shelf? In addition
ensure that is and that
met.
186
COII!.fil:~llti(1'n Management
establisrumeiots, the aim of is to

"'ll<I.J..l!;'"' that may have taken
conform to the latest
prc'Ce(lun~s have been pelioIme:d ..,.~"'~,.""'."'.
bW'lellltleS that the item at each baseline
I<mer.ifir.~tinn for it in the nrevious baseline
"""'Tn"",'; does this.
conllguratlon audits should be done:
• i.rIqJlelneIltation of a new COIllIlgllJl'a110n manag;em.ent
• Before and after CIl!Wg~:s to the structure of the nrCl;I'r.t·~
• After disasters such as the loss

• On detection 'rash' of unauthorised COll11~~,atl()O
• Randomly.
Here is an eXanlple checklist for an audit. The items

should be eXanlined:
• Do the configuration records match the items?
• Are (randomly tested) ~nT"'Cl'''l'n
Are they linked to "nM,,....,,,ri
implementation controlled by the "'"".'-Uf,"""''''''''
method?
• Does the reflect the inclusion of
any random products? Are there links to relevant Issues?
• Are configuration audits carried out? Are the results
recorded? Have follow actions been peliol:1IUlll'l
• Are (randomly tested) archived and versions
retained and recorded in the correct 1"I'1","n,,,.,..,
• Are the recorded versions used in locations
correct?
• Do DanleS and version numbers meet lliUllllll;l
conventions?
• Is library housekeeping carried out in accordance
...."",ll.l,..... procedures?
187
Managing Projects the PRINCE2 Way Configuration Management
• Are staff adequately trained? .x:;
• Can baselines be easily and accurately created, re-created and .~
used?
Product Submission and Issue Procedures
It is essential to control the input of products to the library and extraction
of them from it. ~
Product Submission
Authors of new or revised products should complete a product
submission request form to the Configuration Librarian when they are
satisfied that the product is complete and ready for review. The request ~
form should contain at least: ".
• date of submission
• product identifier
• title
• version number (and sub-version number if applicable) •.no ,. ,
• status (this might default to 'draft version available)

• author ~, . ,
If the product is a document, the librarian files it in a folder in the

technical file. If the product is in machine-readable form, the librarian
should be provided with software procedures to transfer the product to an ',,.,.::
electronic library that can only be accessed by the librarian. Such
procedures should remove the original from its development location
(after validation of the transfer) to avoid unauthorised changes.
Product Issue
There are several reasons why products require to be issued once they
have been lodged with the librarian. While in draft form, copies of them ~
will be sent to the Reviewers. Once they are approved, staff may need \.I
them to work on a later product, they may be the subject of an approved
Project Issue or they may be released as part of a baseline.
Basically the same issue rules apply to both human- and machine
readable products.
~
Master copies ofproducts should never be issued, but held in the
configuration libraries.
The Configuration Librarian is responsible for maintaining a product
':"~
issue record of:
-::
188
• title
• version number
•
• date of issue
• reason for the issue
• nthnritv for the issue
lnn~n"'r"nt to ensure that or obsolete copies are not
,ul",f"\"tPrltlv used to create either the next version or a
later in the life (For document
to write a It is necessary to be able to
""""F,LJJ."''' what is an authorised copy.
Authorised should be stamped in colour. The lack of colour will
indicate an unauthorised The should carry a date, where
I-/V"i)L,,",,_ after which it not be as a copy of the current master
without with the librarian.
Where a copy has been taken for a review or
any other short-term the librarian should to follow up and
recover unwanted for the reason in the
When a new version is the librarian has the

holders of the old version. the old should be
recalled and It should not be taken for that a copy of
the new version should be sent out to all holders. Their reason for llVJ.u..uJ'l'>
should be examined to see if it is or thev should be
The should ensure that no is on issue for
a
At the end of a is released
into production. For many installations this may be a simple matter. The
product will run in the same environment used for its
and 'release' is more than the
But there can be many concerned with the move of
."LVl-I'J.."'JU< work over to live opleratlOln:
189
HkU.uue,"'-''& Proiects the PRINCE2
edition June
• How do we release details of how to build the to a sister
company on another site?
• How do we ensure that we release Droducts that have been
tested as of the whole
• How do we create innumerable of the a
software house or electrical manufacturer) and
~w:u.a.LtL"'" that they will be identical?
• How can we oroduct without the risk of it
• How can we a check on which of our customers or sites has

what version of the _~~A,,~.')
• How do we install a enhancement of a nroduct?
velonen the "1"I'\.4nr-1
who do
cornpl.ere prc,du1ct for every
• Do we issue a new manual or the cnangeC1
The answer is in release another for the

ConfiJ~ati(m Librarian. The tasks for the Librarian are:
• the to be included in the 1'"1,,.<>0 .. '
• Ensure that all the have reached a status which
allows them to be released into live oplera'uOll;
• which do not have a current
• Build a release pal;;Ka.ge:

• List the release and the error reoorts or
• Distribute the --,----.

• Be able to recreate any baseline if a site
ona
• Know which site has what version and variant of the prOIQU(:t.
190
Each release should have a release identifier of the same
form as the version number described for a (Le. baseline
issue number) that identifies:
.. The level bv the release - defined bv the
baseline nnrnhpr'
.. The modification status of the release - defined bv the issue
.. The release - by reference to the relevant baseline

summary.
The release identifier should be revised:

.. When the new release of the o.;WW!;;1;;U
- the baseline number is incremented up to the next

whole number 2.1 becomes
.. When the new release of the fault fixes
the issue number is incremented by one (e.g. 1.4 becomes 1
.. OptionaUy when the new release of the consolidates
many 20) minor the baseline number is
incremented up to the next whole number.
A release should be a release build summary. It

should contain:
.. The release name and Identltier;
.. The release
.. The with for the release. This
will be the contact for any installation If not
then this information should be
......."''"'u..........,"'"' of the
whether it is a or
what has caused the what is its purpose,
nr",v;nu" releases;
• A list ~+' _~_~m for the installation of the

.. A list of all the Issues Hn~wered this
191
Managing Projects the PRINCE2 Way ConJIguration Management
• A bill of material, listing what is contained in the release. This (~~
should cover documentation and any procedures;
!'II
• Assembly steps;
• Assembly test steps;
:"I
• Any customisation steps. If the release can be tailored in any way,
this describes the possibilities and lists the steps to be carried out;
• Notification of any dates when support for previous releases will
cease;
• An acknowledgement to be completed and returned by the
assembler on successful completion of the assembly.
While current, a baseline cannot be changed. It remains active until '~
it is superseded by the next baseline.
Project Filing -
This is a suggested filing system to be used by a project.
There are three types of file in PRINCE: '~'~
• Project
• Stage ~,: ~;
.~lt
• Quality.
It is a project decision whether to include the management and quality
.:;,~.'.'
products within the configuration management method. Even if they are
not, a project filing system will still be needed.
The Project File
This has the following sections:
Organisation
~ ~i2
The project organisation chart and signed job descriptions. ~
Plans
The Project Plans. This should include any versions developed,
not only the one approved as part of the Project Initiation
Document. All the various components of each version should
be kept (such as Product Breakdown Structures, Product Flow ,"
Diagrams) with clear identification of their date, version
number and reasoning, such as change of assumptions, scope,
I'l':'
resource availability and so on. ."
..;.~
192 t~
~
UPUJiU:U at least a1 the end of each
Business Case
Versions of the Business at each end or
when Plans are created.
Risk Log
details of an identified their status and
countermeasures.
Control
Copies Initiation and Closure documents.
Communication Plan
Details of all those ~p.ivin or information.
Files
These have more sections than the project file.
details of team members. These should

5",,"Ui:)Q.,,-Vu.,
asSignments, achievements and the or

~ma.ger·s assessment of the work peliol:rrumce.
Plans, any Team Plans and Exception

UI-'~I4"";U with actual information as available.
Control
A diary of events, answers, informal

discussions with Proiect Board members. and actions for the
or other papers
193
The Quality File {
The objective of a Quality File is to permit an audit at any time of the
quality work being done and to confirm adherence to quality standards.
There is one Quality File that runs through the whole project and is not .
divided into stages.
Customer's quality expectations
Acceptance Criteria
Project Quality Plan
~
The original and any later versions of the plan.
Configuration Management Plan
Configuration Item Records
The master copy of all Product Descriptions. As more information ..,
becomes available, this will grow into full Configuration Item
Records for the products.
Quality Inspection Products
- ''''',~
It is useful to head this section with a log giving a number to each

check, the type of check or test (e.g. Quality Review), the product
··f
and date. This is a quick reference to see or show how many checks
have been held in a particular stage and a guide to where the
appropriate documentation can be found
.;:
The division of the quality section will depend on the type(s) of
check or test being made. The filing for Quality Reviews, for
example, should have separate sections for:
Invitations
Result notifications -,..<
~
p;
Action lists. \1
Project Issues
This should have the Issue Log at the front to facilitate sequential
numbering and to record the status and allocation. The subject of
Project Issues is covered fully in the Change Control chapter.
Links
Configuration management links to quality. If you lose control over
which versions should be used, or release old versions of components or r
194
CO:nfil"l"Iil:i~ln Management
allow the release of an untested change, the ofthe will

suffer.
There is a very corrfigurati4)n mlllDa,geDtlent and
control.
other.
Do's and Don'ts
Do relate the of the configuration method to the
needs of the
Don't underestimate the As
was said at the of the chapter, if there is more than yourself
W(1lrKllng on the if there will be more than one version of a
you need management. Make sure that it's
adeQua,te for
If it's a
,",V:u.11151J.l.:l.UU'llLibrarian role should be of the
one of the software tools available on the market.
If the customer has a method in place
to look after all products in live operation, the should use the same
method.
Ifit can be foreseen that there will be many the life of the
consider whether you should recommend the use of a change
authOltlty with its own budget for There is a low limit on the
amount of time that Board have to consider "'....LllS,"",
and it may be sensible to delegate this. to those performing the
Assurance roles.
If it's a Small ..,rl,\IPj~T
Members of the team can probably do I

looked at a feasibility study where one of the performed the
Librarian's job, It took about two hours ofhis time each
week. There was a lockable cabinet in which the various versions of
sections of the were kept. Team members were responsible for
the when wanted to move to a new version. The
librarian checked the log and allocated the next version number,
first the reason for the These reasons had to be
documented. Once a the would take the cODfiglJration
records the and check that there was a match between the
records the version numbers beine: used.
195
Two Simple Configuration Management Methods
When many people read about configuration management in the
PRINCE2 manual they are alarmed at its apparent complexity and the
amount of effort it will take. Very often there is only a part-time resource
available. Most of the software to support configuration management at
present is very expensive, complex to operate and usually needs a
powerful computer.
A number of companies have ignored the subject all together, but some
have opted to undertake very simple configutationmanagement methods.
Here are two such methods.
Simple System 1
Some time ago I visited a site working on a project for the Fleet Air Arm. ~
They demonstrated a very simple configuration management method that

reduced the Configuration Librarian's effort to about one hour a week.
The project was a short one to produce a technical design study, and
therefore did not have the complexity of having to handle many products.
Identification 'I:~\I
All configuration items had a prefix that indicated the contractor and
the project. The letter M, T or Q to denote that the product was a
management, technical or quality one followed this. Then there was
another alpha character denoted the filing sub-section, and finally
there was a sequence number to identifY the document within the
sub-section. A filing log kept track of the sections, sub-sections and .~,~
sequence numbers allocated.

All products that appeared in the Project Briefhad a Product ..,.
Description. These appeared in the one Stage Plan and had the same
unique reference. These products were kept to a fairly high level.
For example, the Project Initiation Document was one product. The
technical plan showed each product broken down to sub-products,
but these did not warrant a Product Description themselves. Each
sub-product was broken down into the activities needed to create it.
All documents contained data in the page footer that included
document title, configuration identifier, version number and date.
Quality Review Log
Each document had its own folder. In each folder there was an
informal Quality Review log. Each product tended to go through
several informal Quality Reviews. On completion of an informal
Quality Review the owner of the product would advise the
196
9
fi
; '~
Configuration Librarian, and pass over a copy of the annotated
product for safe-keeping in the folder. The librarian then updated
the QR log. The information kept about the review, and therefore
about the product, was minimal, just the date and version number.
The version number was a two-part code. While the product was
going through its initial creation the version was '0' , and the sub
'- versions began at 'A' and ran through the alphabet So after three
informal Quality Reviews a product would have the version 'O.C'.
" Once the client had formally accepted the product, the version
number became '1.0'. If that went back for change later, it would be
" renumbered 'l.A' and so on.
~ Configuration Status
-.li
The librarian kept a small summary of the status of each product
This was, in fact, only a copy from the informal Quality Review logs
of the latest known version level of each product and the date on
which it was submitted to the library. Regularly the librarian would
take this to checkpoint meetings and get each team member to
\o\l confirm that this was the latest status. If a product had moved on to
a later version, the lIbrarian would insist on the informal Quality
Review log being updated and for the relevant annotated product
~~~lt~~\ copies to be filed in the folder.
-'9
No other status information was kept. The version number was the
only clue as to status.
Quality File
This simple system meant that there was always a link between a
product and its quality review(s). No action list was made out
during these informal reviews; the product was just annotated with
details of any changes required. Since a copy of the annotated
product was filed away in the folder, the folders themselves formed
~. the quality file. In the PID a section was defined as being the
storage place for informal Quality Review results, but this was not
used.
After the informal reviews there was always a formal review with
the client, at which time a Quality Review Action List was made
out. There were separate sections of the quality file to hold
invitation copies and results of formal Quality Reviews. For them,
formal Quality Reviews were when the client attended, informal
reviews were all those internal to the team.
197
IVlam:lglIlg the PRINCE2
_ ..... 1
the need to use it, because
The librarian did not details of who had copies of a

but felt that this was a function which would have to be added later
in the
Issue fonn had been but

client had not come up with to the
had not come up with any failures to meet the and any
qUl~St1ons had been dealt with by word of mouth. The project
I-/li1J..illt;U to take or nine weeks. I that in a
the for formal use
Kcqm:s1S For and would have expiosed
the simnlistic that
Location information was held. This indicated the 1J~r.sUl1aI

cornptlter on which the text of the document was
1 ............ ".1" format.
No fonnal details were of 'where used' data. At the foot of one

ofthe documents there was for the author to indicate usage,
but this was little used As level ones and at
an in the life there were no sub-
products, or at least the to that level of
detail.
Simple 2
used
office that ~UpPHCU
Confil~ati(>n Librarian functions to all n,.""p,..·t",
A item was identified bv a combination of:

An identifier which denoted the business area, the project and a
sequence number within the
198
Configuration Management
edition Jillle 2005)
i A type (of which more later)
[ Version number
Version Numbering
They opted for a simple, single character version number, allocated
by the librarian. Up to the initial approval the version number was
'I'. If this was ever required to be changed, it became version '2', and
so on. There was no connection between a configuration item's
version number and the release number or baseline, and no
connection between the version numbers of the items that made up a
baseline. For example, baseline 2 might have included version I of
item A, version 3 of item B and version 5 of item C.
Configuration Item Data
A copy of the Product Description was held in the product folder.
Apart from the information required by PRINCE2, the Product
Description included the identifier and type (not the version number)
so that there was a common identifier with the Configuration Item
Record.
~
'Type' was used to identify different products that stem from the
same basic product. For example, associated with a program
specification there would be:
I I A program design
[' Source code (human readable)
[ Source code (machine readable)
An object deck
Test data
Test data expected results
Screens
Help screens
and so on. These were all given the same identifier, but the 'Type'
field changed. There was a standard for the various types allowed.
Apart from the Product Description data, a Configuration Item
Record was kept in the product folder. It contained the fields:
Identifier
199
[ Type
[ Version
1_ Stage during which the product was created
[ Author (or supplier if external)
C Location
[' Quality review number
L Copies held by
r:: Cause of version change (this was a cross-reference to one or
more Technical Exceptions)
[J Status (explained below)
I Where used (explained below)
.,
Status
The status of a configuration item could be one of five things:
L~ PD - the Product Description has been written
[ IP - the product is in progress
[ DR - the product is available in draft form
r QR - the product has been quality reviewed
~.
o AP - the product has been approved

Together with the status was held the date of change to that status.
At the Milk Marketing Board all this data was held on one form.
The status possibilities were held in boxes that were crossed through
as the product reached that status. Figure CM1 shows an example of
this for a product for which a draft existed.
p.Q 13 Feb 04 PD PD
'
'-.
'
.~
W 17 Mar 04 IP IP \:i:
'...•..
I!m 28 Mar 04 DR DR ~
QR QR QR
AP AP AP
Figure eM]
If the product failed its Quality Review so badly that it was returned
for a complete re-work after which it was to be reviewed again, an ~
200
arrow was drawn back to the box '}P'. As it the
to a second lines were drawn other way.
CM2 shows an of a product that failed its review and had
now reached draft form for the second time.
~ I 13 Feb 04 I PD
17 Mar 04 IP 3 Apr
Two card files were maintained,

each box. Both contain details
in another item. One was filed in order
the other in order of the items.
One form was used to cover

and A box on the form mOllcatecl
had been made. This meant that
than one for each type Issue. No new version ofa
C011fi~~atl(m item could be created after the initial one without a
crolss-ret~~reJllce to at least one Technical Exceotion that caused the
need for a new version.
The number in the Item Record referred to the

where under the same reference the Invitation and
Action List were filed. Boxes had been added to the bottom of the
action list form, so that the same form could be used as the QR
Result Notification form as well
an official stamp indicating the

purpose, date. The last piece of
data was to encourage the return copies. The
was coloured so that an official copy could be discerned from a
copy. This was to avoid that were not known to the
201
librarian, and therefore might be uncollected when the product .....
changed, thus making them unreliable.
I hope this description of two simple implementations of configuration
management is helpful.
,,~,
..',1.'
~"
!." .d
~
202
.j
-.. Managing Projects the PRINCE2 Way Product-Based Planning
(
"I
Product-Based Planning
Product-Based Planning is fundamental to PRINCE2 and I thoroughly

recommend it. There are two reasons for this. Firstly, a project delivers
products, not activities, so why begin at a lower level? The second reason
is about quality. We can measure the quality of a product. The quality of
an activity can only be measured by the quality of its outcome (the
product).
Product-based planning has three components:
• Product Breakdown Structure
• Product Descriptions
• Product Flow Diagram.
Product Breakdown Structure
Most planning methods begin a plan by thinking of the activities to be
undertaken, and listing these in a hierarchical structure called a Work
Breakdown Structure (WBS). These activities, however, depend on what
products are required to be produced by the project, so the correct start
point for a plan is to list the products. In fact, by jumping straight to the
~r
l\~~\~
lower level of detail of activities, it is possible to miss some vital products
and hence vital activities from the plan.
A Product Breakdown Structure is a hierarchy of products, the production
of which must be shown in the plan. At the top of the hierarchy is the
final end product, e.g. a computer system, a new yacht, a department
relocated to a new building. This is then broken down into its major
constituents at the next level. Each constituent is then broken down into
its parts, and this process continues until the planner has reached the level
of detail required for the plan.
Products at an intermediate level in the Product Breakdown Structure
may be either products in their own right - INTEGRAnON PRODUCTS
- (they need to be assembled or tested when all their lower level products
are available) or GROUPINGS - not products themselves, but a name for
the group of products listed below them in the hierarchy.
Let's take an example of the products required in the Starting up a
Project (SU) process. There are many complications that can occur in this
process, but for the sake of an example we shall keep this simple.
....
203
...r
Managing Projects the PRINCE2 Way Product-Based Planning

Product Description
For each significant product a description is produced. Its creation forces
the planner to consider if sufficient is known about the product in order to
plan its production. It is also the first time that the quality of the product
is considered. The quality criteria indicate how much and what type of
'1
quality checking will be required. The first step when planning a project
should be to write a Product Description for the final product.
- -,.
Figure PBP1
The purposes of this are, therefore, to provide a guide:

• To the planner on how much effort will be required to create the
product;
• To the author of the product on what is required; -.:....
• Against which the finished product can. be measured.
These descriptions are a vital checklist to be used at a quality check of the
related products.
The description should contain:
• The purpose of the product;
• The products from which it is derived;
• The composition of the product;
204
kU".LU&E;J..U6 p.,.(1,'Pl'ct" the PRINCE2 Product-Based PI a" .., In..
• Any standards for fonnat and presen.tation;

• The auality criteria to be to the pm'Qu(:t;
• The verification method to be used

The Product is given to both the creator and those
who will
Product Flow the sequence in

which the and the between
them. It is Breakdown Structure. Here is a
PFDfor
FigurePBPl
A PFD needs a to contain the to

be created by the an ellipse for that are
available or are to be obtained from a source external to the
an arrow to show the UI;;IDt::J:luelll:)
External n ...............
There are times when you is dependent on
one or more over the del.1vP T'V no control. To
illustrate how we would show such let's take
the foHowing situation:
205
"The lecturer will you a scenario. Draw a Product Breakdown
Structure and a Product Flow Diagram for the described in the
scenario. When you have the PBS the lecturer will you an
...,,,..1,.,,,<> the names of two products for which you have
The PBS and PFD for this statement would look like the
FigurePBP3
Here we can see the PBS is drawn based on the scenario. Once this is
done, the PFD can be drawn and the Product Descriptions written in
any order or in But the Product Descriptions are on
receiving the PD choice from the lecturer.
PBN
The external products, i.e. those over which you have no control, are
in an ellipse to differentiate them from the over which you
control. If you wish to use the symbol you have
_~"~_.~, in the PBS to show this is perfectly acc:eptable.
206
<': (revised edition June 2005)

Management Products
Another important departure from other methods is the emphasis that, as
well as the technical or specialist products of a project, there are always
management products. Listing these will remind us that they too take
effort to produce and need to be planned as much as the production of
technical products.
The management products are much the same for every project. Here are
sample Product Breakdown Structures of the management products.
..~~
FigurePBP5
-:"''' )
.,.,.
\ 207
r-,'
~-
Quality Other Project

Quality Quality Issue
Review Issue
Log Control Log
Documents Masters
Documents lw
AV
FigurePBP6
,;s'~
'::':i
.........
~
\',""'-'
-
.-. ,
~
.,
~
'..Ii"
~
208
~
Managing Projects the PRINCE2 Way Quality Review
Quality Review
This is a team method of checking a product's quality by a review

process. The purpose of a Quality Review is to inspect a product for
errors in a planned, independent, controlled and documented manner and
ensure that any errors found are fixed.
The Quality Review technique is a structured way of reviewing products
and products and running a meeting on the review to ensure that all
aspects are properly covered. It needs to be used with common sense to
avoid the dangers ofan over-bureaucratic approach but with the intent to
follow the procedures laid down (to ensure nothiD.g is missed).
~
The major aim is to improve product quality. There are several
subordinate objectives. These are to:
• trap errors as early as possible;
• encourage the concept of products as team property rather than
belonging to an individual;
• enhance product status data (i.e. not only has the creator declared it
finished, but others have confirmed that it is of good quality);
~-\ • monitor the use of standards;
• spread knowledge of the product among those whose own products
may interact with it .
.tJ Quality Review documentation, when filed in the Quality File, provides,
together with the Quality Log, a record that the product was inspected,
that any errors found were corrected and that the corrections were
themselves checked. Knowing that a product bas been checked and
declared error-free provides a more confident basis to move ahead and
use that product as the basis of future work.
People Involved
...,p
The interests of parties who should be considered when drawing up the
list of attendees are:
• The product author;
''':' . • Those with Project Assurance responsibilities delegated by the
Project Board;
• The customer;
'""'" • Staff who will operate or maintain the finished product;
209
" in the relevant product area;
" Standards represc~nt:ltivles
Roles at the Quality Review
The roles involved in a Quality Review are:
" The who is the author of the being reviewed.
This role has to ensure that the Reviewers have all the rcclUll:W
information in order to This means a
copy of the product from the Librarian to them
the any documents needed to it
in context. Then the Producer has to answer about
product the review until a decision can be reached on
whether there is an error or not. the Producer will do most,
if not of the work. The Producer must not be
allowed to be defensive about the nroo.u<:t.
" The Chairman. An open, objective attitude is needed. The
Chairman has the attributes:
autnrn~~tocontrolthe
o unaerstands the Review process WUlUUlUIl
o Chairmanshio exoerience.
The Chairman is for ensurulg
~~~_~¥1" and that it runs ;)LU:VVL.I.ll Y
this includes ch€:cking
been carried out and that the people have been
This needs consultation with any
Assurance roles and reference to the
" The to assess the product from
theit
" A Scribe - someone to note down the agreed actions. Very often
this role is taken someone from
It must be that these are roles. at a
but a person may take on more one role.
There are three distinct Review nrocedure:
210
:i
.!~,

QUALITY REVIEW PREPARATION

Reviewers
Scribe
Producer
Chairman
Producer
~...
JIll""
"i' ..
Figure QRl
~\\\ The objective of this phase is to examine the product under review
and to create a list of questions (or possible errors) for the review.
The Chairman checks with the Producer that the product will be
ready on time. If not, the Project Manager is advised. This will lead
to an update of the Stage Plan. The Chairman ensures that the team
of Reviewers is agreed, that they will all be available and that the
venue has been arranged.
An invitation is sent out, giving the time and place for the review
with copies of the product, the relevant Product Description and any
checklist available. This should be done with sufficient time before
the review to allow the Reviewers time to examine the product and
to provide a Question List to the producer.
Each Reviewer will study the product and supporting documents

(including the quality criteria in the Product Description), annotate
the product, and complete a Question List.
A copy of the Question Lists will, wherever possible, be sent to the

Producer before the review. The Producer and Chairman should
review these to allow the Chairman to set up an agenda, prioritise
211
Managmg the PRINCE2 Quality
edition June
quesuons and allocate time to each point. To save time
at the the Producer can questions that identify
agreed errors.
The of the review is to agree a list actions needed to

correct or complete the The Chairman and the Producer do
not have to reconcile actions at the - it is sufficient for
the Chairman and Reviewers to agree that a area needs
correction or at least re-examination. that the action is
logged the Reviewers have an to
confirm that action has been
The Chairman opens the and introduces those if

necessary. Timing (suggested maximum of 2 hours) is announced.
The Producer then 'walks through' the in detail. The

Reviewers' Lists already sent to the Producer will
determine this. If it is found that is understood and
acc:epl:ed, there is no point in it.
The Chairman controls the discussion

that no are than obvious and
imme:d.i1ltelly CU';!,.;l;;IJU;:;U solutions!). The Scribe notes actions on an
minutes are taken of the review.
At the conclusion of the the Chairman asks the Scribe

to read back the actions and determines respolllSilbility
A date is set for each
will corrective action as it is
cornpllete:a and found are recorded on the Action List by
the Scnbe.
The after the Reviewers' and Producer's OPIIDO,ns,

will decide on the outcome of the review. There can be one of three
outcomes:
• The product is 0.....,..,..."'0.,.·
• The product will be acceptable on of the actions
noted;
• There is so much corrective work to be done that the entire
......vI",,' needs to be re-reviewed.
212
<C'
,~
~ <-

In the latter case, the Chairman will advise the Project Manager so
that the Stage Plan can be updated. The Quality Log is updated. A
result notification will be completed and the documents attached.
These forms will be filed in the Quality File.
The Reviewers' Question Lists, copies of the product (probably

~.\ containing the Reviewer's annotations) and any other relevant
documentation is collected by the Chairman and passed to the
Producer to assist in the follow-up.
Phase 3 - Follow-Up
QUALITY REVIEW FOLLOW-UP
\;.::.~::
r;:'
\i*:'V;,
"
Figure QR2
The objective of the follow-up phase is to ensure that all actions

identified on the Action List are dealt with.
<.:k:
The Producer takes the Action List away from the review and
evaluates, discusses, and corrects, ifnecessary, all the errors.
When an error has been fixed, the Producer will obtain sign-off from
whoever is nominated on the Action List. This person may be the
Reviewer who raised the query initially, but other Reviewers have
the option of checking the correction.
,- When all errors have been reconciled and sign-off obtained, the
Chairman will confirm. that the product is complete and sign off the
213
~
(

Action List. The documents will be filed in the Quality File and the ......
' ,.
Stage Plan updated

Quality Review Responsibilities
~.
Chairman's Responsibilities
Preparation Phase ...
I . Check with the Producer that the product is ready for review.
2. If not, update the Stage Plan, e.g. a revised completion date.
3. Consult with the Producer and those performing Project Assurance
roles to confirm appropriate Reviewers.
4. Agree the amount of preparation time required with the Producer
(and Reviewers, if this is appropriate).
5. Arrange a time, location and duration for the review in
consultation with the Producer and Reviewers.
6. Advise the Project Manager if there is to be any delay in holding
the review.
7. Arrange for copies of any relevant checklist or standard to be
provided.
8. Ensure the Configuration Librarian provides Product Descriptions .·)At
and product copies for all Reviewers.
9. Send an invitation, Product Description, product copy, blank
,';;;~'.
Question List, product checklist (if there is one) to each Reviewer. ·l'i "'.
IO.Send a copy of the invitation to the Producer.

II.Decide if a short overview presentation of the product to the
Reviewers is required as part of the preparation, and arrange it if it
is.
I 2.Arrange with the Reviewers for collection of their Question Lists
prior to the review. I.t::
13. Create an agenda for the review from the Question Lists in
,';),"
consultation with the Producer. Agree any obvious errors in the
product with the Producer. Prioritise the questions and roughly
allocate time.
::i'~
14.Confinn attendance with each Reviewer shortly before the review. :t
If a Reviewer cannot attend, ensure that the Reviewer's Question
List is made out and submitted. If too many Reviewers cannot
attend, re-schedule the review and inform the Project Manager of
~'J
the delay.
214
~
(revised edition June 2~O-,-O_5)'--_ _ _ _ _ _ _ _ _ _ _ _ _ _-l
15.Ifnecessary, rehearse the review with the Producer.
Review
1. Provide a copy of the agenda to all attendees.
2. Open the review, stating objectives and apologizing for any non
attendees.
3. Decide whether the Reviewers present and the Question Lists
from any unable to attend are adequate to review the product. If
not, the review should be stopped, re-scheduled and the Project
Manager advised.
4. Identify any errors in the product already agreed by the Producer
and ensure that these are documented on the Action List.
5. Step through the agenda, with the appropriate Reviewer
enlarging where necessary on the question.
6. Allow reasonable discussion on each question between Producer
and Reviewers to decide if action is required.
7. Ensure that the Scribe documents any agreed actions required on
an Action List.
8. Prevent any discussion of possible solutions or matters of style.
9. Ensure that Reviewers are given a chance to voice their
comments.
10.Where agreement cannot be reached on a point in a reasonable
time frame, declare it an action point and note the Reviewer(s)
concerned.
11.Where necessary, decide on the premature close of the review in
the light of the comments made.
I2.If faults are identified in products not under review, ensure that a
Project Issue is raised and sent to the Configuration Librarian.
13. Collect any annotated products detailing minor or typographical
errors.
14.Read back the Action List and obtain confirmation from the
Producer and Reviewers that it is complete and correct.
I 5 Jdentify who is to be involved in working on each action item.
Obtain a target date for completion of the work.
215
with the Reviewers who is to approve the work done on
each action item and note this on the Action List.
17.Pass the Action List and all of the annotated
Producer. a copy of the Action List in the
18.Decide with the Reviewers what the status of the review is. It can
be:
• 'I..A'J..UI.H<ot'" with no errors iii Q('.l)V..T../'l
• 'I./\J'J..UIJl"'" with some re-work

• In need of re-work and another review.
19.1f the review is recommend a course of action to the
M.l.nager There are five courses of action. The
are not recommended:
• nrorillct should be re-worked to another
• The review should be reconvened to finish with no interim
need for ,.",_nr......Ir·
• The review should be reconvened without re-work with a
different set
• The review should be declared the errors found so
far corrected and the rest ofthe as
• The review should be abandoned and the nrr,,1n,M'
Le. none of the errors but noted in a
1. Monitor the correction of errors and sign off the Action List
when all corrections have been "..."".,.",,,,;1
2. If an action carmot be taken within the time
and Producer may decide to transfer it to a
IJV~"HU1" error. This the ofthe
The Action List is with the Project Issue
number and those waiting to off the action item infOImed.
3. On and action off the
vvU~I.I1\..'"' and file it in the with
the Quality
4. the passage of the error-free nroduct to the
COll11gura1tJ.on Librarian.
216
Review
Producer's Re:sponsilbillties
~Y.l.1l.lli1.l:St;;;1
to nominate a Chairman if none is
Plan.
2. Confirm with the Chairman that the is for
review. This should occur several to the planned
review date to allow for nN''''''r",Il/~n
3. Confirm the attendees with the Chairman and those holding
Assurance reSpOllSlI)1lltles
4. with the Chairman and Reviewers the length of
nl"P,""T"'Il/~n
time needed and review location.
S. Assess the
6. the agenda with the Chairman in the lililit of the

QU,estlOn Lists.
1. Answer any questions about the IJ~\J'UU~;L.
2. VllllllVll to the Chairman on whether a has
3. If the review to be collect from the

Chairman the Action List and any annotated copies of the
from the Reviewers.
1. Resolve all allocated action items.

2. Obtain sign-off for each action item from the nominated
Reviewers.
3. If an action item cannot be resolved within a reasonable
bIIllefi:ame, then the Chairman and Producer may decide to
transfer it to a Issue. An alternative is to agree new
dates.
4. Pass the Action List to the Chairman on resolution of all the
action items.
217
Reviewer Responsibilities
Preparation
1. Consult the Product Description and any pertinent checklists
and standards against which the product should be judged.
2. Allow sufficient time to prepare for the review.
3. Consult any necessary source documents from which the
product is derived.
4. Annotate any spelling or typographical mistakes on the
product copy, but do not add these the Question List.
5. Check the product for completeness, defects, ambiguities,
~
inconsistencies, lack of clarity or deviations from standards.
Note any such items on the Question List.
~
6. Forward the Question List to the Chairman in advance of

the review. If possible, this should be done early enough to
give the Producer time to digest the points and prepare an
agenda with the Chairman.
7. Forward a Question List and the annotated product copy to
the Chairman if unable to attend the review. ;.. ~;;
Review
1. Ensure that the points noted on the Question List are raised
at the review.
2. Restrict comments to faults in the product under review.
3. Avoid attempting to redesign the product.
4. Avoid 'improvement' comments if the product meets
requirements and standards. (:it,
\~\\;
.;,. ..\
5. Verify and approve the Action List as complete and correct

when read back by the Chairman.
6. Agree to assist in the resolution of any action items if
requested by the Chairman.
7. Request to check and sign off any action items either raised
personally or which impact the Reviewer's area of expertise
or interest.
Ii
218
"'" Managing Projects the PRINCE2 Way Quality Review
Follow Up
1. Work with the Producer to resolve any allocated action
l\~~
item.
2. Check and sign off those action items where allocated as
Reviewer.
Formal and Informal Reviews
,II '
Quality Reviews can be either formal (i.e. a scheduled meeting
conducted as described above) or informal (i.e. a 'get-together'
between two people to informally walk through a product). A
variation on a formal review is to have the Reviewers forward their
Action Lists, but only the Chairman and the Producer do the actual
review.
Informal Quality Reviews will follow a similar format to the Formal

Quality Review - the paperwork emerging from both meetings is
similar. The main difference will be the informality of the
proceedings during the three phases and the overall time required.
",;~
For informal Quality Reviews two people can be given the task of
checking each other's work on an on-going basis. Alternatively an
,1'1;1,j.'
experienced person can be asked to regularly hold reviews of an
inexperienced person's work as it develops.
Factors in deciding whether a formal or informal review is needed

are:
r I The importance of the product;
LI Whether it is a final deliverable;
I Whether it is the source for a number of other products;
The author's experience;
Who the product's consumer is;
Whether it is a review of a partial document.
~
219
Managing Projects the PRINCE2 Way Roles
Project Management Team Roles
Here is a description for each role in the project management structure.

These can be used as the basis for discussion of an individual's job and
tailored to suit the project's circumstances. The tailored role description
becomes that person's job description for the project. Two copies of an
~
agreed job description should be signed by the individual, one for
retention by the individual, the other to be filed in the project file .
Project Board
General
'1\1
The Project Board is appointed by corporate/programme
\~
management to provide overall direction and management of the
project. The Project Board is accountable for the success of the .......,
project, and has responsibility and authority for the project within
the limits set by corporate/programme management.
The Project Board is the project's 'voice' to the outside world and is .il.:;.~~
responsible for any publicity or other dissemination of information
about the project.
Specific Responsibility
The Project Board approves all major plans and authorises any major
deviation from agreed Stage Plans. It is the authority that signs off the
.,'\:."J
completion of each stage as well as authorises the start of the next
stage. It ensures that required resources are committed and arbitrates -'-'
on any conflicts within the project or negotiates a solution to any

problems between the project and extemal bodies. In addition, it
approves the appointment and responsibility of the Project Manager
and any delegation of its Project Assurance responsibilities.
.,.,
The Project Board has the following responsibility. It is a general list i'
It;
and will need tailoring for a specific project.
At the beginning of the project:
• Assurance that the PID complies with relevant customer
standards and policies, plus any associated contract with the
supplier;
• Agreement with the Project Manager on that person's
responsibility and objectives;
;
220
;'..;.,.
[ (revised edition June 2005)
• Confirmation with corporate/programme management of
project tolerances;
• Specification of external constraints on the project such as
quality assurance;
• Approval of an accurate and satisfactory Project Initiation
Document;
• Delegation of any Project Assurance roles;
• Commitment of project resources required by the next Stage
Plan.
As the project progresses:
• Provision of overall guidance and direction to the project,
ensuring it remains within any specified constraints;
• Review of each completed stage and approval of progress to
the next;
• Review and approval of Stage Plans and any Exception Plans;
• 'Ownership' of one or more of the identified project risks as
allocated at plan approval time, i.e. the responsibility to
monitor the risk and advise the Project Manager of any change
in its status and to take action, if appropriate, to ameliorate the
risk;
• Approval of changes;
• Compliance with corporate/programme management directives.
At the end of the project:
• Assurance that all products have been delivered satisfactorily;
• Assurance that all acceptance criteria have been met;
• Approval of the end project report;
• Approval of the Lessons Learned Report and the passage of
this to the appropriate standards group to ensure action;
• Decisions on the recommendations for follow-on actions and
the passage of these to the appropriate authorities;
• Arrangements, where appropriate, for a post project review;
• Project closure notification to corporate/programme
management.
221
(revised edition June 2005) ,..,.
The Project Board is ultimately responsible for the assurance of the
project, that it remains on course to deliver the desired outcome ofthe
required quality to meet the Business Case defined in the project
contract. According to the size, complexity and risk ofthe project, the
Project Board may decide to delegate some of these Project Assurance
responsibilities. Later in this chapter Project Assurance is defined in
more detail.
' oC.o>
One Project Board responsibility that should receive careful
consideration is that of approving and funding changes. The chapter
on Change Control should be read before finalizing this
responsibility of approving and funding changes.
Responsibilities of specific members of the Project Board are
i
described in the respective sections below.
...... ~
""';\1'
.\1.·:,
....:"
'i" ~'~;
~\'
\~i~-'~\'
I,',
.....
1'4'f:
'
~
'.
I''.
,,.
222
~
[
(~~~~C!~!i~~~1Jl:l~~QQ~L
Executive
General
The Executive is ultimately responsible for the project, supported by
the Senior User and Senior Supplier. The Executive has to ensure that
the project is value for money, ensuring a cost-conscious approach to
the project, balancing the demands ofbusiness , user and supplier.
Throughout the project the Executive 'owns' the Business Case.
Specific Responsibility:
• Ensure that a tolerance is set for the project by
corporate/programme management in the Project Mandate;
• Authorise customer expenditure and set stage tolerances;
• Brief corporate/programme management about project
progress;
• Organize and chair Project Board meetings;
• Recommend future action on the project to
corporate/programme management if the project tolerance is
exceeded
• Approve the End Project Report and Lessons Learned Report;
• Approve the sending of the notification of project closure to
corporate/programme management;
The Executive is responsible for overall business assurance of the
project, i.e. that it remains on target to deliver products that will
achieve the expected business benefits, and the project will complete
within its agreed tolerances for budget and schedule. Business
assurance covers:
• Validation and monitoring of the Business Case against
external events and against project progress;
• Keeping the project in line with customer strategies;
• Monitoring project finance on behalf of the customer;
• Monitoring the business risks to ensure that these are kept under
control;
• Monitoring any supplier and contractor payments;
223
thePRINCE2
vll....l~'~"
to the Project Plan to see if there is any
" needs of the business or the Business
" ASsessmg Dotential on the Business Case
sUDDUt:r excesses;
caused by a programme
" vll<Wl'5"'"
resloonsibilit) may be
programme representation on the
and progress the

"
If the project warrants it, the Executive may some
resP01lSil)ililty for the above business assurance functions.
224
Manag;mg p,."., ..,.,." the PRINCE2 Way Roles
The Senior User is for the of the needs of all

those who will use product(s), user liaison with the
team and for that the solution will meet those needs within
constraints ofthe Business Case.
those for whom the will achieve an

obJect:J.ve,or those who will use the to benefits. The
Senior User role commits user resources and monitors ..,.. v ......."'''''
against This role may more than one person to
cover all the user interests. For the sake the role
should not be split between too many
• Ensure the desired outcome of the is spe'cltlect

• Make sure that progress towards the outcome the
users remains consistent from the user pel:spc~ctt
• Promote and maintain focus on the desired project OUl:come
• Ensure that any user resources for the are made
• A nnmve ¥roduct uescnpttons for those .,..r,nnM"

or (interim or from the
or will affect them and that the pwuu",,,,, off
once ,",V'c.ULJ1\,.''''''.
• Prioritise and contribute user to Project Board
decisions on whether to imolement recommendations on
• Resolve user and

• Provide the user view on recommended
• Brief and advise user on all matters concemmg
the
The assurance of the Senior User are that:
• of the user's needs is accurate, comolete and
225
• Development of the solution at all stages is monitored to ensure .~
that it will meet the user's needs and is progressing towards
that target;
• Impact of potential changes is evaluated from the user point of
VIew; ,...
• Risks to the users are constantly monitored; \
• Testing of the product at all stages has the appropriate user

representation;
• Quality control procedures are uSed correctly to ensure
products meet user requirements;
• User liaison is functioning effectively.
Where the project's size, complexity or impOitance warrants it, the
Senior User may delegate the responsibility and authority for some of ~
the assurance responsibilities.
::..:
"..
.....\ .
"~
,)~
:.:
<r
f,_.••
~. t.'
"'1;
~~~
,.j\!:
~
226
~

~ Senior Supplier
General
~ Represents the interests of those designing, developing, facilitating,

procuring, implementing, operating and maintaining the project
rc: products. The Senior Supplier role must have the authority to commit
or acquire supplier resources required
If necessary, more than one person may be required to represent the
:7-'
':1 suppliers.
~
Specific Responsibility:
• Agree objectives for specialist activities;
;::. • Make sure that progress towards the outcome remains
consistent from the supplier perspective;
• Promote and maintain focus on the desired project outcome
from the point of view of supplier management;
• Ensure that the supplier resources required for the project are
made available;
• Approve Product Descriptions for specialist products;
4~, • Contnbute supplier opinions to Project Board decisions on
whether to implement recommendations on proposed changes;
• Resolve supplier requirements and priority conflicts;
• Arbitrate on, and ensure resolution of any specialist priority or
resource conflicts;
• Brief non-technical management on specialist aspects of the
project.
The Senior Supplier is responsible for the specialist assurance ofthe
project. The specialist Project Assurance role responsibilities are to:
• Advise on the selection of technical strategy, design and
methods;
• Ensure that any specialist and operating standards defined for
- the project are met and used to good effect;

• Monitor potential changes and their impact on the correctness,
completeness and assurance of products against their Product
Description from a technical perspective;
~
227
• Monitor any risks in the specialist and production aspects of the
project;
• Ensure quality control procedures are used correctly so that
products adhere to technical requirements.
Ifwarranted, some of this Project Assurance responsibilities may be
delegated. '.
•.~
""
"'"
l~
ii,·I.\",'.,-.
:~:.,;
-t ......J
~
:':"'
,...l'
~ ." I
....
.......
~
-<
228 t~
Roles
The Project to run the on a

basis on within the constraints laid
down by the board. In a environment the
.,,,,,u_,"" will come from the customer org;anisati.on.
. is to ensure that the

'!"Prim,.,,,", to the
T'I,rnro.~ standard of
spe:cl!l00 constraints oftime and cost. The
resjJOnslb,[e for the a result
aCl1tleVIDIl the benefits in the Business Case.
• NliIIlage VUU~UVll of the nrnilnrt,,·
• Direct and motivate the team;

• Plan and monitor the project;
• Assunmce roles
• Produce the contract;

• Prepare and, Plans in
conjunction with Team and appointed
Assunmce roles. and obtain Proiect Board to the
• l"l<Wil~o;; risks, the

• Liaise with programme if the is part ofa
programme;
• Liaise with programme 1.ll<U.l....""1.ll,,.... to
ensure that work is neither overlooked nor uupw,;au::u;
• Take for overall progress and use ofresources,
and initiate corrective action where necessary;
• Be for change control and any rPflui""'.n
configuration maJlagiemt~nt;
• to the Board through Reports and end
assessments;
229
l',.r\1"...t~ the PRINCE2 Way Roles
edition June 2005)
• Liaise with the Board or its aplr:JOlnted
Assurance roles to assure the overall direction and
Assurance of the "",.";p,,t·
•
• a Lessons Learned owmomthe

• from the Lessons Learned
• any follow-on action recommendations

• PTenlU'e the End
!::oum::n for the
• Be for
• Liaise with any or account managers.
230
Roles
MAnAnAr
The allocation oftbis role to one or more

the does not warrant the use of a Team lYJ.i:l.U.l:ll;;Cl,
n.<IoU...!'..... takes the role.
There are many reasons

this role. Some of these are the
.,~..i"L"U". skills or needed for certain DI1J'UUI;;US.
gel)gI'aptllCl!LIlocation of some team and the ..... ,.,.f''''''..,.,'''.~
Board.
The Team is to ensure of
M,mager to an """,,..,...,"';,,f,,,
in a timescale and at a cost to the
to and takes direction from the
The use of this role should be discussed the with

the Project Board ifthe role is planned at the outset of
the project. This is discussed in the up a Project and
lml'latimga processes.
. for the team's work and agree these with the
.. Receive authorisation from the Manager to create
.. Ml'Inl'lo~ the team;

.. I }m'!ct motiv!lt~. nlan and monitor the team
.. and advise the Project of any risks associated

with a Work
• Ensure that such risks are entered on the Risk
• risks as directed by the
• Take. _ nr"gress of the team's work and use
ofteam resources, and corrective action where
231
(
necessary within the constraints and tolerances laid down by
the Project Manager;
.~
• Advise the Project Manager of any deviations from plan,

recommend corrective action, and help prepare any appropriate
Exception Plans;
• Pass products which have been completed and approved in line
with the agreed Work Package requirements back to the Project
Manager;
• Ensure all Project Issues are properly reported to the person
maintaining the Issue Log;
• Ensure the evaluation of Project Issues which arise within the
team's work and recommend action to the Project Manager;
• Liaise with any Project Assurance roles;
• Attend any stage assessments as directed by the Project
Manager;
• Arrange and lead team checkpoints;
• Ensure that quality controls of the team ' s work are planned and
performed correctly;
• Maintain, or ensure the maintenance of team files;
~
j,~,
232
going as well as we are being told?', 'Are any
hidden from us?', 'Is the solution to be what we want?',
'Are we going to find that the is or
late?' There are other The may have a
assurance function with the to check that all
are to a quality that is being used.
All of these mean that there is a need in the
org;amlsatlon for an of all aspects of the
performance and oroducts. This is the
function.
To cater for a small project, we start these
Assurance functions as of the role of each Proj ect Board
member. to the needs and desires of the
any of these Project Assurance can be dellegated,
as the recipients are mdlepc:md.ent
--_._,-,"--' Assurance
or more of the
maooltOIY that all Project Assurance roles be UI;!vjSl.I.I.t;;U.
of the Assurance roles that are maybe ""''''l&'......
one individual or shared The when a
Assurance role needs to be It may be for the entire
of it. The person or persons Assurance
the at the of the Project
Assurance roles to be IJU11JJ.l~;U
otherwise resource usage and costs for
out of control.
There is no on how many Project Assurance roles there
must be. Each Project Board role has Project Assurance
Agai.n, each should determine what SUDDOrt. if
Board role needs to achieve this
233
IVlilll<lgWg the
For an international standards group, such as ISO may

certificate the work standards. A of the
certification is there will be some form
function that is
Project Assurance covers all interests of a all

business, user and "U~')JHtiL
Assurance has to be independent ofthe
therefore the Project Board cannot any of its
Assurance to the Manager.
The Assurance needs to
• Maintenance
},ptur_n the SUppUtiI
• Customer needs and are met or J.J..U:llla.l') "'u.,

• Risks are
• Assurance of adherence to the Business
• Constant reassessment of the SmULlOn;
• Fit with the overall programme or company sU1luegy;

• The right are ,-_._._._ ....
• An solution is ucvtaum:;u:
• The remains
• The scope ofthe
• Focus on the business need is maLintain:ed:
• Internal and external communications are urn..1r1ncr
• standards are
• It::gISlau constraints are nh"PT'VPil'
234
lVliUJlt~J.Dg Projects the PRINCE2 Roles
" Theneeds inteiresits, e.g. are
" Adherence to quality assurance standards.

It is not to believe that standards will be
to ensure that is wen set up at the outset.
listed above need to be checked throughout
as f eI:l.SUting that it remains consistent with and continues to
meet a business need and no to the external environment
affects the validity of the
235
Roles
June
Project
<.int,nnrt on a formal basis is It

the needs ofthe and
",,.,,,,,1"1' could be in the fonn of advice on
tools and administrative such as the collection of
actual to one or more related set up as an official
rep1osl.tory for lessons and a
I:Xm:n.1= in sunoort tools.
One fimction that must be considered is that
De]PeIlldirlg on the size and there
and it becomes a task with
Seethe
worle
The is a list of tasks:
• Administer
• Set up and maintain
• Establish document control
• C:nmnil,. copy and distribute all management proldUI;1s;
• (:nll .."t actual data and tOfleca:sts;
•
• Administer the review process;
• Administer
• Assist with the "'V'.llv.u".~v.u
Advice
• -=>pecla.t1S!
• tool e.g. and control risk
•
• Standards.
236
librarian Role
monitor and report on !"~<;ll.l<;llL
" To act as the focal point for Control.
" Assist the Manager to prepare the "'"'V.lll!!;W ... UU.U

Ma~:em.ent Plan
" Manager to create the vUilll!!>WI;I.UUIl
n.Ull.U"6,.".UIJ:UL structure and identification scheme
" Assist in the identification
" Create Product n,."mnticl11"
" Ensure that the structural between is
known.
" Archive superseded products.
" and record receipt of Submission Forms with
new or revised products into the CM sample form
in 1).
" Act as custodian for master of all Dr()QU:Cts as
defined in the CM
" Issue product for crumge, correction or
information.
" Maintain copy holder information for both human and machine
readable n .."ilH...t~
to their
" l.il<I.lli;;=
" Document a product is assured if a

n ..",nnlN- structure is a life
'Wherever possible the structure should not be I,;Illillgeu
other than to include items.
" Provide information for the assessment the of a change
to a product.
" Produce Status AC:COlllIltmg
" Assist in conducting Confif!Ul'ation Audits.
237
1J..,..,,,,,,to the PRINCE2 Roles
.. Create baseline records as

.. Produce release PiiJ",rut15I:;;'.
238
contains suggested contents for the main
of Product Descriptions for the PRINCE2 management
l l............. jI;"
products. Care should be taken to scrutinise them and tune them to

any site or specific needs.
239
the PRINCE2 Product n"_~i'rintinn"
ACCetltal1ce Criteria
A definition in measurable terms of those of the final

prclduct which it must demonstrate for the to be ac(:epltahie
to the customer and staff who will be affected
Composition
Criteria suitable for the Droduct. such as:
dates
.J functions
Performance levels
eiopment cost
1'\.UDIlIDg costs
Maintenance
Ease of use
Personnel level reouired to use/operate the
This forms part of the Brief. It is a list

surements, dates when each criterion should be met,
lll"'lw..1.w~ any interim measurements and dates
Derivation
Ba,ck~:rOlmd information
Mandate
Brief
240
Managing Projects the PRINCE2 Way Product Descriptions
!! Senior User
Quality Criteria
r I All criteria are measurable
• Each criterion is individually realistic
:i The criteria as a group are realistic, e.g. high quality, early
delivery and low cost may not go together.
Quality Method
L. Formal Quality Review between Project Manager and those with
Project Assurance responsibility.
241
Product n".""rinnnn.
Title
Business Case
Purpose
To document the reasons nncanon for llT'l.1",...t<l\Cin
based on the estimated cost rel()prnellt and the _,.._....___
business benefits to be . Board will monitor the
of the the Business Case. The total
cOILSidere,d. which may be much wider than
develonment cost.
The Business Case may include or leglslan reasons why the
is needed.
Composition
Business reasons for the
recommended and reasons for the
recommendation
Business benefits and to be Il':alned from develoDment
product
slgmnCant risks the
}evelopm.ent cost and time scale
Investment A ........."';"' .. I
may refer to the overall Business Case if it is Dart of a
programme
The Business Case forms Initiation Document.

Document to standard site the composition shown
above .
.L.L1.L'VU..J.a...,lVU for the Business Case is derived from:

MandatelProiect Brief
Plan (costs)
The customer.
242
Can the benefits
Do the cost and time scale match those in the Plan?
Are the reasons for the project consistent with or
programme sm:lXeJ'lY r
Quality Method
Quality Review with the Executive and anyone aooointed to
business assurance.
243
LY~",ua1:iJ-U!!; Proiects the PRINCE2 Product n ..""riniinn<
Purpose
rrequency defined in the Work the progress
Composition
Date of the cnecKp0mt
_ Period covered by the
on any action from
_~ Products during the
work carried out the
Products to be CODClp!(:rea the next
Risk assessment
- Other actual or Dotential problems or deviations from
agl"eelnellt between and Team

may be verbal or written. It should contain the
any extra data bv the
Team Plan actuals and forecasts

Risk Log
Team member
Qualitv Criteria
Every team member's work covered.
Includes an on any unresolved from the
n1"P,\r1nnc
~._+=1 .. reflects the Team Plan situation.

Reflects any change to the Risk
Reflects any change in a team member's work which has an
on others.
244
~
'::.,
f/JI Quality Method
Informal check by Team Manager and those with Project Assurance
responsibility.
!.l..!
~
.::.
~\\t\*'
(.r .
.....
....
.;..
245
lVliillag:rng Projects the PRINCE2 Way Product De!!"rinnnn!!
Communication Plan
Purpose
The Communication Plan identifies all who
information from the and those from whom the
''''':IULU_" information. The defines what information is needed
and when it should be suonlied.
Composition
Interested as user groups, SU,(:'plliers, VLI..."l,",
i)W...." • •
assurance, internal
Information by each identified
!a~:ntltY of the information ",r",rirl",.
Method of communication.
To the defined site standard for with the above content
The Board
.1 The Brief
The Initiation Document
The Plan
The
Quality
Have all the listed derivation sources been checked?
Has the content and memoa
) Has a common standard been
Has time for the communications been allowed for in the
Plans?
\o4UClmy Method
Review between and those
Communication Plan.
246
vVJl1.Uf:;W.';....l'-J'll Item Record
A record of the infonnation required about a status
... The identifier

...
... Product identifier
... Latest version number.
...
... A descrintion of the life ~rrnT(\1"Iri~t.. to the nrnnnf"t
... 'Owner' of the product

... Person on the 1"Im,ii",,,t
... Date allocated
... or location where the product is
... Source - for example, in-house, or from a third-party
company
... Links to related products
... Status
... holders and users
... Cross-reference to the ...""..."\,,J that caused the to
this nrr><1",f"t
... Cross-references to relevant
... Product Breakdown Structure

... and Team Plans
... Work Package
...
... control
247
J.\Ilanagmg the PRINCE2 Product Del~rilDti,[lIlS
June
Quality criteria
Does it reflect the status of the
- Are all Confilruration Item Records in a secure
location?
Does the version number match the actual
Is the ~~~,,1.~1 information correct?
Do the held bv the match the version number?
248
Product n ....,.rlntl'~n£
Lonnlgurall()D Management Plan

Purpose
whom the will be
Composition
1his forms of the Plan. It consists of:
An of the purpose
A description reference the ,",VLLUj;'u.I.
method to be used.
J..UO"-'<>.5"Lll"'."
or programme standards should be with a
ustification for the variance
Reference to any other with
which links will be necessary
Identification of the Librarian
Identification ofthe levels of product, or classes of
prcldUict that will be controlled under c0!111!~ati(m
A plan of what libraries and files will be used to hold prodUcts

Confumation that the relevant and next files have
been setup.
Details of the come from:

, The customer's (QMS)
products and environment

gaw:Si1UUll structure
vVllJ.,l:)w.....vu software in use or mandated
Quality criteria
n."'''I-''JU.>UJJ..u.u.I,i> are clear and understood both customer and
supplier.
The key identifier for project is defined.
249
the PRINCE2 Way Product oP.",";"""".
method and circumstances of version control is clear.

The with aU the nrMnr.t
"''''IU''"'''''''''U'''' of the purpose

A of (or reference
manall:emlent method to be used.
or programme standards should be with a
.I """uU",,''''Vll for the variance
Reference to any other with

which links will be necessary
Identification 'VVLll"I:;~'"''-''''''' Librarian
Identification of the levels
nrl'Li1n.rt that will be controlled under COIltlg1lll'allOn
A ulan of what and files will be used to

Confinnation that the relevant and next files have
been setup.
250
Managing Projects the PRINCE2 Way Product Tk>" .. riinti,nn"
To record actions or
PRINCE2 documents. It acts as
Composition
title
Date of record
Action or comment
Person res1PollLSlble
date
Result
! Risk
Plan
ChleckpolJat Reports
Conversations and observations

criteria
j Entries are understandable at a later date
nf'T'mlment nature is transferred to the ~nnrnnri
person and date are always filled in
251
lYJ./.'Wd,!;;lli!;; the PRINCE2 Way Product D~~erilrlfi ... n.
Title
End
pf()gr:nrrme management) on
",",',,,,,,,,,,,,,,,, stated in its
the project. It should
schedule
Assessment of the achievement of the nrn,,.rt',,

Performance the planneu
costs
=.; The effect on the vUl!'.="'" Plan and Business Case of
any which were ::Innrnvprl
issues received
V';;;U,",,1"". for t;Ai:1ll!lJlt: I
Statistics for all work carried out.

Post Review date and
Form(at)
To the defined site standard for with the above content
any extra infonnation by the Board
Derivation
The final Plan with actuals
The Initiation Document
Issue
Criteria
Does the describe the
on the intentions
Document?
252
cover all the benefits thai can be assessed at
Does the the meet the

customer?
Quality lUII""'th........
Formal quality Review between and with
Project Assurance responsibility.
253
Product DescripaOnSl
Title
End
Purpose
is to on a that has
the overall
t"nrnn'l",tp'{j situation and sufficient
mt'Om[latlon to ask for a Board decision on the next to
take with the IJH.'I"~'"
The Board use the information in the End Reoort to
approve the next amend the scope,
revised next Plan. or stoo the nroiect.
Composition
Current Plan with all the actuals
Plan outlook
Business Case review
. Risk review
Issue situation
>.JUC<Lll'L v CileCKll1lg statistics
on any internal or external events that have affected
Site report standards the information described above

any extra the Proiect Board.
Derivation
Information for the is obtained from:
The Plan and actuals
The next Plan
The updated Plan
The Lessons Learned
__ Data from the
l-omPlete:Q Work Packal!e data.
254
n ....u~,.lll!;; )J....",,,,,,,j-,, the PRINCE2 Product D""'l"rinfl..n~
Does it clearly descnbe the plan?

Were any modifications described, with their
I Does it an accurate work

done in
Does it give an accurate review of the revised risk situation?
Does it an accurate assessment of the of the
to meet Business Case?
Method
Informal Review between lYL'..........l«a and those with
Assurance resPoIlSib,ilitv.
255
J.u...u ...J!j,J.J.J.l!i I'..,.,,,,,,,,t,, the PRINCE2 Product Descriptions
Purpose
An is when costs and/or time scales for
an Plan are forecast to exceed the tolerance levels
set. It is sent the in order to warn the
Board of the adverse situation.
the
!lJ.V'.U"',O;; an txceJ:lt1on
Composition
A of the cause of the deviation from the Plan
The consequences of the deviation
The available
The effect of each option on the Business
and tolerances
The Proiect Manal!:er's recommendations.
Site standard the information shown above
The information for an nxcepllOD is drawn from:

Current Plan and actuals
and actuals
Deviation forecast
_: Issue
Risk
Board advice of an external event that affects the
256
iVli:1~:W)l, n......:A~+C the PRINCE2 Way Product De!ICriptiJlOS
The reason(s)
risks
A recommendation must be made
Informal review between IV,li:WligCni and

those with
257
lVli:l.lli:l.!!'ill:!; Proiects the PRINCE2 Product n"""";~""ft.
Follow-on Action Kel;onamlenClanons

Purpose
unfinished risks or
Issues to the group with support of the
in its ooemtionallife.
Composition
Date of the recoIlllllle:ndllti()ns;
Issues which were unresolved at the time
that may affect the 1J1UUUo.;l
Any other activities identified for action in the

n"",,,,,tinn,,1 life ofthe _~n"'n"~
Site stand:ll.rd the information shown above
Issue Log
Risk
There must be an for every open Issue.

Issues should have heen closed with an
IJVJJUWJJl~ to FoIIow-on Action Recommendations.
available useful documentation should accompany the
recommendation.
Method
Informal review between Ivlanager and those with
Assurance l"'O'}JUill>!UUJ
258
I
":. :~ ~

:*r" Title
Highlight Report
Purpose
For the Project Manager to provide the Project Board with a
summary of the stage status at intervals defined by them in the
Project Initiation Document.
;:-- A Highlight Report normally summarises a series of Checkpoint
Reports. The Project Board uses the report to monitor 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.
Composition
~,.,1,
~~:,~l~ r Date
Project
§ i;\ ! Stage
'.;:; ~
. .. Period covered
C Budget status
~ C Schedule status
Products completed during the period
Actual or potential problems
Products to be completed during the next period
;. r Project Issue status
~~..
Budget and schedule impact of any changes approved so far in
the stage.
";;'1( Form(at)
Site reporting standards containing the above information plus any
extra data requested by the Project Board
Derivation
Information for the Highlight Reports is derived from:
Checkpoint Reports
Stage Plan
The Issue Log
259
.:: The Risk Log.
Quality Criteria
•. ~ Accurate reflection of Checkpoint Reports
= Accurate summary of the Issue Log status
.:: Accurate summary of the Stage Plan status
',-,
..: Highlights any potential problem areas.
Quality Method
.~
Informal review between the Project Manager and those with Project
~
.l\~'
I'~
'I:~
260
Issue
Purpose
The purpose ofthe Issue is to:
Allocate a number to each
Record the type of Project Issue;
, Be a summary of the Project their and status.
Composition
Request For Off-
Surnmarv ofthe issue

Author
. Date created
Date of last update
Status
Cross-reference to the filed Issue
rt""''''........,'''·nt form with the shown under
Issues may be raised by anyone associated with the at

anytime.
Criteria
Does the status indicate whether action has been taken?
umquelY lUentlIlea, mClUomg to which
Is access to the Issue controlled?

Is the Issue Log kent in a safe
261
the PRINCE2 Product DesI:rinf:iolls
Quality Method
n ..'''' ....,cu irlSPlection and verification the Issues.
262
Title
Lessons Learned Log
Purpose
The purpose of the Lessons Learned Log is to be a repository of any
lessons learned during the project that can be usefully applied to
other projects. At the close of the project it is written up formally in
the Lessons Learned Report. Minimally it should be updated at the
end of a stage, but sensibly a note should be made in it of any good
or bad point that arises in the use of the management and specialist
products and tools at the time of the experience.
Composition
What management and quality processes:
! 1 went well
i I went badly
! I were lacking.
A description of any abnormal events causing deviations.

Notes on the performance of specialist methods and tools used.
Recommendations for future enhancement or modification of the
project management method.
Useful measurements on how much effort was required to create the
various products.
Notes on effective and ineffective Quality Reviews and other tests,
including the reasons for them working well or badly.
Derivation
Information for the report is derived from:
I . observation and experience of the processes
the Quality Log
completed Work Packages
I Stage Plans with actuals.
Quality criteria
Each management control has been considered.
263
Product DelscriiptiODS
The reasons for all tolerance deviations and corrective actions

have been recorded
at the end of each
~" ............".. have been asked for
"~""""au,,, tec:lmiique is included.

Statistics of the success of Oualitv Reviews and other of
test used are included.
264
Lessons Learned
Purpose
The purpose of the Lessons Learned Report is to pass on to other
nm'l~('t~ any useful lessons that can he learned from this project.
An group, such as assurance, who are

reslPQDlSible for the site quality to
and project technical statulaJrds,
use the in the Statistics on how much effort was
needed fOf nroducts can imorove future estiLma:tin:g.
What and processes:

- went well
- went hac: .
- were lacking
• An assessment of the efficacy of technical methods and tools
used
Recommendations for future enhancement or modification of
the nroiect management the reasons
Measurements on how much effort was to create the
various products
Vl1Ulill1to\ deviations to
Issues their causes and results

Statistics on how effective Reviews and other tests
were in error trapping how many errors were found after
products had a Review or
Form (at)
Site reporting standards at least the above information
Information for the is derived from:

Observation and of the processes and tp,.hni",,,.,,
used
265
lV.l.iIDagmg the PRINCE2 Product DellCriptil)DS
edition June
::: ObservatioIl..<; of checks
Performance
End
<>V,,"'..."',,'" situations
Criteria
to the is at the end of each
manaJ~ernerlt control bas been examined

_ A review SDel."1a!lSI lecnmque is illClUueu
Statistics of the success _ of
check used are included
The accuracy of all estimates and plans is included
Details of the effort taken for each are
The success control is reviewed
Quality Method
Informal review at each end lVumager and those
with Proiect Assurance
Formal Review by this group before pre:seDltatllon.
266
the PRINCE2 Way Product DesICrilltiOlllS
Post Review
The purpose of the Post Project Review is to find out:

Whether the expected benefits of the have been
If the has caused any in use;

What enhancement have been revealed use of
the prodUc:t.
Each benefit is assessed for the level of its achievement so
any additional time needed for the benefit to materialise.
UneXJ)eClted side effects, beneficial or which use of the
may have brought, are documented with of
these were not foreseen.
Recommendations are made to realise or benellts. or
counter problems.
Composition
Achievement benefits
Unexpected benefits
Unexpected prc,ble:ms
User reaction
- Follow-on work recommendations
Site reporting standards

Derivation
The expected benefits should have been defined in the Brief
and expanded in the Initiation Document.
General comments should be obtained about bow the users feel
about the product. The of observation will
of product produced but "h.ilWJ.~'1"'"
of use, contribution
and suitability for the work environment.
267
IVll:1lU.t~;m.g Projects the PRINCE2 Product n"""ri"tin<n..
Covers aU benefits mentioned in the Brief and Business

Case.
Covers all "'UOLUO'~i) '"~nr,,,,,~.rl life
- Includes discussionB with reJ:)rellentati of all those affected
the end .....,.r.r\n'C"t
Describes each achievement in a measurable form.
== Makes recommendationB in cases where a benefit is not
a has been or a notential
extra benefit could be obtained.
Is conducted as soon as the benefits and problems can be
measured.
Quality
Review the Business Case and
Issue
268
thePRINCE2 Product Descrintions
d edition June
Title
Post-Project Review Plan
The purpose of the Review Plan is to define for the

Executive how and when a measurement of the achievement of the
_ benefits can be made. The is to the Executive
at the end of the
The plan has to cover the effort to ___ .___.
o Whether the expected benefits of the product have been
realised
I:l Whether the has caused any in use.
Each benefit has to be assessed for the level of its
achievement so or any additional time needed for the benefit to
materialise. Use of the product may have unexpected side
effects, either beneficial or adverse. Time and effort have to be
allowed to document these side effects were not
foreseen. The must include time for on how
to realise or benefits, or counter problems.
Composition
.. How to measure achievement exPected benefits
.. When the various benefits can be measured
.. What resources are needed to carry out the review work
.. A to other headings that will need to be covered such as
user reaction.
Derivation
.. The Business Case
.. Discll..'ilsion with the users and product
.. review is as
but the Executive nrc,rln"""
the has finished.
Quality criteria
.. Covers all benefits mentioned in the Business Case.
.. Describes a suitable for measurement of the U"'J.1"'~''''',
togetlll:r with reasons
269
Product n",...yojinti,nn~
• Identifies the skills or individuals who will be needed to carry out

the measurements
• Is realistic in terms when to the antlcl~)ate:d
benefits.
270
~ .
....;..J
~
~i';,
Title
Product Breakdown Structure
Purpose
To show all products to be developed and quality controlled. To
understand the content and function of all products to be developed
Composition
, ~ ,.
Top-to-bottom diagram showing breakdown of all products to be

developed. External products must be clearly distinguished from the
products developed by the project. The usual PRINCE2 convention
--. is for project products to be shown as rectangles and external
products as ellipses.
Some products are resulting from the integration of other products
\;:: (such as a car chassis sub-assembly). If the integration requires
extra development or quality control activity then the 'super
product' must be distinguished in some way (e.g. a line across the
,.;.
top-left corner of the product box.
Derivation
~\i_" .,
Proj~ct Brief
/'
Project Quality Plan
Quality Criteria
rl Are all external products and project products clearly identified
and distinguished?
I I Is the PBS consistent with the Product Checklist?
Are genuine super-products (i.e. non-bottom level but requiring
a separate product description) distinguished from convenient
product groupings (memory joggers)?
, .'
Are management and specialist products identified and

distinguished?
..... , L Can product descriptions for the bottom level products be
written without further decomposition?
I ' Have enough bottom-level products been identified to meet
management control requirements?
Will all the products identified fulfil the business need?
271
Droducts been identified that meet the needs of
assurance as described in the
nwnblmllig of each product and consistent with

U'U'UU'~L in the hierarchy?
of external
272
Product DescrinDon!l
Title
Product Checklist
Lists the to be produced within a T"",FTn/or with

status
UPUi1tt::Uat agreed intervals by the Manager and

the Project Board to monitor progress.
Composition
Plan identification
Product names identifiers where aOtlro[lriate
Planned and actual dates for:
• draft product
check
Form{at)
Standard form with the defined under
Extracted from the Plan.

Quality Criteria
Do the details and dates match those in the Plan?
Method
Informal review the Plan.
273
thePRINCE2 Product n".~rI ...tI"...
Product Ue!,CnlPtlO,n
To define the information needed to describe each product to be

created the
Composition
_ Title
An of the purpose of the oroduct

Composition
A list of the various of the e.g. of the
document
Form or format
'ORIOUI\;[ should look like. If it is a document. the name
";;;1l'1J'''·'''' to be used
Derivation
The sources of information for the oroduct.
Criteria
What measurements the must meet.
Method
Qualitv is to be
Form(at)
,.1P1"'l<aTftn"...,t form with the headings defined under
Plan
Ultimate recipient of the PlUUUI;L.
274
Quality Criteria
Does it contain information under all the headings?
Is there more than one purpose?
Has the end user been involved in its writing?
Quality Method
Formal Quality Review.
-....
-.
~'
.....
275
Dr~;""+" the PRINCE2 Product np...rinlinn
edition June
Title
Product Flow
Purpose
To show the sequence and
Ge]peIIGe:nCles between those products, lIlcmrung
external nrf"!l1t't"
sequence from
de])enideltlci1es between those
pruUUl:US. Arrows indicate between products. External
n""rllll't" must be clearly distin:gWsh€:d
The normal PRINCE2 convention is for _ _
nr"rllll't" to be shown as and external products as 1;;1l1mil;;lS.
Derivation
and Product Breakdown
Criteria
Are all external identified and the ...... I-"'"'-'~."''-'".'"''
understood?
Are all bottom-level on the PBS identified on the
Areal! ""~"'r_~rnrh".,t,,' identified on the PBS shown on the

PFD?
Are all products identified in the PFD identified as proGucts on
the PBS?
Are there any without GelpeIJlae:ncles
deillemienicies been identified at a level suitable to that of
of which the PFD is a
aq)en.GellClles consistent with the derivation fields
product of all the p~V''''U''''''
276
~,
'I
Managing Projects the PRlNCE2 Way Product Descriptions

~
Title
Project Approach
Purpose
Defines the type of solution to be developed or procured by the
project. It should also identity the environment into which the
.... product must be delivered.
.. Composition
~
I Type of solution., e.g.

Off-the-shelf;
roo.
... Built from scratch;
Moditying an existing product;
Built by one or more external suppliers;
Adding to/moditying a product developed by another project;
Built by company staff;
,, :13..
Built by contract staff under the supervision of the Project Manager;
-= Reason for the selection of approach, e.g. part of a programme
i"It'
;2\ C Implications on the project.
Form(at)
Standard department form with the headings defined under
'Composition' .
Derivation
I Project Brief;
L._Design Authority (if part ofa programme);
r Available solutions on offer
- ·· r Quality Criteria
Must support the business strategy;
"""
Must relate to the product's operational environment;
.... Must be achievable within the known project constraints;

The approach implications must be acceptable to the programme (if
"""X>'
the project is part of one).
277
Managmg the PRINCE2 Way Product n""""lI'Itinn"
Formal Review the business any other

~ ..... ~~-..; --
and the ooerational environment.
278
Brief
To the reasons for the

eXflectatiC)ns, and any limitations
Composition
The list of contents that should be tailored
to the and environment of each
explaining what the needs to
achieve:
deliverables and I or desired outcomes

any exclusions
constraints
interfaces
I Outline Business Case
reason for the
of how this project business strategy,
or programmes
: Customer's ....... 1:. n
''''I-' •.a.u,.... Criteria

known risks.
If earlier work has been done, the refer to
dO(:wIlen1t( s) such as Outline
Form(at)
standards at least the information
Mandate.
If the is part of a programme, the programme should
provide the Project Brief.
279
Product fiGc.!",pjnt:nft"
users.
Any to the material contained in the
Brief will thus need to be referred to or programme
Quality
Does it accurately reflect the Mandate?
Does it form a finn basis on which to initiate
the (IF))?
Does it indicate how the customer will assess the acc:epltabili
of the finished product(s)?
Method
Review between Project Manager
process 'Start the
280
1"'. ..1.U.<l.l!;1llt\ Proiects the PRINCE2 Product Descriptions
Initiation Document
Purpose
To define the
To fonn the basis forthe ultimate assessment of the
success and the
There are two of the document:
To ensure that the project has a sound basis before the
Project Board to make any commitment to the project;
To act as a base document which the Project Board and
M~tna:ger can assess progress, evaluate change
qu~;:sbons ofthe
What the is aiming to

Why it is to achieve it;
Who is 1nvl'Iivpfi in the project and what
How and when it is all to l1"pP<Oll.

The list should be seen as the information needed in order
to make the initiation decisions.
Background, explaining the context of the project, and
taken to arrive at the current of requiring a
1"",.i.,.,~1t Definition, what the project needs to
achieve. Under this may be:
scope
Constraints
Exclusions
Defined method of approach (if applicable)
Interfaces
281
Product I}""~rintijln"
is being
lro'9nii"llltinn ...h .....h ..·., ....~,u.UcU..15 the Project
VU'iIllULJ Plan
t::XIJIl1.IlllIJlg how and when the activities of
will occur. (For details of the Plan content

see separate Product
how control is to be exercised within
renorting: and monitoring mechanisms
Exception process, the to be followed for any significant

deviations
Initial the results of the risk
eXPJllIIWlg how it is intended to deal with

the consequences identified serious risks
materialise
::J down how the various
elements and by the
are to be filed and retrieved.
Form(at)
Site report standards
Customer's or management standards

Customer's control reqUln~me:nts
of the information should come from the Project iVlaname,
enl:m:n4~ed. in the
Quality
Does the document reDresent the ~ ......;",,,.?
achievable that is in line with
or overall programme needs?
282
Product~cripnons
orll:anisation structure with names and
Does it
that can be lIniHeIDe:tllte<!.
business risk and ,,.,,.,,,1"10<>""'
Has everyone named in the structure received and
description?
Does the
Are the internal and external and lines of authority

clear?
Do the controls cover the needs of the
!VUIDCijl:eI and any Team Mamal~en;?
Do the controls Assurance
. , Is it clear who will administer each control?

Quality Method
Formal Review between the and those with
Assurance reSJPonsibillity
283
iua.ua""ili!5 >"'!V\'''I'T'' the PRINCE2 Way Product Descriptions
Title
Project Issue
Purpose
To record any matter which has to be to the attention of the
and reauires an answer. A Proiect Issue may be a:
Question
Statement of concern.
Composition
Issue number
- Author
. Date
Class for'v.LL<LU.5"" o:n-s:oel;lfiicarlon
. Description of the issue
Priority
_ Impact ",.,~.h",,,,
Decision
Signature of decision ill......"l,"
Date of decision.
ofform with the headings shown under

'Composition'
Derivation
Is the statement ofthe clear?

Has all necessary information been made available?
Have all the been considered?
284
Product Descrilptions
Issue been correctly

Method
Check the person for the Issue
285
lVlanagmg the PRINCE2 Way Product Oe'lcrintilll>ns
Mandate
Purpose
Mandate is a tenn to describe an initial for a
which may further work to turn it into a
cornp()Sitlon of a Mandate will vary (1I,.;WIUill~

and also the environment in which
manuare IS geneJra1Jed.
is a list of contents which would make
.LUau"""", and should be tailored to suit the
actual mandate may have much less infonnation.
The CUlSiWIuell and any other known interested

parties.
Outline Business Case
Constraints
- Interfaces
An estimate of the
A view of the risks the
An indication of who should be the Executive and
Reference to any associated nroiects or oroducts

Form(at)
be in any fonn
286
Manaf.l:mg Drni .. "o~ the PRINCE2 Way Product DesCriOtiODS
Derivation
A Mandate may come from anywhere, but it should come
from a level of management that can authorise the cost and resource
usage.
Criteria
Does the mandate describe what is required?
Is the level commensurate with the w.ttJl,;llJi:l.U::U
risk and cost of the ..,.p".i.."o'/
Is there sufficient detail to allow the of an
Executive and
Are aU the known interested identified?
Quality Method
Informal review between and the
mandate author.
287
Product n""",.-i",tl",,,.
Title
Plan
Purpose
A which shows at a level how and when a
are to be achieved. It contains the
the activities and resources reclWn:u.
the BUsiness Case with pllWilCU costs, and
luenunes the 1.1.IJ:lLUa,O"lll<iJLH control
The Board uses it as a baseline which to monitor
progress and cost by
It forms of the Initiation Document.
Composition
Plan dec""';nt-i",., a npo""';nti"n of what the
covers
pre··reQlwsl,tes, cO]J,tauung any fundamental
must at the start of the and which
for the to succeed
External dej:leU(lenl~les
Project level Gantt or bar chart with identified management
level Product Breakdown Structure

level Product Flow Di~lg!'~u:ns
level Product De.scrilpti1ons
level network.
financial
level table of resource reQum:me'nts
est(~dl!lssign~:d S'PleCU1C resources.
Form(at)
Gantt or Bar Chart plus text
288
~
{,r. (revised edition June 2005)

,l\~ Derivation
Project Brief
'1,'\
rjI'\'
Quality Criteria
: ~ Is the plan achievable?
• ~ Does it support the rest of the Project Initiation Document?
Quality Method
-."
Formal Quality Review with Project Manager and those with Project
~~~(~
,\:~
.~~~~
~'
~~
-"
-c-..,.,
289
10.....
Plan
The purpose is to define how the sunnlier

that meet the Customer's
standards.
Composition
control and audit processes to be aoolied to
control and audit process reauirements for sneClans

work
criteria
- Reference to any standards which need to be met
tools to be used to ensure
The Plan is of the Initiation Docwnent.
Customer's Mandate and/or Brief

COlrpolrate or programme management
Does the . define ways to confirm that the

Customer's Expe(;ta1lOIIS win be met?
Are the defined ways sufficient to achieve the reQuired
Are reSl)OnSlblllt1(~S
mOletle:noentofthe
Does the
290
"Y~lll.!) Prolects the PRINCE2 Product n...iCrintil~ns
Quality Method
Review between and whoever is the
on behalf ofthe customer.
291
Title
Quality Log
Purpose
To issue a unique reference for each quality check or test
planned.
To act as a pointer to the quality check and test documentation
for a product .
.~ To act as a summary of the number and type of quality checks
and tests held.
The log summarises an the quality checks and tests that are
planned/have taken place, and provides information for the End
Stage and End Project Reports, as well as the Lessons Learned
Report.
Composition
For each entry in the log:
Quality check reference number
- Product checked or tested
Planned date ofthe check
Actual date of the check
Result of the check
Number of action items found
Target sign-off date
Actual Sign-off date.
Form(at)
Standard departmental form with the headings shown in
'Composition'
Derivation
The first entries are made when a quality check or test is entered on
a Stage Plan. The remaining information comes from the actual
performance of the check. The sign-off date is when all corrective
action items have been signed off.
292
!V~;!; the PRINCE2 Way Product n ..... rintln1l~
Quality r.rit'Ari!2
Is there a in which will ensure that every
check is entered on the
Has for the 101! been allocated?
Quality Method
"""C~Wi:l.l checking should be done those with Assurance
for the customer
"""IJV''-''''''JLU'J' There may also be an
nTt~V1,rlPT'
an maeD€~naent assurance function.
293
p.,..... ;".I'fi:< the PRINCE2 Product nACIi"1"'i'f'\f-:nne
Risk
The purpose ofthe Risk Log is to:

=-= Allocate a number to each
Record the
Beammrunruyofthe thew and status.
Risk number
Risk
Author
Date risk identified
Date of last risk status update
Risk description
Likelihood
Status
form with the shown in
Derivation
Business risks may have been identified in the
should be sought initiation. There be a check
for any new risks every the Risk is reviewed or a new
~~HU'u.u.L'J at each end assessment. The Board
to constantly check external events for risks.
Quality ~ri+ari~
Does the status indicate whether action has been/is taken

or is in a contingency
294
,-------------
Managing the PRINCE2 Way Product Descriptions
Are the risks identified, to which product
refer?
Is access to the Risk controlled?
Is the Risk leI! kent in a safe
Are activities to review the Risk in the Plans?
Has for lllUllUU1 the risk been identified and
documented?
Quality Method
.......'1',...""'" review the person who has business assurance
295 I
I Managing the PRlNCE2 Product n ..~"rintl" .."
I (revised edition June
Title
Stage Plan
Purpose
Identifies the that the stage must produce.
Provides a statement of how and when a are
to be achieved.
Identifies the stalle's control and ,.",,,,,,.-tin ... and
Provides a baseline alZalnst which progress will be

measured.
Records the tolerances.
""I>'''''U.'''''' the controls for the and the resources
needed for them.
Composition
Plan De:)crilPtion;
Plan Pre:reqlllsites
External U"'I-'CJJlU<Jl1""""',
Tolerances
How wiU the be monitored and controlled?
~h""r,,, ...
identified resources, activities. start
a Gantt or Bar
Financial
Table of resource requirements;
Risk assessment.
Product Descriptions for the major 1J1l'UUII,;I.lS,
Form(at)
text
296
Plan
Based. on resource
Is the achievable?
Do any Team involved in its operation believe that
their is achievable?
Does it the Plan?
Does it take into account any constraints of time, resources and
Has it been taken down to the level of detail necessary to

ensure that any deviations will be recognised in time to react
within the stage tolerances, and within the
"''''''''M'~' 'floats'.)
Has it been developed according to the planning standard?

I Does the Plan contain activities and resource effort to
review the Issue
Quality Method
Review the and those with Assurance
297
lVumagmg the PRlNCE2 Way Product n"...rlntinn"
Work
Purpose
A set of instructions to one or more A"~IU.J..i."'" orclducts
the to a Team Manager or team member.
r u •.uVI.l',ll the content may vary
between the and the recllplent

it should cover:
A summary of the work to be done
J Product of the to be orc,uwcea
::J Standards to be used
Product interfaces
interfaces and liaisons
checking to be involved
Work return arr:fI.llll:ernlen1ts.
This pro(luct
performance assessment.
",,,,,JU,,. under a contract is out the work and the
of the customer the Work
racKage written document.
Derivation
There could be many Work authorised each
The creates a Work from the Stage Plan.
Quality
Is the reQ1Ulfe:d defined and llnrlP1"<!tnntl
by the resource?
298
Managlng the PRINCE2 Way Product DlI!llCriotij}JI~
(TP'vi",..A edition
. . . . . . . . . . . . ~~--------------------------------~
Is there a Product Description reauired with

identified and nn~~+~1...1
Does the Product match up with the other Work
documentation?
Are standards for the work agreed?
Are the defined standards in line with those to similar
Have all necessary interfaces been defined?

Do the Y'I"nmtin
OTPf'mPnt between IVll[lJl:l.glef and recipieIlt.
299
the PRINCE2 Forms
Forms
of the forms you will need in a

you an idea of what to in
be structured. Feel free to use
them to suit your environment.
text in italics is there to you on what to put under a heading

text in bold could form a entry in your document
300
'"""
Managing Projects the PRINCE2 Way Forms
Business Case
Purpose of Document
This document is used to justify the undertaking of the xyz project
and is based on the estimated cost of development and the anticipated
business benefits to be gained.
It states why the forecast effort and time will be worth the
expenditure. The on-going viability of this project is to be monitored
by the Project Board against this Business Case.
Note that this document is at afairly high level when first produced. It
should be enhanced during the Project Start-Up stage and finalised
"'" during the process 'Initiating a Project '. From then on it should be
maintained to reflect any changes outside ofagreed tolerances.
Reasons
:{:/ The reasons for the project should be stated here and derived from
information contained in the Project Mandate / Project Brief
Options
~):~~
This section should briefly describe the various options that were
considered to achieve the desired result. The chosen option should be
,~~~~ identified, together with a summary ofreasons for its choice. Options
should start with the 'do nothing' option.
Benefits and Savings
This section should indicate what the benefits and savings are and how
they are justified. Much ofthis information will be derivedfrom the
Project Mandate / Project Briefand the Customer.
Risks
The section should begin with a statement ofwhat the risk tolerance or
appetite ofthe project is. This section should list the key risks, if any,
facing the project with a briefassessment oftheir probability, impact and
proximity. In order to keep it brief, reference can be made to extra
information in the Risk Log.
Cost and Timescales
This section should be presented in the format ofa Spreadsheet if
necessary.
Investment Appraisal
301
'-"
Forms
Checkpoint
The actions from
Products Completed
A descrintion of the oroducts comoleted since the last chedrnoint
Quality
The Quality checks this
Risk Status
New or modified risks
Problems
Actual or I deviations from encountered in this
Products to be completed in the next period

The nroducts to be comoleted the next
302
Project Report
Purpose of Document
The purpose of this document is to enable the Manager to
to the Board on how wen the has performed
Pr."...,..,. Initiation the
schedule and tolerances. the revised Business Case and
the final version of the Proiect Plan.
MJJn"""~sections shcmld be derived from contained in:
- updated Project Plan
Initiation Document
- Business Case
- Issues
A statement and their resoective levels

achievement.
time and cost, mCluamj!

tolerance levels.
Changes
Number of Approved Time Cost
The effect on the _ The effect on the Ul1~

issues received Plan timeframe of Cost
vlll:l.lJ.c;o;;S that were
~"'~..n·".. tl during the
Impact
The total ofapproved the and HP:tlpTlt<
Initiation Document.
303
Quality
all work carried out and confirmation that
customer have been met.
the realisation
nel1entshave not been achieved at this time, a
should be Dlanned (see
Post Project IilA'ViA'IN
The date nrnnn~p.d review.
304
lYli1.U.l1gWg Projects the PRINCE2 Forms
Stage Report
Summary
This document is a report of the of the
It descn"bes what has and the overall effect it
on the project.
The End should be as succinct and Its
purpose is to
in the and
contain the detail ofwhat is to
section is to summarise the contents

impact, U'l'l:,....,"~()lll..,rl nrrlhl.'m~
Stage Details
a comparison actual results
the The section is broken
A tabular can be used as shown here:
N/A
Effort
ys)
Cost (£)
Product Status
All that is that have been
delivered e.g. "All were delivered within the
and schedule tolerances". Anv vroducts not delivered should be
_ have not been delivered or there nrnm..,m~ then more

detail should be sUDDlied here.
305
thePRlNCE2
-'---
edition June
Issue
The overall number Issues dealt with the can be
nr..'~"rlT"'n as a table similar to the one shown here:
Received Actioned Carried

Forward Forward
...."'u,,"''''. OS =
Project issues Board decisions should be listed and
BRIEFLY described.
Prnla",t Management Ke-A!SSl;tS~imlem
section is to illustrate the impact stages
Business Case and Risks. The section is broken do.vn
Prl"IAlr'!;T Plan Impact

A tabular reDresentation can be used as sho.vn here:
Forecast I Difference
N/A
Business
.n..'"n,.., any changes to the caused the C01nf)J'ete'G
or that the Business Case have not changed.
306
~
llle7'ltijry tiny changes to risks arising the completed
and any new risks that have arisen. Refer to the elements ofthe
Plan, which are there to counter or take advantage ofany
Interim Project
section is to document any lessons the
An the ",""""UJJ'l'. C:om!lIli1ttee
closure. section will contribute to the StCeriIll~
un.ae1':S'UJrnaml! ofthe Next infnrmntirm
for the Project Manager
~
307
UJ.<lJ.l"!:iLU15 ,""""""""rot. the PRINCE2
Exc:ep1tion Report
Purpose of Document
The purpose of tbis report is to bighlight to the P""'""t
one or more tolerances for an or
forecast to be exceeded.
Deviation
laenmry the from which the deviation is forecast. Describe the cause
current
llI.v.',",U.lllJ<; scope and
Describe the consequences of the deviation.
Options
Describe the available to resolve the
each option on the Business tolerances.
Recommendation
The recommendation on the best to proceed
with.
308
Forms ,
The actions from nn:VHJUli
Products
A of the completed since the last checkpoint
The aualitv checks this
Status
New or mod.i.fied risks
Actual or potential I deviations from encountered in this
Pre,ducts to be In the next

prod.ucts pllamled to be the next
Issues Actioned I Cost of Actioned

Issues
309
J
Managmg the PRINCE2 Forms 1
of
Issues
310
n ....~,ll.l!\ t'mlects the
June
Brief
Introduction
The purpose section is to describe the It will
include a statement o/the general a as well
as n",<:rrintin'fl
The the level in the document should be given. The

level may depend on how much information is avaiJable at the time
pn)aU!ClI'I'2 the Brief, or it may depend on the level reauested. A
will less detail than a
This dooument descnbes the scope and outline

Business Case of the
section is to put in
It will contain a
Droiect and relevant historical
There should be a
that is to naar",,,!':
business strategy.
1(1'.:ter~,,:i>.~
should be made to documentation rather than
reproducing it.
Project OblectlVEtS
e.g. "The New PC are:

- to make available a cost effective PC to
customers bv 31 January 1999;
DrtlCUrelnellt method that takes advantage
.t:tnHtf" ..al'<:ntinPl to and deliverv times.
In order to do will deliver nrnaUf'i<: a~!s/~rl'n,~a
"
311
/
nmducts that will be created, or
In essence, the deliverables in the

boundaries It may be necessary to state things that the
will not create, or remove, reasonable asJiunwtlOn
could be made that the Droiect will, in fact, include them.
Outline Case
information known or mandated about the timt>."rnlp and cost

should be stated,
nHTn·,n.lilC n:rnil?cts. a and investment
nnnrniSial s:htlwinO' rtl.<:t<: will be
may have
l7I(.:tUttea here.
statement is
.<:I?rlar,atl? document the Business a

re1j~rel'Zce
to it will be sufficient.
accrue from nrndtJrt<: or, more
materialise throuflh operation
Constraints
naira~rranh is to describe the constraints within which
I1nomtp Constraints such as those listed below should be
• limitations imposed
imniementation or
or
• ministerial
312
Formlll
• limit on resources;
• limit on costs.
restrictions management or technical) on
frp,odnJ'lf to manoeuvre must be recorded. :
I'l'rtll~~ Interdependencies
TrlIlrJ'W1rJO informatiD1I. as is
,,.,/,1'111,..' name;
"...,~rh.I"'f. dependent on it;
• who is responsible for supplying or producing
• when it is eXI7eclted:
• when it is "AI7tli,eDd
As well you should consider such as:
to eristi1'i!2
conformance to eristing jUnctions
• customer
Interdependencies
interdependencies that will exist between the
have been delivered and those
"I",,,,',,,,,..t. operational systems or line ma:nal'!er1:lenl tw:ICtiJ,)1L~,
may depend on the products
int~!rd~~velrtdenci,es
should also be identified.
313
overall quality ext)ectati(ms
the success
Criteria should be measurable af!ainst some kind
include:
delivered on
delivered to cost;
rull!cn,omu r,"'nllir'Pm,"'m'~ met;

ac/:eptea by customer;
~o,,..,,,-it1, and control.

Key
lurpose section is to list and describe any known risks to
Business Case and to
~_.~;n"~"" the
countermeasures needed to eliminate or minimise For each
risk there should be:
Risk A descriDtion ofthe risk.
"occurrence
A t/p"rnntinH consequences risk Uf.;.uun ~
Counter thoughts on what could be done to reduce the

chances ofthe risk occurrinf! or to minimise its
does occur.
The overall risk to which the or exposes
the company should also be
Plan
There may be an estimate
study. it should be r-r.>'Ih>'WIorl inclusion in this
314
or programme mc,ma:1!"eirne;nt
I...,UrD{;I7are
what tolerance is to be allowed to the

schedule. is no earlier estimate
senior may have set the tolerances. This
stated
Document.
.
::i
:;J
315
Project
'Issue Log No: Date Raised:
Author: IClass: Status:
I~~~··t'~vu.
Technical Impact
Business Impact:
Priority Assessment:
Decision: Authority: Date:
Allocation Details (if
Date Allocated: Date .
316
the PRINCE2 Way Forms
Purpose
This document a statement of how and when the
objectives are to be by showing the
and resources for the stage.
Define the purpose of the plan and describe its basis and fonnat.
Every should be made to keep the plan as brief as possibJ.e.
Plan
A.
Products carried n.,.",...nnlIH stagers) should be h{"" .. nl(;bA

together with their (scttee-tule and resource) on the current
and the
A.ny unUSUIJl events or situations which have influenced the contents
the plan should be described here.
Tolerance
Tolerance
may
dates.
Controls
the level o/the management controls that are to be
applied during the is no change from the Plan then
a statement confirming this is sufficient. Controls enable the
appropriate level to:
.. ensure that the is on schedule
.. ensure that the is within
.. ensure TJrDdtlt!ts are delivered
.. ensure oromems are antiCipated
317
the PRINCE2 Forms
edition June 2005)
• ensure that is controlled and that nrnd"rt status is
known
• ensure that risks are mCInQ!gea
• decide upon any necessary corrective action
Planning Assumptions
State the the stage process. If
there is no Plan then a statement this
will be sufficient. Mention the which the will upon
the stage or assumes are in place when stage
L>'....u ....• .. Forecast
A oUhe expected oUhe Stage Plan on the overall
Project Plan Impact

A tabular can be used as shown here. There is quite a
lot of detail in tbis table. to include as much of it as possible.
H nla I J
L nla M N I
0 P Q R I S
T I U I w
Table entries are referenced below (A to and their contents

eXI>laiinetii. Where an entry is not it is marked in the table
"n/a" .
• A the End Date determined
initiation and documented in the PID
• B End Date that is fn ..orn~t as the result
Plan
• C the between the Planned and Forecast stage
End dates in days. weeks or months
318
Managing Projects the PRINCE2 Way Forms
• D the original effort for the stage determined during
project initiation and documented in the PID
• E the total stage Effort that is now forecast as the result
ofpreparing this Stage Plan
• F the difference between Planned and Forecast stage
Effort (D - E)
• G the difference between Planned and Forecast stage
Effort (D - E) expressed as a percentage ofthe Pla1l1led stage
Effort
• H the original cost for the stage determined during
project initiation and documented in the PlD
• I the total stage Cost that is now forecast as the result
• J the difference between Planned and Forecast stage
Cost (If-I)
• K the difference between Planned and Forecast stage
Cost (If - I) expressed as a percentage ofthe Planned stage Cost
• L the original Project End Date determined during
project initiation and documented in the PID
• M the Project End Date that is nowforecast as the result
• N the difference between the Planned and Forecast
Project End Dates in days, weeks or months
• 0 the original overall effortfor the project determined
during project initiation and documented in the PID
• P the total actual Project Effort up to the end ofthe
previous stage
• Q the total Project Effort that is now forecast as the
result ofpreparing this Stage Plan
• R the difference between Planned and Forecast Project
Effort (0 - Q)
• S the difference between Planned and Forecast Project
Effort (0 - Q) expressed as a percentage ofthe Planned Project
Effort
319
1V1anagmg the PRINCE2
edition June 2005)
,. T the overall determined
initiation and documented in the PID
,. U the total actual Cost up to the end
,. V the total Cost that is as the result

'nr/marino- this Plan
,. W the between Planned and Forecast
Cost J1
,. X the between Planned and Forecast
Cost J1 exvressed as a lJercentafle o(the Planned
Case
laenmy any Cnc.mfljftS
Plan or t"n.,n,.."
Plan
Product Breakdown Structure - See AppendlX
Product - See 2
Product Flow Diagram - See ADPendix 3
Gantt Chart - See ADDendix 4
Table of Resource On'11-1""JI:l'f"V'l,o,,..,tt:< for - See Aopendix 5
INDEX
Baseline ................................. 184
Customer ............................ 140 Business case ........................... 90
U}:'eI<ltie,n and Maintenance Business Case ..... 4, 117.
........................................ 140 304
69
172
...............37 L.llall!!C Control ..................... 168
Au1tl1011.SUlg a L.llt:CKPUlIlL ............................ 142
,UUJ.orl:SlIlg Initiation .............. .36 137, 305
Closing a Proiect ....................... 9
320
.:.'~::v
IManaging Projects the PRINCE2 Way Index
:~
~"' Closing A Project ..................... 74 Follow-On Actions .................. 77
Communication Plan .............. 246 Giving Ad Hoc Direction ........ 40
~"
Configuration Librarian ......... 169 Highlight Report .... 130, 259, 312
configuration management... ...236 Reporting Highlights ........... 53
Configuration Management .... 11, Initiating a Project ..... 7, 136, 175
140,177 Initiation
Controlling a Stage ..................... 7 Stage Plan .......................... 129
Controlling A Stage ................. 44 Initiation Stage ........................ 22
Controls ..................... 10, 30, 116 Issue Log .. 77, 79, 133, 138, 140,
'21.. Corporate/programme 175,261
management ....................... 101 Lessons Learned Report. 79, 134,
Customer Acceptance ............ 134 265
}~?:' Daily Log .......... ............ 139, 194 Managing Product Delivery 8, 59
Decommissioning..................... 75 Managing Stage Boundaries 8, 65
~
Directing a Project ..................... 7 Off-Specification .. 169, 173, 194,
Directing A Project ................. .35 267
End Project Report. 78, 132, 252, Organisation .............. 10,97, 175
\~\;i~) 306 SUI ...................................... 14
end stage assessment.. ............ 131 SU2 ...................................... 16
.$.,.... Reporting Stage End ............ 71 SU3 ...................................... 18
end stage assessments ............ 122 Plan
End Stage Report .......... 254, 308 Designing a Plan ................. 81
Estimating ................................ 85 Narrative ............................ III
Exception Plan ........ 39, 113, 131 Planning ........ ....................... 9, 80
Producing an Exception Plan Plans ................................ 10, 107
.......................... ........ ... .....72 Post Project Review ...... 133,268
Exception Report ... 130, 256, 311 Post-Project Review ................ 77
Executive ................. ...............223 Product Checklist ...... 83, 89,274
Filing ....................................... .31 Product Descriptionl48, 203, 275
Follow-on Action Product Descriptions ............. 178
Recommendations .............. 258
Product-based Planning...... ..... 83
Follow-on Actions .................. 133
Product-Based Planning ........ 203
321
Laging Projects the PRINCE2 Way-- Index
. ..,
Project Approach ..... 20, 136,278 Quality Review...... 169, 175,209
Project Assurance ...................233 Release Package ................ .... 190
Project Board ......... 102, 170, 220 Request for Change .... ........... 171
Project BrieL.. . 19,95,129,137, Request For Change ...... 169, 295
280,314 Reviewing Stage Status .... ....... 51
Project Closure .........................42 Risk.... ............ .......................... 10
Project Filing ......... ................. 193 Risk. ..................... ... ................. 28
Project Initiation .......................24 Risk
Project Initiation Document....32, Updating the Risk Log ........ 70
129,132,282
Risk
Project Issue .... 96, 168, 285, 319
Analysing Risks .................. 87
Project Issues .......... .................. 77
Risk...................... .................. 117
Capturing ............................. .48
Risk........................................ 152
Escalating .............................55
Risk Analysis Questions ....... 163
Examining .......... ..................50
Risk Log .. .......... 77, 79,138,297
Project Manager ............ 102,229
Scheduling ............................... 86
Project Mandate ..... 95, 127, 129, "~'.;,~
287 Senior Supplier .......... ............ 227
Project Plan .. ... 27, 110, 117,289 Senior User. ............... ............ 225
Updating ...............................68 Stage Plan ...... ........ 111, 299, 320 )~
Project Quality Plan ........ 25,291 Planning a Stage .................. 66
c
Project Support ...................... .236 Stages .......................... .......... 117
Quality ..................... 10, 103, 145 Starting up a Project.. .... 136, 176
Customer's Quality Starting Up a Project ........... 7,12
Expectations ........ ...... ..... 136 Taking Corrective Action ........ 54 ,..:...
Customer's Quality Team Manager............ ... 102, 231

Expectations ................... 127
Team Plan .............. 113, 137, 142
Project Quality Plan .......... .147 'Oi.J
Timesheets ...... ........... ....... ..... 143
Stage Quality Plan .............. 148
Tolerance ....................... 124, 129
Quality File ... 133, 137, 138, 149,
Work Package .. ..... 137, 141, 301
174,195
Accepting ............................ 60
Quality Log .... 79, 142, 149, 175,
293 Authorising .......................... 45 .~,
322
i/;:.
I Managing Projects the PRINCE2 Way Index
Delivering.. ...........................63 Receive Completed Work

' g ...... ......................... 62
Executm Package............................ 56
ru
~ .'
323
Colin Bentley is the foremost author ofbooks
on PRINCEZ. His
books have been used as explanatory texts
on the method for
some years and are acknowledged as preferred texts. (‘olin has a
wealth of background experience and skills that he brings
to his
writing on project management and PRINCEZ. He has been
project manager since I966 and has managed projects in a
a range
ofdimensions and in several countries. He has been working
with PRINCEZ, PRINCE and its predecessor. PROMPT ll, since
I975 and was one ofthe team that brought PROMPT ll
to the
marketplace.
Colin wrote a major part oflhe PRINCEZ manual and is the
author ofany revisions to the PRTNCEZ manual for the CCTA.
He is the Chief Examiner for The APM Group, which
perfomis
the quality assurance role world-wide for the market in
PRINCEZ, under an agreement with the CCTA. In that role he
currently sets and marks the examination
papers in PRINCEZ for
The APM Group and the CCTA, and is responsible for the
assessment oftraining materials and new trainers in the method.
He has had over twenty books published, lectures widely
on
PRINCEZ and has acted as project
management consultant to
such ﬁrms as The London Stock Exchange. Microsoft Europe,
Tesco Stores, Commercial Union and the BBC.
ISBN 978~t')J)S}9l07A(y-2

PRINCES 2 Revised Edition 2005

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

PRINCES 2 Revised Edition 2005

Uploaded by

Copyright:

Available Formats

(Revised edition 2005)

4th edition Nov 200S

© Colin Bentlev Nov 2005

First in 2001 by:

Protec, The Old Boathouse, 12 Bank Rd, Hill

nT'Pc.....t" the revised version

me'thOIi10ilogy for made

Me:tbcldS) set ofIT

and the Far East.

• The method is repeatable;

maintained by the Office of Government Commerce, so use of the

those on the assurance

Websites with more information are and

PRINCE2 is a scalable, flexible project management method, suitable for \.

Managing Projects the PRINCE2 Way Introduction

PRlNCE2 offers a set of Pr~s_ses that provi.4~ JL@lltrolled.start, - ~~~~

'l CHANGE BUSINESS

Figure Ovl PRINCE2 Componen.!,L

The of project management are described in processes, vvhich

,End SllIge R_rt

run under PRINCE2 vvill need to address each of these

fiUUlUIJlilllg the of a Plam amd Business Case for the

remains justifiable at in the

This is intended to be a very short pre-project process with five

• and the project ma:na~:emlent

a there will be mamy of:

progress information about that

~ noting useful lessons in the Lessons Learned

The process covers:

t(m~Callt. the Board may

"Controls" This process also covers the

/111 make any recommendations for foUow-on .:u.;t.lUlJ.lj;

ensure that aU lessons learned the are annotated for the

PRINCE2 is on that a Business

and of a these roles can be combined or

PRINCE2 has a set of controls which facilitate the

EXDec:tatiom and follows these up

irements for a management method and how it should

SU4 Project Brief

• Semor lillIJ.Ili~t:illt:.m to the

• The Customer's tx:pect2Itl(lDS are iripnht,pri'

• Themethod DrOVlCl1nI!: a solution to the problem

• The and enters into it any risks

- Appointing a PB Executive and a Project

·...,.,,,...."'t,, or programme should appoint these two roles.

... Either management or the

What Happens in the

The complete project management team needs to reflect the

The Project Manager has to decide if any administrative support is

• candidates for the roles

• Decide if any staff will be n;;'luu ..... Roles

If the is of a programme, the use of the

of many different user areas is

In theory the Board should decide on what action to take

stage without reference to the Project Board.'

After the project management team has been designed, the

Executive, assisted by the Project Manager.

files. This ensures that there is no

There may be no need to get approval from any

To eIlSure that sufficient information is available for the

The is respoIlSible for the

"""'''WI,,", about .... " or even a verbal

~Vl<W4,""! should remember that it is a of

UHwal-;"l should check out the Brief