PROJECT MANAGEMENT

WITH PRINCE2®
DLMPREEPMPR01
PROJECT MANAGEMENT WITH
PRINCE2®
 MASTHEAD

Publisher:
IU Internationale Hochschule GmbH
IU International University of Applied Sciences
Juri-Gagarin-Ring 152
D-99084 Erfurt

Mailing address:
Albert-Proeller-Straße 15-19
D-86675 Buchdorf
[email protected]
www.iu.de

DLMPREEPMPR01
Version No.: 001-2022-1128
Caroline Naudin

© 2022 IU Internationale Hochschule GmbH

This course book is protected by copyright. All rights reserved.
This course book may not be reproduced and/or electronically edited, duplicated, or dis-
tributed in any kind of form without written permission by the IU Internationale Hoch-
schule GmbH.
The authors/publishers have identified the authors and sources of all graphics to the best
of their abilities. However, if any erroneous information has been provided, please notify
us accordingly.

2
PROF. DR. NEBOJŠA RADOJEVIĆ

Mr. Radojević joined IU International University of Applied Sciences in October 2022 as a pro-
fessor of project management.

Nebojša holds a doctorate in international business and an MBA from Université de Montréal
(Canada), a degree in computer science from Technische Universität Dresden (Germany), and
professional certificates in project and program management. He has taught international
business, general management, project management, strategic management, and innova-
tion management at universities in Canada, China, and Germany.

Mr. Radojević has worked as a manager, project and program manager, and management
consultant for multinational enterprises in the IT industry, consultancy business, and aircraft
manufacturing, as well as for governments in Canada, Cyprus, Germany, and Serbia. The
dominant themes of his professional projects have been IT diffusion, digital transformation,
and business process innovation.

In his research, Mr. Radojević focuses on themes revolving around innovation in the interna-
tional context, such as innovation strategy, micro-foundations of innovation management,
innovation metrics, and links between corporate governance and innovation.

3
 TABLE OF CONTENTS
PROJECT MANAGEMENT WITH PRINCE2®

Module Director . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Introduction
Signposts Throughout the Course Book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Basic Reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Required Reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Further Reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Learning Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Unit 1
Introduction to the PRINCE2® Method 15

1.1 History of PRINCE2® . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

1.2 Project Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.3 The Seven Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.4 The Project Management Team – Structure and Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
1.5 Management Products and Specialist Products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Unit 2
The Seven Themes 37

2.1 Introduction to Themes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

2.2 Business Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.3 Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.4 Quality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
2.5 Plans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
2.6 Risk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
2.7 Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
2.8 Progress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Unit 3
The Seven Processes 71

3.1 Overview and Interaction of the Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

3.2 Starting up a Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
3.3 Initiating a Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
3.4 Directing a Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
3.5 Controlling a Stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
3.6 Managing Product Delivery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
3.7 Managing Stage Boundaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
3.8 Closing a Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

4
Unit 4
Creation of Results 89

4.1 Creation of Management Products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

4.2 Creation of Specialist Products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

Unit 5
Tailoring 107

5.1 Tailoring of PRINCE2® to the Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

5.2 Scaling of PRINCE2® by Combining Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
5.3 Combining PRINCE2® With Other Project Management Methods . . . . . . . . . . . . . . . . . 113

Unit 6
PRINCE2® Agile 117

6.1 Goal of PRINCE2® Agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

6.2 Overview of PRINCE2® Agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
6.3 Similarities and Differences to the Original PRINCE2® . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

Appendix
List of References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
List of Tables and Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

5
INTRODUCTION
 WELCOME
SIGNPOSTS THROUGHOUT THE COURSE BOOK

This course book contains the core content for this course. Additional learning materials
can be found on the learning platform, but this course book should form the basis for your
learning.

The content of this course book is divided into units, which are divided further into sec-
tions. Each section contains only one new key concept to allow you to quickly and effi-
ciently add new learning material to your existing knowledge.

At the end of each section of the digital course book, you will find self-check questions.
These questions are designed to help you check whether you have understood the con-
cepts in each section.

For all modules with a final exam, you must complete the knowledge tests on the learning
platform. You will pass the knowledge test for each unit when you answer at least 80% of
the questions correctly.

When you have passed the knowledge tests for all the units, the course is considered fin-
ished and you will be able to register for the final assessment. Please ensure that you com-
plete the evaluation prior to registering for the assessment.

Good luck!

8
 BASIC READING
AXELOS Limited. (2017). Managing successful projects with PRINCE2® (6th ed.). The Station-
ery Office. http://search.ebscohost.com.pxz.iubh.de:8080/login.aspx?direct=true&db=
cat05114a&AN=ihb.51040&site=eds-live&scope=site

Cooke, J. L. (2016). PRINCE2 Agile. An implementation pocket guide: Step-by-step advice for
every project type. IT Governance Publishing. http://search.ebscohost.com.pxz.iubh.d
e:8080/login.aspx?direct=true&db=edsebk&AN=1232537&site=eds-live&scope=site

International Conference on Electronics, Computers, and Artificial Intelligence, Universita-

tea din Piteşti, Institute of Electrical and Electronics Engineers, IEEE Industry Applica-
tions Society, & ECAI. (2017, June 29–July 1). Proceedings of the 9th International Con-
ference on Electronics, Computers and Artificial Intelligence, New Jersey. http://searc
h.ebscohost.com.pxz.iubh.de:8080/login.aspx?direct=true&db=edsdbl&AN=edsdbl.co
nf.ecai2.2017&site=eds-live&scope=site

Mathis, B. (2014). Prince2 for beginners: Prince2 study guide for certification and project
management. CreateSpace Independent Publishing Platform.

9
 REQUIRED READING
UNIT 1

AXELOS Limited. (2017). Managing successful projects with PRINCE2® (6th ed.). The Station-
ery Office. 19–28; 338–348 http://search.ebscohost.com.pxz.iubh.de:8080/login.aspx?
direct=true&db=cat05114a&AN=ihb.51040&site=eds-live&scope=site

UNIT 2

AXELOS Limited. (2017). Managing successful projects with PRINCE2® (6th ed.). The Station-
ery Office. 46–49; 58–67; 78–82; 94–101; 120–122; 138–140; 148–153 http://search.ebsc
ohost.com.pxz.iubh.de:8080/login.aspx?direct=true&db=cat05114a&AN=ihb.51040&si
te=eds-live&scope=site

Bentley, C. (2019). The Concise PRINCE2®: Principles and essential themes (3rd ed.). IT Gov-
ernance Publishing. 47–86 http://search.ebscohost.com.pxz.iubh.de:8080/login.aspx?
direct=true&db=edsebk&AN=2037102&site=eds-live&scope=site

UNIT 3

AXELOS Limited. (2017). Managing successful projects with PRINCE2® (6th ed.). The Station-
ery Office. 158–168; 180–181; 196–197; 216–218; 236–237; 246–248; 260–262 http://sea
rch.ebscohost.com.pxz.iubh.de:8080/login.aspx?direct=true&db=cat05114a&AN=ihb.5
1040&site=eds-live&scope=site

UNIT 4

AXELOS Limited. (2017). Managing successful projects with PRINCE2® (6th ed.). The Station-
ery Office. 290–332; 350–356 http://search.ebscohost.com.pxz.iubh.de:8080/login.asp
x?direct=true&db=cat05114a&AN=ihb.51040&site=eds-live&scope=site

UNIT 5

AXELOS Limited. (2017). Managing successful projects with PRINCE2® (6th ed.). The Station-
ery Office. 30–40; 271–288 http://search.ebscohost.com.pxz.iubh.de:8080/login.aspx?
direct=true&db=cat05114a&AN=ihb.51040&site=eds-live&scope=site

UNIT 6

AXELOS Limited. (2015). PRINCE2 Agile®. The Stationery Office. 37–44; 48–59; 212–246 http:
//search.ebscohost.com.pxz.iubh.de:8080/login.aspx?direct=true&db=cat05114a&AN=
ihb.51814&site=eds-live&scope=site

10
 FURTHER READING
UNIT 1

Bentley, C. (2019). The Concise PRINCE2®: Principles and essential themes (3rd ed.). IT Gov-
ernance Publishing. 8–9 http://search.ebscohost.com.pxz.iubh.de:8080/login.aspx?dir
ect=true&db=edsebk&AN=2037102&site=eds-live&scope=site

Buehring, S. (2018). PRINCE2®: Principles. Knowledge Train. 1–14. Available online

UNIT 2

Khoja, S. A., Dhirani, L. L., Chowdhary, B. S. & Kalhoro, Q. (2010, November 19–23). Quality
control and risk mitigation: A comparison of project management methodologies in
practice [Conference session]. 2010 International Conference on Education and Man-
agement Technology, Education and Management Technology (ICEMT). http://search.
ebscohost.com.pxz.iubh.de:8080/login.aspx?direct=true&db=edseee&AN=edseee.565
7555&site=eds-live&scope=site

Schibi, O. (2014). Managing stakeholder expectations for project success – A knowledge inte-
gration framework and value focused approach. J. Ross Publishing. 261–276 http://sea
rch.ebscohost.com.pxz.iubh.de:8080/login.aspx?direct=true&db=edsknv&AN=edsknv.
kpMSEPSAK1&site=eds-live&scope=site

UNIT 3

Bentley, C. (2019). The concise PRINCE2®: Principles and essential themes (3rd ed.). IT Gov-
ernance Publishing. 13–46. http://search.ebscohost.com.pxz.iubh.de:8080/login.aspx?
direct=true&db=edsebk&AN=2037102&site=eds-live&scope=site

UNIT 4

Cox, K. (2021). Business analysis, requirements, and project management: A guide for com-
puting students. Auerbach Publications. Chapter 7 http://search.ebscohost.com.pxz.iu
bh.de:8080/login.aspx?direct=true&db=cat05114a&AN=ihb.52034&site=eds-live&scop
e=site

Turner, J. R., & Cochrane, R. A. (1993). Goals-and-methods matrix: Coping with projects
with ill-defined goals and/or methods of achieving them. International Journal of
Project Management, 11(2), 93–102. http://search.ebscohost.com.pxz.iubh.de:8080/lo
gin.aspx?direct=true&db=edsbas&AN=edsbas.2C4DE9E8&site=eds-live&scope=site

11
 UNIT 5

Hinde, D. (2018). Tailoring PRINCE2 to different organizational cultures [White paper]. AXE-
LOS Limited. 12–16. Available online

UNIT 6

Beck, K., Grenning J., Martin, R. C., Beedle, M., Highsmith, J., Mellor, S., van Bennekum, A.,
Hunt, A., Schwaber, K., Cockburn, A., Jeffries, R., Sutherland, J., Cunningham, W.,
Kern, J., Thomas, D., Fowler, M., & Marick, B. (2001). Manifesto for Agile software devel-
opment. Agile Alliance. Available online

Fiampolis, P. (2015). Making sense of PRINCE2 Agile. PM World Journal, 1(4), 1–5. http://sea
rch.ebscohost.com.pxz.iubh.de:8080/login.aspx?direct=true&db=bsu&AN=102562863
&site=eds-live&scope=site

12
 LEARNING OBJECTIVES
According to KPMG (2017), 80 percent of organizations use several project management
methods; PRINCE2® is the most commonly practiced. Why is it so popular? How suitable is
it for your professional challenges? The course book Project Management with
PRINCE2® will explain the PRINCE2® framework, principles, and particularities; help you
reflect on them; and give insight into the roles and responsibilities of the PRINCE2® man-
agement team.

The process-oriented PRINCE2® method is primarily concerned with the project manage-
ment team’s actions, emphasizing the management aspect of seven project themes
(called domains of management activities), rather than the execution side. You will learn
about the well-structured interactions between project management and execution lev-
els, including the reporting cycles.

PRINCE2® is universal; it can be adapted and tailored to any kind of project or environ-
ment and applied to other project methods. The course book will conclude with an out-
look on the features of PRINCE2® Agile to better understand its level of flexibility and com-
patibility. This will also help you identify the advantages, challenges, and disadvantages of
each mode; its field of application; and where the method is unsuitable.

13
 UNIT 1
INTRODUCTION TO THE PRINCE2® METHOD

STUDY GOALS

On completion of this unit, you will be able to...

– understand the contents of the PRINCE2® framework.

– apply the seven PRINCE2® principles.
– define the roles of the PRINCE2® management team.
– identify the different types of PRINCE2® products.
 1. INTRODUCTION TO THE PRINCE2®
METHOD

Introduction
According to the Project Management Institute (PMI; 2021b) Pulse of the Profession survey,
35 percent of projects fail with a loss of the project budget. Implementing strong gover-
Governance nance can offer organizations better visibility and decision-making procedures for more
set of system, processes, controlled proactive project management. Projects IN Controlled Environments version two
and mechanisms by
which an organization (PRINCE2) compiles experienced best practices for more efficient and successful project
and its people operate, management in the AXELOS Limited’s (2017) book, Managing Successful Projects with
communicate, are con- PRINCE2, which is the source of every PRINCE2® certification for practitioners and their
trolled, and held account-
able related credentials. This model is adaptable and scalable to any kind of project and envi-
ronment, as well as the evolving best practices worldwide. It is, thus, changing with time,
offering new versions; we are now covering the sixth edition from 2017.

While other models, like the Project Management Body of Knowledge (PMBOK; PMI, 2021a)
guide, provide what we could consider as a toolbox for the project operational manage-
ment and execution, PRINCE2® proposes a governance framework based on principles
inherent to the way any project should be conducted, themes that must be managed and
controlled, and processes that explain the actions and interactions throughout the project
life cycle.

1.1 History of PRINCE2®

Project management has existed for millennia; however, its formalization, terminology,
methodologies, and tools have been slowly developed, mainly within the last century. The
first iterative and incremental process for improvements were developed in the 1930s,
applying the Plan-Do-Study-Act cycle (PDSA; ancestor of the Deming wheel, PDCA). Tools
like Kanban, Gantt, Critical Path, and program evaluation review technique (PERT) were
developed in the 1940s–1950s, followed by the traditional Phased Project Planning (PPP)
in the 1960s, and the Waterfall model in the 1970s. The fast and flexible sequential
approach of Scrum rose in the 1980s, the PMBOK guide in the 1990s, and the more recent
Agile model was developed about 20 years ago (Săvescu, 2018, p. 301).

PRINCE2® was born in the United Kingdom from the project reporting, organization, and
management planning technique (PROMPT) method, which was originally developed in
1975 by Simpact Systems Ltd. for continuous project evaluation against the expected
results. Built for the development and support of information technology (IT) systems, it
covered strategic planning, system development, operations and maintenance, quality
assurance, and support tools.

16
Initially established by the British Central Computer and Telecommunications Agency
(CCTA), which then became the Office of Government Commerce (OGC) in 1980, PROMPT
was adopted by the UK government as a norm for all IT projects in the country. The
method was eventually replaced by PRINCE in 1989. PRINCE was applied to all British gov-
ernment projects, and since then it has demonstrated high effectiveness in managing vari-
ous projects in different environments, not only in IT.

As a result of PRINCE’s success, a second edition (PRINCE2®) was released in 1996 as a

generic project management methodology; nowadays, it is the standard for government
project planning and management in the United Kingdom. Since the original PRINCE2®
release, there have been several updates to the methodology (in 1998, 2005, 2008/9, and
2017), motivated by a concern for continuous improvement, universal adaptability, and
simplicity. It was initially perceived as very bureaucratic and aligned with the require-
ments of the public sector and non-governmental organizations, which quickly adopted
its structure. Since 2013, PRINCE2® has been applied to Agile. Today, it is a worldwide rec-
ognized standard, applied in both private and public industries by over a million certified
professionals.

You may encounter differences in the approach or terminology between what you learn in
this course book and the organizations in which you will work. It will depend on the
PRINCE2® version they apply, how it has been tailored, and the organization’s use of other
complementary methods.

1.2 Project Definition

First, what is a project? People tend to overuse the word “project,” so how do you differen-
tiate between a project, mission, desire, operational activity, and program? PRINCE2®
defines a project as “a temporary organization that is created for the purpose of delivering
one or more business products according to an agreed business case” (AXELOS Limited,
2017, p. 8), which must respond to the five criteria outlined in the next paragraphs.

Temporary

By nature, a project is limited in time and to what it is meant to deliver, with a definite
start and end, after which the temporarily assigned project team will be dissolved. An
objective of acquiring more clients, for example, is not considered a project if no deadline
or target are defined. A project, in this case, would be to undertake a specific promotion
with the aim of acquiring 10 percent more clients by the end of the year, for example. That
already strikes a difference from the continuous, long-lasting operational activities han-
dled by permanent teams. The use and maintenance of the project outcome will no longer
be part of the project but will be pursued indefinitely after the project closure. It is impor-
tant to note that, although we want to consider in the return on investment (ROI) analy- Return on investment
sis and the related maintenance and operational costs generated by the project after calculated ratio between
the monetary value of
delivery, we will not consider them as project costs, so, they will not be included in the expected benefits and the
project budget. investment costs, calcula-
ted as (profit – cost)/cost

17
 Cross-Functional

A corporate project typically requires different skills to produce project deliverables;

therefore, it brings together people from different departments or organizations who must
be coordinated and synchronized. The exchange of information between them is critical
for the success of the project.

Unique

Unlike a factory that makes pens every day, there are no two projects that are exactly
alike. Indeed, even though the same solution might be deployed, it will not be for the
same client or location, nor with the same project team, time, language, conditions, con-
straints, etc. This implies that, although we can use the experience as a reference to plan
and organize the project, there are differences, variables, uncertainties, and unexpected
changes that will have to be studied. Although producing cars is not a project but opera-
tions, investing in the development of a new ecological car (the outcome of which could
be the delivery of the first pilot) is a project.

Uncertain

For the same reason, while business-as-usual would typically run with well-known,
defined procedures by the same people who repeat the same activities, project unique-
ness generates many unknowns and uncertainties that must be controlled with strong risk
management.

Change

Whatever is delivered by the project, because it is unique, will generate a change, either
for the organization, the users, or the consumers. Since humans must adapt to changes,
good change management greatly contributes to the success of the project and the gener-
ation of the expected benefits. Moreover, since the effort and resources required to run the
project represent an investment, it is crucial for a business to ensure that the resulting
changes will offer more benefits than costs (or not doing it would generate more costs).
Business case That is why PRINCE2® requires a business case to be continuously reviewed to ensure the
the profitable justification justification of the project existence and completion.
and analysis for a project
proposal
Program

While PRINCE2® was developed to manage projects, the AXELOS Limited’s (2017) book
Managing Successful Projects With PRINCE2® also mentions how it works when the project
Program belongs to a program. So, what is a program? Commonly, a program in the project man-
a set of complementary agement world is a strategic objective that an organization is willing to reach and for
projects and activities
that support a common which several projects and activities must be undertaken, which can take several years. All
aim these projects and additional activities can be interdependent or independent from each
other, but they all support the same objective and have been considered in the program’s
return-on-investment calculations. An example of a program could be an organization that
would like to reach a certain ecological level within five years. They could change the type

18
of machines they use or their logistic processes, organize more home office time, encour-
age ecological behaviors from their employees, etc. All these initiatives could be under-
taken separately as independent projects, but they still contribute to the same goal.

A program can also be a project so large and complex that it is divided into sub-projects.
For instance, when a group buys another company, the project will most like be consid-
ered a program and be composed of a project to set up the physical infrastructure,
another project to manage all the IT topics, a human resources (HR) team to manage the
people transfer, and so on. Every team can work mostly independently, although they
would certainly need to exchange information, complete their part by the same official
transition date, and stay within the program budget. Therefore, they need to be coordina-
ted and synchronized at a higher level by the program manager.

In any case, the project must be aligned to the program objectives. The project manage-
ment team reports to the program management. Note that PRINCE2® is a framework for
projects only; programs are covered by other methods.

Project Management

Organizations face two simultaneous challenges: maintaining the business operations and
introducing changes to improve its exploitation, which lead to project management.
PRINCE2® breaks down project management into four types of activities, which constitute
an iterative cycle like the Plan-Do-Check-Act Deming wheel (Johnson, 2002):

• planning: forecast project activities, duration, resources, costs, deliverables, risks, and
benefits
• delegating: define roles, responsibilities, scope, and objective tolerances
• monitoring: supervise and measure the actual results in comparison with the agreed
plans, identify deviations, and communicate
• control: analyze, solve, decide, escalate, and adjust

PRINCE2® relies on six performance variables for project control: time, cost, quality, scope,
benefits, and risks. They are defined as expected targets and constraints for the project
execution and are aligned with the acceptance criteria agreed in the project product
description. Performance indicators can then be set and measured to evaluate the proj- Project product
ect’s health, comparing the actual progress with the planned objectives. It is also impor- description
defines the project deliv-
tant to understand which factors to prioritize and what the most flexible variables are for erable with the custom-
decision-making purposes. For example, if we cannot deliver by the expected date with er’s quality expectations
the available resources, is a delay acceptable? Or is the delivery deadline strict, but can and the acceptance crite-
ria
the costs be increased for more resources? Can the scope be reduced?

1.3 The Seven Principles

What makes a project a PRINCE2® project? Projects vary by their type, complexity, size,
criticality, and environment; PRINCE2® is flexible enough to be tailored to each of them
and to their organization. However, a few requirements must be followed for the project to

19
 be managed according to PRINCE2®. First, the seven PRINCE2® principles must always be
applied: continued business justification, learn from experience, defined roles and respon-
sibilities, manage by stages, manage by exception, focus on products, and tailor to suit the
project.

These principles are based on best practices, a kind of philosophy that must be applied to
successfully manage the project. Imagine following them as one might follow a set of spiri-
tual values in your life to be happier, like being respectful to yourself and others, showing
compassion, practicing self-reflection for continuous self-development, and so on. The
PRINCE2® guidelines serve a similar purpose for projects. These principles are character-
ized by the following criteria:

• universal: applicable to any kind of project, project manager, and environment

• self-validating: proven by the experience of many professionals over many years, in vari-
ous industries
• empowering: by providing strengths to the project manager to run projects with greater
skills and confidence

In versions of PRINCE2® up to 2009, there were no established principles, except that a

project should be managed with a formal start and end with a clear organization. The prin-
ciples explained below are described Managing Successful Projects with PRINCE2® (AXELOS
Limited, 2017, pp. 19–28).

Continued Business Justification

Before spending time, effort, and money on a project, it is essential to make sure that it is
worth it and that there is a profitable business case supporting it, i.e., that it will generate
more benefits than costs or less pain and expenses than if it were not executed. Indeed,
even for a supposedly mandatory project to comply with legal requirements, the organiza-
tion will still calculate how much it will cost to implement the requirements and compare
it to the cost of penalties if they are not compliant, as well as the probability of receiving a
penalty; if it costs more to implement it, they just might not do it and pay the cheaper fine.

Therefore, the first step before starting a project is to clearly understand its purpose and
ensure that the solution addresses the customer’s needs. Next, we identify the expected
constraints, and tangible and intangible benefits, analyze its viability by estimating the
related costs and revenues, and receive official authorization to start mobilizing resources
for the project.

PRINCE2® also requires documentation of the business justification, its formal approval,
and continual review by the project board. Given that changes are inherent to life, the ini-
tial business justification might not remain valid throughout the life of the project. This
could occur because of an inaccurate project forecast or because new challenges arose
(e.g., a competitor launched a similar product on the market earlier). To combat this, the
business case must be revised regularly, and the project board should not hesitate to stop
the project if it is no longer profitable.

20
Consider the Concorde effect (or fallacy; Arkes & Ayton, 1999). The supersonic Concorde
airplane had been evaluated as not economically profitable since 1973, but the French
and British governments elected to continue funding the expensive development of the
aircraft. There were political and legal reasons behind this decision but also the simple
fact that so much money had already been invested into the innovation, that they did not
want to give up. The idea that we tend to continue spending time and money on some-
thing to avoid wasting the investment that we have expended is called the sunk cost fal- Sunk cost
lacy. Nonetheless, when deciding whether to continue a project, we should not consider the money already spent
and that cannot be recov-
the expenses already incurred because they are already lost and only useful for calculating ered
the full ROI. Instead, we should focus on the money we could save by stopping the project.
PRINCE2® requires a justifiable reason for starting any project, its documentation, appro-
val, and continual assurance that it remains valid throughout the life of the project.

Learn From Experience

By nature, driving projects leads to acting outside the usual business operations, explor-
ing new ideas, and enhancing the existing; this makes a project unique. Nevertheless, that
does not mean that everything should be reinvented for each project. Quite the opposite:
Being able to draw on the history and experience to evolve managing projects is a power-
ful lever of performance for organizations. The purpose of this principle is to avoid repeat-
ing the same mistake. It covers lessons about both the project outcome and how to man-
age the project itself. Note that “lessons learned” implies that a change has occurred
thanks to the new knowledge, otherwise it would be referred to as “lesson identified.” This
principle takes place throughout the project life cycle, as explained in the following para-
graphs.

At the project start

Here, lessons from previous similar projects are collected and reviewed. It helps identify
the first challenges, risks, potential solutions, forecast estimations, the expected benefits,
and best practices. These lessons could either come from the project manager’s and
experts’ experience or be found in databases within or outside of the organization.

During the project

While executing the project, it is important to take the time to reflect, identify what is
going wrong or could be improved, and adjust it. Project management usually runs in an
iterative cycle for continuous improvement. Scrum includes a sprint retrospective step Scrum
before jumping into the next one to avoid working with the same errors or bad habits. an iterative framework for
product development
PRINCE2® incorporates this activity at the end of every stage.

Besides, as shown by Tuckman’s model (Tuckman & Jensen, 1977, p. 384), after a new Tuckman’s model
team is formed, there often is a storming phase when people get confused and frustrated There are five stages of
team development: form-
by misunderstandings or differences in how collaborators work. For this reason, it is a ing, storming, norming,
good practice to sit with the new team, supplier, or client after a few weeks to discuss performing, and adjourn-
what is going well, what is not going well, and how it could be improved. Like in any rela- ing.

tionship, this reflection and communication will help teams adjust and adapt to each
other, allowing for a better flow to the subsequent norming and performing phases.

21
 Throughout the course of the project, it is also useful to keep track of ongoing learnings in
the lessons log as they occur, instead of waiting to collect them at the end of the project in
the closure report since it is hard to remember what happened months or years ago.

At the project closure

The project closure assessment is a good moment to reflect again on issues, how they
were solved, and mistakes that happened and how they could have been avoided. It is
also useful to discuss the good practices that could be repeated in future projects. This list
of lessons must be recorded to facilitate its sharing and use by peers for other projects.
Ideally, the organization should possess a good database to store the lessons, although it
may be challenging to have a good search tool for it. What is precious and relevant infor-
mation worth if it is hard to be found? While anyone can identify a lesson learned, it is still
the project manager’s responsibility to ensure that it is recorded and shared properly.

Defined Roles and Responsibilities

A project is temporary and cross-functional, which implies that people from different
departments or organizations will temporarily form a project team with a dedicated man-
agement hierarchy. They can be fully allocated to the project or partially while still work-
ing on other projects and operational activities and reporting to their permanent line
manager. In this case, the project manager might not be perceived as a formal authority,
making their leadership role more difficult. This can generate conflicts of workload, priori-
ties, objectives, and interests, necessitating their clarification and agreement. Another
challenge is to identify who should be included in the project, which depends not only on
their skills but also their personality, interests, and level of authority. More importantly,
when someone is assigned a new activity, the main concerns should be addressed, e.g.,
“What am I expected to do? What can I expect from others? How will I be informed? Which
communication channels should I use?”

Thus, it is necessary to build a strong project team structure with clearly defined roles and
Stakeholder responsibilities that are agreed upon by everyone. Among all stakeholders, PRINCE2®
any individual or group requires that the following three primary parties’ interests must be well represented in the
who can impact, be
impacted by, or feel project management team, and particularly within the project board:
impacted by the project
1. Business refers to the financing organization that defines the project objectives and
constraints to ensure that it delivers the forecasted return on investment. It is typically
the initiating organization for internal projects, the client based on a mandate, or the
program to which the project belongs.
2. Suppliers are the experts and other resources necessary to design, develop, imple-
ment, and transfer the project products according to the specified requirements. Sup-
pliers can be both internal (e.g., design from marketing and development from IT) or
contracted externally when skills are not available internally or not worth using them
depending on the make-or-buy analysis results.
3. Users will make use of the project outcome or handle its operational maintenance to
generate the expected benefits. They will be involved, especially during the functional
analysis, to better understand the business needs from a functional point of view.
Users can be internal employees, client’s employees, or external consumers.

22
Manage by Stages

Have you ever felt lost before starting a huge and complex project, not knowing where to
start? It is easiest to address this by breaking the project down into smaller, more manage-
able steps. These phases are what PRINCE2® calls stages. PRINCE2® also uses this step-by-
step approach to avoid spending too much effort working on something that can change
or be canceled later. Indeed, since forecasts are rarely perfectly accurate and changes are
intrinsic to projects, PRINCE2® recommends planning the project globally at a high level
only, and planning in detail only the upcoming stage that offers the shortest perspectives.

Furthermore, dividing the project into parts allows us to better control its progress. When
delegating a long-term activity, a project manager would certainly not feel comfortable
just giving instructions, and a one-year deadline to complete the job, letting the worker
perform their tasks, and coming back a year later to see the result. Even with very high
trust, it is a good practice to organize periodic checks to ensure that the team can react
soon enough to any possible deviations. The more complex and riskier an activity, the
more regular the monitoring should be. Following this approach, the project board, who
supervises the project execution, delegates its day-to-day management to the project
manager, stage by stage. For each stage, the project board sets the performance objec-
tives, constraints, and the corresponding thresholds that limit the project manager’s
perimeter of autonomous action, responsibility, and decision-making power. The project
manager reports the stage progress status to their superiors regularly; at the end of the
stage, they provide a full assessment of the completed period with a request for approval
from the board to continue onto the next stage of the project. The assessment is also a
good time for the project manager to contemplate lessons from the accomplished stage
while planning the next one, as per the “learn from experience” principle.

These regular approval gates offer the opportunity for the project board to sit together,
assess the stage, verify the business case, and decide early whether the project is still via-
ble or if it should be stopped, as per the “continued business justification” principle (just
as a team climbing Mount Everest would need to go through regular medical check-ups
before continuing to the next stage of their climb). Consequently, stages are sequential.
They must not overlap but follow the logic that we should not waste effort if the project is
prematurely interrupted.

For example, take a project divided into the following phases: study, design, development,
tests, and transfer. It would be difficult to accurately estimate the development costs with-
out finalizing the selection and design of the solution. It is thus recommended to have a
first contract with external consultants for the study and design, finalize the planning as
part of the initiation stage, and request authorization to continue the project with the
revised budget. If approved, a new contract for the developments could be signed and the
project can be executed. Similarly, before deploying the new solution in production, tests
must be successfully completed and validated to avoid any negative impact on the busi-
ness. So, another approval milestone would be necessary at that point. However, it could
make sense to start documenting during the design phase, continue it during the develop-
ments, and finish it during the tests before going live. This raises the question of how to
optimize the project plan and time if activities are grouped by distinct stages? A draft

23
 could be included in the initiation stage and the documentation could be completed part
by part during the subsequent stages, for example. See the following proposal, where the
product scope has been divided in groups A, B, and C:

• stage 1 initiation (January 10–March 5): study, design, planning, documentation draft
• stage 2 (March 6–April 20): development of groups A and B, complete documentation of
groups A and B
• stage 3 (April 21–May 30): development of group C, technical tests of groups A and B,
complete documentation of group C, draft training manuals
• stage 4 (May 31–July 4): technical tests of group C, functional tests, complete training
manuals
• stage 5 final stage (July 5–October 5): product and training delivery, support and serv-
ice, project closure

It should go without saying that it is not always relevant to manage pieces of work so
strictly. It might make sense for some groups of activities, but it could also lose valuable
time that could be triggered earlier for others. You might want to deviate from PRINCE2®
restrictions sometimes to find the most appropriate structure according to the nature of
the project, phases, and activities, but it should be with the agreement of your project
committee.

According to PRINCE2®, there must be a minimum of two stages: one for the initiation and
planning and another for the execution, delivery, and closure. If the decision is to stop the
project after its initiation, another stage will still start to complete the possible open tasks
and formally close the project.

Manage by Exception

Manage by exception is based on the principle that the senior management delegates the
project management and intervenes only in case of exceptions. So, what is an “excep-
tion”? As just seen, the project board delegates the day-to-day project management to the
project manager defining not only the stage performance objectives and constraints but
also a range of tolerances, within which the project manager has an autonomy of action
Authority and authority for each stage. PRINCE2® calls an“exception” any issue that would occur
the ability and right to and whose impact exceeds (or is forecasted to exceed) the stage objective thresholds. In
make decisions, apply
resources, accept deliver- such a case, the project manager would escalate it to the project board.
ables, and influence oth-
ers This approach helps time management efficiency by lowering the high-level manage-
ment’s workload while still enabling the right levels of control and decision-making power
according to the relevant hierarchy layer. The project manager will not contact the project
board every time something happens in the project, only when necessary. This need is
defined by the objective tolerances. There are four PRINCE2® levels of management, as
explained in the following paragraphs.

24
Corporate management

The first level is the financing organization, the mandating customer, or the program that
sets the performance objectives and the related tolerances in terms of cost, time, quality,
scope, risks, and benefits for the whole project.

Project direction

The project board supervises the project progress and makes decisions within the thresh-
olds established by the corporate management, the customer, or the program. If the
project deviates from these boundaries, the project board escalates the “exception” and
its recommendations to its hierarchy, which will make the necessary decisions. Likewise,
the project board approves the performance objectives and tolerances in terms of cost,
time, quality, scope, and risks at the stage level, which are aligned with the global project
objectives. Benefits are not included at the stage level since they are typically generated
after the project delivery, except when combining it with the concept of Agile incremental
delivery. Incremental delivery
piece-by-piece product
delivery to the customer
Project management instead of all at once

The project manager is accountable for managing the respective stage. Should a deviation
from the stage tolerances be identified, they escalate the exception to the project board.
As for the project manager, they define the team manager’s objectives and tolerances in
terms of cost, time, quality, scope, and risks for each work package delivery, in alignment Work package
with the stage objectives. description of the work
that an individual or a
delivery team has to pro-
Project delivery duce during a stage

The team managers lead the project operations and report to the project manager every
issue that has an impact on the work package objectives. Let us take the example of a
team that is struggling to build the required camera lens during the development of a new
smartphone. In the weekly work package checkpoint report, the development team man-
ager informs the project manager of the problem that this has already taken one more
week than expected. The delay can still be compensated for by other tasks they can com-
plete in parallel, but all will depend on how much more time they would need and the
solution they would find. The project manager registers this issue and reports it to the
project board in the stage highlight report for their information. One week later, the team
manager notifies the project manager that they have finally found a solution, but they
need a special tool to make it, which costs €1,000, and two more weeks to develop it –
which would cost an additional €5,000 of effort. The project manager calculates the
impact on its stage objectives:

25
 • time: The stage was supposed to be finished by May 30 with one week of acceptable
delay. But the forecasted two-week delay, plus the risk that the required tool is received
up to 10 days later due to the purchasing process, would make the stage delivered with
14 to 24 days beyond the deadline.
• costs: The stage budget was €10,000 with five percent tolerance, i.e., €500. The addi-
tional costs for the tool and consultant charges are €6,000.
• scope and quality: If the proposed solution is rejected, the scope and quality objective
would not be reached, which would make it impossible to generate all the benefits that
the organization was expecting.

As a result, the project manager prepares an exception report for the project board. The
board realizes that the exception goes beyond the tolerance granted for the whole project
costs, fixed at 10 percent for the approved budget of €50,000, i.e., €5,000. Thus, they need
to escalate the exception to the executive committee, which will decide whether to raise
the budget and implement the required solution or stop the project if the expected bene-
fits do not cover so much effort.

Focus on Products

Another best practice is to first focus on understanding what should be produced and
delivered by clarifying the customer needs, requirements, and expected quality before
planning any activities, as recommended by PRINCE2® with product-based planning. The
project outcome, called the project product, and its components are described in the
product descriptions. These specify its purpose, composition, derivation, format, quality
criteria, and quality method. The objectives of this principle include the following:

• to reduce the risk of user dissatisfaction and acceptance disputes by agreeing before-
hand what will be produced by the project, as well as the constant quality controls of
the deliverables
• to manage uncontrolled changes, called scope creeps, by formalizing the validated
Requests for change scope and approving requests for change depending on their impact on the project
a proposal of requirement products and the business justification
that was not in the
approved project scope • to ensure that the project team only works on what is necessary based on the defined
project scope

Tailor to Suit the Project

PRINCE2® proposes many best practices that can reinforce the success of the project.
However, not everything must be applied exactly as described: The model can and must
be tailored to the project environment, size, complexity, importance, corporate gover-
nance, legal regulations, resource capabilities, risks, and other applied methods.

From the beginning of the project, the project manager and board agree on how the
Project initiation docu- project method will be adapted. They describe it in the project initiation documenta-
mentation tion(PID). The key is to find the right balance between a sufficient level of project control
This is a reference folder
or file that contains all the and a low level of additional workload. It should always add value to the project manage-
project method definition ment while remaining simple so that it can be understood and used by everyone. After-
and planning, approved
by the project board.

26
ward, the project team will need to be trained on the communication channels, how to
use the tools, filling in the template, and so on. For a project to remain a PRINCE2® project,
a few points must be maintained in its adaptation:

• The seven PRINCE2® principles must be applied.

• The seven themes should be managed with the same aim and include the minimum
PRINCE2® requirements.
• Process activities may vary as long as they support the same process purpose.

1.4 The Project Management Team –

Structure and Roles
Every corporate project is confronted with resource and organization challenges. For
every new project, a temporary team is set up with a structure that should be clear and
relevant enough to make communication and the decision-making process efficient.

Even though PRINCE2® is suitable for any kind of project, it has been designed for com-
mercial relationships with a mandating customer and one or several contracting sup-
plier(s). Roles are explained in AXELOS Limited’s book (2017, pp. 13, 58–71, 337–348). If the
project is made in-house, consider the customer as the paying department – perhaps the
human resources department, which needs to improve its HR system, is the customer, and
the supplier(s) create the products. In this case, it could be the IT team. The customer is
responsible for

• financing the project;

• specifying its needs, the expected deliverables, the quality requirements, and associ-
ated acceptance criteria;
• defining the desired and foreseen benefits;
• validate and accept the provided deliverables; and
• realizing the benefits with the right use of the project products.

The supplier is responsible for

• guiding and advising the customer,

• accepting the specifications,
• providing the necessary resources, and
• producing the required deliverables in compliance with the specifications.

PRINCE2® recommends a project management team structure that can defend the inter-
ests of all stakeholders. The right people with adequate experience and level of authority
need to be in the appropriate roles, in the relevant numbers, and at the right time. The
below scheme represents the recommended structure of hierarchy, responsibilities, and
accountability of the project management team. Responsibility versus
accountability
The responsibility is the
assigned duty and task
that someone is expected

27
to perform. The accounta- Figure 1: Project Management Team Structure
bility is the ultimate own-
ership which must answer
for the result and conse-
quences.

Source: Caroline Naudin (2022).

In real life, you will hardly find so many roles individually assigned and assumed, notably
due to a lack of availability, engagement, and support from the senior management and
operation teams. This is one of the root causes of project failure globally. Moreover, for
small projects and organizations, a concern is how to fulfill all PRINCE2® responsibilities
with the fewest people possible. The project organization must be adapted to the project
size and complexity, as well as the people’s capability and level of authority. PRINCE2®
roles should not be eliminated, but they can be combined as long as it does not generate
any conflict of interest, as per PRINCE2® rules.

The Project Board

Also known as the steering committee, the project board directs the project on behalf of
the three major stakeholders: business, users, supplier(s). Applying the “manage by excep-
tion” principle, it delegates the day-to-day project management to the project manager
but remains accountable for its overall success or failure. Board members should have
enough authority, credibility, and availability to execute the following responsibilities:

• authorize the project start, the initiation stage, the management stages, and the project
closure
• approve the baseline documents (project brief, project initiation documentation, and
plans), as well as contracts, exception requests, requests for change, and finalized deliv-
erables in compliance with the acceptance criteria
• guide and advise the project manager
• communicate with external stakeholders

28
They can also assume or delegate the roles of project assurance or change authority. It can
happen that the project board members do not understand their role and do not provide
the project manager with the required support. PRINCE2® requires that each member
understands the objectives, the importance and the benefits of their role and responsibili-
ties.

The Executive

The executive presides over the board and is a business representative of the corporate,
program management, or customer. They should not only be the major support of the
project manager but also the main project promoter and ambassador, who is, incidentally,
the ultimate person accountable for the project success. Indeed, the executive should be
the main interested person in realizing the project and, as such, in finding the right argu-
ments to obtain the necessary financing (or requesting more budget in case of excep-
tions). As a consequence, the executive is responsible for the business case and the fol-
lowing duties:

• designate the project manager and the project board

• guarantee that the project remains a valuable and viable investment, and that the
expected benefits are realized after the project delivery, so the executive is the contract
signatory
• chair the project board meetings and be the final decision-maker in case of disagree-
ments among the project board
• supervise the development of the project brief and the business case, as well as the
project progress from a strategic perspective
• communicate with the executive committee, program manager, and customer

As for any accountable role, there should be only one executive to avoid confusion in dis-
tributing responsibilities. Nonetheless, as the executive and the senior user can both
come from the financing organization, the roles can be combined. And, as mentioned ear-
lier, the executive can assume or delegate the project assurance role, called business
assurance in this case, and the change authority.

Unfortunately, the KPMG Project Management Survey (2017) shows that “48% of organiza-
tions do not always have an effective and actively engaged [s]ponsor” (p. 20) while highly
engaged executives are the number-one driver of project success. Executives play a critical
role in aligning the corporate strategy and project execution. They enable communication
and collaboration, more particularly when there are conflicts of priorities and resource
availability within the organization.

The Senior User

The senior user represents the interests of all who will use and operationally maintain the
project deliverables. Since they can come from different departments, countries, or even
organizations, there can be several senior users within the project board; however, the
more people there are, the more differences there may be, so it is best to keep it limited to
the minimum number of representatives possible, usually no more than three. Their main
activities include the following:

29
 • specify their needs, expected benefits, functional and quality requirements, and accept-
ance criteria, and perhaps provide key user resources to feed the analysis or perform
the functional tests
• resolve the conflicts and priorities among user requirements
• verify and validate the quality of the deliverables according to the agreed criteria
• ensure the good use of the project products to generate the expected benefits and
reach stable productivity, thanks to efficient change management

They can also assume or delegate the role of user assurance and change authority.

The Senior Supplier

The senior supplier defends the interests of those who design, develop, and implement
the project products. Since there can be different internal or external providers, each can
be represented separately within the project board. Accountable for the product quality,
the senior supplier(s)

• study the feasibility and viability of the project approach and the products to be cre-
ated.
• provide available resources.
• ensure that quality procedures are properly followed, and products are created in com-
pliance with the requirements and quality criteria.
• resolve conflicts and priorities among the delivery team, as well as the occurring issues
incumbent upon their area.

They can also undertake or delegate the role of supplier assurance and change authority.

The Project Manager

The project manager has the authority to manage the project, stage by stage, and is
accountable for each one of them. The main functions include

• defining the project approaches tailoring PRINCE2®, preparing most of the project docu-
mentation, the management of products, and keeping them updated.
• planning the project globally and each stage in detail and authorizing work packages.
• establishing project controls through monitoring and reporting.
• informing the stakeholders of the approved plans and any deviation from them.
• leading, coordinating, and motivating the project team.

The project manager and the executive should not be combined since the former repre-
sents the delivery team, while the latter defends the business interests. However, the
project manager can take on the role of project support, team manager, and potentially
the change authority but within the same limits of authority already delegated by the
project board.

30
The Project Support

Delegated or performed by the project manager or by a project management office (PMO),

the project support provides the following assistance to the project manager:

• advise and instruct on project management tools, procedures, and standards

• store project files and keep some of the registers up to date
• collect data from the delivery teams and help with the analysis and forecasting
• organize meetings and the quality review
• administer the configuration management and change control, product versioning, Configuration
and the change budget management
tracking of all product
changes and versions
Since it can be the project manager themself, the project support can neither be com-
Change control
bined with the executive nor with the project assurance.
a procedure to identify,
assess and approve prod-
The Project Assurance uct changes

Delegated or performed by the project board, the business assurance, the user assurance,
and the supplier assurance cover the interests of their respective party. In small organiza-
tions, the members of the project board are closer to the project and are, thus, in a good
position to cover the project assurance role themselves. They serve as audit over the
project management and, as such, they must remain independent from the project man-
ager and project support to realize their duties:

• advise the project manager on the management approaches, in alignment with the
organization’s policies
• monitor the project performance, the stage progress, the risks, and all the procedures
to be followed as defined in the PID
• verify the business case, product descriptions, deliverables, issues, and requests for
change
• ensure that the customer needs are satisfied, the solution is acceptable, the scope is
respected, the roles are adequate, the risks are controlled, the communication is
applied properly, and the quality review and the changes follow their procedure

Often confused with the project assurance, there is a PRINCE2® role called quality assur-
ance that is not part of the project team. It is a permanent structure within the organiza-
tion that owns the corporate standards, norms, procedures, and tools to be applied in
terms of quality. It should ensure that the project manager applies its governance when
defining the project management approaches, and, more particularly, for the quality man-
agement approach. Often the quality assurance is handled by the compliance, quality,
health, safety, security, and environment teams, or by the project management office.

The Change Authority

Delegated or performed by the project board, the change authority reviews and approves
the requests for change and the off-specifications, within the approved change budget. Off-specifications
an in-scope product that
is missing or not meeting
its specifications

31
 There can be different levels of change authority delegation, assumed by different people,
depending on their level of responsibility and the severity of the change. Here, the same
logic that is applied to the “manage by exception” principle is applied. For example, the
project support can agree with the team manager on a change if its impact is negligible
enough. If the issue is more significant, they would escalate it to the project manager, who
could approve it if its impact does not exceed the stage thresholds; otherwise, the project
manager must escalate it to a higher level: the change authority or the project board itself.

The Team Manager

The team manager leads one of the delivery teams. As such, they are accountable for pro-
ducing the work packages defined by the project manager in conformity with the required
timeline, costs, and quality. For a simple project or a small team, the project manager can
carry out the team manager responsibilities, or even more if they have the specialist
knowledge for it:

• plan, coordinate, and monitor the team’s work (the team plan is submitted to the
project manager for approval)
• provide the project manager with the checkpoint reports with the progress status, the
finished products, and recommendations for the management approaches, risks, and
issues
• maintain the quality register with the right entries
• communicate with the project management team and the delivery team

1.5 Management Products and Specialist

Products
PRINCE2® differentiates two types of products: the “specialist products” that the project
delivery team produces and will hand over to the business as usual, and the “manage-
ment products” that are created and used to plan and manage the project itself (AXELOS
Limited, 2017, pp. 289–332).

Management Products

The management products are categorized into three groups, as explained in the follow-
ing paragraphs.

Baselines

This is the reference documentation, in which it is defined and described how the project
will be managed. They must be approved by the project board (except the team plan and
the work packages), but they can evolve during the project life, undergoing change con-
trol. In such a case, the project board will validate the changes and the document will be
referred to as a new version and tracked thanks to the configuration management. The
latest version is the unique source of information for the project team and the reference to

32
evaluate the project in comparison with the actual project progress and events. The base-
lines cover all the definitions, descriptions, and plans: it includes the project brief, the
business case, the project initiation documentation (that includes the change control
approach, the communication management approach, the product description, the
project product description, the project plan, the quality management approach, and the
risk management approach), the benefits management approach, the stage plan, the
team plan, and the work packages.

Records

These are dynamic lists of items managed daily and regularly updated while new ones are
identified or modified. These working documents are centralized and shared with the
project team: the daily log, the issue register, the lessons log, the quality register, the risk
register, and the configuration item record.

Reports

These are snapshots showing the progress status of an element at a specific moment: the
checkpoint report, the highlight report, the end project report, the end stage report, the
issue report, the exception report, the lessons report, and the product status account. A
deviation issue from the baseline plan will be registered in the issue register and devel-
oped further in an issue report to be formally submitted for decision.

The terminology can be modified to the corporate language; the management products
are not necessarily physical or electronic documents. PRINCE2® leaves the freedom to
select the most appropriate format and “tailor to suit the project,” by means of a meeting,
a recorded call, a video, an application, or a database, for instance. Besides, the manage-
ment products can be combined into one document, system, or meeting. For example, a
project manager can create list on the cloud to manage both issue and risk logs together.
They can also be split so that each team manages their own items separately. Some prod-
ucts may not be used in all projects, depending on the need and relevance, like the config-
uration item record, the lessons report, or the product status account.

It is all these recommended management products that gave PRINCE2® the fame of being
bureaucratic. But again, management products must be tailored to the project. Overall,
why is documenting or tracking useful? First, it is the opportunity to sit and reflect, which
helps us brainstorm further, develop, and clarify ideas while trying to express and struc-
ture them to make them understandable to everyone. Then, how can we remember every-
thing if we do not take note of it? That which is documented can easily be shared with
stakeholders or with a backup person who needs to take over the job; lessons learned can
be exploited much later after the project closure. Moreover, formalizing decisions and
agreements can avoid or solve potential conflicts. And finally, providing efficient forms
and templates makes people and meetings more productive by synthesizing the relevant
information.

33
 Specialist Products

The specialist products are the outputs of the project intended for the operation teams
(users and maintenance) to realize the benefits for the customer. They refer not only to the
final product but also to all its components. Designed, developed, and delivered by inter-
nal and external supplier(s), they vary for each project, so there is no standard that can be
shared about it with PRINCE2®. It is better to use the experience of your specific industry.
Examples of specialist products are the pilot of a new electric truck, its engine, the wheels,
the digital screen, the instruction manual for the production team, the launching cam-
paign for the marketing, and the promotional brochure for the sales team. Following the
“focus on products” principle, PRINCE2® has devised the “product-based planning” tech-
nique to plan the project from the customer’s and user’s perspectives and which adheres
to the following steps:

1. First, understand the customer need and define the global project product to be built
in the “project product description,” where all the functions and quality requirements
with the acceptance criteria and method are detailed.
Product breakdown 2. Next, design the product breakdown structure(PBS), a hierarchy of all the product
structure components to be developed during the project.
an organigram of all the
items that compose the 3. Third describe each of these items in the product descriptions, including its purpose,
project outcome composition, derivation, and quality criteria.
4. Finally, sequence these elements in a product flow diagram to understand the order
of production and interdependencies.

Only then can the activities needed to build the product and the corresponding estima-
tions of effort, time, and costs to put in a plan can be derived. This will lead to the work
packages provided from the project manager to the delivery teams. How a project is plan-
ned and executed depends on the nature of the project and the products to be delivered,
so PRINCE2® does not provide techniques to accomplish this. PRINCE2® is a framework for
the overarching management of the project.

SUMMARY
PRINCE2® is a flexible method that compatible with any kind of project,
management method, and environment. It is based on seven principles
that orient the way the seven project objectives should be managed
through the seven processes that compose the project life cycle.

This framework ensures that the project is launched with a viable, sus-
tainable justification, supported by a well-structured organization that
can monitor and control the project efficiently, stage by stage. Its pro-
gress is regularly reviewed and compared with the approved baselines,
and every deviation or issue undergoes a well-defined change control
procedure through different levels of escalation, in which the business
case is constantly reexamined.

34
The complex project team, where each role has a valuable perimeter of
responsibilities, works with a recommended set of specific management
products to ensure that the specialist products are delivered within the
project objectives to meet the customer’s needs and generate the expec-
ted benefits. This gathering of best practices gives clear guidelines to
define the right approaches that can help manage the different themes
throughout the project life cycle.

35
 UNIT 2
THE SEVEN THEMES

STUDY GOALS

On completion of this unit, you will be able to...

– summarize the seven PRINCE2® themes.

– implement a PRINCE2® project management team.
– define the project management approaches.
– apply project management techniques related to the themes.
 2. THE SEVEN THEMES

Introduction
In a school environment, PRINCE2® would be the equivalent of the guidelines defined by
the national education board. The PRINCE2® principles would be like the school behavior
rules that each pupil should follow to ensure a good school life, education, and exam suc-
cess: daily attendance, working hard, listening, respect for each other, etc. The school ten-
ure starts with a specific procedure for the child’s registration, and then every school year
is designed with similar steps, except the final exams which follow a specific process to
show whether the student can proceed to the next grade, and so on until the end of their
education. This is very similar to the PRINCE2® processes and stages throughout the
project life and the stage approval gate mechanism.

Based on decades of education around the world, governments know which disciplines
every child should learn for full instruction: reading, writing, calculating, physical exercise,
and so on. Tests are given regularly to assess the learning progress of each subject. That is
what the themes in PRINCE2® are: the topics to be worked on and frequently reviewed
throughout the project life cycle. The content and approach of every discipline depends
on each teacher, just as every project manager will manage the themes differently.

2.1 Introduction to Themes

Omnipresent during the whole project, the seven themes are areas of know-how that
define the following:

• business case: why we do the project, how viable and feasible it is, and what benefits it
should generate
• organization: who does what, what the roles and responsibilities are of the project
team, who the project stakeholders are, and how to deal with them
• quality: what should be produced, according to which requirements, and how to ensure
quality
• plans: when and how to do it, and how much time, effort, and cost it will take
• risks: “what happens if,” and how to manage uncertainties
• change: what are the new needs and issues, what their impacts are, and how to accept
or solve them
• progress: where are we, how to control, and what next

There used to be eight themes, called “components,” but since the 2009 PRINCE2® version,
the component “configuration management” has been included in the “change,” and
“controls” has been replaced by “progress.” There used to be a whole section for techni-
ques too, but they are now only recommendations embedded within the themes. Change
control has incidentally been dropped as a procedure within the “change” theme. In the
following, the seven themes of the AXELOS Limited’s 2017 version will be discussed.

38
During the project initiation, the project manager defines and plans, in the “approaches”
(previously known as “plans” and then “strategy documents”), how the themes will be
handled, executed, monitored, and controlled according to PRINCE2®’s described purpose
for each theme. They are then managed and controlled in the processes, and the princi-
ples are put into practice. This includes the roles and responsibilities that must be defined
for every theme, as well as the lessons learned for continuous improvement.

Some themes are more critical depending on the project matter and phase, but they are
interrelated. While they can be tailored to the project and its environment, they all must
be covered and maintain the same purpose and apply the minimum requirements sugges-
ted by PRINCE2®. In this unit, we will first define each theme, explain what aim we want to
reach by managing them, and give the PRINCE2® requirements. Additionally, the
PRINCE2® management cycle or a typical procedure is described for each theme, and a
few useful techniques are provided, although they do not belong to the PRINCE2® frame-
work (AXELOS Limited, 2017, pp. 41–156).

2.2 Business Case

Supporting the “continued business justification” principle, the business case is an analy-
sis that explains the project’s reason for being, and how worthwhile and achievable it is. It
must fulfill three criteria:

1. Desirable. A project’s desirability is portrayed by presenting the context, the problem

to solve, the need to satisfy, or the opportunity to seize. It is also important to identify
how profitable it would be for whom, or who the targeted consumers are who would
be willing to pay for it.
2. Viable. A project is viable if it has a profitable balance of long-lasting benefits that out-
weigh the investing costs and time, while possessing the treasury or financing to
cover the expenses. In this return on investment (ROI) calculation, not only the costs
to run the project (which constitute the project budget) are included but also the
operational costs that the project outcome will generate (maintenance, staff salary,
licenses, etc.).
3. Achievable. By knowing that there can be a feasible solution and by considering the
major risks that could prevent the project from completion, can we determine a proj-
ect’s achievability.

The confirmation of the business case consists of selecting and implementing objective
measures of the costs and benefits. PRINCE2® calls “deliverables” the project products or
output. Its use generates a change result, called the outcome, with a quantifiable
improvement, which are the benefits. Any predictable negative side-effect is called a dis-
benefit. If the implementation of the 5G technology in the US is a project output, an out-
come would be a new high-speed bandwidth for the Internet of Things (IoT), a benefit
could be a gross domestic product (GDP) increase of $1.3 billion, and a known dis-benefit
is the temperature rising on biological tissues. Benefits can be tangible or intangible,
financial or not, but should always be

39
 • mapped with the project output and resulting outcome they derive from;
• assigned to someone who can guarantee its achievement;
• measurable, so they can be confirmed once realized;
• quantified with specified tolerances; and
• aligned to the business strategic objectives.

Purpose and Requirements

PRINCE2® states, “the purpose of the business case theme is to establish mechanisms to
judge whether the project is (and remains) desirable, viable and achievable as a means to
support decision-making in its (continued) investment” (AXELOS Limited, 2017, p. 46).

The project management team must define tools, techniques, and criteria to assess the
project value, as well as a procedure that will ensure a regular review in line with the prin-
ciple “continued business justification.” The business case is mandatory for every project,
even when compulsory for legal reasons.

The project executive is accountable for aligning the business case with the business strat-
egy and for ensuring benefits with the support of the senior user. Indeed, the latter is
responsible for specifying the expected benefits, and then they must guarantee a good use
Management product of the project product to be able to generate them. Two management products are
created by the project required by PRINCE® for this theme:
management team to
define, plan, and manage
the project 1. The business case: Apart from being a theme, the business case is also a management
product, formalized in a document or any other format, that recaps the project con-
text, the business need, the estimated project and additional operational costs, the
expected benefits and dis-benefits, the major risks, the relevant timeframe, the scope,
and its constraints.
2. The benefits management approach: This specifies the expected benefits and the
actions that will be implemented to realize the project outcomes. It is the only man-
agement product that remains open after the project closure because it will be used
to later confirm the benefits delivered after the project completion.

Take, for instance, a food and beverage company that has made a program as a strategic
priority to consolidate several of their legacy applications into one system. No budget has
been fixed for the whole program, and the benefits have only been listed but not quanti-
fied. Projects were ongoing for years with an open budget and the adjusted costs and time
to every occurring issue and change. After five years and spending billions, the executive
board wanted to finally see some results and forced the team to hasten the deployment of
the first pilot. It resulted in a disaster. The sales and logistic processes were failing in the
whole pilot country – one of the major markets – and they lost thousands of customers
and millions of euros. They persisted in completing their program, but years later, they still
had not recovered from their investment. All project managers of the program had to fol-
low a training in project management, but the major mistake came from the program and
the corporate governance that did not quantify and confirm any business case.

40
Management Cycle Governance
a set of systems, pro-
cesses, and mechanisms
The life cycle of the business case can be defined in four steps: by which an organization
and its people operate,
communicate, are con-
1. Develop: At the pre-project phase, and while starting up a project process, the busi- trolled, and held to
ness case outline is drafted based on the mandate and detailed during the initiation. account
It is then included in the project initiation documentation (PID) and submitted for
approval to the project board, together with the benefits management approach.
2. Verify: The project board assesses whether the business case is and remains viable,
desirable, and achievable at the end of every management stage and every time an
exception is raised, as changes can impact the business case validity.
3. Maintain: During the project execution, the project manager must regularly review the
business case and maintain it. Documentation occurs when an issue arises and while
managing a stage boundary, as well at the end of the final delivery stage to compare
the project performance against the initial plan.
4. Confirm: Benefits will be measured as soon as they begin and until the end of the
agreed post-project period to be able to compare it to the business case baseline and
validate the investment results. The accountability for the benefits moves from the
executive to corporate, the program management, or the customer as the project
closes. In some projects, benefits may be realized after some incremental deliveries to
the customer before the project ends.

Techniques

Described below are practical project management tools that can support PRINCE2®
objectives.

SMART objectives

While defining the customer needs, the related functional requirements, and the accept-
ance criteria, a best practice is to formulate SMART objectives. The meaning of the acro-
nym has been modified with time, context, and translation, but the most common and
useful definition for project management is

• specific: one clear and precise objective that describes the uniqueness of the project,
the general scope and priority
• measurable: define quantifiable indicators that can be measured to confirm the objec-
tive performance
• achievable: feasible in terms of available resources, knowledge, technology, time, and
budget, and can be validated by both the customer and supplier
• relevant: respond to a determined problem or need
• time-bound: fix a deadline to achieve the goal, first to confirm that the desired period is
both relevant and achievable, but overall prevent delays or postponement

41
 An example of SMART goals could be the following: A contract has been signed (achieva-
ble) to produce a first pilot of a 20 m3 (measurable) electric truck (specific) with a mini-
mum autonomy (specific) of 800 km (measurable and achievable) compatible with all
European countries (specific), by end of 2025 (achievable time-bound), as needed by the
transport industry to comply with the new ecological norms (relevant).

Cost–benefit analysis

Before making a decision or taking action, everyone consciously or unconsciously deter-

mines the balance between the expected benefits and the required effort or potential loss
(of money, time, image, and friends etc.). When we fail in our decision, it is usually due to a
lack of information or because we failed to consider certain factors. Some organizations
have policies on how to build and calculate the business case and related ROI. A cost–ben-
efit analysis can also be performed by taking the following steps:

1. Define the problem or opportunity.

2. Identify several possible options, including the scenario of doing nothing.
3. Analyze the impact of every option, cost, and benefit (direct and indirect, tangible and
intangible, short term and long term), further risks and opportunities, productivity,
corporate image, environmental impact, and so on.
4. Determine which costs and benefits should be considered; remember to include both
the project costs to realize the output, and the through-life operational costs for run-
ning the business and maintaining the product after the project closure.
5. Select comparable measurement indicators (monetary, volume, etc.)
6. Estimate the value of the identified impacts.
7. Perform a sensitivity analysis to adjust the forecast depending on different scenarios
and variable factors.
8. Calculate the cost–benefit ratio (CBR) with the formula

P resent value of benefits

CBR = P resent value of costs

9. Select the most profitable option, i.e., the greatest one above 1 (a ratio inferior to 1
would mean that it costs more than brings benefits, and is thus not worthwhile).

2.3 Organization
The theme organization includes the composition of the project team structure, support-
ing the “defined roles and responsibilities” principle, and managing the stakeholders.

PRINCE2® defines the term “stakeholders” as “any individual, group or organization that
can affect, be affected by, or perceive itself to be affected by, an initiative” (AXELOS Limi-
ted, 2017, p. 58). External or internal to the project and to the organization, the stakehold-
ers must be identified from the very beginning of the project to understand as soon as
possible who should be included in the team, who should be interviewed to identify the
requirements, and how to plan all the interactions and communication.

42
Within the project team, PRINCE2® distinguishes three levels of management, among
which, clear governance is set up to limit the perimeter of authority of each level, follow-
ing the principle of “manage by exception.”

Delivering

The delivery teams, headed by team managers who report to the project manager, pro-
duce the work packages. It is constituted of all the specialists who analyze, design,
develop, and implement the project products. It is a major challenge to find available indi-
viduals with the right skills, authority, and adequate personality profile for the team. They
can be found within the organization or contracted externally, depending on their availa-
bility and costs.

Managing

The project manager, who reports to the project board, is responsible for the day-to-day
operational management of the project, with the help of the project support. The project
manager is under the supervision of the project assurance.

Directing

The project board, accountable for the success of the project, represents the three main
groups of interest: the business by the executive, the users by the senior user(s), and the
suppliers by the senior supplier(s). They can also carry on or delegate the roles of project
assurance to supervise the project performance and change authority to approve upcom-
ing scope changes. They report externally to the corporate committee, program manage-
ment, or customer. External to the project, there are many types of stakeholders, including
the following:

• corporate organization: program, or customer

• within the organization: departments impacted by the project or that own information,
standards, procedures, and tools to be considered in the project
• end-users: operation teams, employees, consumers, and population
• external environment: public authority, government, society

For a waterpark group that wants to open a new park center, we can envisage the follow-
ing stakeholders:

• The corporate executive committee represents the group financing the waterpark.
• The executive could be the head of business development, the most interested individ-
ual in seeing this project happen.
• The senior user could be the head of sales or marketing, who best understands the cus-
tomers’ requirements.
• The senior supplier could be the head of operations internally, or the account manager
of the building firm externally.

43
 • Other stakeholders within the organization could be the legal department, who helps
with contracts and possible judicial challenges; the health, safety, and environment
(HSE) department, which owns all the compliance norms to be applied; the finance and
accounting departments; or the line managers of the project resources.
• External stakeholders include the future park visitors as major consumers, the govern-
ment that owns national regulations, the local authorities that grant building authoriza-
tions and offer financial support, the ecologists or the local population who might fight
against the project if it threatens their values, the competitors who can threaten the
expected project benefits, local economy actors who can benefit from park visitors, etc.

A stakeholder analysis is performed to identify the major stakeholders. It is recommended

to record them with a description of their function, whether they are internal or external to
the team or organization (which will influence the level of confidentiality), the overall
impact they could have on the project, and their expectations and concerns. These items
must be clear; while the executive committee wants transparency on the project progress
and budget, team members want a clear vision of what they are expected to produce, the
health and safety team wants to ensure that all the quality norms are fulfilled, and the
local inhabitants do not want to see their environment ruined by the new infrastructure.
Based on this analysis, the team can proceed with developing the communication plan.

Purpose and Requirements

PRINCE2® states, “the purpose of the organization theme is to define and establish the
project’s structure of accountability and responsibilities” (AXELOS Limited, 2017, p. 58).
The idea is to implement strong governance, allocating all PRINCE2® management roles
clear responsibilities, as well as the assigned delegations and their limit of authority. The
organization must be suitable for the size, scale, and complexity of the project; its tailoring
must respect the following rules:

• The executive is the only accountable person for the project success.
• The executive and project manager roles cannot be combined.
• There cannot be more than one executive nor more than one project manager.
• The project assurance roles cannot be combined with the project manager, team man-
ager, nor project support.

Two management products are required by PRINCE2® for this theme and created during
the “initiating a project” process:

1. The PID, which includes the team organization structure with the roles and responsi-
bilities of every member
2. The communication management approach, most commonly named the “communi-
cation plan,” which describes how the project team will interact with each other and
with the external stakeholders

Management Cycle

To manage the stakeholders, consider the following steps:

44
1. Identify the stakeholders.
2. Analyze how they can impact or be impacted by the project, as well as their expecta-
tions.
3. Determine the objectives and the strategy to engage them.
4. Plan the communication.
5. Implement the communication actions.
6. Measure the plan’s efficiency and review the stakeholders regularly.
7. Adjust the communication accordingly.

To build the project team, other activities are realized in parallel to those above:

1. Identify the required skills, level of authority, and personality profiles for the project
management and delivery teams.
2. The corresponding resources must be requested and negotiated as soon as possible,
and the corporate priorities might be reconsidered. If they are not available internally,
contracting processes must be launched (e.g., request for proposal), or another
project timeframe must be examined.
3. Project team roles and responsibilities must be defined.
4. The project’s tasks must be planned.
5. The project team with allocated roles are composed and resource time is booked,
when needed, according to the project plan. Remember to plan back-up resources.
6. People’s availability must be revised or planned against project progress.
7. Adjustments must be communicated.

Techniques

The following techniques are unrelated to PRINCE2® but are practical project manage-
ment tools that can support PRINCE2® objectives.

Mendelow matrix

A well-known tool for stakeholder analysis is the Mendelow matrix, which categorizes the
stakeholders according to their level of interest against their power of influence. The grid
below is an example of the matrix, in which each group is treated differently.

45
 Figure 2: Stakeholder Power-Interest Grid

Source: Caroline Naudin (2022).

The 5 Ws of communication

Inspired from Lasswell’s model (1948, p. 117), the most common method to develop com-
munication is the 5 Ws:

• who: both the audience target (stakeholder) and the communicator (sender of the mes-
sage, writer of the content, owner of the communication)
• what: the message or type of information (progress report, marketing promotion, pub-
lic information)
• why: the concerns and needs to be addressed, and the objective to be reached (engage,
maintain informed, alarm)
• which: communication channel (conference, meeting, website, mail)
• when: deadline (for unique communication) or periodicity (regular meetings or periodic
reports)

A good practice is to start with the list of stakeholders to ensure that communication rea-
ches them all.

RACI matrix

When defining roles and responsibilities for the project team, a famous technique is the
RACI matrix, which stands for

46
• responsible: These are the people who execute the task. There can be several actors but
at least one who will realize the work.
• accountable: This is the authority and decision-maker who makes sure the work is
done, verifies it, and reports the task progress to the management team. There can be
only one person accountable to avoid conflict.
• consulted: This is an expert or someone who can advise or provide information or items
to realize the task. There can be several for a single activity.
• informed: These are people who must be informed of the task progress or completion.
There can be more than one.

The letters can be modified, added, removed, or the meaning changed. The purpose of
this style of responsibility assignment matrix is to identify roles and allocate them to dif-
ferent team members or stakeholders in a list of tasks or work packages. The activities are
listed in rows, the people are recorded in columns, and the matching cells are filled out
with the corresponding role letter. More information can be found in the Project Manage-
ment Institute’s PMBOK Guide (2021a, p. 262).

Table 1: RACI Matrix

# Package name Actor 1 Actor 2 Actor 3 Actor 4

1.1.1 … A C R I

1.1.2 … A R R I

1.1.3 … A C R R

1.2.1 … R A/R R I

1.2.2 … C A I R

1.2.3 … I A I R

1.2.4 … I R I A

1.3.1 … I C A R

1.3.2 … I C R A

Source: Caroline Naudin (2022).

2.4 Quality
The theme of quality focuses on the product. It is the principle that supports and aims to
meet the business requirements that will satisfy the customer needs and generate the
expected benefits. PRINCE2® takes its understanding of the term “quality” from the ISO
9000 standard: “The degree to which a set of inherent characteristics of a product, service,
process, person, organization, system or resource fulfills requirements” (AXELOS Limited,
2017, p. 78). These requirements define what the project will deliver, with respect to qual-
ity expectations, acceptance criteria, and quality criteria.

47
 The acceptance criteria is a checklist that is elaborated upon during the “starting up a
project” process from the subjective customer’s quality expectations. It is classified by pri-
ority, objective, and measurable features and functions that the project product must
meet to be validated before delivery. It constitutes the project product description. The
quality criteria are similar measurable targets that are applied to the components of the
whole product and documented in the descriptions of the product components. They will
be used during the test to verify how well each element conforms to the criteria. Criteria
should be defined in a SMART way to specify the level of tolerance and a range of accepta-
ble margin to the target. For example, for the construction of a new building, we could
have the following:

• quality expectations: to be ecological, cheap in energy consumption, livable, not too

tall, comfortable, with high-quality materials, secure, etc.
• acceptance criteria: ecological performance level A (tolerance: B), gas emission
<1kgCO2/m2/year (tolerance: five percent), energy consumption <58kW/m2/year (toler-
ance: 10 percent), 10 m high (tolerance: four percent), three floors, etc.
• quality criteria: 2012 regulation standard for the ventilation system with less than 40
percent of heat loss (tolerance: max 42 percent), windows and doors <35 percent heat
loss (tolerance: max 38 percent), six three-room flats of 75 m2 with a terrace of 10 m2
(tolerance: two percent), two 2.5 × 4 m patio doors in the living rooms, chestnut oak
flooring, G1330 white painting for the walls, etc.

In the quality management process, PRINCE2® identifies five roles:

1. The project assurance: Assumed or delegated by the project board, this role is split
into three to represent the business, the users, and the suppliers. It’s part of the
project management team, who ensure that the project can meet its performance
objectives by advising on the quality management approach and the assigned roles,
confirming its actual implementation, and reviewing the product descriptions.
2. The quality assurance: Outside the project team, this belongs to the permanent
organization and owns all the standards, procedures, and systems responsible for
quality. It provides them to the projects teams and ensures they are uniformly
applied.
3. The producer: This is the person who creates the product.
4. The reviewer(s): This is who verifies whether the product meets its requirements; it
cannot be the producer itself (generally, those who check the work cannot do the
work).
5. The approver: This person has enough authority to validate a completed product
before delivery (i.e., the senior user).

We also differentiate two types of activity:

1. The quality assurance: Different from the PRINCE2® role of “quality assurance,” it
encompasses all the proactive actions that ensure the product developments will be
and are made in compliance with the quality requirements, or to avoid waste, failure,
and non-compliance. This can be done by designing a solution that covers all possible

48
 risks, applying ISO standard procedures, contracting high-level experts to recognize
the quality of the work, organizing quality inspections (audits) during the develop-
ments, and so on.
2. The quality control: This consists of reviewing, examining, testing, and correcting
what has already been created but not yet delivered to the customer.

We can also distinguish between the costs of quality:

• the costs of conformance: the prevention costs to cover the initiatives for quality assur-
ance, and the appraisal related to the quality control, to avoid failures
• the costs of non-conformance: due to failures, either internal (when discovering defects
that need to be reworked or that generated waste) or external to the project (appearing
after delivery and resulting in liabilities, penalties, or business loss)

Purpose and Requirements

PRINCE2® states that “the purpose of the quality theme is to define and implement the
means by which the project will verify that products are fit for purpose” (AXELOS Limited,
2017, p. 78). If the project delivers the full scope in time and within budget but does not
meet expectations, the customer might feel dissatisfied. That is why it is so important to
agree on a list of clear, objective criteria that can quantify these expectations and plan the
project to ensure they are met by monitoring and controlling the product developments.
The goal is to the deliver the right solution to the right need. Two management products
are required by PRINCE® for this theme:

1. The quality management approach describes how the quality will be managed
throughout the project life; the measures of quality assurance and quality controls;
the measurement tools; the testing method; the roles and responsibilities, in particu-
lar the project assurance; and the communication channels.
2. The quality register is an up-to-date checklist of all the tests and quality control activi-
ties to follow up on the products’ quality performance and quality review validation. It
will be used for lessons learned and the closure report.

Management Cycle

Quality management consists of the following steps:

1. First, the customer needs must be identified.

2. Next, the quality expectations and acceptance criteria to be included in the project
product description are defined.
3. Third, apply the PRINCE2® product-based planning technique after describing the
project product. It is broken down to identify the scope of all the components that
constitute it, then they are then defined by quality criteria, performance indicators,
metrics, tolerances, the quality assurance, and control method in the product descrip-
tions. The quality management approach will also be prepared, and the dates for test-
ing and validation must be defined to book resource availability as soon as possible.
4. Next, the products are developed according to the quality and acceptance criteria and
by applying the quality assurance measurements.

49
 5. Then, the use cases are prepared and the resources that will verify the quality of the
products will be trained in the control preparation step.
6. The on-time performance, defect frequency, failure rate, reliability, and availability
are measured by monitoring, auditing, process analysis, or testing.
The defects are fixed or adjusted according to the customer’s needs before delivery.
The status progress is tracked in the quality register.
7. Finally, once the products and tests are successfully completed, the senior user vali-
dates or approves the delivery.

The level of detail depends on the industry, product complexity, quality criticality and the
required metrics. The planning will be detailed for each stage so that evolving customer
needs can still be considered.

Techniques

The techniques described below are practical project management tools that can support
PRINCE2® objectives.

Prioritization: MoSCoW

Knowing that more than half of an application’s features are rarely or not used, it is valua-
ble for the customer to review and prioritize the list of functional requirements. Addition-
ally, acceptance and quality criteria should be prioritized. We can qualify them as high,
medium, or low; we can weight them with 1, 2, 3, or 4 points; or we can use the acronym
MoSCoW:

• must have: vital, mandatory, critical

• should have: important, desired, add value, generate significant benefits
• could have: secondary, useful but can work without it, optional
• won’t have: useless luxury, will be used by less than one percent of users, or can be
postponed for further projects

Test types

We can distinguish four types of tests:

1. Unit tests: This includes technical tests of each product component. Examples of
these include verification that each development code gives the expected result; a
verification of the quality of the wheels, engine, and dashboard of a car; or, when
building a house, that the electricity, plumbing, and windows will be tested by their
respective expert when each completes their work package.
2. Integration tests: These are technical tests of the fully assembled product. Examples
of these include a new module included in software, the full payment process, secur-
ity tests of a finished car, or the resistance of a finished doll.

50
3. Functional tests: These are business user tests of the functional quality requirements
and validation before delivery. Examples of these are when an accountant tries a new
payment process with fake data, a customer drives a car on a trial basis, an architect
verifies all the house functionality, or a group of children play with a new doll under
trial monitoring.
4. (Non-)regression tests: These verify that the changes had no impact on the rest of the
environment. Example of these include checking that an order process has not been
impacted by the changes applied to the payment process; repairing just one element
of a car engine and verifying that everything else still works properly; or, when adding
a shower in a house, verifying that the whole plumbing flows well.

2.5 Plans
What will happen to your wedding if nobody plans it? Well, no wedding. Planning allows
us to define, forecast, and organize how things will be done to ensure its success. In
project management, we do not only plan activities but also resources, costs, benefits,
communication, quality and risk management.

Supporting the “manage by stages” principle, the project is managed and planned by the
project manager, stage by stage. PRINCE2® defines a plan as “a detailed proposal for doing
or achieving something which specifies what, when, how, and by whom it will be ach-
ieved” (AXELOS Limited, 2017, p. 94). PRINCE2® specifies the following types of plans:

• corporate, program, or customer’s plan: This is a strategic business plan for the current
and subsequent years. Projects are validated according to this plan, which serve as per-
formance guidelines.
• project plan: This is created during the initiation in the PID and is defined only at a high
level. Since there are too many uncertainties for the duration of the whole project life, it
would be a loss of time to constantly modify it. The project plan is used as a baseline for
the project board to assess the project performance. It includes the stage time periods,
the main milestones, and deliverables, as well as estimations of costs, resources, and
deadlines.
• stage plan: This plan is for the stage that follows a stage as it ends. It is used as a refer-
ence by the project management team to assess and control the stage progress.
• team plan: When the stage is authorized, the project manager provides the work pack-
ages to the delivery teams. Once the team managers accept it, they can build a detailed
team plan and submit it to the project manager for approval.
• exception plan: When an exception is raised and approved, the project board requires
an exception plan that will replace the baseline.

The resources required to deliver a plan need to be committed by plan approvers to

ensure the resources are available when needed.

51
 Purpose and Requirements

PRINCE2® states “the purpose of the plans theme is to facilitate communication and con-
trol by defining the means of delivering the products (the where and how, by whom, and
estimating the when and how much)” (AXELOS Limited, 2017, p. 94). Plans are shared with
the project team for everyone to know who does what, when, and how. The project is
organized and managed by stages, which cannot overlap. There must be at least two
stages:

1. The initiation stage defines and plans the project to verify if the business case can be
realized and, if so, the project board authorizes the delivery of the project.
2. There is at least one management stage for small projects or, if the project is stopped,
activities must be completed to close it officially.

PRINCE2® requires four management products:

1. Project product description: This specifies the quality expectations, acceptance crite-
ria, and quality control methods. Since it defines the overall project output, it applies
to the project plan only.
2. Product breakdown structure: These are all the items that compose the project prod-
uct.
3. Product descriptions: This specifies the purpose, composition, derivation, and quality
criteria of these components.
4. Plans: The project plan and the stage plan are mandatory, as well as the exception
plan. The team plan remains optional.

Management Cycle

In previous PRINCE2® versions, planning was a full process enduring throughout the
project management life cycle as a constant, iterative activity used as an input for manag-
ing everything. It has now been removed from the PRINCE® processes and is included as a
technique. Following the principle of “focus on products,” PRINCE2® recommends the
product-based planning technique. It unfolds into six steps, as explained in the following
paragraphs.

Designing a plan

This step defines the plan structure (i.e., how the stages will be organized) and the delivery
approach (waterfall, Agile, hybrid, etc.). It also includes the plan layout, planning tools,
and the estimating and monitoring methods that will be used.

Defining and analyzing the products

This is a four-step approach that consists of writing the project product description (with
the quality expectations, acceptance criteria, and methods); creating a product break-
down structure (PBS) of the elements that compose the project product; writing the
product descriptions of these items (the purpose, composition, derivation, and quality cri-
teria); and creating a product flow diagram that sequences the production.

52
Identifying activities and dependencies Product breakdown
structure
an organigram of all the
Once the team understands the customer’s need and the scope of products to be deliv- items that compose the
ered, they can study how to produce them. The project manager can design a work break- project outcome
down structure(WBS), which is an organigram of all the work to be realized that is grou- Work breakdown struc-
ped by area of activity and decomposed to the appropriate level for the working plan (the ture
an organigram of all the
main deliverables for the project plan, work packages for the stage plan, and detailed activities necessary to
tasks for the team plan). Once the list of activities is established, they are sequenced realize the project
according to their interdependencies to picture what should be produced and in which
order. A diagram can be drawn with this information and used to elaborate the program
evaluation and review technique (PERT), a task scheduling diagram that is described
below.

Preparing estimates

These clarify the project activities, which will help confirm the required skills and resour-
ces needed to accomplish the work. These experts will estimate, based on their experi-
ence, the time and effort necessary to complete their job. Resource time and material can
then easily be translated into financial estimations. Remember that planning is a forecast,
and is never fully accurate to what will happen. It is only an estimation that is useful as an
initial reference to assess the actual progress.

Preparing a schedule

Now is the moment to put all this information into a calendar, consider the resource avail-
ability (percentage of allocation, overloaded time periods, and days off), and verify if the
targeted project deadline can be reached. If not, an exercise of planning optimization can
help fit in the time objectives. The PERT method can be used to identify the critical path,
which is the largest sequence of tasks dependent on each other where no margin is possi-
ble. A Gantt chart is the most common visual representation of the schedule. The schedule
preparation comes with a risk analysis.

Documenting a plan

Finally, the consolidated plan information is documented and submitted for approval
before being shared with the rest of the team.

This PRINCE2® planning technique is aligned with the best practice of bottom-up estimat-
ing to develop the project budget. It requires forecasting the smallest elements and sum-
ming them up to get the total costs. However, should these costs be the amount you
request for your project budget? First, if the fixed price resources have not been distrib-
uted proportionally to the activities, they must be added to the costs. Second, a margin is
typically added on top of it to cover the risks (a provision can be calculated from the risk
analysis), as well as contingencies (a percentage fixed according to the statistics or corpo-
rate standards).

53
 Techniques

The following techniques are not related to PRINCE2® but are practical project manage-
ment tools that can support PRINCE2® objectives.

Program evaluation and review technique

The project evaluationannd review technique (PERT) diagram offers a scheme of the
project tasks sequence. Based on the duration of each activity and their interdependen-
cies, we can calculate the total duration of the project, determine where there are mar-
gins, and identify the critical path.

In a PERT diagram, every activity is represented by a rectangle that includes the task dura-
tion. They are linked by arrows to their immediate antecedents and following activities.
First, we calculate the earliest start date (once all its predecessors are finished) at the top
left of the rectangle and the earliest end date on the top right based on the estimated task
duration. Below, activity E can start as soon as activities C and D are finished, or the high-
est one, i.e., February 16. Activity E needs five days to complete, which leads to February
21. The earliest end date of the last task is the final project date.

Next, we calculate the earliest dates from the earliest final project date minus the task
duration, and retrograde task after task. Activity D can finish, at the latest, when the next
activity E must start at the earliest, which is February 16. Since activity D still requires
three days to be done, it must start the latest possible by February 13. Once all the dates
have been calculated, we can deduce the following margins:

Floats • The free floats are the difference between the earliest start date of an activity and the
the time buffer or margin earliest late date of its predecessor. The free float between D and E is February 16 minus
for task delay
February 11, i.e., five days. Therefore, we can be up to five days late before starting E.

• The total floats are the margin intra-activity, obtained by subtracting the task latest
dates from the earliest ones; the total float of the activity B is February 13 minus Febru-
ary 8, i.e., five days.

Therefore, we can be up to five days late on activity B, but the total delay on both B and D
cannot exceed the free float of five days. The critical path is the sequence of activities that
have no margin: activities A–C–E.

54
Figure 3: Example of PERT

Source: Caroline Naudin (2022).

Gantt chart

Much more famous and simpler to read and build, the Gantt chart offers a visual chronol-
ogy of the project schedule. Like in a bar chart, the activities are listed on a vertical axis,
generally within their WBS hierarchy. The breakdown structure is included for all project
tasks, and the project timeline is represented on a horizontal axis. The bar length is pro-
portional to the task duration from its start date to its end date.

Gantt is a visual and comprehensive tool. Additionally, more information can be included
either on the bar or in columns next to the tasks; for example, the start date, end date, task
dependencies, assigned resource, progress status, and costs.

Figure 4: Example of A Gantt Chart

Source: Caroline Naudin (2022).

55
 2.6 Risk
A project is unique by definition since it involves a different environment, timing, team
members, needs, tools, skills, and other variables. This uniqueness will generate uncer-
tainties and unpredictable events, which makes the project riskier than routine opera-
tions.

PRINCE2® defines a risk as “an uncertain event or set of events that, should it occur, will
have an effect on the achievement of the objectives. A risk is measured by a combination
of the probability …, and the magnitude of its impact on objectives” (AXELOS Limited,
2017, p. 120). Risks have the following characteristics:

• Unlike an issue, a risk has not yet occurred, but it might occur in the future.
• The realization of such a risk could have consequences on the project success.
• Its effect is not necessarily something negative that should be perceived as a threat. It
can also be seen as positive and an opportunity that could be leveraged for better
project performance.
• The fact that it does not exist yet generates uncertainties that could be evaluated by two
factors: the probability to happen and its impact on the project objectives.

When recording the risks, it is helpful to clearly describe them by considering the following
aspects:

• risk cause: the potential source(s) that could generate such a risk
• risk event: the area of uncertainty, with a positive or negative effect
• risk effect: on which project objective(s) the risk would have an impact

For instance, if a sponsor does not provide funds by the end of March (risk cause), there is
a threat that we will not have enough in the treasury to buy the furniture (risk event),
which would delay the opening of the school (risk effect).

Purpose and Requirements

PRINCE2® states that “the purpose of the risk theme is to identify, assess and control
uncertainty and, as a result, improve the ability of the project to succeed” (AXELOS Limi-
ted, 2017, p. 120). The objective of risk management is to anticipate events and take con-
trol to ensure or improve the success of the project. PRINCE2® recommends an iterative
procedure for managing the risk theme, which is involved in all project stages and must be
tailored to each specific project, depending on its size, complexity, and the corporate
standards and policies. This will be defined in the risk management approach, which is
included in the project initiation document. It describes the governance of roles, responsi-
bilities, processes, strategies, tools, and techniques that will be implemented to identify
and analyze risks, assess their impact on the project business justification, plan and
implement risk responses, communicate to the stakeholders, elaborate warnings, guaran-
tee risk review, and document updates. Moreover, it can define how to establish the risk
budget, as well as the associated risk tolerances, i.e., the limit of risk exposure that
requires an escalation to the next level of management if the risk value overpasses the
defined thresholds. The risk management approach also specifies the risk register content

56
and how to read and use it. The risk register is also required, which is created during the
“initiating a project” process and maintained and updated throughout the project life
cycle. It is a list that records the identified risks, their assessment, and the decisions made.
It also tracks their status and history.

Following the principle of “learn from experience,” lessons must be used to identify and
manage potential risks. Documenting the history of the current project risks will be collec-
ted as lessons for the future.

Management Cycle

An effective risk management would have an iterative life cycle, typically starting with
identifying risks, assessing them, planning a response, then implementing and communi-
cating the response. A continuous review is necessary to verify their status, the result of
the response action, or to identify new risks.

Identifying risks

Risks can be identified at any time throughout the project, by any team member or stake-
holder, and should be documented immediately to ensure their control. Several techni-
ques help gather or brainstorm risks. As always, one brain is certainly not enough, so it is
necessary to gather a team with various knowledge, experience, skills, and personalities
to work together.

Learning from previous similar projects enables the project management team to antici-
pate events and reduce uncertainty. Researching from in-house databases or public
prompt lists of risks help broaden our minds and collect more risks.

Assessing risks

The next step is to evaluate the severity of every risk by estimating their probability,
impact, and urgency, then weigh the worth of acting on each of them. We would also
assess the risk exposure (i.e., the bearable extent of risks) to ensure the continuous busi-
ness justification for the project while considering the risk appetite (i.e., the risk-taking
attitude) of the organization.

In the risk management approach, it will be decided if it is better to perform a qualitative

risk analysis, which might be less time-consuming, or a quantitative one, which is highly
recommended for analyzing high-risk projects and calculating an accurate risk budget. We
can calculate the expected risk value with the following formula:

Risk value = P robability · Impact

The risk budget includes the sum of all the risk or residual risk financial values, plus the Residual risk
cost of all the agreed risk responses. Obviously, opportunities would generate benefits, the risk that would
remain after implement-
which would be subtracted from the total costs. ing the risk response

57
 Planning risk responses

Depending on the risk level, the team can decide on different ways to address them.
Threats can be

• mitigated by reducing its probability or impact and acting on the root cause of the risk.
Here, a residual risk will remain. An example of risk mitigation is hiring experienced
experts who might make mistakes but at a lower probability than less experienced
employees.
• avoided by reducing the probability of the impact to null. For example, risks can be
avoided by purchasing only in-stock products to eliminate the probability of shortage.
• transferred to a third party. An example of transferring risks could be contracting an
insurance to cover the costs in case of accident.
• accepted by doing nothing, generally for negligible risks or risks beyond the project
team’s control. They can also create a back-up plan in case the risk becomes real. For
example, a war could break out and jeopardize the project, but the probability is so low
that the team decides to accept it. If it happens, the organization will review the priori-
ties.

Conversely, there are several ways to deal with opportunities, such as the following:

• Opportunities can be exploited by acting on their cause or considering building the abil-
ity to welcome the opportunity. For example, there is a 50 percent probability of attract-
ing more than 1,000 visitors at the same time on a company website, but the server can
only support 800 visitors. Considering the benefits if it exceeds the capacity and the
negative image if the website crashes, the team decides to invest in more server
capacity.
• Opportunities can be enhanced by increasing the probability or impact further. Follow-
ing the same example, the team decides to invest in more server capacity. To ensure it is
worth it, they also invest in a stronger marketing campaign to increase the probability
and the number of visitors, which would bring even more benefits.
• Opportunities can be shared by collaborating to exploit them and distribute the impact.
Following the same example, if increasing the server capacity is too expensive com-
pared to the possible benefits, the team may decide to contract a hosting server, which
is activated only when there is more than 900 visitors at the same time.
• Opportunities can be implicitly accepted by taking no action. It is beneficial if the
opportunity arises, but there is no loss if it doesn’t. Or there might be too little chance
for it to happen that it would be worthless to make any effort toward it. With the same
example, the probability that the volume of visitors exceeds the 1,000 limit is so low
(one percent), that the team does nothing and risks the website crashing for a few
hours.

The decision to act on the risk will depend on the balance between the initial risk’s finan-
cial impact and the response cost added to the residual risk value. Would it be woth it to
take out an insurance policy to cover the risk of a machine accident that could hurt a
worker? If, in 10 percent of similar projects an injury-inducing accident occurs, the cost
might be, on average, €5,000. Contracting an assurance would cost €100 for the project
period and would totally cover the damages. The risk value would be 10 percent of €5,000,

58
i.e., €500. This is compared to the cost of the response, €100, plus the residual risk value
for which the probability of occurrence of the residual risk value remains the same (10 per-
cent), but the impact on the project would be null since it was transferred to the insur-
ance, i.e., 10 percent of zero is zero. Therefore, it would be profitable to pay €100 to cover
the risk that is worth €500.

Implementing the risk plan

Once the response plan has been agreed, actions will be assigned to a “risk actionee” who
is responsible implementing the risk response by a specific deadline. A risk owner is also
nominated to monitor the response status, its efficiency, and the resulting new probability
or impact. If a risk occurs, its impact will be paid with the risk budget. Risks are continu-
ously revised to verify if they evolved or disappeared, or if new risks have arisen.

Communicating the risks

The relevant risks are generally communicated to the relevant stakeholders through con-
trol reports to the management team or as specified in the risk and communication man-
agement approaches.

Techniques

The following techniques are not related to PRINCE2® but are practical project manage-
ment tools that can support PRINCE2® objectives.

Brainstorming techniques

Several methods are very useful for brainstorming risks:

• SWOT analysis is a very popular method to discover the project’s strengths, weak-
nesses, opportunities and threats (Ansoff & McDonnell, 1990).
• The speed boat is an Agile gaming tool with the same objective as the SWOT analysis: to
examine the team on board, its environment, the obstacles and weaknesses (represen-
ted by the anchors), and what can help the project (symbolized by the wind), while
keeping in mind the targets that the project aims to reach (Hohmann, 2006).
• The PEST analysis (political, economic, socio-cultural, and technological) is another
strategic tool that reinforces the SWOT analysis by providing a framework of macro-
environmental factors that could influence the project. We can add other fields, like
legal, demographic, environmental, or ecological (Bensoussan & Fleisher, 2008).
• The Ishikawa fishbone is a useful tool to encourage people to think outside the box by
directing them to think about risks within different categories (methods/processes,
machines/technology, measures/data, manpower/human resources, and mother
nature/external environment). The risks are then broken down into potential root fac-
tors that could generate them and on which we could act (Ilie & Ciocoiu, 2010).

59
 Risk analysis

Qualitative risk analysis necessitates a scale be set prior to analysis (e.g., low/moderate/
high, 1–4, unlikely/probably/very likely). The clearer and more objective each level is, the
better it will be understood and applied by the team (e.g., low = 0–10 percent, or less than
one day of delay, or less than €1,000). Numeric weights (e.g., low = 1, moderate = 2, high =
3) are useful for measuring the criticality rate by multiplying the values of the probability
and impact. Additionally, an urgency factor can be included.

For quantitative risk analysis, probability is estimated as a percent, generally based on sta-
tistics for similar situations; the impact is then translated into comparable figures. Project
risk management often seeks to understand the financial impact (e.g., if we have one
week of delay, how does it affect cost?) and define it in proportion to the project business
justification (budget/benefits). For a visual understanding, the defined scales can be rep-
resented in a probability-impact grid or matrix, as illustrated in the figure below.

For example, if the risk has an 80 percent probability of manifesting, with a high impact of
€7,000, it would appear in the matrix’s red zone, which would be alarming enough to catch
the attention of the project board. The value of this risk would be 80 percent of €7,000, i.e.,
€5,600. This would represent the level of importance of such a risk until the project team
decides to address it with a risk response plan.

60
Figure 5: Example of a Probability-Impact Matrix

Source: Caroline Naudin (2022).

2.7 Change
Changes are intrinsic to the project life. We do not expect project managers to prevent
them but to accept and deal with them. We understand change management in PRINCE2®
as change control. This was the name of the theme until 2009. The equivalent ITIL® proc-
ess name that was changed in ITIL®4 to “change enablement” to remove the connotation
of filter or stopper. Instead, there is an intention to foster beneficial changes, with minimal
disruption to the project objectives. This theme should not be confused with change man-
agement, which facilitates user acceptance, adaptation, and adoption of changes that are
introduced into the project. PRINCE2® does not cover change management, which often
results in it being forgotten and the expected benefits not being achieved.

61
 PRINCE2® refers to changes as “issues,” which are unforeseen events that happened
(unlike risks) and differ from the approved plans with an impact significant enough to cap-
ture the project team’s attention. An issue can generate risks. A risk that becomes reality
turns itnto an issue. PRINCE2® categorizes issues into the following types:

• A request for change is a scope change on a product, often requested by the client who
usually finances it. Examples of this include adding a new feature, changing a layout, or
removing a product.
• An off-specification is a product that does not comply with the product description;
either a failure in the product quality, generally identified during the quality control, or
a product that cannot be created. Examples of this include a bug in the development,
technical unfeasibility, and broken pieces.
• A problem/concern is any other issue that can have an impact on the project objectives
that must be solved or reported to the management team. Examples of this include sup-
plier in bankruptcy, the resignation of a team member, a war, and a pandemic.

Changes and the actions to address them might impact the project objectives and plan
baselines. Any approved modification applied to the plans must be tracked in the configu-
Configuration item ration item record, maintained by the project support. The administration of these items
record has historically been covered in information technology (IT) by configuration manage-
the list that tracks both
management and special- ment, which has been adopted by PRINCE2®. However, due to its complexity, which does
ist products’ version, sta- not fit into every type of project and industry, it has been optional since 2017. A configura-
tus, variant, and interrela- tion item has remained to refer to any product or component that has been approved and
tionship
is thus subject to change control.

Purpose and Requirements

Based on the ISO 20000 definition of change management, PRINCE2® states that “the pur-
pose of the change theme is to identify, assess and control any potential and approved
changes to the project baselines” (AXELOS Limited, 2017, p. 138). It defines how any
change to products will be studied and validated, considering the full project picture while
reducing the project risk. Two management products are essential for this theme:

1. The change control approach describes how issues and changes will be handled in
the project, how they will be captured, which management system will be used, the
format and categories of the issue register, how the product documentation will be
stored and controlled, what the change control roles and responsibilities will be, and
who the change authority will be.
2. The issue register is maintained by the project manager. It captures every issue that
needs to be formalized, tracks their status, and documents the agreed action plan.

Usually, the change control approach is defined at the organization level (e.g., by the
project management office) so the project manager can apply it when tailoring the project
governance. The project manager is often perceived as an inflexible judge who rejects
most of the requests. However, it is the change authority who enables the project man-
ager to welcome the requests, acknowledge them, and assess them for validation by the
change authority. This helps the project manager remain close to the project team and
stakeholders and build trust through open communication.

62
Moreover, a good practice is to reserve part of the project budget to cover unforeseen con-
tingencies. Since they are unpredictable, they cannot be calculated as a risk. However, sta-
tistics from similar projects can be used, or the organization can apply the same percent-
age for all, which is a common practice. Often, this margin is confused with the authority
threshold fixed on project cost performance. PRINCE2® requires that only change requests
are covered by the change budget, not by the project budget tolerances.

Management Cycle

PRINCE2® recommends the below procedure for issue and change control.

Capture

Anyone can raise an issue that should be reported to the project manager. The project
manager will first qualify it, then determine its type (change request, off-specification, or
other concerns), its level of severity, and priority. If no action is required, the issue can be
noted in the project manager’s daily log; formal issues will be recorded in the issue regis-
ter.

Examine

Here, we assess the consequences or potential changes and analyze their impact on the
six project performance objectives, the business case, and the stage and project plans. We
evaluate their level of gravity and the urgency, and then we prioritize them. Advice can be
sought from the project board with an issue report, although it is always better to first
think about solutions. Issues whose impact surpasses the sequence or project objectives
will give rise to an exception.

Propose

The project manager should identify solutions or options for action; evaluate their advan-
tages, risks, disadvantages, and costs; and then select the recommended option. Issues
that need a formal decision are detailed in an issue report, and exceptions are described
in an exception report that must be submitted to the project board. Change requests and
off-specifications will be addressed to the change authority.

Decide

The project manager can decide on the action plan for the issues under their authority or
hand it over to the change authority where required. Change requests are accepted if they
bring more profits than costs or avoid losing the expected benefits. The project board will
approve, reject, or defer solutions for issues that need their official decision, and excep-
tions. If the exception exceeds the overall project plan tolerances, the project board for-
wards the exception request to the client, the corporate executive board, or the program
board. For approved exceptions, the project board requests the project manager to pro-
duce an exception plan that will replace the stage plan or, if impacted, the project plan.

63
 Implement

The project manager takes the agreed actions for correction, reviews its efficacity, and
adjusts it when necessary. In case of exceptions, they create the exception plan to be sub-
mitted to the project board. Finally, they close the report and update the records and
plans accordingly.

Techniques

The change impact analysis technique is not related to PRINCE2® but is a practical project
management tool that can support PRINCE2® objectives. A change impact analysis can be
performed within the business operations when a change request is raised and can be
applied quickly to generate a full project or be implemented within a project when a
change is required. Typically, this exercise consists of several steps:

1. Describe the issue or change request.

2. Analyze the impact on the environment (the project, organization, infrastructure,
stakeholders, and ecology), scope, costs, benefits, quality, timeline, and resources.
Whenever it is possible, try to understand what the impact means financially (i.e.,
what would cost one week of delay or poor quality?).
3. Evaluate the related risks, advantages and disadvantages.
4. Identify several options of solution or action, including the option of not doing any-
thing.
5. Perform a cost-benefit analysis for each option.
6. Submit the recommended action.

2.8 Progress
More than being a good planner, a good project manager should show flexibility and
adaptability to changes. Projects never proceed exactly as planned, but the plans are a
point of reference on the project status and its progress, and they direct the next steps.
This preserves the control of the project objectives and destination, thanks to the method-
ical management of deviations from the plans. In previous versions, this PRINCE2® theme
was called “controls,” but control is not only about monitoring; it brings the project back
to its objectives. This matter is managed by means of regular reviews and reports.
PRINCE2® differentiates between two types of control:

1. Time-driven controls are periodic monitoring and reports that are regularly produced
which are predefined by the project manager in the PID. Examples of these include
monthly highlight reports to the project board and weekly checkpoint reports to the
project manager.
2. Event-driven controls can be punctual or planned controls that are performed every
time a specific event occurs. Examples of these include the issue report, exception
report, end stage report, end project report, and product status account.

64
Purpose and Requirements

PRINCE2® states, “the purpose of the progress theme is to establish mechanisms to moni-
tor and compare actual achievements against those planned, provide a forecast for the
project objectives and the project’s continued viability, and control any unacceptable
deviations” (AXELOS Limited, 2017, p. 148). The project manager defines the progress con-
trol approach, tools, reporting format, and periodicity, delegating roles and responsibili-
ties, communication channels, and other exception-related processes in the project initia-
tion documentation.

Controlling is performed following the principle of “manage by exception,” where each

hierarchy level is responsible at different project levels according to the performance
objectives and associated tolerances. Reporting gives visibility to the progress. An alert
mechanism is established to inform when deviations exceed the thresholds outlined in the
following paragraphs.

The team manager

The team manager reports the work package progress to the project manager through the
checkpoint reports, which include the team issues. Objectives and tolerances of time,
cost, scope, and risks are defined by the project manager in the work package and the
quality in the product descriptions.

The project manager

The project manager records issues in the issue register and regularly reports the stage
progress in the highlight reports to the project board as per the “manage by stage” princi-
ple. Issues that need the project board’s consultation are described in an issue report.
Those exceeding the stage tolerances are defined in the stage plan (time, cost, scope, and
risks) or the product descriptions will generate an exception report. Once the stage is com-
pleted, an end stage report is provided to the project board to decide whether it is worth
continuing with the next stage to ensure the principle of “continued business justifica-
tion,” depending on the business case status.

The project board

The project board forwards the highlight reports and exception requests that might jeop-
ardize the project (time, cost, scope, and risks) to the client, the corporate committee, or
the program, as approved in the project plan, the expected benefits, as stipulated in the
business case, or the quality defined in the project product description.

The intervals of the progress controls must be defined according to the level of complexity
and uncertainties of the work. For instance, the project manager can decide to receive
reports from the communication team monthly during the first stages but then weekly
during the last stage, where all the communication and trainings are provided for change
management before delivery to the customer.

65
 Management Cycle

Progress control would typically consist of the following activities:

• monitoring the work progress with project team meetings or periodic status reports
• measuring the work progress
• comparing the actual progress with the baseline plans
• identifying deviations from the forecast and objectives
• analyzing potential issues, root causes, and their impact on the project objectives
• proposing corrective solutions and decide on actions
• implementing the agreed actions, reviewing their result, and adjusting if needed
• communicating any relevant information to the interested stakeholders

Techniques

Earned value management (EVM) is not related to PRINCE2® but is a practical project man-
agement tool that can support PRINCE2® objectives. EVM is a method that allows the
assessment of the project progress and performance in terms of both time and cost. The
earned value (EV) is the value of what has already been accomplished before billing
occurs. To calculate it, we first need to understand the progress status as a percentage
(i.e., how much of the work has been completed) and multiply it by the planned cost of
this piece of work according to initial estimations:

V olume completed
EV = T otal volume to be done
× F orecasted cost

Imagine you hire a painter to paint 100 m2 in your house. They quote you €2,000 for ten
days of work. After three days, and painting 40 m2, the painter gets sick and cannot finish.
You want to evaluate how much you will be expected to pay for the accomplished work,
although you will have to find someone else to finish it. How would you calculate it? 40 m2
represents 40 percent of the total 100 m2, and 40 percent of the quoted €2,000 would be
€800. That is the earned value, i.e., what you are supposed to pay them. A few days later,
you receive the bill with a total amount of €700, and a note that says they gave you a €100
discount to compensate for the inconvenience. That is called the actual costs (AC).

What if the painter needs just one day off? You must understand by how long the deadline
will be delayed. How would you calculate this? You could calculate the planned progress
after three days, considering the total of 100 m2, proportionally divided by the estimated
10 days, which would be 10 m2 for each day. Multiplying it by three, it would give a plan-
ned 30 m2 accomplished after three days. The painter was, thus, ahead by 10 m2, i.e., one
day of work, which should compensate for their day off and avoid further delay. For fur-
ther formulas, we want to compare financials with financials, so we would convert this
planned 30 m2 after three days of work into money, too. The planned value (PV), calcula-

66
ted by multiplying this progress (30 percent of the 100 m2) by the total costs (€2,000),
would be €600. The planned value, earned value, and actual cost are the three indicators
used in EVM. With them, we can perform several calculations:

• Schedule variance (SV) is the difference between the actual progress and the planned
one. If the difference is positive, the work is ahead of schedule; if it is negative, there is a
delay; and if it is null, we are on time:

SV = EV − P V

• Schedule performance index (SPI) is the schedule-efficiency expressed with a ratio. A

result below one shows a delay:

EV
SV = PV

• Cost variance (CV) is the difference between the planned cost of the actual progress
with the real costs. If the difference is positive, the costs are more expensive than plan-
ned:

CV = AC − EV

• Cost performance index (CPI) is the cost-efficiency expressed with a ratio. An index over
one shows more expenses:

AC
CP I = EV

• Estimate at completion (EAC) compares the budget forecast (budget at completion

[BAC]), with the actual project performance. We will use the cost variance when the cost
difference was just a punctual deviation (e.g., the material was broken and we had to
buy a new one), and the CPI Index if the variation is expected to remain with the same
performance until the end (e.g., we have to hire a more expensive consultant). So, we
get two formulas:

BAC
EAC = BAC + AC − EV and EAC = CP I

In the graph below, if we compare the actual costs, what has actually been paid, and the
planned value, we would not be able to guess if the lower costs are due to delayed bills,
delayed work, higher productivity, or discounts. By comparing it with the earned value, we
know that part of the reason is the delay in the work progress.

67
 Figure 6: Earned Value Management

Source: Caroline Naudin (2022).

SUMMARY
The PRINCE2® themes are the seven project matters that must be man-
aged throughout the project life cycle. At the initiation stage, the project
manager defines how they will be managed, monitored, and controlled
until the end of the project. They support the PRINCE2® principles and
are integrated into the processes, which are the required management
products.

The business case describes how viable, desirable, and feasible the
project is. It is regularly reviewed to ensure the “continued business jus-
tification.” The organization deals with stakeholder management and
provides the project team with a clear distribution of their responsibili-
ties, as per the “defined roles and responsibilities” principle. The pur-
pose of the theme “quality” is to be able to satisfy the customer’s needs
and quality requirements using the product-based planning technique
and following the “focus on products” principle. Plans will be used as a
baseline that will be compared with the actual progress to understand
the project performance. While a project plan is described at a high level
only, the project is defined in detail by stage and work package, con-
stantly learning from the previous stage. The project board approves the
project continuity stage by stage after reviewing the business case.

68
The theme “risk” allows us to identify uncertain threats and opportuni-
ties to proactively put in place actions to control them. Deviations
between the project plan and reality can generate new risks to be con-
tinuously evaluated. Changes are inherent to life, so the project man-
ager must handle them to leverage the benefits they can bring while
reducing the risks of impacting the project objectives. Likewise, progress
is monitored with periodic reviews and reporting to collect actual pro-
gress data and compare them with the forecasted baselines. Deviations
must be controlled to ensure the project success.

69
 UNIT 3
THE SEVEN PROCESSES

STUDY GOALS

On completion of this unit, you will be able to...

– build the seven PRINCE2® processes.

– understand how the processes interact with each other.
– explain the purpose of each process.
– define the process activities and responsibilities.
 3. THE SEVEN PROCESSES

Introduction
PRINCE2® is often defined as a process-oriented approach for project management. But
what do we mean by process? A process is the transformation of an input into an output
thanks to a set of activities. You can imagine the PRINCE2® processes as various recipes for
the preparation of a dinner with friends. The project themes are like the ingredients and
tools that will be used for cooking, and the PRINCE2® principles are similar to behaviors
that can ensure a joyful evening. A project is run by seven interconnected processes that
serve specific objectives to qualify and complete it successfully. The seven processes and
their activities can be modified to the project and its organization, but they still must aim
for the purpose recommended by PRINCE2® (AXELOS Limited, 2017, pp. 157–270).

In previous versions of PRINCE2®, there were eight processes, including planning – that is
now integrated as a technique – and the product-based planning, used to build all the
PRINCE2® plans. In this unit, we will describe the goals of each process, the inputs that
trigger and feed them, the activities that PRINCE2® recommends completing, and the pro-
duced outcomes.

3.1 Overview and Interaction of the

Processes
Each process belongs to a level of the hierarchy and describes each level’s responsibilities
and interactions with the other levels. The higher levels exercise control over the lower
ones. Process outputs provide information to the processes of the nearest levels:

• starting up a project: Initiated by a mandate or equivalent, this is the very first process,
owned by a selected project executive and supported by a nominated project manager.
It is the entry point to study at a high level. The project viability is written in a project
brief and submitted for approval to the newly composed project board.

directing a project: This is triggered by the submission of the project brief and is the only
process of the project board until the end of the project. They approve the project, stages,
Exceptions exceptions, and closure; supervise the project progress; and continuously review the
deviations from the business case. They also serve as an interface between the project and the external stake-
project or stage plans
whose impact could jeop- holders.
ardize the performance
objectives and exceeds
their related tolerances

72
• initiating a project: If the project board approves the viability and initiation of the
project, the project manager will define the appropriate management approach and
plan the project to request its execution.
• controlling a stage: If the project board approves the project execution and the follow-
ing management stages, the project manager will authorize the delivery of the work
packages to the team. They will supervise the stage progress, report it to the project Work packages
board, and control possible deviations from the stage plan. descriptions of the work
that an individual or
• managing product delivery: Once the project manager provides the authorized work delivery team must pro-
packages to the delivery teams, the team managers coordinate their production and duce during a stage
report their progress back to the project manager. They will also hand over the finished
products to the project manager.
• managing a stage boundary: When approaching the end of a stage, except the final one,
the project manager will assess the completed stage according to the plan in an end
stage report, plan the next stage, and request its start to the project board. This process
can also be activated when the project board requests an exception plan to replace the
baseline plan after approving an exception request.
• closing a project: When approaching the end of the final stage, the project manager
assesses the completed project after validation of the project product delivery and
requests its formal closure to the project board. This process can also be triggered by
the project board when deciding to stop the project prematurely.

73
 Figure 7: PRINCE2® Structure

Source: Caroline Naudin (2022).

74
3.2 Starting up a Project
This first process happens before the project is validated to examine its viability, feasibil-
ity, and profitability. The objectives are as follows:

• Understand the customer’s need, the reasons for doing it, and the corresponding scope.
• Assess the potential benefits for the business.
• Identify the major constraints, risks, and challenges.
• Estimate the required effort in terms of time and costs.
• Nominate the potential team that could take responsibility for the project or participate
in the initiation stage.
• Request the initiation of the project.

There should be enough information for the project board to be able to assess the profita-
bility of the proposal. However, as little time and effort as possible should be spent on an
idea that might not be worthwhile, so the study must remain short and at a high level. In
many organizations, it is usually not the project board but a corporate committee that first
approves the projects based on their strategy, priorities, portfolio, and available resour-
ces.

Input

This first process is generally triggered by a client’s mandate or an internal request. This
unique entry point should contain enough information to

• identify or convince an individual to become the project executive, who is a sponsor

who would take ownership of the project.
• fulfill the pre-study. Otherwise, the customer, experts, or other stakeholders can be
interviewed for further information.

Activities

There are several activities that must be performed prior to starting a project, as outlined
in the following paragraphs.

Appoint the executive and project manager

First, someone is needed who is willing to take ownership of the project and has the ability
to represent the interests of the business stakeholders. The project executive gets the
financing to concretize the project and, as such, is ultimately responsible for the success
of the project and the realization of the expected benefits.

Then, the executive will delegate the day-to-day project management to a project man-
ager and, together, they will complete this first process, “starting up a project.” Their role
and responsibilities must be clearly defined, and they will estimate the effort required for
project to book their assignment time. A daily log will be created for the project manager
to take note of any relevant information that can be used later.

75
 Capture previous lessons

To plan and conduct a project, knowledge from other projects will be used. It can come
from

• the proper experience of the project manager and executive;

• the corporate project portfolio database with lessons learned from previous similar
projects;
• information found on the internet;
• interviews with experts; or
• corporate standards, procedures, and tools.

These lessons are then gathered in a lessons log.

Design and appoint the project management team

It is also necessary to appoint the people who will participate in the first project phase,
including the other PRINCE2® management roles:

• the senior user(s) and senior supplier(s) who will be part of the project board
• the project assurance who will supervise and guide the project manager in defining the
project management approaches
• the project support that will assist the project manager and track the product version-
ing
• the team managers who can already be identified

At this point, although PRINCE2® does not mention it, it is also good practice to identify
required skills and thus the people who should participate in the project. This way, we can
verify and reserve their availability as soon as possible before they are engaged in other
projects or activities. In the event that some resources are unavailable, we might either
consider a more appropriate period of time to execute the project or contract external
resources, which must be taken into consideration in the cost estimations.

Prepare the outline business case

The business case will justify the project viability. In this preliminary study, time wasting
should be avoided, so only an outline with high-level information and gross estimations
will be drafted. The business case will be developed further in the initiation stage.

The customer’s needs must be clearly defined in the project product description with the
quality requirements and measurable acceptance criteria. Owned by the executive, the
business case explains what is needed and why to really understand the objectives and
reasons for realizing this project, as well as the alternative options that could satisfy the
Dis-benefit same need. Expected benefits, required effort, time and costs, dis-benefits, and major
any predictable negative risks should be identified for each option. This will enable the selection of the most profit-
effect
able solution and calculate the corresponding return on investment (ROI). There are cor-
porate templates and standards that can be used to assemble the business case or calcu-
late the related ROI.

76
Finally, verification is needed to ensure that the project objectives are aligned with the
Return on investment
business strategy and determine how it can be financed. This is calculated ratio
between the monetary
Select the project approach and assemble the project brief value of expected benefits
and the investment costs.
The ROI formula is (profit
Before planning the project, we must also determine which project management and – cost)/cost.
delivery methods will be used, depending on the nature of the project product, the busi-
ness industry, the corporate standards, people skills, and available training. The informa-
tion collected during “starting up a project” is summarized in the project brief, which
includes the following:

• the project context and objectives

• the scope and exclusions
• the assumptions and constraints
• the business case outline
• the project product description
• the selected management approach
• the team structure and roles descriptions
• the identification of the major stakeholders

Plan the initiation stage

If the project is approved, a first initiation stage will start up to study more deeply, define,
and plan the project. This first stage also needs a plan since it will require time, effort, and
resources that must be financed and coordinated. The project brief and the initiation
stage plan will thus be presented to the project board to get authorization and resources
to initiate the project.

Output

At the end of this process, a request to formally initiate the project will be submitted to the
project board, along with the following management products: Management product
documentation and infor-
mation created and used
• project brief that includes the business case outline and the project product description to plan and manage the
• initiation stage plan project
• daily log
• lessons log

The request will then trigger the “directing a project” process for the first time for the
project board to review the project brief and decide whether the project can officially
start.

77
 3.3 Initiating a Project
If the project board authorizes the initiation of the project, the project manager starts the
first stage with the process “initiating a project.” Its main purposes are to study the busi-
ness case and possible solutions in more depth to validate that the project can be real-
ized, as well as to establish a clear structure and a strong baseline plan for the project suc-
cess. Shared with the project team for a common understanding and guideline, the
Project initiation docu- project initiation documentation (PID) answers the following questions: what needs to
mentation be done, how, when, by whom, and how will it be controlled?
the reference folder or
space that contains all the
project method definition Input
and planning, approved
by the project board
The project manager uses the approved project brief and develops it further, as well as the
other information collected in the daily and lessons logs during the “starting up a project”
process. Collaboration with experts, input from quality assurance and advice from
Quality assurance project assurance are also necessary to plan the project and define its management
versus project assurance approach.
Outside of the project
team, the quality assur-
ance owns the corporate Activities
standards in terms of
quality. The project assur-
ance belongs to the Before imitating a project, the following actions need to be taken.
project management
team and supervises the
project performance.
Agree on the tailoring requirements

Following the principle “tailor to suit the project,” the corporate standards, PRINCE2®, and
other selected project management methods must be adapted to the project according to
its nature, size, level of complexity, partners, stakeholders, and other external factors. This
tailoring must be documented in the PID and approved by the project board. This part was
not included in the PRINCE2® versions prior to 2017, but with the willingness to become
more flexible and adaptable, PRINCE2® has now put more emphasis on this topic.

Prepare the risk management approach

In alignment with the theme “risk,” how risks will be identified and managed must be
defined upfront. Included in the PID are the procedure, tools, techniques, format of the
risk register, categories and terminology to be used, organization’s risk appetite, and
applicable tolerances. It also explains how to build the risk budget, how and when risks
will be revised, and the related roles and responsibilities.

Prepare the change control approach

In alignment with the theme “change,” how changes and issues will be managed and how
product requirements will be controlled must be defined in advance. The level of control
varies from one project to another, one stage to another, and even one work package to
another, according to the level of risks. Included in the PID, the change control approach
explains the different types of issues that will be managed, how they will be communica-
ted, how to create and use the issue register, and how it is linked to the risk management.

78
It appoints the change authority and other roles that can approve or reject the occurring
changes. It also covers the configuration management strategy that tracks the deviations
and versioning of the approved management and specialist products.

Prepare the quality management approach

In alignment with the theme “quality,” the procedure that can ensure the full understand-
ing and satisfaction of the customer needs must be defined in advance. The project prod-
uct description, collected in the “starting up a project” process, will be used to understand
how to ensure and control the quality. In this approach, the quality roles and responsibili-
ties must be clearly defined, particularly the project assurance that supervises the project
performance. Integrated in the PID, it also includes the communication channels and how
the quality register will be used.

Prepare the communication management approach

This approach defines and plans the communication among both the project team and
with external stakeholders. Based on the stakeholder analysis, it specifies all the proce-
dures, tools, techniques, periodicity, storage systems, roles, and responsibilities that
should be applied. It is also incorporated in the PID.

Set up the project controls

Supporting the theme “progress” and the principle “manage by exception,” this activity
consists of implementing mechanisms to monitor and control the project progress and
possible deviations from the baselines, such as

• the type and periodicity of progress controls,

• the tools and techniques to record and analyze issues,
• the different levels of impact according to all the project performance objectives,
• tolerances, and the escalation procedure in case of exception.

Create the project plan

Incorporated in the PID, the project plan is only outlined, as per the theme “plans” and the
“manage by stage” principle. It presents the timeline overview, the stage structure, the key
milestones, and the estimated costs. A detailed plan is elaborated on at the stage level
during another process called “managing a stage boundary.”

Prepare the benefits management approach

Based on the outline prepared during the “starting up a project” process, the business
case can now be updated with the planned forecast. Integrated in the PID, its revision
periodicity and control need to be defined in alignment with the “business case” theme
and the “continued business justification” principle.

79
 The benefits are included in a separate list from the PID because, at the end of the project,
the PID will be stored away, while benefits must be confirmed upon their receipt after the
project delivery. The realization of benefits is the project executive’s responsibility, with
the support of the senior user(s) who will ensure the good use and maintenance of the
project product to generate the expected benefits. The responsible people and the time at
which the benefits will be confirmed must be defined in the benefits management
approach.

Assemble the project initiation documentation

All the information and documents collected during the “initiating a project” process,
except the benefits management approach, are gathered in the PID. This will later be sub-
mitted to the project board, and, if approved, it will become the initial project baseline.

Output

The project managers will present the PID and the benefits management approach to the
project board, requesting approval to start delivering the project. Registers (risk, issues,
and quality), as defined in the different approaches, are also created to be used during the
project execution. The daily log and lessons log have been updated with the information
received.

3.4 Directing a Project

“Directing a project” is the process of all the project board’s activities to supervise the
project progress and take key decisions that ensure the project success and continued via-
bility. They also serve as an interface between the project and external stakeholders, like
the corporate management, customer, or program.

Input

This process is triggered several times throughout the project life cycle, especially

• at the end of the pre-study with the request to initiate the project, the project brief, and
the initiation stage plan.
• at the end of the initiation stage to validate the PID and the benefits management
approach, authorize the project delivery, and (with the first delivery stage plan) to
approve its start.
• at the end of every delivery stage to assess the end stage report, review the business
case, approve its completion, and further project execution based on the next stage
plan.
• every time a formal decision is required by using the highlight reports and the potential
issue reports.
• every time an exception report is submitted and later to review the related exception
plan that they requested.
• at the end of the project with the end project report.

80
Activities

Several activities must be performed to direct a project, as outlined in the following para-
graphs.

Authorize initiation

Based on the project brief received from the “starting up a project” process, the project
board verifies whether the project investment is profitable. If so, it will review and confirm
the proposed organization, project approach, customer’s expectations, and the initiation
stage plan. Once the project brief is validated, the project board informs the relevant
stakeholders of the project’s official start and authorizes the project manager to proceed
with the “initiating a project” process, as indicated in the communication management
approach.

Authorize the project

Based on the PID received from the “initiating a project” process, the project board
reviews the detailed business case to confirm the project viability. If so, it will verify
whether the proposed management approaches and project plan are adequate to realize
the business case and meet the project objectives. It will also request approval from the
corporate committee, customer, or program and receive validation for the project objec-
tives of costs, time, quality, scope, benefits, and risks. This activity is performed with the
“authorize a stage or exception plan”; the project board will then authorize the whole
project delivery. This activates the process “controlling a stage” for the first delivery stage.
If the project is deemed as not worthwhile, it will be aborted and trigger the “closing a
project” process.

Authorize a stage or exception plan

Based on the stage or exception plan received from the “managing a stage boundary”
process, the project board assesses the stage performance and verifies whether the busi-
ness case is viable. If so, it will approve either

• the next stage plan and related product descriptions and the project manager will start
a “controlling a stage” process,
• or the exception or project plan (if it was impacted) that will replace the current stage
plan. The project manager will then complete the current stage with the “controlling a
stage” process.

Give ad hoc direction

The project board examines the highlight reports, potential ad hoc issues, or exception
reports received periodically by the project manager. It will then guide the project man-
ager or make decisions regarding the issues, changes, and risks.

81
 Authorize project closure

Based on the end project report and lessons report from the “closing a project” process,
the project board verifies the completeness of the project and the adequate transfer to
operations. It will then use the notification drafted by the project manager to inform the
external stakeholders of the official project closure.

Output

The project board does not produce anything; it only makes decisions and gives recom-
mendations. This process triggers several other processes when authorizing the project
initiation, the project delivery, the next stage, an exception plan, or the project closure.

3.5 Controlling a Stage

This process starts every time the project board approves the start of a new delivery stage.
Its purpose is to monitor the progress of the authorized work and control any potential
deviation from the stage plan to meet the project objectives. Focused on the stage prod-
uct delivery, this process covers the day-to-day tasks of the project manager.

Input

The baseline for monitoring the stage progress is the stage plan created by the project
manager during the previous stage in the “managing a stage boundary” process and
authorized by the project board in the “directing a project” process. In special cases, it
might have been replaced by an exception plan. Management procedures that will be fol-
lowed have been defined in the approved PID. Checkpoint reports will allow the project
manager to monitor the stage progress.

Activities

Several activities are performed while controlling a stage, as outlined in the following
paragraphs.

Work packages

The following tasks must be performed in relation to work packages:

82
• authorize a work package: The delivery teams cannot start work until they receive the
formal authorization from the project manager by the means of a work package. In the
work package, the project manager defines the products they must deliver during the
stage, by when, how the progress and issues will be monitored, and how the quality will
be controlled.
• review work package status: The project manager has visibility on the work package
progress thanks to regular reports the team managers send. The format and regularity
of such reports are defined for each team in their work package.
• receive completed work packages: Once the work package products have been comple-
ted, the project manager checks the quality register to confirm the quality, verify that
they match the product descriptions, and confirm that the configuration item records Configuration item
have been updated accordingly. record
the list that tracks man-
agement and specialist
Monitoring and reporting products’ version, status,
variant, and interrelation-
ship
The following activities must be performed in relation to monitoring and reporting:

• review the management stage status: The project manager compares the checkpoint
reports with the work package and stage plan, assesses any deviation, and updates the
issue and risk registers accordingly.
• report highlights: The project manager consolidates the information from the check-
point reports and registers it in the highlight reports that are regularly sent to the
project board according to the frequency defined in the communication management
approach.

Issues and risks

The following actions must be performed in relation to issues and risks that may arise:

• capture and examine issues and risks: The project manager must keep track of and con-
trol the identified risks and issues. Issues will be formally captured in the issue register
and will follow the agreed change control approach. Risks will be assessed in the risk
register and managed as defined in the risk management approach.
• take corrective action: With the support of the project team, the project manager must
find and implement actions that correct the deviations from the baseline plan. Reports,
registers, and plans will then be updated with the impacted changes.
• escalate issues and risks: If the issues and risks cannot be resolved within the author-
ized stage tolerances, the project manager will raise an exception report to the project
board, who will decide upon the adequate action.

Output

The project manager will deliver the finished work packages and update the plans,
reports, and registers with the information that occurred during that stage.

83
 3.6 Managing Product Delivery
This is the process of the delivery teams coordinated by the team managers, who must
ensure the plan is feasible and that the team understands the work to be performed and
its associated constraints. The team managers must enable the project manager’s visibil-
ity and control of the work progress and get the finished product approved in accordance
with the required quality.

Input

The delivery teams can only start working once the team managers receive the authorized
work packages from the project manager.

Activities

Several activities must be performed while managing a product delivery, as outlined in the
following paragraphs.

Accept a work package

The team managers must first understand the content of the work packages and ask for
information if needed. They assess the work’s feasibility and constraints. If they believe it
is not achievable, they will negotiate adjustments with the project manager. Once agreed,
the team managers might elaborate a detailed team plan for the project manager’s appro-
val.

Execute a work package

The team managers must ensure that the products are developed according to the
requirements, and quality criteria, and acceptable tolerances defined in the product
descriptions. Otherwise, they must address the issue with the project manager. They will
also ensure the quality of the product according to the control management approach,
that the quality register is fulfilled properly, and that the finished products are verified.
Team managers provide the project manager with the progress status in the checkpoint
reports according to the frequency specified in the work package.

Deliver a work package

The team managers deliver the approved products according to the defined procedure
and notify the project manager after verifying that the registers, configuration item
records, approval records, and team plan have been updated accurately.

Output

In this process, the team managers produce the team plan, give regular checkpoint
reports, update the registers, and deliver the completed work packages.

84
3.7 Managing Stage Boundaries
Following the PRINCE2® principles “manage by stage” and “continued business justifica-
tion,” a stage cannot start until the previous one is completed and reviewed to verify
whether the business case is viable and the project worthy of pursuit. To facilitate the
project board’s decision, the project manager must provide all the stage assessments
along with other relevant information. Based on lessons learned from the closing stage, a
plan for the next one will be elaborated to request its execution. In the case of an excep-
tion, an exception plan will be submitted that will replace the current baseline.

Input

This process can be activated in two cases:

1. When approaching the end of a delivery stage, except the final one
2. At any time during a stage when an exception report has been raised and the project
board has requested an exception plan

The project manager collects all the baselines, registers, and reports produced during the
stage to make its evaluation.

Activities

Several activities must be performed when managing stage boundaries, as outlined in the
following paragraphs.

Report management stage end

The project manager compares the actual achievements with the baseline plans and
objectives to assess the stage performance for cost, time, quality, scope, and risks. It is
also the opportunity to update the lessons log. The revised information is consolidated in
the end stage report.

Update the business case

With the support of the executive, who is accountable for the business case, the project
manager must review the business case with accurate data and consider any changes that
happened during the stage.

Update the project plan

The project plan must be updated with the progress, the identified issues and risks, and
the revised forecast for the next stage or exception plan.

85
 Plan the next management stage

Based on the approved PID and the changes that occurred during the current stage, the
project manager creates a detailed plan for the next stage using the product-based plan-
ning technique. The collaboration of the project board, the project assurance, the team
managers, and other specialists would strengthen the plan viability.

Produce an exception plan

In case of an exception, a new plan needs to be produced to reflect the impact of the devi-
ations. If the issue only exceeds the stage tolerances, the exception plan will replace the
current stage plan. If it is forecasted to exceed the tolerance of the whole project objec-
tives, the exception plan will be submitted to the project board, corporate board, cus-
tomer, or program management to replace the initially approved project plan.

Output

As a result of this process, all the registers, plans, and DIP must be updated. The project
manager will request the validation of the current stage completion based on the end
stage report. They will start the next stage according to the next stage plan. If there is an
exception, the project manager will present the exception plan.

3.8 Closing a Project

It is important to formally close the project to end the team’s responsibilities and notify all
the stakeholders. It is a key milestone when the customer officially accepts the project
product delivery and confirms nothing more is expected. Formally closing a project can
also be to concede its premature end; it is also an opportunity to review the forecasted
benefits that the project outcome could generate.

Input

This process can be activated in two cases:

1. When approaching the end of the final stage

2. Whenever the project board decides to stop the project, either because the business
case is no longer viable or by a lack of financing

The DIP, the benefits management approach, plans, all the registers, and reports will be
used to evaluate the project.

Activities

Several activities are necessary for closing a project, as outlined in the following para-
graphs.

86
Prepare planned closure

With the help of the project support, the project manager verifies the product status
account to ensure that all the specialist products have been controlled, approved, and
delivered as agreed in the project product description. The project plan should also be
updated with the current project information.

Prepare premature closure

Although the project must be closed, the project manager should identify in the product
status account the valuable items that can still be delivered or used in the future. In some
cases, an exception might be granted by the project board to finish a profitable product.

Handover products

When delivering the project product, the project team must enable the good use, mainte-
nance, and improvement of the product by providing instruction, documentation, train-
ing, or a list of activities that remain to be performed. The project manager should also
confirm the acceptance from the business and operational teams.

The benefits management approach should be reviewed with the lessons taken from the
project, as well as from the changes that might have occurred on the project product or in
the external environment.

Evaluate the project

The project manager compares what had initially been planned with what occurred dur-
ing the project to assess the performance and take lessons about issues and good practi-
ces. Lessons learned can also be gathered by the project team and be registered in the les-
sons report for future projects.

Recommend project closure

The project manager will raise a closure recommendation to the project board, presenting
the end project report and lessons report. A communication of the project closure will be
drafted for the project board to notify the relevant stakeholders following the communica-
tion management approach. The daily log, lessons log, issue register, risk register, and
quality register can now be closed.

87
 Output

The end project report, the lessons report, and the closure notification will be submitted
to the project board with the recommendation to formally close the project. The updated
management products can now be closed and stored, except the benefits management
approach, which will serve to confirm the realization of the benefits by the operational
team.

SUMMARY
The seven PRINCE2® processes describe what should be done, by whom,
and by when. Interdependent, they transform the output of previous
processes into new ones. A pre-study is performed by the project execu-
tive and project manager during the “starting up a project” phase to
assess whether the project business case is viable, desirable, and feasi-
ble. If so, the project board will approve the official start of the project in
its unique process, called “directing a project.” The project manager can
then start defining and planning the project approach in “initiating a
project” and request its execution. At the same time, the project man-
ager presents the detailed stage plan, elaborated during the “managing
a stage boundary” process, for the first stage.

Every time the project board authorizes a new delivery stage, the project
manager will monitor its progress and take actions to meet the objec-
tives in “controlling a stage.” They will also provide the team managers
with their corresponding work packages, which give permission for the
delivery team to start working. The team managers supervise and report
its progress to the project manager in “managing product delivery.”

At the end of every delivery stage, the project manager will perform a
stage assessment and create the next stage plan to be submitted to the
project board. The stage plan must always verify that the project is still
worth being pursued; otherwise, it should be stopped. When ending the
final stage, the project manager will verify the finished products to be
given to the operational teams before recommending the formal project
closure to the project board. The project performance will be assessed
against the initial plan to report lessons; the benefits forecast will be
reviewed; and the management products must be updated, closed, and
stored.

88
 UNIT 4
CREATION OF RESULTS

STUDY GOALS

On completion of this unit, you will be able to...

– create project management documentation.

– implement an efficient project work structure.
– identify the required activities of a project.
– understand the complexity of the delivery team.
 4. CREATION OF RESULTS

Introduction
When reading about the PRINCE2® best practices, we can easily understand the principles
that govern them and what we aim to achieve by managing each theme. However, it can
be difficult to understand what the project team produces in the different processes and,
thus, how to put it into practice. PRINCE2® differentiates two types of products that the
project delivery team produces for the business and the “management products” that are
created and used to plan and manage the project itself (AXELOS Limited, 2017, pp.289–
332).

This unit describes which elements each of the PRINCE2® management products are com-
posed of and what should be considered when planning and organizing the work of the
delivery team.

4.1 Creation of Management Products

To follow the principle of “tailor to suit the project environment,” there are no PRINCE2®
requirements regarding the format of the management products. Therefore, they are not
called project documentation. They can be created as a document, presentation slides, a
meeting, or a database, for instance. They are distinguished into three types:

1. The baselines define and plan the project. Approved by the project board, they are
used as a reference.
2. The registers are dynamic lists that are updated while executing the project.
3. The reports capture the status of project items at a specific moment.

Project Brief

The project brief is the result of the information collected during “starting up a project” as
a pre-study to verify how worthy the project is for implementation. Based on the initial
mandate and collected lessons, it would typically include the following:

• project definition: background; problem or need; expected outcomes; objectives; and

tolerances for time, costs, benefits, scope, quality, and risks
• business case outline: justifies the project and includes the different options possible
with the recommended one
• project product description: describes the customer’s quality requirements and accept-
ance criteria
• project approach: the selected project management and delivery methods
• project management structure: with the role descriptions

90
As a baseline, the project brief is submitted to the project board to request the formal ini-
tiation of the project.

Project Product Description

The project product description defines what the project should deliver to satisfy the cus-
tomer’s needs and quality expectations. Created during “starting up a project” and refined
during the initiation, this baseline is the reference to verify if the acceptance criteria have
been met before the product delivery and project closure. Based on the customer’s initial
mandate and subsequent discussions with the project executive and senior user(s), it
should comprise the following aspects:

• name of the project

• purpose: customer’s need to satisfy, target users, major constraints
• composition: a list of the major deliverables
• derivation: existing source(s) of information that clarify the project product (e.g., man-
date, existing feasibility study, regulations to be applied) or the existing product(s) that
will be modified or replaced
• customer’s quality expectations, required standards, and processes
• acceptance criteria: a list of measurable and prioritized criteria
• project-level quality tolerances: acceptable deviation from the targeted quality criteria
• acceptance method: how it will be confirmed and formalized
• acceptance responsibilities: who will confirm it
• required skills: necessary for the product development

Daily Log

The daily log is like a project journal where the project manager notes useful information
that does not yet fit in any other management product. Created during “starting up a proc-
ess,” this register can contain the risks while the register is not set up, issues, and informa-
tion that needs to be formalized.

Lessons Log

Created during “starting up a process,” the lessons log gathers all the lessons from exter-
nal experiences and lessons from the project that can be helpful for future projects.
Although any format can be employed, the best way is to use a database with an efficient
taxonomy and a great search function. Each entry of this register could be characterized
by the following items:

• type of lesson, project, subject, etc.

• lesson details with a description, root causes, and recommendations
• date of identification
• level of priority or criticality

91
 Lesson Report

A lesson can be detailed in a lesson report if it needs to be explained, shared with another
organization, or formalized to initiate a specific action within or outside of the project.

Project Initiation Document (PID)

The PID gathers all the documentation and information developed during the “initiate a
project” process. With the collaboration of the project management team and experts, the
project manager completes the project brief in detail and includes the following informa-
tion and management products:

• project definition
• project approach
• business case
• project team structure and the role descriptions
• quality management approach
• change control approach
• risk management approach
• communication management approach
• project plan
• project controls (the level, means, and frequency of project monitoring according to
defined objective tolerances)
• tailoring of PRINCE2® (how PRINCE2® will be adapted to the project needs)

As a baseline, the PID is submitted to the project board to request the production and
delivery of the planned project. Once approved, it becomes the reference and strong
guideline for the whole project team.

Business Case

Outlined during “starting up a project” and detailed further in the project initiation docu-
mentation, the business case is a baseline that demonstrates the viability, desirability, and
feasibility of the project. It includes the following aspects:

• Executive summaries explain the purpose of the project.

• Reasons explain the need or problem that the project covers and how it is aligned with
the corporate strategy.
• Business options typically include the impact analysis of at least three situations (if
nothing is done, if the minimum is done, or if the recommended option is used).
• Expected benefits and dis-benefits are the tangible and intangible benefits and the
known disadvantages. It also specifies the benefits’ objectives and tolerances to meet
to be profitable.
• Costs include the project costs and the operational ones that the project will generate
after delivery of its product.
• Return on investment should represent a profitable balance between quantified bene-
fits, costs, and dis-benefits.

92
• There will be a timescale outlining the project and the period when the benefits will be
generated.
• All major risks will also be included.

Under the responsibility of the project executive, the business case must be regularly
updated by the project manager and reviewed by the project board to verify the “contin-
ued business justification.”

Benefits Management Approach

The benefits management approach defines when and how actual benefits can be verified
to confirm the expected business case. This baseline is created during the initiation but is
the only one not integrated in the PID because it will remain active after the project clo-
sure to confirm the expected benefits. It contains the following aspects:

• scope: which benefits will be measured over which period of time

• accountable person: responsible for generating the expected benefits
• management actions: to ensure the realization of the benefits
• measurements: metrics, processes, and tools of measurement
• performance assessment: comparing with the baseline
• resources: needed for the measurements and assessments

Communication Management Approach

Based on the stakeholder analysis, the communication management approach plans what
will be communicated to whom, by whom, when, and how. Integrated in the PID during
the initiation, it details the following aspects:

• procedure: processes and means of communication, including the corporate standards

to be followed
• tools and techniques: for each step of the process, including the documentation or sys-
tems to be used
• register and reporting: its format, the categories, the frequency, the metrics, etc.
• roles and responsibilities: involved in the communication management
• timing: frequency of the communication activities
• stakeholder analysis: identification, evaluation, and action needed

Risk Management Approach

The risk management approach is built from the project brief and the planning output
with the aim of anticipating and controlling the maximum number of risks possible. Inclu-
ded in the PID during the initiation, this baseline describes how the risk will be managed
by defining the following aspects:

• responsible: for the risk management approach

• procedure: how and when the risks will be identified, assessed, addressed, reviewed,
and communicated

93
 • tools and techniques: for each step of the process, including the documentation, sys-
tems to be used, or how to calculate the risk value
• risk register: its format, the categories, the scales of risk impact, probability, proximity
and severity, the types of risk response, etc.
• roles and responsibilities: involved in the risk management
• risk exposure: the acceptable total level of risk and related tolerances that the project
can assume while remaining viable
• risk budget: how it will be determined and used

Risk Register

The risk register is used to track the identified risks, their assessment, the decisions made,
and their status. Once its format is defined in the risk management approach, the risk reg-
ister can be created during the initiation. It is filled out with the risks collected during the
“starting-up a project” process and completed with the ones identified during the project.
Continuously reviewed and updated, this record is usually a list, in any kind of document,
spreadsheet, or database, with one entry for each risk and columns that commonly record
the following aspects:

• risk identifier: as a unique reference for every risk

• risk author: who raised the risk
• date: when the risk was identified
• risk category: department or topic, which will help determine an owner
• risk owner: responsible for managing and monitoring the risk
• risk description: cause, event (threat or opportunity), and effect
• probability: based on the defined scale levels of likelihood for the risk to occur
• impact: based on the defined scale levels of effect the risk would have on the project
objectives
• criticality/severity/priority: global level of importance of the risk, result of the probabil-
ity and impact, according to the chosen scale or calculation
• expected value: monetary value of the risk based on its financial impact and probability
of occurrence
• proximity: period when the risk event is foreseen to happen
• risk response type: how the risk will be addressed (e.g., avoid, reduce, accept)
• risk response: action(s) to be taken to resolve the risk
• risk status: active or closed
• risk actionee: the PRINCE2® term used to refer to the person who will execute the action
described in the risk response

Quality Management Approach

The quality management approach is defined based on the project product description
and the corporate quality standards with the aim of meeting the customer’s quality
expectations. Included in the PID during the initiation, this baseline describes how the
quality will be ensured and controlled by specifying the following aspects:

94
• responsible: for the quality management approach
• procedure: processes, timing, and means of quality planning, quality assurance (to
ensure the quality while producing), and quality control (to verify the finished products)
• tools and techniques: for each step of the process, including the documentation or sys-
tems to be used, and the means of control and measure
• register and reporting: its format, the categories, the frequency, the metrics, etc.
• roles and responsibilities: involved in the quality management

Quality Register

Based on the quality criteria defined in the product descriptions, the quality register
tracks all the quality controls to be performed and their status. It is verified to prepare the
end stage and end project reports. Once its format is defined in the quality management
approach, this register can be created during the initiation to record the following aspects:

• quality identifier: as a unique reference for every activity to be performed

• product: name and unique identifier of the product that the related quality activity
must control
• method(s): type of control, procedure to be followed, or monitoring and controlling
tools to be used
• roles and responsibilities: involved in the quality management
• date(s): when the quality activity must be performed
• result: pass or fail; in case of failure, corrective actions must be tracked, either in the
quality register or in the issue register
• quality records: reference to external sources for product inspection or for tracking the
corrective actions

Change Control Approach

The change control approach is based on the corporate governance standards and quality
management approach with the aim of transparency over the project progress and to con-
trol deviations from the plans. Included in the PID during the initiation, this baseline
describes how the issues will be managed and the changes controlled by specifying the
following aspects:

• responsible: for the change control approach

• procedure: of how and when the issues and changes will be monitored, identified,
assessed, reported, controlled, and communicated
• tools and techniques: for each step of the procedure, including the documentation or
systems to be used
• register and reporting: the format of the issue register, the issue reports, and the excep-
tion reports, but also their categories, the scales of issue impact, priority, severity, and
the types of issues
• roles and responsibilities: involved in the issue management and change control proce-
dure
• change budget: how it will be determined and used

95
 Issue Register

The issue register is used to track any deviation from the plan that needs to be managed,
their assessment, the decisions, the action plan, and its status. Once its format is defined
in the change control approach, this register can be created during the initiation. It is typi-
cally a list in any kind of document, spreadsheet, or database, with one identified entry for
each issue and columns that commonly record the following aspects:

• issue identifier: as a unique reference for every issue

• issuer: who raised the issue
• date: when the issue was identified
• issue type: called “request for change,” “off-specification,” and “problem or concern” in
PRINCE2®
• issue description: event, cause, and impact.
• priority: based on the defined scale levels, categories, and urgency.
• criticality/severity: importance of the issue and management escalation level, deter-
mined by the impact on the project or stage objectives and tolerances
• issue owner: responsible for managing and monitoring the issue
• status: active or closed
• issue report: reference to the corresponding report, if any
• closure date

Issue Report

A particular issue can be detailed in an issue report to formalize a decision. Based on the
issue register information, this report contains the following information:

• issue identifier: as a unique reference for every issue

• date: when the issue was identified
• report author: who raised the issue
• issue type: called “request for change,” “off-specification,” and “problem or concern” in
PRINCE2®
• issue description: event, cause, and impact
• impact analysis: a detailed list and assessment of the impacted objectives and products
• priority: based on the defined scale levels, categories, and urgency
• criticality/severity: importance of the issue and management escalation level, deter-
mined by the impact on the project or stage objectives and tolerances
• recommendation: solution proposed by the project manager
• decision: accept, reject, on hold, or alternative
• issue owner: responsible for managing and monitoring the issue
• approver: which authority made the decision
• approval and closure dates

Exception Report

If an issue’s impact is predicted to exceed the tolerances fixed on the stage or project
objectives, the project manager will report an exception. Based on the issue register infor-
mation, this report contains the following information:

96
• exception description: event, cause, and impact on the business case
• options: what can be done to correct the deviation or what would happen if nothing
were done, along with the pros and cons of each action
• recommendation: solution proposed by the project manager
• decision (from the project board): accept, reject, on hold, or alternative
• approval date
• lessons learned: from the exception

Plan

PRINCE2® proposes different types of plans at the three management levels: the high-level
project plan is defined during the initiation, the stage plan and exception plan are created
during “managing a stage boundary,” and the detailed team plan is proposed by the team
manager in “managing product delivery.” Elaborated with the PRINCE2® product-based
planning technique, the plan baselines define how to achieve the project goals with the
following information:

• description: which plan and which management approach

• prerequisites: what should be in place for the plan to be successful
• external dependencies: can impact the plan
• assumptions: hypothesis on which the plan is built
• lessons: from previous projects or stages
• monitoring and control: when, how, and by whom
• budgets: to cover resource time and costs, risks, and changes
• tolerances: acceptable deviation from the plan objectives
• product descriptions: of the plan scope
• schedule: plan timeline

Product Description

The PRINCE2® product-based planning technique leads to the product breakdown struc-
ture (PBS), which details all the elements that compose the project product. With the help Product breakdown
of business end-users, a full comprehension of these components is analyzed and docu- structure
an organigram of all the
mented in the product descriptions during the initiation. Integrated in the project and items that compose the
stage plans, this baseline will be used by the project team to understand the following project outcome
items:

• product name and identifier

• purpose: need to satisfy, target users, major constraints, and future use
• composition: list of the product items
• derivation: existing source(s) of information that helps understand the product (e.g.,
mandate, existing feasibility study, and regulations to be applied) or the existing prod-
uct(s) that will be modified or replaced
• characteristics: product appearance, format, and constraints
• quality criteria: list of prioritized product specifications and measurable levels of quality
• quality tolerances: acceptable deviation from the targeted quality criteria
• quality method: how the product quality will be controlled and formalized

97
 • quality responsibilities: the producer(s), reviewer(s), and approver(s) of the product
• required skills and resources: for the product development

Work Package

Once the project board approves the project execution after the initiation, the project
manager defines the work packages that the delivery teams will produce. Created at the
beginning of “controlling a stage” and agreed upon by the team managers during “manag-
ing product delivery,” this baseline gives the formal authorization and serves as a guide-
line to produce the project deliverables. Aligned with the stage plan, each work package
includes the following items:

• agreement date
• team manager
• description: the work to be done
• techniques and procedures: tools, systems, standards, or processes to be used
• interfaces: other interdependent products or stakeholders
• configuration management requirements: to track and communicate the product ver-
sioning
• joint agreements: about the effort, time, cost, quality, key milestones, etc.
• tolerances: acceptable deviation from the agreed objectives
• reporting: the format, content, and frequency of the checkpoint reports
• problem management: escalation procedure to raise issues and risks
• references: or extracts from useful external sources of information (e.g., product
description(s), design, stage plan)
• approval method: who will approve the product and how it will be communicated to
the project manager

Configuration Item Record

Configuration management tracks the versions and status of all the management and spe-
cialist products identified in the product breakdown structure and the relationships
among them. Registered by the project support in the configuration item record that was
defined in the change control approach, products are identified by the following aspects:

• identifier: name of the product and the covering project

• current version: and last change date
• location: where it is stored
• item type: and attributes of the product
• timeline: when the product should be developed and delivered
• producer(s): responsible for the product development
• owners: to whom the product will be handed over
• end-users
• status: pending, in development, in review, approved, or handed over
• interdependences: relationships with other items, issues, risks, or external documenta-
tion

98
Product Status Account

The product status account is a report that provides the status of one or several manage-
ment and specialist products. Requested by the project status on behalf of the project
manager, the information is based on the configuration item record

• report scope: for the whole project, a stage, a supplier, or a work package
• date of issue
• product status: with all the information from the configuration item record (version, sta-
tus, owner, producer, location, baseline, and actual dates)

Highlight Report

As defined in the communication management approach, the highlight report is provided

by the project manager periodically. This report updates the stage progress for the project
board with the following information:

• date of report and covered period

• status summary
• completed work during the current period
• upcoming work for the next report
• stage performance comparison of cost, time, quality and scope against the stage objec-
tives and acceptable tolerances
• key issues, risks, and requests for change
• lessons learned

Checkpoint Report

As defined in the communication management approach, the checkpoint report is provi-

ded by team managers periodically. This report gives updates on the work package pro-
gress to the project manager with the following information:

• date of the report and covered period

• follow-up from the previous report
• upcoming work for the next report
• stage performance comparison of costs, time, quality, and scope against the work pack-
age objectives and acceptable tolerances
• issues and risks

End Stage Report

Developed by the project manager during “managing a stage boundary,” the end stage
report provides a summary of the current stage. This report is submitted to the project
board to review the project performance and business case before approving the stage
completion and deciding to continue the project. It includes the following:

• stage performance summary

• review of the project objectives of cost, time, quality, scope, benefits, and risks

99
 • review of the business case
• review of the stage objectives of costs, time, quality, scope, and risks
• review of the team performance
• review of the products for quality records, approved products, off-specifications, and
possible handovers
• issues and risks
• forecast for the next stage and the rest of the project
• lessons learned

End Project Report

Assembled by the project manager during “closing a project,” the end project report
assesses the project performance against what was planned in the PID. Its aim is to learn
lessons for future projects. This report will be submitted to the project board to request
the formal project closure. It includes the following:

• project performance summary

• review of the project objectives for cost, time, quality, scope, benefits and risks, and
evaluation of the efficiency of the project approaches and controls
• review of the business case to explain deviations and review the expected benefits
• review of the stage objectives for of costs, time, quality, scope, and risks
• review of the team performance and to recognize the good work
• review of the products for quality records, approved products, off-specifications, hand-
over, and follow-up actions to be assigned to operations
• lessons learned from the lessons log

4.2 Creation of Specialist Products

The specialist products refer to all the items that need to be created or acquired before
being assembled to form the global project deliverable that will be given to the customer
or operations. They vary depending on the nature and industry of the project.

The goals-and-methods matrix by Turner and Cochrane (1993, pp. 94–95) classifies
projects into four types, depending on how well-defined the project goals and methods
are:

1. Earth: Thanks to repetitive experience, the goals and methods are clearly defined for a
solid foundation, which should ensure high chances of success. Examples of this
include engineering and construction.
2. Water: Poor in methods because it had never been done before, this type of project
flows intuitively, led by a clear goal. Examples of this include product development
and process improvement.

100
3. Fire: Supported by strong methods and hard work, the results can burn into ashes
because goals or user requirements are difficult to specify. Examples of this include
application software development and making a movie.
4. Air: Both goals and methods are unclear, which would make the chances of failure
higher. Examples of this include research, innovation, and organizational changes.

Since the types of projects and their related outcome vary so much across industries,
PRINCE2® cannot recommend universal standards on how to build the project delivera-
bles. However, it provides methods to identify and document their description for a full
and common understanding from all involved stakeholders.

Product Breakdown Structure (PBS)

The PRINCE2® product-based planning technique recommends starting by fully under-

standing the customer’s needs and the project product, i.e., the overall output that will be
delivered by the project. It is defined in the project product description, which includes
the customer’s requirements and the project acceptance criteria.

During the initiation, the project team brainstorms to decompose the global outcome into
a product breakdown structure (PBS). The PBS is a hierarchical organigram of all the fin-
ished sub-products, called “specialist products” (Cox, 2021, pp. 111–122). The figure
below provides the PBS for building a house.

Figure 8: The Product Breakdown Structure for Constructing a House

Source: Caroline Naudin (2022).

101
 The number of hierarchical levels depends on the project complexity and required accu-
racy. We could break down the product “1.4.5 Kitchen equipment” further to list the fitted
kitchen units, sink, fridge, and so on. Each is a specialist product. Decomposing the
project product into smaller items allows us to

• better understand the full scope and prioritize its items.

• precisely describe the attributes, constraints, and expected quality criteria for each ele-
ment in the product descriptions.
• determine the required activities and skills to produce or get them. This can be illustra-
ted in a similar organigram but this time by decomposing all the tasks to be performed
Work breakdown in a work breakdown structure (WBS).
structure • identify the human and material resources needed to complete it.
an organigram of all the
activities necessary to • estimate the effort, time, and costs for each activity, which will be consolidated later for
realize the project the whole project.

The specialist product can also be arranged in a product flow diagram that will show the
order of production. This helps determine the sequence of activities and anticipate when
each should be performed. Activities must then fit in a calendar, which also depends on
the resource availability that must be verified when planning the project.

For example, one of the specialist products of the house in the figure above is the terrace,
which will be covered with concrete. This is one of the latest items of the diagram and plan
because there are no successive specialist products afterward. However, if the terrace is
planned to be done by mid-August so the house will be complete by end of August, we
need to ensure that the concrete supplier will be available for the planned date; other-
wise, the whole project delivery might be delayed. Additionally, if it is found that some
pillars belonging to the town would prevent the concreting truck to access the building
site, a municipal authorization would be needed to remove them before August. It might
take two months to get the authorization and task done. Therefore, the request for an
additional specialist product should be submitted to the municipality no later than the
beginning of June.

Product Project Life Cycle

Once the specialist products have been identified, how can we proceed in order to build
them? Most of the projects can follow a similar life cycle for the elaboration of the prod-
ucts. The 2002 version of PRINCE2® (Office of Government Commerce, 2002, p. 7) sugges-
ted the following product life span, which is included the project period:

• before the project: ideation, market study, and initiative trigger

• specify: collection of the requirements
• design: of the solution
• develop: acquire and create the products
• test: verify the product quality
• change over: deliver the product to the business
• after the project delivery: value assessment, use, and scrap

102
Likewise, Kerzner (2009, p. 73) proposes the following phases according to the project
industry:

• engineering: start-up, definition, main, and termination

• manufacturing: formation, buildup, production, phase-out, and final audit
• computer programming: conceptualization, planning, definition and design, implemen-
tation, and conversion
• construction: planning, data gathering and procedures, studies and basic engineering,
major review, detail engineering and construction overlap, construction, and testing
and commissioning

Work Packages

Most of the project management methodologies suggest integrating the project activities
into a WBS. The WBS is a hierarchical organigram of all the activities required to realize the
project, including the project management activities and those necessary to build the
product. A best practice is to decompose the project work into independent, manageable
pieces, called work packages, on which we can perform the following (Kerzner, 2009, pp.
434–439):

• Identify resources and assign responsibilities.

• Estimate required effort duration and costs.
• Define measurable performance targets and means of control, including the progress
and quality.

The WBS does not contain finished deliverables but rather actions that can be organized
by chronology, domain, job, or product, according to the project manager’s logic. This
hierarchical structure can be listed in a file, like in the example below, to report all the rel-
evant information for each task and design the corresponding Gantt chart. Gantt chart
avisual schedule of
project activities repre-
Table 2: Example of a WBS List for Constructing a House sented in a calendar by
bars, whose length is pro-
portional to the task
WBS Duration Resources Costs in € Completed
duration
work

1 Foundation 35 days 30,400 82%

1.1 Excavate 12 days 12,000 100%

1.1.1 Pour concrete 2 days A. Smith 2,000 100%

1.1.2 Cure and strip 10 days A. Smith 10,000 100%

1.2 Erect steel 23 days 18,400 70%

1.2.1 Install columns 8 days C. Perez 6,400 100%

1.2.2 Install beams 10 days C. Perez 8,000 70%

1.2.3 Install joist 5 days C. Perez 4,000 40%

103
 WBS Duration Resources Costs in € Completed
work

2 Utilities 65 days 48,500 0%

2.1 Plumbing 15 days 12,900 0%

2.1.1 Rough in plumbing 8 days P. Durand 6,400 0%

2.1.2 Set plumbing fixtures 5 days P. Durand 4,000 0%

2.1.3 Test and clean 2 days J. Muller 2,500 0%

… … … … …

Source: Caroline Naudin (2022).

As explained in the process “managing product delivery” (AXELOS Limited, 2017, pp. 236–
241), the work should not start without the stage approval from the project board. The
project manager formalizes the authorization by providing work packages and the corre-
sponding product descriptions to the delivery team managers. The delivery team manag-
ers, who defend the interests of the delivery teams, must verify the content of the work
package before accepting it to ensure that

• there are no assumptions or misunderstandings by requesting clarification.

• the plan is feasible; otherwise, they should negotiate the constraints adequately.

The work package contains the list of deliverables, planned estimations, communication
channels, and processes. In case of issues, it contains the means (checkpoint report, meet-
ings) and frequency for the project manager to be able to control the production progress,
as well as the methods for product quality control, validation, and delivery.

This supports the delivery teams in creating the products described in the product
descriptions according to the quality criteria and objectives set in the work package.
Teams should meet regularly to share their progress with their team manager. If a devia-
tion from the plan or other issues occur, they should be notified as soon as possible. The
team and their manager might be able to resolve it themselves unless the impact exceeds
the work package tolerances. In this case, the team manager must raise the problem to
the project manager, who might formalize it in the issue register.

Once a specialist product is finished, its quality must be verified before delivery. Again, the
means of quality control will differ depending on the product. An electrician, for example,
will use a voltmeter to verify the energy in every room of the house, while a plumber
would probably make sure the water flows in all the pipes to verify there are no leaks.
When all the specialist products are completed and assembled, a control over the whole
project product must be performed. This can be an audit to the whole house energy con-
sumption, isolation, and ecological level, for instance.

104
Only after validation of the product completion and quality can the project board approve
its delivery to the customer. The delivery team should remain available for a few weeks to
ensure a service support to fix issues after the delivery or to assist the client in using the
new products.

SUMMARY
The management products help the project team define the project
approach, plan its activities, track the project information, and commu-
nicate it. The baselines serve as guidelines for the project team and as a
reference for management to assess the project performance. The regis-
ters are used to track the project progress and occurring events, while
the reports capture the status of an item at a specific moment.

The specialist products are created by the delivery teams according to

the product descriptions and the work packages provided by the project
manager. The product breakdown structure is a good technique from
the PRINCE2® product-based planning procedure to identify all the items
that compose the project product. The different steps to produce them
vary from one industry to another, so the project manager should rely on
the experts’ experience and industry standards.

105
 UNIT 5
TAILORING

STUDY GOALS

On completion of this unit, you will be able to...

– distinguish tailoring and embedding PRINCE2®.

– adapt PRINCE2® to your projects and organization.
– exemplify what can be tailored.
– integrate PRINCE2® with other methods.
 5. TAILORING

Introduction
PRINCE2® gathers a multitude of best practices and rules that can seem overwhelming
and bureaucratic when improperly tailored. Indeed, tailoring is mandatory, following the
PRINCE2® principle “tailor to suit the project.” The method and related effort of adminis-
tration must be adjusted to the project’s needs, which vary according to the project type
and its environment.

Nevertheless, PRINCE2® is not a toolbox from which a few items can be selected when
they might be useful. The framework is a whole web of interdependent, supporting ele-
ments. Therefore, they must be maintained, although they can and must be adapted for
every project.

What makes a project a PRINCE2® project? Projects can vary by type, complexity, size, criti-
cality, and environment. PRINCE2® is flexible enough to be tailored to each project and its
organization. However, a few requirements are necessary to be followed to consider that
the project is managed according to PRINCE2®:

• the seven principles: Each principle must be applied unaltered because they are univer-
sal, as per the PRINCE2® definition.
• the seven themes: None can be discarded, but the project manager decides how they
will be managed and controlled, by whom, and with which techniques. Yet, the
PRINCE2® minimum requirements for each theme and their purpose must be preserved.
• the seven processes: They transform the themes into management products. None can
be ignored, but they can be combined, simplified, or amplified according to the activi-
ties and responsibilities.
• the eight project management roles: None can be removed, but they can be combined
to be covered by a single person or distributed according to the corresponding respon-
sibilities, as long as there is no conflict of interest or accountability.
• the six project variables: These might be fixed or flexible according to the performance
targets.
• the management products: These are created by the project management roles during
the processes to support the themes. Their format is unspecified and can be combined
into a database or split into different files. Others can be added and defined in the
Product description product description.
a detailed definition of • the terminology: This can be changed to fit the organization’s or other in-use method’s
each component of the
project deliverables language but must be applied consistently within the organization or the project.

This unit will discuss how PRINCE2® can be integrated into an organization, how it can be
adapted to the project – particularly in terms of roles – and how it can be combined with
other project management approaches (AXELOS Limited, 2017, pp. 30–40, 271–288).

108
The project manager defines and documents the project tailoring in the project initiation
documentation (PID). The key when adapting PRINCE2® is to apply an adequate degree of
planning, control, and governance, depending on the level of risks, without overloading
the project. The PRINCE2® and tailoring elements should add value to the project manage-
ment work. It is then approved by the project board, who must ensure that the adaptation
will not jeopardize the achievement of the project objectives.

5.1 Tailoring of PRINCE2® to the

Organization
When starting a new project, one of the project manager’s first concerns is knowing what
the organization expects and how to meet these expectations. Depending on the organiza-
tion’s level of maturity, guidelines should be provided to support the project manager’s
work. Unfortunately, these guidelines are not always clear. Usually, project-oriented com-
panies or institutions have defined rules, standards, and templates to govern projects
more efficiently and successfully. The AXELOS Limited’s book P3M3® Maturity Model
(2015a) explains how to identify the organization’s project management capabilities and
how to improve them when implementing PRINCE2®.

Setting up a common method for the organization enables its members to share and
apply best practices, which improves the project’s success. It also increases the project
management efficiency thanks to standard templates, processes, and checklists that
guide the teams. Harmonizing the practices offers more clarity about the responsibilities
of identified roles and facilitates communication with a common vocabulary. Besides,
harmonized data can help the organization consolidate them at the portfolio level for a
holistic picture, data comparison, project selection, monitoring, and control.

Organization’s Tailoring

PRINCE2® also needs to be tailored according to the organization’s specifications. For

example, particular procedures and management products might be needed to fulfill com-
pliance requirements for quality certifications, legal regulations, or safety measures. The
organization might also use the same project life cycle for its projects. For example, a
mechanical engineering society will apply the same sequence of steps for all their projects
to build customized machines for their clients. They generally have pre-defined stages and
processes that include a list of required deliverables for each stage. It can be combined
with PRINCE2® by adjusting the activities of each process and adding any required man-
agement products. The format of the management products is usually defined by the
organization.

PRINCE2® terminology can also be modified to integrate the industry or corporate lan-
guage. For instance, if most of the business units use the term “project closure report” (the
equivalent of the PRINCE2® “end project report”), or “progress status” instead of “check-
point report,” the organization might prefer to keep these corporate terms instead of
changing to the PRINCE2® terms. A glossary might then be useful for everyone.

109
 Depending on the size of the organization, it might be difficult to identify the perfect per-
son for every PRINCE2® role. In a small start-up, the founder would certainly not have time
to embrace all the responsibilities of a project executive for all the company’s projects.
Instead of deciding against implementing PRINCE2®, a lighter version could be used. Con-
versely, if the organization’s complexity, hierarchy, and rigorous requirements need more
control over specific topics in a project, they could create other project management roles
in addition to the ones recommended by PRINCE2®. They can also split the different func-
tions between various actors to avoid overloading the employees.

It is often a “center of excellence,” like a project management office, that would have the
expertise to develop and deploy a standard method for the organization. The purpose of
the framework should be to share information appropriately to facilitate decision-making
and teamwork to improve business performance. The framework must follow the seven
PRINCE2® principles and adequately adapt the seven themes and processes. The impact
on the other PRINCE2® components must be verified for each tailored element. If several
organizations are involved in a project, they will have to agree on a combined approach,
the required procedures, and common terminology, as well as clearly define the project
roles and responsibilities.

Embedding PRINCE2® Within the Organization

To benefit from a corporate methodology, it must be widely used by its members. How
can an organization encourage its application? After defining the framework, it must be
fully integrated and understood in the group. This is referred to as embedding, which can
be accomplished by

• ensuring it is suitable for the whole organization, easy to understand, and quick to
apply.
• building a unique source of information.
• promoting it to ensure awareness.
• enabling the accessibility to the relevant information.
• developing skills by training the project actors and explaining what can be tailored from
PRINCE2® and the corporate standards.

Adopting a corporate methodology by all the project team members must be fostered by
change management techniques. Indeed, working on a new project with a new method
and tools implies a significant change, while people tend to be resistant to change. These
changes should be accompanied and awarded to ensure a collaborative, efficient use by
everyone.

A point that is not covered in the AXELOS Limited’s book (2017) but is a significant factor in
how PRINCE2® can suit an environment, is the organization’s culture. For example, small
but very dynamic structures could reject complex methods that might slow them down if
they cannot be simplified. People and cultures can also influence the methodic use of
PRINCE2®. Hinde (2018, pp. 3–16) discusses organizational culture and gives interesting
insights on the types of cultures and how PRINCE2® can fit them. Creating the right culture
and atmosphere is thus a key to successful project management.

110
5.2 Scaling of PRINCE2® by Combining
Roles
Even within the same organization, projects can be very different. A marketing event will
not be handled the same way as implementing a new business unit or deploying new soft-
ware. Besides, not all organizations will offer a PRINCE2®-based framework. The project
manager will, thus, need to adapt both PRINCE2® and the corporate standards to the
project specification and describe them in the project initiation documentation.

Tailoring to Project Constraints

Tailoring should consist of applying the minimum requirements from PRINCE2® and add-
ing only valuable elements for the project management. The purpose of adapting
PRINCE2® to the project is to set up the right level of control according to the degree of
project risk without overloading the project team or senior management.

For simple and predictable projects, a light version of the method should be used. By con-
trast, the more complex or uncertain a project is, the riskier it is. This is what determines
the levels of authority (i.e., the perimeter of responsibility and objective tolerances for
each role), means of monitoring, regularity of controls (e.g., the number of stages and fre-
quency of checkpoint reports), and decision-making process. The factors that can be con-
sidered when adapting PRINCE2® at the project level include the following:

• project size in terms of time, budget, number of actors

• complexity of the solution
• the level of risk
• skills and experience of the project team
• geographical location(s) for local rules, cultures, language, physical or remote teams,
ecological, and meteorological conditions
• the project life cycle model
• other management methods
• external partners, such as customer(s), supplier(s), and multi-organizational projects
• belonging to a program

From the project environment, the impacted organization(s), and countries, the following
should also be considered:

• corporate standards
• industry requirements
• organizational maturity, hierarchy, and stability
• organization’s priorities and project portfolio
• legal requirements
• economic, social, political, and ecological context

With the recommendations of the project assurance and project support, the project man-
ager must be able to tailor PRINCE2® according to the project specifications influenced by
the above factors. For instance, in the case of a short and simple project, the processes

111
 “starting up a project” and “initiating a project” could be combined. The same can be
done for projects that belong to a program where the pre-study was performed at the pro-
gram level. Another example could be to include particular quality assurance audits, roles,
and documentation in the theme “quality” to be compliant with some Interational Organi-
zation for Standardaization (ISO) norms to which the project is subject. Moreover, should
several methods be required for the same project, PRINCE2® must be compatible with the
other approaches by merging the processes, adapting the corresponding roles, and har-
monizing the vocabulary.

Tailoring the Project Organization

A major concern when tailoring PRINCE2® is the theme “organization” and the related
roles that are often difficult to identify within the organization, either due to a lack of
clarity, availability, authority, or skills. The key for the theme “organization” is “the right
people with the right experience need to be in the right roles, in the right numbers and at
the right time” (AXELOS Limited, 2017, p. 69). Support from the senior management is
often a big challenge, too.

PRINCE2® defines eight mandatory project management roles but does not specify the
number of individuals who should take them on. Indeed, these roles can be combined or
assigned to several people. The main rule is to avoid conflict of accountability or interest,
which is why the following roles cannot be combined:

• the executive and the project manager: The executive defends the interests of the busi-
ness, while the project manager defends those of the project delivery teams.
• the senior supplier and the senior user: The senior supplier represents the producers,
while the senior user represents those who receive the project outcome.
• the project assurance and the project manager: The project assurance supervises the
project manager on behalf of the project board. For the same reason, the project assur-
ance cannot be shared with the project support.

For tailoring, it is necessary to first understand and define the responsibilities of each role.
We can then split the functions between individuals if the project team members are not
100 percent allocated to the project. Nevertheless, it is important to remember that there
can be only one executive and one project manager because project accountability cannot
be shared.

An example of this can be how to allocate the activities of the project support: On one
side, an experienced project officer can set up all the project management tools and train
people on them. On the other side, a junior project support can help the project manager
update the management products and handle the configuration management.

Likewise, in the case of a complex project that delivers different solutions in parallel, like
the organization of a fair where there are sales stands and a virtual reality experience, it
may be useful to assign several change authorities who have distinct skills: one who could
judge changes regarding the marketing aspects and another one who has the technical
knowledge for the virtual reality machine. For small organizations or project teams, the
roles that can be combined include the following:

112
• The executive and the senior user can be combined when both come from the customer
environment.
• The project manager and the project support can be combined.
• The project manager and the team manager can be combined. If the project manager
has the required skills and knowledge, they can assume the role of team manager. In
such a case, work packages and checkpoint reports might not be relevant anymore or
the project manager can define individual work packages for the team members and
get progress reports directly from them.
• The project board and the project assurance can be combined when they have the time
and are close enough to the project.
• The change authority can be covered by the project board, the project manager, or the
project support within the same perimeter of authority defined for each of them.

Once the roles have been defined, it is important to review their scope of responsibility for
each process activity, their authority level, and the level of control for each theme, with
the purpose of verifying the global coherence or possible conflicts. The project manager
must then ensure that every actor fully understands and assumes their role and responsi-
bilities.

Note that, in a commercial relationship, PRINCE2® places the project manager within the
customer organization, but there would also often be a project manager on the provider
side. In this case, the supplier will have to first picture the full project from the customer’s
perspective before positioning itself within it in order to avoid duplicate roles and func-
tions.

5.3 Combining PRINCE2® With Other

Project Management Methods
PRINCE2® requires that a project life cycle must be followed, although it does not specify
any one. It is more efficient for a project manager to follow a standard that tracks most of
the steps and activities. The organization could create standardized life cycles by the type
of project to match its specifications and combine them with the PRINCE2® framework
implemented in the organization. This might also occur when an external partner follows
a model other than PRINCE2® and aligning the two is required to manage the project
together.

There exist several project management methods that can be combined with PRINCE2®.
Let us go over a couple of them as examples.

APM BoK7

Since 1992, the Association for Project Management (APM) has developed a body of
knowledge (BoK) that is highly recognized in the United Kingdom. The latest version, the
seventh edition from 2019, covers projects, program, and portfolio management (APM,
2019, pp. iv–xv). On the one hand, it gives recommendations to implement project gover-

113
 nance within the organization. On the other hand, it explains how to manage stakeholders
and the project delivery. It provides detailed techniques that cover different types of situa-
tions that can complement PRINCE2® since they might not be relevant for all kinds of
projects. Besides, the APM model refers to many external pieces of literature to complete
the best practices. Tending to be more and more flexible, the APM BoK is applicable to
multiple types of life cycles. Also focused on the project products, it divides the project
into three phases:

1. Defining outputs: similar to the PRINCE2® process “starting-up a project” and aligned
with the product-based planning technique
2. Integrated planning: equivalent to the PRINCE2® process “initiating a project”
3. Controlling deployment: a combination of the PRINCE2® processes “controlling a
stage” and “managing product delivery”

PMBOK®

The Project Management Body of Knowledge (PMBOK®) is a guide, evolving since 1987, by
the Project Management Institute (PMI®). It offers a list of best practices and techniques
that can be used to manage projects (Project Management Institute, 2021a, pp. ii–viii). The
PMBOK® is a method that only deals with the functions of the project manager, while
PRINCE2® is a governance framework that defines the responsibilities and communication
flow among all the hierarchical levels. The PMBOK® proposes the following aspects (PMI,
2021a):

• 12 principles: They recommend behaviors and goals any project manager should follow
and achieve. While some are similar to the PRINCE2® principles of “tailoring” and “focus
on value” (referring to the “continued business justification”), the others are comple-
mentary and do not conflict with PRINCE2®.
• eight project performance domains: They describe how to reach the principles and
project success thanks to a list of models, methods, and artifacts. More detailed than
the PRINCE2® themes, they offer project operational tools and techniques.

The latest PMBOK® edition is no longer based on processes but focuses on the project
products and tailoring, which makes its integration with PRINCE2® easier. For that matter,
it covers different project delivery approaches, like traditional, predictive, iterative, Agile,
adaptative, incremental, or hybrid.

114
The project manager or organization can decide the standard terminology that should be
used. They can use, for example, the PMBOK® term “steering committee” instead of
“project board,” the “sponsor” for the “executive,” or the “change control board” instead
of “change authority.”

SUMMARY
The PRINCE2® methodology aspires to be universal, i.e., usable for any
kind of project in any type of industry. For this purpose, it provides
guidelines which require tailoring; otherwise, there is little chance that
the framework covers the specific needs of the organization or the
project.

When implementing PRINCE2® as a standard method for managing

projects at the organization level, it should be adapted to the industry
requirements, internal habits, and other in-use methods. A critical chal-
lenge is to make the project actors adopt these new ways of working
thanks to efficient change management.

At the project level, the project manager also must tailor PRINCE2® to
the project size, complexity, team, external partner’s methods, and
other specifications. All the customizations must be then documented in
the project initiation documentation.

The seven PRINCE2® principles are essential and cannot be modified;

the seven themes must be managed but with any relevant techniques
that can be found in other best practices. The seven processes can be
simplified, extended by additional activities, or combined with other
models’ processes. Also, the terminology can fully be modified to use
the corporate language or from other methods. Finally, the eight project
management roles must be represented but can be combined or shared,
as long as it does not create any conflict of interest or problem of
authority.

115
 UNIT 6
PRINCE2® AGILE

STUDY GOALS

On completion of this unit, you will be able to...

– understand the purpose of PRINCE2® Agile.

– summarize the PRINCE2® Agile method.
– compare PRINCE2® Agile to the original PRINCE2®.
– adapt PRINCE2® to an Agile project.
 6. PRINCE2® AGILE

Introduction
Agile mindset and techniques have slowly appeared over the past century, but it has been
an official method since The Agile Manifesto (Beedle et al., 2001). The Agile Manifesto is
the fruit of the collaboration of a group of engineers in response to the constraints of the
Waterfall model traditional waterfall model (AXELOS Limited, 2015b, p. 8). Indeed, this predictive and
It organizes project activi- sequential approach, which defines the whole project plan, does not allow experimenta-
ties by sequential and lin-
ear phases. tion in the unknown (Petersen et al., 2009, pp. 386–387). Besides, benefits and incomes
would typically arrive after the project delivery, sometimes even years after starting the
project.

Different initiatives have emerged to bypass these challenges, notably the rapid applica-
tion development (RAD) method (Martin, 1991, p. 2), until the Agile Alliance agreed on the
best practices to form a consolidated framework and philosophy in the Manifesto for Agile
Software Development. Agile has become very popular over the past few years, particularly
in the technology industry.

A challenge for the organizations that are used to working on a traditional model is to inte-
grate Agile in their framework. Consequently, project management methods have become
more flexible and scalable to Agile, resulting in today’s hybrid solutions. PRINCE2® has
been including an increasing number of examples of how each theme and process can be
tailored to Agile projects.

In 2015, the PRINCE2® Agile® methodology was developed to fully incorporate the Agile
project delivery approach used in the 2009 PRINCE2® guidelines. Let us study the model’s
objectives, content, and differences from the original PRINCE2®.

6.1 Goal of PRINCE2® Agile

PRINCE2® Agile makes tailoring and scaling to Agile projects easier. It enables the smooth
integration of Agile method, values, behaviors, terminology, and techniques into the struc-
tured PRINCE2® framework. Its purpose is to blend both practices and leverage their
respective benefits. This serves either for organizations that are already applying
PRINCE2® and would like to be more agile or work with an Agile team, or for Agile organi-
zations that would like to implement more governance and control.

On one hand, PRINCE2® provides Agile projects with solid governance, better planning,
clearer guidelines, and more control. On the other hand, Agile offers the following aspects:

• higher on-time and on-budget project performance

• closer team collaboration and, thus, higher engagement and efficiency
• higher customer satisfaction, thanks to an adaptive approach to requirements

118
• faster decision-making
• benefits sooner, thanks to incremental and early delivery in value

It is crucial to maintain the integrity of the PRINCE2® pillars (the seven themes, principles,
and processes) as the method’s spine and add the following five Agile behaviors to the mix
(AXELOS Limited, 2015b, pp. 51–53):

• transparency: This openness provides not only visibility by sharing information but also
trust with high people integrity.
• collaboration: This requires engaging both the team and the customer for higher effi-
ciency and performance through support and goal alignment.
• rich communication: This is done with the most efficient channels and means (short
and dynamic face-to-face meetings, use of visuals, etc.).
• self-organization: Autonomy and empowerment generate higher individual motivation
and involvement.
• exploration: This encourages learning by experimenting, failing, and improving the
products.

Moreover, an “Agilometer” has been designed for organizations to assess how well
PRINCE2® Agile can suit their culture and level of maturity. Otherwise, actions might be
necessary before implementing the model. The measurement is scaled in six areas where
using Agile could represent a risk for the required conditions to be successful, as outlined
in the following (AXELOS Limited, 2015b, pp. 212–218):

• flexibility on what is delivered

• level of collaboration
• ease of communication
• ability to work iteratively and deliver incrementally
• advantageous environmental conditions
• acceptance of Agile

6.2 Overview of PRINCE2® Agile

Agile is a project delivery approach that fills gaps that are not covered by PRINCE2® in the
“managing product delivery” process. Indeed, while PRINCE2® focuses on project gover-
nance among the different management levels, Agile can be used by the specialist product
delivery teams as a project life cycle method.

A famous component of Agile is Scrum, created by Schwaber and Sutherland in the 1990s
(Schwaber & Sutherland, 2020, p. 1). It consists of adaptive iterative processes, called
sprints. One of its key principles is to make decisions based on experience by allowing
product quality control while developing. It is also based on the values of transparency,
inspection, and adaptation. Its adaptation to PRINCE2® is documented in Appendix H of
AXELOS Limited’s book PRINCE2® Agile (2015b). Tailoring to other Agile frameworks, like

119
 Kanban and lean start-up, are also included in PRINCE2® Agile. Kanban offers a visual pro-
gress status to quickly track just-in-time work, and lean start-up follows the principle of
failing fast to learn faster (AXELOS Limited, 2015b, p. 13).

Roles

PRINCE2® Agile® clarifies the responsibilities of the Agile roles and how they can relate to
PRINCE2® roles. The Product Owner knows the customer’s needs best, selects and prioriti-
zes the product scope, and should ensure the maximum value of the delivered products.
This role commonly comes from the business but cannot be represented by the project
manager. PRINCE2® Agile® has also added a new role, called the product manager, to head
several Scrum teams. They own the global project product and, as such, can be represen-
ted by the senior user.

The Scrum Master is an expert in Scrum who can coach the Product Owner, team, and
organization about its practices. Reporting to or assumed by the team manager, the
Scrum Master facilitates the work to the team, who creates the specialist products and
ensures the interface with other teams.

The development team is self-organized, autonomous, does not have a hierarchy, and
they create the specialist products. Cross-functional, they cover all the skills from business
analysis and design to development and testing.

Terminology

The framework adopts several Agile terms, such as the following:

• product backlog: Created by the product owner, it is a prioritized queue of all the spe-
cialist products that must be produced by the development team. The most common
prioritization technique in Agile is MoSCoW, scaled by four categories: must have,
should have, could have, and won’t have. The rule is to start with the highest priority
items and complete them as soon as possible.
• sprint backlog: The Scrum team selects the highest-priority requirements from the
product backlog that the development team will try to develop during the next sprint
period.
• increment: This is the list of products that are complete and ready to be delivered.
• user story: This is equivalent to the product description; it defines the functional
requirements for the specialist products from the user’s point of view, describing who
needs what and why.
• burn chart: This is a graph that represents the evolution of the work progress.
• minimum viable product (MVP): This is the piece of product that brings the highest cus-
tomer satisfaction with the minimum amount of effort.

120
Life Cycle

A fundamental principle of Agile is to deliver early and frequently. For this, the delivery
approach is organized by recurrent releases of interdependent pieces of the product back-
log turned into operational use. Each release contains several development iterations,
called sprints, of a selected piece of the product backlog, starting with those with the
highest priority.

The sprint is a timeboxed process of less than one month to ensure fast feedback, correc-
tion, and delivery. It contains a full iterative process of specifications analysis, design,
building (developments), integration, and testing with feedback until the completion of
the sprint backlog. PRINCE2® Agile distinguishes a few events specific to the sprint:

• sprint planning: Aligned with the product-based planning, the sprint backlog is transla-
ted into tasks planned for the sprint period.
• daily Scrums: The development team meets daily (for about 15 minutes) to share the
status of their work, review potential issues, and decide together on the next steps.
• sprint review: This is to verify the quality and efficacy of the product created, like testing
for quality control.
• sprint retrospective: This is to review the process used to create the products, like col-
lecting lessons learned, to study how the performance can be improved.

The roadmap plan of the product backlog is defined at the same time as the project plan
during the “starting up a project” process. Each PRINCE2® management stage is composed
of one or more releases for the Agile teams. Work packages tailored to Agile are used to
plan the team plan, which includes the release plans and sprint planning. Agile teams
must accept that baselines may not be the right reference and the initial plan might
change.

121
 Figure 9: PRINCE2® Agile Plans

Source: Caroline Naudin (2022).

Performance Targets

Since priorities are different in an adaptive approach like Agile compared to the predictive
traditional methods, dealing with the performance factors varies. Thereby, PRINCE2®
Agile® has five targets (AXELOS Limited, 2015b, p. 40):

1. Be on time, hit deadlines: The project is organized by short delivery life cycles with no
flexibility on the deadline.
2. Protect the level of quality: To ensure customer satisfaction, the products’ quality cri-
teria remain a high priority.
3. Embrace change: Teams must accept that change is inevitable to enable product
improvements.
4. Keep teams stable: Adding resources to work faster tends to disrupt the work and the
knowledge transfer would take time; quality could be jeopardized. It is, thus, more
efficient to maintain a stable and engaged team.
5. Accept that the customer does not need everything: Teams should challenge the
necessity and priority of the requirements to only add profitable value to the product
within the time and budget constraints.

As a result, when the project team foresees deviations from the project objectives and its
tolerances, as per the PRINCE2® principle “manage by exception,” the following actions
are recommended regarding the six project constraints. In this case, “fix” means to find a
solution and “flex” means that the variable is flexible:

122
• time and costs: These must be fixed because the deadline and budget are strict, with no
tolerance; therefore, they cannot be flexed.
• benefits: These cannot flex benefits on the minimum viable product, which must then
be fixed, but can flex everything else on top of it.
• risks: These are fixed and may flex upon decisions by management and according to the
tolerances.
• quality and scope: These can both fix and flex the quality criteria and the scope priori-
ties. Note that it might be difficult from a procurement perspective to deal with a flexi-
ble scope. Agile contracts often focus on the minimum viable product and the priorities
instead of detailed requirements. The related risks are shared with trust among the par-
ties.

6.3 Similarities and Differences to the

Original PRINCE2®
In the past few years, PRINCE2® has been designed to be tailored to Agile and has involved
Agile experts in its redaction. Therefore, methods are already compatible. When the con-
trary was perceived, it would most probably be due to a lack or misuse of the tailoring
principle.

The main difference is that PRINCE2® focuses on the project management governance,
activities, and roles, and not on the specialist aspects, detailed techniques, nor leadership
soft skills. This makes PRINCE2® incomplete as a project management method but adapta-
ble to any kind of project. Conversely, PRINCE2® Agile® goes over many techniques to
manage Agile delivery life cycles. That is why it mainly impacts – or rather completes – the
“managing product delivery” process and can fit well under this layer. Another significant
variance happens in the “fix and flex” mechanism to manage potential deviations from the
project performance targets since PRINCE2® Agile® is more flexible apart from cost and
time.

Otherwise, PRINCE2® and PRINCE2® Agile® rely on the same principles, themes, processes,
and management products, although PRINCE2® Agile® brings five additional principles for
stronger collaboration and a higher acceptance of changes. Tailoring to Agile is detailed
and fully integrates the Agile philosophy and delivery techniques, especially regarding the
following themes (AXELOS Limited, 2015b, pp. 57–58):

• business case: There is no change in this theme, but the minimum viable product
becomes the focus and the rest of the scope should be prioritized. Benefits will occur
earlier thanks to the incremental deliveries; its tolerances should reflect the scope flexi-
bility.
• organization: While PRINCE2® is hierarchical and defines a scope of authority and
responsibilities for each role and level, the self-organized PRINCE2® Agile® delivery team
avoids hierarchy. The PRINCE2® Agile® communication and reporting mechanisms will,
therefore, need to be integrated and tailored between the project management team

123
 and delivery team. Besides, Agile roles should be matched to the PRINCE2® organization
(i.e., the Product Owner or product manager as the senior user) or should report to
management roles.
• quality: They both focus on the product, quality, and customer satisfaction. However,
PRINCE2® plans to deliver the full scope, while the PRINCE2® Agile® focuses on the high-
est priorities and minimum viable requirements.
• plans: PRINCE2® is based on the traditional, predictive waterfall model, when the work
can be planned and is validated stage by stage and it is difficult to move backwards.
Conversely, Agile works on an adaptive, experimental, and iterative model. Neverthe-
less, the “managing stage boundaries” process should not disrupt the incremental
releases, but should still offer a control point to review their progress, priorities, and
project viability. Many techniques are proposed by Agile PRINCE2® for planning.
• risk: Since there are more uncertainties in Agile projects than in predictive ones, con-
trols must be more frequent in PRINCE2® Agile® (e.g., with daily Scrums).
• change: Baseline changes are handled the same way, following the configuration man-
agement and approval processes for change control. Since PRINCE2® Agile® emphasizes
embracing changes and learning from failure, baselines cannot be strict guidelines but
should be flexible for changes in the specialist product scope. A change budget makes
less sense since scope prioritization must overcome potential excess costs.
• progress: The required transparency and rich communication with sharp deadlines in
PRINCE2® Agile® bring many techniques to control the project progress daily; Kanban is
an efficient framework for this.

SUMMARY
Faced with a growing need for organizations to combine predictive and
adaptive approaches to control projects in changing business environ-
ments, AXELOS Limited offers a hybrid solution called PRINCE2® Agile.
This enables planning and structure governance to be merged and to
guide and control the project with flexibility, autonomy, and early deliv-
ery.

Based on the PRINCE2® principles, themes, and processes, PRINCE2®

Agile incorporates Agile methods, behaviors, and techniques to deal
with specialist product delivery. It also improves project performance
thanks to greater collaboration, sharper deadlines, better customer sat-
isfaction, and earlier benefits. It specifies the responsibilities of Agile
roles and how they can fit in the PRINCE2® organization. It also provides
practices to manage specialist product life cycles in an Agile model.

124
A challenge that PRINCE2® Agile addresses is how to handle the project
constraints thanks to the “fix and flex” mechanism to manage possible
exceptions of time, cost, benefit, risk, quality, and scope. Ultimately,
PRINCE2® Agile does not differ much from the original PRINCE2® but
explains in more detail how to tailor it to Agile environments.

125
BACKMATTER
 LIST OF REFERENCES
Ansoff, H. I., & McDonnell, E. J. (1990). Implanting strategic management. Prentice Hall.

Arkes, H. R., & Ayton, P. (1999). The sunk cost and Concorde effects: Are humans less
rational than lower animals? Psychological Bulletin, 125(5), 591. https://doi.org/10.103
7/0033-2909.125.5.591

Association for Project Management. (2019). APM body of knowledge (7th ed.).

AXELOS Limited. (2015a). P3M3® maturity model (3rd ed.). The Stationery Office.

AXELOS Limited. (2015b). PRINCE2® Agile®. The Stationery Office.

AXELOS Limited. (2017). Managing successful projects with PRINCE2® (6th ed.). The Station-
ery Office.

Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., Highsmith, J.,
Hunt, A., Jeffries, R., Kern, J., Marick, B., Martin, R. C., Schwaber, K., Sutherland, J., &
Thomas, D. (2001). Manifesto for Agile software development. Agilemanifesto.org. https
://agilemanifesto.org/

Bensoussan, B. E. & Fleisher, C. F. (2008). Analysis without paralysis : 10 tools to make better
strategic decisions. FT Press.

Cox, K. (2021). Business analysis, requirements, and project management: A guide for com-
puting students. Auerbach Publications.

Hinde, D. (2018). Tailoring PRINCE2® to different organizational cultures [White paper]. AXE-
LOS Limited. https://tassililibya.com/wp-content/uploads/2019/06/Tailoring-PRINCE2
-to-different-organizational-cultures.pdf

Hohmann, L. (2006). Innovation games: Creating breakthrough products through collabora-

tive play. Addison-Wesley Professional.

Ilie, G., & Ciocoiu, C. N. (2010). Application of fishbone diagram to determine the risk of an
event with multiple causes. Management Research and Practice, 2(1), 1–20.

Johnson, C. N. (2002). The benefits of PDCA. Quality Progress, 35(5), 120.

Kerzner, H. (2009). Project management: A systems approach to planning, scheduling, and

controlling (10th ed.). John Wiley & Sons.

KPMG. (2017). Driving business performance: Project management survey 2017. https://asse
ts.kpmg/content/dam/kpmg/nz/pdf/July/projectmanagementsurvey-kpmg-nz.pdf

128
Lasswell, H. D. (1948). Lasswell’s model. Communication Theory.

Martin, J. (1991). Rapid application development. Macmillan.

Office of Government Commerce. (2002). PRINCE2® (3rd ed.). The Stationery Office.

Petersen, K., Wohlin, C., & Baca, D. (2009). The waterfall model in large-scale development.
In F. Bomarius, M. Oivo, P. Jaring, & P. Abrahamsson (Eds.), Product-focused software
process improvement. Springer. https://doi.org/10.1007/978-3-642-02152-7_29

Project Management Institute. (2021a). A guide to the project management book of knowl-
edge. PMBOK® guide (7th ed.).

Project Management Institute. (2021b). Pulse of the profession® 2021: Beyond agility. https:
//www.pmi.org/-/media/pmi/documents/public/pdf/learning/thought-leadership/pul
se/pmi_pulse_2021.pdf

Săvescu, D. (2018). Project’s management: Some aspects. Fiability & Durability/Fiabilitate

si Durabilitate, 1, 299–304.

Schwaber, K., & Sutherland, J. (2020). The Scrum guide. The definitive guide to Scrum: The
rules of the game. https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guid
e-US.pdf#zoom=100

Tuckman, B. W., & Jensen, M. A. C. (1977). Stages of small-group development revisited.

Group & Organization Studies, 2(4), 419–427. https://doi.org/10.1177/10596011770020
0404

Turner, J. R., & Cochrane, R. A. (1993). Goals-and-methods matrix: Coping with projects
with ill-defined goals and/or methods of achieving them. International Journal of
Project Management, 11(2), 93–102. https://doi.org/10.1016/0263-7863(93)90017-H

129
 LIST OF TABLES AND
FIGURES
Figure 1: Project Management Team Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Figure 2: Stakeholder Power-Interest Grid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Table 1: RACI Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Figure 3: Example of PERT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Figure 4: Example of A Gantt Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Figure 5: Example of a Probability-Impact Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Figure 6: Earned Value Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Figure 7: PRINCE2® Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Figure 8: The Product Breakdown Structure for Constructing a House . . . . . . . . . . . . . . . . 101

Table 2: Example of a WBS List for Constructing a House . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

Figure 9: PRINCE2® Agile Plans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

130
IU Internationale Hochschule GmbH
IU International University of Applied Sciences
Juri-Gagarin-Ring 152
D-99084 Erfurt

Mailing Address
Albert-Proeller-Straße 15-19
D-86675 Buchdorf

[email protected]
www.iu.org

Help & Contacts (FAQ)

On myCampus you can always find answers
to questions concerning your studies.