Managing Successful Projects with PRINCE2

Acknowledgements
Contents summary
Conventions used in the official book
 CHAPTER 1
INTRODUCTION
1.1 Introduction
PRINCE2 is one of the most widely used methods for managing projects in the world. It is a structured
project management method that uses the experience gained from thousands of projects, as well as
contributions from countless project sponsors, project managers, project teams, academics, trainers,
and consultants.
PRINCE2 has been designed to be adaptable so that it can be applied to any project, regardless of the
project’s purpose, scale, type, organization, geography, or culture. This is achieved by:
 Organizational context
The PRINCE2 method does not assume any specific organizational context. There may be users who
specify the desired outputs (referred to as products in PRINCE2), suppliers who will provide the
resources and expertise to deliver the products, and business decision-makers who will ensure that the
project investment can be justified and remains justified through the project lifecycle. The PRINCE2
method does not require any specific organizational relationships between the users, suppliers, and
business decision-makers for the project. The users, suppliers, and business decision-makers may all
come from the same organization, or they may be in separate organizations with commercial
agreements between them.
Within the PRINCE2 method, the business decision-makers come from the organization that
commissions the project. The decision-making will be made within the context of the business strategy,
objectives, and policies of the organization.
 Chapter 1 - Introduction
Figure 1.2 Various project contexts

9
1.5.3 Delivery method
The delivery method is the way in which the work of the project is to be delivered. The project may rely
on one or more delivery methods to create the required products. Typical delivery methods include:
 Stakeholders
Projects will impact people from across the organizational ecosystem. Therefore, a project will need to
involve those with a formal role in the project team and key people either impacted by or critical to the
success of the project (who may not hold a formal role). These people are the stakeholders in the
project and will cover the full spectrum of users, suppliers, and the business. Stakeholders can be
external to both the project team and the business.
Chapter 3 - People

37
3.3 Leading successful teams

Chapter 3 - People

39
These factors mean project teams require a different style of management and leadership than that
used for established business teams, as it can be more challenging for a temporary leader or manager
to exercise their authority.

3.3.1 Leading across organizational boundaries

In addition to those people formally assigned to a project, there are people within the business who are
affected by the project, but do not work within the defined project team. They often have a role to play,
for example directly contributing to the project through activities such as defining, assuring, and
accepting products into the business. They may indirectly contribute by undertaking activities within
their area of the business to accommodate or derive benefit from the project, such as upskilling staff,
changing ways of working, or integrating new products into their area of the organization.
When these activities are outside of the defined project scope, it is important to ensure that there is a
clear understanding of the dependencies on such activities, who is responsible for undertaking them,
and how they will be funded and monitored. If this type of work is not managed carefully, projects can
be delayed or fail to achieve their benefits.
Leading people beyond a project’s direct authority (often across organizational boundaries) requires a
degree of cultural intelligence. Cultural intelligence is the capability to relate and work across cultures
within the organizational ecosystem. Successfully working across cultures requires:
 People and PRINCE2 principles
PRINCE2 is based on seven principles, one of which is that all PRINCE2 projects must define roles,
responsibilities, and relationships. This ensures people factors are continually addressed throughout
the project’s lifecycle.
People factors permeate the other principles as illustrated below.
Ensure continued business justification
 People and PRINCE2 processes
The PRINCE2 processes are organized into four layers: business, directing, managing, and delivering.
People factors such as behaviours, culture, and relationships are included in the processes, explaining
how people interface between the layers (see Chapter 12).
 CHAPTER 4
INTRODUCTION TO
PRINCE2 PRACTICES
4.1 The PRINCE2 practices

Table continues
Chapter 4 - Introduction to PRINCE2 Practices

51
Chapter 4 - Introduction to PRINCE2 Practices

53
  uidance for effective business case
G
management

5.2.1 Business case lifecycle

The business case is developed as an outline at the start of a project based on information provided in
the project mandate. It needs to include sufficient information to enable the project board to confirm
the business justification and authorize the project manager to initiate the project. PRINCE2 uses the
term ‘outline business case’ for this initial justification. Other approaches may use terms such as
‘strategic outline case’. The outline business case is documented in the project brief.
In most cases, the project costs, timescales, products, risks, and targets will not be sufficiently
understood at this point to provide a robust justification of the entire project. Therefore, the outline
business case will need further development and refinement. As the project is planned in more detail
and information becomes clearer, the outline business case is developed into a more detailed business
case. PRINCE2 uses the term ‘full business case’ to describe this enhanced business case. Other
approaches may also use the terms ‘detailed business case’ or ‘final business case’.
The evolution from the project mandate to the project brief and the (full) business case is shown in
figure 5.2.

Project
mandate

Contains the outline business

Project brief
case in response to the mandate

Provides the full business case

Business case
in response to the project brief

Figure 5.2 Evolution of the business case

Chapter 5 - Business case

59
 Confirm benefits Confirm benefits Confirm benefits

Subsequent Final
Pre-project Initiation delivery delivery Post-project
stage stages stage

Check outline Check full Check updated

business case business case business case

Develop business case Maintain business case

Figure 5.3 Business case through the project lifecycle

Chapter 5 - Business case

61
[Link] Maintain
At the end of each stage, the project manager updates the business case with the progress data (such
as products delivered, projects costs, benefits realized) and the latest forecasted benefits and
performance targets. It is important to maintain the business case with appropriate version control so
that previous versions can be accessed for reference and comparison.

[Link] Confirm
The business will review the business case as part of a post-project benefits review to determine the
project outcomes in realizing their benefits. They will also assess whether the intended benefits have
been realized in practice. During the project, benefits reviews should be conducted at stage boundaries
to confirm that any benefits forecast to be achieved during the project are on track to be realized.

Chapter 5 - Business case

As shown in figure 5.1 (see section 5.1), projects deliver outputs, and the use of those outputs will result
in outcomes that provide benefits to the business. It is important that the project management team
understands the benefits and outcomes the project should realize. Otherwise, it is unlikely to be able to
develop the right outputs or build and sustain commitment to the changes during the project’s lifespan.
The senior user, who is responsible for specifying the benefits from the project, is also accountable for
confirming that the forecast benefits are realized. This may involve a commitment beyond the life of the
project, as it is likely that many benefits will not be realized until after the project has closed. For this
reason, it is usually advisable that the senior user comes from an area of the business impacted by the
change. However, this poses a dilemma because when the project closes, the ‘temporary organization’
is disbanded along with the framework (and in particular the funding and resources) to perform any
measurement activities.
The benefits management approach defines the management actions that will be established to ensure
that the project’s outcomes are achieved and to confirm that the project’s benefits are realized. It is first
created by the project manager in the ‘initiating a project’ process during the initiation stage and is
submitted to the project board for approval when seeking project authorization. If the business is to
manage or participate in the benefits reviews, the project board may need to seek its approval. The
benefits management approach may be managed by the project or by the business and is likely to be
managed beyond the life of the project.
Any benefits that can be measured during the life of a project should be confirmed by the senior user
for formal reporting by the project manager in the end stage reports and end project report. When
benefits can be reviewed during the life of the project, the benefits management approach should
include appropriate mid-project benefits reviews. Any forecast benefits that are unrealized should be
re-examined and their forecasts updated as part of the ‘managing a stage boundary’ process.
Post-project benefits reviews will involve the business holding the senior user accountable by asking for
evidence of how the individual benefits allocated to them have been realized, with corrective actions
taken to achieve benefits that have not been fully realized. The post-project benefits reviews will also
review the performance of the project product in operational use and identify whether there have been
any side effects (beneficial or adverse) that may provide useful lessons for other projects.
The project executive is responsible for ensuring that benefits reviews are planned and executed. For
post-project measurement activities, the responsibility for benefits reviews transfers from the project
executive to the business (specifically the senior user) when the project closes, as the reviews will need
to be funded and resourced.

63
5.3.2 Supporting techniques

[Link] Investment appraisal

An investment appraisal compares the costs of developing, operating, and maintaining the project
product with the value of the benefits over a period of time. The investment appraisal looks at the
relationship between benefits, costs, and risks. It should cover both the project costs (both in producing
the required products and the project management costs) and the ongoing operations and
maintenance costs.
There are many investment appraisal techniques available to organizations that will often have
preferences on which technique to adopt for specific projects. The selection of techniques may be
influenced by the type of business (such as those that have to follow public sector accounting rules) or
the organization’s own standards.
Examples of investment appraisal techniques include the following:
 Multi-case model
Evaluating investments from different perspectives, rather than focusing solely on financial return, gives
a rounded view of whether an investment is desirable, viable, and achievable. Examples of some
different investment perspectives include:
 Commercial context
Customers and suppliers will have their own business justifications for participating in the project and
may need their own business cases. The customer needs to ensure that its project is viable, and the
risks are acceptable, considering the suppliers chosen. A supplier would have to ensure that it will
benefit from the work it undertakes on the project. In other words, that it would be worthwhile from the
supplier’s perspective.
Successful projects ensure these business cases are aligned and compatible recognizing that there may
be elements of each business case that are private to each organization. It is the responsibility of the
project executive to ensure compatibility through the alignment of the three project interests of the
user, the business, and the supplier on the project board.

5.4.3 Delivery method

An iterative-incremental approach may require more information on the benefit tolerances, priorities,
and timescales. Additionally, it may also need details of the extent and sequence of the scope to be
delivered. Given the fixed cost and time, one way to present a business case is to show the best case,
expected case, and worst case of the scope that can be used.
When creating a business case, it is important to understand how incremental delivery of a product and
the value associated with it could impact the project’s viability (positively or negatively) and also the
ability to achieve the early realization of some benefits. If there is a high level of uncertainty, the
business case should be developed, and the assumptions should be tested quickly.
When using an iterative-incremental delivery method such as agile, the understanding of what is to be
delivered will increase throughout the project together with understanding the benefits. Thus, the
business case would evolve much more during the lifecycle of the project than for a linear-sequential
project. The business case may also be framed as having a worst-case scenario when only the “must
have” requirements are delivered and an expected-case scenario when the “must haves” and “should
haves” are delivered and a best-case scenario when the “could haves” are also delivered.

5.4.4 Sustainability
The United Nations defines 17 sustainability development goals to improve health and education,
reduce inequality, and encourage economic growth while tackling climate change. Many organizations
have signed up to align with these targets. Organizations may define specific business objectives related
to improving sustainability, and specific organizational policies, targets, and frameworks to achieve their
ESG commitments. It is important that the sustainability targets for the project align with the
organization’s broader objectives and any ESG targets it has defined.
If a project’s primary purpose is to satisfy a sustainability objective, then using traditional methods of
investment appraisal may not be effective when assessing its business justification. For example, a
project to build a flood defence barrier, where benefits may not be achieved for 20 or 30 years, may be
difficult to justify using discounted cash flow methods, where the future value of money, and therefore
benefits, is worth less than today. The approach to assessing business justification may need to be
adapted for this type of project.

Chapter 5 - Business case

67
5.5 Management products to support the
practice
PRINCE2 includes 16 management products that are used to manage the project. The management
products specific to the business case practice are described here.
Management product: Business case

Purpose
The purpose of the business case is to document the business justification for undertaking a
project, based on the estimated costs against the expected benefits to be gained and offset
by any associated risks. It should outline how and when the expected benefits can be
measured.
High-level content
Executive summary highlights the key points in the business case, which should include
important benefits and the return on investment
Reasons defines the reasons for undertaking the project and explains how the project will

Chapter 5 - Business case

enable the achievement of business objectives
Business options analysis and reasoned recommendation for the options including any
assumptions upon which the options are based
Expected benefits and dis-benefits benefits and dis-benefits expressed in measurable
terms against the situation as it exists prior to the project. The measures include benefits
tolerances
Sustainability targets specific targets relating to sustainability that the project must meet.
The targets include sustainability tolerances
Time the period over which the project will run and the period over which the benefits will be
realized
Costs a summary of the project costs, the ongoing operations and maintenance costs, and
their funding arrangements
Investment appraisal compares the aggregated benefits and dis-benefits with the project
costs and ongoing incremental operations and maintenance costs in order to define the value
of a project as an investment
Major risks a summary of the key threats and opportunities associated with the project,
together with their likely impact and responses
References for any associated documents or products.

Management product: Benefits management approach

The benefits management approach is part of the project initiation documentation.

Purpose
The purpose of the benefits management approach is to define the benefits management
actions and benefits reviews that will be established to ensure that the project’s outcomes
are achieved and to confirm that the project’s benefits are realized.
Box continues

69
describes what benefits are to be managed and measured
Benefits realization procedures describes what management actions are required to ensure
that the project’s outcomes are achieved (This should include arrangements for benefits
realization activities to be undertaken by the business layer after the project has closed. For
example, preparing and handing over a benefits realization plan.)
Benefits measurement describes how to measure achievement of expected benefits, when they
can be measured, and the baseline measures from which the improvements will be calculated
Benefits tolerance guidance Provides additional guidance to the benefits tolerance levels
defined for the project in the business case
Product performance describes how the performance of the project product will be
reviewed
Responsibilities defines the responsibilities for business case activities, including who is
accountable for the expected benefits
Resources for the benefit management activities, for example, to undertake studies
Supporting tools and techniques for the benefit management activities, for example, use of
a simulator
Standards any standards which apply to benefit measures
References for any associated documents or products.

Management product: Sustainability management approach

The sustainability management approach is part of the project initiation documentation.

Purpose
The purpose of the sustainability management approach is to define the actions, reviews, and
controls that will be established to ensure that sustainability performance targets for the
project are achieved.
High-level content
Scope describes what sustainability targets are to be managed and measured
Measurement describes how to measure achievement of sustainability targets, when they
can be measured, and the baseline measures from which targets will be calculated
Responsibilities defines responsibilities for sustainability activities, including who is
accountable for measuring the achievement of the sustainability targets
Resources for the sustainability management activities, for example, to undertake studies
Supporting tools and techniques for the sustainability management activities
Standards any standards which apply to sustainability management
References for any associated documents or products.
5.6 Focus of key roles for the practice
PRINCE2 defines seven key roles to manage a project. Their responsibilities specific to the business case
practice are described here.

Chapter 5 - Business case

71
 CHAPTER 6
ORGANIZING
6.1 Purpose
 Chapter 6 - Organizing

Figure 6.1 The three project stakeholder groups

75
 Commissioning
(business layer)

Directing
(project board)

Project
Managing
management
(project manager)
team

Delivering
(team managers)

Figure 6.2 The four organizational layers

Chapter 6 - Organizing

77
 Business layer

Project board

Senior Senior
Executive
user(s) supplier(s)

Project
assurance

Project
manager

Project
support

Team
manager(s)

Team members
Within the project
Lines of authority
management team
Project assurance
From the business responsibility
From the supplier Lines of support/advice

Figure 6.3 Project management team structure

[Link] Project executive
The project executive is appointed by the business as the single point of accountability for the project
and is ultimately accountable for the success of the project. This accountability cannot be delegated.
The project executive secures funding for the project and is responsible for the business case and the
continued business justification of the project. They are responsible for effectively governing the project
in a way that is aligned to the business strategy, including ensuring longer-term thinking on topics such
as environmental or social impacts.
There cannot be more than one project executive role, and the role cannot be combined with the
project manager role. In organizations where there is a job-sharing scheme, there is still a one-to-one
allocation of the business role (job) to the project role (project executive). However, additional
arrangements may be needed to ensure there is clarity on how the single point of accountability will be
maintained by the job holders who share the business role. The business’ policies and guidance relating
to job-sharing are likely to address such scenarios, and they should be reflected in the project
executive’s role description and the project initiation documentation.

Chapter 6 - Organizing
[Link] Senior user
The senior user represents the user community and is accountable for the approach taken to capture
user requirements and the specification of benefits aligned to the business case. The senior user is
responsible for:

79
 Project board
All PRINCE2 projects must have a project board comprising the project executive, senior user, and
senior supplier roles. On smaller and less complex projects, the role of the project executive can be
combined with the role of the senior user or the senior supplier. It is not recommended to combine the
senior user and senior supplier roles to avoid conflicts of interest in decision-making and ensure that
the perspectives and interests of the user and supplier communities are adequately represented on the
project.
The project board has authority and responsibility for the project within the project tolerances set by
the business, often captured in a project mandate. They are responsible for creating the right
environment for the project to succeed, including:
 Work breakdown structure

Figure 6.4 PRINCE2 technique for organizational design and development

[Link] Understand the organizational ecosystem
Projects unite people from organizations that already have defined organizational structures and
corporate governance requirements. An understanding of the organizational ecosystem is required to
successfully design the project organization and determine how the project ecosystem will develop as a
distinct entity from the organizational ecosystem.
As a temporary organization, the project approach needs to define how the project will interface and
align with the organizational ecosystem where required. There should be clarity on who retains
responsibility for issues such as:
 Manage the ongoing changes to the project ecosystem
People require time to become familiar with the project and to gain the capability and develop the
relationships to fulfil their roles. It is critical to have clear feedback loops established to determine
whether there are any capability or capacity gaps or relational issues to address.
The project manager is responsible for making the best use of the people and resources available,
enhancing capabilities where required. They do so by ensuring people’s responsibilities are matched to
their capability and capacity, sourcing additional skills and capabilities, or upskilling people through
coaching and learning opportunities.
The capabilities required on a project will change over the project lifecycle, requiring the project manager
to ensure the commercial management approach supports this, transitioning people onto and off the
project as required, and enhancing capacity and capabilities. The project manager must also ensure that a
robust change management procedure is established to ensure the impact on different areas of the
project ecosystem are considered in decision-making. One way this can be done is to identify the new
capabilities that the products will provide and review any barriers to getting this new capability embedded
into business as usual activities. Clarifying these barriers early in the project lifecycle will highlight new
project risks or issues and establish expectations on a realistic time frame for benefits realization.
A project stage is often defined by these transition points in the required capabilities. This is a good
point to review the project management team structure and the associated roles and responsibilities,
ensuring that the commercial management approach supports the proposed changes.

[Link] Transition the project into the organizational ecosystem

As with the start of a project, at the close of a project, it is important to understand the organizational
ecosystem that the products of the project and any remaining project team members will be transitioning
into. There are three key aspects the project board needs to consider as part of the transition:
 described in the commercial management approach and reflected in the
project management team structure.
Chapter 6 - Organizing

89
 Sustainability
The project executive is responsible for ensuring that the project remains aligned with the business
objectives. This typically includes targets for environmental, social, and governance (ESG) objectives, the
UN’s sustainable development goals (SDG), net zero, waste reduction targets, reuse of materials, the
decommissioning approach, and so on.
Projects are often the vehicle for driving forward an organization’s sustainability targets, whether that is
their primary focus or as a by-product of how they are delivered. To support this, there should be clear
accountability for sustainability targets across the project ecosystem captured in the business case, the
requirement setting, and people’s role descriptions. The organization of the project impacts its ability to
deliver sustainably. The project approach should empower team members to deliver sustainably,
embedding sustainability considerations into all decision-making and ensuring a diversity of
perspectives to challenge the way things have always been done.
The project management team structure and role descriptions should define responsibilities for
delivering the sustainability targets, including how they will be managed once the project is concluded.
The commercial management approach should ensure that the way products are ethically procured,
and the performance measures applied enables meeting sustainability targets.
knowledge and capacity to make those decisions reside. The use and composition of a change authority
is documented in the issue management approach.
The project board is responsible for ensuring clarity as to who is authorized to make decisions within
what tolerances. These authorities should be established during the initiation stage and captured within
role descriptions and the relevant management approach. Delegated authorities should be reviewed at
each stage and whenever a project tolerance or authorized person changes. (See Chapter 10 for more
information on change control and issue management.)

6.5  anagement products to support the

M
practice
PRINCE2 includes 16 management products that are used to manage the project. The management
products specific to the organizing practice are described here.
Chapter 6 - Organizing

93
6.7 Key relationships with principles
The organizing practice contributes to the adherence to PRINCE2 principles across the project lifecycle.

Chapter 6 - Organizing

95
 CHAPTER 7
PLANS
7.1 Purpose
Chapter 7 - Plans

99
 Levels of plans
All PRINCE2 plans have the same fundamental structure. What differs is the purpose, scope, and level of
details. For example, a project plan, which covers the full project lifecycle, is less detailed than a stage
plan that only covers a single stage. Whatever the type of plan, it should provide sufficient information
for the project management team to be confident that it represents a realistic assessment of the
products to be delivered and the work required to deliver them.

Project mandate and business

plan and/or programme plan

Project plan

Initiation stage Subsequent

Exception plans
plan stage plans

(as necessary)

Team plans

Figure 7.1 Relationship between PRINCE2 plans

The project plan is created during the process of initiating the project and baselined upon its approval
by the project board. In the process of managing a stage boundary, any necessary changes to the
project plan should be approved by the project board and reflected in an updated and baselined
project plan.

[Link] Stage plan

[Link] Team plan

Chapter 7 - Plans

103
Determining how to divide the project into stages is a matter of balancing:
 Stages and work packages
PRINCE2 stages do not overlap. Instead, they partition the project by introducing stop-go decision
points. By not overlapping, they enable the project management team and project board to review
progress and assess whether the project has continued business justification and therefore should
proceed to the next stage. The stages also enable the project management team and project board to
maintain alignment with the business case through the plans for the subsequent stage and the
decisions taken at stage boundaries.

Stage 1 Stage 2 Stage 3 Stage 4

Specification
High-level Detailed
design design

Site Ground
Utilities
preparation works

Substructure

Superstructure
Public
Fit-out realm

Operations plan Mobilised operations

Figure 7.2 Illustration of stages and work packages

 Definition: Time tolerance

The permissible deviation in a plan’s time that is allowed before the deviation needs to be
escalated to the next level of management.
7.2.5 Product-based planning

Chapter 7 - Plans

107
 Defining and analysing products

Organizing work packages

Preparing estimates
Analysing risks

Repeated for:
• Project plan
• Stage plan
• Team plan
Preparing schedule

Preparing the budget

Documenting the plan

Figure 7.3 The PRINCE2 planning technique

Figure 7.4 Defining and analysing products

Chapter 7 - Plans

109
[Link] Creating a product breakdown structure

LouisShopping

Connections Shopping mall Pathways, Plaza, Gardens

Revised bus routes

and timetable
Operational
Enabling works Mall Mall tenants
readiness

Revised rail
timetable
Cleared & secured Operations needs
Substructure Tenants secured
site assessment

Park & ride

Utilities Superstructure Fit-out for tenants Operations plan

External
product Mechanical,
Mobilised
Systems Electrical, Tenants ready
operations
Plumbing

Figure 7.5 Product breakdown structure for LouisShopping project

Another function of a product breakdown structure is to group requirements related to the same
procurement or delivery method. In the house example, the land is likely purchased in a different way
and from a different source than the construction of the house.
It may be worth considering whether to include different states of a particular product. For example,
the mall may start as a design from an architect, then become a construction effort by a construction
team, and then a decorator for the interior finishing. Although the owner’s goal is to obtain a building
with units which can be let to tenants, there may be quality specifications for each state.

[Link] Writing product descriptions

In the process of initiating a project, the required products are described in more detail. The project
manager elicits the user’s requirements for these products and documents them in one or more
product descriptions. The project manager also consults with subject matter experts to determine
requirements related to how these products are procured, developed, tested, used, and supported
after acceptance. The aim of this more detailed step is to confirm that the requirements for the major
products have been described in sufficient detail to enable realistic scheduling and estimation.
The definition and analysis of products may be an iterative procedure. In a linear-sequential project, the
product descriptions should be sufficiently detailed to enable costs and time to be estimated at an

Chapter 7 - Plans
appropriate level of confidence. However, in an iterative-incremental project, the detailed requirements
for products may be developed in parallel with the products themselves, and a high-level set of product
descriptions may be sufficient to proceed with the stage in which they are to be developed.
Projects rarely have the luxury of fulfilling all user expectations without regard to constraints. For
example, a desirable product option that has a high energy demand may be in conflict with
sustainability constraints set for the project. For this reason, it is helpful to prioritize quality
specifications for each product to ensure that the most important requirements are met.

[Link] Creating a product flow diagram

111
Figure 7.6 Product flow diagram for LouisShopping project
[Link] Organizing work packages
The product flow diagram helps the project management team decide whether the project should be
delivered in a linear-sequential or iterative-incremental manner.
When the delivery method is decided, the delivery activities involved in each product can be identified
and organized into work packages. Each work package should combine closely related people,
resources, and delivery activities. Also, each should create at least one required end product or an
intermediate product required as an input to a subsequent work package.
If a work package depends on delivery of a product from another work package or from an activity
outside the scope of the project, this relationship is considered a dependency.

Chapter 7 - Plans

113
Finally, the work breakdown structure helps in developing team plans, where necessary work to deliver
the products can be detailed in terms of tasks and the team members assigned to them. The work
breakdown structure is optional for simple projects with one or two products or work packages and
small delivery teams.

[Link] Preparing estimates

Project managers and team managers always plan using estimates of:
 Preparing the budget
The people and resource requirements can be listed, and their costs along with other costs can be
calculated to produce the plan’s budget. The budget should include:
 Estimating
A variety of estimating techniques are available to project managers. These include the following:
 Organizational context
Project planning is often influenced by organizational context, including policies, procedures, and
support. For example, the project budget may need to be prepared according to procedures for
handling capital investment expenditures. Projects in governmental or other public organizations may
need to comply with regulatory requirements and ensure transparency in record keeping.
alignment with the acceptance criteria and quality specifications approved by the project board. This
approach is often referred to as a back-to-back agreement.
The agreement should state how these plans are to be produced and what rights of inspection and
audit the user has. The supplier’s plan should have sufficient activities or milestones for the user’s
project manager to maintain their plans.
Both the user’s and supplier’s plans may be confidential to the other party as they may contain other
information, such as dependencies to or from other client projects or subcontractor costs. Therefore, it
is beneficial to prepare non-confidential versions of the plan that can be shared while omitting private
information.
Plans need to include procurement-related milestones such as purchase orders and milestone
payments aligned with each stage.

Chapter 7 - Plans

119
 Key quality terminology
PRINCE2 uses a specific set of terms to characterize information about the needs of project
stakeholders and enable effective quality planning, quality control, and quality assurance. These terms
are:
Chapter 8 - Quality

131
 Product sustainability
Product descriptions should include product sustainability requirements captured as quality
specifications or acceptance criteria. Product sustainability considers both the environmental impact of
the product and the characteristics that will ensure that the product can sustain the realization of its
benefits over its expected lifetime. It may be appropriate to consider how a product will be
decommissioned if that work represents a significant portion of its overall environmental impact.

[Link] Quality responsibilities

To avoid confusion and potential conflicts, the quality responsibilities for a product should be specified
in the product description. Quality responsibilities are often described as the following:
Quality assurance
Chapter 8 - Quality

137
8.3.2 Supporting techniques
An understanding of the types of quality techniques used and their timing, location, and resource
requirements is essential to project planning. Although a wide range of quality techniques exist, the
most commonly used in a project context are:

Chapter 8 - Quality

139
 Delivery method

[Link] Linear-sequential projects

In a linear-sequential delivery method, there is generally more information about the required products
and their delivery activities. This enables product descriptions and quality specifications to be
developed in sufficient detail to support scheduling and estimation to a higher level of confidence.
However, this does not mean that there will be no changes in requirements in the course of production
or delivery. Instead, the sequence of delivery activities is typically designed to allow uncertain aspects of
product requirements and quality specifications to be addressed early, thereby reducing the level of risk
in later stages.
In addition, as with all projects, acceptance criteria and quality specifications may be affected by
changes external to a linear-sequential project and addressed through change control. An example of
such an external change would be the introduction of new regulatory requirements for a project
product.
Chapter 8 - Quality

143
Chapter 8 - Quality

145
 CHAPTER 9
RISK
9.1 Purpose
standard helps organizations with their risk analysis and risk assessments. PRINCE2 risk approach is also
aligned with regional variants of the ISO standard and can be tailored to meet these local requirements.

9.2 Guidance for effective risk management

Effective risk management provides confidence that the project can meet its objectives, and the
business justification continues to be valid. It supports decision-making by ensuring that the project
team understands not only individual risks but also the overall risk exposure that exists at a particular
time.
For risk management to be effective:

Chapter 9 - Risk

149
 Risk planning
The use of risk categories helps projects to identify and prioritize risks. Techniques such as PESTLE
(political, economic, social, technological, legal, and environmental) analysis and SWOT (strengths,
weaknesses, opportunities, threats) analysis (both described later in this chapter) can be used to
analyse the internal and external context for risks. These techniques also help to identify different types
of risk that may affect the project (for example, sustainability, cybersecurity, or systems integration). An
understanding of the types of risks can also help to identify the most appropriate owners.
A key item that needs to be recorded in the risk management approach is the project board’s attitude
towards risk-taking, documented as the risk tolerance. The risk tolerance will be set by the project board
based on the business’ overall risk appetite.
An important aspect of identifying risks is the ability to provide a clear and unambiguous expression of
each risk. A useful way of expressing risk is to consider the following aspects:
 PRINCE2 technique for risk management
PRINCE2 includes a five-step risk management technique (identify, assess, plan, implement, and
communicate) as shown in figure 9.2, based on Management of Risk: Creating and Protecting Value.
An alternative procedure can be used if desired, for example, if the project is part of a programme that
has a programme-wide risk management technique. The use of an alternative procedure should be
documented as part of the tailoring decisions in the project initiation documentation.
The following will have an influence on the project’s risk management approach:
 Plan
This step involves identifying and evaluating the appropriate risk response to remove or reduce threats,
and to maximize opportunities. Typical risk responses are summarized in table 9.1.
Any chosen response needs to be included in the appropriate level of plan. For more significant risks, it
may be appropriate to establish not only early warning indicators to identify whether the risk is likely to
materialize but also plans for managing the risk should it occur.
The risk response needs to identify the most appropriate body to manage a risk. This may not be the
project team, especially if:
 Supporting techniques
Table 9.2 shows examples of additional techniques that support the PRINCE2 risk management
technique. The risk management approach should document which specific techniques are used on the
project.
 Strengths Weaknesses

‘Green town’ status Low level of trust from the town

residents
Solid funding available
Outdated infrastructure
Strong town’s reputation
Shortage of parking spaces
Experienced main contractor
Little experience in the city
Standard for construction agreed council to act as ‘intelligent client’
with Buildy Brick

Opportunities Threats

Increasing residents’ sustainability Competition from nearby towns

awareness
Economic crisis approaching
Increasing number of tourists
Shortages in building materials
External funding possible to obtain supply

Cooperation with twin and Changes in national law and

partner towns construction industry regulations

Possible archaeological discovery

Chapter 9 - Risk
Figure 9.3 SWOT analysis for LouisShopping project

159
[Link] The Swiss cheese model
The Swiss cheese model shows that for a risk to actually occur, multiple levels of controls must fail (or in
the Swiss cheese analogy, the holes in the cheese must align). This technique is useful for considering
whether risk controls are sufficient.

[Link] Use of data

The use of data to identify, analyse, and control risks can give deeper insight into and understanding of
the risks facing a project, the relationships between them, and the most appropriate controls for risk
mitigation. For example, use of data analytics on data sets containing similar projects, products, or
tasks may provide a better understanding of the project’s predisposition to certain risks and therefore
their probability, impact, and priority. Robotic process automation (RPA) may be used to automate
aspects of the risk procedure to aid the assignment of actions and the monitoring, reporting, and
escalation of risks.

9.4 Applying the practice

9.4.1 Organizational context

A project may need to align its approach to risk management with organizational, programme, or
portfolio policies, standards, or approaches. This might include:
 Commercial context
In a commercial context, there may be a need for more than one risk register. Some project risks could
be unique to only one party that may have good reasons for not making the risk register visible to the
other party. When a joint risk register is used, care should be taken to establish whose risk it is, and as a
result, the risk owner should be appointed accordingly. For example, on a fixed price contract, any cost
overruns will impact the supplier’s business case, but timescale overruns will typically impact the
customer’s business case.
In order to adapt and tailor PRINCE2 in the best way possible, it is important to assess the context in
which a project exists with regard to the environment and the working relationships. To help achieve
this, an assessment tool such as the Agilometer in PRINCE2 Agile can be used to answer the question,
‘how agile can we be on this project?’.

9.4.3 Delivery method

The approach to managing risk needs to work with and support the project’s chosen delivery method.
For example, a risk management approach that includes monthly risk review meetings will struggle to
support an iterative-incremental delivery method with two-week sprints.
The PRINCE2 method does not require a particular format for risk management products, nor specific
timings for risk management activities. What is important is that they are appropriate for the format and
pace of the project. For example, in an agile delivery method, risks in a risk register may be written on a
whiteboard and reviewed as part of a daily stand-up meeting. In this context, this manual approach may
be just as valid as using a specialized IT system to capture and review risks.
It is also important to recognize that the project’s delivery method might work to mitigate or reinforce
specific risks. For example, an agile way of working inherently ensures that users do not overspecify
requirements at the beginning of a project, which can be a risk in a more linear approach.
Although agile is characterized by a high level of engagement with the users directly involved in the
project, if not managed correctly, it can lead to uncontrolled changes to the agreed baseline. Linear
approaches tend to reinforce the impression of ‘controlled change’ but can appear unresponsive and
alienate users. It is of importance that the risk management approach recognizes these inherent
differences.

9.4.4 Sustainability
A project will have specific sustainability targets and tolerances incorporated into its business case.
These should be assessed for risks. Risk management considerations related to sustainability can
include:
Change control
10.2.4 Delegating authority for changes
The project board is the ultimate authority for reviewing and approving requests for change and off-
specifications. However, the project board may delegate authority to approve changes. Delegating
authority for effective change control is a matter of balancing efficiency and control. If there is too little
delegation, the project board is likely to slow the progress or be asked to review changes that others are
better able to decide. Whereas, if there is too much delegation, particularly to too many different roles,
there is an increased risk that the overall benefits of the project will be reduced as alignment with the
business justification is diluted.
In a project where few changes are envisaged, it may be reasonable to leave this authority in the hands
of the project board. However, for projects where there are likely to be many changes, the project board
may choose to delegate some decisions.
In practice, most changes will be generated at the work package level. It is important to ensure that
there is sufficient delegated authority to approve the changes for the work packages. In this way,
changes can be made without always having to escalate decisions to the project board for approval.
Subject to the scale and complexity of the project, it may be useful to delegate change authority to
several levels within the project management team. This is based on parameters specified in the issue
management approach.

10.2.5 Change budget

Chapter 10 - Issues

173
the programme. The use of an alternative procedure should be documented as part of the tailoring
decisions in the project initiation documentation.

Project board/change approval authority

Request for advice

Request for advice
or exception report
Capture Assess Recommend Decide Implement

• Determine • Assess impact • Identify • Escalate if • Take

issue type on project options beyond corrective
• Determine business case • Evaluate delegated action
severity/ and project options authority • Update
priority risk profile • Approve, records
• Recommend
• Register the • Check options reject, and project
issue severity/ ask for an baseline, if
priority exception necessary
plan, and
request more
information

Project log: issue register

Figure 10.1 PRINCE2 technique for issue management

[Link] Assessing issues
When reviewing issues, the aim is to answer these three questions:

Chapter 10 - Issues

175
 Supporting techniques
A variety of problem-solving techniques may be used to enable the assessment and resolution of
issues. Examples include:
 Iterative-incremental projects
Issue management and change control are intrinsic to the iterative-incremental approach. The frequent
review of progress and short cycles of delivery work (such as in agile methodologies) are intended to
raise and resolve issues quickly. This is to allow the scope baseline (sometimes referred to as the
product backlog) to evolve in a manner that keeps a close alignment between requirements and
developed capabilities of the product.
If the entire scope of the project’s delivery activities follows an incremental-iterative approach, it may be
sufficient for the project manager to ensure that issues are consistently captured, assessed, and
decided. This would be in a manner that provides traceability back to the project product description
and maintains an effective level of control.
In other cases, the project manager should consider structuring the issue management approach to
allow the project board to retain change authority over management products. Meanwhile, delegating
authority over changes in features and functionality in specialist products to the teams working within a
framework such as PRINCE2 Agile. The issue management approach may include the agile technique of
trading/swapping features in response to issues as a means of remaining within tolerance.
Agile methods enable change late in the product development lifecycle to deliver a product that better
matches user expectations with the biggest possible value. This philosophy applies when products are
difficult to define in detail early in the project.

10.4.4 Sustainability
Sustainability can be a source of significant issues and changes from outside the project, particularly in
the areas of regulatory requirements and supplier capabilities. If sustainability and environment
impacts are a major aspect of the project, the issue management approach should ensure that
someone in the project management team is tasked with the responsibility to monitor external sources
of potential issues and changes.

10.4.5 Scale
The project manager should consider the following in developing the issue management approach:
Table continues
Chapter 11 - Progress

193
within projects is essential because it helps to identify responses to project risks, predict project
outcomes, and help ensure overall project success.
It is important to consider the performance of the project so far and other projects inside or outside
the organization. Although time and cost are often stated as the key metrics to track, all seven PRINCE2
performance targets should be considered.
The collected data is then sifted, collated, and analysed to provide the project manager with sufficient
information on the past performance to predict the future risks and outcomes, as well as determine
whether the project retains a continued business justification. Again, the data may be held in an
integrated system, which may also allow for ‘what if’ scenario forecasting, to ease the forecasting
workload for project managers.
The digital and data management approach will describe what systems and data will be used by the
project to assist with forecasting. This may involve using data from outside the project or the business,
for example, from a data trust as a reference class to enable predictive data analytics to be used.

11.2.6 Escalating
The output derived from reviewing progress is a decision as to whether the work package, stage plan, or
project plan will remain within or exceed the agreed tolerances. If they exceed or are forecast to exceed
the agreed tolerances, then they are in exception.

[Link] Work package level exceptions

After agreeing the work package tolerances with the team manager, the project manager should be kept
informed of progress with regular checkpoint reports. If a work package is forecast to exceed its
tolerances, the team manager should inform the project manager by raising an issue for the attention of
the project manager. The project manager will advise of any corrective actions required.

[Link] Stage level exceptions

If the stage is forecast to exceed its tolerances, the project manager should produce an issue report to
capture and analyse the data behind the deviation and then provide an exception report for the project
board. Based on information in this report, the project board may request that the project manager
produces an exception plan to replace the plan that was forecast to exceed tolerance. The project board
may also remove the cause, accept or adjust the tolerance, or request more time to consider the
recommendations. If an exception plan is requested, the project board will review and either approve or
reject the exception plan.

[Link] Project level exceptions

If the forecast is for project tolerances to be exceeded, the project board no longer has the authority to
direct the project and must refer the matter to the business layer for a decision. The project board may
request the project manager to produce an exception plan for the project.
Chapter 11 - Progress

195
11.3 Techniques: progress management

11.3.1 PRINCE2 technique for exception management

PRINCE2 includes a six-step exception management technique shown in figure 11.3. An alternative
procedure can be used instead if desired, for example, if the project is part of a programme that has a
programme-wide exception management procedure. The use of an alternative procedure should be
documented as part of the tailoring decisions in the project initiation documentation.
Although this technique mentions reports, this does not preclude the use of systems and data from
performing the same function.

Stage 2a (new)

Directing a project
3 5

Exception Exception New stage

report plan plan
2 4

Managing a stage
Controlling a stage 6 Controlling a stage
boundary

!
Issue
1
Managing product
delivery

Figure 11.3 PRINCE2 technique for exception management

Chapter 11 - Progress

197
11.3.2 Supporting techniques
Measuring the progress of a stage involves looking backward at the progress made against plans and
forward at what still needs to be completed with available time and resources. However, effective progress
management requires an open and transparent culture with a no blame attitude to progress reporting.
There are many supporting techniques, and those mentioned below may be used in isolation or
combined depending on the needs of the project or team. For example, the solution developers may
use Kanban as a team board to demonstrate progress and hold daily stand-ups for reporting purposes.

[Link] Dashboards
A dashboard is a technique to represent vast amounts of decision supporting information at an
amalgamated level using tabular and graphic representation, such as graphs and traffic lights.

Highlight Report Project NowBYou Campaign

RAG Project Sponsor Mary L
Overall Benefits Cost Time Quality Scope Carbon Risk
Status
Project Manager Tommy S
This period G G G A G A G A
Last period G G A G G R G A Reporting Period February

1. Achieved this period? 2. Expected achievements next period?

• Completed requirements gathering for new campaign • Complete options analysis for stage 3
• Establish coaching routine for Director of Campaigns

3. Pending Decisions and Changes 4. Critical Issues and Risks

• Waiting on Director of Campaigns to reduce the long list of • Issue: Coaching sessions for Director of Campaigns not
options to be analysed started
• Risk: there may be insufficient funding depending on
selected option
• Risk: stage 2 completion could be delayed if longlist of
options are not reduced soon

Project Manager’s Commentary

All identified stakeholders have been consulted and their needs captured in the requirements document. The sponsor will
present the project at the next donors forum to gain (financial) support to enable the campaign to deliver to objectives.

Project Budget Actual Cost Forecast Cost Cost Variance Variance Commentary

Based on initial estimates on the Business Case, additional

£ 45,000 £ 4,000 £ 55,000 +£ 10,000
10K may need to be secured via donations

No. Project Milestone Baseline Date Current Date Variance Commentary

1 High-Level Requirements Gathering Complete 10-February 10-February Completed

2 Financial support secured 05-March 05-March –

3 Options selected 24-March 31-March Too many options to analyse

4 Campaign Launch 10-July 10-July –

Figure 11.4 Example highlight report for NowBYou campaign

Chapter 11 - Progress

199
[Link] Earned value management
This is a technique to create an integrated project baseline combining scope, schedule, and cost
performance by comparing the completed products and the actual cost and time taken against their
schedule and cost estimates. Besides providing an objective assessment of past performance, it can be
used to forecast total project cost and duration based on historical performance. PRINCE2’s approach
to product-based planning provides information to support earned value management.

[Link] Peer review

A peer review is where people experienced in project management but outside the project
management team are asked to evaluate the project. Peer reviews may also be held between subject
matter experts in relation to a particular product. There are many peer review techniques, and the
quality management approach should identify the techniques appropriate to the project.

[Link] Burn charts

This is a technique for showing progress (for example, during a timebox), where work that is completed
and work still to be done are shown with one or more lines, and the chart is updated regularly (perhaps
daily). This is one of the most popular techniques when using an agile approach.
Burn charts come in two forms: burn-down charts and burn-up charts. Burn-down charts are the most
well-known, and they show how much work remains, whereas burn-up charts show how much work has
been done.
Burn-down charts identify estimation issues early and help viewers to understand how much work and
effort remains. Burn charts help motivate teams by showing progress toward the project’s outcome.

Project X
300 300

250 250

200 200

150 150

100 100

50 50

0 0
Start Week 1 Week 2 Week 3 Week 4 Week 5 Week 6 Week 7 Week 8

Planned hours Actual hours Actual effort Effort to complete

Ideal burndown
Figure 11.5 Burn down chart
[Link] Retrospectives
A retrospective is a type of progress review that specifically considers the way of working as opposed to
looking at what was produced.
To be fully effective, a retrospective should be planned, structured, and actively facilitated. They can be
quite informal, but if they are run as an unstructured meeting, they are likely to become ineffective and
not contribute to better ways of working.
Running an effective retrospective is similar to running a successful workshop, and should consider:

Chapter 11 - Progress

Figure 11.6 Kanban board example for timebox 1

201
11.4 Applying the progress practice

11.4.1 Organizational context

A starting point for any project will be to identify the timing of the business layer governance
arrangements from which the project will require decisions or authority. It is usually advisable to design
the project’s progress controls to align with business layer timings.
If the project is part of a programme or portfolio, then the programme or portfolio will usually dictate
the progress controls for the project. This will typically include defining common controls, procedures,
tolerances, and timings.

11.4.2 Commercial context

PRINCE2 is based on a customer/supplier environment. It assumes that there will be a customer who
will specify the desired result and (usually) pay for the project, and a supplier who will provide the
resources and skills to deliver that result. Additional considerations apply if the relationship between
the customer and the supplier is a commercial one.
The contract between the parties acts as a constraint on a project manager’s or team manager’s degree
of freedom when managing the project or work package. For this reason, it is good practice to ensure
that contracts reflect and promote good working relations rather than inhibiting them and that any
tailoring to PRINCE2 respects the parties’ contract obligations.
From a supplier’s perspective, the project lifecycle should be defined to consider pre-contract activities,
such as qualification, designing and costing the solution, bidding, and negotiation. It may also consider
activities at the end of the project, such as warranty and maintenance periods.

11.4.3 Delivery method

It is important that the approach to managing progress works with, and supports, the project’s chosen
delivery method rather than going against it.
For a project using an iterative-incremental delivery method, it will typically be more appropriate to
focus on tracking how much of the requirement is being met by the end of the sprint rather than how
long it will take to complete the products. The tolerances would have been set in accordance with this.
The frequent delivery of products that meet their acceptance and quality specifications is a primary
source of progress information and provides the basis for forecasting future progress.
The formality of reporting may differ in an iterative-incremental project using agile techniques such as
Kanban and burn-down or burn-up charts. Checkpoint reporting may be based on a ‘pull’ system,
where the project manager reviews the charts maintained by the development teams rather than being
sent by them.
By contrast, for a project using a linear-sequential delivery method, the focus may be on when the
stage’s products will be complete and for what costs. In this way, the project board can be confident
that there is a robust basis to move from the current stage to the next.
11.4.4 Sustainability
Progress management will gather data on those aspects of sustainability recorded in the project
implementation document that are critical success factors for the project. This is to check that the
project remains within its sustainability tolerances and the parameters established by the business
layer.
Some areas of sustainability will fall under legislation, regulation, or business layer policies. Therefore, it
will require evidence to support compliance. Progress management must be able to identify and report
on the data required to support this evidence.
The project executive may request an audit of the project if compliance against sustainability
regulations is required. Advice should be sought from the quality assurance function with the business
or programme.
Sustainability reporting should not be separate from the agreed reporting requirements but rather
integrated into the cyclical analysis of the project data by the project manager, team managers, and
project support. The activities in the plans should consider the data needed to satisfy sustainability
analysis, just as they should for the other tolerances within the project. This is so that evidential
reporting on sustainability is a consequence of progress management and not something that requires
additional activities or resource.

11.4.5 Scale
Progress management needs to be applied or tailored to reflect the needs of the project’s scale, risk,
complexity, and prominence. In simple projects where risk and complexity are minimal, the progress
practice may lend itself to some simplified data analysis for reporting and forecasting purposes. Some
of the roles may have been combined with a project executive sponsoring the project without a project
board. The style may be more relaxed, and this could lead the project manager to report progress in a
structured email rather than a formal report, for example.

Chapter 11 - Progress
For simple projects, questions that may be asked are:

203
 Pre-project
Before a project begins, someone has an idea or a need. The trigger for the project (which may come in
a wide range of ways) in PRINCE2 is called a project mandate. The project mandate is provided by the
business, (the organization commissioning the project) and can vary in form from a verbal instruction to
a well-defined and justified project definition.
Before formally starting a project, it is important to assess and confirm that it is worthwhile and viable.
This is done in the process of starting up a project (see Chapter 13), in which the project manager and
project board are appointed, and a project brief and a stage plan for the initiation stage are created.
The decision to proceed with project initiation is taken by the project board using their own process of
directing a project (see Chapter 14). The project board then reviews the project brief and stage plan and
decides whether and how to initiate the project and allocate the people and resources required.

12.1.2 Initiation stage

When a decision has been made to proceed with the project, it needs to be planned at an appropriate
level of detail. The planning, establishment of the project management approaches and controls,
development of a robust business case, and a means of reviewing benefits are covered by the process
of initiating a project (see Chapter 15). Also, during the initiation stage, the process of managing a stage
boundary (see Chapter 18) is used to plan the next stage in detail.
The initiation stage ends with the project initiation documentation being reviewed by the project board,
again using their own process (directing a project) to decide whether to authorize the project and the next
stage to proceed. The contents of the project initiation documentation are likely to change throughout the
project (under change control), so this version is preserved as the original baseline for later reviews.

12.1.3 Subsequent stages

The project board delegates day-to-day control to the project manager on a stage-by-stage basis. The
project manager needs to ensure that progress is in line with the approved plan and that forecasts for
the project are within agreed tolerances. The project manager informs the project board of progress
through regular highlight reports. The activities to control each stage are covered by the process of
controlling a stage (see Chapter 16).
The project manager needs to assign work to be done to the team managers or members, who execute
assigned work packages. They, in turn, keep the project manager informed of progress through
checkpoint reports. This work is covered by the process of managing product delivery (see Chapter 17).
Towards the end of each stage, the project manager requests permission to proceed to the next stage
by reporting how the current stage performed, provides an update to the business case, and plans the
next stage in detail. The project manager provides the information needed by the project board to
assess the continuing viability of the project and to make a decision to authorize the next stage. At all
times, the project board must ensure the project remains aligned with the business strategy. The
activities to manage each stage boundary are covered in the process of managing a stage boundary
(see Chapter 18).
12.1.4 Final stage
As a project is a temporary undertaking, it will be time to start the process of closing a project towards
the end of the final stage (see Chapter 19).
The project may have been transferring and transitioning individual products into operational use
throughout the life of the project. The project board now needs to be satisfied that the recipients of
each product are in a position to own and use them on an ongoing basis and that the business is able to
take overall ownership of the project product. Should this be the case, the project can close. The project
documentation should be archived, the project assessed for performance against its original plan, and
the people and resources assigned to the project need to be released. Closure activities include
confirming or revising the plans for the planning post-project benefits reviews to occur for those
benefits that can only be assessed after the project product has been in use (and therefore after the
project has closed).

12.1.5 Post-project
Even though some benefits may be realized during the project, in most cases, many or all of the
benefits will be realized after the project is completed. It is therefore likely that one or more post-
project benefits reviews will occur. The project’s benefits management approach will document how
and when these reviews should occur and who is responsible and accountable for them.

12.2 The PRINCE2 process model

The PRINCE2 process model is shown in figure 12.2. The processes are aligned with the management
levels of business layer, directing, managing, and delivering. The triggers between the processes are
shown.
Business
Advice and
Project decisions
mandate from the

Chapter 12 - Introduction to PRINCE2 Processes

business
Project Project Closure
Initiation
authorization board’s notice
notice
notice advice
request

Directing a project
Directing

Project Exception Stage Project Premature

initiation plan authorized board’s close
authorized request advice and notice
Exception decisions
plan
authorized
Exception
plan
approval
request
Project
Project Project Next stage closure
Starting up a project

initiation authorization request request

request request
Managing

Managing
Initiating
a stage Closing a project
a project
boundary
Exception
raised

Stage Project
boundary Advice end
approaching request approaching

New issue
Controlling a stage
or risk

Work
package
authorized
Completed
work
Delivering

package notice

Managing product delivery

Figure 12.2 The PRINCE2 process model

217
 of activities.

This is an activity within a PRINCE2 process. Each activity

contains a number of actions.

This is an event or decision that triggers a PRINCE2 process.

The direction of the arrow indicates which process is being
triggered. Where the arrow goes to the business layer, it
serves to notify the business of an update or request.
Double triggers indicate that there are alternative triggers
for a process.
Figure 12.3 Key to process diagrams
 CHAPTER 13
STARTING UP
A PROJECT
13.1 Purpose
The purpose of the process of starting up a project is to ensure that the prerequisites for initiating a
project are established by answering the question, ‘do we have a viable and worthwhile project?’
The decision to start the project must be explicit, as the activities within the process of starting up a
project happen before this decision. Nothing should be done until fundamental information needed to
make rational decisions about the commissioning of the project is defined, key roles and responsibilities
are resourced and allocated, and a foundation for detailed planning is available.
The purpose of the process of starting up a project is as much about preventing poorly conceived ideas
from ever being initiated as it is about progressing viable projects for approval. As such, starting up a
project is a lighter process compared to the more detailed and thorough process of initiating a project.
The aim is to do the minimum necessary to decide whether it is worthwhile to even initiate the project.

13.2 Objectives
The objectives of the process of starting up a project are to ensure:
 Directing a project

Project initiation
Project request
mandate

Appoint the
executive and
project manager

Assess previous Appoint the project

lessons management team

Prepare the
Select the project
outline
approach
business case

Assemble the project

brief

Plan the initiation Request project

stage initiation
The project board must be provided with sufficient information to make the decision to initiate the
project. The project brief is prepared for this purpose.
The effort involved in starting up a project can vary enormously from project to project. If the project is
part of a programme, the programme management team should provide the project brief and will
appoint some, if not all, members of the project board, thus eliminating much of the work required in
this process. In such cases, the project manager should validate what is provided by the programme
and, if necessary, recommend modifications.
The preparation of the outline business case and the assembling of the project brief, which are parallel
and iterative activities, require regular and frequent interaction and consultation between the project
manager, the project board members, and other stakeholders. The more time spent on clearly
capturing the requirements during the process of starting up a project, the more time will be saved
during project initiation and delivery by avoiding issues, exceptions, and replanning.
13.4.2 Assess previous lessons
A number of lessons may have been provided by other projects in the business and external
organizations. These lessons may include weaknesses or strengths of the processes and procedures, as
well as the techniques and tools used, when they were used, how they were used, and by whom. The
design of the project management team, the outline business case, the contents of the project brief,

Chapter 13 - Starting up a project

and the stage plan for the initiation stage can be influenced by lessons from previous projects.
It may be useful to hold a workshop as a means to capture relevant lessons. Attendees could include
any interested parties and people who have worked on previous similar projects. If the business has not
done this type of project before, it may be helpful to include people external to the business who have
the relevant experience.
Recommended actions for the project manager:

223
 Tailoring roles in starting up a project
It is good practice to appoint the project manager as early in this process as possible, but if a project
manager has not been appointed until later in the process, the required management products may be
created by the project executive or anyone appointed by them. Similarly, the project executive does not
need to create the outline business case personally but may have another person create this on their
behalf. The single point of accountability for each role’s duty should be maintained.
For more guidance on roles, see Chapter 6.

13.6 Responsibilities
Table 13.2 summarizes the accountability and responsibility for completing each activity in the process
along with who should be consulted and informed.
13.7 Application of the practices to this process
Table 13.3 summarizes how each practice supports the activities of the process of starting up a project.

Chapter 13 - Starting up a project

227
 CHAPTER 14
DIRECTING A
PROJECT
14.1 Purpose
The purpose of the process of directing a project is to enable the project board to be accountable for
the project’s success by making key decisions and exercising overall control while delegating day-to-day
management of the project to the project manager.

14.2 Objectives
The objectives of the directing a project process are to ensure:
 Give ongoing direction
Project board members must offer informal guidance or respond to requests for advice at any time
during a project. The need for consultation between the project manager and project board is likely to
be especially frequent during the initiation stage and when approaching stage boundaries.
Ongoing direction may be given collectively or by individual project board members. There are a variety
of circumstances that trigger ongoing direction, including:
 Authorize a stage or exception plan
It is important that a stage starts only when the project board says it should. The project board
authorizes a stage by reviewing the performance of the current stage and approving the stage plan for
the next stage. Approval of stage plans occurs prior to every stage.
The project board delegate project assurance by instructing a person or group to undertake some of
the reviewing and assessing actions, such as inspecting the stage plan to confirm it is viable. Where
project assurance activities are delegated, the project board remains accountable.
Recommended actions for the project board:
 Application of the practices to this process
Table 14.3 summarizes how each practice supports the activities of the process of directing a project.
 CHAPTER 15
INITIATING A
PROJECT
15.1 Purpose
The purpose of the process of initiating a project is to establish solid foundations for the project,
enabling the business to understand the work that needs to be done to deliver the project product
before committing to any significant expenditure or resources.

15.2 Objectives
The objectives of the process of initiating a project are to ensure that there is a common understanding
of:
 Prepare the project plan
Before committing to major expenditure on the project, the timescale, resource, and people
requirements must be established. This information is held in the project plan and is needed so that the
benefits management approach can be prepared, and the project board can control the project.
Planning is not an activity that the project manager performs in isolation but something that should be
done with close involvement of the users and suppliers to co-create the project plan. It is often useful to
hold planning workshops to help identify all the products required, their details, and the dependencies
between them.
Recommended actions for the project manager:
 Tailoring roles in initiating a project
This book shows that the project manager is responsible for the creation of the management products.
Project support may be responsible for some supporting products, but in all cases, the project manager
is responsible to the project executive for how the project is run. The project manager may therefore
assign the various roles to whoever is appropriate for the tasks. Often, support may be provided by a
higher-level programme office or a similar setup.
For more guidance on roles, see Chapter 6.

15.6 Responsibilities
Table 15.2 summarizes the accountability and responsibility for completing each activity in the process
along with who should be consulted and informed.
15.7 Application of the practices to this process
Table 15.3 summarizes how each practice supports the activities of the process of initiating a project.

Chapter 15 - Initiating a project

249
 CHAPTER 16
CONTROLLING A
STAGE
16.1 Purpose
The purpose of the process of controlling a stage is to assign work, monitor such work, handle issues,
report progress to the project board, and take corrective actions to ensure that the stage remains
within the tolerances set by the project board.

16.2 Objectives
The objectives of the process of controlling a stage are to ensure that:
 Authorize a work package
The degree of autonomy people require to deliver project work needs to be balanced with the need to
coordinate timing of when work starts and by when work should be completed. Project work should only
commence and continue with the consent of the project manager. Otherwise, the working environment
would be chaotic if people started performing activities whenever they chose. The vehicle for ensuring
the coordinated timing of project work is the authorization, execution, and delivery of a work package.
A work package should cover the work to create one or more products. If a product requires more than
one work package to create it, then it should be broken down into further sub-products with their
supporting product descriptions.
The triggers for the project manager to authorize a work package include the following actions:

Chapter 16 - Controlling a stage

255
 Receive completed work package
When work has been allocated to individuals or teams, there should be a matching confirmation that
the work has been completed and approved.
Recommended actions for the project manager:
 General considerations
The work package descriptions are fundamentally important to this process, as they relate to PRINCE2’s
principle to focus on products.
A work package description may vary in detail depending on the relationship between the business and
the supplier. It is good practice to include extracts from, or simply make cross-reference to elements of,
the project plan, stage plan, or project initiation documentation. This can reduce duplicate content.
The relationship between the project manager, project support, and team managers during the
controlling a stage process should be collaborative. The project manager is not delegating or assigning
tasks to team managers or project support but rather facilitating the process to improve ownership and
enable the team manager and project support to deliver their contribution to the project, and
ultimately, the business objectives (see Chapter 3 on co-creation and collaboration).

16.5.2 Tailoring roles in controlling a stage

The project manager is responsible for the creation of all new management products in this process but may
delegate tasks to others while retaining responsibility. For example, PRINCE2 shows the project manager as
responsible for creating work package descriptions. However, in practice, they may not have the requisite
skills to define specialist products or method statements in the work package description. Hence, they will
rely on the team manager or other specialists to create the content, and the project manager’s role will be to
ensure that they are defined, reviewed, and assured sufficiently to meet the needs of the stage plan.

16.6 Responsibilities
Table 16.2 summarizes the accountability and responsibility for completing each activity in the process
along with who should be consulted and informed.
16.7 Application of the practices to this process
Table 16.3 summarizes how each practice supports the activities of the process of controlling a stage.
 CHAPTER 17
MANAGING
PRODUCT DELIVERY
17.1 Purpose
The purpose of the process of managing product delivery is to control the link between the project
manager and the team manager. This is achieved by agreeing the requirements for acceptance,
execution, reporting, and delivery of specialist products. The role of the team manager is to coordinate
an area of work that will deliver one or more of the specialist products that form the project product.
Team managers can be internal or external to the organization running the project.

17.2 Objectives
The objectives of the process of managing product delivery are to ensure that:
 Execute a work package
The work must be executed and monitored in accordance with the requirements defined in the
authorized work package.
The team manager can only proceed with the work package or take corrective action when the work
package is forecast to be completed within the tolerances set by the project manager. As soon as work
package tolerances are expected to be exceeded, the team manager should raise an issue with the
project manager. They will then choose a course of action.
In addition, it is extremely important to ensure psychological safety within the team (see Chapter 3).
Related issues and risks will have to be addressed immediately and adequately.
Recommended actions for each team manager:
 Prepare premature closure
In some situations, the project board may have instructed the project manager to close the project
prematurely. In such circumstances, the project manager must ensure that work-in-progress is not
simply abandoned but that the project salvages anything of value created to date and checks that any
gaps left by the cancellation of the project are raised to the business.
Recommended actions for the project manager:
 General considerations
The activities in this process may be combined, separated, or run concurrently to suit the context, but
care should be taken to ensure the integrity of the connections with the processes of directing a project
and controlling a stage.
The product handover activity may not be undertaken in the project’s final stage as part of closing the
project, but it may have happened within several previous stages. Closing the project process would
then only require confirmation that all handovers have been completed.

19.5.2 Tailoring roles in closing a project

The project manager is responsible for the creation of all new management products in this process but
may delegate work to others, provided the overall responsibility is retained. Checking that post-project
benefits reviews are planned to take place may be undertaken by the senior user in the ‘confirm project
acceptance’ activity.

19.6 Responsibilities
Table 19.2 summarizes the accountability and responsibility for completing each activity in the process
along with who should be consulted and informed.
 MANAGEMENT
PRODUCTS
This appendix contains product description outlines for PRINCE2’s defined management products.
These are not full product descriptions as defined in section A10, as some elements, such as quality
method, will vary depending on the project’s needs. Format examples are provided, but these are not
exhaustive.
Management products should be applied and tailored to the requirements and environment of each
project. This could include the composition, format, quality criteria, and naming of the management
products. For example: