Vi

ew P
e
on op

CHAPTER 2
ly leC
C -
op no er

PRINCIPLES
yr t f t c
ig or op
ht r y
© ed rig
20 ist ht
23 rib
ut
io
n
 Managing Successful Projects with PRINCE2

CHAPTER 2
PRINCIPLES
Chapter 2 - Principles

n
Definition: PRINCE2 principles

io
20 ist ht
ut
The PRINCE2 principles are the guiding obligations that determine whether the project is
genuinely being managed using PRINCE2 and ensure effective application and tailoring of

© ed rig
23 rib
PRINCE2 to any project.

ht r y
PRINCE2 is suitable for every project, regardless of type, size, complexity, importance, level of risk, or
ig or op
delivery method (linear-sequential, iterative-incremental, or hybrid). Moreover, it can be used for all
types of organizations, whether commercial, governmental, non-profit, or not-for-profit. Additionally, it is
applicable for projects anywhere in the world, with its ability to incorporate country-specific regulations,
yr t f t c
business models, and cultures.
To enable PRINCE2 to be used for such a wide range of projects, the method is flexible in how it can be
op no er

used for any given project. Rather than prescribing what to do to align the method to the specific
project, PRINCE2 offers guidance through principles. These principles enable the project management
ly leC

team to decide how PRINCE2 will be used on their project.

The seven PRINCE2 principles are:
● ensure continued business justification
on op

● learn from experience

● define roles, responsibilities, and relationships
C -
e

● manage by stages
ew P

● manage by exception
● focus on products
● tailor to suit the project.

How the method is applied and tailored depends on the nature of the project and factors internal and
external to the business as shown in figure 2.1.
Vi

20
 Principles

Project specific arrangements

External (to project)

Organizational context documented in…
e.g. sector, capability,
culture, policies
Project initiation
Changing the method.
documentation
(e.g. management
For example, using
approaches)
Sustainability context Tailor alternative terminology
e.g. business drivers and or replacing a PRINCE2

Chapter 2 - Principles
priorities technique

Project plan
Typical contexts

n
Commercial context
e.g. contracts, Stage plans
relationships

io
20 ist ht
Team plans

ut
Using the method.
Delivery method
For example, assigning
e.g. lifecycle model,

© ed rig
roles, number of stages,
development techniques,
Apply

23 rib
number of teams/work
terminology
packages, setting
Internal (to project)

tolerances or choice of
supporting techniques

ht r y
Project scale

ig or op e.g. complexity, duration

Figure 2.1 How to apply and tailor PRINCE2 to a project

yr t f t c
The seven principles offer flexibility, as they provide guidance on how the integrated elements of the
op no er

method can be applied and tailored to find the best fit for the project and its context while keeping the
integrity of the method. So long as the principles are followed, PRINCE2 is being used effectively.

2.1
ly leC

Ensure continued business justification

on op
C -
e

Key message
ew P

A PRINCE2 project has business justification sufficient to warrant investment to initiate the
project and ongoing investment through to successful completion. If it does not, it should be
stopped.

There must be a justifiable reason for starting a project, and the justification must remain valid and be
revalidated throughout the lifecycle of the project. The business justification drives decision-making to
Vi

ensure the project remains aligned with the benefits sought and contributes to business objectives.
Organizations that lack rigour in business justification may find that projects proceed even when there
are few real benefits or when a project has only tentative associations with the business strategy. Poor
alignment with business strategy can also result in organizations having a portfolio of projects that have
inconsistent or duplicated objectives.

21
 Managing Successful Projects with PRINCE2

Compulsory projects, such as those driven by legislation or regulation, still require justification for the
chosen approach to ensure it represents the best value for money. All parties involved in the project will
need a balance between expected benefits, costs, and risks for them to have business justification for
their involvement.
The business justification for a project may change; therefore, it is important that what the project is
delivering remains consistent with the evolving justification. If continuing with the project can no longer
Chapter 2 - Principles

be justified, then it should be stopped and end in a controlled way. Cancelling a project in these
circumstances is a positive contribution to the business as the project’s funds and resources can be
reinvested in other more worthwhile projects.

n
After the project is completed, the project should be reviewed to evaluate if the benefits have

io
materialized sufficiently to warrant the final investment and what lessons can be learned from the

20 ist ht
project.

ut
Below are some examples of the application of the ‘ensure business justification’ principle.

© ed rig
23 rib
For a commercial project with one or more customers and suppliers, each party will need to have a
clear business justification to undertake the project and to continue with it. The customer may want to

ht r y
enhance market share by introducing a new product. The supplier’s business justification might include

ig or op
non-financial benefits, such as gaining an impressive customer reference for promotional purposes or
building experience in applying new technologies.
yr t f t c
For a co-owned project, such as a governmental project to jointly develop a new IT system across a
number of agencies, if the business justification is lost for one or more parties, those parties should
consider ending their participation in the project. In this case, the consequences of ending or
op no er

withdrawing participation in the project, such as contractual obligations, will inform the decision and
any approach to prematurely close the project. Throughout the project, each investing party will need
ly leC

to keep monitoring their own business justification to ensure that the project is still worthwhile for
them.

2.2
on op

Learn from experience

C -
e
ew P

Key message

A PRINCE2 project team actively seeks, records, and implements improvements as a result of
relevant lessons learned from prior projects and throughout the life of the project. It applies
them in future projects and shares them for others to apply.
Vi

A common characteristic of projects is that they include an element of uniqueness. This makes projects
challenging as the temporary team may not have experience of a project quite like the one being
undertaken.
To overcome these challenges, project teams need to find ways to learn from the experience of others
and from the experience gained from the project as it develops.

22
 Principles

Learning from experience occurs throughout the lifecycle of the project:

● When starting a project Previous or similar projects should be reviewed to see if lessons could be
applied. If the project is a ‘first’ for the people within the business or if there is any content which is
new or novel, then it is even more important to learn from others. This could include projects
delivered by people or organizations external to the business to identify relevant lessons.

Chapter 2 - Principles
● As the project progresses The project team should continue to learn. Lessons should be included
in relevant reports and reviews and included at the end of each stage. The goal is to seek
opportunities to implement improvements during the life of the project. The retrospective technique
is an example of gathering lessons in agile approach.

n
● As the project closes The project team should share the insights gained during the project.

io
20 ist ht
The foundation for learning is data and the ability to gain insights from it. Projects should be clear about

ut
what data is required, how it will be analysed so that insights can be gained and applied, and what will
happen to the data during the project and when the project closes.

© ed rig
23 rib
Project teams need to consider how to effectively share lessons with all those involved in the project, as
people may have different learning needs and preferences. Some may learn best by observing, whereas

ht r y
others do so by experimenting.

ig or op
It is important to learn from both mistakes and successes to continuously improve and innovate. It is
the responsibility of everyone involved with the project to identify lessons rather than wait for someone
yr t f t c
else to do so. Lessons that are not used to improve the project, or future projects, are only ‘lessons
identified’ and not actually ‘lessons learned’.
op no er

Below are some examples of applying the ‘learn from experience’ principle.
In a smaller project with one co-located team, ‘lessons learned’ can be discussed on a regular basis in
ly leC

team meetings. Learning in this case happens on the job, potentially on a daily basis.
In a large and complex project, the learning process will involve many project team members who could
be spread across multiple teams and locations. This large-scale approach will make it harder to ensure
on op

everyone has access to the same learning experience.

Learning in larger projects may require more advanced communication, such as explanatory videos,
C -

presentation kits for project team managers, or tailored workshops in subgroups. Such projects may
e

benefit from field trips, pilots, simulations, or go-live rehearsals as a source of learning too.
ew P
Vi

23
 Managing Successful Projects with PRINCE2

2.3 Define roles, responsibilities, and relationships

Chapter 2 - Principles

Key message

n
A PRINCE2 project has defined and agreed roles and responsibilities within an organization
structure that engages the business, user, and supplier stakeholder interests. Moreover, a

io
PRINCE2 project management team initiates and builds relationships with and between

20 ist ht
ut
internal and external stakeholders.

© ed rig
23 rib
Projects need people. It is important that the right people are involved, and they know what is expected
of them and what they may expect from others in the project. Successful projects require an

ht r y
understanding of the relationships with and between stakeholders and ongoing activities to strengthen

ig or op
them. This is why ‘People’ is one of the five integrated elements of PRINCE2.
Stakeholders can be individuals or groups within or external to the business. Stakeholders within the
yr t f t c
business could be a work council, sustainability board, diversity board, owners, department leaders, or
other project teams; stakeholders outside the business could be trade unions, customers, suppliers,
communities, interest groups, banks, or the media.
op no er

All projects have the following primary stakeholders: the business, users, and suppliers (see section
1.5.1). All three stakeholder interests need to be represented effectively in the project management
ly leC

team; this is reflected in the design of a PRINCE2 project board (see section 6.2.1).
Defining roles and responsibilities is particularly challenging as projects are cross-functional, may
involve more than one organization, often have a mix of full and part-time resources, and may be
on op

spread across multiple locations. The management structures of the parties involved in the project are
likely to be varied, with different priorities, objectives, and interests to protect. The day-to-day line
C -

management structures of the business may not be designed for, or suited to, project work.
e

The assignment of roles to individuals throughout the life of the project and their responsibilities must
ew P

be clear, unambiguous, and accepted. To be successful, projects must have an explicit project
management team structure consisting of defined and agreed roles and responsibilities for the people
involved in the project. Moreover, the projects must have an understanding of the relationships and a
means for effective communication between them.
The goal is to clearly articulate roles and responsibilities to provide a clear, coherent structure that all
stakeholders understand and is suitable to enable effective project delivery performance against the
project performance targets.
Vi

Below are some examples of applying the ‘define roles, responsibilities, and relationships’ principle.
If the project is part of a programme, then some of the project responsibilities may be held by people in
the programme management team. In this case, the programme’s business change manager (BCM) may
undertake the project executive or senior user role on the project board to help align the project with
the programme. The programme management office (PMO) could provide project support, or the
programme’s design authority could be given decision-making responsibility for authorizing changes at
the project level. Agreements need to be made about who accepts which project role and the authority

24
 Principles

and responsibility they each have. The goal is to enhance consistency and coherence between the
project and the programme.
The nature of the project will determine the number of stakeholders and the amount of change it
creates for each of them. A project with a small number of stakeholders and a high degree of impact will
have a very focused approach to engaging with them, perhaps on an individual and personal basis. A
project with a large number of stakeholders and a wide range of impacts may have to use multiple

Chapter 2 - Principles
approaches with a mix of personalized engagement and more general engagement through surveys
and broadcast channels (such as emails).

n
For projects that have development teams using agile development methods, the PRINCE2 team
manager role may be held collectively by the development team.

io
2.4

20 ist ht
ut
Manage by exception

© ed rig
23 rib
ht r y
ig or op
Key message
yr t f t c
A PRINCE2 project establishes limits of delegated authority by defining tolerances for
performance against its plans.
op no er
ly leC

Definition: Tolerance
on op

The permissible deviation above and below the plan’s target for benefits, cost, time, quality,
scope, sustainability, and risk without needing to escalate the deviation to the next level of
C -
e

management. Tolerance is applied at project, stage, and team levels.

ew P

PRINCE2 enables appropriate governance by defining distinct responsibilities for directing, managing,
and delivering the project and clearly defining accountability at each level.
Accountability is established by:
● delegating authority from one management level to the next by setting tolerances against the seven
aspects of performance (benefits, cost, time, quality, scope, sustainability, and risk) for the respective
level (project, stage, team)
Vi

● establishing controls so if tolerances are forecast to be exceeded, they are flagged as being an
exception and immediately escalated to the next management level for a decision on how to proceed
● establishing an assurance mechanism so that each management level can be confident that the
exception controls are effective.

25
 Managing Successful Projects with PRINCE2

The seven aspects of a plan’s performance requiring tolerances to be defined are:

● Benefits The degree to which it is permissible to underdeliver or overdeliver benefits; for example,
the business case for a sales improvement project modelled with a plus or minus two percent range
of increased income generation.
● Costs The degree of permissible overspend or underspend against an agreed budget (both person-
Chapter 2 - Principles

hours and financial).

● Time The degree to which it is permitted to deliver earlier or later than an agreed target completion
date compared to the project plan, stage plan, or work package description.

n
● Quality How much something can vary from agreed acceptance criteria; for example, a project to

io
produce a new sports watch might have a target that the watch should work underwater to a depth
of 50 metres with a permissible tolerance of plus or minus five metres.

20 ist ht
ut
● Scope Permissible variation of the plan’s products; for example, a project requiring delivery of all the
must-have mandatory requirements but permitted to deliver only 60 percent or more of its should-

© ed rig
23 rib
have and could-have requirements.
● Sustainability The degree to which the project product or project activities required to deliver the

ht r y
project can vary from sustainability targets; for example, a new production line that operates within

ig or op
five percent of an emissions target and was delivered using around 70 percent of workforce coming
from the local community.
● Risk Limits on the plan’s aggregated risks; for example, a tolerance that the cost of aggregated
yr t f t c
threats must remain less than 10 percent of the agreed budget and that the cost of any single threat
must be no more than five percent of the budget.
op no er

The implementation of ‘manage by exception’ provides for efficient use of senior management time as it
reduces senior managers’ time burden without removing their control. This ensures that decisions are
ly leC

made at the right level in the organization. The goal is to alert the next management level in the project
as early as possible that the work will move outside of agreed tolerances, and a decision is needed on if
and how to proceed. The decision-maker can decide to accept the deviation and its consequences or
act to remove or reduce it.
on op

A project using an iterative-incremental delivery method with defined timeboxes will typically fix time
and cost and vary in scope. In this case, time and cost will have much tighter tolerances set than the
C -
e

scope.
ew P

An example of applying the ‘manage by exception’ principle is that the use of tolerances will differ
depending on the project’s context, such as a project with a commercial arrangement between
customer and supplier where the tolerances will be reflected in the contract. In this example, if the
project manager learns that procured materials will be delivered late and the issue cannot be resolved
within the tolerances, the project manager will need to alert the project board quickly. The contract may
define any cost remedies available between the customer and supplier, but there may be consequences
for the project’s stakeholders caused by the delay. In this case, the project board will need to decide
what actions to take and provide direction to the project manager. By reviewing the tolerances at the
Vi

end of every stage, the project is able to adapt and modify the next stage activities to reflect a changing
operating environment.

26
 Principles

2.5 Manage by stages

Chapter 2 - Principles
Key message

n
A PRINCE2 project is planned, monitored, and controlled on a stage-by-stage basis.

io
20 ist ht
ut
© ed rig
23 rib
Definition: Stage

ht r y
The section of a project that the project manager is managing on behalf of the project board
ig or op
at any one time.
yr t f t c
The focus on managing by stages ensures that the project is properly initiated before work starts on
delivery of the project’s outputs. Every PRINCE2 project should have at least two stages: an initiation
op no er

stage and one further stage. Many projects benefit from having more than two stages.
Advantages of managing by stages are:
ly leC

● It enables adaptability to changes in the project or business context.

● It provides review and decision points, giving the project board opportunities to assess the project’s
viability at defined intervals rather than let it continue in an uncontrolled manner.
on op

● It provides the ability to ensure that key decisions are made prior to the detailed work needed to
implement them.
C -
e

● It allows clarification of what the impact will be of an identified external influence, such as the
organizational budget setting process or the finalizing of legislation.
ew P

● It facilitates the principle of manage by exception by delegating authority to the project manager at
each stage.

The choice of appropriate stages for a project will depend on a number of factors (see 7.2.3), including:
● minimizing risk exposure through the project lifecycle
● the size and complexity of the project (shorter stages offer more control, whereas longer stages
reduce the effort for senior management)
Vi

● any significant decisions and control points required during the project’s lifecycle; these will often be
linked to key investment, business, or technical decisions
● sector or business policies and standards.

The project board authorizes one stage of the project at a time and delegates the authority for day-to-
day control of the stage, within agreed tolerances, to the project manager. As long as the stage is
forecast to remain within tolerance, the project manager is authorized to make adjustments as required.
The project board only authorizes the next stage if there is sufficient business justification and funds to

27
 Managing Successful Projects with PRINCE2

continue. If the project no longer has a valid business case, the project board will determine whether
and how to recover the project or prematurely end it.
An example of applying the ‘manage by stages’ principle is when teams work in ‘sprints’ or ‘timeboxes’
while operating incrementally and iteratively to realize the agreed features and user stories. PRINCE2
can be tailored to work with sprints and user stories instead of work packages and product
descriptions. The project manager will define how many sprints are required for each stage. In this way,
Chapter 2 - Principles

the project is consistent with the principle of manage by stages.

2.6

n
Focus on products

io
20 ist ht
ut
© ed rig
23 rib
Key message

ht r y
A PRINCE2 project focuses on the definition and delivery of products, in particular their user

ig or op
quality expectations and requirements.
yr t f t c
Definition: Product
op no er
ly leC

An input or output, whether tangible or intangible, that can be described in advance, created,
and tested. PRINCE2 includes four types of products:
● Management products Are often documents or information needed to support the
on op

management of the project, such as a business case or a plan.

● Specialist products Are the products that are needed by the user to realize the benefits
required of the project.
C -
e

● The project product Describes the total output from the project as defined in the project
ew P

product description (see section 7.3.2.1).

● External products Are products developed or provided outside of the project’s control but
which the project is dependent on, for example, the publication of a new standard.

Specialist products will be referred to throughout the book as simply ‘products’, except when
a distinction is needed between management and specialist products.
The term ‘project products’ refers to the specialist and management products created during
the project.
Vi

Projects that focus on what the project needs to produce are more likely to be efficient and avoid waste
than projects that focus primarily on the work activity. This is because the purpose of a project is to
fulfil stakeholder expectations in accordance with the business justification. Therefore, there must be a
common understanding of the products required and the user quality expectations for them.
The purpose of a project can be interpreted in many different ways, unless there is an explicit
understanding of the products to be produced and the criteria against which they will be individually

28
 Principles

approved. PRINCE2 requires projects to be output-oriented rather than work-oriented. PRINCE2 calls
these outputs ‘products’.
This focus on products:
● ensures that the project only performs work that directly contributes to the delivery of a product
(that is, the project does no more work than it needs to deliver its agreed products)

Chapter 2 - Principles
● helps manage uncontrolled change (‘scope creep’) by ensuring that all changes are agreed in terms
of how they will impact the project products and the business case for the project
● reduces the risk of user dissatisfaction and acceptance disputes by agreeing (at the start of the

n
project) what will be produced by the project

io
● assists a pause or closure of the project. Agreement can be more easily met to pause or close a

20 ist ht
project after certain products are completed. It also allows easier and controlled resumption of the

ut
project.

© ed rig
23 rib
An output-oriented project is one that agrees and defines the project product prior to undertaking the
activities required to produce it. The set of agreed products defines the scope of a project and provides
the basis for planning and control.

ht r y
ig or op
A PRINCE2 project uses product descriptions that provide the means to determine effort estimates,
resource requirements, dependencies, and activity schedules. The focus on products supports almost
every aspect of PRINCE2: planning, responsibilities, progress reporting, quality, change control,
yr t f t c
acceptance, and risk management.
Below are examples of applying the ‘focus on products’ principle.
op no er

In a small simple project, such as publishing a new management book, a single project product
description might suffice. This description will determine, among others features, how many chapters
ly leC

will be required, the desired total number of pages, the language, and the number of graphics in colour
versus black and white. Product descriptions for projects using an iterative-incremental delivery
method, such as agile, may be in the form of requirements, features, epics, and user stories.
on op

For larger and more complex projects, the project product description will be divided into sub-products
and then further subdivided to a level of detail to understand how each product will be sourced,
developed, and approved. The further the products are subdivided, the harder it will be for the project
C -
e

board to be able to decide whether product descriptions are correct. This is because the content
ew P

becomes more technical and will require specialist knowledge to understand. In this case, it is important
that the supplier has the expertise to define the right products at each level, and the business establishes
project assurance with the knowledge necessary to assure that the product meets the specification.

2.7 Tailor to suit the project

Vi

Key message

PRINCE2 is applied and tailored to suit the project environment, size, complexity, importance,
delivery method, team capability, and level of risk.

29
 Managing Successful Projects with PRINCE2

PRINCE2’s value is that it is a universal project management method that can be applied to take account
of the project’s context, scale or size, delivery method, stakeholder landscape, complexity, importance,
team capability, and level of risk. Furthermore, it can be used for any project type, geography, or culture.
It can be used on any project because the method is designed to be applied and tailored to suit each
project’s specific needs and context.
The purpose of tailoring is to ensure that:
Chapter 2 - Principles

● the project management method used is appropriate to the project (for example, aligning the
method with the business processes that may govern and support the project, such as human

n
resources, finance, and procurement)

io
● project controls are appropriate to the project’s scale, complexity, importance, delivery method,
team capability, and risk (for example, the frequency and formality of reports and reviews).

20 ist ht
ut
Tailoring requires the project board and the project manager to make proactive choices and decisions

© ed rig
on how PRINCE2 will be applied. It may also involve adjusting the terminology to match terms used by

23 rib
the organizations involved or replacing some of the PRINCE2 techniques (such as the risk management
technique) with alternative procedures such as those already used by the business or supplier(s).

ht r y
When tailoring PRINCE2, it is important to remember that effective project management requires
ig or op
information (but not necessarily documents) and decisions (but not necessarily meetings).
If PRINCE2 is not tailored, it is unlikely that the project management effort and management approaches
yr t f t c
would be appropriate for the needs of the project. This can lead to inattentive project management at
one extreme, where PRINCE2 is followed without question, or ‘heroic’ project management at the other
extreme, where PRINCE2 is not really followed at all.
op no er

The project manager is responsible for tailoring and will make recommendations having consulted
ly leC

relevant lessons and standards. The project board is accountable and needs to approve the
recommendations at the end of the initiation stage and every time there is a proposed change to the
management approaches.
How PRINCE2 will be applied and tailored for the particular project is captured in the project initiation
on op

documentation. This ensures that all those involved in the project understand how PRINCE2 is to be
used and how to carry out their responsibilities. Care should be taken that the proposed tailoring is
C -
e

consistent with PRINCE2’s seven principles and that the resultant method retains its integrity.
ew P

An example of applying the ‘tailor to the suit the project’ principle is where the project has a commercial
customer-supplier relationship. The project may need to align the project management processes,
practices, and documentation to two or more quality systems, one from the customer and one from the
supplier. For example, a supplier may wish to use their in-house product development framework based
on an iterative-incremental delivery method using agile management approaches. To avoid potential
confusion, the project manager might propose to:
● map and define terminology between PRINCE2 and the supplier’s agile management approaches
● add the project team roles of ‘customer subject matter expert’ and ‘supplier subject matter expert’
Vi

to the agile team, representing the customer and the supplier respectively
● add a coach to guide the teams in working effectively in the combination of PRINCE2 and the
supplier’s in-house agile method
● collaborate and communicate according to agile ways of working, such as a daily stand-up and
support agile reporting tools, such as information radiators
● define project procedures, such as working with sprints or work packages, product descriptions, or
user stories, and how to use these in the project.

30