Sie sind auf Seite 1von 346

It is often stated that the one constant in the modern world

is change. Whether that change is driven from a strategic


perspective, forms part of a programme of transformational
change, or is in response to an operational imperative, the
delivery mechanism for change remains the same, and that is
project management.

This latest version of the PRINCE2TM method has been


designed to place more emphasis on the principles that
underpin successful project management, and to provide
clear guidance on how to apply these principles to the
organizational context within which projects are operating.
As such, it is an essential manual for anyone with an interest

Managing Successful Projects with PRINCE2TM


in managing projects more successfully.

The challenge that faces all organizations, whether they be


public or private sector, large or small, is to deliver change
through managing projects successfully and consistently. Managing Successful Projects with PRINCE2TM
This is where the PRINCE2 project management method adds
real value, as the globally recognized standard for delivering
successful projects.

ISBN 978-0-11-331059-3

www.tso.co.uk 9 780113 310593

5909_P2Managing_V0_7.indd 1 15/5/09 14:42:36


Managing Successful Projects with PRINCE2

London: TSO
Published by TSO (The Stationery Office) and available from:
Online
www.tsoshop.co.uk

Mail, Telephone, Fax & E-mail


TSO
PO Box 29, Norwich, NR3 1GN
Telephone orders/General enquiries: 0870 600 5522
Fax orders: 0870 600 5533
E-mail: customer.services@tso.co.uk
Textphone 0870 240 3701

TSO@Blackwell and other Accredited Agents

Customers can also order publications from:


TSO Ireland
16 Arthur Street, Belfast BT1 4GD
Tel 028 9023 8451 Fax 028 9023 5401

Crown Copyright 2009

Published on behalf of the Office of Government Commerce

This is a Crown copyright value added product, reuse of which requires a Licence from OGC.

Applications to reuse, reproduce or republish material in this publication should be sent to OGC,
The OGC Service Desk, Rosebery Court, St Andrews Business Park, Norwich, Norfolk, NR7 0HS.
Tel No: (+44) (0)845 000 4999, E-mail: servicedesk@ogc.gsi.gov.uk, or complete the application
form on the OGC website, Licensing section.

Copyright in the typographical arrangement and design is vested in The Stationery Office Limited.
Applications for reproduction should be made in writing to The Stationery Office Limited,
St Crispins, Duke Street, Norwich NR3 1PD

The Swirl logo is a Trade Mark of the Office of Government Commerce

The OGC logo is a Registered Trade Mark of the Office of Government Commerce in the United Kingdom

PRINCE is a Registered Trade Mark of the Office of Government Commerce in the United Kingdom and
other countries

PRINCE2 is a Trade Mark of the Office of Government Commerce in the United Kingdom and other
countries

ITIL is a Registered Trade Mark of the Office of Government Commerce in the United Kingdom and other
countries

M_o_R is a Registered Trade Mark of the Office of Government Commerce in the United Kingdom and
other countries

MSP is a Trade Mark of the Office of Government Commerce

P3O is a Registered Trade Mark of the Office of Government Commerce

P3M3 is a Trade Mark of the Office of Government Commerce

First edition Crown Copyright 1996


Second edition Crown Copyright 1998
Third edition Crown Copyright 2002
Fourth edition Crown Copyright 2005
Fifth edition Crown Copyright 2009

First published 2009

ISBN 978 0 11 331059 3

Printed in the United Kingdom for The Stationery Office


N6012442 c240 05/09
Contents

List of figures vi 5 Organization 29


List of tables viii 5.1 Purpose 31
5.2 Organization defined 31
Foreword x
5.3 The PRINCE2 approach to
Acknowledgements xi organization 32
5.4 Responsibilities 43
Conventions used in this manual xiii
1 Introduction 1 6 Quality 45
1.1 The purpose of this manual 3 6.1 Purpose 47

1.2 The importance of projects 3 6.2 Quality defined 47

1.3 What makes projects different? 3 6.3 The PRINCE2 approach to quality 49
1.4 Why have a project management 6.4 Responsibilities 57
method? 4
7 Plans 59
1.5 Introducing PRINCE2 4
7.1 Purpose 61
1.6 Related OGC guidance 6
7.2 Plans defined 61
1.7 Benefits of PRINCE2 7
7.3 The PRINCE2 approach to plans 64
2 Principles 9
7.4 Responsibilities 72
2.1 Continued business justification 11
2.2 Learn from experience 12 8 Risk 75
2.3 Defined roles and responsibilities 12 8.1 Purpose 77
2.4 Manage by stages 13 8.2 Risk defined 77
2.5 Manage by exception 13 8.3 The PRINCE2 approach to risk 78
2.6 Focus on products 14 8.4 Responsibilities 88
2.7 Tailor to suit the project
environment 14
9 Change 89
9.1 Purpose 91
3 Introduction to PRINCE2 themes 15
9.2 Change defined 91
3.1 What are the themes? 17
9.3 The PRINCE2 approach to change 92
3.2 Applying the themes 18
9.4 Responsibilities 96
3.3 Format of the themes 18
10 Progress 99
4 Business Case 19
10.1 Purpose 101
4.1 Purpose 21
4.2 Business Case defined 21 10.2 Progress defined 101

4.3 The PRINCE2 approach to the 10.3 The PRINCE2 approach to progress 102
Business Case 22 10.4 Responsibilities 109
4.4 Responsibilities 27
iv | Contents

11 Introduction to processes 111 18 Closing a Project 203


11.1 The PRINCE2 processes 113 18.1 Purpose 205
11.2 The PRINCE2 journey 113 18.2 Objective 205
11.3 The PRINCE2 process model 114 18.3 Context 205
11.4 Structure of the process chapters 114 18.4 Activities 205

12 Starting up a Project 119 19 Tailoring PRINCE2 to the project


environment 213
12.1 Purpose 121
19.1 What is tailoring? 215
12.2 Objective 121
19.2 General approach to tailoring 215
12.3 Context 122
19.3 Examples of tailoring PRINCE2 217
12.4 Activities 122
19.4 Projects in a programme
13 Directing a Project 133 environment 217
13.1 Purpose 135 19.5 Project scale 221
13.2 Objective 135 19.6 Commercial customer/supplier
environment 224
13.3 Context 135
19.7 Multi-organization projects 227
13.4 Activities 136
19.8 Project type 228
14 Initiating a Project 147
19.9 Sector differences 229
14.1 Purpose 149
19.10 Project management Bodies of
14.2 Objective 149 Knowledge 230
14.3 Context 150
Appendix A: Product Description
14.4 Activities 150 outlines 233

15 Controlling a Stage 165 A.1 Benefits Review Plan 235


A.2 Business Case 237
15.1 Purpose 167
A.3 Checkpoint Report 238
15.2 Objective 167
A.4 Communication Management
15.3 Context 168
Strategy 239
15.4 Activities 168
A.5 Configuration Item Record 240
16 Managing Product Delivery 183 A.6 Configuration Management
Strategy 241
16.1 Purpose 185
A.7 Daily Log 242
16.2 Objective 185
A.8 End Project Report 243
16.3 Context 185
A.9 End Stage Report 244
16.4 Activities 186
A.10 Exception Report 245
17 Managing a Stage Boundary 191
A.11 Highlight Report 245
17.1 Purpose 193
A.12 Issue Register 246
17.2 Objective 194
A.13 Issue Report 247
17.3 Context 194
A.14 Lessons Log 248
17.4 Activities 194
A.15 Lessons Report 249
Contents | v

A.16 Plan 250 E.6 Managing a Stage Boundary 292


A.17 Product Description 251 E.7 Closing a Project 293
A.18 Product Status Account 253
Further information 295
A.19 Project Brief 253
Glossary 301
A.20 Project Initiation Documentation 254
A.21 Project Product Description 256 Index 315
A.22 Quality Management Strategy 257
A.23 Quality Register 258
A.24 Risk Management Strategy 259
A.25 Risk Register 260
A.26 Work Package 261

Appendix B: Governance 263

Appendix C: Roles and responsibilities 267


C.1 Project Board 269
C.2 Executive 270
C.3 Senior User 270
C.4 Senior Supplier 271
C.5 Project Manager 271
C.6 Team Manager 272
C.7 Project Assurance 273
C.8 Change Authority 274
C.9 Project Support 274

Appendix D: Product-based planning


example 277
D.1 Scenario 279
D.2 Example of a Project Product
Description 279
D.3 Examples of a product breakdown
structure 281
D.4 Example of a Product Description 282
D.5 Product flow diagram 283

Appendix E: Health check 285


E.1 Starting up a Project 287
E.2 Directing a Project 288
E.3 Initiating a Project 291
E.4 Controlling a Stage 291
E.5 Managing Product Delivery 292
List of figures

Figure 1.1 Project management Figure 10.4 Specialist work aligned to


management stages
Figure 1.2 The structure of PRINCE2
Figure 11.1 The PRINCE2 processes
Figure 1.3 OGC best-practice guidance
Figure 11.2 PRINCE2 process model
Figure 4.1 Relationship between outputs,
outcomes and benefits Figure 11.3 Relationship between processes,
activities and actions
Figure 4.2 The development path of the
Business Case Figure 12.1 Overview of Starting up a Project
Figure 5.1 The three project interests Figure 12.2 Appoint the Executive and the
Project Manager: activity summary
Figure 5.2 The four levels of management
within the project management Figure 12.3 Capture previous lessons: activity
team summary
Figure 5.3 Project management team structure Figure 12.4 Design and appoint the project
management team: activity summary
Figure 5.4 Possible reporting structure using
user and supplier groups Figure 12.5 Prepare the outline Business Case:
activity summary
Figure 5.5 The many facets of the Project
Manager role Figure 12.6 Select the project approach and
assemble the Project Brief: activity
Figure 6.1 The quality audit trail summary
Figure 7.1 PRINCE2s planning levels Figure 12.7 Plan the initiation stage: activity
Figure 7.2 The PRINCE2 approach to plans summary

Figure 7.3 Product-based planning technique Figure 13.1 Overview of Directing a Project

Figure 7.4 Simple activity-on-node diagram Figure 13.2 Authorize initiation: activity
summary
Figure 8.1 Organizational perspectives
Figure 13.3 Authorize the project: activity
Figure 8.2 The risk management procedure summary
Figure 8.3 Example of a risk breakdown Figure 13.4 Authorize a Stage or Exception Plan:
structure activity summary
Figure 8.4 Risk cause, event and effect Figure 13.5 Give ad hoc direction: activity
Figure 8.5 Probability impact grid summary

Figure 8.6 Summary risk profile Figure 13.6 Authorize project closure: activity
summary
Figure 8.7 Threat and opportunity responses
Figure 14.1 Overview of Initiating a Project
Figure 9.1 Issue and change control procedure
Figure 14.2 Prepare the Risk Management
Figure 9.2 Options analysis Strategy: activity summary
Figure 10.1 Delegating tolerance and reporting Figure 14.3 Prepare the Configuration
actual and forecast progress Management Strategy: activity
summary
Figure 10.2 Specialist work defined in technical
stages Figure 14.4 Prepare the Quality Management
Strategy: activity summary
Figure 10.3 Specialist work crossing management
stage boundaries
List of figures | vii

Figure 14.5 Prepare the Communication Figure 17.5 Report stage end: activity summary
Management Strategy: activity
Figure 17.6 Produce an Exception Plan: activity
summary
summary
Figure 14.6 Set up the project controls: activity Figure 18.1 Overview of Closing a Project
summary
Figure 18.2 Prepare planned closure: activity
Figure 14.7 Create the Project Plan: activity summary
summary
Figure 18.3 Prepare premature closure: activity
Figure 14.8 Refine the Business Case: activity summary
summary
Figure 18.4 Hand over products: activity
Figure 14.9 Assemble the Project Initiation summary
Documentation: activity summary
Figure 18.5 Evaluate the project: activity
Figure 15.1 Overview of Controlling a Stage summary
Figure 15.2 Authorize a Work Package: activity Figure 18.6 Recommend project closure: activity
summary summary

Figure 15.3 Review Work Package status: activity Figure 19.1 Influences on the tailoring
summary requirement

Figure 15.4 Receive completed Work Packages: Figure 19.2 Comparison between projects and
activity summary programmes
Figure 19.3 Organization structure with the
Figure 15.5 Review the stage status: activity
Executive being a member of the
summary
programme board and the Senior
Figure 15.6 Report highlights: activity summary User being nominated by the
relevant business change manager
Figure 15.7 Capture and examine issues and
risks: activity summary Figure 19.4 Organization structure with the
programme manager as the project
Figure 15.8 Escalate issues and risks: activity Executive and the Senior User role
summary on the project being undertaken
Figure 15.9 Take corrective action: activity by the relevant business change
manager
summary
Figure 19.5 An example of a feasibility lifecycle
Figure 16.1 Overview of Managing Product
Delivery Figure A.1 Evolution of baseline management
products
Figure 16.2 Accept a Work Package: activity
summary Figure D.1 Product breakdown structure in the
form of a hierarchy chart
Figure 16.3 Execute a Work Package: activity
summary Figure D.2 Product breakdown structure in the
form of a mindmap
Figure 16.4 Deliver a Work Package: activity
summary Figure D.3 Example of a product flow diagram
for the conference project
Figure 17.1 Overview of Managing a Stage
Boundary
Figure 17.2 Plan the next stage: activity summary
Figure 17.3 Update the Project Plan: activity
summary
Figure 17.4 Update the Business Case: activity
summary
List of tables

Table 3.1 The PRINCE2 themes Table 12.6 Plan the initiation stage:
responsibilities
Table 4.1 Responsibilities relevant to the
Business Case Table 13.1 Authorize initiation: responsibilities
Table 5.1 Responsibilities relevant to the Table 13.2 Authorize the project:
Organization theme responsibilities
Table 6.1 The relationship between Project Table 13.3 Authorize a Stage or Exception Plan:
Assurance and quality assurance responsibilities
Table 6.2 Example of a Quality Register Table 13.4 Give ad hoc direction: responsibilities
Table 6.3 Responsibilities relevant to the Table 13.5 Authorize project closure:
Quality theme responsibilities
Table 7.1 Responsibilities relevant to the Plans Table 14.1 Prepare the Risk Management
theme Strategy: responsibilities
Table 8.1 Example of the expected monetary Table 14.2 Prepare the Configuration
value technique Management Strategy:
Table 8.2 Risk responses responsibilities

Table 8.3 Responsibilities relevant to the Risk Table 14.3 Prepare the Quality Management
theme Strategy: responsibilities
Table 9.1 Types of issue Table 14.4 Prepare the Communication
Management Strategy: responsibilities
Table 9.2 Project Board decisions
Table 14.5 Set up the project controls:
Table 9.3 Responsibilities relevant to the
responsibilities
Change theme
Table 14.6 Create the Project Plan:
Table 10.1 The six tolerance areas by level
responsibilities
Table 10.2 Responsibilities relevant to the
Progress theme Table 14.7 Refine the Business Case:
responsibilities
Table 11.1 An example of a table of
responsibilities Table 14.8 Assemble the Project Initiation
Documentation: responsibilities
Table 11.2 Key to process diagrams
Table 15.1 Authorize a Work Package:
Table 12.1 Appoint the Executive and the responsibilities
Project Manager: responsibilities
Table 15.2 Review Work Package status:
Table 12.2 Capture previous lessons: responsibilities
responsibilities
Table 15.3 Receive completed Work Packages:
Table 12.3 Design and appoint the project responsibilities
management team: responsibilities
Table 15.4 Review the stage status:
Table 12.4 Prepare the outline Business Case:
responsibilities
responsibilities
Table 15.5 Report highlights: responsibilities
Table 12.5 Select the project approach
and assemble the Project Brief: Table 15.6 Capture and examine issues and
responsibilities risks: responsibilities
List of tables | ix

Table 15.7 Escalate issues and risks:


responsibilities
Table 15.8 Take corrective action:
responsibilities
Table 16.1 Accept a Work Package:
responsibilities
Table 16.2 Execute a Work Package:
responsibilities
Table 16.3 Deliver a Work Package:
responsibilities
Table 17.1 Plan the next stage: responsibilities
Table 17.2 Update the Project Plan:
responsibilities
Table 17.3 Update the Business Case:
responsibilities
Table 17.4 Report stage end: responsibilities
Table 17.5 Produce an Exception Plan:
responsibilities
Table 18.1 Prepare planned closure:
responsibilities
Table 18.2 Prepare premature closure:
responsibilities
Table 18.3 Hand over products: responsibilities
Table 18.4 Evaluate the project: responsibilities
Table 18.5 Recommend project closure:
responsibilities
Table 19.1 Embedding and tailoring
Table 19.2 Examples of projects of different
scales
Table 19.3 Comparison between PRINCE2 and a
Body of Knowledge
Table A.1 Example of a product checklist
Table B.1 The Association for Project
Managements governance of project
management principles
Table D.1 Example of a Project Product
Description for an annual conference
Foreword

PRINCE2 is extensively used in more than This new edition covers the principles of PRINCE2,
150 countries around the world, and its take-up reinforcing the good practices of successful
grows daily. It is widely considered as the leading projects. The themes describe aspects of project
method in project management, with in excess of management that require specific treatment,
20,000 organizations already benefiting from its and the processes describe the progress through
pioneering and trusted approach. a project lifecycle from start-up to closure.
It is recommended that you use this manual
This updated guidance will help those running in conjunction with the companion volume,
projects of any size and in any environment Directing Successful Projects with PRINCE2
to effectively deliver what is required by (TSO, 2009).
appropriately managing the costs, timescales,
quality, scope, risks and benefits. Its development The number of people taking PRINCE2
has followed widespread consultation and draws qualifications increases by around 20% year on
upon real-life experiences in both public and year, and it remains a key contributor to the
private sector organizations. successful delivery of projects. It is a vital method
for any organization wishing to secure efficient
Today, complex projects often involve several and effective operational outcomes.
organizations working together in partnership or
through contractual arrangements to achieve the
objectives. PRINCE2 provides a common language
between organizations and with external
suppliers. It also allows a focus on the Business
Case, providing a mechanism to define what the
project is trying to achieve, and the rationale and
business justification for it.
This latest version of Managing Successful Nigel Smith
Projects with PRINCE2 represents an evolution
of the previous manuals. The basic methodology Chief Executive
remains, but by building on comments from users,
Office of Government Commerce
this new manual aims to be more accessible and
easier to tailor for specific individual needs.
Acknowledgements

The Office of Government Commerce (OGC) has PRINCE2:2009 project governance


continued to develop and improve the definition Mike Acaster, OGC, Project Executive; Eddie
and presentation of PRINCE2 within this reference Borup, BPUG, Senior User; Anne-Marie Byrne,
manual. The authoring team are acknowledged TSO, Project Manager; Janine Eves, TSO, Senior
for their significant contribution, under contract, Supplier; Sandra Lomax, BPUG, Senior User;
to the design and development of this guidance. Richard Pharro, APMG, Senior Supplier

Lead author Change control panel


Andy Murray Outperform UK Ltd Coos Groot, Best Practice User Group (PRINCE2
Italy); Peter Johnson, Peter Johnson PJ Ltd; Sheila
Authoring team Roberts, Cupe Ltd; Martin Rother, Best Practice
Nigel Bennett Sun Microsystems Ltd User Group (PRINCE2 Germany); David Watson,
John Edmonds pearcemayfield ADt Partnership
Bob Patterson Fujitsu Services
Sue Taylor APMG PRINCE2 examiner Reviewers
Graham Williams GSW Consultancy Ltd Robert Allen, PRS for Music; Adalcir da Silva
Angelo, Elumini IT & Business Consulting; Paul
Lead reviewer and mentor Askew, Housing Corporation; Richard Aspden,
Colin Bentley PRINCE2 Chief Examiner 1998-2008 Pathfinder Project Management; Gareth
Atwood, Foster Wheeler Energy; Marc Baetens,
Pronohau Ltd; Andrew Ball, Audit Commission;
Further contributions Jim Barker, Curtis & Cartwright Consulting Ltd;
In order to ensure that OGCs Managing Keith Batchelor, Foster Wheeler Energy; Dick
Successful Projects with PRINCE2 (2009) remains Bennett, APMG Chief Assessor; Kate Blackall,
a true reflection of current and future trends in APMG PRINCE2 examiner; Johan Bleeker,
the international field of project management Standard Bank; Eddie Borup, Ibps solutions;
best practice, and to produce guidance with Chris Braithwaite, Wellstream; George Brooke,
lasting value, OGC consulted widely with key Oak Lodge Consulting Ltd; Mark Canning, North
stakeholders and experts at every stage in the West Regional Development Agency; Tim Carroll,
process. OGC would like to thank the following Standard Chartered Bank; Jacqueline Chadwick,
individuals and their organizations for their VOSA; Sue Childs, APMG PRINCE2 examiner;
contributions to this new guidance: Alison Clack, Sean Alison Ltd; Jim Clinch, Clinch
Consulting; Brian Coombes, The Projects Group;
PRINCE2 reference group Arthur Coppens, Getronics Consulting Educational
Rob Brace, Department of Work & Pensions; Services; Bjarne Corvinius, Rovsing Management;
Andrew Bragg, Chief Executive, APM; Prof. Anthony Dailey, MWH; Terry Dailey, Deliverables
Christophe Bredillet, ESC Lille; Terry Cooke Davis, Management Consultants; Bill Duncan, APMG
Human Systems; Lynne Crawford, University PRINCE2 examiner; Hassan El Meligy, IEEE; Darilyn
of Sydney; John Cutting, MOD (DPA DE&S); Evans, Adaptive Frameworks, Alan Ferguson, AFA;
Prof. Darren Dalcher, Middlesex University, Chris Ferguson, Novare Consulting Ltd; Ray Frew,
National Centre for Project Management; Steve Aspen Management Training; Alvin Gardiner,
Falkenkrog, PMI; Ruth Little, DTI Projects Centre; PR-02 (Scotland) Ltd; Emmanuel Gianquitto,
Dusty Miller, Sun Microsystems Ltd; Bob Patterson, APMG (International); Colin Graham, Aylesbury
Fujitsu; Philip Rushbrook, Cabinet Office; Beverley Vale DC; John Greenwood, CSC; Angelika
Webb, BSI Project Management standard Hamilton, APMG (Germany); Gary R O Haran
committee; Jens Wandel, Director, UNDP Doyle, Swiss Life; Simon Harris, Logical Model
xii | Acknowledgements

Ltd; Wietse Heidema, Opmaat Consultancy &


Training; Luis Herrera, Consultant; Terry Hewins,
Land Registry; Emma Jones, APMG PRINCE2
Chief Examiner; Nigel Jones, AJS; Howard
Joseph, Home Office; Ravi Joshi, Action For
Children; Hans Kemper, APMG (Netherlands);
Eddie Kilkelly, ILX Group plc; Lawrie Kirk, Tanner
James Management Consultants (Australia);
Wieslaw Kosieradzki, P2Ware; Eddie Lamont,
Lothian & Borders Police; Tony Levene, Quality
Projects; Martin Lewis, Lucid IT; David Lillicrap,
London Borough of Ealing; Steve Livingstone,
BNFL; Tim Lulham, Network Rail; Maria Maltby,
Charnwood Borough Council; Dusty Miller, Sun
Microsystems Ltd; Trevor Mirams, Parity; Adrian
Newton, Quorum ICT; Bruce Nicholls, Bryan
Cave; Helen Nicoll, NHS; Chris Price, Highways
Agency; G. Raghunandan, Satyam Computer
Services Ltd; Geoff Rankins, Goal Professional
Services Pty Ltd; Lizz Robb, Yellowhouse.net pty
Ltd; Graham Robertson, Serco; Eileen Roden, PM
Professional Learning; Philip Rushbrook, Cabinet
Office; Ian Santry, Home Office; Andrew Schuster,
Department of Health; Noel Scott, Symantec;
John Sherwood, Highways Agency; Joy Shewring,
APMG (USA); Jay M. Siegelaub, Impact Strategies
LLC; Raed M. Skaf, Oger Systems Ltd; Tim Sneller,
Southend-on-Sea Borough Council; Rod Sowden,
Aspire Europe Ltd; Phil Stephensen-Payne, Remarc
Group; Rob Sucher, Armstrong Webb; Mark
Sutton, SCOLL Methods Ltd; Ian Thomas, Liberty
Network Consultancy; Dot Tudor, TCC; Bram de
Vuyst, Getronics Consulting Management Services;
Jens Wandel, United Nations Development
Programme; Geoff Ward, APMG PRINCE2
examiner; Sheryl Ward, Skandia; Peter Weaver,
Corte-grande; David Whelbourn, Xwave solutions
inc; Stephen Wierzbicki, Bristol Management
Centre; Jorn Wigh, APMG (Denmark); Gerald
Williams, Projectlabs; Philip Wilson, Cabinet Office

Managing Successful Projects with


PRINCE2 pilot group
The British Council; Capital Coast District Health
Board; Department of Labour (New Zealand);
Fishserve; Metropolitan Police; Ministry of
Economic Development (New Zealand); Ministry
of Education (New Zealand); Staffordshire
Metropolitan Borough Council; Standard Bank;
Suffolk County Council; Sun Microsystems Ltd;
Vietnamese Academy of Social Sciences.
Conventions used in this manual

Throughout this manual, the following terms use


title case:
PRINCE2 themes
PRINCE2 processes
PRINCE2 roles
Defined management products
Activities within PRINCE2 processes will always
be referred to using the same key words or
phrases, and are not otherwise distinguished,
as they should be evident from their context.
For example, The Project Board will give ad hoc
direction in these circumstances.
Abbreviations and acronyms have largely been
avoided; however, where they are used, they will
be spelt out in full on first use.
Key points are illustrated like this:

A PRINCE2 project has continued business


justification.

Example techniques are illustrated like this:

Example of a prioritization technique


MoSCoW
Each acceptance criterion is rated as either
Must have, Should have, Could have or Wont
have for now (MoSCoW).
All the Must have and Should have
acceptance criteria should be mutually
achievable.
Introduction 1
1 Introduction

1.1 The purpose of this manual can be introduced to best effect for the
organization.
PRINCE2 (Projects in a Controlled Environment) is a
As the pace of change (technology, business, social,
structured project management method based on
regulatory etc.) accelerates, and the penalties of
experience drawn from thousands of projects and
failing to adapt to change become more evident,
from the contributions of countless project sponsors,
the focus of management attention is inevitably
Project Managers, project teams, academics, trainers
moving to achieve a balance between business as
and consultants. This manual is designed:
usual and business change.
For entry-level project management personnel
Projects are the means by which we introduce
wishing to learn about project management
change and, while many of the skills required
generally and the PRINCE2 method in particular
are the same, there are some crucial differences
For experienced Project Managers and
between managing business as usual and
personnel who wish to learn about the PRINCE2
managing project work.
method
As a detailed reference source for PRINCE2
practitioners 1.3 What makes projects different?
As a source of information on PRINCE2 for
managers considering whether to adopt the A project is a temporary organization that is
method. created for the purpose of delivering one or
more business products according to an agreed
The manual covers the questions frequently asked
Business Case.
by people involved in project management and
support roles. These questions include:
Whats expected of me? There are a number of characteristics of project
What does the Project Manager do? work that distinguish it from business as usual:
What do I do if things dont go to plan? Change Projects are the means by which we
What decisions am I expected to make? introduce change
What information do I need or must I supply? Temporary As the definition above states,
Who should I look to for support? For projects are temporary in nature. Once the
direction? desired change has been implemented, business
How can I tailor the use of PRINCE2 for my as usual resumes (in its new form) and the need
project? for the project is removed. Projects should have
a defined start and a defined end
Cross-functional Projects involve a team of
1.2 The importance of projects people with different skills working together
A key challenge for organizations in todays world (on a temporary basis) to introduce a change
is to succeed in balancing two parallel, competing that will impact others outside the team.
imperatives: Projects often cross the normal functional
divisions within an organization and sometimes
To maintain current business operations
span entirely different organizations. This
profitability, service quality, customer
frequently causes stresses and strains both
relationships, brand loyalty, productivity, market
within organizations and between, for example,
confidence etc. What we term business as usual
customers and suppliers. Each has a different
To transform business operations in order to
perspective and motivation for getting involved
survive and compete in the future looking
in the change
forward and deciding how business change
4 | Introduction

Unique Every project is unique. An organization of project scale, type, organization, geography or
may undertake many similar projects, and culture.
establish a familiar, proven pattern of project
PRINCE2 achieves this by isolating the management
activity, but each one will be unique in some
aspects of project work from the specialist
way: a different team, a different customer, a
contributions, such as design, construction etc.
different location. All these factors combine to
The specialist aspects of any type of project are
make every project unique
easily integrated with the PRINCE2 method and,
Uncertainty Clearly, the characteristics already
used alongside PRINCE2, provide a secure overall
listed will introduce threats and opportunities framework for the project work.
over and above those we typically encounter
in the course of business as usual. Projects are Because PRINCE2 is generic and based on proven
more risky. principles, organizations adopting the method
as a standard can substantially improve their
organizational capability and maturity across
1.4 Why have a project multiple areas of business activity business
management method? change, construction, IT, mergers and acquisitions,
research, product development and so on.
Project management is the planning, delegating,
monitoring and control of all aspects of the 1.5.1 What does a Project Manager do?
project, and the motivation of those involved, In order to achieve control over anything, there
to achieve the project objectives within the must be a plan. It is the Project Manager who plans
expected performance targets for time, cost, the sequence of activities to build the house, works
quality, scope, benefits and risks. out how many bricklayers will be required and so
on.

It is the development of the projects deliverables It may be possible to build the house yourself but
(known as products in PRINCE2) that deliver the being a manager implies that you will delegate
projects results. A new house is completed by some or all of the work to others. The ability to
creating drawings, foundations, floors, walls, delegate is important in any form of management
windows, a roof, plumbing, wiring and connected but particularly so (because of the cross-
services. None of this is project management so functionality and risks) in project management.
why do we need project management at all? The With the delegated work under way, the aim is
purpose of project management is to keep control that it should go according to plan, but we cannot
over the specialist work required to create the rely on this always being the case. It is the Project
projects products or, to continue with the house Managers responsibility to monitor how well the
analogy, to make sure the roofing contractor work in progress matches the plan.
doesnt arrive before the walls are built.
Of course, if work does not go according to plan,
Additionally, given that projects are the means the Project Manager has to do something about
by which we introduce business change, and it, i.e. exert control. Even if the work is going well,
that project work entails a higher degree of the Project Manager may spot an opportunity
risk than other business activity, it follows that to speed it up or reduce costs. Whether it is by
implementing a secure, consistent, well-proven taking corrective action or implementing measures
approach to project management is a valuable to improve performance, the aim of PRINCE2 is
business investment. to make the right information available at the
right time for the right people to make the right
1.5 Introducing PRINCE2 decisions.

PRINCE2 is a non-proprietary method and has 1.5.2 What is it we wish to control?


emerged worldwide as one of the most widely
There are six variables involved in any project, and
accepted methods for managing projects. This
therefore six aspects of project performance to be
is largely due to the fact that PRINCE2 is truly
managed.
generic: it can be applied to any project regardless
Introduction | 5

or live in it happily. The Project Manager has


Plan to have a clear understanding of the purpose
of the project as an investment and make sure
that what the project delivers is consistent with
achieving the desired return.
Control Delegate
PRINCE2 is an integrated framework of processes
and themes that addresses the planning,
delegation, monitoring and control of all these six
Monitor aspects of project performance.
Figure 1.1 Project management
1.5.3 The structure of PRINCE2
Costs The project has to be affordable and, The PRINCE2 method addresses project
though we may start out with a particular management with four integrated elements of
budget in mind, there will be many factors principles, themes, processes and the project
which can lead to overspending and, perhaps, environment (Figure 1.2).
some opportunities to cut costs
Timescales Allied to this, and probably the 1 The principles (Chapter 2)
next most-frequent question asked of a Project These are the guiding obligations and good
Manager, is: When will it be finished? practices which determine whether the project is
Quality Finishing on time and within budget is genuinely being managed using PRINCE2. There
not much consolation if the result of the project are seven principles and unless all of them are
doesnt work. In PRINCE2 terms, the projects applied, it is not a PRINCE2 project.
products must be fit for purpose
Scope Exactly what will the project deliver? 2 The themes (Chapters 3 to 10)
Without knowing it, the various parties These describe aspects of project management
involved in a project can very often be talking that must be addressed continually and in parallel
at cross-purposes about this. The customer may throughout the project. The seven themes explain
assume that, for instance, a fitted kitchen and/ the specific treatment required by PRINCE2 for
or bathroom is included in the price of the various project management disciplines and why
house, whereas the supplier views these as they are necessary.
extras. On large-scale projects, scope definition
is much more subtle and complex. There must 3 The processes (Chapters 11 to 18)
be agreement on the projects scope and the These describe a step-wise progression through
Project Manager needs to have a detailed the project lifecycle, from getting started to
understanding of what is and what is not project closure. Each process provides checklists
within the scope. The Project Manager should of recommended activities, products and related
take care not to deliver beyond the scope as responsibilities.
this is a common source of delays, overspends
and uncontrolled change (scope creep) 4 Tailoring PRINCE2 to the project
Risk All projects entail risks but exactly how
environment (Chapter 19)
much risk are we prepared to accept? Should
we build the house near the site of a disused This chapter addresses the need to tailor PRINCE2
mine, which may be prone to subsidence? If we to the specific context of the project. PRINCE2
decide to go ahead, is there something we can is not a one size fits all solution; it is a flexible
do about the risk? Maybe insure against it or framework that can readily be tailored to any type
have thorough surveys carried out? or size of project.
Benefits Perhaps most often overlooked is the There is a companion guide, Directing Successful
question, Why are we doing this? Its not Projects with PRINCE2, which addresses the
enough to build the house successfully on time, PRINCE2 method from the viewpoint of senior
within budget and to quality specifications if, personnel, specifically Project Board members.
in the end, we cant sell or rent it at a profit
6 | Introduction

PROJECT ENVIRONMENT

Business
Progress Case
Organization

Change PRINCE2 PROCESSES


Quality

Risk
Plans

PRINCE2 THEMES

PRINCE2 PRINCIPLES

Figure 1.2 The structure of PRINCE2

1.6 Related OGC guidance 1.6.1 What PRINCE2 does not provide
PRINCE2 is part of a suite of guidance developed It is not intended (or possible) for PRINCE2 to cover
by the UK Office of Government Commerce (OGC), every aspect of project management. There are
which is aimed at helping organizations and three broad topic categories which are deliberately
individuals manage their projects, programmes considered to be outside the scope of PRINCE2:
and services consistently and effectively. Figure 1.3 Specialist aspects PRINCE2s strength is in
outlines the structure of the set. its wide applicability it is entirely generic.
Where appropriate, OGC methods and guidance Consequently, industry-specific or type-specific
are augmented by qualification schemes, and all activity is excluded. Engineering models,
aspects are supported by accredited training and project lifecycles or specific techniques (such
consultancy services. Details of these best-practice as organizational change management or
guides and other relevant guides can be found in procurement) can readily be used alongside
Further Information. PRINCE2. PRINCE2 categorizes all these aspects

Common Glossary

Models Guides
Refresh pending

Portfolio,
Programme
and Project Gateway M_o_R ITIL
Portfolio, Office
Programme and (P3O)
Project
Management
Maturity Model Portfolio Guide (PfM)
(P3M3TM)

MSPTM (programme)

PRINCE2TM
Maturity Model
(P2MM) PRINCE2TM (project )

Figure 1.3 OGC best-practice guidance


Introduction | 7

of project work as specialist (which means that There is a defined structure for accountability,
the specialist products concerned need to be delegation, authority and communication
identified and included within project scope Its product focus clarifies (for all parties) what
and plans) a project will deliver, why, when, by whom and
Detailed techniques There are many proven for whom
planning and control techniques that can PRINCE2 plans are carefully designed to
be used in support of the PRINCE2 themes. meet the needs of the different levels in the
Examples are critical path analysis (in planning) management team, improving communication
and earned value analysis (in progress and control
control). Such techniques are well documented It is based on a management by exception
elsewhere. Only techniques that have a specific framework, providing for the efficient and
PRINCE2 approach are described, e.g. the economic use of management time (whether at
product-based planning and quality review corporate, programme, Project Board or project
techniques management levels)
Leadership capability Leadership, motivational PRINCE2 ensures that participants focus on the
skills and other interpersonal skills are viability of the project in relation to its Business
immensely important in project management Case objectives rather than simply seeing the
but impossible to codify in a method. completion of the project as an end in itself
Leadership styles vary considerably and a style It defines a thorough but economical structure
that works in one situation may be entirely of reports
inappropriate in another. The fact that it is
It ensures that stakeholders (including
easy to think of successful leaders who have
sponsors and resource providers) are properly
adopted very different styles from autocratic
represented in planning and decision making
to consensus-based bears this out. For this
Adopting PRINCE2 promotes learning and
reason, PRINCE2 cannot address this aspect
continual improvement in organizations
of project management directly. There are
many leadership models and interpersonal- PRINCE2 promotes consistency of project work
skills training programmes that fulfil this and the ability to reuse project assets; it also
requirement. facilitates staff mobility and reduces the impact
of personnel changes/handovers
PRINCE2 is an invaluable diagnostic tool,
1.7 Benefits of PRINCE2 facilitating the assurance and assessment of
Before introducing the structure of the method, project work, troubleshooting and audits
it is worthwhile reviewing the key benefits of There are scores of accredited training and
adopting PRINCE2: consultancy organizations (ATOs and ACOs)
operating worldwide, who can supply
PRINCE2 embodies established and proven
expert support for PRINCE2 projects or for
best practice and governance for project
organizations planning to adopt PRINCE2.
management
It can be applied to any type of project and
can easily be implemented alongside specialist,
industry-specific models (engineering models
or development lifecycles)
PRINCE2 is widely recognized and understood,
and therefore provides a common vocabulary
for all project participants promoting effective
communication
PRINCE2 provides for the explicit recognition
of project responsibilities so that participants
understand each others roles and needs.
Principles 2
2 Principles

The purpose of PRINCE2 is to provide a project 2.1 Continued business justification


management method that can be applied
regardless of project scale, type, organization, A PRINCE2 project has continued business
geography or culture. This is possible because justification.
PRINCE2 is principles-based. Principles are
characterized as:
Universal in that they apply to every project A requirement for a PRINCE2 project is that:
Self-validating in that they have been proven in There is a justifiable reason to start it
practice over many years The justification should remain valid
Empowering because they give practitioners throughout the life of the project
of the method added confidence and ability The justification is documented and approved.
to influence and shape how the project will be
In PRINCE2, the justification is documented in a
managed.
Business Case. As a project is inextricably linked
The principles on which PRINCE2 is based originate to its business justification, it drives the decision-
from lessons learned from projects both good and making processes to ensure that the project
bad. They provide a framework of good practice remains aligned to the business objectives and
for those people involved in a project. If a project benefits being sought.
does not adhere to these principles, it is not being
Organizations that lack rigour in developing
managed using PRINCE2, because the principles are
Business Cases may find that some projects
the basis of what defines a PRINCE2 project.
proceed even where there are few real benefits
The seven PRINCE2 principles can be summarized or where a project has only tentative associations
as: with corporate strategy. Poor alignment with
Continued business justification corporate strategies can also result in organizations
having a portfolio of projects that have mutually
Learn from experience
inconsistent or duplicated objectives.
Defined roles and responsibilities
Manage by stages Even projects that are compulsory (for example, to
Manage by exception comply with new legislation) require justification
of the option chosen, as there may be several
Focus on products
options available that yield different costs, benefits
Tailor to suit the project environment.
and risks.
It is the adoption of these principles that
Although the justification should remain valid,
characterizes whether a project is using PRINCE2,
it may change. It is therefore important that the
not the adoption of processes and documents
project and evolving justification remain consistent.
alone. The principles facilitate good use of PRINCE2
by ensuring that the method is not applied in If, for whatever reason, the project can no longer
an overly prescriptive way or in name only, but be justified, the project should be stopped.
applied in a way that is sufficient to contribute to Stopping a project in these circumstances is a
the success of the project. positive contribution to an organization as its
funds and resources can be reinvested in other
more worthwhile projects.
12 | Principles

2.2 Learn from experience Projects involve people. No amount of good


planning or control will help if the wrong people
PRINCE2 project teams learn from previous are involved, if the right people are not involved,
experience: lessons are sought, recorded and or if people involved do not know whats expected
acted upon throughout the life of the project. of them or what to expect of others.
A project is typically cross-functional, may involve
Projects involve a temporary organization for a more than one organization, and may involve a
finite timescale for a specific business purpose. A mixture of full-time and part-time resources. The
common characteristic is that the project includes management structures of the parties involved
an element of uniqueness such that it cannot in the project are likely to be different with
be managed by existing line management or different priorities, objectives and interests
functional units. It is this element of uniqueness to protect. The day-to-day line management
that makes projects challenging as the temporary structures may not be designed for, or suited to,
team may not have experience of a project like the project work.
one being undertaken. To be successful, projects must have an explicit
In PRINCE2, learning from experience permeates project management team structure consisting of
the method: defined and agreed roles and responsibilities for
the people involved in the project and a means for
When starting a project Previous or similar
effective communication between them.
projects should be reviewed to see if lessons
learned could be applied. If the project is a All projects have the following primary
first for the people within the organization, stakeholders:
then it is even more important to learn from Business sponsors who endorse the objectives
others and the project should consider seeking and ensure that the business investment
external experience provides value for money
As the project progresses The project should Users who, after the project is completed, will
continue to learn. Lessons should be included use the products to enable them to gain the
in all reports and reviews. The goal is to seek intended benefits
opportunities to implement improvements
Suppliers who provide the resources and
during the life of the project
expertise required by the project (these may be
As the project closes The project should pass on internal or external).
lessons. Unless lessons provoke change, they are
only lessons identified (not learned). Therefore, all three stakeholder interests need
to be represented effectively in the project
It is the responsibility of everyone involved with management team two out of three is not
the project to seek lessons learned rather than enough. If the project costs outweigh the benefits,
waiting for someone else to provide them. the project will fail. Equally, if the outcome of the
project does not meet the users or operational
2.3 Defined roles and needs, or cannot feasibly be delivered by the
responsibilities suppliers, failure is inevitable.
The defined project management team structure
A PRINCE2 project has defined and agreed roles unites the various parties in the common aims of
and responsibilities within an organization the project. For all those people involved, a defined
structure that engages the business, user and project management team structure provides the
supplier stakeholder interests. answer to the question, What is expected of me?
Principles | 13

2.4 Manage by stages 2.5 Manage by exception

A PRINCE2 project is planned, monitored and A PRINCE2 project has defined tolerances for
controlled on a stage-by-stage basis. each project objective to establish limits of
delegated authority.
Management stages provide senior management
with control points at major intervals throughout PRINCE2 enables appropriate governance by
the project. At the end of each stage, the projects defining distinct responsibilities for directing,
status should be assessed, the Business Case and managing and delivering the project and
plans reviewed to ensure that the project remains clearly defining accountability at each level.
viable, and a decision made as to whether to Accountability is established by:
proceed.
Delegating authority from one management
Breaking the project into a number of stages level to the next by setting tolerances against
enables the extent of senior management control six objectives for the respective level of the
over projects to be varied according to the business plan:
priority, risk and complexity involved. Shorter Time Plus or minus an amount of time on
stages offer more control, while longer stages the target completion dates
reduce the burden on senior management. Cost Plus or minus an amount of the
Planning can only be done to a level of detail that planned budget
is manageable and foreseeable. A great deal of Quality Plus or minus degrees off a quality
effort can be wasted on attempts to plan beyond a target (e.g. a product that weighs a target
sensible planning horizon. For example, a detailed 300 g, with an allowed 5 g to +10 g
plan to show what each team member is doing tolerance)
for the next 12 months will almost certainly be Scope Permissible variation of the plans
inaccurate after just a few weeks. A detailed Team products (e.g. mandatory requirements plus
Plan for the short term and an outline plan for the or minus desirable requirements)
long term is a more effective approach. Risk Limits on the plans aggregated risks

PRINCE2 overcomes the planning horizon issue by: (e.g. cost of aggregated threats to remain
less than 10% of the plans budget) or limits
Dividing the project into a number of on any individual threat (e.g. a threat to
management stages operational service)
Having a high-level Project Plan and a detailed Benefit Plus or minus degrees off an
Stage Plan (for the current stage) improvement goal (e.g. 3040% cost
Planning, delegating, monitoring and reduction)
controlling the project on a stage-by-stage Setting up controls so that if those
basis. tolerances are forecast to be exceeded, they
PRINCE2 requires there to be a minimum of two are immediately referred up to the next
management stages: one initiation stage and one management layer for a decision on how to
or more further management stages. proceed
Putting an assurance mechanism in place so
that each management layer can be confident
that such controls are effective.
This implementation of management by
exception provides for very efficient use of senior
management time as it reduces senior managers
time burden without removing their control by
ensuring decisions are made at the right level in
the organization.
14 | Principles

2.6 Focus on products 2.7 Tailor to suit the project


environment
A PRINCE2 project focuses on the definition and
delivery of products, in particular their quality PRINCE2 is tailored to suit the projects
requirements. environment, size, complexity, importance,
capability and risk.

A successful project is output-oriented not activity-


oriented. An output-oriented project is one that The value of PRINCE2 is that it is a universal
agrees and defines the projects products prior project management method that can be applied
to undertaking the activities required to produce regardless of project type, organization, geography
them. The set of agreed products defines the scope or culture. It can be used by any project because
of a project and provides the basis for planning the method is designed to be tailored to its specific
and control. needs.

The purpose of a project is to fulfil stakeholder If PRINCE2 is not tailored, it is unlikely that the
expectations in accordance with the business project management effort and approach are
justification, and to do this there must be a appropriate for the needs of the project. This
common understanding of the products required can lead to robotic project management at one
and the quality expectations for them. The purpose extreme (the method is followed without question)
of a project can be interpreted in many different or heroic project management at the other
ways unless there is an explicit understanding extreme (the method is not followed at all).
of the products to be produced and the criteria The purpose of tailoring is to:
against which they will be individually approved.
Ensure the project management method relates
A PRINCE2 project uses Product Descriptions to to the projects environment (e.g. aligning the
provide such clarity by defining each products method to the business processes that may
purpose, composition, derivation, format, quality govern and support the project, such as human
criteria and quality method. They provide the resources, finance and procurement)
means to determine effort estimates, resource Ensure that project controls are based on
requirements, dependencies and activity schedules. the projects scale, complexity, importance,
The product focus supports almost every capability and risk (e.g. the reporting and
aspect of PRINCE2: planning, responsibilities, reviewing frequency and formality).
status reporting, quality, change control, scope, Tailoring requires the Project Manager and the
configuration management, product acceptance Project Board to make an active decision on how
and risk management. the method will be applied, for which guidance is
Without a product focus, projects are exposed to provided. When tailoring PRINCE2, it is important
several major risks such as acceptance disputes, to remember that it requires information (not
rework, uncontrolled change (scope creep), user necessarily documents) and decisions (not
dissatisfaction and underestimation of acceptance necessarily meetings).
activities. To ensure that all those people involved with the
project understand how PRINCE2 is to be used, the
Project Initiation Documentation should state how
the method is being tailored for that particular
project.
Introduction to
PRINCE2 themes 3
3 Introduction to PRINCE2 themes

3.1 What are the themes? of each theme, i.e. they are carefully designed to
link together effectively.
The PRINCE2 themes describe aspects of project
management that must be addressed continually. The PRINCE2 processes address the chronological
Any Project Manager who gives thorough flow of the project with actions relating to
attention to these themes will fulfil the role in a different themes mixed together. Here, the logical
professional manner. thread that runs through each theme is highlighted
However, the strength of PRINCE2 is the way in and more detailed guidance is provided in order
which the seven themes are integrated, and this is to amplify the process activities. Table 3.1 lists the
achieved because of the specific PRINCE2 treatment seven PRINCE2 themes and the relevant chapter.

Table 3.1 The PRINCE2 themes


Theme Description Answers Chapter
Business The project starts with an idea which is considered to have potential value for Why? 4
Case the organization concerned. This theme addresses how the idea is developed
into a viable investment proposition for the organization and how project
management maintains the focus on the organizations objectives throughout
the project.
Organization The organization sponsoring the project needs to allocate the work to Who? 5
managers who will be responsible for it and steer it through to completion.
Projects are cross-functional so the normal line function structures are not
suitable. This theme describes the roles and responsibilities in the temporary
PRINCE2 project management team required to manage the project effectively.
Quality The initial idea will only be understood as a broad outline. This theme explains What? 6
how the outline is developed so that all participants understand the quality
attributes of the products to be delivered and then how project management
will ensure that these requirements are subsequently delivered.
Plans PRINCE2 projects proceed on the basis of a series of approved plans. This How? 7
theme complements the Quality theme by describing the steps required
to develop plans and the PRINCE2 techniques that should be applied. In How much?
PRINCE2, the plans are matched to the needs of the personnel at the various
levels of the organization. They are the focus for communication and control
throughout the project. When?

Risk Projects typically entail more risk than stable operational activity. This theme What if? 8
addresses how project management manages the uncertainties in its plans and
in the wider project environment.
Change This theme describes how project management assesses and acts upon issues Whats the 9
which have a potential impact on any of the baseline aspects of the project (its impact?
plans and completed products). Issues may be unanticipated general problems,
requests for change or instances of quality failure.
Progress This theme addresses the ongoing viability of the plans. The theme explains Where are 10
the decision-making process for approving plans, the monitoring of actual we now?
performance and the escalation process if events do not go according to plan. Where are
Ultimately, the Progress theme determines whether and how the project should we going?
proceed.
Should we
carry on?
18 | Introduction to PRINCE2 themes

3.2 Applying the themes 3.3 Format of the themes


All seven themes must be applied in a project but Each of the themes chapters are structured as
they should be tailored according to the scale, follows:
nature and complexity of the project concerned.
Purpose Why it is important to the successful
Themes can be tailored up or down, i.e. delivery of the project
additional detailed documentation and process Theme defined Terms and definitions used
discipline can be introduced for complex or The PRINCE2 approach to the theme The
high-risk projects, whereas concise bullet-point specific treatment of the particular aspect of
presentations and more informal processes may be project management required for the PRINCE2
adequate for simple, low-risk projects. processes to be fully effective
Responsibilities Specific to the key theme for
each PRINCE2 role.
Business Case 4
4 Business Case

4.1 Purpose a pre-existing Business Case (from corporate or


programme management), in which case it will be
The purpose of the Business Case theme is to refined during initiation.
establish mechanisms to judge whether the
project is (and remains) desirable, viable and 4.2 Business Case defined
achievable as a means to support decision
making in its (continued) investment. 4.2.1 What is a Business Case?
The Business Case presents the optimum mix of
It is a PRINCE2 principle that a project must have information used to judge whether the project is
continued business justification. (and remains) desirable, viable and achievable, and
The business justification is the reason for the therefore worthwhile investing in.
project. Without it no project should start. If The Project Board and stakeholders must have
business justification is valid at the start of a confidence at all times that the project remains
project, but disappears once it is under way, the viable. In PRINCE2, the Business Case provides the
project should be stopped or changed. vital test of the viability of the project. It provides
In PRINCE2, the business justification is the answer to the question: is the investment in
documented in a Business Case describing the this project still worthwhile?
reasons for the project based on estimated costs, Since this viability question is ongoing, the Business
risks and the expected benefits. Case is not static. It should not be used only to gain
The reasons for undertaking the project must initial funding for a project, but should be actively
drive decision making. When projects face changes maintained throughout the life of the project and
or risks, the impact analysis should focus on the be continually updated with current information
Business Case, remembering that the project is only on costs, risks and benefits.
a means to an end and not the end itself. When making investment decisions, it is important
The ongoing and ever-present decision regarding to ascertain what benefits can be gained when,
the Business Case is whether the project can (still) with what degree of risk and from what level of
be justified. This is based on whether the project is investment. Projects should be evaluated on how
desirable (the cost/benefit/risk balance), viable (the well they will contribute to corporate objectives.
project can deliver the products) and achievable Such analysis enables one project to be compared
(the products can provide the benefits). with another so that the organization can choose
to invest in the best set of projects.
The Senior User(s) is responsible for specifying the
benefits and subsequently realizing the benefits
4.2.2Outputs, outcomes and benefits
through the use of the products provided by the
project. The Executive is responsible for ensuring In PRINCE2:
that those benefits specified by the Senior User(s) A projects output is any of the projects
represent value for money, are aligned to corporate specialist products (whether tangible or
objectives, and are capable of being realized. intangible)
In PRINCE2, the Business Case is developed at An outcome is the result of the change derived
the beginning of the project and maintained from using the projects outputs
throughout the life of the project, being formally A benefit is the measurable improvement
verified by the Project Board at each key decision resulting from an outcome that is perceived as
point, such as end stage assessments, and the an advantage by one or more stakeholders.
benefits are confirmed as they start to accrue.
In some cases the project may be initiated with
22 | Business Case

Customer/supplier project
Example of output, outcome and benefits
Multi-organization project.
Output: New sales system
Some of these projects may be measured
Outcome: Sales orders are processed more principally on return on investment, but others
quickly and accurately (particularly the compulsory or not-for-profit
Benefits: Costs are reduced by 10%, volume projects) may be measured on other non-financial
of sales orders increased by 15% and revenue benefits.
increased by 10% annually. Regardless of the type of measure being used, the
question remains: for this level of investment, are
As the projects outcomes and benefits are often the anticipated benefits more desirable, viable
only realized after the project has closed, it is and achievable than the other options available?
unfortunately easy for projects to become focused For more details on how the project environment
solely on creating products (the outputs). The affects the Business Case, see Chapter 19.
link from the projects outputs to outcomes and
benefits should be clearly identified and made
4.3 The PRINCE2 approach to the
visible to those involved, otherwise the original
purpose of the project can get lost (Figure 4.1). Business Case
In PRINCE2, the Business Case is developed at
4.2.3 Types of Business Case
the beginning of the project and maintained
The reasons for undertaking projects vary throughout the life of the project, being formally
enormously and are largely driven by their verified by the Project Board at each key decision
environment. The nature of the project will point, such as end stage assessments, and confirmed
determine the objectives that will be used to throughout the period that the benefits accrue.
verify the desirability of the project and later
to confirm that the projects products have met In this context:
those objectives. Such objectives will be measured Develop means getting the right information
differently depending on the type of project, for upon which decisions can be made
example: Verify means assessing whether the project is
Compulsory project (still) worthwhile
Not-for-profit project Maintain means to update the Business Case
Evolving project with actual costs and benefits and current
forecasts for costs and benefits
Confirm means assessing whether the intended
Project
outputs benefits have been (or will be) realized.
Confirming benefits will mostly take place post-
enable project.

create The Business Case is at the centre of any impact


Business Desired
changes assessment of risks, issues and changes by asking
outcomes
the question: how will this risk, issue or change
also cause
measured in
affect the viability of the Business Case and the
business objectives and benefits being sought?

Side-effects and 4.3.1Developing the Business Case


consequences realize Benefits
further In PRINCE2 the Executive is responsible for the
Business Case. It does not necessarily mean that
result in helps achieve
one or more the Executive writes the Business Case, merely that
the Executive is responsible for ensuring that the
Dis-benefits Strategic
objectives Business Case is written and approved.

Figure 4.1 Relationship between outputs, Development of the Business Case may be
outcomes and benefits delegated, for example, to a business analyst or
Business Case | 23

Confirm Confirm Confirm


benefits benefits benefits

Pre- Initiation
Subsequent delivery stage(s) Final delivery stage Post-project
project stage

Verify Verify Verify


outline detailed updated
Business Case Business Case Business Case

Develop Maintain
Business Case Business Case
Figure 4.2 The development path of the Business Case

perhaps even to the Project Manager. In some To drive the decision making, the Business Case
cases, programme management will provide an should be reviewed:
approved Business Case as part of the Project
At the end of the Starting up a Project process
Brief. Whoever is given the task of developing the
by the Project Board in order to authorize
Business Case, it is important to ensure that they
project initiation based on a reasonable
have the appropriate business skills required (for
justification
example, understanding the difference between a
At the end of the Initiating a Project process
cash-flow forecast, a profit-and-loss account and
by the Project Board in order to authorize the
a balance sheet). If not, then the Project Board
project
should consider using Project Assurance to assist
with the development of the Business Case. As part of any impact assessment by the Project
Manager of any new or revised issues or risks
The outline Business Case is derived from the In tandem with an Exception Plan by the Project
project mandate and developed pre-project in Board, in order to authorize the revised stage
the Starting up a Project process in order to gain and the continuation of the project
approval by the Project Board in the Directing a
At the end of each stage by the Project
Project process to initiate the project.
Manager to determine whether any of the
The detailed Business Case is derived from the costs, timescales, risks or benefits need to be
outline Business Case, the Project Plan (costs, updated
timescale, products) and the Risk Register. Due to At the end of each stage by the Project
the inputs required to develop a Business Case, its Board, to authorize the next stage and the
development will be iterative. There needs to be an continuation of the project
initial justification to proceed with the project, but During the final stage by the Project Manager,
until the project is planned in detail, the outline to assess the projects performance against
Business Case is based on costs and timescales its requirements and the likelihood that the
that are, at best, approximate. Once the costs and outcomes will provide the expected benefits
timescales are better understood, it may increase or As part of the benefits review (possibly by
decrease the desirability, viability and achievability corporate or programme management), to
of the project and could therefore change the determine the success of the project outcomes
project approach, leading to some replanning. in realizing their benefits.

4.3.2Verifying and maintaining the It is the responsibility of the Executive to assure


the projects stakeholders that the project remains
Business Case
desirable, viable and achievable at all times. The
The Business Case drives all decision making by Executive should not rely on end stage assessments
ensuring that the project remains justified and that alone to make this judgement and should use
the business objectives and benefits being sought Project Assurance to assist.
can be realized.
24 | Business Case

The investment appraisal section of the Business This poses a dilemma because, once the project
Case provides the Project Board with the source closes, the temporary organization is disbanded
of information to verify that the Business Case along with the framework (and in particular
justifies the authorization or continuation of the the funding and resources) to carry out any
project. measurement activities.
PRINCE2 overcomes this dilemma through defining
Example of an unverified Business Case
a Benefits Review Plan. The projects Benefits
A project to build a tourist attraction in London Review Plan will use the detailed Business Case to
was justified on the basis of attracting define the scope, timing and responsibility of a
12 million visitors in its first year. The projected number of reviews based on the timing and nature
number of visitors determined the revenue for of the expected benefits.
the exhibition and, with the project team under
By default, the Executive is responsible for ensuring
pressure to build a world class exhibition,
that benefits reviews are planned and executed,
the project budget was set at a level that
but there are circumstances where this may not
was break-even with 11 million visitors. The
always be the case:
projected 12 million visitors was an untested
assumption and significantly higher than the For projects in a programme environment, the
actual 4.5 million visitors. In project terms it projects Benefits Review Plan may be produced
was a success the exhibition opened on time, and executed by the programme, as one of the
was within 5% of cost budget and had all the roles of the programme is to coordinate the
facilities that were requested (so therefore met realization of the benefits of its projects
the acceptance criteria). However, the shortfall If the corporate organization has a centre
of visitors significantly reduced revenue, which of excellence or some form of performance
meant that the necessary government grant monitoring unit, it may undertake the
increased from 399 million to 628 million. It responsibility for measuring benefits of all
was a commercial and public relations disaster, projects within the organization
illustrating that delivering a project on time, For post-project measurement activities, the
within budget and to specification based on responsibility for benefits reviews will transfer
unsound benefit assumptions negates the from the Executive to corporate or programme
successful project delivery. management as the project closes (as the
reviews will need to be funded and resourced).
The Benefits Review Plan is first created by the
4.3.3 Confirming the benefits Project Manager in the initiation stage and is
The approach to confirming benefits is to: submitted to the Project Board for approval
Identify the benefits when seeking project authorization. If corporate
Select objective measures that reliably prove
or programme management are to manage or
participate in the benefits reviews, the Project
the benefits
Board may need to seek approval from corporate
Collect the baseline measures (from which the
or programme management. The Benefits Review
improvements will be quantified)
Plan is updated towards the end of each stage
Decide how, when and by whom the benefit
with actual benefits achieved, and a revised plan is
measures will be collected.
created for any remaining reviews whether within
The Senior User(s) specifies the benefits and is or beyond the life of the project.
held to account by demonstrating to corporate
As the Benefits Review Plan may be managed by
or programme management that the forecast
the project, corporate or programme management,
benefits that formed the basis of project approval
PRINCE2 recommends that it is kept separate from
are in fact realized. This may involve a commitment
the Project Plan and Stage Plans.
beyond the life of the project as it is likely that
many benefits will not be realized until after it The benefits that can be measured during the
has closed. life of a project should be reported by the Project
Manager in the End Stage Report. Any residual
Business Case | 25

benefits should be re-examined and their forecast 4.3.4.2 Business options


updated as part of the Managing a Stage Boundary There are three basic business options concerning
process. any investment:
The post-project benefits review(s) will involve Do nothing
corporate or programme management holding the Do the minimum
Senior User(s) to account by asking them to provide
Do something.
evidence of how the individual benefits allocated
to them have been gained in comparison to those Do nothing should always be the starting option
benefits promised to justify the cost and risk of the to act as the basis for quantifying the other options
project when it was authorized. The post-project the difference between do nothing and do the
benefits review(s) will also review the performance minimum/do something is the benefit that the
of the projects products in operational use and investment will buy.
identify whether there have been any side-effects The analysis of each option provides the Project
(beneficial or adverse) that may provide useful Board and the projects stakeholders with sufficient
lessons for other projects. information to judge which option presents the
best value for the organization. It provides the
4.3.4 The contents of a Business Case answer to the question: for this level of investment,
The Business Case should describe the reasons for are the anticipated benefits more desirable, viable
the project based on estimated costs, risks and and achievable than the other options available?
expected benefits. It typically contains:
The Business Case for the chosen option should be
An executive summary continually assessed for desirability, viability and
Reasons achievability as any new risks and/or changes may
Business options make one of the other options more justifiable.
Expected benefits
Expected dis-benefits 4.3.4.3 Expected benefits
Timescale The Business Case should list each benefit that
Costs it is claimed would be achieved by the projects
Investment appraisal
outcome (for the selected business option). It is
important to define the current status of each
Major risks.
benefit in quantifiable terms so that measurable
The Product Description for a Business Case can improvements can be assessed after the project
be found in Appendix A. The following sections has been completed. The Business Case should
provide further guidance for some of the Business define how and when the measurement of the
Case content. improvement can be made. For example, one of
the benefits of relocating the office could be a
4.3.4.1 Reasons saving in hotel conferencing costs, but only if the
The Business Case should explain the reasons why new site has more conference rooms.
the project is required. Ideally, it should be linked Benefits can be financial and non-financial
to the organizational context and should explain (sometimes referred to as cashable and non-
how the project will enable the achievement of cashable). Regardless of whether they are financial
corporate strategies and objectives. or non-financial, benefits should be:
The reasons are likely to be defined in the project Aligned to corporate objectives and strategy
mandate. If not, clarification should be sought. Mapped from the outputs and outcomes
For example, the reason for relocating an office provided by the project
may be because of changing demographics or
Quantified (with tolerance)
increasing leasing costs, because the firm has
Measurable
outgrown its current office or to meet new
legislation, such as disability access. Assigned.
26 | Business Case

Clear responsibility for benefits, collectively and The last might be affected by building into the
individually, is a key requirement for successful costs an allowance for estimating inaccuracies,
benefits realization. The Senior User(s) is changes and risks. This analysis usually reveals
responsible for the set of benefits within their whether benefit expectations are reasonable
respective areas, but responsibility for individual or overoptimistic. The result of this analysis can
benefits should be assigned to an appropriate lead to revision of the decision to go ahead with
person, ideally from within the group of users the project, which in turn would form a basis for
affected by that benefit. setting any benefit tolerance.
The list of expected benefits will influence the Once the benefits are defined, the activities to
set of products that the project will provide. The establish and collect the measures should be
project should not include any products that described in the Benefits Review Plan.
do not directly or indirectly enable the sought-
after benefits to be achieved. Mapping products 4.3.4.4 Expected dis-benefits
to outcomes and subsequently to benefits aids A dis-benefit is an outcome perceived as negative
decision making in the planning and control of by one or more stakeholders. Dis-benefits are
the project. Such mapping enables decisions to actual consequences of an activity whereas, by
be made based on the impact of the realization definition, a risk has some uncertainty about
of the expected benefits, i.e. the justification for whether it will materialize.
undertaking the project.
For example, a decision to merge two elements of
Wherever possible, benefits should be expressed an organization onto a new site may have benefits
in tangible ways. The Senior User or Executive may (e.g. better joint working), costs (e.g. expanding
define many benefits as intangible (for example, one of the two sites) and dis-benefits (e.g. drop in
happier staff). It is worth making the effort to productivity during the merger). These would all
think carefully about intangible benefits to see need to be considered and valued as part of the
whether they can be expressed in measurable investment appraisal.
ways. In this example, happier staff may translate
into reduced staff turnover and/or less time off 4.3.4.5 Timescale
for stress-related problems. Both of these can be
Corporate and/or programme management will
converted into a likely monetary saving.
wish to know:
The quantification of benefits enables benefits
Over what period the project costs will be
tolerance to be set (e.g. a 1015% increase in sales)
incurred
and the measurability of the benefits ensures that
Over what period the cost/benefits analysis will
they can be proven. If the project includes benefits
be based
that cannot be proven, then it is impossible to
judge whether the project: When the organization can expect to accrue
benefits
Has been a success
What the earliest/latest feasible start date is
Has provided value for money
What the earliest/latest feasible completion
Should be (or have been) initiated. date is.
There are many ways to verify the expected Identifying the timescale requirement for a project
benefits. For example, sensitivity analysis can be can help identify tolerances and timings for
used to determine whether the Business Case is benefits reviews.
heavily dependent on a particular benefit. If it is,
this may affect project planning, monitoring and 4.3.4.6 Costs
control activities, and risk management, as steps
The Business Case should summarize the costs
would need to be taken to protect that specific
derived from the Project Plan together with the
benefit.
assumptions upon which they are based. The
Another example is to define three views of the costs should also include details of the ongoing
achievement of the benefits, i.e. what are we really operations and maintenance costs and their
expecting, what might we achieve if things went funding arrangements.
well, and what might be the worst-case scenario?
Business Case | 27

4.3.4.7 Investment appraisal


Investment appraisal techniques
With the information in the Business Case,
it is possible and necessary to compare the Investment appraisal techniques include:
development, operations and maintenance costs Through-life costs Analysing the total cost of
with the value of the benefits over a period of implementation and any incremental operations
time (often referred to as an investment appraisal). and maintenance costs
The investment appraisal period may be a fixed
number of years or the useful life of the products. Net benefits Analysing the total value of the
The commissioning authority may have prescribed benefits less the cost of implementation and
accounting rules defining how the investment will ongoing operation calculated over a defined
be appraised. period
The investment appraisal should cover both the Return on investment (ROI) Profits or savings
project costs (to produce the required products and resulting from investments (this is the same as
the project management costs) and the ongoing net benefits if the benefits were only financial)
operations and maintenance costs. For example,
the estimated costs for office relocation could Payback period Calculating the period of time
cover the project costs for the relocation activities, required for the ROI to repay the sum of the
new stationery costs, penalties for terminating original investment
service agreements on the current premises, and
Discounted cash flow A means of expressing
the increase in rent/rates and service costs for the
future benefits based on the current value
new premises.
of money. Sometimes discounted cash flows
include risk adjustments as the business may
4.3.4.8 Major risks
not be confident that all the benefits will
Any opportunity is likely to be offset by an element materialize
of risk. Therefore in order to make the judgement
of business justification, the Project Board needs Net present value The total value of discounted
to understand not only the benefits and the project future cash inflows less the initial investment.
costs, but the set of risks that may either reduce/ For example, if inflation is at 6%, the value of
enhance the benefits or reduce/increase the cost. money halves approximately every 12 years.
If a project is forecasting a 500,000 benefit
The Business Case should include a summary of
to materialize in year 12, then it is only worth
the aggregated risks (and it is suggested that
250,000 in todays money
this is in the form of a summary risk profile) and
highlight the major risks that will have an effect Sensitivity analysis Business Cases are based
on the business objectives and benefits (therefore on uncertain forecasts. In order to identify
covering both the project delivery and the ongoing how robust the Business Case is, it is useful to
operations and maintenance). For example, understand the relationship between input
the risks for the office relocation could include factors (e.g. project costs, timescale, quality,
unforeseen moving costs (e.g. asbestos removal) or scope, project risk) and output (e.g. operations
impact on business continuity (e.g. loss of key staff and maintenance costs, business benefits and
unwilling to relocate). business risk). Sensitivity analysis involves
tweaking the input factors to model the point
4.4 Responsibilities at which the output factors no longer justify
the investment. For example, the project is
Table 4.1 outlines the responsibilities relevant to worthwhile if it can be done in four months,
the Business Case theme. Refer to Appendix C for but ceases to be worthwhile if it were to take
further details of project management team roles six months.
and their associated responsibilities.
28 | Business Case

Table 4.1 Responsibilities relevant to the Business Case


Role Responsibilities
Corporate or Provide the project mandate and define any standards to which the Business Case needs to
programme be developed.
management Hold the Senior User(s) to account for realizing the post-project benefits enabled by the
projects products.
Responsible for the Benefits Review Plan (post-project).
Executive Responsible for the Business Case for the duration of the project.
Responsible for the Benefits Review Plan (for the duration of the project) unless being
managed by corporate or programme management.
Oversee the development of a viable Business Case, ensuring that the project is aligned with
corporate strategies, and secure the funding for the project.
Senior User(s) Responsible for specifying the benefits upon which the Business Case is approved.
Ensure the desired outcome of the project is specified.
Ensure that the project produces products which deliver the desired outcomes.
Ensure that the expected benefits (derived from the projects outcomes) are realized.
Provide actual versus forecast benefits statement at the benefits reviews.
Senior Supplier(s) Responsible for the supplier Business Case(s) (if they exist) see section 19.6.1.1.
Confirm that the products required can be delivered within the expected costs and are viable.
Project Manager Prepare the Business Case on behalf of the Executive.
Conduct impact analysis of any new or revised issues or risks that affect the projects
desirability, viability or achievability against the original basis for approving the project.
Assess and update the Business Case at the end of each management stage.
Assess and report on project performance at project closure.
Project Assurance Assist in the development of the Business Case.
(business assurance Verify and monitor the Business Case against external events and project progress.
responsibilities)
Ensure the project fits with overall programme or corporate strategy.
Monitor project finance on behalf of the customer.
Ensure the value-for-money solution is constantly reassessed.
Monitor changes to the Project Plan to identify any impact on the needs of the business or
the Business Case.
Review the impact assessment of potential changes on the Business Case and Project Plan.
Verify and monitor the Benefits Review Plan for alignment to corporate or programme
management.
Project Support The Business Case should have a baseline and therefore be under configuration
management. Project Support should advise the Project Manager of any proposed or actual
changes to products that affect the Business Case.
Organization 5
5 Organization

5.1 Purpose and is likely to require a broad base of skills for a


comparatively short period of time.
The purpose of the Organization theme is to
define and establish the projects structure of 5.2.2 Programme
accountability and responsibilities (the who?). A project can be run as a stand-alone entity or
can be part of a programme of related projects. A
PRINCE2 is based on a customer/supplier programme is a temporary flexible organizational
environment. It assumes that there will be a structure created to coordinate, direct and oversee
customer who will specify the desired result and the implementation of a set of related projects and
probably pay for the project, and a supplier who will activities, in order to deliver outcomes and benefits
provide the resources and skills to deliver that result. related to the organizations strategic objectives. It
Every project needs effective direction, is likely to have a longer life than a single project.
management, control and communication. A project which forms part of a programme may
Establishing an effective project management be impacted by the programme structure and
team structure and strategy for communication at reporting requirements.
the beginning of a project, and maintaining these
throughout the projects life, are essential elements 5.2.3 Corporate organization
of a projects success. A project may or may not form part of a
programme. It will, however, exist within the wider
One of the principles of PRINCE2 is that all projects
context of a corporate organization. Corporate
must have a defined organizational structure to
organizational structures can vary from traditional
unite the various parties in the common aims
functional structures, where staff are organized
of the project and to enable effective project
by type of work (for example, marketing, finance,
governance and decision making.
sales etc., where there are clear reporting lines),
A successful project management team should: to project-focused corporate organizations, which
work with project teams as a norm, to variations in
Have business, user and supplier stakeholder
between.
representation
Ensure appropriate governance by defining
5.2.4Roles and jobs
responsibilities for directing, managing and
delivering the project and clearly defining In order to be flexible and meet the needs of
accountability at each level different environments and different project
Have reviews of the project roles throughout
sizes, PRINCE2 does not define management jobs
to be allocated to people on a one-to-one basis.
the project to ensure that they continue to be
It defines roles, each of which is defined by an
effective
associated set of responsibilities. Roles might be
Have an effective strategy to manage
shared or combined according to the projects
communication flows to and from stakeholders.
needs but the responsibilities must always be
allocated. When combining roles, consideration
5.2 Organization defined should be given to any conflicts of responsibilities,
whether one person has the capacity to undertake
5.2.1 Project the combined responsibilities, and whether any
PRINCE2 defines a project as a temporary bottlenecks might be created as a result.
organization that is created for the purpose of
delivering one or more business products according 5.2.5Three project interests
to an agreed Business Case. It needs to be flexible The PRINCE2 principle of defined roles and
responsibilities states that a PRINCE2 project
32 | Organization

will always have three primary categories of use both in-house and external supplier teams
stakeholder, and the interests of all three must be to construct the project product. The Senior
satisfied if the project is to be successful. Figure Supplier(s) will represent this stakeholder
5.1 shows the three primary interests which make interest on the Project Board.
up the Project Board. PRINCE2 recommends that
The level of overlap between the interests of the
for completeness the Project Board should include
business, user and supplier will change according to
representation from each of the business, user and
the type of corporate organization and project. For
supplier interests at all times.
example, if a project uses an in-house supplier, the
business and supplier interests will be more likely
to have overlapping interests than if an external
Business supplier is used.
Note the term customer is also used in PRINCE2,
normally in the context of a commercial customer/
The supplier relationship. Customer can usually be
project
interpreted as a collective term for the business
User Supplier and user interests. However, one example of an
exception to this broad rule would be where an
organization is developing a new product to bring
to market. In this case, the business interest is
Figure 5.1 The three project interests aligned with that of the supplier and customer
Business The products of the project should equates simply with users. Where the user interest
meet a business need which will justify the is external to the organization sponsoring the
investment in the project. The project should development, as in this example, it still needs to
also provide value for money. The business be represented in some way perhaps by the sales/
viewpoint therefore should be represented to marketing function.
ensure that these two prerequisites exist before As well as the primary categories of business, user
a project commences and remain in existence and supplier interests which should be represented
throughout the project. The Executive role is on the Project Board, there will be a wider range
defined to look after the business interests of stakeholders which may affect, or be affected
User PRINCE2 makes a distinction between by, the project. These stakeholders may be internal
the business interests and the requirements or external to the corporate organization and may
of those who will use the projects outputs. support, oppose or be indifferent to the project.
The user viewpoint should represent those Effective engagement with these stakeholders is
individuals or groups for whom some or all of key to a projects success (see section 5.3.5).
the following will apply:
They will use the outputs of the project
5.3 The PRINCE2 approach to
to realize the benefits after the project is
complete
organization
They will operate, maintain or support the
5.3.1 Levels of organization
projects outputs
The level of management required to make
The outputs of the project will impact them
decisions and commitments may be too busy to be
The user presence is needed to specify the involved on a day-to-day basis with the project. But
desired outputs and ensure that the project projects need day-to-day management if they are to
delivers them. The Senior User(s) will represent be successful. PRINCE2 separates the direction and
this stakeholder interest on the Project Board management of the project from the delivery of the
Supplier The creation of the projects outputs projects outputs, concentrating on the former and
will need resources with certain skills. The using the principle of management by exception.
supplier viewpoint should represent those who The project management structure has four levels,
will provide the necessary skills and produce three of which represent the project management
the project product. The project may need to team and the fourth which sits outside of the
Organization | 33

information should, if possible, be documented


Corporate or programme management in the project mandate
Directing The Project Board is responsible
Project management team

Directing Project Board for the overall direction and management of


the project within the constraints set out by
corporate or programme management. The
Project Board is accountable for the success of
Managing Project Manager
the project. As part of directing the project, the
Project Board will:
Approve all major plans and resources
Delivering Team Manager Authorize any deviation that exceeds or is
forecast to exceed stage tolerances
Figure 5.2 The four levels of management within Approve the completion of each stage and
the project management structure authorize the start of the next stage
Communicate with other stakeholders
project. Figure 5.2 illustrates these four levels of
Managing The Project Manager is responsible
management.
for the day-to-day management of the
The four levels of management are: project within the constraints set out by the
Corporate or programme management This level Project Board. The Project Managers prime
sits outside the project management team responsibility is to ensure that the project
but will be responsible for commissioning the produces the required products in accordance
project, including identifying the Executive with the time, cost, quality, scope, risk and
and defining the project-level tolerances benefit performance goals
within which the Project Board will work. This

Corporate or programme management

Project Board

Senior User(s) Executive Senior Supplier(s)

Business, User and Change Authority


Supplier Project
Assurance
Project Manager

Project Support

Team Manager(s)

Team members

Within the project management team

From the customer

From the supplier

Lines of authority

Project Assurance responsibility

Lines of support/advice

Figure 5.3 Project management team structure


34 | Organization

Delivering While the Project Manager is 5.3.2.2 Project Board


responsible for the day-to-day management Together, the Executive, Senior User(s) and Senior
of the project, team members are responsible Supplier(s) make up the Project Board. The Project
for delivering the projects products to an Board has authority and responsibility for the
appropriate quality within a specified timescale project within the instructions (initially contained
and cost. Depending on the size and complexity in the project mandate) set by corporate or
of the project, the authority and responsibility programme management.
for planning the creation of certain products
and managing a team of specialists to produce PRINCE2 defines the duties of the Project Board as:
those products may be delegated to a Team Being accountable for the success or failure of
Manager. the project in terms of the business, user and
supplier interests
5.3.2The project management team Providing unified direction to the project. As
one of the key responsibilities of the Project
5.3.2.1 Project management team structure Board is to provide direction to the Project
A project management team is a temporary Manager, it is important that all members have
structure specifically designed to manage the a unified view as to what the direction should
project to its successful conclusion. The structure be
allows for channels of communication to decision- Delegating effectively, using the PRINCE2
making forums and should be backed up by role organizational structure and controls designed
descriptions that specify the responsibilities, goals, for this purpose
limits of authority, relationships, skills, knowledge
Facilitating integration of the project
and experience required for all roles in the project
management team with the functional units
management team. Figure 5.3 illustrates the
of the participating corporate or external
structure of the project management team and its
organizations
reporting lines.
Providing the resources and authorizing the
The Executive (representing the business funds necessary for the successful completion of
viewpoint) and Senior User (representing the user the project
viewpoint) roles can often be combined. In such
Ensuring effective decision making
cases, to avoid any conflict, two individuals could
Providing visible and sustained support for the
be appointed to carry out Project Assurance, one
Project Manager
looking after the user interests and the other
representing the business interests. Ensuring effective communication both
within the project team and with external
Some of the PRINCE2 responsibilities cannot be stakeholders.
shared or delegated if they are to be undertaken
effectively. For example: Further guidance on these duties can be found in
OGCs Directing Successful Projects with PRINCE2
The Project Manager and Executive roles cannot (TSO, 2009).
be shared. The Executive cannot also be the
Project Manager and there cannot be more A good Project Board should display four key
than one Executive or Project Manager characteristics:
The Project Manager and Project Board Authority The members of the Project Board
decision-making accountability cannot be should be senior enough within the corporate
delegated. organization to make strategic decisions
about the project. As the Project Board is
PRINCE2 provides role description outlines in
accountable for the project, the individuals
Appendix C, which should be tailored to the
chosen must have sufficient authority to make
needs of the specific project and each specific
these decisions and to provide resources to the
appointment.
project, such as personnel, cash and equipment.
The managerial level required to fill the roles
will depend on factors such as the budget,
scope and importance of the project
Organization | 35

Credibility The credibility of the Project Board The Executive is appointed by corporate or
members within the corporate organization will programme management during the pre-project
affect their ability to direct the project process of Starting up a Project. The role of the
Ability to delegate A key part of the Project Executive is vested in one individual, so that
Boards role is to ensure that the Project there is a single point of accountability for the
Manager is given enough space to manage the project. The Executive will then be responsible
project by keeping Project Board activity at the for designing and appointing the rest of the
right level. Project Board members should not project management team, including the other
be involved in the detail of how the project is members of the Project Board. If the project is
managed, nor in the specialist content of the part of a programme, corporate or programme
project management may appoint some or all Project
Availability Project Board members who meet Board members.
all the above characteristics are of little value Throughout the project, the Executive is
to the project if they are not available to make responsible for the Business Case.
decisions and provide direction to the Project
Manager. Senior User

Project Board members are often from senior The Senior User(s) is responsible for specifying the
management positions, and their Project Board needs of those who will use the projects products,
responsibilities will be in addition to their normal for user liaison with the project management team
responsibilities. The concept of management by and for monitoring that the solution will meet
exception allows the Project Manager to keep those needs within the constraints of the Business
them regularly informed of project progress but Case in terms of quality, functionality and ease of
only requires decision making at key points in the use.
project. The role represents the interests of all those who
The frequency and detail of communication will use the projects products (including operations
required by the Project Board during a project and maintenance), those for whom the products
should be documented in the Communication will achieve an objective, or those who will use
Management Strategy. Project Board members may the products to deliver benefits. The Senior User
require more detailed or frequent information at role commits user resources and monitors products
the start of the project. As the project progresses, against requirements. This role may require more
and the Project Board becomes more comfortable than one person to cover all the user interests. For
with the progress being achieved, the requirement the sake of effectiveness the role should not be
for frequent or detailed Highlight Reports may split between too many people.
reduce. It is important to review the level and The Senior User(s) specifies the benefits and is
frequency of reporting for each stage during the held to account by demonstrating to corporate
Managing a Stage Boundary process. or programme management that the forecasted
Executive benefits that were the basis of project approval
are in fact realized. This is likely to involve a
Although the Project Board is responsible for commitment beyond the end of the projects life.
the project, the Executive (supported by the
Senior User(s) and Senior Supplier(s)) is ultimately Senior Supplier
accountable for the projects success and is the The Senior Supplier(s) represents the interests of
key decision maker. The Project Board is not a those designing, developing, facilitating, procuring
democracy controlled by votes. and implementing the projects products.
The Executives role is to ensure that the project This role is accountable for the quality of products
is focused throughout its life on achieving its delivered by the supplier(s) and is responsible for
objectives and delivering a product that will the technical integrity of the project. This role will
achieve the forecasted benefits. The Executive has include providing supplier resources to the project
to ensure that the project gives value for money, and ensuring that proposals for designing and
ensuring a cost-conscious approach to the project, developing the products are feasible and realistic.
balancing the demands of the business, user and
supplier.
36 | Organization

In most cases, the Senior Supplier also represents the relevant area of interest, and must be
the interests of those who will maintain the independent of the Project Manager. The Project
specialist products of the project after closure, Board should not assign any Project Assurance roles
e.g. engineering maintenance and support. to the Project Manager.
Exceptions to this do occur, e.g. when an external
As part of its function to monitor all aspects of the
supplier is delivering products to a customer who
projects performance and products independently
will maintain them in service/operation in this
of the Project Manager, Project Assurance should
instance the operations and maintenance interests
be involved in all of the PRINCE2 processes.
are more likely to be represented by a Senior User.
In fact, the distinction is not really important; what
5.3.2.4 Change Authority
matters is that operations, service and support
interests are represented appropriately from the One consideration at project initiation should
outset. be who is permitted to authorize requests for
change or off-specifications. It is the Project
If necessary, more than one person may be Boards responsibility to agree to each potential
required to represent the suppliers. change before it is implemented. In a project
where few changes are envisaged, it may be
5.3.2.3 Project Assurance reasonable to leave this authority in the hands
The Project Board is responsible, via its Project of the Project Board. But projects may be in a
Assurance role, for monitoring all aspects of the dynamic environment, where there are likely to be,
projects performance and products independently for example, many requests to change the initial
of the Project Manager. agreed scope of the project. Technical knowledge
may also be needed to evaluate potential changes.
Project Board members are responsible for the
aspects of Project Assurance aligned to their The Project Board needs to decide before the
respective areas of concern business, user or project moves out of the initiation stage if it
supplier. If they have sufficient time available, and wishes to delegate some authority for approving or
the appropriate level of skills and knowledge, they rejecting requests for change or off-specifications.
may conduct their own Project Assurance tasks,
To facilitate this, the Project Board should define in
otherwise they may appoint separate individuals to
the Configuration Management Strategy a scale of
carry these out.
severity ratings for requests for change. Depending
The Project Board may also make use of other on the severity, the request for change could be
members of the corporate organization taking handled by:
specific Project Assurance roles, such as appointing
Corporate or programme management
the corporate quality manager to monitor the
The Project Board
quality aspects of the project. Project Board
Delegating to a Change Authority
members are accountable for the Project Assurance
actions aligned to their area of interest, even if Delegating to the Project Manager.
they delegate these to separate individuals. These delegated authorities must be written into
Project Assurance is not just an independent the appropriate role descriptions. For projects
check, however. Personnel involved in Project that exist within a programme, the programme
Assurance are also responsible for supporting the management should define the level of authority
Project Manager, by giving advice and guidance that the Project Board will have in order to be able
on issues such as the use of corporate standards or to approve changes.
the correct personnel to be involved in different The Project Manager and/or the people with
aspects of the project, e.g. quality inspections or delegated Project Assurance responsibilities may
reviews. act as the Change Authority. Refer to Chapter 9 for
Where Project Assurance tasks are shared between more information on changes.
Project Board members and other individuals, it is
important to clarify each persons responsibilities.
Anyone appointed to a Project Assurance role
reports to the Project Board member overseeing
Organization | 37

On a large project, tailoring the project


Example of a Change Authority
management team could mean breaking the
A Project Manager is given authority to approve PRINCE2 roles into multiple appointments for
changes to individual products only if the example, several Senior Users or Senior Suppliers
changes would: could be appointed. However, it is good practice
to keep the size of the Project Board as small
Cost less than a pre-arranged limit
as possible while still representing all business,
Impact the project timescales by no more
user and supplier interests. To avoid enlarging
than one week the Project Board, user or supplier groups could
Not require any changes to the Project be used to maintain broad-ranging senior
Product Description or any other product. management involvement in those projects that
Any changes that fall outside of these limits impact on a large user or supplier community.
would have to be escalated to the Project These groups discuss user or supplier issues and
Board. risks, and pass recommendations to the Senior
User(s) or Senior Supplier(s) on the Project Board. If
a user or supplier group is involved, it is important
to define at the outset who is authorized to
5.3.2.5 Size of the Project Board
represent its collective view and how this will
The Executive, supported by the Project Manager, is operate. It may also be appropriate to appoint
responsible for agreeing a suitable team structure members of these groups to user or supplier Project
and tailoring it to the projects size, risk and Assurance; multiple individuals can fulfil Project
complexity. The Project Board needs to represent Assurance roles. The commercial context will also
all of the interested parties in the corporate affect the projects organizational structure (e.g. if
organization, and involve any suppliers (internal or a prime contractor is appointed).
external) that have been identified.

User Project Board Supplier


groups groups
Senior User Executive
Project Board Senior Supplier
User Supplier
groups groups
Senior User Executive Senior Supplier
User Supplier
representative representative
(area 1) (area 1)
User Supplier
representative
User Supplier
representative
(area 1)
representative representative
(area 1)
(area 2) User Project Business Project Supplier Project (area 2)
User Supplier
Assurance Assurance Assurance
representative representative
(area 2) User Project Business Project Supplier Project (area 2)
Assurance Assurance Assurance

Within the project management team

From the customer


Within the project management team
From the supplier
From the customer
Lines of authority
From the supplier
Project Assurance responsibility
Lines of authority
Lines of support/advice
Project Assurance responsibility
Figure 5.4 Possible reporting structure using user and supplier groups
Lines of support/advice
38 | Organization

Figure 5.4 shows a potential project-reporting


structure which includes user and supplier groups. Line management
Strategy Cost management
Producing a matrix of stakeholders against the
projects products also helps split the project Teamwork Communication
stakeholders (who need to be engaged as part of
the Communication Management Strategy) from
the project decision makers (who need to be on Planning
Project
Quality
the Project Board). Manager

The decision on whether to include external


suppliers on the Project Board may be a cultural Product status
Monitoring
one based on fear of divulging commercial or
financial information. Leaving them out of the User needs Product vs project needs
Directing a Project process could cause delays Changes
due to the lack of supplier resources to deal with
change and to address specialist issues. It is the
Figure 5.5 The many facets of the Project Manager
Executives decision as to how this dilemma is
role
solved practically.
5.3.2.7 Team Manager
5.3.2.6 Project Manager
The Team Managers primary responsibility is to
The Project Manager is the single focus for day-
ensure production of those products allocated by
to-day management of a project. This person has
the Project Manager. The Team Manager reports
the authority to run the project on behalf of the
to, and takes direction from, the Project Manager.
Project Board within the constraints laid down by
the Project Board. In a PRINCE2 environment the The Team Manager role may be assigned to the
Project Manager role should not be shared. Project Manager or a separate person. There are
many reasons why the Project Manager may decide
The Project Manager will normally come from the
to appoint other people to be Team Managers
customer corporate organization, but there may
rather than undertake the role themselves. Among
be projects where the Project Manager comes
these are the size of the project, the particular
from the supplier. Refer to Chapter 19 for more
specialist skills or knowledge needed for certain
information on customer/supplier relationships.
products, geographical location of some team
The Project Manager is responsible for the work of members and the preferences of the Project Board.
all the PRINCE2 processes except for the Directing The Project Manager should discuss the need for
a Project process, and appointing the Executive separate individuals as Team Managers with the
and the Project Manager in the pre-project process Project Board and, if required, should plan the role
Starting up a Project. The Project Manager also at the start of the project during the Starting up a
delegates responsibility for the Managing Product Project process, or for each stage in the Managing
Delivery process to the Team Manager(s). a Stage Boundary process.
The Project Manager manages the Team Managers PRINCE2 uses Work Packages to allocate work to
and Project Support, and is responsible for liaison Team Managers or team members. They can be
with Project Assurance and the Project Board. In used formally or informally depending on the
projects with no separate individual allocated to needs of the project. In addition to the information
a Team Manager role, the Project Manager will included in Appendix A, a Work Package can
be responsible for managing work directly with include items such as resource costs, accounting
the team members involved. In projects with no codes, allocated resources and other management
separate Project Support role, the support tasks information. Defining the deliverables at the
also fall to the Project Manager, although they may appropriate level will also assist new Team
be shared with team members. Managers in becoming more effective as it is clear
what has to be produced, and with the definition
As the single focus for the day-to-day management
of reporting frequency and method, the feedback
of a project, there are many different aspects to
from the Team Manager can be clearly controlled.
the Project Manager role. Figure 5.5 shows some of
these different facets.
Organization | 39

If the Team Manager comes from the supplier its life. In practice, however, this may not always
corporate organization, there could be a reporting be possible and the project management team
line to a Senior Supplier. It is vital that any such may change during the project. A clearly defined
links are understood to avoid conflicts of interest team structure, together with comprehensive role
and any undermining of the Project Managers descriptions outlining the responsibilities for each
authority. role, should help to alleviate disruption caused by
project management team changes.
The structure of the project management team
does not necessarily reflect line function or The use of management stages also allows a
seniority but represents roles on the project. A smooth transition for changes to the project
Team Manager, for example, may be more senior management team. Project roles should be
in the corporate organization than the Project reviewed for the next stage during the Managing
Manager, or may be a senior representative from a Stage Boundary process. The use of End Stage
an external supplier. In the context of the project, Reports and Stage Plans can help to ensure
however, the Team Manager reports to, and takes that any handover procedure is thorough and
direction from, the Project Manager. well documented. Although ideally the Project
Executive and Project Manager should stay with
5.3.2.8 Project Support the project throughout its lifecycle, a stage
Project Support is the responsibility of the Project boundary provides an opportunity to hand over
Manager. If required, the Project Manager can the role during the project if this is necessary.
delegate some of this work to a Project Support
role: this may include providing administrative Example of changes to the project management
services or advice and guidance on the use of team
project management tools or configuration
management. It could also provide specialist A project may include a procurement
functions to a project such as planning or risk stage, during which a supplier is selected
management. Unless performed by a corporate to develop some of the projects products.
or programme management function, Project Before the supplier has been selected, a
Support is typically responsible for administering senior representative from the procurement
any configuration management procedure and department may represent the Senior
tools as defined in the Configuration Management Supplier on the project. After the supplier has
Strategy. been selected and the project moves to the
development stage, a senior representative
It is important to stress that the role of Project from the selected suppliers organization could
Support is not optional, but the allocation of be included on the team as a Senior Supplier.
a separate individual or group to carry out the
required tasks is. Project Support defaults to the
Project Manager if it is not otherwise allocated.
5.3.3 Working with the project team
Some corporate organizations may have a project 5.3.3.1Balancing the project, team and
office (a temporary office set up to support the individual
delivery of a specific project) or similar structure, People are crucial to the success of a project. It is
which can fulfil some or all of the Project Support not enough to have the required processes and
role. Refer to OGCs Portfolio, Programme and systems in place: if the people on a project do not
Project Offices (P3O) for further information on work effectively together, then the chances of the
the use of a project office. projects success are severely restricted. Knowledge
Project Support and Project Assurance roles of different types of personalities and how these
should be kept separate in order to maintain the work together can help the Project Manager to
independence of Project Assurance. structure balanced teams that can work together
effectively during a project.
5.3.2.9Dealing with changes to the project Different people have different characteristics, and
management team certain types of people are more suited to certain
Ideally, the Project Manager and Project Board roles. In a given environment, some combinations
members should stay with the project throughout of personality types work better than others.
40 | Organization

working on the project on a part-time basis. Part-


Example of team building using different
time team members suffer more absences and
personalities
diversions, as a percentage of their working time,
Some people are very sociable and enthusiastic, than full-time team members. The Project Manager
generating many different ideas. Others should allow for this when designing a plan
are more analytical, skilled in detailed work either by negotiating guaranteed availability or
and ensuring no tasks get missed. While it greater tolerance.
is not usually possible to change peoples
If individuals are tasked with working on too many
characteristics, it is possible to balance a team
projects, they will simply stand still on all of the
so that it has an appropriate mix of personality
projects, expending a lot of effort but making no
types to enable tasks to be completed
forward progress. Solutions include undertaking
effectively. Project Managers who know the
fewer projects in parallel or, where possible,
natural roles of the team members can use
allocating staff full time to projects for limited
that knowledge to build effective teams
periods.
during the Starting up a Project process for the
management team and the Initiating a Project
5.3.4Working with the corporate
process when identifying team members. It
is important to achieve the correct balance: organization
for example, a team consisting of only ideas
5.3.4.1Line management/functional
people risks losing focus on the detail of tasks
which need to be performed. Conversely, a
management
team made up of only detailed people may In a strongly functional environment, Project
lack a strategic overview of a solution. Managers can find difficulties when managing
cross-functional projects due to the inability to
agree overall leadership from within the various
5.3.3.2 Training needs for project teams
groups. As a result, the Project Board may need
At the start of the project, team members may to be involved more closely to lead, direct and
need training. This could include training on prioritize work and resolve issues. Whatever
any processes and standards to be used on the the environment, the Project Manager will have
project (such as configuration management to adapt to, and work within, the corporate
procedures, quality methods, progress reporting organization and this will affect the level of
and other project-specific areas), or it could management required for the team members.
be an introduction to the project and its goals
designed to motivate the team members. Project Example of a Project Managers responsibilities to
Board members may also need training on line/functional management
their roles, including what is expected of them
and the procedures needed to carry out their The Project Manager may be responsible for
responsibilities. Training on PRINCE2 processes carrying out performance appraisals as part of
and terminology may also be required for Team a project, or may provide input to the appraisal
Managers and other members of the project undertaken by the functional area of the
management team. corporate organization responsible for the team
member.
During a project, team members may also need
specialist training to enable them to complete their
Understanding and working within the wider
assigned tasks. The Project Manager should ensure
corporate organization can be challenging for the
that training needs are built into the appropriate
Project Manager, particularly if working part-time
plans.
or on a contract basis. Setting up clear project
controls at the start of the project, and agreeing
5.3.3.3 Part-time teams
these with the Project Board, will help to ensure
Project teams are brought together for the that the Project Manager understands the level
duration of a project and then return to their of interaction and support to expect during the
routine work. The manager of a small project is project and is given appropriate exposure to other
therefore likely to find that team members are areas of the corporate organization.
Organization | 41

5.3.4.2 Centre of excellence Support or oppose the project


The concept of a centre of excellence is that of a Gain or lose as a result of project delivery
central standards unit, which defines standards See the project as a threat or enhancement to
(such as processes, templates and tools), and their position
provides skills, training and possibly independent Become active supporters or blockers of the
assurance functions to a number of projects. project and its progress.
It is important to analyse who these stakeholders
Example of a centre of excellence
are and to engage with them appropriately.
An organization has established a centre of
excellence that provides: Example of stakeholder analysis
A central filing system for all projects Stakeholder analysis identified the following
A configuration management system stakeholders for a project to relocate a chemical
Expertise for estimating techniques factory:
Advice on the preparation of plans A number of unions
A historical database of how long specific An environmental pressure group
activities take (metrics) and an analysis of An industry regulator
productivity The programmes quality assurance function
PRINCE2 expertise and advice
A number of corporate management
Consolidated reports summarizing the status functions (e.g. internal audit, finance, legal)
of all the projects in the portfolio. The external contractor
Some members of the public affected by the
A centre of excellence can be useful where: project.

Resource shortages, either in numbers or skills, Note that some of these were external to the
make it difficult to supply people to perform project management team but internal to
project administration for each current project the corporate or programme management
There are a number of small projects of a organization.
diverse nature that individually require only
limited support from Project Support
There is a large programme, requiring 5.3.5.2 Stakeholder engagement
coordination of individual projects Stakeholder engagement is the process of
A large project requires several resources to identifying and communicating effectively with
handle Project Support roles. those people or groups who have an interest or
influence on the projects outcome. It is usually
Refer to OGCs guidance Portfolio, Programme and carried out at the programme level. All projects
Project Offices (TSO, 2008) for further information need to have some level of some stakeholder
on the centre of excellence and its relationship to engagement, particularly if not part of a
projects. programme.

5.3.5 Working with stakeholders Parties external to the project management team
can exert a powerful influence on a project.
5.3.5.1 Types of stakeholder Effective communication with key stakeholders,
There are likely to be individuals or groups who both internal and external to the corporate
are not part of the project management team, but organization, is essential to the projects success.
who may need to interact with the project or who
may be affected by the projects outcome. Such
people may:
42 | Organization

Example of stakeholder engagement greatly influence their credibility. Many


projects have a formal commencement
OGCs Managing Successful Programmes
meeting to introduce the project and its
(MSP) identifies a six-step procedure for
aims to the corporate organization. If this
stakeholder engagement:
type of meeting is used, it is important that
Identifying stakeholders (Who?) Identifying the members of the Project Board attend to
the individual stakeholders involved in, show their support and commitment to the
or affected by, the project and perhaps project
grouping similar stakeholders together Engaging stakeholders (Do) Carrying out the
so that key messages can be targeted planned engagements and communications.
effectively The first two steps in stakeholder
Creating and analysing stakeholder profiles engagement identifying and analysing
(What?) Gaining an understanding of the also engage stakeholders to some degree
influences, interests and attitudes of the Measuring effectiveness (Results) Checking
stakeholders towards the project and the the effectiveness of the engagements.
importance and power of each stakeholder. Project Assurance could be involved in
For instance, is a particular group likely to checking all the key stakeholders, their
be negative, irrespective of the message, information needs and that the most
and therefore require particular care? appropriate communication channels are
Stakeholders influence and interests, covered.
whether rational or emotional, must all
be taken into account. They have the
potential to affect the success of the project.
Perceptions may be mistaken, but they must 5.3.5.3The Communication Management
be addressed. The stakeholders perception Strategy
of the benefits should be quantified where The Communication Management Strategy
possible contains a description of the means and frequency
Defining the stakeholder engagement strategy of communication to parties both internal and
(How?) Defining how the project can external to the project. It facilitates engagement
effectively engage with the stakeholders, with stakeholders through the establishment of a
including defining the responsibilities for controlled and bi-directional flow of information.
communication and the key messages that Where the project is part of a programme, the
need to be conveyed. For each interested Communication Management Strategy should also
party, agree the: define what information the programme needs
Information the party needs from the and how this is to be communicated.
project
If a formal stakeholder engagement procedure
Method, format and frequency of
has been completed, such as that described earlier,
communication
this should also be documented as part of the
Sender and recipient of the
Communication Management Strategy. Refer to
communication Appendix A for more details of the suggested
Planning the engagements (When?) content for the Communication Management
Defining the methods and timings of the Strategy.
communications. These are best planned The Project Manager should be responsible for
after defining how the project will engage documenting the Communication Management
with the different stakeholders. When Strategy during the Initiating a Project process. It
selecting the senders of information, it is is also important to review and possibly update
important to select communicators who the Communication Management Strategy at
have the respect and trust of the audience. each stage boundary in order to ensure that it still
Their position in the corporate organization includes all the key stakeholders. When planning
and expertise in the subject matter will the final stage of the project it is also important to
review the Communication Management Strategy
Organization | 43

to ensure it includes all the parties who need to be 5.4 Responsibilities


advised that the project is closing.
Table 5.1 outlines the responsibilities relevant to
During a project, corporate or programme the Organization theme. Refer to Appendix C for
management retains control by receiving project further details of project management team roles
information as defined in the Communication and their associated responsibilities.
Management Strategy and taking decisions on
project-level exceptions escalated by the Project
Board.
If a project forms part of a programme, there
will need to be consistency and communication
between the project and programme levels of
management. Refer to Chapter 19 for more
detailed information on programme roles and how
they may interact with project roles.

Table 5.1 Responsibilities relevant to the Organization theme


Role Responsibilities
Corporate or programme management Appoint the Executive and (possibly) the Project Manager.
Provide information to the project as defined in the Communication
Management Strategy.

Executive Appoint the Project Manager (if not done by corporate or programme
management).

Confirm the appointments to the project management team and the


structure of the project management team.

Approve the Communication Management Strategy.


Senior User Provide user resources.
Define and verify user requirements and expectations.
Senior Supplier Provide supplier resources.
Project Manager Prepare the Communication Management Strategy.
Review and update the Communication Management Strategy.
Design, review and update the project management team structure.
Prepare role descriptions.
Team Manager Manage project team members.
Advise on project team members and stakeholder engagement.
Project Assurance Advise on selection of project team members.
Advise on stakeholder engagement.
Ensure that the Communication Management Strategy is appropriate
and that planned communication activities actually take place.
Project Support Provide administrative support for the project management team.
Quality 6
6 Quality

6.1 Purpose is derived from the ISO 9000 standards but is aimed
specifically at project work.
The purpose of the Quality theme is to define
and implement the means by which the project
will create and verify products that are fit for
6.2.1 Quality
purpose. Quality is generally defined as the totality of
features and inherent or assigned characteristics of
The Quality theme defines the PRINCE2 approach a product, person, process, service and/or system
to ensuring that the projects products: that bear on its ability to show that it meets
expectations or satisfies stated needs, requirements
Meet business expectations
or specification.
Enable the desired benefits to be achieved
subsequently. In PRINCE2, a product can also be a person, process,
service and/or system, so the focus of quality is on a
The product focus principle is central to PRINCE2s
products ability to meet its requirements.
approach to quality. It provides an explicit common
understanding of what the project will create (the
6.2.2 Scope
scope) and the criteria against which the projects
products will be assessed (the quality). Without this The scope of a plan is the sum total of its products.
understanding, the project would be exposed to It is defined by the product breakdown structure
major risks (such as acceptance disputes, rework, for the plan and its associated Product Descriptions.
uncontrolled change, user dissatisfaction) that
could weaken or invalidate the Business Case. 6.2.3 Quality management and quality
management systems
Only after establishing the quality criteria for the
products and the quality management activities Quality management is defined as the coordinated
that have to be included in the projects plans can activities to direct and control an organization with
the full project costs and timescales be estimated. regard to quality. A quality management system is
Underestimating or omitting quality management the complete set of quality standards, procedures
activities is likely to lead to slippages, overspends and responsibilities for a site or organization.
and/or poor quality results. The Quality theme In the project context, sites and organizations
addresses the quality methods and responsibilities should be interpreted as the permanent or semi-
not only for the specification, development and permanent organization(s) sponsoring the project
approval of the projects products, but also for the work, i.e. they are external to the projects
management of the project. temporary organization. A programme, for
The Quality theme also covers the implementation instance, can be regarded as a semi-permanent
of continuous improvement during the project organization that sponsors the project, and may
for example, looking for ways to introduce more have a documented quality management system.
efficiency or effectiveness into the management of It is frequently the case that more than one
the project and the projects products. Capturing permanent organization will be involved in
and acting on lessons contributes to the PRINCE2 a project for example, separate customer
quality approach, as it is a means of achieving and supplier businesses and it follows that
continuous improvement. each may have its own quality management
system. Alternatively, if the project has a
6.2 Quality defined single key sponsoring organization, or is part
Terms used in a quality context are sometimes of a programme, a single established quality
interpreted differently or interchangeably by management system is more likely to apply. These
various people. This can lead to misunderstandings. various circumstances must be addressed when
For the purposes of PRINCE2, the terminology used determining the projects approach to quality.
48 | Quality

6.2.4 Quality planning PRINCE2 as it is the responsibility of the corporate


To control anything, including quality, there must or programme organization.
be a plan. Quality planning is about defining Quality assurance is about independently checking
the products required of the project, with their that the organization and processes are in place
respective quality criteria, quality methods for quality planning and control (i.e. not actually
(including effort required for quality control and performing the quality planning or control, which
product acceptance) and the quality responsibilities will be undertaken by the project management
of those involved. team). It provides the projects stakeholders with
confidence that the quality requirements can be
6.2.5 Quality control fulfilled.
Quality control focuses on the operational The term quality assurance is used in two senses:
techniques and activities used by those involved in
the project to: As the function within an organization (or site
or programme) that establishes and maintains
Fulfil the requirements for quality (for example, the quality management system
by quality inspections or testing) As the activity of reviewing a projects
Identify ways of eliminating causes of organization, processes and/or products
unsatisfactory performance (for example, by to assess independently whether quality
introducing process improvements as a result of requirements will be met.
lessons learned).
Note that, in both senses of the term, quality
6.2.6 Quality assurance assurance involves contributions that are
independent of the project management team,
It is good practice to arrange for quality assurance
whereas quality planning and quality control are
independent of the project management
undertaken by the project. Nevertheless, it is a
team. Quality assurance provides a check that
project management responsibility to ensure that
the projects direction and management are
adequate quality assurance is arranged.
adequate for the nature of the project and that it
complies with relevant corporate or programme Quality assurance should not be confused with
management standards and policies. Quality Project Assurance. Project Assurance refers
assurance activities are outside the scope of specifically to the Project Boards accountability

Table 6.1The relationship between Project Assurance and quality assurance


Project Assurance Quality assurance
What they do Provide assurance to the projects Provide assurance to the wider
stakeholders that the project is being corporate or programme organization
conducted appropriately and properly. that the project is being conducted
appropriately, properly and complies
with relevant corporate or programme
management standards and policies.
How they differ Must be independent of the Project Performed by personnel who are
Manager, Project Support, Team independent of the project (i.e. not a
Managers and project teams. member of the project management
team).
Responsibility of the Project Board, Responsibility of the corporate or
therefore undertaken from within the programme management organization,
project. therefore external to the project.
How they relate Quality assurance as a corporate or Quality assurance would look for (or
programme management function require) effective Project Assurance as
could be used by the Project Board as one of the indicators that the project is
part of its Project Assurance regime being conducted properly.
(for example, having quality assurance
perform a peer review).
Quality | 49

for assuring that the project is conducted properly Identify all the projects products (i.e. to the
in all respects. This is, therefore, a responsibility level at which the project intends to exert
within the project management team. Although control)
Project Assurance is independent of the Project Define them in Product Descriptions including
Manager, unlike quality assurance it is not the quality criteria by which they will be
independent of the project. However, Project assessed; the quality methods to be used in
Assurance and quality assurance do overlap, as designing, developing and accepting them; and
illustrated in Table 6.1. the quality responsibilities of those involved
Implement and track the quality methods
6.3 The PRINCE2 approach to quality employed throughout the project.

The specific treatment for quality in PRINCE2 is The first two of these are covered by quality
the focus on products from the outset, requiring planning (section 6.3.1) and the last is covered by
systematic activities to: quality control (section 6.3.2) and quality assurance
(section 6.2.6).

From customer Project response

Customers
quality expectations

Acceptance criteria

Project Product Quality Management


Description Strategy
Quality components
Quality Quality criteria
Product
planning Descriptions and tolerances

PRINCE2
product-based
planning Quality methods

technique

Quality responsibilities

Quality Register

PRINCE2 PRODUCT
quality Quality
review
technique Quality and approval
control
records

Acceptance records

Figure 6.1 The quality audit trail


50 | Quality

The PRINCE2 approach to quality can be 6.3.1.1 The customers quality expectations
summarized simply by the quality audit trail The customers quality expectations are a
depicted in Figure 6.1. The terms used in the statement about the quality expected from the
diagram are explained in the remainder of this project product. They are defined and agreed
section. early in the Starting up a Project process. The
expectations are captured in discussions with the
6.3.1 Quality planning customer and then refined for inclusion in the
The purpose of quality planning is to provide a Project Product Description.
secure basis for:
To avoid misinterpretations and inaccurate
Project Board agreement on the overall quality assumptions about the projects quality
expectations, the products required with their requirements, the customers quality expectations
associated quality criteria (including corporate should cover:
and other standards to be observed), the means
The key quality requirements for the project
by which quality will be achieved and assessed
product
and, ultimately, the acceptance criteria by which
Any standards and processes that will need
the projects product will be judged
to be applied to achieve the specified quality
Communicating these agreements
requirements, including the extent to which
unambiguously so that all the project
the customers and/or suppliers quality
stakeholders have a common understanding of
management system should be used
what the project is setting out to achieve
Any measurements that may be useful to assess
Control, i.e. establishing an effective baseline
whether the project product meets the quality
for the projects quality controls (including
requirements (for example, existing customer
the quality tolerances) and a secure means of
satisfaction measures).
achieving products that are fit for purpose.
The key quality requirements will drive the choice
When these aspects of planning are neglected, the
of solution and, in turn, influence the time, cost,
people involved in the project may have conflicting
scope, risk and benefit performance targets of the
views on the scope of the solution, on what
project.
constitutes a successful result, on the approach to
be adopted, on the extent of the work required, Examples of quality expectation
on who should be involved, and on what their roles
The quality expectation for a water pump in a
should be.
remote village is that it is robust enough to last
Quality planning comprises: a lifetime, whereas because the oil pump in a
Understanding the customers quality racing car needs to be as light as possible, it may
expectations (section 6.3.1.1) only need to last the duration of one race.
Defining the projects acceptance criteria
The customers quality expectations are often
(section 6.3.1.2)
expressed in broad terms as a means to gain
Documenting the customers quality common understanding of general quality
expectations and the projects acceptance requirements. They are then used to identify more
criteria in the Project Product Description detailed acceptance criteria, which should be
(section 6.3.1.3) specific and precise.
Formulating a Quality Management Strategy
(section 6.3.1.4) Where possible, the customers quality expectations
should be prioritized as they will be used as inputs
Writing clear Product Descriptions containing
to define quality tolerances for the projects
quality criteria, quality tolerances, quality
products.
method and quality responsibilities (section
6.3.1.5) The customers quality expectations should be
Setting up the Quality Register (section 6.3.1.6). reviewed at the end of each management stage in
case any external factors have changed them.
Quality | 51

6.3.1.2 Acceptance criteria Example of acceptance criteria


The projects acceptance criteria form a prioritized
If a customers quality expectation for a water
list of measurable definitions of the attributes
pump is that it lasts a lifetime, the acceptance
required for a set of products to be acceptable to
criteria should focus on those measures that
key stakeholders. Examples are ease of use, ease
provide sufficient indication or confidence
of support, ease of maintenance, appearance,
that the pump is capable of lasting a lifetime
major functions, development costs, running costs,
(defined as a specific number of years). This may
capacity, availability, reliability, security, accuracy,
include complying with certain engineering
and performance.
standards relating to product durability.
Acceptance criteria should be prioritized as this
helps if there has to be a trade-off between some Identifying the acceptance methods is crucial
criteria high quality, early delivery and low cost, because they address the question: how do we
for example, may not be compatible and one of prove whether and when the project product
them may need to be sacrificed in order to achieve has been completed and is it acceptable to the
the other two. customer?

Example of a prioritization technique MoSCoW 6.3.1.3 The Project Product Description


Each acceptance criterion is rated as either Must The Project Product Description is created in the
have, Should have, Could have or Wont have Starting up a Project process as part of the initial
for now (MoSCoW). scoping activity and may be refined during the
All the Must have and Should have acceptance Initiating a Project process when creating the
criteria should be mutually achievable. Project Plan. It is subject to formal change control
and should be checked at stage boundaries (during
When the project can demonstrate that all the Managing a Stage Boundary) to see if any changes
acceptance criteria have been met, the projects are required. It is used by the Closing a Project
obligations are fulfilled and the project can be process as part of the verification that the project
closed. has delivered what was expected of it and that the
acceptance criteria have been met.
The acceptance criteria should be agreed between
the customer and supplier during the Starting The Project Product Description includes:
up a Project process and documented as part of The overall purpose of the product
the Project Product Description. It is important to Its composition (i.e. the set of products it needs
recognize that little may be understood about the to comprise)
projects products at this early point. Consequently,
The customers quality expectations
it is often the case that acceptance criteria will
Acceptance criteria, method and responsibilities
be refined and agreed during the Initiating a
Project-level quality tolerances.
Project process and reviewed at the end of each
management stage. Once finalized in the Project The approved Project Product Description is
Product Description, acceptance criteria are subject included as a component of the Project Brief and
to change control and can only be changed with is used to help select the project approach. The
the approval of the Project Board. Project Product Description defines what the
In considering acceptance criteria, it is useful customer is expecting the project to deliver and the
to select proxy measures that will be accurate project approach defines the solution or method
and reliable indicators of whether benefits will to be used by the supplier to create the project
subsequently be achieved. product.
The Project Product Description is a special form
of Product Description in that it includes the
customers quality expectations and, at this level,
the quality criteria and quality methods constitute
the acceptance criteria and acceptance methods for
the project overall.
52 | Quality

6.3.1.4 The Quality Management Strategy The content of a Product Description is described
The Quality Management Strategy is prepared fully in Appendix A. The purpose section of the
during the Initiating a Project process and Product Description should clearly state who needs
approved subsequently by the Project Board. the product, why they need it and what it will do.
It augments the project approach and can be In addition to the purpose, the sections specific
regarded as the project management teams to quality are: quality criteria, quality tolerances,
proposals in response to the customers quality quality methods, quality skills required and quality
expectations and acceptance criteria. responsibilities. These define the quality controls
that must be applied during product development
The Quality Management Strategy describes and in the review and approval procedures for the
how the quality management systems of the completed product.
participating organizations will be applied to
the project and confirms any quality standards, Care should be taken not to write Product
procedures, techniques and tools that will be used. Descriptions in too much detail. They exist to help
Where models and standards are to be tailored, support the planning, development, quality and
the tailoring should also be outlined in the Quality approval methods. Product Descriptions that are
Management Strategy for approval. too detailed can lead to an unnecessary increase
in the cost of quality for the project. Incomplete
The Quality Management Strategy also provides or inaccurate Product Descriptions can lead to
a means by which the levels of formality to be acceptance disputes if the delivered results do
applied in the quality plans and controls can be not match the customers expectations. Where
scaled and agreed according to the particular necessary, the Product Description should reference
needs of the project. supporting information, such as any applicable
It should outline the arrangements for quality standards or specialist design documents.
assurance, including independent audits The time needed to create good Product
where these are required by the policies of the Descriptions will depend on factors such as how
participating organizations. important, complex and unique the product is,
Key responsibilities for quality should be defined how many stakeholders will review and approve
(both within and outside the project management the product, and whether the organization has
team), including a summary of the approach to a library of standard Product Descriptions for
Project Assurance. reuse. Product Description libraries are frequently
implemented by PRINCE2 users, to promote
Where there is already an established quality
consistency and reuse.
management system for projects, for example in
a programme, only the measures specific to this Quality criteria
project may need to be documented. The Product Description should include the quality
The Quality Management Strategy is maintained, specifications that the product must meet, and the
subject to change control, throughout the life of quality measurements that will be applied by those
the project. inspecting the finished product.
The quality criteria should be of sufficient detail
6.3.1.5 Product Descriptions and clarity to enable those reviewing a product to
Once detailed planning gets underway, Product unambiguously confirm whether the product meets
Descriptions should be created for all of the its requirements.
projects products. Product Descriptions are
Quality tolerances
not optional. They govern the development of
the products and their subsequent review and Quality tolerances for a product can be specified in
approval. quality criteria by defining an acceptable
range of values. For example: Is the duration
The level of detail in a Product Description is of the presentation 30 minutes (plus or minus
a matter of judgement, with the primary aim 5 minutes)?, Is temperature maintained in the
being to select a level that provides a secure and range of 1 to 5C?
appropriate measure of control sufficient to fulfil
the customers quality expectations.
Quality | 53

methods, these should also be specified. There are


Example of quality criteria
two primary types of quality methods: in-process
Consider a project to design and manufacture methods and appraisal methods (see section 6.3.2.1).
a new camera. One quality criterion is that the
camera and its packaging must weigh no more Quality responsibilities
than 1 kg. The product breakdown structure To avoid doubt, the quality responsibilities for a
identifies a user guide product. It follows that product should be specified. The responsibilities
the size and weight of the user guide is an will fall into one of three categories:
important factor and not, for example, the Producer The person or group responsible for
number of pages. developing a product
Questions to be asked include: What is the Reviewer(s) A person or group independent of
target market for the camera? Does this also the producer who assesses whether a product
imply that the manual needs to be written meets its requirements as defined in its Product
in several languages? Will that mean it gets Description
heavier? Or will a CD-ROM-based manual Approver(s) The person or group, for example
suffice? This could reduce the weight of the a Project Board, who is identified as qualified
manual and allow the camera itself to be and authorized to approve a product as being
heavier. complete and fit for purpose.
Considering quality criteria often highlights
connections and factors such as these which 6.3.1.6 The Quality Register
inform the subsequent planning process. The Quality Register is effectively a diary of the
quality events planned and undertaken (for
Quality methods example, workshops, reviews, inspections, testing,
The quality methods section of the Product pilots, acceptance and audits). It is created during
Description is used to specify the quality activities the Initiating a Project process as the products and
to be implemented during the development of a quality control measures are being defined. It is
product, for review and approval on completion. then maintained (in line with the current baseline
Where specialized skills are implicit in the quality plans) throughout the project.

Table 6.2Example of a Quality Register


Quality Activity ID

Target Approval

Actual Approval
Quality Method

Target Review

Actual Review
Approver(s)
Reviewer(s)
Product ID

Producer
Product

Result
Date

Date

Date

Date

1 121 Test Inspection Ali Paulo John, 14-Feb 21-Feb 21-Feb 28-Feb Pass
Plan Rita

2 124 Water Performance Paulo Ali, John 20-Mar 20-Mar 27-Mar NA Fail
Pump Test Bob

3 124 Water Maintenance Paulo Ali, Rita 21-Mar 21-Mar 27-Mar 27-Mar Pass
Pump Test Amir

. . . . . . . . . . . .
. . . . . . . . . . . .
9 124 Water Performance Paulo Ali, John 14-Jun 21-Jun
Pump Test Bob
54 | Quality

As the project progresses and records of the quality inspections during the course of product
quality activities are received, the Quality Register development as well as upon completion
is updated to reflect (in summary form) the Appraisal methods These are the means by
actual results from the quality activities. The which the finished products are assessed for
Quality Register provides key audit and assurance completeness and fitness for purpose. There
information, relating what was planned and are, in essence, two types of appraisal methods,
agreed (in the Quality Management Strategy depending on the extent to which it is possible
and Product Descriptions) to the quality activities to define objective quality criteria: testing
actually performed. (if the quality criteria are truly objective and
The amount of information included in the quantifiable) or quality inspection (if some
Quality Register can vary considerably, depending subjective judgement is required).
on the extent to which quality metrics (e.g. A quality inspection is a systematic, structured
defect counts) need to be analysed for process assessment of a product conducted in a planned,
improvement purposes. An example of a Quality documented and organized fashion. A systematic
Register is shown in Table 6.2. but flexible approach to quality inspection can be
used:
6.3.2 Quality control
During the development of products of
Quality control is achieved by implementing, this type, whether formally (i.e. in line with
monitoring and recording the quality methods what was agreed during quality planning) or
and responsibilities defined in the Quality informally (simply as a means of assessing the
Management Strategy and Product Descriptions quality of a work in progress)
(and subsequently agreed to in Work Packages).
To mark the completion and approval of
Quality control comprises: products
To complement testing, e.g. simply for checking
Carrying out the quality methods (section
6.3.2.1) test results.
Maintaining quality and approval records Quality inspection techniques are particularly
(sections 6.3.2.2 and 6.3.2.3) applicable when professional judgement is
Gaining acceptance (section 6.3.2.4). required to assess the products fitness for purpose.
The techniques can be used within the project,
6.3.2.1 Quality methods as quality controls, and by independent experts,
The cost of correcting flaws in products increases as part of quality assurance. Peer and gateway
the longer they remain undetected. It is much reviews are examples of quality assurance activities
easier and cheaper to correct a design document that can be implemented by using or adapting a
early in the project than to correct a design fault generic inspection technique. Used as a project
that is only discovered when the finished product management team control, conducting systematic
is being tested or, worse, when the product is quality inspections can also have valuable team-
already in operational use. It follows that quality building side-benefits.
inspections, implemented early in the design and Even when testing is the primary appraisal method,
development process, are potentially the most cost- it is often the case that someone has to check that
effective quality methods available. the test results meet the criteria for success and so
There are two types of quality methods: a simple inspection is still required.

In-process methods These are the means


There are a variety of systematic inspection
by which quality can be built into the techniques, some being specific to certain
products as they are developed. These might industries or types of product. PRINCE2
involve the use of specialist methods and/ accommodates the use of these techniques, but
or techniques, including calibrated process also provides a useful quality review technique,
controls, automation (e.g. robotics, software which complements the use of PRINCE2 Product
tools), piloting exercises, workshops, surveys Descriptions.
and consultation, or, more simply, the use of
Quality | 55

The PRINCE2 quality review technique Check the product is ready for review and
confirm the availability of the reviewers
Objectives
(chair)
To assess the conformity of a product which Distribute copies of the product and the
takes the form of a document (or similar relevant Product Description to the review
item, e.g. a presentation or test results) team, allowing sufficient time for reviewers
against set criteria to prepare (presenter)
To involve key interested parties in checking Review the product in line with the quality
the products quality and in promoting wider criteria in the associated Product Description
acceptance of the product (reviewers)
To provide confirmation that the product is Submit a question list to the chair and
complete and ready for approval presenter ahead of the review (reviewers)
To baseline the product for change control Annotate the product copy where there are
purposes. spelling/grammar mistakes and return to the
Review team roles presenter (reviewers)
Produce a consolidated question list (chair)
Chair This role is responsible for the overall
and send to the presenter in advance of the
conduct of the review
meeting.
Presenter This role introduces the product
for review and represents the producer(s) of Review meeting agenda
the product. The presenter also coordinates Personal introductions, if necessary (chair)
and tracks the work after the review, i.e. Product introduction (presenter) A very brief
applying the changes to the product agreed summary, covering the products purpose:
by the team who needs it, why they need it and what it
Reviewer This role reviews the product, will do
submits questions and confirms corrections Major/global questions (chair) Invite each
and/or improvements reviewer to contribute any major or global
Administrator This role provides questions with the product. Global questions
administrative support for the chair and are ones that appear repeatedly throughout
records the result and actions. the product. The review team agrees any
The minimum form of review (used for simple action on each question as it is raised.
inspections, e.g. of test results) involves only two The administrator records the actions and
people: one taking the chair and reviewer roles, responsibilities
the other taking the presenter and administrator Product talk-through (presenter) Lead the
roles. review team through the product section by
section or page by page, as appropriate, by
Note: quality review is a generic technique which
reviewing the consolidated question list and
can be used outside the project context. Thus the
inviting clarification where required. The
quality review roles have no specific relationship
review team agrees actions on each question
to roles in the project management team
as it is raised. The administrator records the
structure. However, team-building benefits can
actions and responsibilities
be realized where Project and Team Managers
Read back actions (administrator) Confirm
regularly chair reviews. Chairing quality
the actions and responsibilities
reviews requires competence in facilitation and
independence of the product being reviewed Determine the review result (chair) Lead
(the primary responsibility is to ensure that the the review team to a collective decision. The
review is undertaken properly). options are:
Complete (the product is fit for purpose,
Review preparation
as is)
Make the administrative arrangements for Conditionally complete (the product is fit
the review (chair/administrator) for purpose subject to the actions)
56 | Quality

Incomplete (the product requires another


products. If it appears that there may be a
quality review cycle) problem associated with a related product,
Close the review (chair) handle it outside the meeting as an issue
Inform interested parties of the result (chair). Chair Make sure the reviewers contribute
effectively. It is your responsibility to ensure
Review follow-up
that the approved product is fit for purpose
Coordinate the actions (presenter) Chair If a reviewer cannot attend the
Sign off individual actions (reviewers, as review, accept the question list from them
agreed at the meeting) and either raise the questions on their
Once all actions are complete, sign off that behalf, accept a delegate or replace the
the product is now complete (chair) reviewer
Communicate the quality review outcome Presenter It may be that a follow-up action
to appropriate managers/support personnel is not feasible to implement or cannot be
(administrator) done within agreed tolerances, in which
Store the quality records (administrator) case an issue should be raised to the Project
Request approval for the product (presenter). Manager
Approver If the person (or group) who
Hints and tips will approve the product participates in the
Reviewers Review the product not the quality review, it may be possible to approve
person. This means avoid personalizing issues the product as part of the review.
(You ) and operate as a team (We )
Reviewers Operate as a team but defer to The formal approval of a product may or may not
specialist areas of expertise. Some reviewers result from a quality review. Products that have
may be selected to address specific aspects been signed off as complete at an inspection or
of the product and their comments may be review may still have to be submitted to a separate
considered to carry more weight in those authority for approval.
areas
Reviewers Do not introduce trivia at The PRINCE2 quality review technique (and other
reviews (spelling, punctuation etc.) unless it is quality inspection techniques) can yield substantial
a major/global issue (e.g. if the document will side-benefits, particularly in terms of:
be communicated to an important audience, Stakeholder engagement Quality inspections
such as the public) are opportunities for effective cross-functional
Chair Encourage the presenter to maintain communication. Many important stakeholders
a steady pace during the product talk- may only have direct contact with the project
through. The reviewers must have the through these reviews, so they provide a
opportunity to introduce their issues but window into the project. This is particularly
allowing too much time invites comments true for users. Structured quality inspections are
that would not otherwise be made. The among the most effective ways of encouraging
presenter should not be opening discussions buy-in to the project. Generally, the more
unnecessarily systematic and effective the reviews, the better
Chair Resolve each point as it is raised by the impression for the stakeholders
getting a decision from the review team. Leadership In many circumstances a focus
Does the product have to be changed or not? on quality (as in fitness for purpose) elicits a
Do not allow discussions to drift. Remember, better response from review team members
the purpose of the review is to identify (and users) than simply focusing on budgets
defects, not to design solutions to them. and schedules. Quality inspection techniques
Avoid the temptation to formulate and agree often provide excellent tips and soft guidance
solutions. These should be done post-review on effective behaviour and decision making in
Chair Focus on this product. Do not allow meetings
discussion to drift onto other related
Quality | 57

Team building Formal and informal quality experience. For example, quality metrics, such as
inspections are opportunities to focus on defect types and trends, can be used as a source for
building an effective project team, where lessons learned and process improvements.
members understand each others contributions,
needs and priorities 6.3.2.3 Approval records
Developing individuals New starters learn While quality records provide evidence that each
from more experienced personnel and spot product has met its requirements as specified in its
omissions that others take for granted. Product Description, it is good practice to obtain a
Experienced personnel learn from the fresh record that the product has been approved.
perspectives brought by newcomers
PRINCE2 does not specify the format or composition
Quality documentation Consistent and
of approval records as these will depend on the
familiar quality records make for improvements
level of formality required, the customer/supplier
in communication and in the analysis of quality
relationship and the quality management system of
metrics
the organizations involved. The format for approval
Quality culture The PRINCE2 quality review
records could include, for example, a note in the
technique is generic. It can be employed on minutes of a meeting, an email, a letter, a signature
programmes, projects and services throughout on a document, or a certificate.
an organization, resulting in a positive and
familiar quality culture. 6.3.2.4 Acceptance records
Products are approved throughout the life of the
6.3.2.2 Quality records
project and ownership may even be transferred
It is important that evidence is gathered to to the customer as part of a phased handover.
demonstrate that the planned quality activities But, during the Closing a Project process, it is
have been carried out. The records support entries important to check that all forms of approval have
in the Quality Register by providing the Project been obtained and records kept for audit and/or
Manager and the Project Board with assurance contractual purposes.
that:
PRINCE2 uses the term acceptance to describe
Products really are complete (and consequently
the ultimate approval of the projects product.
that the related activities are finished) Acceptance is frequently required from more
Products have met their associated quality than one set of stakeholders, e.g. those using the
criteria and are fit for their intended purposes projects products and those maintaining them
(alternatively there are records of any quality (in which case both categories of stakeholder
failures and corrective action) should have been involved in defining the relevant
The agreed processes have been observed products, participating in quality inspections and
Approval authorities and key product granting approval during the course of the project).
stakeholders are satisfied
Acceptance may be qualified, and documented
Planned audits have been conducted and
concessions can be granted (e.g. if there are
reported. faults in the solution or some performance criteria
Quality records should include references to the have not been fully achieved). Where concessions
quality inspection documentation, such as a test have been granted by the Project Board, it may
plan; details of any defect statistics and actions be necessary to recommend follow-on actions for
required to correct errors and omissions of the later improvements or remedies for the products
products inspected; and any quality-related reports concerned.
(for example, an audit). When these records are
received by Project Support, the Quality Register 6.4 Responsibilities
entries for the relevant products can be completed.
During the project and at project closure, the Table 6.3 outlines the responsibilities relevant to
quality records provide a valuable source of the Quality theme. Refer to Appendix C for further
information for analysis in accordance with the details of project management team roles and their
PRINCE2 principle that projects should learn from associated responsibilities.
58 | Quality

Table 6.3Responsibilities relevant to the Quality theme


Role Responsibilities
Corporate or Provide details of the corporate or programme quality management system.
programme Provide quality assurance.
management
Executive Approve the Project Product Description.
Approve the Quality Management Strategy.
Confirm acceptance of the project product.
Senior User Provide the customers quality expectations and acceptance criteria.
Approve the Project Product Description.
Approve the Quality Management Strategy.
Approve Product Descriptions for key user products.
Provide resources to undertake user quality activities and product approval.
Provide acceptance of the project product.
Senior Supplier Approve the Project Product Description (if appropriate).
Approve the Quality Management Strategy.
Approve the quality methods, techniques and tools adopted in product development.
Provide resources to undertake supplier quality activities.
Approve Product Descriptions for key specialist products.
Project Manager Document customers quality expectations and acceptance criteria.
Prepare the Project Product Description (with users).
Prepare the Quality Management Strategy.
Prepare and maintain the Product Descriptions.
Ensure that Team Managers implement the quality control measures agreed in Product
Descriptions and Work Packages.
Team Manager Produce products consistent with Product Descriptions.
Manage quality controls for the products concerned.
Assemble quality records.
Advise the Project Manager of product quality status.
Project Assurance Advise the Project Manager on the Quality Management Strategy.
Assist the Project Board and Project Manager by reviewing the Product Descriptions.
Advise the Project Manager on suitable quality reviewers/approvers.
Assure Project Board members on the implementation of the Quality Management Strategy, i.e.
the proper conduct of the project management and quality procedures.
Project Support Provide administrative support for quality controls.
Maintain the Quality Register and the quality records.
Assist Team Managers and members with the application of the projects quality processes.
Plans 7
7 Plans

7.1 Purpose A plan must therefore contain sufficient


information and detail to confirm that the targets
The purpose of the Plans theme is to facilitate
are achievable.
communication and control by defining the
means of delivering the products (the where Plans are the backbone of the management
and how, by whom, and estimating the when information system required for any project. It
and how much). is important that plans are kept in line with the
Business Case at all times. A plan requires the
Effective project management relies on effective approval and commitment of the relevant levels of
planning as without a plan there is no control. the project management team.
Planning provides all personnel involved in the
project with information on: 7.2.2 What is planning?
What is required Planning is the act or process of making and
How it will be achieved and by whom, using maintaining a plan. The term is also used to
what specialist equipment and resources describe the formal procedures used in this
When events will happen exercise, such as the creation of documents and
diagrams. Planning is essential, regardless of the
Whether the targets (for time, cost, quality,
type or size of the project; it is not a trivial exercise
scope, risk and benefits) are achievable.
but is vital to the success of the project.
The development and maintenance of credible
Without effective planning, the result of complex
plans provides a baseline against which progress
projects cannot be predicted in terms of scope,
can be measured. They enable planning
quality, risk, timescale, cost and benefits. Those
information to be disseminated to stakeholders in
involved in providing resources cannot optimize
order to secure any commitments which support
their operations.
the plan.
Poorly planned projects cause frustration, waste
The very act of planning helps the project
and rework. It is therefore essential to allocate
management team to think ahead to mentally
sufficient time for the planning stage.
rehearse the project. It is such rehearsal that
enables omissions, duplication, threats and PRINCE2 requires a product-based approach to
opportunities to be identified and managed. planning.
The Plans theme provides a framework to design,
develop and maintain the projects plans (Project
7.2.3Levels of plan
Plan, Stage Plans and Team Plans). All aspects of planning become more difficult the
further into the future they extend. The period of
time for which it is possible to accurately plan is
7.2 Plans defined known as the planning horizon. Because of this, it
is seldom desirable, or possible, to plan an entire
7.2.1 What is a plan? project in detail at the start. Therefore plans need
When asked to describe a plan, many people think to be produced at different levels of scope and
of a chart showing timescales. detail (see section 2.4).
A PRINCE2 plan is more comprehensive. It is a PRINCE2 recommends three levels of plan to reflect
document describing how, when and by whom a the needs of the different levels of management
specific target or set of targets is to be achieved. involved in the project, stage and team. A Product
These targets will include the projects products, Description for a plan can be found in Appendix A.
timescales, costs, quality and benefits.
PRINCE2s planning levels are illustrated in Figure 7.1.
62 | Plans

Corporate or
programme plan

Project Plan

(Initiation) (Delivery)
Exception Plans
Stage Plan Stage Plans
as necessary

Team Plans

Figure 7.1 PRINCE2s planning levels

The Project Plan is created by the Initiating a Should align with the corporate or programme
Project process. managements plan.
The Initiation Stage Plan is created by the Starting
up a Project process and each subsequent Stage
7.2.5Stage Plans
Plan is created by the Managing a Stage Boundary A Stage Plan is required for each management
process. Note that since the Initiation Stage Plan is stage. The Stage Plan is similar to the Project Plan
created prior to the Project Plan, it is influenced by in content, but each element will be broken down
the corporate or programme plan (or equivalent) to the level of detail required to be an adequate
from the organization commissioning the project. basis for day-to-day control by the Project
Manager.
Team Plans are created by the Managing Product
Delivery process. Each Stage Plan for the next management stage is
produced near the end of the current management
The only other plan in PRINCE2 is the Benefits stage. This approach allows the Stage Plan to:
Review Plan (see Chapter 4 for more details).
This covers activities during and after the project Be produced close to the time when the
and therefore may be part of a corporate or planned events will take place
programme plan. The Benefits Review Plan covers Exist for a much shorter duration than the
corporate, project and stage levels. Project Plan (thus overcoming the planning
horizon issue)
7.2.4 The Project Plan Be produced with the knowledge of the
The Project Plan provides a statement of how performance of earlier management stages.
and when a projects time, cost, scope and See Chapter 10 for further guidance on
quality performance targets are to be achieved, partitioning a project into management stages.
by showing the major products, activities and
resources required for the project. The Project Plan: 7.2.6 Team Plans
Provides the Business Case with planned project A Team Plan is produced by a Team Manager to
costs and timescales, and identifies the major facilitate the execution of one or more Work
control points, such as management stages and Packages. Team Plans are optional; their need
milestones and number will be determined by the size and
Is used by the Project Board as a baseline complexity of the project and the number of
against which to monitor project progress stage resources involved.
by stage
Plans | 63

PRINCE2 does not prescribe the format or replace the plan that is in exception and it will
composition of a Team Plan. There may be more become the new baselined Project Plan or current
than one team on a project and each team may Stage Plan, as appropriate.
come from separate organizations following
If a Stage Plan is being replaced, this needs the
different project management standards (not
approval of the Project Board. Replacement of
necessarily PRINCE2). In some customer/supplier
a Project Plan should be referred by the Project
contexts it could even be inappropriate for the
Board to corporate or programme management if
Project Manager to see the details of a suppliers
it is beyond the authority of the Project Board.
Team Plan; instead, summary information would
be provided sufficient for the Project Manager to An Exception Plan is prepared to the same level of
exercise control. Therefore the formality of the detail as the plan it replaces. It picks up from the
Team Plan could vary from simply appending a current plan actuals and continues to the end of
schedule to the Work Package to a fully formed that plan. Exception Plans are not produced for
plan in similar style to a Stage Plan. Work Packages. Should a Team Manager forecast
that the assigned Work Package may exceed
The Team Manager(s) may create their Team Plans
tolerances, they will notify the Project Manager by
in parallel with the Project Manager creating the
raising an issue. If the issue relating to the Work
Stage Plan for the management stage.
Package can be resolved within stage tolerances,
the Project Manager will take corrective action by
7.2.7Exception Plans updating the Work Package or issuing a new Work
An Exception Plan is a plan prepared for the Package(s) and instructing the Team Manager(s)
appropriate management level to show the actions accordingly.
required to recover from the effect of a tolerance
deviation. If approved, the Exception Plan will For more explanation of the types and the use of
tolerance in PRINCE2, see Chapter 10.

Design the plan


(7.3.2) Prerequisite

Define and analyse the products


(7.3.3)

Identify activities and dependencies


Analyse the risks

(7.3.4)
(7.3.7)

Repeated for:
Prepare estimates
Project Plan
(7.3.5)
Stage Plan
Team Plan (optional)

Prepare the schedule


(7.3.6)

Document the plan


(7.3.8)

Figure 7.2 The PRINCE2 approach to plans


64 | Plans

7.3 The PRINCE2 approach to plans Where the project is part of a programme, the
programme may have developed a common
7.3.1 Philosophy approach to project planning. This may cover
The philosophy behind producing plans in PRINCE2 standards for example, level of planning and
is that the products required are identified first, tools. These will be the starting point for designing
and only then are the activities, dependencies any Project Plan. Any project-specific variations
and resources required to deliver those products should be highlighted and the agreement of
identified. This is known as product-based planning programme management sought. There may also
and is used for the Project Plan, the Stage Plan and, be a company standard for planning and control
optionally, the Team Plan. Figure 7.2 illustrates the aids, or the customer may stipulate the use of a
steps required in producing a PRINCE2 plan. particular set of tools. The choice of planning tool
may depend on the complexity of the project
Each step in the planning procedure may need hence the choice may need to be deferred until the
to be revisited on completion of later steps (for level of complexity is known.
example, in preparing the schedule if additional
activities or dependencies are identified). The estimating methods to be used in the plan may
affect the plan design, so decisions on the methods
should be made as part of the plan design itself.
7.3.2Prerequisites for planning design
the plan The use of planning tools is not obligatory, but it
Decisions need to be made about how the plan can save a great deal of time if the plan is to be
can best be presented, given the audience for the regularly updated and changed. A good tool can
plan and how it will be used, together with the also validate that the correct dependencies have
presentation and layout of the plan, planning been built in and have not been corrupted by any
tools, estimating methods, levels of plan, and plan updates.
monitoring methods to be used for the project.
This will include the use of diagrams versus text 7.3.3Define and analyse the products
and will be driven, in part, by any standards PRINCE2 uses a technique known as product-based
adopted by the project. planning to identify, define and analyse the plans
products, as shown in Figure 7.3.

Write the Project Product Description


For Project Plan only
(7.3.3.1)

Create the product breakdown structure


(7.3.3.2)

Write the Product Descriptions For all levels of plan


(7.3.3.3)

Create the product flow diagram


(7.3.3.4)

Figure 7.3 Product-based planning technique


Plans | 65

Product-based planning is likely to be iterative. In See Appendix A for the suggested composition of
the case of Product Descriptions, this means that at the Project Product Description.
first it may comprise simply a title and a statement
of purpose. Therefore, in the following note, 7.3.3.2Create the product breakdown
write (as in write a Product Description) should structure
be interpreted as meaning commence to write,
The plan is broken down into its major products,
and proceed to complete as fully as appropriate as
which are then further broken down until an
soon as convenient.
appropriate level of detail for the plan is reached.
The format and presentation of the product A lower-level product can be a component of only
breakdown structure and product flow diagram is one higher-level product. The resultant hierarchy
determined by personal preference. See Appendix of products is known as a product breakdown
D for examples. structure.
The benefits of product-based planning include: When creating a product breakdown structure,
consider the following:
Clearly and consistently identifying and
documenting the plans products and the It is usual to involve a team of people in the
interdependencies between them. This reduces creation of a product breakdown structure,
the risk of important scope aspects being perhaps representing the different interests and
neglected or overlooked various skill sets involved in the plans output
Removing any ambiguity over expectations It is common to identify products by running a
Involving users in specifying the product structured brainstorming session (for example,
requirements, thus increasing buy-in and using sticky notes or a whiteboard) to capture
reducing approval disputes each product as it is identified
Improving communication: the product When a team is creating a product breakdown
breakdown structure and product flow diagram structure, there is likely to be discussion on
provide simple and powerful means of sharing the way in which to break down the products.
and discussing options for the scope and For example, if the output of the plan is a
approach to be adopted for the project computerized accounts system, users might
Clarifying the scope boundary: defining want to separate the system into Accounts
products that are in and out of the scope for Payable, Accounts Receivable, General Ledger
the plan and providing a foundation for change etc. The suppliers, however, may prefer Screens,
control, thus avoiding uncontrolled change or Reports, Databases etc. Neither breakdown is
scope creep wrong, but the project management team must
Identifying products that are external to the reach a consensus on which approach will be
plans scope but are necessary for it to proceed, used in the product breakdown structure (and
and allocating them to other projects or hence the plan)
organizations It is useful to identify any external products
Preparing the way for the production of Work required by the plan. External products already
Packages for suppliers exist or are being created or updated outside
of the scope of the plan and are required
Gaining a clear agreement on production,
in order to create one or more of the plans
review and approval responsibilities.
products. For example, a procurement project
would show the bidders tender responses
7.3.3.1 Write the Project Product Description
as external products. The Project Manager is
The first task of product-based planning is to not accountable for the creation of external
write the Project Product Description. Although products as they will be supplied by parties
the Senior User is responsible for specifying the external to the project management team.
project product, in practice the Project Product For each external product there should be
Description is often written by the Project Manager a corresponding entry on the Risk Register
in consultation with the Senior User and Executive. detailing the threat to the plan if they are late
Every effort should be made to make this Product or not to the required specification. Consider
Description as complete as possible at the outset. whether external products require Product
66 | Plans

Descriptions to reduce the likelihood of them or subtle differences in the quality criteria;
not providing whats expected of them the locations may be different, or the people
When using product-based planning, it is and responsibilities involved may be different.
important to consider whether to include Moreover, lifecycle models frequently address
different states of a particular product. An only one aspect of a projects scope.
example of product states is dismantled
machinery, moved machinery and reassembled 7.3.3.3 Write the Product Descriptions
machinery. It could be appropriate to identify A Product Description is required for all the
the different states as separate products, where identified products. When creating a Product
each state would require its own Product Description, consider the following:
Description with different quality criteria
Product Descriptions should be written as soon
and quality controls. This may be particularly
as possible after the need for the product has
useful when the responsibility for creating
been identified. Initially, these may only be
each state will pass from one team to another.
skeletons with little more than the title and
Alternatively, a single Product Description
identifier as information. They will be refined
could be used with a set of quality criteria that
and amended as the product becomes better
the product needs to meet in order to gain
understood and the later planning steps are
approval for each state
done
When presenting the product breakdown
A Product Description should be baselined
structure, consider the use of different shapes,
when the plan containing the creation of that
styles or colours for different types of product.
product is baselined. If the product is later
For example, a rectangle could be used in a
changed, the Product Description must also pass
product breakdown structure to represent most
through change control
types of product, but it may be helpful to use
different shapes such as ellipses or circles to Although the responsibility for writing
distinguish external products. Colours could be Product Descriptions rests officially with the
used to indicate which team is responsible for Project or Team Manager, it is wise to involve
the product or in which stage the product will representatives from the area with expertise in
be created the product and those who will use the product
in question. The latter should certainly be
If the project is broken down into several
consulted when defining the quality criteria for
stages, the products for each stage are
the product
extracted from the project product breakdown
structure to form the stage product breakdown Successful Product Descriptions may be reused
structure. These may be expanded to more for other projects within that programme or
levels of detail and thus extra products may organization. For this to happen, a library of
be added to give the detail required of the Product Descriptions for reuse will need to
Stage Plan. Care must be taken to use the same be established and a mechanism for Product
names in the Stage Plan diagrams as were used Descriptions to be placed in the library will also
in the Project Plan. The creation of Stage Plan need to be implemented. The Project Manager
diagrams may cause rethinking that requires should therefore refer to the library in order to
further modification of the Project Plans see if any of the Product Descriptions within it
diagrams in order to retain consistency are suitable for reuse and/or modification for
the project
In some cases, the organizations lifecycle model
may have a preset product breakdown structure If a detailed requirements specification for a
and product flow diagram for common types product is already available, this may be used
of projects and a library of Product Description as a substitute for the Product Description as
outlines for common products. In such cases the long as the requirements specification covers
steps in the PRINCE2 product-based planning the components and meets the quality criteria
technique should not be skipped but used to expected of a Product Description. Alternatively
verify the completeness of any library material. a Product Description should be created
As every project is unique, there may be referencing the requirements specification
additional product requirements for this project contents where appropriate
Plans | 67

For a small project, it may only be necessary to any from being overlooked. The symbol
write the Project Product Description becomes the predecessor for all entry points
Quality criteria, aimed at separating an and would be the only symbol on a product
acceptable product from an unacceptable one, flow diagram that is not on the product
need careful thought. One way of testing breakdown structure.
quality criteria is by asking the question: how
will I know when work on this product is 7.3.4Identify activities and dependencies
finished as opposed to stopped?
7.3.4.1 Activities
7.3.3.4 Create the product flow diagram Simply identifying products may be insufficient
A product flow diagram needs to be created to for scheduling and control purposes. The activities
identify and define the sequence in which the required to create or change each of the planned
products of the plan will be developed and any products need to be identified to give a fuller
dependencies between them. picture of the plans workload.

The product flow diagram also identifies There are several ways to identify activities,
dependencies on any products outside the scope of including:
the plan. It leads naturally into consideration of the Making a separate list of the activities, while
activities required, and provides the information still using the product flow diagram as the
for other planning techniques, such as estimating source of the information
and scheduling. Taking the products from the product
When creating a product flow diagram, consider breakdown structure and creating a work
the following: breakdown structure to define the activities
required.
Although the Project or Team Manager is
responsible for the creation of the product flow The activities should include management and
diagram, it is sensible to involve those who quality-checking activities as well as the activities
are to develop or contribute to the products needed to develop the specialist products. The
contained in the plan activities should include any that are required
Rather than preparing the product flow to interact with external parties for example,
diagram once the product breakdown structure obtaining a product from an outside source or
has been drawn, some planners prefer to create converting external products into something that
the product flow diagram in parallel with the the plan requires.
product breakdown structure Guard against a proliferation of activities beyond
A product flow diagram needs very few the detail appropriate to the level of the plan. If in
symbols. Each product to be developed within doubt, keep things simple.
the plan in question is identified (for example,
it may be enclosed in a rectangle), and the 7.3.4.2 Dependencies
sequence in which they are to be created is Any dependencies between activities (and
shown (the rectangles may be connected by products) should also be identified. There are
arrows, for example). Any products that already two types of dependency: internal and external.
exist or that come from work outside the scope An example of an internal dependency is that
of the plan should be clearly identified as activity C cannot start until activities A and B have
external products (for example, they may be been completed. External dependencies may, for
enclosed in a different shape, such as an ellipse) example, be:
It may be useful to add a starting point in the
The delivery of a product required by this
product flow diagram from which all entry
project from another project
points are attached. There is always one exit
on a product flow diagram but when there are The provision of a purchase order by the user
many entrances, such a place marker prevents A decision from programme management.
68 | Plans

Examples of estimating techniques Delphi technique This relies on obtaining


group input for ideas and problem solving
Top-down estimating Once a good overall
without requiring face-to-face participation.
estimate has been arrived at for the plan
It uses a series of questionnaires interspersed
(by whatever means), it can be subdivided
with information summaries and feedback
through the levels of the product breakdown
from preceding responses to achieve an
structure. By way of example, historically
estimate.
development may be 50% of the total and
testing may be 25%. Subdivide development
and testing into their components and
7.3.5 Prepare estimates
apportion the effort accordingly
A decision about how much time and resource are
Bottom-up estimating Each individual
required to carry out a piece of work to acceptable
piece of work is estimated on its own merit.
standards of performance must be made by:
These are then summed together to find the
estimated efforts for the various summary Identifying the type of resource required.
level activities and overall plan Specific skills may be required depending
Top-down and bottom-up approach An on the type and complexity of the plan.
overall estimate is calculated for the plan. Requirements may include non-human
Individual estimates are then calculated, or resources, such as equipment, travel or money
drawn from previous plans, to represent the Estimating the effort required for each activity
relative weights of the tasks. The overall by resource type. At this point, the estimates
estimate is then apportioned across the will be approximate and therefore provisional.
various summary and detailed-level tasks
Estimating cannot guarantee accuracy but, when
using the bottom-up figures as weights
applied, provides a view about the overall cost and
Comparative estimating Much data time required to complete the plan. Estimates will
exist about the effort required and the inevitably change as more is discovered about the
duration of particular items of work. Over project.
time an organization may build up its own
historical data regarding projects that it has Estimates should be challenged, as the same
undertaken (previous experience or lessons work under the same conditions can be estimated
learned). Where such data exists, it may be differently by various estimators or by the same
useful to reference it for similar projects and estimator at different times.
apply that data to the estimates
Parametric estimating Basing estimates Basic rules for estimating
on measured/empirical data where possible Many books and software packages include
(for example, estimating models exist some basic rules to help ensure that an accurate
in the construction industry that predict and realistic estimate is produced. Examples of
materials, effort and duration based on the such planning rules include:
specification of a building)
Assume that resources will only be
Single-point estimating The use of sample
productive for, say, 80% of their time
data to calculate a single value which is to
Resources working on multiple projects take
serve as a best guess for the duration of an
longer to complete tasks because of time
activity
lost switching between them
Three-point estimating Ask appropriately
People are generally optimistic and often
skilled resource(s) for their best-case, most
underestimate how long tasks will take
likely and worst-case estimates. The value
that the Project Manager should choose Make use of other peoples experiences and
is the weighted average of these three your own
estimates Ensure that the person responsible for
creating the product is also responsible for
creating the effort estimates
Plans | 69

This is an iterative task as the assigning of actual


Always build in provision for problem
resources may affect the estimated effort and
solving, meetings and other unexpected
duration.
events
Cost each activity rather than trying to cost The amount of time that an activity can be delayed
the plan as a whole without affecting the completion time of the overall
Communicate any assumptions, exclusions or plan is known as the float (sometimes referred
constraints you have to the user(s). to as the slack). Float can either be regarded as a
provision within the plan, or as spare time.

7.3.6 Prepare the schedule The critical path(s) through the diagram is the
A plan can only show the ultimate feasibility of sequence of activities that have zero float. Thus, if
achieving its objectives when the activities are any activity on the critical path(s) finishes late, then
put together in a schedule that defines when the whole plan will also finish late (for example, if
each activity will be carried out. There are many task 4 in Figure 7.4 is delayed, then completion of
different approaches to scheduling. Scheduling can the plan will be delayed).
either be done manually or by using a computer- Identifying a plans critical path enables the Project
based planning and control tool. Manager to monitor those activities:

7.3.6.1 Define activity sequence That must be completed on time for the whole
plan to be completed to schedule
Having identified the activities, their dependencies
That can be delayed for a time period if
and estimated their duration and effort, the next
resources need to be re-allocated to catch up
task is to determine the optimal sequence in which
on missed activities.
they can be performed.

Arrows show dependencies

Activities are shown as boxes


Task 3 cannot begin until both
Tasks 1 and 2 have been completed

Task 1 Task 3

Start Task 5 End

Task 2 Task 4

Task 4 is a predecessor to Task 5


and a successor to Tasks 1 and 2

ES = Earliest start time for the activity


D = Duration of the activity
EF = Earliest finish time for the activity
LS = Latest start time for the activity
TF = Total float for the activity
ES = 18 D=5 EF = 23 LF = Latest finish time for the activity

Task 4

LS = 18 TF = 0 LF = 23

Figure 7.4 Simple activity-on-node diagram


70 | Plans

they understand what it means to complete the


Example of activity-on-node technique
task.
An activity-on-node diagram (sometimes called
When assigning resources, it is important to
an arrow diagram) can be used to schedule
re-check the critical path as actual resources
dependent activities within a plan. It helps a
assigned may be more or less productive than the
Project Manager to work out the most efficient
assumption made when calculating activity effort
sequence of events needed to complete any plan
and duration.
and enables the creation of a realistic schedule.
The activity-on-node diagram displays 7.3.6.4 Level resource usage
interdependencies between activities through The first allocation of resources may lead to
the use of boxes and arrows. Arrows pointing uneven resource usage or over-utilization of
into an activity box come from its predecessor some resources. It may therefore be necessary to
activities, which must be completed before rearrange resources this is called levelling.
the activity can start. Arrows pointing out of
an activity box go to its successor activities, Activities may be reassigned, or they may have
which cannot start until at least this activity is start dates and durations changed within the slack
complete. A simple activity-on-node diagram is available.
shown in Figure 7.4. The end result is a final schedule with all activities
assigned and resource utilization equating to
resource availability.
7.3.6.2 Assess resource availability
The number of people who will be available to do The critical chain technique
the work (or the cost of buying in resources) should
be established. Any specific information should be The critical chain method of planning puts more
noted (for example, names, levels of experience, emphasis on the resources required to execute
percentage availability, available dates). the plan and their availability. This is in contrast
to traditional methods, which emphasize task
7.3.6.3 Assign resources order and rigid scheduling. A critical chain
network will tend to keep the resources levelly
Using the resource availability and the information
loaded, but will require them to be flexible in
from the activity sequence allows the Project
their start times and to switch quickly between
Manager to assign resources to activities. The
tasks and task chains to keep the whole plan on
result will be a schedule that shows the loading of
schedule.
work on each person, and the use of non-human
resources.
A useful approach is to allocate resources to those 7.3.6.5 Agree control points
activities with zero slack first (by definition they The draft schedule enables the control points to be
are on the critical path). Those activities with the confirmed by the Project Board.
greatest slack are the lowest priority for resource Activities relating to the end of a management
allocation. stage (for example, preparing the End Stage Report
It is important that task owners be defined. If a and the next Stage Plan) should be added to the
group needs to complete a task, ask one person activity network and the schedule revised.
from the group to be accountable to the group for One common mistake when creating a schedule
that task. is not to allow time for approvals of products or
If any of the task owners do not participate in releases.
creating the schedule, make sure you check with
them first on their availability and willingness to 7.3.6.6 Define milestones
own the task. Do not assume that putting their A milestone is an event on a schedule which marks
names on a plan or schedule will automatically the completion of key activities. This could be
get the work done. Collaborate, communicate and the completion of a Work Package, a technical
follow up with each task owner to make sure that stage or a management stage. In a commercial
Plans | 71

environment, reaching a milestone may be the


Examples of presentation formats for the
trigger for a payment to a supplier.
schedule
Breaking the plan into intervals associated with
Gantt charts
a milestone allows the Project Manager to have
an early indication of issues associated with A Gantt chart is a graphical representation of
the schedule itself, and also a better view of the duration of tasks against the progression of
the activities whose completion is critical to the time. It allows the Project Manager to:
timeline of the plan.
Assess how long a plan should take
While there is no correct number of milestones Lay out the order in which tasks need to be
or duration between them, they lose their value carried out
when there are too many or too few. There should Manage the dependencies between tasks
be far fewer milestones than deliverables or Work See what should have been achieved at a
Packages, but there should be enough milestones certain point in time
at major intervals to gauge whether or not the
See how remedial action may bring the plan
plan is proceeding as expected.
back on course.

7.3.6.7Calculate total resource requirements Critical path diagram


and costs A critical path diagram highlights those tasks
The resource requirements can be tabulated, and which cannot be delayed without causing the
the cost of the resources and other costs calculated plan to be delayed, and those tasks that can
to produce the plans budget. be delayed without affecting the end date
of the plan. It helps with monitoring and
The budget should include:
communication.
Costs of the activities to develop and verify the
Spreadsheets
specialist products, and the cost of the project
management activities It is possible to create a list of tasks down the
Risk budget (see Chapter 8) spreadsheet and a timeline across it, then
Change budget (see Chapter 9) colour in the cells to represent where the tasks
will occur in the timeline, and progress to
Cost tolerances.
date. For simple projects where the timeline is
The use of risk budgets and change budgets is
unlikely to change, this may be adequate. For
optional.
large or complex projects, the timeline may
change frequently. This means that the Project
7.3.6.8 Present the schedule
Manager may spend a significant amount of
A schedule is best presented in a graphical form. time changing the schedule while neglecting
There are a number of ways of presenting a the day-to-day tasks required in order to
schedule and the choice of format will depend on manage the project.
the scale and complexity of the plan and the needs
of the people who will receive it. Most planning Product checklist
tools will offer a choice of formats to view the A product checklist is a list of the major
schedule. products of a plan, plus key dates in their
delivery. An example of a product checklist is
7.3.7Analyse the risks shown in the Product Description outline for a
This planning activity will typically run parallel with plan in Appendix A.
the other steps, as risks may be identified at any
point in the creation or revision of a plan. Once the plan has been produced, it should still be
considered a draft until the risks inherent in the
Each resource and activity, and all the planning
plan have been identified, assessed and the plan
information, should be examined for its potential
possibly modified.
risk content. All identified risks should be entered
into the Risk Register (or the Daily Log when See Chapter 8 for more details on identifying and
planning the initiation stage). analysing risks.
72 | Plans

Examples of planning risks


7.3.8Document the plan
Having completed the schedule satisfactorily,
Omission of plans at the appropriate
the plan, its costs, the required controls and
management level(s) its supporting text need to be consolidated in
Lots of resources joining the project at accordance with the plan design.
the same time can slow progress and
cause communication issues (plotting an Narrative needs to be added to explain the plan,
S-curve for the resource profile over time any constraints on it, external dependencies,
can identify this steep curves should be assumptions made, any monitoring and control
avoided) required, the risks identified and their required
responses.
The plan includes unnamed resources,
causing the productivity of the actual It is a good discipline to keep plans as simple as
resource to differ from the estimated is appropriate. Consider summary diagrams if the
productivity in the plan plan is to be presented to the Project Board.
The plan contains a high proportion of It may be sensible to have one plan format for
external dependencies presentation in submissions seeking approval,
The plan uses untested suppliers or is and a more detailed format for day-to-day
dependent on new technologies control purposes. Also consider different levels of
There is a high proportion of activities on presentation of the plan for the different levels of
the critical path a delay to any one of readership. Most planning software packages offer
them will delay the plan such options.
The plan does not allow for sufficient
See Appendix A for the suggested composition of
management decision points such as stage
a plan.
boundaries
There is not much float in the plan (creating
a histogram showing the number of 7.4 Responsibilities
activities by amount of float is a useful way Table 7.1 outlines the responsibilities relevant to
of identifying this risk) the Plans theme. Refer to Appendix C for further
A large number of products are to be details of project management team roles and their
completed at the same time associated responsibilities.
The plan is time-bound by fiscal boundaries
(e.g. the budget cannot be transferred
from this year to the next) or by calendar
boundaries (e.g. millennium bug projects
were calendar-bound)
The schedule shows many paths narrowly
paralleling the critical path are likely to
become critical themselves if there is a minor
slip.
Plans | 73

Table 7.1Responsibilities relevant to the Plans theme

Role Responsibilities
Corporate or programme Set project tolerances and document them in the project mandate.
management
Approve Exception Plans when project-level tolerances are forecast to be exceeded.
Provide the corporate or programme management planning standards.
Executive Approve the Project Plan.
Define tolerances for each stage and approve Stage Plans.
Approve Exception Plans when stage-level tolerances are forecast to be exceeded.
Commit business resources to Stage Plans (e.g. finance).
Senior User Ensure that Project Plans and Stage Plans remain consistent from the user perspective.
Commit user resources to Stage Plans.
Senior Supplier Ensure that Project Plans and Stage Plans remain consistent from the supplier perspective.
Commit supplier resources to Stage Plans.
Project Manager Design the plans.
Prepare the Project Plan and Stage Plans.
Decide how management and technical stages are to be applied and design Stage Plans.
Instruct corrective action when Work Package-level tolerances are forecast to be exceeded.
Prepare an Exception Plan to implement corporate management, programme management
or the Project Boards decision in response to Exception Reports.

Team Manager Prepare Team Plans.


Prepare schedules for each Work Package.
Project Assurance Monitor changes to the Project Plan to see whether there is any impact on the needs of
the business or the project Business Case.

Monitor stage and project progress against agreed tolerances.


Project Support Assist with the compilation of Project Plans, Stage Plans and Team Plans.
Contribute specialist expertise (for example, planning tools).
Baseline, store and distribute Project Plans, Stage Plans and Team Plans.
Risk 8
8 Risk

8.1 Purpose 8.2.2 What is at risk?


In the context of a project, it is the projects
The purpose of the Risk theme is to identify,
objectives that are at risk. These will include
assess and control uncertainty and, as a result,
completing the project to a number of targets,
improve the ability of the project to succeed.
typically covering time, cost, quality, scope, benefits
Risk taking in projects is inevitable since projects and risk.
are enablers of change and change introduces For more information on these targets, see
uncertainty, hence risk. section 2.5.
Management of risk should be systematic and
not based on chance. It is about the proactive 8.2.3 What is risk management?
identification, assessment and control of risks that The term risk management refers to the systematic
might affect the delivery of the projects objectives. application of procedures to the tasks of
The project should establish and maintain a cost- identifying and assessing risks, and then planning
effective risk management procedure. The aim is and implementing risk responses. This provides
to support better decision making through a good a disciplined environment for proactive decision
understanding of risks their causes, likelihood, making.
impact, timing, and the choice of responses to For risk management to be effective, risks need to
them. be:
Management of risk is a continual activity, Identified This includes risks being considered
performed throughout the life of the project. that could affect the achievement of the
Without an ongoing and effective risk projects objectives, and then described to
management procedure it is not possible to ensure that there is a common understanding
give confidence that the project is able to of these risks
meet its objectives and therefore whether it is Assessed This includes ensuring that each risk
worthwhile for it to continue. Hence effective risk can be ranked in terms of estimated likelihood,
management is a prerequisite of the continued impact and immediacy, and understanding the
business justification principle. overall level of risk associated with the project
Controlled This includes identifying appropriate
8.2 Risk defined responses to risks, assigning risk owners, and
then executing, monitoring and controlling
8.2.1 What is a risk? these responses.
A risk is an uncertain event or set of events Risk management applies from the strategic,
that, should it occur, will have an effect on operational, programme and project perspectives.
the achievement of objectives. It consists of a The approach to the management of risk can be
combination of the probability of a perceived common across all of these perspectives but risk
threat or opportunity occurring, and the management procedures should be tailored to
magnitude of its impact on objectives, where: suit each one. See Figure 8.1 for organizational
Threat is used to describe an uncertain event perspectives.
that could have a negative impact on objectives
Opportunity is used to describe an uncertain
event that could have a favourable impact on
objectives.
78 | Risk

Long-term
Strategic

Programme
Business change

Medium-term

Project

Short-term Operational

Figure 8.1 Organizational perspectives

8.3 The PRINCE2 approach to risk 8.3.2 Risk management in projects


A starting point for all projects will be to identify
8.3.1 Management of Risk (M_o_R) whether there are any corporate or programme
principles policies and processes that need to be applied.
PRINCE2s approach to the management of risk This information may be in the form of a risk
is based on OGCs publication Management of management policy and/or a risk management
Risk: Guidance for Practitioners (TSO, 2007). process guide (or similar documents).
Management of risk is based on a number of risk An organizations risk management policy
management principles, of which the following are should communicate how risk management will
appropriate within a project context: be implemented throughout the organization
Understand the projects context to support the realization of its strategic
Involve stakeholders objectives. This will include information
Establish clear project objectives
such as the organizations risk appetite (an
organizations unique attitude towards risk
Develop the project risk management approach
taking that in turn dictates the amount of risk
Report on risks regularly
that it considers acceptable), risk tolerances,
Define clear roles and responsibilities procedures for escalation and defined roles and
Establish a support structure and a supportive responsibilities
culture for risk management An organizations risk management process
Monitor for early warning indicators guide should describe the series of steps and
Establish a review cycle and look for continual their respective associated activities necessary
improvement. to implement risk management. This guide
Risk | 79

should provide a best-practice approach 8.3.4 Risk Register


that will support a consistent method of risk The purpose of the Risk Register is to capture
management across the organization. and maintain information on all of the identified
Where the project forms part of the programme, threats and opportunities relating to the project.
the projects approach to risk management will be Each risk on the Risk Register is allocated a unique
determined by the programmes Risk Management identifier as well as details such as:
Strategy. Who raised the risk
PRINCE2 recommends that every project should When it was raised
have its own Risk Management Strategy (defining The category of risk
the project procedures for risk management from The description of the risk (cause, risk event,
identification through to implementation) and a effect)
means of control, i.e. the Risk Register. Probability, impact and expected value
For more information on the risk management Proximity
policy and process guide documents, see OGCs Risk response category
Management of Risk: Guidance for Practitioners Risk response actions
(TSO, 2007). Risk status
Risk owner
8.3.3 Risk Management Strategy
Risk actionee.
Having reviewed the organizational- and
programme-level documents, and before Project Support will typically maintain the Risk
embarking on any risk management activities, a Register on behalf of the Project Manager. The Risk
Risk Management Strategy should be developed Management Strategy will describe the procedure
for the project. The purpose of this strategy is to for registering risks and maintaining the risk
describe how risk management will be embedded register.
in the project management activities. See Appendix A for the Product Description of a
A key decision that needs to be recorded within Risk Register.
the Risk Management Strategy is the Project
Boards attitude towards risk taking, which in 8.3.5 Risk management procedure
turn dictates the amount of risk that it considers PRINCE2 recommends a risk management
acceptable. This information is captured in the procedure comprising the following five steps:
form of risk tolerances, which represent the levels
Identify (context and risks)
of exposure that, when exceeded, will trigger an
Assess (i.e. Estimate and Evaluate)
Exception Report to bring the situation to the
Plan
attention of the Project Board.
Implement
Communicate.
Example of risk tolerance
A large electrical retailer would not tolerate any The first four steps are sequential, with the
unnecessary disruption to its support systems Communicate step running in parallel because
during the peak trading period, which extends the findings of any of the other steps may need
from the middle of November through to the to be communicated prior to the completion of
end of January. Projects are not permitted to the overall process. All of the steps are iterative
introduce any changes to the support systems in nature in that when additional information
during this period. Therefore any risks in the becomes available, it is often necessary to revisit
Risk Register that mean the support systems earlier steps and carry them out again to achieve
would change in this peak trading window the most effective result.
would need to be escalated to the Project Board. Figure 8.2 shows the elements of the risk
management procedure, which are described in
See Appendix A for the Product Description of a sections 8.3.5.18.3.5.5.
Risk Management Strategy.
80 | Risk

This information will be derived from the project


mandate, the Project Brief and the Project Product
Description. The Risk Management Strategy will
include decisions on the:
Implement
Risk management procedure
Identify
Tools and techniques to be used
Records to be kept
Risk reporting
Communicate Timing of risk management activities
Roles and responsibilities for the risk
management procedure
Risk scales to be used (for likelihood, impact,
proximity)
Plan Assess
Any categorization of risks (and possibly the
risk breakdown structure to use)
Risk response categories to be used
Early warning indicators
Any risk tolerances
Figure 8.2 The risk management procedure Whether a risk budget will be established and,
if so, how it will be controlled.
8.3.5.1 Identify
The early warning indicators (relevant to the
Identify context
project) will provide advanced warning that one
The primary goal of the Identify context step is to or more of the projects objectives could be at risk.
obtain information about the project in order to Early warning indicators could include progress
understand the specific objectives that are at risk performance data (see Chapter 10) such as:
and to formulate the Risk Management Strategy
Percentage of Work Packages accomplished/not
for the project. The Risk Management Strategy
describes how risks will be managed during the accomplished to schedule
project. It is created during the initiation stage Percentage of approvals accomplished/not
and then reviewed and possibly updated at the accomplished to schedule
end of each stage. The projects Risk Management Number of issues being raised (per week/
Strategy should be based on the corporate risk month)
management policy or on the programmes Risk Percentage of issues that remain unresolved
Management Strategy. Average number of days that issues remain
The following will have an influence on the unresolved
projects Risk Management Strategy: Average number of defects captured in quality
inspections
Customers quality expectations
Adherence to budget (e.g. rate of spend behind
Number of organizations involved and the or ahead of planned spend)
relationship between them
Adherence to schedule (e.g. days behind or
The needs of the stakeholders involved with the ahead of schedule).
project
The importance, complexity and scale of the Other early warning indicators could include
project non-project data such as customer satisfaction,
absenteeism levels, staff attrition rates etc., if
What assumptions have been made
they are relevant to the project. It is also useful
The organizations own environment (e.g.
to analyse and report on the direction of travel
legislative or governance requirements)
of these early warning indicators (i.e. are they
The organizations approach to risk improving/deteriorating) as that can be of more
management as described by its risk significance than their snapshot value.
management policy.
Risk | 81

Risk identification techniques Identify risks


The primary goal of the Identify risks step is to
Risks can be identified using a number of
recognize the threats and opportunities that may
techniques, such as:
affect the projects objectives.
Review lessons Risks are driven by
PRINCE2 recommends the following actions:
uncertainty, so one of the most effective
ways to reduce uncertainty is to review Capture identified threats and opportunities in
similar previous projects to see what threats the Risk Register
and opportunities affected them Prepare early warning indicators to monitor
Risk checklists These are in-house lists of critical aspects of the project and provide
risks that have either been identified or information on the potential sources of risk
have occurred on previous similar projects. Understand the stakeholders view of the
Risk checklists are useful aids to ensure that specific risks captured.
risks identified on previous projects are not
An effective way of identifying risks is to use a
overlooked
risk workshop. This is a group session designed
Risk prompt lists These are publicly
to identify threats and opportunities. The session
available lists that categorize risks into types
should be facilitated by someone who is able to use
or areas and are normally relevant to a
a range of identification techniques, such as those
wide range of projects. Risk prompt lists are
listed in the boxed example. Workshops should
useful aids to help stimulate thinking about
lead to the identification of a broad range of risks
sources of risk in the widest context
and possible risk owners.
Brainstorming This enables group thinking,
which can be more productive than An important aspect of identifying risks is
individual thinking. However, it is important being able to provide a clear and unambiguous
to avoid criticism during the brainstorm expression of each one. A useful way of expressing
as this can stop people contributing. In risk is to consider the following aspects of each risk:
addition to identifying risks, brainstorming Risk cause This should describe the source of
can also be used to understand the the risk, i.e. the event or situation that gives
stakeholders views of the risks identified rise to the risk. These are often referred to as
Risk breakdown structure This is a risk drivers. They are not risks in themselves, but
hierarchical decomposition of the project the potential trigger points for risk. These may
environment assembled to illustrate be either internal or external to the project
potential sources of risk. Each descending Risk event This should describe the area of
level represents an increasingly detailed uncertainty in terms of the threat or the
definition of sources of risk to the project. opportunity
The structure acts as a prompt and an aid Risk effect This should describe the impact(s)
to support the project management team that the risk would have on the project
in thinking through the potential sources of objectives should the risk materialize.
risk to the objectives. There are numerous
ways to break down risk and it may be The cause, event and effect relationship is shown in
useful to do more than one list. For example, Figure 8.4.
a risk breakdown structure could be broken
The cause, event and effect relationship could also
down by PESTLE (political, economical,
be expressed in a sentence, for example:
sociological, technological, legal/legislative,
environmental), product breakdown
structure, stage, benefits/objectives etc.
Figure 8.3 shows a risk breakdown structure
relating to financial risk. These structures
will help to identify appropriate risk owners
to develop responses.
82 | Risk

Financial risks

Over-extending
Currency risk Customer failure
credit

Failure to honour Contractual


Bankruptcy
payment breach

Figure 8.3 Example of a risk breakdown structure

Threat Because it has been raining heavily (risk


Risk estimation techniques
cause), there is a threat that the river flowing
through the farmers field might overflow Risks can be estimated using a number of
techniques, such as:
(risk event), which would severely damage the
farmers crop (risk effect) Probability trees These are graphical
Opportunity Because the weather has been representations of possible events resulting
particularly mild this winter (risk cause), there from given circumstances. A probability
is an opportunity that fewer people will be tree can be used to predict an outcome
in a qualitative way when historical data
hospitalized with influenza (risk event), which
is used to populate the likelihood of
will mean that there will be less disruption to
each circumstance happening. Probability
planned routine operations (risk effect). trees assist in communicating to project
participants or decision makers the likelihood
8.3.5.2 Assess of the different possible outcomes to a set of
Estimate circumstances
Expected value This technique quantifies
The primary goal of the Estimate step is to assess the
risk by combining the cost of the risk impact
threats and the opportunities to the project in terms of with the probability of the risk occurring.
their probability and impact. The risk proximity will also Expected value is useful when a tangible
be of interest to gauge how quickly the risk is likely to measure of risk is required to enable risks
materialize if no action were taken. to be prioritized. For example, if the cost
of a risk was 160,000 and its likelihood of
occurrence was estimated at 25%, then the
expected value would be 40,000
Pareto analysis This technique ranks or
orders risks once they have been assessed to
A risk cause determine the order in which they should
be addressed. Pareto analysis can be used
to focus management effort on those risks
may result in that have the potential to have the greatest
A risk event
impact on the project objectives
Probability impact grid This grid contains
ranking values that may be used to rank
which may affect
An objective threats and opportunities qualitatively. The
probability scales are measures of probability
derived from percentages, and the impact
Figure 8.4 Risk cause, event and effect scales are selected to reflect the level of
Risk | 83

impact on project objectives. The values Evaluate


within the grid cells are the combination of The primary goal of the Evaluate step is to assess
a particular probability and impact, and are the net effect of all the identified threats and
determined by multiplying the probability by opportunities on a project when aggregated
the impact. A probability impact grid can be together. This will enable an assessment to be
used to provide an assessment of the severity made of the overall severity of the risks facing the
of a risk and enable risks to be ranked so
project, to determine whether this level of risk is
that management time and effort can be
within the risk tolerance set by the Project Board
prioritized. For example, the Project Board
may set their risk tolerance at any risk with and whether the project has continued business
a value of greater than 0.18, and they may justification.
require a proactive response for any risk with
a value of greater than 0.045, as depicted by Risk evaluation techniques
the dark shading shown in Figure 8.5. Risks can be evaluated by using techniques such
as:
PRINCE2 recommends that the following is Risk models Take, for example, the Monte
understood: Carlo analysis. This model enables simulation
The probability of the threats and opportunities of what if scenarios using random numbers
in terms of how likely they are to occur to determine whether each risk within a
given range occurs or not. The simulations
The impact of each threat and opportunity in
are repeatedly run to predict the average
terms of the project objectives. For example, if level of risk to the projects time or cost. The
the objectives are measured in time and cost, scenarios can also be used to model extreme
the impact should also be measured in units of cases (e.g. if nearly all the risks occur)
time and cost Expected monetary value This technique
The proximity of these threats and takes the expected values of a number
opportunities with regard to when they might of risks and sums them to arrive at an
materialize overall value. It provides a quick and easy
How the impact of the threats and assessment of a group of risks to understand
their combined effect. An example is shown
opportunities may change over the life of the
in Table 8.1.
project.
A useful way of summarizing the set of risks and Table 8.1 Example of the expected monetary value
their estimations is to plot them onto a summary technique
risk profile, an example of which is shown in
Figure 8.6. This profile represents a situation at Risk ID Likelihood (%) Impact () Expected
a specific point in time, i.e. a snapshot of the risk value ()
environment. The numbered markers in the matrix 1 60 20,000 12,000
represent unique risk identifiers used in the Risk 2 30 13,000 3,900
Register on which this is based. The risks above 3 10 4,000 400
and to the right of the dotted risk tolerance line 4 5 10,000 500
represent those that the organization will not
Expected monetary value 16,800
tolerate except under special circumstances. In the
depicted case, the Project Manager would refer
risks 1, 3 and 4 to the Project Board.
8.3.5.3 Plan
The primary goal of the Plan step is to prepare
The summary risk profile can also be used to show specific management responses to the threats
trends. For example, risk 6 may have previously and opportunities identified, ideally to remove
been recorded as low probability, high impact, or reduce the threats and to maximize the
indicating that its likelihood of occurring is opportunities. Attention to the Plan step ensures
increasing. as far as possible that the project is not taken by
surprise if a risk materializes.
84 | Risk

Very high
0.9 7190% 0.045 0.09 0.18 0.36 0.72

High
0.7 5170% 0.035 0.07 0.14 0.28 0.56
Probability

Medium
0.5 3150% 0.025 0.05 0.10 0.20 0.40

Low
0.3 1130% 0.015 0.03 0.06 0.12 0.24

Very low
0.1 up to 10% 0.005 0.01 0.02 0.04 0.08

Very low Low Medium High Very high

0.05 0.1 0.2 0.4 0.8

Impact

Figure 8.5 Probability impact grid

The Plan step involves identifying and evaluating The various types of response for threats and
a range of options for responding to threats opportunities are summarized in Figure 8.7.
and opportunities. It is important that the risk
The types of response are explained further in
response is proportional to the risk and that
Table 8.2.
it offers value for money. A key factor in the
selection of responses will be balancing the cost of Risk responses do not necessarily remove the
implementing the responses against the probability inherent risk in its entirety, leaving residual risk.
and impact of allowing the risk to occur. Any If the inherent risk was significant and the risk
chosen responses should be built into the response was only partially successful, the residual
appropriate level of plan, with a provision made risk can be considerable. It may be appropriate to
for any fallback plans. select more than one risk response.
In some cases, implementing a risk response
will reduce or remove other related risks. It is
Very high 1 3
also possible that the responses to risks, once
implemented, will change some aspect of the
High 2 4
project. This in turn may lead to secondary risks, i.e.
risks that may occur as a result of invoking a risk
Medium 8 6
response. It is essential that these are identified,
assessed and controlled in the same way as the
Low 10 7
inherent risk.

Very low 9 2 5 It is advisable to review lessons from previous


similar projects when planning risk responses. This
Prob.
Very low Low Medium High Very high will help in identifying the range of responses
Impact
available and in evaluating how effective they are
Risk tolerance line likely to be.
Figure 8.6 Summary risk profile
Risk | 85

Threat responses Opportunity responses

Avoid Exploit

Reduce
(probability and/or impact)
Fallback
(reduces impact only) Enhance
Transfer
(reduces impact only, and often only
the financial impact)

Share

Accept Reject

Figure 8.7 Threat and opportunity responses

Consideration should also be given to the effect Risk actionee An individual assigned to carry
the possible responses could have on: out a risk response action or actions to respond
to a particular risk or set of risks. They support
The Project Plan, Stage Plan and Work Packages
and take direction from the risk owner.
The Business Case
Corporate and/or programme management. Example of a risk owner and risk actionee

8.3.5.4 Implement There is a risk that a key supplier may go


The primary goal of the Implement step is bankrupt. The commercial director has been
to ensure that the planned risk responses are appointed as the risk owner. A number of risk
actioned, their effectiveness monitored, and responses have been identified and selected.
corrective action taken where responses do not One of the risk responses (fallback) is to identify
match expectations. possible alternative suppliers who have the
capacity to undertake the affected Work
An important part of the Implement step is to Packages at short notice, and to obtain some
ensure that there are clear roles and responsibilities quotes from them. The Procurement Manager is
allocated to support the Project Manager in the the risk actionee for this particular risk response.
management of project risks. The main roles in this
respect are:
In many cases, the risk owner and risk actionee are
Risk owner A named individual who is likely to be the same person. The risk owner should
responsible for the management, monitoring be the person most capable of managing the risk.
and control of all aspects of a particular risk Allocating too many risks to any one individual
assigned to them, including the implementation should be avoided.
of the selected responses to address the threats
or to maximize the opportunities
86 | Risk

Table 8.2 Risk responses


Response Definition Example
Avoid (threat) Typically involves changing some aspect of A critical meeting could be threatened by air
the project, i.e. the scope, procurement route, travel disruption so the project chooses to hold
supplier or sequence of activities, so that the the meeting by conference call instead.
threat either can no longer have an impact or
can no longer happen.
Reduce (threat) Proactive actions taken to: To reduce the likelihood of users not using
a product, the number of training events is
Reduce the probability of the event
increased.
occurring, by performing some form of
control To reduce the timescale impact should a
Reduce the impact of the event should it prototype be damaged in transit, two prototypes
occur. are built.
Fallback (threat) Putting in place a fallback plan for the actions The companys test facility is only available for
that will be taken to reduce the impact of the two weeks in August. To reduce the impact
threat should the risk occur. This is a reactive should the product not be available in time,
form of the reduce response which has no there is a fallback plan to hire an alternate test
impact on likelihood. facility (at a greater expense).
Transfer (threat) A third party takes on responsibility for some To reduce the financial impact should a
of the financial impact of the threat. (For prototype be damaged in transit, it is insured.
example, through insurance or by means of To reduce the financial impact if a product is not
appropriate clauses in a contract.) This is a form available to launch in time for a trade show, the
of the reduce response which only reduces the contract with the supplier includes liquidated
financial impact of the threat. damage clauses for any delays.
Accept (threat) A conscious and deliberate decision is taken to There is a threat that a competitor may launch
retain the threat, having discerned that it is more a rival product first, thus affecting the expected
economical to do so than to attempt a threat market share for the product. The choice is
response action. The threat should continue to to accelerate the project by increasing the
be monitored to ensure that it remains tolerable. resources, to reduce the products scope so
that it can be finished earlier, or to do nothing.
Accelerating the project may lead to product
quality issues; reducing the scope may make the
product less appealing; so the risk is accepted
and the do nothing option is chosen.
Share (threat or Modern procurement methods commonly entail The cost of the project could be adversely
opportunity) a form of risk sharing through the application of affected due to fluctuations in the cost of oil.
a pain/gain formula: both parties share the gain The customer and supplier agree to share the
(within pre-agreed limits) if the cost is less than cost of price increases or the savings from price
the cost plan; and share the pain (again within reductions equally from a midpoint fixed at the
pre-agreed limits) if the cost plan is exceeded. time of agreeing the contract.
Several industries include risk-sharing principles
within their contracts with third parties.
Exploit Seizing an opportunity to ensure that the There is a risk that the project will be delayed.
(opportunity) opportunity will happen and that the impact If it is delayed, a later version of software could
will be realized. be implemented instead which would reduce
ongoing maintenance. The Project Board agree
to change the project timescale and scope,
enabling the later version of the software to be
bought and implemented.
Risk | 87

Enhance Proactive actions taken to: It is possible that the product completes user
(opportunity) acceptance testing in a single test cycle, rather
Enhance the probability of the event
than the scheduled two, enabling it to be
occurring
delivered early and prior to a competitors rival
Enhance the impact of the event should it product. The Project Board decide to hold a
occur. test rehearsal to increase the likelihood that the
product will pass its first user acceptance tests,
and prepare for the option of an earlier launch
date.
Reject A conscious and deliberate decision is taken not It is possible that the product completes user
(opportunity) to exploit or enhance the opportunity, having acceptance testing in a single test cycle, rather
discerned that it is more economical not to than the scheduled two, enabling it to be
attempt an opportunity response action. The delivered early and prior to a competitors rival
opportunity should continue to be monitored. product. The Project Board decide not to take
advantage of an early release and to stick with
the planned launch date.

8.3.5.5 Communicate A projects exposure to risk is never static:


Communication is a step that is carried out effective communication is key to the
continually. The Communicate step should identification of new risks or changes in
ensure that information related to the threats and existing risks. This depends on the maintenance
opportunities faced by the project is communicated of a good communications network, including
both within the project and externally to relevant contacts and sources of information, to
stakeholders. Risks are communicated as part of facilitate the identification of changes that may
the following management products: affect the projects overall risk exposure
Effective risk management is dependent on
Checkpoint Reports
participation and, in turn, participation is
Highlight Reports dependent on effective communication.
End Stage Reports
End Project Reports 8.3.6 Risk budget
Lessons Reports. A risk budget, if used, is a sum of money included
within the project budget and set aside to fund
Care should be taken in using these reports to
specific management responses to the projects
communicate risks with external stakeholders and
threats and opportunities (for example, to cover
reference should be made to the Communication
the costs of any fallback plans should they need to
Management Strategy for the most appropriate
be implemented).
method.
In order to arrive at a risk budget for the project,
There are numerous other communication
a financial approach to risk management is
methods, such as bulletins, notice boards,
needed. Each risk must be fully analysed for the
dashboards, discussion threads, briefings etc.,
impact costs, response costs and likelihood. The
that could be considered alongside the PRINCE2
aggregation of the costs (for responses and impact)
management products.
weighted by each risks probability generates the
A number of aspects of communication should be expected monetary value for the set of risks. The
recognized and addressed if risk management is to expected monetary value can be used to determine
be effective: a risk budget. The assumption is that the risk
budget is expected to be used over the course
of the project. Care needs to be taken that the
aggregation of the factored costs is not skewed
by a small number of large risks. This is where
analytical techniques, such as Monte Carlo analysis
and associated software tools, can help.
88 | Risk

As the risk budget is part of the project budget, 8.4 Responsibilities


there may be a tendency to treat it as just another
Table 8.3 outlines the responsibilities relevant to
sum of money that the Project Manager can
the Risk theme. Refer to Appendix C for further
spend. This culture should be discouraged in
details of project management team roles and their
favour of the Risk Management Strategy defining
associated responsibilities.
the mechanisms for control of, and access to, this
budget. As the project progresses, some of the
risks previously identified will occur and others will
not. New risks may be identified during the life
of the project whose response costs will not have
been included within the risk budget. It is always
prudent to set the risk budget to cover the known
risks (as identified) and to make a provision for
unknown risks (yet to be identified).

Table 8.3 Responsibilities relevant to the Risk theme


Role Responsibilities
Corporate or programme Provide the corporate risk management policy and risk management process guide (or
management similar documents).
Executive Be accountable for all aspects of risk management and, in particular, ensure a project Risk
Management Strategy exists.
Ensure that risks associated with the Business Case are identified, assessed and controlled.
Escalate risks to corporate or programme management as necessary.
Senior User Ensure that risks to the users are identified, assessed and controlled (such as the impact on
benefits, operational use and maintenance).
Senior Supplier Ensure that risks relating to the supplier aspects are identified, assessed and controlled
(such as the creation of the projects products).
Project Manager Create the Risk Management Strategy.
Create and maintain the Risk Register.
Ensure that project risks are being identified, assessed and controlled throughout the
project lifecycle.
Team Manager Participate in the identification, assessment and control of risks.
Project Assurance Review risk management practices to ensure that they are performed in line with the
projects Risk Management Strategy.
Project Support Assist the Project Manager in maintaining the projects Risk Register.
Change 9
9 Change

9.1 Purpose 9.2.2 Configuration management


The purpose of the Change theme is to identify, Configuration management is the technical
assess and control any potential and approved and administrative activity concerned with the
changes to the baseline. creation, maintenance and controlled change of
configuration throughout the life of a product (or
Change is inevitable during the life of a project, item).
and every project needs a systematic approach to A configuration item is an entity that is subject
the identification, assessment and control of issues to configuration management. The entity may be
that may result in change. a component of a product, a product or a set of
As changes may arise from project team members, products that form a release. For example:
stakeholder requests, complaints or a wide range A component of a product: an electronic motor
of other factors, PRINCE2 provides a common that is part of a piece of machinery
approach to issue and change control. A product: a piece of machinery
PRINCE2 provides both a systematic and common A release: a piece of machinery, the refitted
approach, which ensures that issues possibly machine room, training materials, and the
affecting the projects performance targets necessary health and safety certificates.
(time, cost, quality, scope, risk and benefits) are A release is a complete and consistent set of
appropriately managed. products that are managed, tested and deployed as
Issue and change control is a continual activity, a single entity to be handed over to the user(s).
performed throughout the life of the project. Issue and change control procedures need to be
Without an ongoing and effective issue and integrated with the configuration management
change control procedure, a project will either system used by the project.
become totally unresponsive to its stakeholders or
quickly drift out of control. 9.2.3Issues
The aim of issue and change control procedures is PRINCE2 uses the term issue to cover any relevant
not to prevent changes; it is to ensure that every event that has happened, was not planned, and
change is agreed by the relevant authority before requires management action. It can be a concern,
it takes place. Change can only be considered query, request for change, suggestion or off-
in relation to an established status quo, i.e. a specification raised during a project. Project issues
baseline. Therefore, a prerequisite of effective can be about anything to do with the project.
issue and change control is the establishment of
an appropriate configuration management system 9.2.4 Types of issue
which records baselines for the projects products Issues may be raised at any time during the
and ensures that the correct versions are delivered project, by anyone with an interest in the project
to the customer. or its outcome.
Table 9.1 provides a summary of the different types
9.2 Change defined of issue that need to be dealt with during
a project.
9.2.1Issue and change control
Issue and change control procedures ensure that all
issues and changes which may affect the projects
agreed baselines are identified, assessed and either
approved, rejected or deferred.
92 | Change

Table 9.1 Types of issue


Types of issue Definition Examples
Request for change A proposal for a change to a baseline. The Senior User would like to increase the
capacity of a product from 100 to 150 users.
Off-specification Something that should be provided by the Advice from a supplier that they can no longer
project, but currently is not (or is forecast deliver one of the products specified by the
not to be) provided. This might be a missing customer.
product or a product not meeting its
specification.
Problem/concern Any other issue that the Project Manager Advice from a Team Manager that a team
needs to resolve or escalate. member has been taken ill and as a result the
target end date for a Work Package will slip by
a week.
Notification that one of the suppliers has gone
bankrupt, resulting in the need to identify and
engage a new supplier.

9.3 The PRINCE2 approach to change and incorporate them into the projects own
Configuration Management Strategy. The projects
9.3.1Establish controls Configuration Management Strategy should
The projects controls for issues, changes and define:
configuration management will be defined and The configuration management procedure
established by the Initiating a Project process (e.g. planning, identification, control, status
and then reviewed and (if necessary) updated accounting, verification and audit)
towards the end of each management stage by the The issue and change control procedure (e.g.
Managing a Stage Boundary process. The following capturing, examining, proposing, decision
management products are used to establish and making, implementing)
maintain the projects controls for issues, changes The tools and techniques that will be used
and configuration management: The records that will be kept
Configuration Management Strategy How the performances of the procedures will
Configuration Item Records be reported
Product Status Accounts Timing of configuration management and issue
Daily Log and change control activities
Issue Register The roles and responsibilities for configuration
Issue Reports. management and issue and change control
activities (including whether any corporate
The importance and use of each of these or programme management roles are to be
management products are described in sections involved).
9.3.1.19.3.1.6.
The Configuration Management Strategy should
9.3.1.1 Configuration Management Strategy define the way issues are handled. During the
initiation stage, the Project Manager and Project
Effective issue and change control is only possible
Board need to agree:
if it is supported by a configuration management
system that facilitates impact assessments The scale for prioritizing issues
(relationships between products) and maintains The scale for rating the severity of issues
product baselines (the basis from which the entity What severity of issues can be handled at what
will change). management level.
The starting point for all projects will be to identify
whether there are any corporate or programme
policies and processes that need to be applied,
Change | 93

possibly also their analysis costs. Unless the


Example of priority and severity
anticipated level of change on a project is low,
There are numerous ways to prioritize issues, it is advisable for a budget to be set up to pay
one of which is called MoSCoW where (for for changes. This arrangement can reduce the
requests for change) the issue is rated as either: number of trivial exceptions arising in projects
where the frequency of requests for change is
Must have The change is essential for the
forecast to be high. Including a change budget
viability of the project
provides for a more realistic expectation of
Should have The change is important and
the overall costs/timeframe of the project.
its absence weakens the Business Case
Where a change budget is given to a Change
Could have The change is useful but its
Authority, the Project Board may wish to put a
absence does not weaken the Business Case limit on (a) the cost of any single change, and
Wont have (for now) The change is not (b) the amount spent on change in any one
essential nor important and can wait. stage without reference to the Project Board.
There are numerous ways to rate the severity of The change control procedure would then be
issues, such as numeric (e.g. 14) or descriptive defined in such a way as to control access to
(e.g. minor, significant, major, critical). The the change budget. If used, the change control
Project Manager and Project Board might budget is documented in the relevant plan.
agree that minor issues can be dealt with by See Appendix A for a Product Description of a
the Project Manager, and significant issues by Configuration Management Strategy.
a Change Authority, but that major issues need
to be escalated to the Project Board, and critical 9.3.1.2 Configuration Item Records
issues to corporate or programme management.
The purpose of the Configuration Item Records
is to provide a set of records that describe
When deciding what severity of issues can be dealt information such as the status, version and variant
with by what level of management, the Project of each configuration item and any details of
Board may consider delegating some decision important relationships between the items.
making for accepting/rejecting requests for change
See Appendix A for the Product Description of the
or off-specifications to a Change Authority and
Configuration Item Records.
whether to provide a budget to pay for changes:
Change Authority It is the Project Boards 9.3.1.3 Product Status Account
responsibility to review and approve requests The purpose of the Product Status Account is
for change and off-specifications. In a project to provide information about the state of the
where few changes are envisaged, it may products within defined limits. The limits can vary.
be reasonable to leave this authority in the For example, the report could cover the entire
hands of the Project Board. But for projects project, a particular stage, a particular area of the
where there are likely to be lots of changes, project or even the history of a single product. It is
the Project Board may choose to delegate particularly useful if the Project Manager wishes to
some decisions to a person or group, called confirm the version numbers of products.
the Change Authority. The Project Manager
and/or the people with delegated Project See Appendix A for the Product Description of a
Assurance responsibilities may act as the Product Status Account.
Change Authority. It may be appropriate, for
example, to make the Project Manager the 9.3.1.4 Daily Log
Change Authority for Work Packages so that A Daily Log is used to record problems/concerns
any changes that are within the delegated that can be handled by the Project Manager
authority limits can be made without referral to informally. Issues initially captured on the Daily Log
the Project Board for approval may later be transferred to the Issue Register if,
Change budget This is a sum of money that after examining them, it is decided they need to be
the customer and supplier agree will be used treated more formally.
to fund the cost of requests for change, and
94 | Change

The Daily Log can also be used to record required agreement of appropriate authorities. Once
actions or significant events not caught by other a product has been approved, the motto is
PRINCE2 registers and logs. It acts as the project Nothing moves and nothing changes without
diary. authorization. A baseline is a reference level
against which an entity is monitored and
See Appendix A for the Product Description of a
controlled. In configuration management terms,
Daily Log.
it is a snapshot of a release, product and any
component products, frozen at a point of time
9.3.1.5 Issue Register
for a particular purpose. This purpose may be
The purpose of the Issue Register is to capture and when a product is ready to be reviewed or
maintain information on all of the issues that are when it has been approved. If the product that
being managed formally. The Issue Register should has been baselined is to be changed, a new
be monitored by the Project Manager on a regular version is created to accommodate the change,
basis. and the baseline version is kept unchanged.
See Appendix A for the Product Description of an Old baseline versions should be archived where
Issue Register. possible, not discarded. Configuration control
also includes: the storing and retrieving of all
9.3.1.6 Issue Report information relevant to the management of
An Issue Report is a report containingthe the project; ensuring the safety and security
description, impact assessment and of configuration items and controlling who
recommendations for a request for change, has access to them; distribution of copies of all
off-specification or a problem/concern. It is only configuration items; and the archiving of all
created for those issues that need to be handled documentation produced during the project
formally. lifecycle. Both management and specialist
products are subject to configuration control.
9.3.2Configuration management Status accounting The reporting of all current
and historical data concerning each product
procedure
in the form of a Product Status Account. The
Configuration management procedures can vary, Project Manager may call for a Product Status
but they typically comprise five core activities: Account towards the end of a stage, at the end
Planning Deciding what level of configuration of the project, or as part of examining issues
management will be required by the project and risks
and planning how this level is to be achieved. Verification and audit A series of reviews
The level of control required will vary from and configuration audits to compare the
project to project. The maximum level of actual status of all products against the
control possible is determined by breaking authorized state of products as registered in
down the projects products until the level the Configuration Item Records, looking for
is reached at which a component can be any discrepancies. These reviews and audits
independently installed, replaced or modified. also check that the configuration management
However, the level of control exercised will be procedure is being undertaken in accordance
influenced by the importance of the project with the Configuration Management Strategy.
and the complexity of the relationship between The reviews are typically undertaken at the end
its products of each stage and at the end of the project.
Identification Specifying and identifying all
components of the projects products (known 9.3.3Issue and change control procedure
as configuration items) at the required level of PRINCE2 provides a common approach to dealing
control. A coding system should be established, with requests for change, off-specifications and
enabling a unique identifier for each problems/concerns, as shown in Figure 9.1.
configuration item to be allocated and various
attributes of the product recorded
Control The ability to approve and baseline
products and to make changes only with the
Change | 95

Project Board/Change Authority

Request for advice Request for advice/


Exception Report

Capture Examine Propose Decide Implement

Determine Assess Identify Escalate if Take


issue type impact on options beyond corrective
Determine project Evaluate delegated action
severity/ objectives/ options authority Update
priority Business Case Recommend Approve, records and
Log and project options reject or defer plans
Register risk profile recommended
Check option
severity/
priority

Daily Log or
Issue Register/Issue Report

Figure 9.1 Issue and change control procedure

9.3.3.1 Capture An Issue Report should be created to capture what


The first step in the procedure is to undertake an is already known about the issue. It is often useful
initial analysis to determine the type of issue that to ask the person who raised the issue to create the
has been raised and whether it can be managed initial Issue Report.
informally or formally.
9.3.3.2 Examine
The Project Manager is likely to receive many
The next step is to examine the issue by
issues that can be handled without having to
undertaking an impact analysis.
treat them formally, particularly if the issue can
be immediately resolved for example, a team The Project Manager needs to consider whether it
member raising an issue that their site access pass is is worthwhile doing a detailed impact analysis as
about to expire. In such cases, the Project Manager the duration and effort required to undertake one
should decide on the best course of corrective may itself cause a deviation from the plan.
action.
The impact analysis should consider the impact the
The purpose of distinguishing between those issues issue has (or will have) on:
that can be managed informally and those that
The project performance targets in terms of
need to be managed formally is to:
time, cost, quality and scope
Ensure decisions are made at an appropriate The project Business Case, especially in terms of
level within the project management team the impact on benefits
Avoid the Project Board being inundated with The project risk profile, i.e. the impact on the
too many issues and therefore diluting the overall risk exposure of the project.
time it has available to deal with the key issues
If the project is part of a programme, the impact
affecting the project
of the change on the programme as a whole
Reduce the administrative burden on the
should be considered. There may also be effects on
Project Manager when dealing with the day-to-
other projects that are not necessarily part of the
day issues that may arise.
programme.
Issues being managed formally should be entered
Examining the impact of issues can be wrongly
in the Issue Register and given a unique identifier.
taken to mean only the impact on the customer.
96 | Change

Impact analysis must cover the three areas of The risk considerations should include both project
business, user and supplier for example, the risks (i.e. of not completing within tolerances) and
suppliers cost and effort required to implement operational risks (e.g. potential performance issues
a change and what products would have to be once the projects products are in use).
changed. Having undertaken the impact analysis,
If any of the proposed options would take the
the severity or priority should be re-evaluated.
stage or project beyond any tolerances, consider
The Issue Register and Issue Report should be preparing an Exception Report for that option to
updated to include the above information and the accompany the Issue Report.
person who raised the issue and the person who
created the Issue Report (if different) should be 9.3.3.4 Decide
kept appraised of its status. The Project Manager may be able to resolve
It may be necessary to request advice from the issues without the need to escalate them to the
Project Board to check their understanding of Project Board. For example, a minor change to an
the issues priority or severity before proposing approved detailed design document that does not
resolutions. affect any other products could be handled by the
Project Manager (if allowed in the Configuration
9.3.3.3 Propose Management Strategy), as long as it is formally
recorded.
Having gained a full understanding of the impact
of the issue, the next step is to consider alternative Other issues may need to be escalated to the
options for responding to it and proposing a course Project Board (or its delegated Change Authority)
of action to take. for a decision. The escalation could be in the form
of an Issue Report (as part of a request for advice)
Consideration should be given as to the effect
or in the form of an Exception Report (if the
each of the options will have on the projects time,
selected option to address the issue would cause an
cost, quality, scope, benefit and risk performance
exception see Chapter 10).
targets. There must be a balance between the
advantage to be gained by implementing the For escalated issues and exceptions, the likely
option, and the time, cost and risk of implementing Project Board responses are shown in Table 9.2.
it, as illustrated in Figure 9.2.
9.3.3.5 Implement
The Project Manager will either:
Advantage Impact of
gained implementation Take the necessary corrective action (such as
updating a Work Package or issuing a new
one), or
Create an Exception Plan for approval by the
s/
Reduced cost Project Board.
time/risks In both cases, the Project Manager will update the
Issue Register and Issue Report with the decision
Cost/duration and inform all interested parties.
ts of option
More benefi Once the issue is closed, the Project Manager
should update the Issue Register and the Issue
Report.
Risk
etc. of option
9.4Responsibilities
Table 9.3 outlines the responsibilities relevant to
the Change theme. Refer to Appendix C for further
details of project management team roles and their
associated responsibilities.
Figure 9.2 Options analysis
Change | 97

Table 9.2 Project Board decisions


Request Project Board (or Change Authority) response Considerations
Request for change Approve the change If a request for change involves extra cost, there
Reject the change are three principal ways to fund it:
Use the change budget (if being used and if
Defer decision
of sufficient size)
Request more information
Increase the project budget
Ask for an Exception Plan (if the request for
De-scope other elements of the project.
change cannot be implemented within the
limits delegated to the Change Authority).

Tolerance should not be used to fund requests


for change.
Off-specification Grant a concession The Project Board may decide to accept the
Instruct that the off-specification be resolved off-specification without immediate corrective
action. This is referred to as a concession. When
Defer decision
a product is granted a concession, the Product
Request more information Description will need to be revised before the
Ask for an Exception Plan (if the concession product is handed over to the User.
cannot be granted within the limits delegated
to the Change Authority).
Problem/concern Provide guidance Could the problem/concern be resolved by
Ask for an Exception Plan relaxing the stage tolerances?

Table 9.3 Responsibilities relevant to the Change theme


Role Responsibilities
Corporate or programme Provide the corporate or programme strategy for change control, issue resolution and
management configuration management.
Executive Determine the Change Authority and change budget.
Set the scale for severity ratings for issues.
Set the scale for priority ratings for requests for change and off-specifications.
Respond to requests for advice from the Project Manager.
Make decisions on escalated issues, with particular focus on continued business justification.
Senior User Respond to requests for advice from the Project Manager.
Make decisions on escalated issues with particular focus on safeguarding the expected benefits.
Senior Supplier Respond to requests for advice from the Project Manager.
Make decisions on escalated issues, with particular focus on safeguarding the integrity of the
complete solution.
Project Manager Manage the configuration management procedure, assisted by Project Support where
possible.
Manage the issue and change control procedure, assisted by Project Support where possible.
Create and maintain the Issue Register, assisted by Project Support where possible.
Implement corrective actions.
Team Manager Implement corrective actions.
Project Assurance Advise on examining and resolving issues.
Project Support Administer the configuration management and issue and change control procedures:
Maintain Configuration Item Records
Produce Product Status Accounts
Assist the Project Manager to maintain the Issue Register.
10
Progress
10 Progress

10.1 Purpose 10.2.2 What are progress controls?


The purpose of the Progress theme is to Progress controls ensure that for each level of
establish mechanisms to monitor and compare the project management team the next level of
actual achievements against those planned; management can:
provide a forecast for the project objectives and Monitor progress
the projects continued viability; and control any Compare level of achievement with plan
unacceptable deviations. Review plans and options against future
situations
Two of the principles of PRINCE2 are managing
Detect problems and identify risks
by stages and continued business justification.
Initiate corrective action
The Progress theme provides the mechanisms
Authorize further work.
for monitoring and control, enabling the critical
assessment of ongoing viability.
10.2.3 Exceptions and tolerances
The Progress theme provides such mechanisms
An exception is a situation where it can be forecast
for all management levels (delivering, managing,
that there will be a deviation beyond the agreed
directing) within the project management team,
tolerance levels.
and for corporate or programme management
outside the project. Tolerances are the permissible deviation above and
below a plans target for time and cost without
Another PRINCE2 principle is that projects are
escalating the deviation to the next level of
managed by exception, setting tolerances for
management. There may also be tolerance levels
project objectives to establish limits of delegated
for quality, scope, benefit and risk.
authority. Tolerances define the amount of
discretion that each management level can If tolerances are not implemented, there is no clear
exercise without the need to refer up to the next measure of discretion if things do not go to plan.
level for approval. The Progress theme provides For example, if every minor deviation is escalated
the mechanisms to monitor progress against the to the Project Board, the Project Manager is merely
allowed tolerances, and the controls to escalate to monitoring the work and making no effort to
the next level should any forecast suggest that one implement corrective action clearly unsatisfactory
or more tolerances will be exceeded. from the Project Board members point of view.
In effect, the Project Board is having to do the
Control of progress is all about decision making
Project Managers job. On the other hand, if the
and is central to project management, ensuring
Project Manager carries on working to put things
that the project remains viable against its approved
right, implementing corrective actions, there is
Business Case.
the risk that Project Board members will see this
as exceeding the Project Managers (unwritten)
10.2 Progress defined discretion, and will question why the problems
were not escalated earlier. In this instance, the
10.2.1 What is progress? Project Manager is seen as taking on the Project
Progress is the measure of the achievement of the Boards role.
objectives of a plan. It can be monitored at Work Table 10.1 describes where tolerances may be
Package, stage and project level. usefully applied and shows in which management
product they are documented.
102 | Progress

Table 10.1 The six tolerance areas by level

Work
Product
Project level Stage level Package
Tolerance areas level
tolerances tolerances level
tolerances
tolerances
Time
Work
+/- amounts of time on target completion Project Plan Stage Plan NA
Package
dates

Cost Work
Project Plan Stage Plan NA
+/- amounts of planned budget Package

Scope
Permitted variation of the scope of a Work
Project Plan Stage Plan
project solution, e.g. MoSCoW prioritization Package NA
of requirements (Must have, Should have, (note 1) (note 1)
(note 1)
Could have, Wont have for now).

Risk
Limit on the aggregated value of threats
(e.g. expected monetary value to remain less Risk Stage Plan Work
Management Package NA
than 10% of the plans budget); and (note 2)
Strategy (note 2)
Limit on any individual threat (e.g. any
threat to operational service)

Quality Project NA NA Product


Defining quality targets in terms of ranges, Product
(note 3) (note 3) Description
e.g. a product that weighs 300g +/- 10g Description
Benefits
Defining target benefits in terms of ranges,
Business
e.g. to achieve minimum cost savings of NA NA NA
Case
5% per branch, with an average of 7%
across all branches

Note 1 the scope of a plan is defined by the set of products to be delivered. Scope tolerance (if used)
should be in the form of a note on or reference to the product breakdown structure for the plan. Scope
tolerance at the stage or Work Package level is of particular use if applying a time-bound iterative
development method such as Agile.

Note 2 more specific stage level risk tolerances may be set by the Project Board when authorizing a
stage or by the Project Manager when commissioning Work Packages, especially from external suppliers.

Note 3 quality tolerances are not summarily defined at the stage or Work Package level but are defined
per Product Description within the scope of the plan.

10.3 The PRINCE2 approach to Dividing the project into management stages
progress and authorizing the project one stage at a time
Time-driven and event-driven progress-
Progress control involves measuring actual progress
reporting and reviews
against the performance targets of time, cost,
Raising exceptions.
quality, scope, benefits and risk, and then using this
information to make decisions (such as whether The projects controls should be documented in the
to approve a stage or Work Package, whether to Project Initiation Documentation.
escalate deviations, whether to prematurely close
the project etc.) and to take actions as required. 10.3.1 Delegating authority
PRINCE2 provides progress control through:
10.3.1.1 The four levels of management
Delegating authority from one level of
The principle of management by exception uses
management to the level below it
six types of tolerance against which a project can
Progress | 103

be controlled. The allocation of tolerances follows


the four levels of the project management team as Corporate or programme management
outlined in Figure 10.1 and described below:
Corporate or programme management
Project Project
sits outside the project but sets the overall tolerances progress/exceptions
requirements and tolerance levels for the
project. The three levels of management within
the project (responsible for directing, managing
Project Board
and delivering) will manage and implement
within these tolerances and escalate any
forecast breaches of project tolerance
Stage Stage
The Project Board has overall control at a tolerances progress/exceptions
project level, as long as forecasts remain within
project tolerance, and will allocate tolerances
for each management stage to the Project Project Manager
Manager. The Project Board has the ability
to review progress and decide whether to
continue, change or stop the project. During Work Package Work Package
execution of the Project Plan, if any forecasts tolerances progress/issues
indicate that the project is likely to exceed the
agreed project tolerances, then the deviation
should be referred to corporate or programme Team Manager
management by the Project Board in order to
get a decision on corrective action
Figure 10.1 Delegating tolerance and reporting
The Project Manager has day-to-day control actual and forecast progress
for a management stage within the tolerance
limits laid down by the Project Board. During
After the pre-project process Starting up
execution of a Stage Plan, if any forecasts
a Project, the Project Board authorizes
indicate that the stage is likely to exceed the
progress to the initiation stage, which is the
agreed stage tolerances, then the deviation
official start of the project
should be referred to the Project Board by the
After the Initiating a Project process, the
Project Manager in order to get a decision on
Project Board reviews the information from
corrective action
the Project Initiation Documentation and,
The Team Manager has control for a Work
if satisfied that there is sufficient reason
Package, but only within the Work Package
to go ahead with the project, can approve
tolerances agreed with the Project Manager.
the Project Initiation Documentation and
During execution of the Work Package, if
authorize the project itself
any forecasts indicate that it is likely that the
After the Managing a Stage Boundary
agreed tolerances will be exceeded, then the
process, the Project Board reviews a
deviation should be referred to the Project
Stage Plan or Exception Plan, and can
Manager by the Team Manager in order to get
either approve the plan, with its relevant
a decision on corrective action.
tolerances for the next management stage,
or, if there is insufficient justification to
10.3.1.2 Project Board controls
continue with the project, trigger premature
The main controls available to the Project Board closure of the project
include:
After the Closing a Project process, the
Authorizations The Project Board uses the Project Board reviews the End Project Report
Directing a Project process to authorize and, if satisfied that the project is complete
initiation, authorize the project, authorize each or has nothing more to offer, can authorize
stage and, finally, authorize project closure: its closure
104 | Progress

Progress updates Including Highlight Reports Facilitate the management by exception


and End Stage Reports principle by delegating authority to the Project
Exceptions and changes Including Exception Manager on a stage-by-stage basis.
Reports and Issue Reports. The Project Board authorizes one management
When the Project Board has agreed stage stage of the project at a time. Towards the end
tolerances with the Project Manager, it is kept of each stage, during the Managing a Stage
informed of progress by means of Highlight Boundary process, the Project Manager will review
Reports. There is no need for regular progress the Business Case and Project Plan, update the
meetings during this stage, although personnel project documentation with the results of the
with Project Assurance responsibilities will require stage, and create an End Stage Report and Stage
regular contact with the Project Manager and team Plan to request authorization to commence the
members. next management stage. The End Stage Report,
together with the Stage Plan for the next stage,
10.3.1.3 Project Manager controls should contain all the information necessary to
enable the Project Board to conduct an end stage
The main controls available to the Project Manager
assessment and make a decision as to whether
include:
to proceed. The Project Board only authorizes
Authorizations Project Manager authorizations the next management stage if there is sufficient
occur during the process Controlling a Stage business justification to continue. If the project no
(see Chapter 15). The Project Manager will be longer has a valid Business Case, the Project Board
responsible for agreeing and authorizing Work has the authority to prematurely close it.
Packages and Work Package tolerances
The Project Board delegates the authority for day-
Progress updates Including Checkpoint Reports to-day control of a stage, within agreed tolerances,
produced by Team Managers or team members to the Project Manager. As long as the stage is
Exceptions and changes Use of project registers forecast to remain within tolerance, the Project
and logs to review progress and identify issues Manager has discretion to make adjustments as
and risks that may need to be resolved. These required. This allows the Project Board to manage
are discussed further in section 10.3.3.2. by exception, retaining the level of control
it requires while reducing the administrative
10.3.2 Use of management stages for overhead of being involved.
control
Management stages are partitions of the project 10.3.2.1 Number of stages
with management decision points. A management The use of management stages in a PRINCE2
stage is a collection of activities and products project is mandatory, but the number of stages
whose delivery is managed as a unit. As such, this is flexible and depends on the scale and risk of
stage is a subset of the project and, in PRINCE2 the project. Every PRINCE2 project consists of
terms, is the element of work that the Project at least two management stages. The initiation
Manager is managing on behalf of the Project stage is mandatory as it ensures that there is a
Board at any one time. firm basis for the project, which is understood
by all parties. There should also be at least one
Management stages:
other management stage to cover the remainder
Provide review and decision points, giving the of the project. For larger projects, additional
Project Board the opportunity to assess the management stages may be needed to enable the
project viability at regular intervals, rather than project management team to have an optimal level
let it run on in an uncontrolled manner of planning and control.
Give the ability to ensure that key decisions Defining management stages is fundamentally a
are made prior to the detailed work needed to process of balancing:
implement them
How far ahead in the project it is sensible to
Allow clarification of what the impact will be
of an identified external influence, such as the plan
corporate budget round or the finalization of Where the key decision points need to be on
legislation the project
Progress | 105

The amount of risk within a project The level of risk Management stages can be
Too many short management stages (increasing very useful as a means of bringing Project Board
the project management overhead) versus too control to risky projects. Stage breaks can be
few lengthy ones (reducing the level of control) inserted at key points when risks to the project
How confident the Project Board and Project can be reviewed before major commitments of
Manager are in proceeding. money or resources.

The number of management stages required will 10.3.2.3 Technical stages


be dictated by the nature of the project and its Another method of grouping work is by the
duration. For short-duration projects (where the set of techniques used or the products created.
project can be completed within the planning This results in stages covering elements such as
horizon, for example), the introduction of multiple design, build and implementation. Such stages are
management stages could result in unnecessary technical stages and are a separate concept from
overheads and additional costs. the management stages already introduced.

10.3.2.2 Length of stages Technical stages often overlap (as in Figures 10.2
and 10.3) but management stages do not. Technical
PRINCE2 does not define how long a management
stages are typified by the use of a particular set
stage should be. Stages should be shorter when
of specialist skills. Management stages equate to
there is greater risk, uncertainty or complexity,
commitment of resources and authority to spend.
for example at the beginning and end of projects.
They can be longer when risk is lower, typically in Often the boundary of the two types of stage will
the middle of projects. Further, the length of those coincide for instance, where the management
management stages may vary depending on the decision is based on the output from the technical
point within the project lifecycle. Factors that will stage. However, on other occasions the stage
influence this decision include: boundaries will not coincide for example, there
might be more than one technical stage per
The planning horizon at any point in time
management stage.
The planning horizon may vary depending
on the nature of the work being undertaken. Where a technical stage spans a management
For example, the work involved in installing stage boundary, the extent to which the product(s)
a computer system during an application of the technical stage should be complete at the
migration project may be better understood stage boundary should be clear in the Product
and less risky than the work involved with Description(s) concerned.
migrating the application itself Figures 10.2, 10.3 and 10.4 give examples of the
The technical stages within the project The distinction between technical and management
end of management stages do not necessarily stages. Figure 10.2 shows a project with five
need to occur at the same time as the end of technical stages.
technical stages, but there are often benefits
if they do. For example, the Project Board may Figure 10.3 shows the same project from Figure
wish to be able to understand any effects on 10.2, but broken down into four management
the Business Case of the results of a proof stages. Two of the technical stages span more than
of concept before committing to a full-scale one management stage.
deployment Figure 10.4 shows that the technical stage of
Alignment with programme activities It designing has been broken into three product
may be a requirement to align the end of a groups. The overall design now falls within
management stage with the end-of-tranche management stage 1; detailed design and training
review within the programme. This will allow syllabus form the second management stage; and
the project to contribute fully to the assessment periphery design is scheduled for management
of the ongoing viability of the programme itself stage 3, together with the creation of the built
facility and trained staff.
106 | Progress

Project
10.3.3 Event-driven and time-driven
Specifying controls
PRINCE2 provides two types of progress control
Designing
throughout the life of a project:
Building Event-driven controls Take place when
a specific event occurs. This could be, for
Training example, the end of a stage, the completion
of the Project Initiation Documentation or the
creation of an Exception Report. It could also
Commissioning include organizational events that might affect
the project, such as the end of the financial
Figure 10.2 Specialist work defined in technical year
stages Time-driven controls Take place at predefined
Project
periodic intervals. This could be, for example,
Management stage 1 Management stage 2 Management stage 3 Management stage 4
producing monthly Highlight Reports for the
Project Board or weekly Checkpoint Reports
Specifying
showing the progress of a Work Package.
Designing Monitoring and reporting requires a time-based
approach, whereas control (decision making) is an
Building event-based activity.
The following sections describe the management
Training products that are used to establish and execute
event-driven and time-driven controls.

Commissioning
10.3.3.1 Baselines for progress control
Figure 10.3 Specialist work crossing management It is only possible to control at the level of
stage boundaries resolution in the plans, i.e. if you want to have
Checkpoint Reports weekly, you need to know (in
Project
the Stage Plan) what you expect to achieve week
Management stage 1 Management stage 2 Management stage 3 Management stage 4
by week.

Specification The following management products assist the


Detailed Peripheral
Project Manager in establishing baselines for
Overall
design design design progress control:
Project Plan This will include the project-
Built facility
level performance targets and tolerances. Any
Training
syllabus
threat to the project-level tolerances needs to
Trained staff
be escalated to the Project Board, which will
seek advice from corporate or programme
Commissioned
facility
management for corrective action
Stage Plans These form the basis of the day-to-
day control of the stage. They should contain
Figure 10.4 Specialist work aligned to
details of the activities to be conducted during
management stages
a management stage, their timescales, and the
The PRINCE2 approach is to concentrate the resources needed to carry them out
management of the project on the management Exception Plan The Project Board may request
stages since these will form the basis of the an Exception Plan after having considered an
planning and control processes described Exception Report during the process Directing a
throughout the method. To do otherwise runs the Project. The Exception Plan should be produced
risk of the project being driven by the specialist at the same level as the plan that it replaces
teams instead of the customers management.
Progress | 107

Work Packages The Project Manager authorizes the Daily Log and marked off when completed.
a Work Package in order to trigger an Actions involving significant effort may need
individual team member or a Team Manager to to be incorporated into the Stage Plan. If such
undertake a piece of work during a stage. This actions cannot be incorporated into the plan
means that work cannot be undertaken unless within tolerances, then an issue should be raised
the Project Manager has specifically authorized to examine their impact on the stage and project.
it. Details of the work to be completed within The Daily Log can also be used to record informal
what tolerances must be agreed between the issues and any other notes or observations
Project Manager and Team Manager or team that are not captured by any other registers or
member, and documented in the Work Package. logs. The Daily Log is a useful way of recording
Work Package authorization is a particularly individual observations that on their own may
useful control when dealing with contractors seem insignificant, but when collated may alert
or subcontractors. The individuals or teams the Project Manager to a new issue or risk
monitor progress against the Work Package Issue Register This will contain details of all
and report back to the Project Manager via formal issues raised during the project, which
Checkpoint Reports. A project may be a mix of could take the form of requests for change, off-
internal and external teams. It may therefore be specifications or problems/concerns. Reviewing
valid to use a mixture of formal and informal the Issue Register may uncover progress issues
Work Packages of varying sizes, with tight or for example, a sudden increase in the number
loose tolerances, depending on the needs of of requests for change, or an increasing number
the project. of overdue corrective actions
Product Status Account This provides a
10.3.3.2 Reviewing progress snapshot of the status of products within the
As part of Controlling a Stage, the Project project, management stage or a particular area
Manager will regularly review the progress of of the project. It can reveal progress issues as
work through Checkpoint Reports and maintain it shows the planned and actual dates for key
a set of project registers and logs. The Project points in the production, review and approval
Manager will use this information to update the of the products to be delivered by the plan.
Stage Plan with actual progress achieved. The The Product Status Account is derived from the
frequency of checkpoint reporting required may Configuration Items Records
change according to the needs of individual Work Quality Register This is a record of all planned
Packages. and implemented quality activities. The Quality
It is also useful to look at trends to get a view of Register can reveal progress issues as the
the overall health of the stage. For example, the Project Manager can assess whether any quality
stage may seem to be progressing well in terms activities are outstanding or whether there are
of the products being completed against the any useful trends in the quality results for
schedule. However, the Issue Register may reveal example, an increasing number of products
an increasing number of issues which are not being failing quality review or an increase in the
resolved and which may be a cause for concern. average number of quality review actions
Similarly, a high number of outstanding items Risk Register This is a record of all identified
against a product in the Quality Register may show risks. The Project Manager should review the
design issues with that product. Risk Register as part of reviewing stage status.
As risks are driven by uncertainty, the number
The following management products assist the of risks should generally decrease as the project
Project Manager in reviewing progress: progresses and the level of certainty increases.
Daily Log This is a useful tool for recording The Risk Register should be reviewed to
actions. Project actions may arise from many determine whether the aggregated risks may
sources, including checkpoints, quality reviews, impact on progress for the remainder of the
end stage assessments or ad hoc conversations. stage and project, e.g. there may be a large
There is a danger that actions may get lost if number of risks with similar proximity in time,
they are only recorded in minutes or progress indicating a period where progress may be
reports. Small actions may simply be recorded on affected.
108 | Progress

PRINCE2 to the project, or the analysis of


Progress evaluation techniques
quality statistics and measurements
Measuring the progress of a management stage Lessons Report Although lessons may be
involves looking backwards, at the progress identified and recorded during a project,
made against plans, and forwards, at what still learning lessons involves taking action to
needs to be completed with what time and implement improvements. These actions may
resources. There are many techniques available apply to the current project, in which case they
to measure project progress, including: should be incorporated into the appropriate
Milestone chart This is a graphical chart plans and Work Packages, or they may be
showing key planned and actual milestones relevant to different projects. If a lesson is
in a stage significant and has relevance for future projects,
it should be included in the Lessons Report. It is
S-curve This is a graph showing cumulative
important to note that actions to learn lessons
actual figures (for example, costs or hours)
can be taken, and the Lessons Report created,
plotted against time. The curve is usually
at any appropriate time during a project. As a
shaped like the letter S, reflecting the fact
minimum, however, a Lessons Report should be
that a project typically consumes fewer
produced during the Closing a Project process.
resources and costs at the start and end
of the project, and more in the middle. 10.3.3.4 Reporting progress
The steeper the curve, the more resources
The frequency of reporting should reflect the level
required. When planned and actual figures
of control required, and this is likely to vary during
are shown on the same chart, this can be
the project. For example:
used to identify potential overspend or
forecast areas where tolerances may be During the design stage, less frequent control
exceeded may be required than during later management
Earned value management This is a stages
technique to measure the scope, schedule If the team is highly experienced then less
and cost performance compared with plans, frequent reporting may be appropriate,
by comparing the completed products and whereas for an inexperienced team the Project
the actual cost and time taken against their Manager may wish to increase the frequency of
schedule and cost estimates. PRINCE2s reporting until sufficient confidence has been
product-based approach to planning gained on the capability of the team.
provides the prerequisites needed for The following management products are used for
earned value management. progress reporting:
Checkpoint Report The Team Manager will
10.3.3.3 Capturing and reporting lessons
produce this to provide the Project Manager
The following management products are used for with details of progress against the Work
capturing and reporting lessons when reviewing Package. The Work Package will include the
progress: frequency of Checkpoint Reports required.
Lessons Log One of the principles of a PRINCE2 The Project Manager will collate Checkpoint
project is that the project management team Reports and use these as part of the progress
learns from experience, which means that assessment when reviewing stage status
lessons are sought, recorded and actioned Highlight Report The Project Manager
throughout. It is often in the reviewing of produces this report on management stage
progress that lessons are identified. Lessons progress for the Project Board. The Project
could include information about management Board will determine the frequency of
or specialist processes, products, techniques or Highlight Reports required, either for the whole
procedures that either made a contribution to project or stage by stage, and document this
the projects achievements or caused a problem in the Communication Management Strategy.
for example, the performance of the project The Highlight Report allows members of the
management team, the success of tailoring Project Board to manage by exception between
end stage assessments as they are aware of the
Progress | 109

tolerances agreed with the Project Manager time to consider or reject the recommendations
in the Stage Plan. The Highlight Report should in the Issue Report. If an Exception Plan is
confirm that progress is being made within requested, the Project Board will conduct
these tolerances and provide early warning an exception assessment, similar to the end
of possible problems which may need actions. stage assessment, to review and approve the
As part of the Communication Management Exception Plan
Strategy, the Project Board can request that Project-level exceptions If the forecast is for
copies of the Highlight Report be sent to project tolerances to be exceeded, the Project
other interested parties outside the project. Board no longer has the authority to manage
The Project Board may also issue the Highlight the project and must refer the matter to
Report (or a summary of it) to corporate or corporate or programme management for a
programme management decision. The Project Board may request the
End Stage Report This is produced by the Project Manager to produce an Exception Plan
Project Manager towards the end of each for the project.
management stage, providing the Project Board
Refer to Chapter 9 for more information on issue
with the information on the progress to date,
and change control procedures.
the overall project situation and (in tandem
with the next Stage Plan) sufficient information
to ask for a Project Board decision on what to 10.4 Responsibilities
do next with the project Table 10.2 outlines the responsibilities relevant
End Project Report This is produced by the to the Progress theme. Refer to Appendix C for
Project Manager towards the end of the further details of project management team roles
project, during the Closing a Project process, and their associated responsibilities.
and is used by the Project Board to evaluate the
project and authorize closure.

10.3.4 Raising exceptions


The output from reviewing progress is a decision
as to whether the Work Package, Stage Plan or
Project Plan remain, or are forecast to remain,
within agreed tolerances:
Work-Package-level exceptions Having
agreed Work Package tolerances with the
Team Manager, the Project Manager should
be kept informed of progress through regular
Checkpoint Reports. If a Work Package is
forecast to exceed its tolerances, the Team
Manager should inform the Project Manager by
raising an issue. The Project Manager will advise
of any corrective actions required
Stage-level exceptions If the stage is forecast
to exceed its tolerances, the Project Manager
should produce an Issue Report to capture and
analyse the details of the deviation and then
provide an Exception Report for the Project
Board. Based on information in this report,
the Project Board may request that the Project
Manager produces an Exception Plan to replace
the plan that was forecast to exceed tolerance.
The Project Board may also remove the cause,
accept and adjust tolerance, or request more
110 | Progress

Table 10.2 Responsibilities relevant to the Progress theme


Role Responsibilities
Corporate or programme Provide project tolerances and document them in the project mandate.
management
Make decisions on Exception Plans when project-level tolerances are forecast to be
exceeded.

Executive Provide stage tolerances.


Ensure that progress towards the outcome remains consistent from the business
perspective.

Make decisions on Exception Plans when stage-level tolerances are forecast to be


exceeded.

Recommend future action on the project to corporate or programme management if


the project tolerance is forecast to be exceeded.

Senior User Ensure that progress towards the outcome remains consistent from the user
perspective.

Senior Supplier Ensure that progress towards the outcome remains consistent from the supplier
perspective.

Project Manager Authorize Work Packages.


Monitor progress against Stage Plans.
Produce Highlight Reports, End Stage Reports , Lessons Reports and End Project Report.
Produce Exception Reports for the Project Board when stage-level tolerances are
forecast to be exceeded.

Maintain the projects registers and logs.


Team Manager Agree Work Packages with the Project Manager.
Inform Project Support of completed quality activities.
Produce Checkpoint Reports.
Notify the Project Manager of any forecast deviation from Work Package tolerances.
Project Assurance Verify the Business Case against external events and project progress.
Verify changes to the Project Plan to see whether there is any impact on the needs of
the business or the Business Case.

Confirm stage and project progress against agreed tolerances.


Project Support Assist with the compilation of reports.
Contribute specialist tool expertise (for example, planning and control tools).
Number, record, store and distribute Issue Reports and Exception Reports.
Assist the Project Manager in maintaining the Issue Register and Risk Register.
Maintain the Quality Register on behalf of the Project Manager.
11
Introduction to
processes
11 Introduction to processes

11.1 The PRINCE2 processes 11.2.1 Pre-project


PRINCE2 is a process-based approach for project In the beginning, someone has an idea or a need.
management. A process is a structured set of This may result from new business objectives,
activities designed to accomplish a specific responding to competitive pressures, changes
objective. It takes one or more defined inputs and in legislation, or a recommendation in a report
turns them into defined outputs. or an audit. The trigger for the project could be
almost anything. In PRINCE2, this trigger is called a
There are seven processes in PRINCE2, which project mandate. The project mandate is provided
provide the set of activities required to direct, by the commissioning organization (corporate or
manage and deliver a project successfully. programme management) and can vary in form
Figure 11.1 shows how each process is used from a verbal instruction to a well-defined and
throughout a projects life. justified project definition.
Prior to the activity to fully scope the project, it is
11.2 The PRINCE2 journey important to verify that the project is worthwhile
and viable. Such activities are covered by the
The Project Board sets direction and makes key
process Starting up a Project (see Chapter 12),
decisions throughout the life of the project.
which culminates in the production of a Project
The Project Boards activities are covered by the
Brief and a Stage Plan for project initiation.
Directing a Project process (see Chapter 13), which
runs from pre-project through to, and including, The Project Board reviews the Project Brief and
the final stage. decides whether to initiate the project, and states

Initiation Subsequent Final delivery


Pre-project
stage delivery stage(s) stage

Directing a Project
Directing
SU

SB SB CP
Managing
IP Controlling a Stage Controlling a Stage

Managing Product Delivery Managing


Delivering Product Delivery

Key Note
SU = Starting up a Project Starting up a Project is used by both the directing and
IP = Initiating a Project managing levels.
SB = Managing a Stage Boundary There should be at least two management stages, the first
CP = Closing a Project of which is the initiation stage.
Managing a Stage Boundary is first used at the end of the
initiation stage and repeated at the end of each subsequent
stage except the final stage. It is also used to prepare Exception
Plans, which can be done at any time including in the final stage.
For complex or lengthy initiations, Controlling a Stage
and Managing Product Delivery can optionally be used to
Figure 11.1 The PRINCE2 processes manage the initiation stage.
114 | Introduction to processes

the levels of authority to be delegated to the the Project Manager appraised of progress via
Project Manager for the initiation stage. Checkpoint Reports.
Towards the end of each management stage, the
11.2.2 Initiation stage Project Manager requests permission to proceed
Once there is a decision to go ahead with the to the next stage by reporting how the stage
project, it needs to be planned in detail. Funding performed, providing an update to the Business
needs to be obtained and controls should be Case and planning the next management stage
defined to ensure that the project proceeds in in detail. The Project Manager provides the
accordance with the wishes of those people paying information needed by the Project Board in order
for the project and those who will make use of for it to assess the continuing viability of the
what the project delivers. The detailed planning, project and to make a decision to authorize the
establishment of the project management next management stage. The activities to manage
strategies and controls, development of a robust each stage boundary are covered in the Managing
Business Case, and a means of reviewing benefits a Stage Boundary process (see Chapter 17).
are covered by the Initiating a Project process (see
Chapter 14). Also, during the initiation stage, the 11.2.4 Final delivery stage
Managing a Stage Boundary process (Chapter 17) is
As a project is a temporary undertaking, during the
used to plan the next stage in detail.
final stage (once the Project Manager has gained
The initiation stage culminates in the production approval for all of the projects products) it is time
of the Project Initiation Documentation, which is to decommission the project. The Project Board
reviewed by the Project Board to decide whether needs to be satisfied that the recipients of the
to authorize the project. As the contents of the projects products are in a position to own and use
Project Initiation Documentation are likely to them on an ongoing basis. Should this be the case,
change throughout the project (under change the products can be transitioned into operational
control), this version of the Project Initiation use and the project can close. The project
Documentation is preserved as input for later documentation should be tidied up and archived,
performance reviews. the project should be assessed for performance
against its original plan and the resources assigned
11.2.3 Subsequent delivery stages to the project need to be released. The closure
The Project Board delegates day-to-day control activities include planning post-project benefits
to the Project Manager on a stage-by-stage basis. reviews to take place for those benefits that
The Project Manager needs to assign work to can only be assessed after the products have
be done, ensure that the outputs of such work been in use (and therefore after the project has
(products) meet relevant specifications, and gain closed). The activities to decommission a project
suitable approval where appropriate. The Project are covered by the Closing a Project process (see
Manager also needs to ensure that progress is in Chapter 18).
line with the approved plan and that the forecasts
for the projects performance targets are within 11.3 The PRINCE2 process model
agreed tolerances. The Project Manager ensures
that a set of project records (Daily Log, Lessons The PRINCE2 process model is shown in Figure 11.2.
Log, Issue Register, Risk Register, Quality Register The processes are aligned to the management
and Configuration Item Records) are maintained to levels of corporate or programme, directing,
assist with progress control. The Project Manager managing and delivering. The triggers between
informs the Project Board of progress through each process are shown.
regular Highlight Reports. The activities to control
each stage are covered by the Controlling a Stage
process (see Chapter 15).
11.4 Structure of the process
chapters
In the Managing Product Delivery process (see
Chapter 16), the Team Manager(s) or team Each process within PRINCE2 is described using the
members execute assigned Work Packages (that following structure and format.
will deliver one or more products) and keep
Introduction to processes | 115
Corporate or
programme

Corporate
Project mandate advice and
decisions

Project Project Board


Initiation Closure
authorization request for
notification notification
notification advice

Directing a Project
Direction

Stage
Authorization

Authority to Exception Plan Exception Plan Project Board Premature


initiate a project request approved advice close

Request to approve
Starting up a Project

Exception Plan

Request to approve Closure


Request to Request to
next Stage Plan recommendation
initiate a project deliver a project
Management

Initiating a Managing a
Closing a Project
Project Stage Boundary
Exception
raised

Request
Stage boundary Project end
for advice
approaching approaching

Controlling a Stage

Authority to deliver
a Work Package

Completed
Work Package
Delivery

Managing Product Delivery

Notes:

Note 1: at the end of the initiation stage, the Initiating a Project process is used to request Project Board approval
to initiate the project (with the submission of the Project Initiation Documentation) and in parallel the Managing
a Stage Boundary process is used to request Project Board approval of the Stage Plan for the second
management stage.

Note 2: the closure activities are planned and approved as part of the stage approval for the final stage; therefore
the Closing a Project process takes place in the final stage.

Figure 11.2 PRINCE2 process model

11.4.1 Purpose the project and from corporate or programme


management.
This section describes the reason for the process.

11.4.2 Objective 11.4.4 Activities


PRINCE2 processes comprise a set of activities,
This section describes the specific objectives to be
which may be run in series or in parallel. PRINCE2
achieved by the process.
activities comprise a set of recommended actions
designed to achieve a particular result.
11.4.3 Context
This section puts each process in context with the The relationship between processes, activities and
other processes and activities going on within actions is shown in Figure 11.3.
116 | Introduction to processes

Each one comprises


Processes

Activities Each one comprises

Recommended
actions

Figure 11.3 Relationship between processes, activities and actions

A diagram is provided for each activity showing Note that management products created during
the inputs and outputs, including those products one process may be approved in another (e.g. a
that are created or updated by that activity. The Stage Plan is created in the Managing a Stage
recommended actions to be taken to achieve the Boundary process but is approved in the Directing
objectives of the activity are described. a Project process). However, the complete set of
responsibilities is shown, and those covered by
Each activity is concluded by a table showing
another process are indicated by being shown in
the responsibilities for each product created or
parentheses, e.g. (A).
updated during the activity, as illustrated in
Table 11.1.

Table 11.1 An example of a table of responsibilities

Producer responsible for products production


Reviewer ideally independent of production

Product Description available


Approver confirms approval
Corporate/Programme

Project Assurance
Project Manager

Project Support
Team Manager
Senior Supplier
Senior User
Executive

Product Action
Stage Plan Create (A) (A) (A) P R A16
Introduction to processes | 117

Table 11.2 Key to process diagrams

Symbol Key

This is a PRINCE2 process.


Starting up
a Project

Authorize This is an activity. Each process comprises a number of activities.


initiation

This is an event or decision that triggers another process or is used to


Exception Plan notify corporate or programme management. The arrow shows which
request process is triggered by the event.
Double triggers indicate where there are alternative triggers from one
process to another (e.g. a request to approve the next Stage Plan or a
request to approve an Exception Plan).
Corrective action Those with dotted lines are triggers internal to a process (e.g. corrective
action is a trigger from one activity in the Controlling a Stage process to
another).

Business Case These are management products that are created or updated by
a processs activities.
Those with hard lines are defined management products with Product
Description outlines in Appendix A.
Those with dotted lines are components of a management product or are
Follow-on action
recommendations non-defined management products where PRINCE2 does not require
specific composition or quality criteria.
Starting up a
12
Project
12Starting up a Project

12.1 Purpose 12.2 Objective


The purpose of the Starting up a Project process The objective of the Starting up a Project process is
is to ensure that the prerequisites for Initiating a to ensure that:
Project are in place by answering the question: do There is a business justification for initiating the
we have a viable and worthwhile project? project (documented in an outline Business Case)
Nothing should be done until certain base All the necessary authorities exist for initiating
information needed to make rational decisions the project
about the commissioning of the project is defined, Sufficient information is available to define and
key roles and responsibilities are resourced and confirm the scope of the project (in the form of
allocated, and a foundation for detailed planning is a Project Brief)
available. The various ways the project can be delivered
The purpose of the Starting up a Project process is are evaluated and a project approach selected
as much about preventing poorly conceived projects Individuals are appointed who will undertake
from ever being initiated as it is about approving the work required in project initiation and/or
the initiation of viable projects. As such, Starting up will take significant project management roles in
a Project is a lighter process compared to the more the project
detailed and thorough Initiating a Project process. The work required for project initiation is
The aim is to do the minimum necessary in order to planned (documented in a Stage Plan)
decide whether it is worthwhile to even initiate the Time is not wasted initiating a project based on
project. unsound assumptions regarding the projects
scope, timescales, acceptance criteria and
constraints.

Corporate or
Project mandate
programme
management

Directing a
Project

Appoint the Executive


and
the Project Manager

Design and appoint


Capture
previous lessons the project
management team

Select the
Prepare the outline
project approach and
Business Case
assemble the Project Brief

Request to
Plan the
initiate a project
Starting up a Project initiation stage

Figure 12.1 Overview of Starting up a Project


122 | Starting up a Project

12.3 Context The preparation of the outline Business Case and


the assembling of the Project Brief (which are
Projects can be identified in a variety of ways and
parallel and iterative activities) require regular and
thus have a wide variation in the information
frequent interaction and consultations between the
available at the time of start-up. PRINCE2 calls the
Project Manager, the Project Board members and
trigger for the project the project mandate, which
other stakeholders. The more time spent on getting
is provided by the responsible authority which is
the requirements clearly captured during the
commissioning the project typically the corporate
Starting up a Project process, the more time will
or programme management organization. The term
be saved during project delivery by avoiding issues,
project mandate applies to whatever information
exceptions and replanning.
is used to trigger the project, be it a feasibility
study or the receipt of a request for proposal in a The contents of the Project Brief are later
supplier environment. The project mandate should extended and refined into the Project Initiation
provide the terms of reference for the project and Documentation via the Initiating a Project process.
should contain sufficient information to identify at
12.4 Activities
least the prospective Executive of the Project Board.
The mandate is refined to develop the Project Brief. The activities within the Starting up a Project
The Project Board must be provided with sufficient process are likely to be shared between corporate
information to make the decision to initiate the or programme management, the Executive and the
project. The Project Brief is prepared for this Project Manager. The activities are to:
purpose. Appoint the Executive and the Project Manager
The effort involved in Starting up a Project will vary Capture previous lessons
enormously from project to project. If the project Design and appoint the project management
is part of a programme, the programme itself team
should provide the Project Brief and will appoint Prepare the outline Business Case
some, if not all, members of the Project Board, Select the project approach and assemble the
thus eliminating much of the work required in this Project Brief
process. In such cases, the Project Manager should Plan the initiation stage.
validate what is provided by the programme and, if
necessary, recommend modifications.

Appoint the Executive (Part of)


Project mandate and Project Brief
the Project Manager

Executive
Create role description

Project Manager
Create role description

Appointed
Executive

Appointed
Project Manager

Create
Daily Log

Figure 12.2 Appoint the Executive and the Project Manager: activity summary
Starting up a Project | 123

12.4.1 Appoint the Executive and the Establish the responsibilities for the
Project Manager Executive
Prepare the role description for the
To get anything done in the project, a decision
maker with appropriate authority is needed the Executive based on the role description in
Executive who represents the interests of the Appendix C
business stakeholder(s). The appointment of the Estimate the time and effort required for the

Executive is a prerequisite to ensuring that the Executive role (this will be refined later)
project is justified. Identify candidates for the Executive from

The appointment of a Project Manager allows for the projects stakeholders and select the
the project to be managed on a day-to-day basis on most appropriate person for the role
behalf of the Executive. The Executive may need to Confirm the selected persons availability,

consult with, and gain agreement from, corporate their acceptance of the role, and their
or programme management when appointing a commitment to carry it out
Project Manager. Assign the selected person to the role of
Executive
Figure 12.2 shows the inputs to, and outputs
The Executive to appoint the Project Manager:
from, this activity. For more details on project
Establish the responsibilities for the Project
organization, see Chapter 5.
Manager
PRINCE2 recommends the following actions: Prepare a role description for the Project
Review the project mandate and check Manager, based on the role description
understanding in Appendix C, and gain agreement from
Appoint the Executive (the appointment is corporate or programme management
made by the commissioning organization Identify candidates for the Project Manager
typically corporate or programme and select the most appropriate person for
management): the role

Table 12.1 Appoint the Executive and the Project Manager: responsibilities

Producer responsible for products production


Reviewer ideally independent of production

Product Description available


Approver confirms approval
Corporate/Programme

Project Assurance
Project Manager

Project Support
Team Manager
Senior Supplier
Senior User
Executive

Product Action
Project mandate Provide P
Executive role description Create P
Appointed Executive Confirm P
Project Manager role description Create A P
Appointed Project Manager Confirm A P
Daily Log Create P A7
124 | Starting up a Project

Estimate the time and effort required for


Figure 12.3 shows the inputs to, and outputs from,
the Project Manager role (this will be refined this activity.
later)
PRINCE2 recommends the following actions:
Confirm the selected persons availability,
their acceptance of the role, and their Create the Lessons Log
commitment to carry it out Review related Lessons Reports from similar
Assign the selected person to the role of previous projects to identify lessons that can
Project Manager be applied to this project. This may include,
Confirm the appointment with corporate or
for example, the results of audits and project
programme management reviews
Create the Daily Log as a repository for project Review any lessons from corporate
information that is not yet being captured management, programme management and
elsewhere. external organizations
Consult with individuals or teams with previous
Table 12.1 shows the responsibilities for this experience of similar projects
activity.
If appropriate, record any lessons identified in
the Lessons Log.
12.4.2 Capture previous lessons
A number of lessons may have been learned Table 12.2 shows the responsibilities for this
by other projects, corporate or programme activity.
management, and external organizations
12.4.3 Design and appoint the project
about weaknesses or strengths of the processes,
procedures, techniques and tools used, when they
management team
were used, how they were used, and by whom. The project needs the right people in place, with
The design of the project management team, the authority, responsibility and knowledge to
outline Business Case, the contents of the Project make decisions in a timely manner. The project
Brief, and the Stage Plan for the initiation stage management team needs to reflect the interests of
can be influenced by lessons learned from previous all parties who will be involved, including business,
projects. user and supplier interests.

It may be useful to hold a workshop as a means It is essential for a well-run project that every
to capture relevant lessons. Attendees could individual involved in the management of the
include any interested parties and people who project understands and agrees who is accountable
have worked on previous similar projects. If the to whom for what, who is responsible for what, and
organization has not done this type of project what the reporting and communication lines are.
before, it may be helpful to include people Figure 12.4 shows the inputs to, and outputs
external to the organization who have the relevant from, this activity. For more details on project
experience. organization, see Chapter 5.
When moving from the general view in Starting up
a Project to the detailed view in Initiating a Project
and updated view in Managing a Stage Boundary,
it may be necessary to look beyond the Lessons
Log, by repeating this activity, to capture any
further relevant external lessons.

Previous Capture Create


Lessons Log
lessons reports previous lessons

Figure 12.3 Capture previous lessons: activity summary


Starting up a Project | 125

Table 12.2 Capture previous lessons: responsibilities

Producer responsible for products production


Reviewer ideally independent of production

Product Description available


Approver confirms approval

Corporate/Programme

Project Assurance
Project Manager

Project Support
Team Manager
Senior Supplier
Senior User
Executive
Product Action

Lessons Log Create R P A14

PRINCE2 recommends the following actions: Consider whether separate individuals are
likely to be needed as Team Manager(s)
Review the Lessons Log for lessons related to
or whether the Project Manager will be
the project management team structure
filling this role. If appropriate, create role
Design the project management team:
descriptions for the Team Manager(s) based
Prepare the project management team on the role description in Appendix C
structure
Consider whether the Project Manager will
Create role descriptions for the remaining be performing the Project Support role or
Project Board roles based on the role whether a separate individual(s) will be
descriptions in Appendix C required. If this role is to be delegated,
Assess whether any members of the Project create the role description for the Project
Board are likely to delegate any of their Support role based on the role description in
assurance responsibilities, and create the role Appendix C
description(s) for Project Assurance (where Confirm the reporting and communication
appropriate) based on the role description in lines within the role descriptions
Appendix C

Design and appoint Update


Lessons Log Daily Log
the project
management team

(Part of) (Part of)


Project Brief Project Brief

Executive Project management


role description team role descriptions
Create

Project Manager Project


management team
role description
structure
Create

Appointed project
management team

Figure 12.4 Design and appoint the project management team: activity summary
126 | Starting up a Project

Appoint the project management team: appointment with corporate or programme


Estimate the time and effort required by management
each of the roles identified (this will be If any risks are identified, add them to the Daily
refined later) Log.
Identify candidates for each of the roles, and Table 12.3 shows the responsibilities for this
propose the most appropriate people for activity.
them:
It may be appropriate to undertake an 12.4.4 Prepare the outline Business Case
analysis of the stakeholders (see section
When setting up, and particularly while running
5.3.5) in order to identify suitable
the project, it is all too easy to concentrate on
candidates for the roles
what is being done and how it is to be done, while
It is possible that candidates may not be
ignoring why it needs to be done. The Business
known at this time, in which case they Case states why the work is worth doing and, as
will need to be selected later (see sections such, is a crucial element of the project.
14.4.5 and 17.4.1). This is particularly true
if Team Managers are to be sourced from If the project is part of a programme, then the
subcontractors Business Case may already have been defined at
Consider whether identified candidates
the programme level.
match the competencies required of the Given the information available, the outline
role and, if not, whether any training or Business Case is likely to be only a high-level view
support (e.g. coaching) is required at this time. It provides an agreed foundation for
Confirm the selected peoples availability a more extensive Business Case developed in the
(if they are known), their understanding Initiating a Project process.
and acceptance of the roles, and their
Figure 12.5 shows the inputs to, and outputs from,
commitment to carry them out
this activity. For more details on the Business Case,
Assign the selected people to each of see Chapter 4.
the roles identified and confirm the

Table 12.3 Design and appoint the project management team: responsibilities

Producer responsible for products production


Reviewer ideally independent of production Product Description available
Approver confirms approval
Corporate/Programme

Project Assurance
Project Manager

Project Support
Team Manager
Senior Supplier
Senior User
Executive

Product Action

Daily Log Update P A7


Project management team role descriptions Create A P
Project management team structure Create A P
Appointed project management team Confirm A P
Starting up a Project | 127

Prepare the outline (Part of)


Project mandate Business Case Project Brief

Lessons Log (Outline)


Business Case
Create

Project
Product Description
Create

Daily Log
Update

Figure 12.5 Prepare the outline Business Case: activity summary

PRINCE2 recommends the following actions: Check for any standards mandated for the
format and presentation of the Business Case
Executive to draft the outline Business Case
(templates, cost metrics etc.)
based on what is currently known about the
Assemble any relevant background
project:
information, e.g. contracts, feasibility
Understand the objectives of, and the
reports, service level agreements etc.
reasons for, the project as defined in the
If necessary, seek approval of the outline
project mandate
Business Case from corporate or programme
Understand how the project will contribute
management
toward corporate and/or programme
Project Manager to consult with the Senior
objectives
User and Executive to define what the project
Understand how the project will be funded
is to deliver, and create the Project Product
Review the Lessons Log for lessons related to
Description (see Chapter 6):
business justification

Table 12.4 Prepare the outline Business Case: responsibilities

Producer responsible for products production


Reviewer ideally independent of production
Product Description available

Approver confirms approval


Corporate/Programme

Project Assurance
Project Manager

Project Support
Team Manager
Senior Supplier
Senior User
Executive

Product Action
Outline Business Case Create A P R R R R A2

Project Product Description Create (A) (A) (A) P R A21

Daily Log Update P A7


128 | Starting up a Project

Capture the customers quality expectations


Consider any corporate or programme
Capture and agree the projects acceptance strategies that are relevant, and put the
criteria project in context with any other work or
Check feasibility of the timescale corporate initiatives by establishing external
requirements from the project mandate or dependencies and prerequisites
as required by the outline Business Case Consider any corporate or programme
Determine any key milestones standards or practices that should apply
Capture any new risks in the Daily Log
(in a commercial customer/supplier context
there are likely to be different standards and
Review the risks captured in the Daily Log and
practices which need to be accommodated)
summarize the key risks affecting viability of
Consider the current thinking about the
the project in the outline Business Case.
provision of solutions within the industry
Table 12.4 shows the responsibilities for this sectors and specialist skill areas involved
activity. (including any technical options for the
development lifecycle for the project
12.4.5 Select the project approach and product)
assemble the Project Brief Define the operational environment into
Before any planning of the project can be done, which the solution must fit (including
decisions must be made regarding how the work operational or maintenance implications and
of the project is going to be approached. For constraints) and how the project product can
example, will the solution be developed in-house be brought into that environment
or contracted to third parties? Will the solution be Consider any security constraints that
a modification to an existing product or built from apply to the project or the operation of its
scratch? Will the solution be based on a commercial products
off-the-shelf product (often referred to as COTS) or Consider any training needs for user
something that is custom-designed? personnel
The way in which the work is to be conducted will Assemble the Project Brief:
depend on any customer or supplier standards, Define the project:
practices and guidelines for example, any specific Confirm current status of the project (e.g.
development lifecycles that may apply. These project background and any preparation
should be captured in the Project Brief as part of work carried out to date)
the project approach, as they will influence the Confirm the objectives and desired
project strategies to be created in the Initiating outcomes
a Project process. It also ensures that the project Confirm the project scope and exclusions
approach is clearly understood between customer Identify any constraints and assumptions
and supplier, and does not jeopardize the project
Identify the project tolerances
in any way.
Identify the user(s) and any other known
An agreed Project Brief ensures that the project interested parties
has a commonly understood and well-defined start Identify the interfaces that the project
point. must maintain
Figure 12.6 shows the inputs to, and outputs from, Incorporate the outline Business Case
this activity. Incorporate the Project Product Description

PRINCE2 recommends the following actions: Incorporate the project approach


Review the project management team
Evaluate the possible delivery solutions and
structure and role descriptions to identify
decide upon the project approach appropriate
any additional roles or skills required to
to delivering the project product and achieving
conduct the work. Prepare additional role
the outline Business Case:
descriptions as necessary
Review the Lessons Log for lessons related to
Incorporate the project management team
the project approach
structure and role descriptions
Starting up a Project | 129

(Part of) Select the project Assemble


Project Brief approach and assemble Project Brief
the Project Brief

Project
Product Description Create Project approach

(Outline) Additional
Business Case Create role descriptions

Executive
role description Daily Log
Update

Project Manager
role description

Project management
team role descriptions

Project management
team structure

Lessons Log

Figure 12.6 Select the project approach and assemble the Project Brief: activity summary

Table 12.5 Select the project approach and assemble the Project Brief: responsibilities

Producer responsible for products production


Reviewer ideally independent of production
Product Description available
Approver confirms approval
Corporate/Programme

Project Assurance
Project Manager

Project Support
Team Manager
Senior Supplier
Senior User
Executive

Product Action

Project approach Create/select (A) (R) (R) P R

Additional role descriptions Create (A) (R) (R) P R

Project Brief Assemble (A) (R) (R) P R A19


Daily Log Update P A7
130 | Starting up a Project

Use the Daily Log to record any new issues or Identify any constraints on time and costs for
risks. the initiation stage and produce the Stage Plan
Table 12.5 shows the responsibilities for this for this stage according to the principles and
activity. techniques in Chapter 7
Review any risks in the Daily Log and assess
12.4.6 Plan the initiation stage their impact on the Stage Plan for the initiation
Initiating a Project takes time and consumes stage
resources. The work should be planned and If any new risks are identified (or existing ones
approved like any other project work. This have changed), update the Daily Log
also ensures that initiation is not aimless and Request authorization to initiate the project.
unstructured.
Table 12.6 shows the responsibilities for this
If the project is part of a programme, the end activity.
date for the initiation stage should be checked
against that held in the programmes plans. The
Stage Plan for the initiation stage will also give the
programme management team warning of any
requirements from the programme.
The application of PRINCE2 processes during
Initiating a Project needs to be considered as part
of the Starting up a Project process. For example,
the project may choose to apply the Controlling
a Stage and Managing Product Delivery processes
during the Initiating a Project process.
Figure 12.7 shows the inputs to, and outputs from,
this activity. For more details on planning, see
Chapter 7.
PRINCE2 recommends the following actions:
Based on the project approach, decide upon
suitable management controls for the project
sufficient for it to be initiated:
Review the Lessons Log for lessons related to
project controls
Define the reporting and control
arrangements for the initiation stage

Plan the Create


Project Brief Stage Plan
initiation stage

Update
Daily Log Daily Log

Request to
initiate a project
Lessons Log

Figure 12.7 Plan the initiation stage: activity summary


Starting up a Project | 131

Table 12.6 Plan the initiation stage: responsibilities

Producer responsible for products production


Reviewer ideally independent of production

Product Description available


Approver confirms approval

Corporate/Programme

Project Assurance
Project Manager

Project Support
Team Manager
Senior Supplier
Senior User
Executive
Product Action
Stage Plan Create (A) (A) (A) P R A16

Daily Log Update P A7


13
Directing a Project

13 Directing a Project

13.1 Purpose 13.3 Context


The purpose of the Directing a Project process is The Directing a Project process starts on completion
to enable the Project Board to be accountable for of the Starting up a Project process and is triggered
the projects success by making key decisions and by the request to initiate a project.
exercising overall control while delegating day-
The Directing a Project process does not cover the
to-day management of the project to the Project
day-to-day activities of the Project Manager, but
Manager.
the activities of those at the level of management
above the Project Manager: that is, the Project
13.2 Objective Board. The Project Board manages by exception. It
monitors via reports and controls through a small
The objective of the Directing a Project process is
number of decision points. There should be no
to ensure that:
need for other progress meetings for the Project
There is authority to initiate the project Board. The Project Manager will inform the board
There is authority to deliver the projects of any exception situation. It is also important that
products levels of authority and decision-making processes
Management direction and control are are clearly identified.
provided throughout the projects life, and that There needs to be a two-way flow of information
the project remains viable between the Project Board and corporate or
Corporate or programme management has an programme management during the project. It
interface to the project is a key role of the Project Board to engage with
There is authority to close the project corporate or programme management and to act
Plans for realizing the post-project benefits are as a communication channel. This need, and how
managed and reviewed. it is to be satisfied, should be documented in the
Communication Management Strategy.

Initiation Project Project Board Corporate Closure


notification authorization request for advice and notification
notification advice decisions

Authorize
initiation

Authorize
Directing a Project
the project

Authorize a Stage or
Exception Plan

Give ad hoc
direction

Authorize project
closure

Request to Project Manager


Stage approve
authorization request for New issue
Exception Plan advice
Request to Project Board
Request to Authority to Request to Exception Plan approve Exception Plan Exception Premature Closure
initiate a project initiate a project deliver a project approved request raised advice and close recommendation
next Stage Plan decisions

Starting up Initiating Managing a


a Project a Project Stage Boundary Closing a Project

Controlling a Stage

Figure 13.1 Overview of Directing a Project


136 | Directing a Project

The Project Board should provide unified direction Once a request to initiate a project is received
and guidance to the Project Manager. If the from Starting up a Project, the Project Board must
Project Board is unable to provide a single view decide whether to allow the project to proceed to
or if independent, possibly contradictory, advice is the initiation stage. This may be done at a formal
given, then the risk of project failure significantly Project Board meeting. The Project Board can,
increases. In such cases, the Project Manager should however, choose to make the decision without the
defer to the Executive. need for a formal meeting, as long as all members
are in agreement, and the Project Manager is given
The Project Board is responsible for assuring that
documented instruction from the Executive to
there is continued business justification. The
proceed with initiation.
Directing a Project process provides a mechanism
for the Project Board to achieve such assurance The Project Board may appoint Project Assurance
without being overburdened by project activity. to undertake some of the reviewing and assessing
actions (e.g. inspecting the Initiation Stage Plan to
One of the functions of the Project Board is to
confirm it is viable).
provide informal advice and guidance to the
Project Manager as well as formal direction. The In a commercial customer/supplier relationship,
Project Manager should seek advice whenever the Senior Supplier may not be appointed at this
necessary during the course of the project. point, and/or their approval of the Project Brief
and its components may not be necessary in order
to authorize initiation.
13.4 Activities
Figure 13.2 shows the inputs to, and outputs from,
The activities within the Directing a Project process
this activity.
are Project-Board-oriented and are to:
PRINCE2 recommends the following actions:
Authorize initiation
Authorize the project Review and approve the Project Brief:
Authorize a Stage or Exception Plan Confirm the project definition (including key
Give ad hoc direction milestones)
Authorize project closure. Confirm the project approach
Formally confirm the appointments to the
13.4.1 Authorize initiation project management team, and confirm that
Projects take time and cost money to initiate, so all members have agreed their roles
the activities for initiation should be planned,
monitored and controlled. The Project Board
activity to authorize initiation ensures that such
investment is worthwhile.

Approve
Request to Authorize Project Brief
initiate a project initiation

Approve Stage Plan


Project Brief (initiation)

Authority to
Stage Plan initiate a project
(Initiation)

Initiation
notification

Figure 13.2 Authorize initiation: activity summary


Directing a Project | 137

Review and approve the Project Product 13.4.2 Authorize the project
Description: This activity will be triggered by a request from the
Confirm the customers quality expectations Project Manager for authorization to deliver the
Confirm the acceptance criteria project, and should be performed in parallel with
Verify that the outline Business Case authorizing a Stage or Exception Plan (see section
demonstrates a viable project. At this point, 13.4.3).
the outline Business Case may only contain The objective of authorizing the project is to
sufficient information that reasonably justifies decide whether to proceed with the rest of the
the project as worthwhile. The detailed Business project. The Project Board has to confirm that:
Case will be developed during the initiation
An adequate and suitable Business Case exists
stage
and that it shows a viable project
Review and approve the Stage Plan for the
The Project Plan is adequate to deliver the
initiation stage:
Business Case
Understand any risks that affect the decision
The projects strategies and controls support
to authorize the initiation stage
delivery of the Project Plan
Obtain or commit the resources needed by
The mechanisms for measuring and reviewing
the Stage Plan for the initiation stage
the projected benefits are established and
Ensure that adequate reporting and control
planned.
mechanisms are in place for the initiation
stage and set tolerances for it If the project is not authorized by the Project
Board, then it should be prematurely closed (see
Inform all stakeholders and the host sites that
Chapter 18).
the project is being initiated and request any
necessary logistical support (e.g. communication The Project Board may appoint Project Assurance
facilities, equipment and any project support) to undertake some of the reviewing and assessing
sufficient for the initiation stage actions (e.g. inspecting the Communication
Authorize the Project Manager to proceed with Management Strategy to confirm all stakeholders
the initiation stage. are covered).

Table 13.1 shows the responsibilities for this Figure 13.3 shows the inputs to, and outputs from,
activity. this activity.

Table 13.1 Authorize initiation: responsibilities

Producer responsible for products production


Reviewer ideally independent of production
Product Description available

Approver confirms approval


Corporate/Programme

Project Assurance
Project Manager

Project Support
Team Manager
Senior Supplier
Senior User
Executive

Product Action
Project Brief Approve (R) A A A (P) R A19

Initiation Stage Plan Approve A A A (P) R A16


138 | Directing a Project

Approve Project Initiation


Request to Authorize
deliver a project Documentation
the project

Approve Benefits Review


Lessons Log Plan

Project
authorization
Project Initiation notification
Documentation

Premature
close

Benefits Review
Plan

Figure 13.3 Authorize the project: activity summary

PRINCE2 recommends the following actions: Project Board authority (for example, to a
Change Authority)
Review and approve the Project Initiation
Documentation: Ensure that the project controls are
adequate for the nature of the project
Confirm that the project definition is
accurate and complete and that the project Confirm the validity and achievability of the
approach is achievable Project Plan (including any key milestones and
proposed stage structure), and approve it
Confirm that lessons from previous
similar projects have been reviewed and Review and approve the Product
incorporated Description(s)
Confirm that the Quality Management
Review the tolerances for the project provided
Strategy is sufficient to ensure that the by corporate or programme management to
quality expectations will be met, and ensure they are appropriate and realistic
approve it Obtain or commit the resources needed by
Confirm that the procedures defined in the
the project (these will be released to the
Risk Management Strategy are sufficient to Project Manager on a stage-by-stage basis)
keep the risks under control, and approve Confirm the proposals to tailor the corporate
it. Confirm that there has been a review of (or programme) project management
the risks, and that risk responses for both method and any tailoring of PRINCE2
threats and opportunities are appropriate Verify that the Business Case demonstrates a
and planned viable project, and approve it
Confirm that the Configuration Review and approve the Benefits Review
Management Strategy will adequately Plan. Confirm it addresses all the expected
control the status (versions and variants) of benefits and meets the needs of corporate or
the projects products, and approve it programme management
Ensure that the stakeholder information Notify corporate or programme management
needs and timing of communications, as and other interested parties that the project
defined in the Communication Management has been authorized
Strategy, are adequate, and approve it Authorize the Project Manager to deliver the
Confirm that all members of the project project or instruct the Project Manager to close
management team have agreed their roles the project prematurely if it is decided not to
and agree any delegations of, and limits to, proceed.
Directing a Project | 139

Table 13.2 Authorize the project: responsibilities


Producer responsible for products production
Reviewer ideally independent of production

Product Description available


Approver confirms approval

Corporate/Programme

Project Assurance
Project Manager

Project Support
Team Manager
Senior Supplier
Senior User
Executive
Product Action
Lessons Log Review R R R (P) R A14

Project Initiation Documentation Approve R A A A (P) R A20

Benefits Review Plan Approve A A A A (P) R A1

Table 13.2 shows the responsibilities for this PRINCE2 recommends the following actions:
activity.
Review and approve the End Stage Report:
Ascertain the performance of the project to
13.4.3Authorize a Stage or Exception
date, asking the Project Manager to explain
Plan any deviations from the approved plans and
It is important that a stage starts only when the to provide a forecast of project performance
Project Board says it should. The Project Board for the remainder of the project
authorizes a management stage by reviewing the If required, review the Lessons Report
performance of the current stage and approving and agree who should receive it. Ensure
the Stage Plan for the next stage. Approval of that the appropriate groups (for example,
Stage Plans occurs at the end of every management corporate or programme management, or
stage except the last one. a centre of excellence) have been made
If an exception has occurred during the stage, aware of their responsibility for taking any
the Project Board may request that the Project recommendations forward
Manager produces an Exception Plan for Project Check the risk summary to ensure the
Board approval. Only exceptions to Stage Plans or exposure is still acceptable and that risk
Project Plans need to be escalated for approval. responses for both opportunities and threats
Deviations from the Project Plan may need are appropriate and planned
corporate or programme management approval. If there has been a phased handover of
Work Package exceptions are managed by the products during the stage:
Project Manager using the Controlling a Stage Verify that the product handover was
process (see Chapter 15). If approved, the Exception in accordance with the Configuration
Plan will replace the plan that is in exception and Management Strategy and, in particular,
will become the new baselined plan. that user acceptance, and operational
The Project Board may appoint Project Assurance and maintenance acceptance, exist for
to undertake some of the reviewing and assessing each product
actions (e.g. inspecting the Stage Plan to confirm it Ensure that, where appropriate, the
is viable). resulting changes in the business are
supported and sustainable
Figure 13.4 shows the inputs to, and outputs from,
this activity.
140 | Directing a Project

(If updated)
Authorize a Stage or Approve
Request to approve Project Initiation
Exception Plan Exception Plan Documentation

Request to approve
next Stage Plan Approve End Stage Report
(current stage)

End Stage Report


(current stage)
Approve Lessons Report
(if required)

Lessons Report
(if required)
Approve Follow-on action
recommendations
(if required)
Follow-on action
recommendations
(if required) Approve Stage Plan
(next stage)

Stage Plan
(next stage)
Approve (If updated)
Benefits Review Plan

Exception Plan Stage


authorization

Benefits Review Plan Premature


close

Exception Plan
Project Initiation authorization
Documentation

Figure 13.4 Authorize a Stage or Exception Plan: activity summary

Confirm who should receive which Confirm the strategies and project
follow-on action recommendation, if controls in the (updated) Project Initiation
any, as summarized in the End Stage Documentation are adequate for the
Report (in some instances it may remainder of the project
be necessary to review the detailed Verify that the (updated) Business Case
recommendation for some of the follow- continues to demonstrate a viable project
on action recommendations). Ensure that Review and approve the (updated) Benefits
the appropriate groups (for example, Review Plan to ensure that any benefits
operations or maintenance) have been planned to be achieved within the next
made aware of their responsibility for stage will be measured and reviewed
taking any recommendations forward
Make a decision:
Review the Stage Plan or Exception Plan for
Approve the plan(s) and authorize the
which the Project Manager is seeking approval: Project Manager to proceed with the
Confirm the validity and achievability of the submitted plan(s):
Stage Plan/Exception Plan Obtain or commit the resources needed
Review and approve any new Product by the plan(s)
Description(s) Set tolerances for the plan being approved
Confirm the validity and achievability of the (for the final stage, the Project Board
Project Plan. If necessary, secure appropriate should consider whether any residual
approvals from corporate or programme tolerances from the previous stages could
management be assigned to the plan or whether they
are better held back in reserve)
Directing a Project | 141

Or ask the Project Manager to revise the variety of circumstances that might prompt ad hoc
rejected plan, giving guidance about the direction, including:
changes required to make it acceptable
Responding to requests (e.g. when options
Or instruct the Project Manager to initiate need clarifying or where areas of conflict need
premature closure of the project resolving)
Communicate the status of the project to Responding to reports (e.g. Highlight Report,
corporate or programme management and Exception Report, Issue Report)
keep other interested parties informed about Responding to external influences (e.g. changes
project progress (in accordance with the in corporate priorities)
Communication Management Strategy). Project Board members individual concerns
Table 13.3 shows the responsibilities for this Responding to changes in Project Board
activity. composition (which may also require corporate
or programme approval).
13.4.4 Give ad hoc direction It is also possible that corporate or programme
Project Board members may offer informal management revises the project mandate in
guidance or respond to requests for advice at any response to events external to the project, or
time during a project. The need for consultation instructs the Project Board to close the project.
between the Project Manager and Project Board The Project Board has two primary options should
is likely to be particularly frequent during the corporate or programme management decide to
initiation stage and when approaching stage change the project mandate:
boundaries.
Treat it as a request for change (see Chapter
Ad hoc direction may be given collectively or by 9) asking the Project Manager to replan the
individual Project Board members. There are a stage and/or project

Table 13.3 Authorize a Stage or Exception Plan: responsibilities


Producer responsible for products production
Reviewer ideally independent of production

Product Description available


Approver confirms approval
Corporate/Programme

Project Assurance
Project Manager

Project Support
Team Manager
Senior Supplier
Senior User
Executive

Product Action
Specialist products Confirm approval A A A (R) (P) (R)
End Stage Report Approve A A A (P) R A9

Lessons Report Distribute A R R (P) R A15

Follow-on action recommendations Distribute A A A (P) R

Stage Plan for the next stage Approve A A A (P) R A16

Exception Plan Approve A A A (P) R A16


(Updated) Project Initiation Documentation Approve (R) A A A (P) R A20

(Updated) Benefits Review Plan Approve A A R R (P) R A1


142 | Directing a Project

Project Manager Give ad hoc Project Board


request for advice direction request for advice

Exception Project Board


raised advice

Exception Plan
Corporate advice request
and decisions

Premature
Highlight Report close

Raise
New
issue
Exception Report

Issue Report

Figure 13.5 Give ad hoc direction: activity summary

Stop, and restart the project by triggering In response to an escalated Issue Report (see
premature closure (see Chapter 18). This may Chapter 9):
result in additional costs compared to the Seek advice from corporate or programme
request-for-change option. management if necessary
The Project Board may appoint Project Assurance Make a decision within the Project Boards
to undertake some of the reviewing and assessing delegated limits of authority. This decision
actions (e.g. inspecting a request for change could be regarding:
to confirm that adequate impact assessment A problem/concern Ask for an Exception
has been undertaken). When making decisions, Plan or provide guidance
it is important to consider the impact on all A request for change Approve, defer,
stakeholders (as identified in the Communication reject or ask for more information.
Management Strategy). Consider whether an Exception Plan is
required
Figure 13.5 shows the inputs to, and outputs from,
An off-specification Grant a concession,
this activity.
defer, reject or ask for more information.
PRINCE2 recommends the following actions: Consider whether an Exception Report is
In response to informal requests for advice and required
guidance: In response to an Exception Report (see
Seek advice from corporate or programme Chapter 10):
management if necessary Seek advice from corporate or programme
Assist the Project Manager as required (this management if necessary
may include asking the Project Manager to Make a decision, within the Project Boards
produce an Issue Report and/or an Exception delegated limits of authority, to:
Report) Increase the tolerances that are forecast
to be breached
Directing a Project | 143

Instruct the Project Manager to produce Ensure that the project management team
an Exception Plan (stating what will be is kept informed of external events that may
acceptable) affect it (for example, advising the Project
Instruct the Project Manager to close the Manager of a change of Project Board
project prematurely personnel)
Defer the exception for a fixed period Notify the Project Manager of any changes
of time. This is a useful response if in the corporate or programme environment
there is low confidence in the forecast that may impact on the project, and ensure
(that tolerances will be exceeded) or appropriate action is taken. This may involve:
if the exception is contingent on a risk Raising an issue to the Project Manager
occurring Instructing the Project Manager to

In response to the receipt of a Highlight Report produce an Exception Plan


(see Chapter 10): Instructing the Project Manager to close

Review the Highlight Report to understand the project prematurely.


the status of the project Table 13.4 shows the responsibilities for this
Ensure that the project remains focused on activity.
the corporate or programme objectives set,
and remains justified in accordance with its 13.4.5 Authorize project closure
Business Case The controlled close of a project is as important as
Ensure that the stage is progressing the controlled start. There must be a point when
according to plan the objectives set out in the original and current
Keep corporate or programme management versions of the Project Initiation Documentation
and other interested parties informed and Project Plan are assessed in order to
about project progress, as defined by the understand:
Communication Management Strategy
Whether the objectives have been achieved
Take actions as necessary. For example, ask
How the project has deviated from its initial
the Project Manager to produce an Issue
basis
Report and/or an Exception Report
That the project has nothing more to
In response to advice and decisions from contribute.
corporate or programme management:

Table 13.4 Give ad hoc direction: responsibilities

Producer responsible for products production


Reviewer ideally independent of production
Product Description available

Approver confirms approval


Corporate/Programme

Project Assurance
Project Manager

Project Support
Team Manager
Senior Supplier
Senior User
Executive

Product Action
Highlight Report Inspect R R R (P) R A11

Exception Report Respond R R R (P) R A10

New issue Raise P P P P


144 | Directing a Project

Closure Approve End Project


Authorize project
recommendation Report
closure

Project Initiation
Documentation Lessons Report

(Updated) Follow-on action


Business Case recommendations

End Project Approve (Updated)


Report Business Case

Lessons Report Approve (If updated)


Benefits Review Plan

Follow-on action
recommendations Closure
notification

Benefits Review Plan

Figure 13.6 Authorize project closure: activity summary

Without this approach, the project may never end; recommendation for some of the follow-on
a project can become business as usual and the actions). Ensure that the appropriate groups
original focus on benefits will be lost. (for example, operations or maintenance)
have been made aware of their responsibility
Authorizing closure of the project is the last activity
for taking any recommended actions
undertaken by the Project Board, prior to its own
forward
disbandment, and may require endorsement from
corporate or programme management. Review the Lessons Report and agree
who should receive it. Ensure that the
The Project Board may appoint Project Assurance appropriate groups (for example, corporate
to undertake some of the reviewing and assessing or programme management, or a centre
actions (e.g. inspecting the End Project Report to of excellence) have been made aware
confirm it is accurate). of their responsibility for taking any
Figure 13.6 shows the inputs to, and outputs from, recommendations forward
this activity. Verify that the handover of the projects
products was in accordance with the
PRINCE2 recommends the following actions:
Configuration Management Strategy and,
Review the original and current versions of the in particular, that user acceptance, and
Project Initiation Documentation to understand operational and maintenance acceptance,
the projects initial baseline, and current exist for each product. Ensure that, where
strategies and controls appropriate, the resulting changes in the
Review and approve the End Project Report to: business are supported and sustainable
Understand the projects actual performance Ensure that the post-project benefits review
against its initial basis, including a summary covers the performance of the projects
of any deviations from the approved plans products in operational use in order to identify
Confirm who should receive which follow- whether there have been any side-effects
on action recommendation as summarized (beneficial or adverse)
in the End Project Report (in some instances
it may be necessary to review the detailed
Directing a Project | 145

Review and gain approval for the updated Review and issue a project closure notification
Benefits Review Plan, ensuring that it addresses in accordance with the Communication
the expected benefits that cannot yet be Management Strategy. The Project Board
confirmed. As the Benefits Review Plan includes advises those who have provided the support
resources beyond the life of the project, infrastructure and resources for the project
responsibility for this plan needs to transfer to that these can now be withdrawn. This should
corporate or programme management indicate a closing date for costs being charged
Confirm the updated Business Case by to the project.
comparing actual and forecast benefits, costs Table 13.5 shows the responsibilities for this
and risks against the original Business Case that activity.
was used to justify the project (it may not be
possible to confirm all the benefits as some will
not be realized until after the project is closed)

Table 13.5 Authorize project closure: responsibilities

Producer responsible for products production


Reviewer ideally independent of production

Product Description available


Approver confirms approval
Corporate/Programme

Project Assurance
Project Manager

Project Support
Team Manager
Senior Supplier
Senior User
Executive

Product Action
End Project Report Approve A A A (P) R A8

Lessons Report Distribute A A A (P) R A15

Follow-on action recommendations Distribute A A A (P) R

(Updated) Business Case Confirm R A R R (P) R A2

(Updated) Benefits Review Plan Approve A A R R (P) R A1


14
Initiating a Project
14Initiating a Project

14.1 Purpose The scope of what is to be done and the


products to be delivered
The purpose of the Initiating a Project process
How and when the projects products will be
is to establish solid foundations for the project,
delivered and at what cost
enabling the organization to understand the work
Who is to be involved in the project decision
that needs to be done to deliver the projects
products before committing to a significant spend. making
How the quality required will be achieved
How baselines will be established and controlled
14.2 Objective
How risks, issues and changes will be identified,
The objective of the Initiating a Project process is to assessed and controlled
ensure that there is a common understanding of: How progress will be monitored and controlled
The reasons for doing the project, the benefits Who needs information, in what format, and at
expected and the associated risks what time

Directing a Project

Authority to
initiate project

Prepare the Prepare the Prepare the


Risk Management Quality Management Configuration Management
Strategy Strategy Strategy

Prepare the
Communication
Management Strategy

Set up the Create the


project controls Project Plan

Refine the
Business Case

Assemble the Request to


Project Initiation deliver a project
Initiating a Project Documentation

Stage boundary Managing a


approaching Stage Boundary

Figure 14.1 Overview of Initiating a Project


150 | Initiating a Project

How the corporate (or programmes) project Prepare the Quality Management Strategy
management method will be tailored to suit Prepare the Communication Management
the project. Strategy
Set up the project controls
14.3 Context Create the Project Plan
Refine the Business Case
Initiating a Project is aimed at laying down the
foundations in order to achieve a successful Assemble the Project Initiation
project. Specifically, all parties must be clear on Documentation.
what the project is intended to achieve, why it is The activities to establish the strategies for
needed, how the outcome is to be achieved and the project may be executed in parallel, but
what their responsibilities are, so that there can be it is recommended that the Communications
genuine commitment to it. Management Strategy is completed last as it will
The Initiating a Project process allows the Project need to include any communications required of
Board, via Directing a Project (see Chapter 13), to the other strategies.
decide whether or not the project is sufficiently The strategies are derived from the corporate or
aligned with corporate or programme objectives to programme management strategies, standards or
authorize its continuation. practices that the project needs to comply with,
If, instead, the organization proceeds directly and the customers quality expectations captured in
from Starting up a Project (see Chapter 12) to the Project Product Description. Once the strategies
Controlling a Stage (see Chapter 15), then it may have been defined, it is possible to set up the
be forced to commit significant financial resources project controls and create the Project Plan. These
to a project without fully understanding how are parallel and iterative activities as:
its objectives will be achieved. Without a firm Each control will need time and resources to
definition, the Project Board will be taking a leap operate, which will need to be documented in
of faith. the Project Plan
All activities within the Initiating a Project process There may be additional controls required as
need further consideration if the relationship products and activities are identified in the
between the customer and the supplier is a Project Plan.
commercial one (for example, the reasons for Once the controls have been established and a
undertaking the project as defined in the suppliers Project Plan created, it is then possible to complete
Business Case may be different from those defined the Business Case because forecast time and
in the customers Business Case) see Chapter 19 costs of developing the projects products, and
for more details. managing the project, are now fully understood.
During the Initiating a Project process the Project The final activity in the Initiating a Project
Manager will be creating the suite of management process is to assemble the Project Initiation
products required for the level of control specified Documentation. This is a compilation of all the
by the Project Board. The Project Manager should documentation developed during initiation that
have agreed (as part of the Initiation Stage Plan) will be used to gain Project Board approval to
the means by which the Project Board will review proceed.
and approve the management products the two
extremes are one at a time or all at once. 14.4.1Prepare the Risk Management
Strategy
14.4 Activities The Risk Management Strategy describes the goals
The activities within the Initiating a Project process of applying risk management, the procedure that
are Project-Manager-oriented and are to: will be adopted, the roles and responsibilities, the
risk tolerances, the timing of risk management
Prepare the Risk Management Strategy activities, the tools and techniques that will be
Prepare the Configuration Management used, and the reporting requirements.
Strategy
Initiating a Project | 151

Prepare the (Part of)


Authority to Risk Management Project Initiation
initiate a project Strategy Documentation

Create Risk Management


Project Brief Strategy

Create
Risk Register
Lessons Log

Daily Log

Figure 14.2 Prepare the Risk Management Strategy: activity summary

For more details on risk management, see Chapter 8. Define the Risk Management Strategy,
including:
Figure 14.2 shows the inputs to, and outputs from,
this activity. The risk management procedure (e.g.
Identify, Assess, Plan, Implement,
PRINCE2 recommends the following actions: Communicate)
Review the Project Brief to understand whether Tools and techniques that will be used
any corporate or programme management Records that will be kept
strategies, standards or practices relating to risk How the performance of the risk
management need to be applied by the project management procedure will be reported
Seek lessons from similar previous projects, Timing of risk management activities
corporate or programme management, The roles and responsibilities for risk
and external organizations related to risk management activities
management. Some of these may already have The scales to be used for estimating
been captured in the Lessons Log probability and impact
Review the Daily Log for any issues and risks
Guidance on how proximity for risks will be
related to risk management assessed
Table 14.1 Prepare the Risk Management Strategy: responsibilities

Producer responsible for products production


Reviewer ideally independent of production
Product Description available

Approver confirms approval


Corporate/Programme

Project Assurance
Project Manager

Project Support
Team Manager
Senior Supplier
Senior User
Executive

Product Action
Risk Management Strategy Create (A) (A) (A) P R A24

Risk Register Create and populate A R P A25


152 | Initiating a Project

Definition of risk categories to be used replaced or modified. However, the level of control
Any early-warning indicators to be used exercised will be influenced by the importance of
Tolerances relating to risk the project and the complexity of the relationship
Whether a risk budget will be established between its products.
and, if so, how it will be controlled. The initial set of Configuration Item Records will
Consult with Project Assurance to check that be created during this activity. The Configuration
the proposed Risk Management Strategy meets Management Strategy will define the format
the needs of the Project Board and/or corporate and composition of the records that need to be
or programme management maintained (see Appendix A).
Create the Risk Register in accordance with the For more details on configuration management,
Risk Management Strategy, and populate it see Chapter 9.
with any risks from the Daily Log
Figure 14.3 shows the inputs to, and outputs from,
Seek Project Board approval for the Risk
this activity.
Management Strategy (although the Project
Board may prefer to review it later as part of PRINCE2 recommends the following actions:
the Project Initiation Documentation). Review the Project Brief to understand whether
Table 14.1 shows the responsibilities for this any corporate or programme management
activity. strategies, standards or practices relating
to configuration management need to be
14.4.2Prepare the Configuration applied (in particular whether the customer
and/or supplier has an existing configuration
Management Strategy
management system that should be applied)
Configuration management is essential for the
Seek lessons from similar previous projects,
project to maintain control over its management
corporate or programme management, and
and specialist products.
external organizations related to configuration
The level of control required will vary from project management. Some of these may already have
to project. The maximum level of control possible been captured in the Lessons Log.
is determined by breaking down the projects Review the Risk Register and Daily Log for
products until the level is reached at which a risks and issues associated with configuration
component can be independently installed, management

Prepare the (Part of)


Authority to Configuration Management Project Initiation
initiate a project Strategy Documentation

Create Configuration
Project Brief Management
Strategy

Update Project management


Lessons Log team structure

Update Role
descriptions
Risk Register

Create Configuration Item


Records
Daily Log

Create
Issue Register

Figure 14.3 Prepare the Configuration Management Strategy: activity summary


Initiating a Project | 153

Define the Configuration Management Create the Issue Register and consider whether
Strategy, including: any issues already captured in the Daily Log
The configuration management procedure need to be managed formally and therefore
(e.g. planning, identification, control, status transferred
accounting, verification and audit) If any new risks or issues are identified (or
The issue and change control procedure (e.g. existing ones have changed), then update the
capturing, examining, proposing, deciding, Risk Register, Issue Register and/or Daily Log
implementing) Seek Project Board approval for the
Tools and techniques that will be used Configuration Management Strategy (the
Records that will be kept Project Board may prefer to review it later as
How the performance of the procedures will
part of the Project Initiation Documentation).
be reported Table 14.2 shows the responsibilities for this
Timing of configuration management activity.
activities and issue and change control
activities 14.4.3Prepare the Quality Management
The roles and responsibilities for the Strategy
procedures. Consider whether a Change A key success factor of any project is that it delivers
Authority and/or change budget should be what the user expects and finds acceptable. This
established will only happen if these expectations are both
The scales for priority and severity of issues stated and agreed at the beginning of the project,
Consult with Project Assurance to check that together with the standards to be used and the
the proposed Configuration Management means of assessing their achievement. The purpose
Strategy meets the needs of the Project Board of the Quality Management Strategy is to ensure
and/or corporate or programme management such agreements are captured and maintained.
Create the initial Configuration Item Records For more details on quality management, see
(at this point there will only be Configuration Chapter 6.
Item Records for the management products
Figure 14.4 shows the inputs to, and outputs from,
that have already been created and any pre-
this activity.
existing project documentation that needs to
be controlled, e.g. feasibility study, request for
proposal etc.)

Table 14.2 Prepare the Configuration Management Strategy: responsibilities


Producer responsible for products production
Reviewer ideally independent of production
Product Description available

Approver confirms approval


Corporate/Programme

Project Assurance
Project Manager

Project Support
Team Manager
Senior Supplier
Senior User
Executive

Product Action
Configuration Management Strategy Create (A) (A) (A) P R A6

(Initial) Configuration Item Records Create A R P A5

Issue Register Create and populate A R P A12


154 | Initiating a Project

Prepare the (Part of)


Authority to Quality Management Project Initiation
initiate a project Strategy Documentation

Create Quality
Project Brief Management
Strategy

Create
Quality Register
Project Product
Description

Lessons Log

Risk Register

Issue Register

Figure 14.4 Prepare the Quality Management Strategy: activity summary

PRINCE2 recommends the following actions: system that should be applied to aspects of the
project)
Review the Project Product Description to
Seek lessons from similar previous projects,
understand the customers quality expectations
and to check that the projects acceptance corporate or programme management, and
criteria are sufficiently defined external organizations related to quality
management. Some of these may already have
Review the Project Brief to understand whether
been captured in the Lessons Log
any corporate or programme management
Review the Risk Register and Issue Register
strategies, standards or practices relating to
quality management need to be applied by the for issues and risks associated with quality
project (in particular whether the customer and/ management
or supplier has an existing quality management

Table 14.3 Prepare the Quality Management Strategy: responsibilities

Producer responsible for products production


Reviewer ideally independent of production
Product Description available

Approver confirms approval


Corporate/Programme

Project Assurance
Project Manager

Project Support
Team Manager
Senior Supplier
Senior User
Executive

Product Action
Quality Management Strategy Create (A) (A) (A) P R A22

Quality Register Create A R P A23


Initiating a Project | 155

Define the Quality Management Strategy, If any new risks or issues are identified (or
including: existing ones have changed), then update the
The quality management procedure (e.g. Risk Register, Issue Register and/or Daily Log
quality planning, quality control, quality Seek Project Board approval for the Quality
assurance) Management Strategy (although the Project
Tools and techniques that will be used Board may prefer to review it later as part of
Records that will be kept the Project Initiation Documentation).
How the performance of the quality Table 14.3 shows the responsibilities for this
management procedure will be reported activity.
Timing of quality management activities
The roles and responsibilities for quality 14.4.4Prepare the Communication
management activities (check links to any Management Strategy
corporate or programme quality assurance The Communication Management Strategy
function and ensure that all project quality addresses both internal and external
activities support, and are supported by, this communications. It should contain details of
function) how the project management team will send
Consult with Project Assurance to check that information to, and receive information from, the
the proposed Quality Management Strategy wider organization(s) involved with, or affected by,
meets the needs of the Project Board and/or the project. In particular, where the project is part
corporate or programme management of a programme, details should be given on how
Create a Quality Register in readiness to record information is to be fed to the programme.
details of all quality activities

Prepare the (Part of)


Project Brief Communication Project Initiation
Documentation
Management Strategy

Create Communication
Lessons Log Management
Strategy

Risk Register

Issue Register

(Part of)
Project Initiation
Documentation

Risk Management
Strategy

Quality Management
Strategy

Configuration
Management
Strategy

Figure 14.5 Prepare the Communication Management Strategy: activity summary


156 | Initiating a Project

If a formal stakeholder engagement procedure Establish the information needs associated with
is needed (such as that described in Chapter5), the Quality Management Strategy, the Risk
this should also be documented as part of the Management Strategy and the Configuration
Communication Management Strategy and Management Strategy
should record the types of stakeholder, desired Define the Communication Management
relationships and key messages, strategies for Strategy, including:
communication, and methods for evaluating the The communication management procedure
success of communications. Tools and techniques that will be used
Figure 14.5 shows the inputs to, and outputs from, Records that will be kept
this activity. How the performance of the communication
management procedure will be reported
PRINCE2 recommends the following actions:
Timing of communication activities
Review the Project Brief to understand whether
The roles and responsibilities for
any corporate or programme management communication activities
strategies, standards or practices relating
Stakeholder analysis
to communication management need to be
Consult with Project Assurance to check that
applied by the project
the proposed Communication Management
Seek lessons from similar previous projects,
Strategy meets the needs of the Project Board
corporate or programme management,
and/or corporate or programme management
and external organizations related to
If any new risks or issues are identified (or
communication management. Some may
already have been captured in the Lessons Log existing ones have changed), then update the
Risk Register, Issue Register and/or Daily Log
Review the Risk Register and Issue Register for
Seek Project Board approval for the
risks and issues associated with communication
Communication Management Strategy (although
management
the Project Board may prefer to review it later as
Identify and/or review stakeholders, and consult
part of the Project Initiation Documentation).
them for their information needs:
Identify desired relationships
Table 14.4 shows the responsibilities for this activity.
Clarify key communication messages 14.4.5Set up the project controls
Determine desired outcomes from successful The level of control required by the Project
communications Board after initiation needs to be agreed and

Table 14.4 Prepare the Communication Management Strategy: responsibilities

Producer responsible for products production


Reviewer ideally independent of production
Product Description available

Approver confirms approval


Corporate/Programme

Project Assurance
Project Manager

Project Support
Team Manager
Senior Supplier
Senior User
Executive

Product Action
Communication Management
Create (A) (A) (A) P R A4
Strategy
Initiating a Project | 157

the mechanism for such controls needs to be Mechanisms to capture and analyse issues and
established as does the level of control required changes (see Chapter 9)
by the Project Manager of the work to be Mechanisms to escalate exceptions (see
undertaken by Team Managers. Chapter 10)
Project controls enable the project to be managed Tolerances for delegated authority (see
in an effective and efficient manner that is Chapter 10)
consistent with the scale, risks, complexity and How delegated authority from one level of
importance of the project. Effective project management to another will be monitored (see
controls are a prerequisite for managing by Chapter 10).
exception.
Many of these controls will have been defined
Project controls can include: in the projects strategies but not necessarily set
The frequency and format of communication up. The focus of this activity is to establish such
between the project management levels (see controls and to make sure that they make sense as
Chapter 5) a coherent set.
The number of stages and hence end stage Figure 14.6 shows the inputs to, and outputs from,
assessments (see Chapter 7) this activity.

(Part of)
Lessons Log Set up the Project Initiation
project controls Documentation

Create Project
Project Brief controls

Update Role
(Part of)
Project Initiation descriptions
Documentation

Update Project management


Quality Management team structure
Strategy

Configuration
Management
Strategy

Risk Management
Strategy

Communication
Management
Strategy

Project Plan

Risk Register

Issue Register

Figure 14.6 Set up the project controls: activity summary


158 | Initiating a Project

PRINCE2 recommends the following actions: management system or other standard


procedures
Review the Project Brief to understand whether
any corporate or programme management Incorporate the agreed decision-making
strategies, standards or practices relating to authority and responsibility into the project
controls need to be applied by the project. management team structure and role
Identify whether any of these require PRINCE2 descriptions where appropriate; this may
to be tailored include finalizing any roles not previously
allocated, re-allocating roles previously filled
Review the Quality Management Strategy,
and, if necessary, re-designing the project
Configuration Management Strategy, Risk
management team
Management Strategy and Communication
Management Strategy to identify which Confirm the tolerances for the project and the
controls need to be established escalation procedures (from Team Managers to
Project Manager, Project Manager to Project
Seek lessons from similar previous projects,
Board, and Project Board to corporate or
corporate or programme management, and
programme management)
external organizations related to project
controls. Some of these may already have been Summarize the project controls in the Project
captured in the Lessons Log Initiation Documentation
Review the Risk Register and Issue Register for Consult with Project Assurance to check that
risks and issues associated with project controls. the proposed project controls are consistent
The aggregated set of risks will have an impact with the nature of the project and meet the
on the scale and rigour of control activities needs of the Project Board and/or corporate or
programme management
Confirm and document the management stage
boundaries required to provide the appropriate If any new risks or issues are identified (or
level of control existing ones have changed), then update the
Risk Register, Issue Register and/or Daily Log
Allocate the various levels of decision making
required within the project to the most Seek Project Board approval for the project
appropriate project management level. controls (the Project Board may prefer to review
Establish any decision-making procedures them later as part of the Project Initiation
that may be appropriate, possibly by tailoring Documentation).
procedures within an existing quality Table 14.5 shows the responsibilities for this
activity.
Table 14.5Set up the project controls: responsibilities

Producer responsible for products production


Reviewer ideally independent of production
Product Description available

Approver confirms approval


Corporate/Programme

Project Assurance
Project Manager

Project Support
Team Manager
Senior Supplier
Senior User
Executive

Product Action
Project controls Create (A) (A) (A) P R

Role descriptions Update (A) (A) (A) P R

Project management team structure Update (A) (A) (A) P


Initiating a Project | 159

14.4.6Create the Project Plan the user(s) and supplier(s). It is often useful to
Before committing to major expenditure on the hold planning workshops to help identify all
project, the timescale and resource requirements the products required, their details, and the
must be established. This information is held in the dependencies between them.
Project Plan and is needed so that the Business Case For more details on planning, see Chapter 7.
can be refined and the Project Board can control
Figure 14.7 shows the inputs to, and outputs from,
the project.
this activity.
Planning is not an activity that the Project Manager
performs in isolation but, rather, something
that should be done with close involvement of

(Part of)
Lessons Log Create the Project Initiation
Project Plan Documentation

Create Project
Risk Register Plan

Update Project
management
Issue Register team structure

Update Role
Project Brief descriptions

Update Configuration
Project approach Item Records

Project
Product Description

(Part of)
Project Initiation
Documentation

Quality Management
Strategy

Configuration
Management
Strategy

Risk
Management
Strategy

Communication
Management
Strategy

Project controls

Figure 14.7 Create the Project Plan: activity summary


160 | Initiating a Project

PRINCE2 recommends the following actions: the Product Description for a Plan in Appendix
A for more information
Review the Project Brief to:
Identify any planning and control tools to be
Understand what the project is to deliver
used by the project
and check for any predetermined milestones
as defined in the Project Brief Choose the method(s) of estimating for the
projects plans
Check whether there are any corporate
or programme management strategies, Review the Quality Management Strategy,
standards or practices relating to planning Risk Management Strategy, Configuration
that the project needs to follow Management Strategy and Communication
Management Strategy to understand the
Check understanding of any prerequisites,
resources, standards, methods and costs for the
external dependencies, constraints and
work to be carried out
assumptions documented in the Project Brief
Create a product breakdown structure,
Check understanding of the selected solution
product flow diagram and Product Descriptions
as described by the project approach
for the major products in the Project Plan.
Seek lessons from similar previous projects, Identify the arrangements for the transition
corporate or programme management, and of the projects products into operational
external organizations related to planning. use. Where the projects products are likely
Some of these may already have been captured to require potentially expensive maintenance
in the Lessons Log once operational, plan for a suitable service
Review the Risk Register and Issue Register for agreement or contract to be drawn up between
risks and issues associated with planning the support group and the user. In such
Decide on the format and presentation of instances, it will be necessary to include any
the Project Plan, given the audience for the agreement as a product in the Project Plan
plan and how it will be used (for example, Consider whether the Project Product
is it sufficient to use a product checklist for Description needs to be updated (for example,
presenting the plan to the Project Board?). See if the understanding of the acceptance criteria

Table 14.6Create the Project Plan: responsibilities

Producer responsible for products production


Reviewer ideally independent of production

Product Description available


Approver confirms approval
Corporate/Programme

Project Assurance
Project Manager

Project Support
Team Manager
Senior Supplier
Senior User
Executive

Product Action
Project Plan Create (A) (A) (A) P R A16

Product Descriptions Create (A) (A) (A) P R A17

Configuration Item Records Create/update A R P A5

Project management team structure Update (A) (A) (A) P R

Role descriptions Update (A) (A) (A) P R


Initiating a Project | 161

Refine the Create Benefits


Project Brief Review Plan
Business Case

(Part of)
(Outline) Project Initiation
Business Case Documentation

Create
(Part of) (Detailed)
Project Initiation Business Case
Documentation

Project Plan

Risk Register

Figure 14.8 Refine the Business Case: activity summary

has changed or been refined in the course of Project Plan, and the aggregated risks from the
initiating the project) updated Risk Register.
Create or update the Configuration Item The detailed Business Case will be used by the
Records for each product to be delivered by the Project Board to authorize the project and provides
plan the basis of the ongoing check that the project
Identify and confirm resources required. remains viable.
Confirm the selected peoples availability, their
acceptance of these roles and their commitment For more details on business justification, see
to carry them out. See Chapter 5 for more Chapter 4.
details Figure 14.8 shows the inputs to, and outputs from,
Identify the activities, resources and timings for this activity.
the project controls and include them in the
PRINCE2 recommends the following actions:
plan
Identify risks associated with the plan Review the Project Brief to check whether there
Document the Project Plan are any corporate or programme management
requirements for the format and content of the
Consult with Project Assurance to check that
Business Case
the proposed Project Plan meets the needs
Seek lessons from similar previous projects,
of the Project Board and/or corporate or
programme management corporate or programme management, and
external organizations related to Business Case
If any new risks or issues are identified (or
development. Some of these may already have
existing ones have changed), then update the
been captured in the Lessons Log
Risk Register, Issue Register and/or Daily Log
Create the detailed Business Case with the
Seek Project Board approval for the Project
additional detail gained, namely:
Plan (although the Project Board may prefer to
The costs and timescale as calculated in the
review it later as part of the Project Initiation
Documentation). Project Plan
The major risks that affect the viability and
Table 14.6 shows the responsibilities for this activity. achievability of the project (from the Risk
Register)
14.4.7Refine the Business Case The benefits to be gained
The outline Business Case produced during Starting The tolerances allowed for each of the
up a Project needs to be updated to reflect the benefits
estimated time and costs, as determined by the
162 | Initiating a Project

Table 14.7Refine the Business Case: responsibilities

Producer responsible for products production


Reviewer ideally independent of production

Product Description available


Approver confirms approval

Corporate/Programme

Project Assurance
Project Manager

Project Support
Team Manager
Senior Supplier
Senior User
Executive
Product Action
Benefits Review Plan Create (A) (A) (A) (A) P R A1

Detailed Business Case Create (R) (A) (A) (A) P R A2

Create the Benefits Review Plan: 14.4.8Assemble the Project Initiation


Review the Business Case and check Documentation
understanding of the benefits expected of There needs to be a focal point at which all
the project information relating to the what, why, who, how,
Identify how the achievement of each where, when, and how much of the project is:
benefit is to be measured and capture the
current baseline measures Gathered for agreement by the key
stakeholders
Identify the timing of benefits reviews (most
likely to align to stage boundaries) Available for guidance and information for
those involved in the project.
If the project is part of a programme,the
Benefits Review Plan may be created, This information is collated into the Project
maintained and executed at the programme Initiation Documentation. The Project Initiation
level Documentation is an aggregation of many of the
If any new risks or issues are identified (or
management products created during initiation
and used to gain authorization for the project to
existing ones have changed), then update the
proceed. It is not necessarily (and rarely) a single
Risk Register, Issue Register and/or Daily Log
document, but a collection of documents.
Consult with Project Assurance to check that
the proposed Business Case and Benefits Review The version of the Project Initiation Documentation
Plan meet the needs of the Project Board and/ created during the Initiating a Project process,
or corporate or programme management and used to gain authorization for the project
Seek Project Board approval for the Business to proceed, should be preserved. It will be used
Case and Benefits Review Plan (although the later as a means to compare the projects actual
Project Board may prefer to review them later performance against the original forecasts that
as part of the Project Initiation Documentation). formed the basis of approval.

Table 14.7 shows the responsibilities for this activity. Figure 14.9 shows the inputs to, and outputs from,
this activity.
Initiating a Project | 163

Assemble the Project Assemble Project Initiation


Project Brief
Initiation Documentation Documentation

Request to
Project definition
deliver a project

Stage boundary
approaching
Project approach

(Detailed)
Business Case

Project management
team structure

Role descriptions

Quality Management
Strategy

Configuration
Management Strategy

Risk Management
Strategy

Communication
Management Strategy

Project Plan

Project controls

Tailoring of
PRINCE2

Figure 14.9 Assemble the Project Initiation Documentation: activity summary


164 | Initiating a Project

Table 14.8 Assemble the Project Initiation Documentation: responsibilities

Producer responsible for products production


Reviewer ideally independent of production

Product Description available


Approver confirms approval

Corporate/Programme

Project Assurance
Project Manager

Project Support
Team Manager
Senior Supplier
Senior User
Executive
Product Action
Project Initiation Documentation Assemble (A) (A) (A) P R A20

PRINCE2 recommends the following actions: Include or reference the project controls
and summarize how the project has tailored
Extract and, if necessary, revise information
PRINCE2
from the Project Brief (project definition and
project approach) Assemble the Project Initiation Documentation
Include or reference information in the: Carry out a cross-check of the information in
the various elements to ensure that they are
Projects management team structure and
compatible
role descriptions
Consult with Project Assurance to check that
Business Case
the assembled Project Initiation Documentation
Quality Management Strategy
meets the needs of the Project Board and/or
Configuration Management Strategy
corporate or programme management
Risk Management Strategy
Prepare for the next stage (which triggers the
Communication Management Strategy Managing a Stage Boundary process)
Project Plan Request authority from the Project Board to
deliver the project.
Table 14.8 shows the responsibilities for this
activity.
15
Controlling a Stage
15 Controlling a Stage

15.1 Purpose 15.2 Objective


The purpose of the Controlling a Stage process is The objective of the Controlling a Stage process is
to assign work to be done, monitor such work, deal to ensure that:
with issues, report progress to the Project Board,
Attention is focused on delivery of the stages
and take corrective actions to ensure that the stage
products. Any movement away from the
remains within tolerance.
direction and products agreed at the start of
the stage is monitored to avoid uncontrolled
change (scope creep) and loss of focus
Risks and issues are kept under control

Directing a Project

Exception Plan
approved
Stage Exception Request Project Board
authorization raised for advice advice

Managing a Closing a
Stage Boundary Project

Stage boundary Project end


approaching approaching

Escalate
Controlling issues and risks
Report highlights

a Stage

Take corrective Review the stage


action status

Capture and
examine issues New issue
and risks

Authorize Review Work Receive completed


Work Packages Package status Work Packages

Authority to deliver Completed


Work Package Work Package

Managing Product Delivery

Figure 15.1 Overview of Controlling a Stage


168 | Controlling a Stage

The Business Case is kept under review 15.4 Activities


The agreed products for the stage are delivered
Controlling a Stage activities are Project-Manager-
to stated quality standards, within cost, effort
oriented and comprise:
and time agreed, and ultimately in support of
the achievement of the defined benefits Work Packages:
The project management team is focused on Authorize a Work Package
delivery within the tolerances laid down. Review Work Package status
Receive completed Work Packages
15.3 Context Monitoring and reporting:

The Controlling a Stage process describes the work Review the stage status
of the Project Manager in handling the day-to- Report highlights
day management of the stage. This process will be Issues:
used for each delivery stage of a project. Towards
Capture and examine issues and risks
the end of each stage, except the final one, the
Escalate issues and risks
activities within the Managing a Stage Boundary
process (see Chapter 17) will occur. Take corrective action.

The Controlling a Stage process is normally first 15.4.1 Authorize a Work Package
used after the Project Board authorizes the project,
It would be chaotic to have the people who are
but it may optionally be used during the initiation
working on the project starting activities whenever
stage for large or complex projects with a lengthy
they think fit. There must be a level of autonomy
initiation.
within the project team(s), but there will be wider
Work Packages are used to define and control the issues involved of which they cannot be expected
work to be done, and also to set tolerances for the to be aware. It is therefore important that work
Team Manager(s). In the case where the Project only commences and continues with the consent
Manager is fulfilling the Team Manager role, Work of the Project Manager. The vehicle for this is the
Packages should still be used to define and control production, execution and delivery of a Work
the work of the individual team members being Package.
assigned work. Where this is the case, references to
A Work Package may include extracts from,
Team Manager throughout the Controlling a Stage
or simply cross-reference elements of, the
process should be regarded as references to the
Project Plan, Stage Plan or Project Initiation
individual team member being assigned work.
Documentation.
Central to the ultimate success of the project is
A Work Package should cover the work to create
the day-to-day control of the work that is being
one or more products. If a product requires more
conducted. Throughout a stage, this will consist of
than one Work Package to create it, then it should
a cycle of:
be broken down into further products with their
Authorizing work to be done supporting Product Descriptions.
Monitoring progress information about that The triggers for the Project Manager to authorize a
work, including signing off completed Work Work Package include:
Packages
Stage authorization the Project Board gives
Reviewing the situation (including that for
product quality) and triggering new Work authority to execute a Stage Plan
Packages Exception Plan approved the Project Board
Reporting highlights gives authority to execute an Exception Plan
New Work Package required an output from
Watching for, assessing and dealing with issues
and risks reviewing the stage status (see section 15.4.4)
Corrective action in response to an issue
Taking any necessary corrective action.
or risk.
Towards the end of the last stage, the Closing a
Project process (see Chapter 18) will be invoked.
Controlling a Stage | 169

Authorize a Update Stage Plan


Stage Plan
Work Package (current stage)

Create
Product Descriptions Work Package(s)

(Part of) Update Configuration


Project Initiation Item Records
Documentation

Update
Quality Register
Project controls

Update
Quality Management Risk Register
Strategy

Update
Configuration Issue Register
Management Strategy

Authority to deliver
Team Plan a Work Package

Corrective action

New Work
Package

Stage
authorization

Exception Plan
approved

Figure 15.2 Authorize a Work Package: activity summary

This activity is used to authorize new Work The project controls required (for example,
Packages or to authorize amendments to existing progress reporting arrangements)
ones. The quality standards required, as defined in
Figure 15.2 shows the inputs to, and outputs from, the Quality Management Strategy
this activity. If any products are to be handed over,
how this will be done (as defined in the
PRINCE2 recommends the following actions: Configuration Management Strategy)
Examine the Stage Plan for the current Define each Work Package to be authorized (or
management stage in order to understand the: amended):
Products to be produced
Obtain the relevant Product Descriptions for
Cost and effort that the work is expected to inclusion in the Work Package
consume Define the techniques, processes and
Tolerances available procedures to be used
Examine the Project Initiation Documentation Define the development interfaces to be
in order to understand: maintained
170 | Controlling a Stage

Define the operational and maintenance the Stage Plan to reflect the timing of the Work
interfaces to be maintained Package(s) authorized
Define the configuration management Update the Configuration Item Records to
requirements reflect the content of the Work Package(s)
Define the joint agreements on effort, cost, authorized
start and end dates, key milestones and Update the Quality Register for planned quality
tolerances management activities. Consult with Project
Define any constraints that may apply Assurance that the identified and selected
Define the reporting, problem handling and quality reviewers are acceptable
escalation arrangements If necessary, update the Risk Register in
Define the approval method accordance with the Risk Management Strategy
Provide relevant references (e.g. Stage Plan, If necessary, update the Issue Register.
Product Descriptions) Table 15.1 shows the responsibilities for this
Review the Work Package with the Team activity.
Manager, ensure that they have accepted
it,and authorize them to begin work (see 15.4.2Review Work Package status
Chapter 16) This activity provides the means for a regular
Review the Team Managers Team Plan (or the assessment of the status of the Work Package(s).
milestone extract from it if the commercial The frequency and formality of this activity will
environment means it is inappropriate for the usually be aligned with the frequency of reporting
Project Manager to see its contents) and update defined in the Work Package(s) and supported by
the Stage Plan for the current stage.

Table 15.1 Authorize a Work Package: responsibilities

Producer responsible for products production


Reviewer ideally independent of production

Product Description available


Approver confirms approval
Corporate/Programme

Project Assurance
Project Manager

Project Support
Team Manager
Senior Supplier
Senior User
Executive

Product Action
Work Package Create P (A) R A26
Configuration Item Record(s) Create/update A (R) R P A5
Quality Register Update R (R) R P A23
Risk Register Update P A25
Issue Register Update P A12
Team Plan Review R (P)

Stage Plan Update P (R) R A16


Controlling a Stage | 171

Review Work Update


Stage Plan Stage Plan
Package status

Update Configuration
Work Package(s) Item Records

Update
Risk Register
Checkpoint Report(s)

Update
Issue Register
Quality Register

Update
Work Package
Team Plan(s)

Risk Register

Figure 15.3 Review Work Package status: activity summary

Table 15.2Review Work Package status: responsibilities


Producer responsible for products production
Reviewer ideally independent of production

Product Description available


Approver confirms approval
Corporate/Programme

Project Assurance
Project Manager

Project Support
Team Manager
Senior Supplier
Senior User
Executive

Product Action
Checkpoint Report Review R (P) A3

Team Plan Review R (P)

Stage Plan Update P R A16

Configuration Item Record(s) Update A (R) R P A5

Risk Register Update P A25

Issue Register Update P A12


172 | Controlling a Stage

Figure 15.3 shows the inputs to, and outputs from, 15.4.3Receive completed Work Packages
this activity. Where work has been allocated to individuals or
PRINCE2 recommends the following actions for teams, there should be a matching confirmation
each Work Package in progress: that the work has been completed and approved.
Collect and review progress information from Once approved, any subsequent changes to the
the Checkpoint Report for the Work Package product(s) must pass through change control (see
being executed: Chapter 9). This should be an automatic part of any
Assess the estimated time and effort to configuration management method being used.
complete any unfinished work (including Figure 15.4 shows the inputs to, and outputs from,
that not yet started) this activity.
Review the Team Plan with the Team
PRINCE2 recommends the following actions:
Manager (or the milestone extract from it
if the commercial environment means it is Ensure that the Team Manager has completed
inappropriate for the Project Manager to see the work defined by the Work Package(s)
its contents) to ascertain whether work will Check that the Quality Register entries relating
be completed on time and to budget to the product(s) are complete
Review entries in the Quality Register to Ensure that each product in the Work Package
understand the current status of quality has gained its requisite approval (as defined
management activities in the quality responsibilities in its Product
Confirm that the Configuration Item Record Description)
for each product in the Work Package Confirm that the Configuration Item Record for
matches its status each approved product has been updated
If necessary, update the Risk Register and Issue Update the Stage Plan to show the Work
Register Package as completed.
Update the Stage Plan for the current stage Table 15.3 shows the responsibilities for this
with actuals to date, forecasts and adjustments. activity.
Table 15.2 shows the responsibilities for this
activity.

Completed Receive completed Update Configuration


Work Package Work Packages Item Records

Update
Stage Plan Stage Plan

Quality Register

Configuration
Item Records

Figure 15.4 Receive completed Work Packages: activity summary


Controlling a Stage | 173

Table 15.3Receive completed Work Packages: responsibilities


Producer responsible for products production
Reviewer ideally independent of production

Product Description available


Approver confirms approval

Corporate/Programme

Project Assurance
Project Manager

Project Support
Team Manager
Senior Supplier
Senior User
Executive
Product Action
Configuration Item Record(s) Confirm A (R) R P A5

Stage Plan Update P R A16

15.4.4Review the stage status Request a Product Status Account from


If the project is not checked on a timely basis, there Project Support to identify any variation
is a danger that it will get out of control. There between planned progress, reported
needs to be a balance between planning ahead progress and actual progress
and reacting to events. Check for any quality issues shown in the
Quality Register
In order to make informed decisions and exercise
Check the Risk Register for any new or
rational control, it is necessary to compare what
revised risks and assess their impact on the
has actually happened with what was expected to
Business Case, Stage Plan or the Project Plan
happen and what might happen next (including
Check the Issue Register to see whether
any issues and risks). It is therefore essential to
anything has happened within the project or
have a steady flow of information that provides
externally that will impact on the Business
an overall view of progress and simple, robust
Case, Stage Plan or the Project Plan
monitoring systems to supply that information.
Check the status of any corrective actions
The objective of this activity, therefore, is to Assess the utilization of resources in the
maintain an accurate and current picture of period under review and their availability
progress on the work being carried out and the for the remainder of the stage (or project).
status of resources. Check for any variation in the expected
This activity occurs at a frequency defined in the future resource availability
Stage Plan, may be triggered by Project Board Check the Benefits Review Plan to see
advice, or forms part of the analysis of new issues whether any benefits reviews are due, and
and risks. execute them as necessary
Figure 15.5 shows the inputs to, and outputs from, Based on the above analysis, decide whether
this activity. any actions are required. For example, whether
to:
PRINCE2 recommends the following actions:
Authorize a Work Package (section 15.4.1)
Review progress for the stage:
Report highlights (section 15.4.5) in
Review Checkpoint Reports for the period accordance with the Communication
Review the current Stage Plan forecast and Management Strategy
actuals
174 | Controlling a Stage

Stage Plan Review the stage Corrective


status action

Tolerance
Quality Register threat

Stage boundary
approaching
Product
Status Account Project end
approaching

New Work
Checkpoint Report(s) Package

Request for
advice
Issue Register

Update
Risk Register

Risk Register

Update
Issue Register
Project Initiation
Documentation
Update
Stage Plan

Business Case
Update
Lessons Log

Project Plan

Update
Issue Report

Benefits Review Plan

Corrective
action

Project Board
advice

Figure 15.5 Review the stage status: activity summary

Capture and examine issues and risks (section Continue as planned


15.4.6)
Revise the Risk Register and Issue Register as
Escalate issues and risks (section 15.4.7) if necessary
tolerances are threatened
Update the Stage Plan if the aggregated
Take corrective action (section 15.4.8) assessment changes any forecasts
Seek Project Board advice (and if necessary If ownership of any of the products is to be
provide them with the Issue Report) transferred to the customer as part of a phased
Log any lessons that have been identified handover:
Controlling a Stage | 175

Table 15.4Review the stage status: responsibilities


Producer responsible for products production
Reviewer ideally independent of production

Product Description available


Approver confirms approval

Corporate/Programme

Project Assurance
Project Manager

Project Support
Team Manager
Senior Supplier
Senior User
Executive
Product Action
Risk Register Update P A25

Issue Register Update P A12

Stage Plan Update P R A16


Lessons Log Update P A14

Issue Report Update P A13

Request a Product Status Account for the 15.4.5Report highlights


release being handed over The Project Manager must provide the Project
Ensure that the: Board with summary information about the
Products have been approved by those status of the stage and project and distribute
specified in its Product Description other information to stakeholders at a frequency
Products meet all the quality criteria, or documented in the Communication Management
are covered by approved concessions Strategy (as defined by the Project Board). For
Operation and maintenance organizations more details on progress controls, see Chapter 10.
are ready to take responsibility for the Figure 15.6 shows the inputs to, and outputs from,
products this activity.
Hand over the products (see Chapter 18)
PRINCE2 recommends the following actions:
Consider whether to review lessons now or wait
Assemble the information from the Checkpoint
until a later review of stage status or when
approaching a stage end Reports, Risk Register, Issue Register, Quality
Register, Lessons Log, Product Status Account
If the end of the current stage is approaching
and any significant revisions to the Stage
(as indicated by, for example, the Stage
Plan for the current reporting period (the
Plan, the contents of the Quality Register, a
information is gained from the review of the
milestone etc.), prepare for the next stage (see
stage status see section 15.4.4)
Chapter 17)
Assemble a list of corrective actions (as noted
If the end of the final stage is approaching,
in the Daily Log and/or recorded in the Issue
prepare to close the project (see Chapter 18).
Register) undertaken during the reporting
Table 15.4 shows the responsibilities for this period. This will, for example, assure the Project
activity. Board that the Project Manager is acting
within the agreed tolerances (the information
is gained from taking corrective action see
section 15.4.8)
176 | Controlling a Stage

Create Highlight Report


Checkpoint Report(s) Report highlights (current period)

Risk Register

Issue Register

Quality Register

Lessons Log

Product
Status Account

Stage Plan

Daily Log

Highlight Report
(previous period)

Product Initiation
Documentation

Communication
Management
Strategy

Figure 15.6 Report highlights: activity summary

Review the Highlight Report for the previous 15.4.6Capture and examine issues and
reporting period risks
Produce the Highlight Report for the current
In the course of managing the project, various
reporting period issues will occur and risks may be identified. They
Distribute the Highlight Report to the Project will arrive in an ad hoc manner and will need to
Board and any other recipients identified in the be captured in a consistent and reliable way. Any
Communication Management Strategy. member of the project, corporate or programme
Table 15.5 shows the responsibilities for this management, or other stakeholders may raise an
activity. issue or risk.
Controlling a Stage | 177

Table 15.5Report highlights: responsibilities

Producer responsible for products production


Reviewer ideally independent of production

Product Description available


Approver confirms approval

Corporate/Programme

Project Assurance
Project Manager

Project Support
Team Manager
Senior Supplier
Senior User
Executive
Product Action
Highlight Report Create P R A11

Before making a decision on a course of action, Document the issue by creating an Issue

each issue or risk should be registered and then Report
assessed for its impact. Report the status of the issue in accordance

For more details on risk management, see with the Configuration Management
Chapter8. Strategy and check the Communication
Management Strategy to see whether there
For more details on issue and change control are any external parties that need to be
procedures, see Chapter 9. informed of the issue
Figure 15.7 shows the inputs to, and outputs from, For risks (see Chapter 8 for more information):
this activity. Check the requirements of the risk
management procedure in the Risk
PRINCE2 recommends the following actions:
Management Strategy
If an issue can be dealt with by the Project Enter the risk in the Risk Register as soon as
Manager informally, then this should be done, it is captured
and a note made in the Daily Log (see Chapter Identify the risk event and describe its cause
9 for more information) and effect
For issues that need to be managed formally
Assess the risk against the Stage Plan, Project
(see Chapter 9 for more information): Plan and Business Case and plan the selected
Check the requirements of the issue risk response
and change control procedure in the Report the status of the risk in accordance
Configuration Management Strategy with the Risk Management Strategy and
Enter the issue in the Issue Register as soon check the Communication Management
as it is captured Strategy to see whether there are any
Categorize the issue (is it a request for external parties that need to be informed of
change, an off-specification or a problem/ the risk
concern?) If it is necessary either to take corrective
Assess the severity of the issue action, seek advice from the Project Board, or
Assess the priority of the issue (for requests to escalate an issue or risk, then review the
for change and off-specifications) stage status first so that a full picture can be
Assess the impact of the issue on the Stage considered (see section 15.4.4).
Plan, Project Plan and Business Case Table 15.6 shows the responsibilities for this
activity.
178 | Controlling a Stage

Capture and Update


New issue examine issues Daily Log
and risks

Create
New risk
Issue Report

Stage Plan Update


Issue Register

Project Initiation
Update
Documentation
Risk Register

Business Case Request for


advice

Project Plan

Communication
Management Strategy

Configuration
Management Strategy

Figure 15.7 Capture and examine issues and risks: activity summary

Table 15.6 Capture and examine issues and risks: responsibilities


Producer responsible for products production
Reviewer ideally independent of production

Product Description available


Approver confirms approval
Corporate/Programme

Project Assurance
Project Manager

Project Support
Team Manager
Senior Supplier
Senior User
Executive

Product Action
Daily Log Update P A7

Issue Report Create P A13

Issue Register Update P A12


Risk Register Update P A25
Controlling a Stage | 179

15.4.7Escalate issues and risks followed by supporting information in the form of


A stage should not exceed the tolerances agreed an Exception Report.
with the Project Board. The Project Manager can The Project Manager should execute any decision
only take corrective action or maintain the status by the Project Board in response to the escalation.
quo as long as the stage (or project) is forecast
Escalating issues and risks is good practice and
to be completed within the tolerances set by the
should not be seen as failure. The earlier that
Project Board. This activity applies where any
issues are escalated, the more time is available to
corrective action within the Project Managers
implement any corrective actions.
control would not save the stage (or project) from
going beyond the tolerances agreed. This applies For more details on management of risk, see
to all types of issue and risk (or aggregation Chapter 8.
of them) that cannot be resolved within the
For more details on issue and change control, see
tolerances set by the Project Board.
Chapter 9.
As it may take some time to gather the information
For more details on exception management, see
to create an Exception Report, it is recommended
Chapter 10.
that the Project Board be alerted as early as
possible. Therefore, the Project Manager may Figure 15.8 shows the inputs to, and outputs from,
wish to execute this activity in two steps: an early this activity.
notification to the Project Board of the forecast
exception situation in order to prepare them,

Create
Tolerance Escalate Exception Report
threat issues and risks

Update
Project Initiation Issue Register
Documentation

Update
Risk Register
Business Case

Exception
raised
Project Plan
Update
Issue Report

Stage Plan
(current stage)

Issue Report

Issue Register

Risk Register

Figure 15.8 Escalate issues and risks: activity summary


180 | Controlling a Stage

PRINCE2 recommends the following actions: Granting a concession for an off-


specification, or deferring or rejecting it
Examine the Stage Plan to define the extent
Increasing the tolerances that are forecast to
of the deviation and the unfinished products,
and to extrapolate what would happen if the be breached
deviation were allowed to continue Instructing the Project Manager to produce

Examine the Project Plan for the project status an Exception Plan, stating what will be
and overall effect of any deviation (using acceptable (see Chapter 17)
the current baseline of the Project Initiation Instructing the Project Manager to close the
Documentation) project prematurely (see Chapter 18).
Determine the options for recovery and assess Table 15.7 shows the responsibilities for this
them against the Business Case activity.
Assess the impact of the options for recovery
against the Stage Plan for the current 15.4.8Take corrective action
stage. Consideration should be given to the Changes and adjustments to the project need to be
availability of individuals or groups with the made in a considered and rational way, even when
skills or experience to assess the impact they appear to be easily manageable and within
Put the situation, options and the tolerances.
recommendation for a course of action to In taking corrective action, the objective is to select
the Project Board in an Exception Report. and, within the limits of the stage and project
The Project Board will then decide on an tolerances, implement actions that will resolve
appropriate course of action (which may deviations from the plan. Corrective action is
support or otherwise the Project Managers triggered during the review of the stage status
recommendation). This may include: (section 15.4.4) and typically involves dealing with
Requesting more information or more time advice and guidance received from the Project
to consider their response Board, and with issues raised by Team Managers.
Approving, deferring or rejecting a request
for change

Table 15.7Escalate issues and risks: responsibilities


Producer responsible for products production
Reviewer ideally independent of production
Approver confirms approval Product Description available
Corporate/Programme

Project Assurance
Project Manager

Project Support
Team Manager
Senior Supplier
Senior User
Executive

Product Action
Exception Report Create (A) (R) (R) P R A10

Issue Register Update P A12

Risk Register Update P A25

Issue Report Update P A13


Controlling a Stage | 181

For more details on planning, see Chapter 7. For Update the Configuration Item Records of the
more details on issue and change control, see affected products
Chapter 9. Update the Issue Report (if necessary) to show
Figure 15.9 shows the inputs to, and outputs from, the status of the corrective action
this activity. Update the Issue Register with any changes
resulting from the corrective action (or if being
PRINCE2 recommends the following actions: handled informally, update the Daily Log with
Collect any relevant information about the the details and status of the corrective action)
deviation (from the Configuration Item Records, Update the Risk Register with any changes
Issue Register, Risk Register, Issue Report, resulting from the corrective action
Exception Report, Project Board advice, Daily Update the Stage Plan for the current stage.
Log)
Table 15.8 shows the responsibilities for this
Identify the potential ways of dealing with
activity.
the deviation and select the most appropriate
option
Trigger corrective action via authorizing a Work
Package (see section 15.4.1)

Daily Log Take corrective Update


Daily Log
action

Update Issue Register


Issue Register

Update Risk Register


Risk Register

Update Issue Report


Issue Report

Update Stage Plan


Stage Plan

Update Configuration
Item Records
Configuration
Item Records

Corrective
action
Corrective
action

Figure 15.9 Take corrective action: activity summary


182 | Controlling a Stage

Table 15.8Take corrective action: responsibilities

Producer responsible for products production


Reviewer ideally independent of production

Product Description available


Approver confirms approval

Corporate/Programme

Project Assurance
Project Manager

Project Support
Team Manager
Senior Supplier
Senior User
Executive
Product Action
Issue Register Update P A12

Risk Register Update P A25

Issue Report Update P R A13

Stage Plan Update P R A16

Configuration Item Records Update P (R) R A5

Daily Log Update P A7


16
Managing Product
Delivery
16 Managing Product Delivery

16.1 Purpose 16.3 Context


The purpose of the Managing Product Delivery Managing Product Delivery views the project
process is to control the link between the Project from the Team Managers perspective, while the
Manager and the Team Manager(s), by placing Controlling a Stage process views it from the
formal requirements on accepting, executing and Project Managers perspective.
delivering project work.
The Team Manager ensures that products are
The role of the Team Manager(s) is to coordinate created and delivered by the team to the project
an area of work that will deliver one or more of by:
the projects products. They can be internal or
Accepting and checking authorized Work
external to the customers organization.
Packages from the Project Manager
Ensuring that interfaces identified in the Work
16.2 Objective Package are maintained
The objective of the Managing Product Delivery Creating a Team Plan for the Work Packages
process is to ensure that: being assigned (where this may be done in
parallel with the Project Manager creating the
Work on products allocated to the team is Stage Plan for the management stage)
authorized and agreed
Ensuring that the products are developed in
Team Managers, team members and suppliers accordance with any development method(s)
are clear as to what is to be produced and what specified in the Work Package
is the expected effort, cost or timescales
Demonstrating that each product meets its
The planned products are delivered to quality criteria through the quality method(s)
expectations and within tolerance specified in the Product Description this
Accurate progress information is provided to may include using the PRINCE2 quality review
the Project Manager at an agreed frequency to technique (see Chapter 6)
ensure that expectations are managed. Obtaining approval for completed products
from the authorities identified in the Product
Description

Controlling a Stage

Authority to deliver Completed


a Work Package Work Package

Accept a Execute a Deliver a


Work Package Work Package Work Package

Managing Product Delivery


Figure 16.1 Overview of Managing Product Delivery
186 | Managing Product Delivery

Accept a Create Team Plan


Authority to deliver
Work Package
a Work Package

Update Quality Register


Work Package

Approve Work Package


Project Initiation
Documentation

Raise
New risk

Figure 16.2 Accept a Work Package: activity summary

Table 16.1 Accept a Work Package: responsibilities

Producer responsible for products production


Reviewer ideally independent of production

Product Description available


Approver confirms approval
Corporate/Programme

Project Assurance
Project Manager

Project Support
Team Manager
Senior Supplier
Senior User
Executive

Product Action
Team Plan Create (A) (A) P R

Risk Raise (R) P

Quality Register Update (R) R (P) A23


Work Package Approve (P) A R A26

Delivering the products to the Project Manager Work Package, to creating a fully formed plan that
in accordance with any procedures specified in is presented in a similar style to a Stage Plan.
the Work Package.
If the project uses external suppliers that are not 16.4 Activities
using PRINCE2, Managing Product Delivery provides
The activities within the Managing Product
a statement of the required interface between
Delivery process are Team-Manager-oriented and
the Team Manager and the PRINCE2 method
are to:
being used in the project by the Project Manager.
The Work Package may be part of a contractual Accept a Work Package
agreement. Therefore, the formality of a Team Plan Execute a Work Package
could vary from simply appending a schedule to the Deliver a Work Package.
Managing Product Delivery | 187

16.4.1 Accept a Work Package Understand the reporting requirements


The fundamental principle is that before a Work Understand how, and from whom, approval
Package is allocated to a team, there should be for the product(s) is to be obtained
agreement between the Project Manager and the Understand how the approved product(s) is
Team Manager as to what is to be delivered, the to be formally handed over
reporting requirements, what constraints apply, Confirm how the Project Manager is to be
any procedures to be applied, and whether the informed about the completion of the Work
requirements of the Work Package are reasonable Package
and can be achieved. Produce a Team Plan to show that the
Figure 16.2 shows the inputs to, and outputs from, product(s) can be completed within the given
this activity. constraints. Consult with Project Assurance
(supplier) that the Team Plan is viable and in
PRINCE2 recommends the following actions: accordance with relevant supplier standards.
Review the Work Package: Seek necessary approval for the Team Plan
Obtain any referenced documentation (although in a commercial customer/supplier
relationship, it may be inappropriate for the
Clarify with the Project Manager what is to
Project Manager to review and approve the
be delivered
Team Plan, in which case the key milestones
Negotiate with the Project Manager, on
will be summarized in the Work Package. In a
behalf of the team, the constraints within
commercial context, the Senior Supplier may
which the work is to be done
review and approve the Team Plans)
Agree tolerances for the Work Package

Execute a Create Specialist


Work Package Work Package product(s)

Update Quality Register


Team Plan

Update Configuration
Project Initiation Item Records
Documentation

Update
Team Plan

Create
Checkpoint Report(s)

Obtain Approval
record(s)

Raise
New risk

Raise
New issue

Figure 16.3 Execute a Work Package: activity summary


188 | Managing Product Delivery

Undertake a review of the risks against the is forecast to complete within the tolerances set
Team Plan, and advise the Project Manager by the Project Manager. As soon as Work Package
of any additional or modified risks (and if the tolerances are forecast to be exceeded, the Team
Work Package allows the Team Manager to Manager should raise an issue to the Project
directly log the risks, then the Team Manager Manager who will decide upon a course of action.
should update the Risk Register)
Figure 16.3 shows the inputs to, and outputs from,
Consult with Project Assurance as to
this activity.
whether any extra reviewers are required and
ensure that the Quality Register is updated PRINCE2 recommends the following actions:
accordingly (check the Work Package for the Manage the development of the required products:
procedure to update the Quality Register) Develop the product(s) required by the Work
Agree to deliver the Work Package. Package to the quality criteria defined in the
Table 16.1 shows the responsibilities for this Product Description(s)
activity. Ensure that the work is conducted in
accordance with the required techniques,
16.4.2Execute a Work Package processes and procedures specified in the
The work has to be executed and monitored to Work Package
the requirements defined in the authorized Work Maintain the development and operational
Package. and support interfaces as detailed in the
Work Package
While developing the products, the Team Manager
Check the Work Package for the procedure
should not exceed the Work Package tolerances
to update the Quality Register (for example,
agreed with the Project Manager. The Team
to record completed quality management
Manager can only proceed with the Work Package
activities)
or take corrective action while the Work Package

Table 16.2Execute a Work Package: responsibilities


Producer responsible for products production
Reviewer ideally independent of production

Product Description available


Approver confirms approval
Corporate/Programme

Project Assurance
Project Manager

Project Support
Team Manager
Senior Supplier
Senior User
Executive

Product Action
Specialist products Create (A) (A) (A) (R) P R

Quality Register Update (R) R (P) A23


Configuration Item Records Update P P A5

Team Plan Update P R


Checkpoint Report Create (R) P A3

Issue Raise (R) P

Risk Raise (R) P

Approval records Obtain (R) P R R


Managing Product Delivery | 189

Deliver a Update
Work Package
Work Package Work Package

Update
Team Plan
Quality Register

Completed
Configuration Work Package
Item Records

Figure 16.4 Deliver a Work Package: activity summary

Table 16.3 Deliver a Work Package: responsibilities


Producer responsible for products production
Reviewer ideally independent of production

Product Description available


Approver confirms approval
Corporate/Programme

Project Assurance
Project Manager

Project Support
Team Manager
Senior Supplier
Senior User
Executive

Product Action
Work Package Update (A) P R A26

Team Plan Update (R) P R

Capture and record the effort expended Check the Work Package and follow the
Monitor and control any issues and risks procedure to update the Configuration
associated with the Work Package and Item Records (to change the status of the
advise the Project Manager of their status products that have been completed)
Notify the Project Manager of any new issues, Review and report the status of the Work
risks or lessons. The Project Manager can then Package to the Project Manager:
decide on an appropriate course of action. Take Determine the status of each product in the
the action required by the Project Manager Work Package
Obtain approvals for completed products: Update the Team Plan and, if necessary,
Check the Work Package and follow the consult with Project Assurance (supplier)
method of obtaining and issuing approval regarding its viability
records
190 | Managing Product Delivery

Feed the progress information back to the PRINCE2 recommends the following actions:
Project Manager in Checkpoint Reports, in
Review the Quality Register to verify that all
the manner and at the frequency defined in
the quality activities associated with the Work
the Work Package
Package are complete
If the agreed tolerances for the Work
Review the approval records to verify that
Package are forecast to be exceeded, notify
all the products to be delivered by the Work
the Project Manager by raising an issue.
Package are approved
Table 16.2 shows the responsibilities for this activity. Update the Team Plan to show that the Work
Package is complete
16.4.3 Deliver a Work Package Check the Work Package and follow the
Just as the Work Package was accepted from the procedure to deliver completed products. Notify
Project Manager, notification of its completion the Project Manager that the Work Package is
must be returned to the Project Manager. complete.
Figure 16.4 shows the inputs to, and outputs from, Table 16.3 shows the responsibilities for this
this activity. activity.
17
Managing a
Stage Boundary
17 Managing a Stage Boundary

17.1 Purpose Therefore, the process should be executed at, or


close to the end of, each management stage.
The purpose of the Managing a Stage Boundary
process is to enable the Project Board to be Projects do not always go to plan and in response
provided with sufficient information by the Project to an Exception Report (if the stage or project
Manager so that it can review the success of the is forecast to exceed its tolerances) the Project
current stage, approve the next Stage Plan, review Board may request that the current stage (and
the updated Project Plan, and confirm continued possibly the project) is replanned. The output from
business justification and acceptability of the risks. replanning is an Exception Plan which is submitted

Directing a Project

Request to approve
Exception Plan

Request to approve
next Stage Plan Exception Plan
request

Update the Produce an


Report stage end Business Case Exception Plan

Update the
Project Plan

Plan the next stage

Managing a Stage Boundary

Stage boundary
approaching

Initiating a Controlling a
Project Stage

Figure 17.1 Overview of Managing a Stage Boundary


194 | Managing a Stage Boundary

for Project Board approval in the same way that a It is also important to recognize that projects can
Stage Plan is submitted for approval. go wrong or can be affected by external factors
that invalidate the business justification. An early
identifier of potential failure is the Project Managers
17.2 Objective
forecast that any of the project or stage tolerances
The objective of the Managing a Stage Boundary are likely to be exceeded. In such cases it is important
process is to: to have a mechanism for corrective action in order to
Assure the Project Board that all products in bring the project back into the right direction.
the Stage Plan for the current stage have been A positive decision not to proceed is not failure.
completed and approved However, providing insufficient information
Prepare the Stage Plan for the next stage that prevents the Project Board from making an
Review and, if necessary, update the Project informed decision is itself a failure as it may lead to
Initiation Documentation (in particular the a wrong decision.
Business Case, Project Plan, project approach, The Managing a Stage Boundary process provides
strategies, project management team structure a means by which an exception process can be
and role descriptions) implemented.
Provide the information needed for the Project
Board to assess the continuing viability of
the project including the aggregated risk 17.4 Activities
exposure The activities within the Managing a Stage
Record any information or lessons that can help Boundary process are Project-Manager-oriented
later stages of this project and/or other projects and are to:
Request authorization to start the next stage. Plan the next stage
For exceptions, the objectives of the Managing a Update the Project Plan
Stage Boundary process are to: Update the Business Case
Prepare an Exception Plan as directed by the Report stage end
Project Board Produce an Exception Plan.
Seek approval to replace the Project Plan
or Stage Plan for the current stage with the 17.4.1 Plan the next stage
Exception Plan. The Stage Plan for the next management stage
is produced near the end of the current stage.
Managing a Stage Boundary is not used towards
Closure activities should be planned as part of the
the end of the final stage (unless there is a need
Stage Plan for the final stage.
to create an Exception Plan) because the activities
to review the performance of the final stage are Planning is not an activity undertaken in isolation.
included in the activities to review the performance The Project Manager will need to consult with the
of the whole project as part of the Closing a Project Project Board, Project Assurance, Team Managers
process. and possibly other stakeholders in order to create a
viable plan. The more people involved in planning,
the more robust the plan will be (so long as the
17.3 Context
right people are involved). See Chapter 7 for more
The Managing a Stage Boundary process is predicated details on planning.
on dividing the project into management stages (see
Figure 17.2 shows the inputs to, and outputs from,
Chapter 10).
this activity.
A project, whether large or small, needs to ensure
PRINCE2 recommends the following actions:
that the products it creates will deliver the benefits
being sought, either in their own right or as part of Review the components of the Project Initiation
a larger programme. The continuing correct focus of Documentation. It may be necessary to consult
the project should be confirmed at the end of each with the Project Board regarding any required
stage. If necessary, the project can be redirected or changes. The following should be reviewed
stopped to avoid wasting time and money. and, if necessary, updated:
Managing a Stage Boundary | 195

Update Project Initiation


Stage boundary Plan the next stage Documentation
approaching

Create
Project Initiation Stage Plan
Documentation (next stage)

Create
Issue Register Product Descriptions
(next stage)

Update
Risk Register Configuration
Item Records

Update
Lessons Log
Risk Register

Update
Issue Register

Update
Quality Register

Figure 17.2 Plan the next stage: activity summary

Table 17.1 Plan the next stage: responsibilities

Producer responsible for products production


Reviewer ideally independent of production

Product Description available


Approver confirms approval
Corporate/Programme

Project Assurance
Project Manager

Project Support
Team Manager
Senior Supplier
Senior User
Executive

Product Action
Project Initiation Documentation Update (R) (A) (A) (A) P R A20

Stage Plan Create (A) (A) (A) P R A16

Configuration Item Records Create/update P R R A5

Risk Register Update P R A25

Issue Register Update P R A12

Quality Register Update R R P A23


196 | Managing a Stage Boundary

Any change to the customers quality


Update the Issue Register and Risk Register if
expectations, acceptance criteria or project any new issues or risks have been identified (or
approach if existing ones need to be modified)
The relevance and suitability of the Update the Quality Register for planned quality
strategies and controls management activities. This should include
Any change in the project management target review and approval dates for the
team or their role descriptions (in particular products.
the situation with regard to external Table 17.1 shows the responsibilities for this activity.
resources or suppliers as these may affect the
Stage Plan) 17.4.2Update the Project Plan
Produce the Stage Plan for the next stage:
The Project Board uses the Project Plan throughout
Decide how the plan can best be presented
the project to measure progress.
given its audience, and how it will be used
Review the Project Plan to understand the
The Project Plan is updated to incorporate actual
products required for the next stage progress from the stage that is finishing, and
to include forecast duration and costs from the
Examine the Quality Management Strategy
Exception Plan or Stage Plan for the stage about to
for the quality standards and procedures
begin.
required
Create (or update) the product breakdown Details of any revised costs or end dates are used
structure, Product Descriptions and product when updating the Business Case.
flow diagram for the products to be See Chapter 7 for more details on planning.
delivered by the next stage
Review the Issue Register as it may contain
Figure 17.3 shows the inputs to, and outputs from,
issues marked for assessment at the stage this activity.
end or information that affects the next PRINCE2 recommends the following actions:
stage
Check that the current Stage Plan is up to date
Review the Risk Register for any risks that
with actual progress and update if necessary
may affect the Stage Plan for the next stage,
Revise the Project Plan to reflect:
and check the status of risk responses by
consulting with the risk owners Actuals from the current Stage Plan
Create (or update) Configuration Item Records Forecasts from the next Stage Plan, or the
for products to be produced in the next stage impact of the Exception Plan

(Part of)
Stage Plan Update the Project Initiation
(current stage) Project Plan Documentation

Update Project Plan


Stage Plan
(next stage)

Update Issue Register


Project Initiation
Documentation

Update Risk Register


Exception Plan

Figure 17.3 Update the Project Plan: activity summary


Managing a Stage Boundary | 197

Table 17.2Update the Project Plan: responsibilities

Producer responsible for products production


Reviewer ideally independent of production

Product Description available


Approver confirms approval

Corporate/Programme

Project Assurance
Project Manager

Project Support
Team Manager
Senior Supplier
Senior User
Executive
Product Action
Project Plan Update (A) (A) (A) P R A16

Issue Register Update P R A12

Risk Register Update P R A25

Any changes to the Project Product Projects, however, do not take place in a static
Description environment. The environment external to the
The implications of any issues or risks project changes, as do the nature and timing of
Any new or changed PRINCE2 process- the projects products. The Business Case needs to
tailoring requirements for the project reflect these changes and must be reviewed and
Any changed or extra products sanctioned
amended to keep it relevant to the project.
by the Project Board As the Executive is responsible for the Business
Any changes within the Project Initiation Case, the Project Manager should consult with
Documentation (e.g. revised project the Executive when reviewing and updating the
approach, strategies, project controls, Business Case in preparation for Project Board
project management team structure or role approval.
descriptions)
For further details on business justification, see
Update the Issue Register and Risk Register if
Chapter 4.
any new issues or risks have been identified (or
if existing ones need to be modified). Figure 17.4 shows the inputs to, and outputs from,
this activity.
Table 17.2 shows the responsibilities for this
activity. PRINCE2 recommends the following actions:
Check whether there have been any changes
17.4.3Update the Business Case to the risk appetite and risk capacity of the
It is a PRINCE2 principle that projects have organizations involved and whether risk
continued business justification. tolerances need to be redefined. Assess
the projects risks using the Risk Register to
The Project Board is ordinarily only authorized to
ascertain the aggregated risk exposure for the
continue while the project remains viable (that is,
project and identify the current key risks that
the benefits will be realized within the cost, time,
affect the Business Case. This should include an
quality, scope and risk parameters set out in the
assessment that the aggregated risk exposure
currently agreed Business Case).
remains within risk tolerances
198 | Managing a Stage Boundary

(Part of)
Risk Register Update the Project Initiation
Business Case Documentation

Update
Issue Register Business Case

(Part of) Update


Project Initiation Benefits
Documentation Review Plan

Update
Project Plan
Risk Register

Update
Benefits Review Issue Register
Plan

Figure 17.4 Update the Business Case: activity summary

Update the Benefits Review Plan with the The Issue Register for any issues that may
results from any benefits reviews undertaken affect the Business Case
during the stage The Project Plan to see whether the final
Examine and review: implementation date of the project has
The Benefits Review Plan for the results of changed (for better or worse), which might
any benefits reviews undertaken during the affect some or all of the projected benefits
stage compared with the expected results The Project Plan to see whether the cost
The impact of approved changes as these of delivering the projects products has
may affect the projected benefits changed, which may affect the cost/benefit
The project risk profile and key risks analysis

Table 17.3Update the Business Case: responsibilities

Producer responsible for products production


Reviewer ideally independent of production
Product Description available
Approver confirms approval
Corporate/Programme

Project Assurance
Project Manager

Project Support
Team Manager
Senior Supplier
Senior User
Executive

Product Action
Business Case Update (R) (A) (A) (A) P R A2

Benefits Review Plan Update (R) (A) (A) (A) P R A1

Risk Register Update P R A25

Issue Register Update P R A12


Managing a Stage Boundary | 199

The corporate or programme environment The Project Manager gives a view on the
into which the projects products will be continuing ability of the project to meet the
delivered, as it may have changed Project Plan and Business Case, and assesses the
Whether any benefits reviews are required overall risk situation.
in the next management stage This activity should happen as close as possible to
Revise the Business Case and, if necessary, the the actual end of a stage.
Benefits Review Plan, ready for Project Board
approval Figure 17.5 shows the inputs to, and outputs from,
this activity.
Update the Risk Register and Issue Register as
necessary. PRINCE2 recommends the following actions:
Table 17.3 shows the responsibilities for this For an Exception Plan:
activity. Depending on the point within the stage
when the exception occurred, it may be
17.4.4Report stage end appropriate to produce an End Stage Report
The results of a stage should be reported back to for the activities to date. Whether this is
the Project Board so that progress is clearly visible required will be advised by the Project Board
to the project management team. in response to the Exception Report. If an

(Part of) Create End Stage Report


Project Initiation Report stage end (current stage)
Documentation

Create
Lessons Report
Business Case

Create
Communication Follow-on action
Management Strategy recommendations

Request to approve
Benefits Review next Stage Plan
Plan
Request to approve
Exception Plan

Issue Register

Risk Register

Quality Register

Stage Plan
(current stage)

Product Status
Account

Lessons Log

Figure 17.5 Report stage end: activity summary


200 | Managing a Stage Boundary

End Stage Report is required, then follow Review the issues and risks raised during
the guidance for a Stage Plan below the stage and any risk response actions
For a Stage Plan: taken. Include a summary of the current
Review the status of the updated Business aggregated risk exposure
Case and, in particular, the achievement Prepare an End Stage Report for the current
of any benefits anticipated for the stage. stage
Confirm that any activities in the Benefits It may be appropriate to create a Lessons
Review Plan for the current stage have been Report at this time, particularly for longer
completed projects, where interim reviews of lessons, or
Review the Stage Plan to ensure that the the project itself, may benefit corporate or
objectives of the stage have been met, and programme management. Check the Lessons
the Project Plan to ensure that the project Log for appropriate lessons to report
objectives are still achievable Seek approval from the Project Board of
Review the team performance for the stage the Exception Plan or Stage Plan (and, if
Review the product performance for the appropriate, the revised Project Plan, the
stage by reference to the Product Status revised Benefits Review Plan and the revised
Account (provided by Project Support): Business Case [see Chapter 13])
Review the quality management activities Review the Communication Management
for the stage and their results Strategy to see whether there is a requirement
Ensure that all the products identified
to send copies of the End Stage Report (and,
within the Stage Plan for the current stage if appropriate, the Lessons Report) to external
are complete and approved, or have been interested parties at this time.
carried forward into the next stage Table 17.4 shows the responsibilities for this
If a phased handover of products occurred activity.
during the stage, confirm user acceptance
and operational and maintenance 17.4.5 Produce an Exception Plan
acceptance of the products transferred If a stage or the project is forecast to deviate
to customer ownership. Identify any beyond its agreed tolerances, it no longer has the
follow-on action recommendations for the approval of the Project Board.
products handed over

Table 17.4Report stage end: responsibilities

Producer responsible for products production


Reviewer ideally independent of production
Product Description available

Approver confirms approval


Corporate/Programme

Project Assurance
Project Manager

Project Support
Team Manager
Senior Supplier
Senior User
Executive

Product Action
End Stage Report Create (A) (A) (A) P R A9

Lessons Report Create (A) (A) (A) P R A15

Follow-on action recommendations Create (A) (A) (A) P R


Managing a Stage Boundary | 201

Produce an Update
Exception Plan Issue Register
request Exception Plan

Stage Plan Update


(current stage) Project Initiation
Documentation

Create
Exception Report
Exception Plan

Create
Issue Register Product Description(s)

Update
Risk Register Configuration
Item Records

Project Initiation Update


Documentation Quality Register

Update
Risk Register

Figure 17.6 Produce an Exception Plan: activity summary

Exception Plans are requested by the Project Board The customers quality expectations do
in response to an Exception Report. Although they remain unchanged?
an Exception Plan will be produced prior to the The relevance and suitability of the project
planned stage boundary, its approval by the Project approach, the strategies and controls
Board marks a stage boundary for the revised stage. Any change in the project management
Planning is not an activity undertaken in isolation. team or their role descriptions (in particular
The Project Manager will need to consult with the situation with regard to external
Project Board members, Project Assurance, Team resources or suppliers as these may affect the
Managers and possibly other stakeholders in order Exception Plan)
to create a viable plan. The more people involved Produce the Exception Plan:
in planning, the more robust the plan will be. See Examine the Stage Plan to define the
Chapter 7 for more details on planning. products required for the stage
Examine the Exception Report for details
Figure 17.6 shows the inputs to, and outputs from,
this activity. (such as recommended actions) that will
contribute to the Exception Plan
PRINCE2 recommends the following actions: If the Exception Plan requires new products
Update the Issue Register (and, if necessary, to be created, then examine the Quality
the Issue Report) to record the Project Boards Management Strategy for the quality
request for an Exception Plan standards and procedures required
Review and, if needed, update the Project Update the product breakdown structure,
Initiation Documentation. It may be necessary Product Descriptions and product flow
to consult with the Project Board regarding diagram for the products to be delivered by
any required changes. The following should be the Exception Plan
reviewed:
202 | Managing a Stage Boundary

Table 17.5 Produce an Exception Plan: responsibilities

Producer responsible for products production


Reviewer ideally independent of production

Product Description available


Approver confirms approval

Corporate/Programme

Project Assurance
Project Manager

Project Support
Team Manager
Senior Supplier
Senior User
Executive
Product Action
Project Initiation Documentation Update (R) (A) (A) (A) P R A20

Exception Plan Create (A) (A) (A) P R A16

Configuration Item Records Create/update R R P A5

Risk Register Update P R A25

Issue Register Update P R A12

Quality Register Update R (R) R P A23

Update the Quality Register for planned


quality management activities
Create (or update) Configuration Item Records
for products to be produced by the Exception
Plan
Update the Issue Register and Risk Register if
any new issues or risks have been identified (or
if existing ones need to be modified)
Update the Quality Register for planned quality
management activities. This should include
target review and approval dates for the
products.
Table 17.5 shows the responsibilities for this
activity.
18
Closing a Project
18 Closing a Project

18.1 Purpose Assess any benefits that have already been


realized, update the forecast of the remaining
The purpose of the Closing a Project process is to
benefits, and plan for a review of those
provide a fixed point at which acceptance for the
unrealized benefits
project product is confirmed, and to recognize that
Ensure that provision has been made to address
objectives set out in the original Project Initiation
all open issues and risks, with follow-on action
Documentation have been achieved (or approved
recommendations.
changes to the objectives have been achieved), or
that the project has nothing more to contribute.
18.3 Context
18.2 Objective One of the defining features of a PRINCE2 project
is that it is finite it has a start and an end. If the
The objective of the Closing a Project process is to:
project loses this distinctiveness, it loses some of its
Verify user acceptance of the projects products advantages over purely operational management
Ensure that the host site is able to support the approaches.
products when the project is disbanded
A clear end to a project:
Review the performance of the project against
its baselines

Directing a Project

Premature
close

Controlling a Project end Prepare planned Prepare premature


closure
Stage approaching closure

Hand over
products

Closing a
Project Evaluate the project

Recommend project Closure


closure recommendation

Figure 18.1 Overview of Closing a Project


206 | Closing a Project

Is always more successful than a slow drift into A number of actions specific to the projects
use as it is a recognition by all concerned that: products may be required after the project, and
The original objectives have been met
these should be documented and planned for as
(subject to any approved changes) follow-on action recommendations. These may
The current project has run its course have different audiences and therefore may need
Either the operational regime must now
to be issued individually. The needs of the recipient
take over the products from this project, will determine the format and content some
or the products become inputs into some may want a formal report, some a log entry on a
subsequent project or into some larger system, and others a meeting.
programme
The project management team can be 18.4 Activities
disbanded
The activities within the Closing a Project process
Project costs should no longer be incurred
are Project-Manager-oriented and are to:
Provides an opportunity to ensure that all
unachieved goals and objectives are identified Prepare planned closure
so that they can be addressed in the future Prepare premature closure
Transfers ownership of the products to the Hand over products
customer and terminates the responsibility of Evaluate the project
the project management team. Recommend project closure.

Closure activities should be planned as part of


the Stage Plan for the final management stage.
18.4.1 Prepare planned closure
When closing a project, work is required to prepare Before closure of the project can be recommended,
input to the Project Board in order to obtain its the Project Manager must ensure that the expected
authorization to close the project. Subsequently, results have all been achieved and delivered.
the Executive should also notify corporate or Figure 18.2 shows the inputs to, and outputs from,
programme management that the project has this activity.
closed (see Chapter 13).
PRINCE2 recommends the following actions:
It is also possible that the Project Board may wish
to trigger a premature closure of the project under Update the Project Plan with actuals from the
some circumstances (for example, if the Business final stage
Case is no longer valid). If the project is being Request a Product Status Account from Project
brought to a premature close, this process will still Support. From the Product Status Account,
need to be executed, but may have to be tailored ensure that the projects products:
to the actual project situation.

Project end Prepare planned Project Initiation


approaching closure Documentation

Product Status Update


Account Project Plan

Project Initiation
Documentation

Project Plan

Figure 18.2 Prepare planned closure: activity summary


Closing a Project | 207

Table 18.1 Prepare planned closure: responsibilities

Producer responsible for products production


Reviewer ideally independent of production

Product Description available


Approver confirms approval

Corporate/Programme

Project Assurance
Project Manager

Project Support
Team Manager
Senior Supplier
Senior User
Executive
Product Action
Project Plan Update P R A16

Product Status Account Create R R P A18

Have been approved by the authorities


18.4.2 Prepare premature closure
identified in their Product Descriptions In some situations, the Project Board may have
Meet all the quality criteria, or are covered instructed the Project Manager to close the project
by approved concessions prematurely. In such circumstances, the Project
Confirm that the project has delivered what is Manager must ensure that work in progress is not
defined in the Project Product Description, and simply abandoned, but that the project salvages
that the acceptance criteria have been met anything of value created to date and checks that
Seek approval to give notice to corporate or any gaps left by the cancellation of the project are
programme management that resources can be raised to corporate or programme management.
(or are about to be) released.
Figure 18.3 shows the inputs to, and outputs from,
Table 18.1 shows the responsibilities for this this activity.
activity.
PRINCE2 recommends the following actions:
Update the Issue Register (and, if necessary, the
Issue Report) to record the premature closure
request

Update
Premature Prepare premature
closure Issue Register
close

Product Status
Account Project Initiation
Documentation

Project Initiation Update


Documentation Project Plan

Create
Project Plan Additional work
estimates

Figure 18.3 Prepare premature closure: activity summary


208 | Closing a Project

Update the Project Plan with actuals from the 18.4.3 Hand over products
final stage The projects products must be passed to an
Request a Product Status Account from Project operational and maintenance environment prior
Support. From this, determine which of the to the project being closed. This may happen as
projects products: a single release at the end of the project, or the
Have been approved by the authorities project approach may include phased delivery
identified in their Product Descriptions where products are handed over in a number of
Are currently in development (and which of releases.
those need to be completed)
In the case of a premature closure, there may be
Are covered by approved concessions some products that have been approved but not
Have yet to be started yet handed over and, depending on the Project
Need to be made safe Board guidance, the ownership of some or all of
May be useful to other projects those products may need to be transferred to the
Agree the means for recovering products