The PRINCE2 ® Foundation Course

Prince2 ® Course Notes

By: Kais Abu Al Haija
Table of Contents:
Chapter 1 – Intro to Projects and Prince2..................................................................................................... 6
Lecture 1 – Introducing Projects. .............................................................................................................. 6
Lecture 2 – Why do Projects Fail? ............................................................................................................. 6
Lecture 3 – What is Project Management? .............................................................................................. 7
Lecture 4 – What Needs to be Controlled? .............................................................................................. 7
Lecture 5 – Projects in Context. ................................................................................................................ 8
Lecture 6 – The Structure of Prince2. ....................................................................................................... 8
Lecture 7 – The 7 Principles. ..................................................................................................................... 9
Lecture 8 – The 7 Themes. ........................................................................................................................ 9
Lecture 9 – The Scope of Prince2. ............................................................................................................. 9
Lecture 10 – What Makes a Project a Prince2 Project? .......................................................................... 10
Lecture 11 – Benefits of using Prince2.................................................................................................... 10
Chapter 2 – Principles and Tailoring. .......................................................................................................... 11
Lecture 1 – Principles and Applying Prince2 Introduction: ..................................................................... 11
Lecture 2 – Continued Business Justification.......................................................................................... 11
Lecture 3 – Learn from Experience. ........................................................................................................ 11
Lecture 4 – Defined Roles & Responsibilities.......................................................................................... 12
Lecture 5 – Manage by Stages. ............................................................................................................... 12
Lecture 6 – Manage by Exception. .......................................................................................................... 13
Lecture 7 – Focus on Product.................................................................................................................. 13
Lecture 8 – Tailor to Suit the Project. ..................................................................................................... 14
Lecture 9 – Tailoring vs Embedding. ....................................................................................................... 14
Lecture 10 – What can be Tailored. ........................................................................................................ 15
Lecture 11 – Tailoring Responsibilities. .................................................................................................. 16
Lecture 12 – Project Delivery Approaches. ............................................................................................. 17
Chapter 3 – Process Model. ........................................................................................................................ 18
Lecture 1 – Four Levels of Management. ............................................................................................... 18
Lecture 2 – Process Model-Pre Project Preparation. .............................................................................. 19
Lecture 3 – Process Model-Initiation Stage. ........................................................................................... 21
Lecture 4 – Process Model-First Occurrence of SB. ................................................................................ 23
Lecture 5 – Process Model-Stage Two. ................................................................................................... 24
Lecture 6 – Process Model-Stage Three. ................................................................................................ 26
 Lecture 7 – Process Model-Stage Four. .................................................................................................. 28
Lecture 8 – Process Model Tips. ............................................................................................................. 30
Lecture 9 – The Seven Processes. ........................................................................................................... 31
Chapter 4 – Organization Theme. ............................................................................................................... 32
Lecture 1 – Organization Theme Purpose............................................................................................... 32
Lecture 2 – Introduction to Stakeholders. .............................................................................................. 32
Lecture 3 – Primary Stakeholders Interests. ........................................................................................... 33
Lecture 4 – The Four Levels of Management.......................................................................................... 34
Lecture 5 – Project Management Team Structure. ................................................................................ 35
Lecture 6 – Project Board Roles & Responsibilities. ............................................................................... 36
Lecture 7 – Extended Project Board. ...................................................................................................... 37
Lecture 8 – Project Assurance................................................................................................................. 38
Lecture 9 – Project Manager................................................................................................................... 39
Lecture 10 – Team Manager. .................................................................................................................. 40
Lecture 11 – Project Support. ................................................................................................................. 41
Lecture 12 – Change Authority. .............................................................................................................. 42
Lecture 13 – Tailoring Organization Design. ........................................................................................... 43
Lecture 14 – Project Management Roles in Context. ............................................................................. 45
Lecture 15 – Stakeholder Identification.................................................................................................. 46
Lecture 16 – Organization Theme Minimum Requirements. ................................................................. 47
Lecture 17 – Organization Theme Key Responsibilities. ......................................................................... 49
Chapter 5 – Business Case Theme. ............................................................................................................. 50
Lecture 1 – Business Case Theme Purpose. ............................................................................................ 50
Lecture 2 – Desirable, Viable & Achievable. ........................................................................................... 50
Lecture 3 – Business Case Life Cycle. ...................................................................................................... 51
Lecture 4 – Outputs, Outcomes, Benefits and Dis-Benefits.................................................................... 52
Lecture 5 – Business Case Contents........................................................................................................ 54
Lecture 6 – Benefits Management Approach. ........................................................................................ 56
Lecture 7 – Minimum Requirements for Business Case Theme. ............................................................ 58
Lecture 8 – Business Case Theme Key Responsibilities. ......................................................................... 59
Chapter 6 – SU & IP Processes. ................................................................................................................... 60
Lecture 1 – SU & IP Process. ................................................................................................................... 60
Lecture 2 – SU Purpose and Objectives. ................................................................................................. 61
 Lecture 3 – Appoint Executive & Project Manager. ................................................................................ 63
Lecture 4 – Capture Previous Lessons. ................................................................................................... 64
Lecture 5 – Design and Appoint the Project Management Team........................................................... 65
Lecture 6 – Prepare Outline Business Case............................................................................................. 66
Lecture 7 – Approach & Project Brief. .................................................................................................... 67
Lecture 8 – Plan the Initiation Stage. ...................................................................................................... 68
Lecture 9 – IP Purpose and Objectives. .................................................................................................. 69
Lecture 10 – Agree the Tailoring Requirements. .................................................................................... 71
Lecture 11 – Project Management Approaches. .................................................................................... 72
Lecture 12 – Project Controls and Plan................................................................................................... 74
Lecture 13 – Refine the Business Case.................................................................................................... 75
Lecture 14 – Assemble the PID. .............................................................................................................. 77
Lecture 15 – SU & IP Process Review. ..................................................................................................... 78
Chapter 7 – Progress Theme. ...................................................................................................................... 79
Lecture 1 – Progress Theme Purpose. ................................................................................................... 79
Lecture 2 – Why Have Controls? ............................................................................................................ 80
Lecture 3 – Limits of Authority............................................................................................................... 81
Lecture 4 – Elements of Tolerance......................................................................................................... 82
Lecture 5 – Levels of Tolerance.............................................................................................................. 84
Lecture 6 – Project Board Controls. ....................................................................................................... 85
Lecture 7 – Project Manager Controls. .................................................................................................. 86
Lecture 8 – Minimum Requirements for Progress Theme. .................................................................... 87
Lecture 9 – Progress Theme Key Responsibilities. ................................................................................. 88
Chapter 8 – Plans Theme. ........................................................................................................................... 89
Lecture 1 – Plans Theme Purpose. ......................................................................................................... 89
Lecture 2 – Three Levels of Plan. ........................................................................................................... 90
Lecture 3 – Project Plans. ....................................................................................................................... 91
Lecture 4 – Stage Plans. ......................................................................................................................... 92
Lecture 5 – Team Plans. ......................................................................................................................... 93
Lecture 6 – Exception Plans. .................................................................................................................. 94
Lecture 7 – Where Do We Plan? ............................................................................................................ 95
Lecture 8 – Management Stages............................................................................................................ 96
Lecture 9 – Aligning Stages and Delivery. .............................................................................................. 98
 Lecture 10 – Management Stages Summary. ...................................................................................... 100
Lecture 11 – Introducing Product Based Planning. .............................................................................. 101
Lecture 12 – Product Descriptions. ...................................................................................................... 102
Lecture 13 – Product Breakdown Structure......................................................................................... 104
Lecture 14 – Product Flow Diagram. .................................................................................................... 106
Lecture 15 – Benefits of Product Based Planning. ............................................................................... 108
Lecture 16 – Structured Approach to Plans. ........................................................................................ 109
Lecture 17 – Plans Theme Minimum Requirements............................................................................ 112
Lecture 18 – Plans Theme Key Responsibilities and Summary. ........................................................... 113
Chapter 9 – Risk Theme. ........................................................................................................................... 114
Lecture 1 – Risk Theme Purpose. ......................................................................................................... 114
Lecture 2 – Threats & Opportunities. .................................................................................................. 115
Lecture 3 – Introducing the Risk Management Procedure. ................................................................. 116
Lecture 4 – Identify Step. ..................................................................................................................... 117
Lecture 5 – Assess Step. ....................................................................................................................... 119
Lecture 6 – Plan Step............................................................................................................................ 121
Lecture 7 – Risk Planning Considerations. ........................................................................................... 123
Lecture 8 – Implement Step. ................................................................................................................ 124
Lecture 9 – Communicate Step. ........................................................................................................... 126
Lecture 10 – Risk Theme Minimum Requirements. ............................................................................. 127
Lecture 11 – Risk Theme Responsibilities and Summary. .................................................................... 128
Chapter 10 – Change Theme..................................................................................................................... 129
Lecture 1 – Change Theme Purpose. ................................................................................................... 129
Lecture 2 – Types of Issue. ................................................................................................................... 131
Lecture 3 – Technique, Issue and Change Control Procedure. ............................................................ 132
Lecture 4 – Issue & Change Control Documentation. .......................................................................... 134
Lecture 5 – Configuration Management. ............................................................................................. 136
Lecture 6 – Change Theme Minimum Requirements. ......................................................................... 137
Lecture 7 – Change Theme Responsibilities......................................................................................... 138
Chapter 11 – CS & MP Processes. ............................................................................................................. 139
Lecture 1 – Purpose of CS & MP. ......................................................................................................... 139
Lecture 2 – Controlling a Stage Normal Process. ................................................................................. 140
Lecture 3 – Controlling a Stage Handling Problems. ............................................................................ 142
 Lecture 4 – Managing Product Delivery. .............................................................................................. 144
Lecture 5 – CS & MP Summary. ........................................................................................................... 145
Chapter 12 – Quality Theme. .................................................................................................................... 146
Lecture 1 – Purpose of Quality Theme................................................................................................. 146
Lecture 2 – Quality Management Systems. ......................................................................................... 147
Lecture 3 – The Quality Assurance Role............................................................................................... 148
Lecture 4 – Quality Planning and Quality Control................................................................................ 149
Lecture 5 – Quality Audit Trail. ............................................................................................................ 151
Lecture 6 – Quality Theme Minimum Requirements........................................................................... 153
Lecture 7 – Quality Theme Responsibilities. ........................................................................................ 154
Chapter 13 – DP, SB & CP Processes. ........................................................................................................ 155
Lecture 1 – Introducing SB, DP & CP Processes. .................................................................................. 155
Lecture 2 – SB Purpose & Activities. .................................................................................................... 156
Lecture 3 – SB End of Stage.................................................................................................................. 158
Lecture 4 – SB Exception Handling. ...................................................................................................... 160
Lecture 5 – DP Purpose and Overview. ................................................................................................ 161
Lecture 6 – DP Activities....................................................................................................................... 162
Lecture 7 – CP Purpose. ....................................................................................................................... 164
Lecture 8 – CP Normal Closure Activities. ............................................................................................ 166
Lecture 9 – CP Premature Closure Activities........................................................................................ 168
Lecture 10 – CP Premature Closure Activities...................................................................................... 169
 Chapter 1 – Intro to Projects and Prince2.

Lecture 1 – Introducing Projects.

BAU = Business as Usual

A project is a temporary organization that is created for the purpose of delivering one or more
business products according to an agreed business case.

Project environments and organizations are not static environments.

A key challenge is maintaining a balance between: Current business operations and Transform of
business operations.

Lecture 2 – Why do Projects Fail?

 Lack of senior management commitment.

 Lack of sound business reasons.
 Lack of well-defined roles and responsibilities.
 Lack of change control leading to “scope creep”.
 Lack of effective communication.
Lecture 3 – What is Project Management?

One aim of prince 2 is to make the right information available at the right time for the right people
to make the right decisions about the project.

Plan

Control Delegate

Monitor

Lecture 4 – What Needs to be Controlled?

Time
scale

Risk Benefit

The
project

Cost Quality

Scope

The aim is to figure which aspect is more important depending on the type of project.
Lecture 5 – Projects in Context.

An organization can have quite several projects and initiatives at any one time. Some projects
may be standalone projects “independent” from any other. These projects will report into
corporate management.

Sometimes projects and their resulting benefits are related. These projects may be run as part of
a larger piece of work called programme.

Definition Program: A temporary flexible organization structure created to coordinate, direct and
oversee the implementation of a set of related projects and activities in order to deliver outcome
and benefits related to the organization’s strategic objectives. A programme is likely to have a
life that spans several years.

Definition Portfolio: The totality of an organization’s investment (or segment thereof) in the
changes required to achieve its strategic objectives.

Lecture 6 – The Structure of Prince2.

Prince  PRojects IN Controlled Environments.

4 integrated Elements:

 Principles
 Themes
 Processes
 Environment

 The 7 principles form the bedrock of prince2, they are universal, so to claim that a project
is being run efficiently, all principles must be applied and described as the guiding
obligations.
 The 7 themes provide detailed guidance on different aspects of managing a project, they
describe what is required, why and how.
 The 7 processes provide step-by-step instructions and checklist that will guide you
through the project life cycle.
 Too little information will leave your project vulnerable and increase the risk of failure,
whereas a heavy-handed approach can over-burden a project with too much bureaucracy
and management overhead.
Lecture 7 – The 7 Principles.

 Continued business Justification.

 Learn from Experience.
 Defined Roles & Responsibilities.
 Manage by Stages.
 Manage by Exception (saves senior management time).
 Focus of Products.
 Tailor to Environment.

Lecture 8 – The 7 Themes.

 Business case  Why we are doing the project.

 Organizational  Who is required.
 Quality  What it must deliver.
 Plans  Steps required, how, how much and when.
 Risk  What if.
 Change  Analyze impact.
 Progress  Where are we now, should we carry on.

Lecture 9 – The Scope of Prince2.

What Prince2 doesn’t cover?

Specialist Aspects:

 A major strength of the method is that it can be used in any industry.

Detailed Technique:

 Except for Product Based Planning and Quality Review Techniques.

Leadership Capability:

 Soft skills are an important aspect of being a successful project manager, but no part of
Prince2.
Lecture 10 – What Makes a Project a Prince2 Project?

It must be possible to demonstrate that the project:

 Is applying the 7 Prince2 principles.

 It meets the minimum requirements of the 7 Prince2 themes.
 It has processes that satisfy the purpose and objectives of the 7 Prince2 processes.
 It either uses the recommended techniques or implements similar alternatives.

Lecture 11 – Benefits of using Prince2.

Benefits:

 Recognized best practice – established and proven.

 Improved communication.
 Can be used on any type or size of project.
 Defined structure for accountability, delegation, authority and communication.
 Ensures focus on viability of the project.
 Promotes learning and continual improvement.
 No license fee.
 Chapter 2 – Principles and Tailoring.

Lecture 1 – Principles and Applying Prince2 Introduction:

Applying Prince2:

 Tailoring / Adopting / Embedding.

 Project delivery approaches.
 Measures of success.

Lecture 2 – Continued Business Justification.

Key message: A Prince2 project has continued business justification.

Prince2 required for all projects that:

 There is a justifiable reason for starting the project.

 That justification is recorded and approved.
 The justification remains valid and is re-validated throughout the life of the project.

The idea of business justification is to drive decision making to ensure that the project will still
achieve the desired benefits.

For a compulsory project, such as one driven by legislation, the business case will focus on
demonstrating which option provides the best value for money.

Lecture 3 – Learn from Experience.

Key message: Prince2 project teams learn from experience, lessons are looked for, recorded and
acted upon throughout the life of the project.

Throughout the project means:

 When starting a project – previous projects reviewed / learn from others.

 As the project progresses – continue to learn & lessons recorded.
 As the project closes – pass on lessons.
Lecture 4 – Defined Roles & Responsibilities.

Key message: A Prince2 project has defined and agreed roles and responsibilities within an
organization structure that engages the business, user and supplier stakeholder interest.

All projects have the following Primary Stakeholders:

 Business sponsors – who endorse the objective and ensure that the business investment
provides value for money.
 Users – who, after the project is completed, will use the products to enable the
organization to gain the expected benefits.
 Suppliers – who provide the resources and expertise required by the project (internal or
external).

Lecture 5 – Manage by Stages.

Key message: A Prince2 project is planned, monitored and controlled on a stage-by-stage basis.

The choice of appropriate management stages will depend on several factors including:

 The size and complexity of a project – shorter stages offer more control; longer stages
reduce burden on senior management.
 Significant decisions / control points – often linked key investment, business or technical
decisions.
 Organizational policies or standards.

A Prince2 project must have at least 2 stages – initial & at least one other.

Planning Horizon  How far ahead can a project be planned in detail?

Creating a detailed plan takes time and planning in too much far ahead is likely to be wasted
time.

Key message: Stages enable the project board to delegate the authority for day-to-day control of
a management stage, within agreed tolerance, to the project manager.
Lecture 6 – Manage by Exception.

Key message: A Prince2 project has defined tolerances for each project objective to establish
limits of delegated authority.

Within Prince2 accountability is established by:

 Delegating authority from one level to the next – by setting tolerances against the six
aspects: cost, timescale, quality, scope, risk and benefits.
 Setting up controls – which provides for immediate escalation for a decision if tolerances
are forecast to be exceeded.
 Having an assurance mechanism – so each management layer can be confident that
controls are effective.

The management by exception principle does make for very efficient use of senior management
time because they will not need to be bothered with every little thing. It ensure decisions are
made at the appropriate level of management without loss of control.

Lecture 7 – Focus on Product.

Key message: A Prince2 project focuses on delivery of products. This includes on what they should
be, including the important quality requirements to ensure benefits can be achieved.

Projects that focus on WHAT the project needs to achieve are more successful than those
focusing on activities, because:

 It ensures projects only carries out work that directly contributes to the delivery of a
product.
 It helps manage uncontrolled change (scope creep).
 It reduces user dissatisfaction and acceptance disputes.

Definition Product: An input or output, whether tangible or intangible, that can be described in
advance, created, and tested.

Prince2 has two types of products:

1. Management products such as project plans and

2. Specialist products such as deliverables.

The Prince2 guidance uses the terms “output” and “deliverable” synonymously with the term
product.
Lecture 8 – Tailor to Suit the Project.

Key message: Prince2 is tailored to suit the project environment, size, complexity, importance,
team capability and risk.

Blindly following the method would give rise to mechanistic, and probably bureaucratic, project
management, whereas not using a method relies on management heroics. Neither is good.

Prince2 must be tailored to ensure:

 It is used appropriately – for the project.

 Controls are appropriate – neither bureaucratic nor too risky.

The project board and project manager need to make pro-active choices about prince2
applications (detailed in PID).

Lecture 9 – Tailoring vs Embedding.

Definition Tailoring: Adapting a method or process to suit the situation in which it will be used.

What does Tailoring Prince2 entails to:

 Adapting the roles for a project.

 Adapting project strategies (defined in approach documents).
 Incorporating specific terms/languages.
 Adjusting the process to meet specific situations.

Definition Embedding: The act of making something an integral part of a bigger whole. Its what
an organization needs to do to adopt Prince2 as its corporate project management method and
encourage its widespread use.

What does Embedding Prince2 entails to:

 Setting up standards (template designs).

 Process responsibilities.
 Scaling rules/guidance (scorecard).
 Training and development.
 Integration with business processes.
Lecture 10 – What can be Tailored.

Key message: Tailoring can be applied to processes, themes, roles, product descriptions and
terminology.

Good tailoring entails a certain amount of skill, experience and judgement to be successful.

Some high-level pointers of Tailoring:

 Processes – could be adapted or even combined.

 Themes – must all apply, it can be tailored using various techniques such as industry and
technology.
 Roles – are fully defined in the organizational theme, standard roles can be adapted
providing accountability is maintained. It can be combined or split.
 Management Products – These can be combined or even split. They can be represented
in different formats and style.
 Terminology – can be changed however, changes should be consistently applied to avoid
confusion.
 Techniques.

Key message: Tailoring as a Prince2 project is mandatory (as are all principles), so if the
organization does not consider tailoring, it is not using Prince2.

Prince2’s principles should not be tailored as they are universal and always apply.

Caution: Tailoring is a method that does add value and does not diminish the effectiveness of
Prince2.
Lecture 11 – Tailoring Responsibilities.

How Prince2 is going to be used on a given project is documented in something called the PID, or
Product Initiation Documentation. It is the project managers responsibility to create the PID,
which is the approved by the project board.

The project manager must therefore identify the level of tailoring required when creating the
PID. There will be several influences on this such as:

Summarized Key message: The manual provides tailoring guidance, but it can be exhaustive.

Prince2 practitioners should ensure their tailoring choices:

 Comply with the 7 principles & corporate standards.

 Do not un-duly increase risk.
 The rational is explained in the PID.
Lecture 12 – Project Delivery Approaches.

Firstly, we have the Waterfall Approach, which entails completing different delivery steps is a
sequel.

Then we have the Agile Approach, this shows the steps in SCRUM, which is a common agile
approach. The focus in on delivering the project within iterative timeboxed periods called sprints.
Sprints are quite short, between 1 and 4 weeks, and different type of delivery work will be carried
out in each sprint, a bit like a series of mini waterfalls.

Key message: Prince2 regards agile as a family of behaviors, concepts, frameworks and
techniques.

Guidance: What does Fail Fast mean?

Using timeboxes / sprint in agile delivery enables fast detection of possible failure of products.
This fail fast effect reduces waste of resources and can be a useful learning experience.
 Chapter 3 – Process Model.

Lecture 1 – Four Levels of Management.

The level at the top shown in green is the level to which the project reports. This level is
responsible for commissioning the project. If the project is a stand-alone internal project it will
be corporate management, and if the project is part of a larger piece of work, this will be
programme management. This level is outside of the project management team. They identify
the project executive and set high level strategies.

Next, we have the project board shown in black who are accountable for the project. This is the
directing level. The board make the major decisions on the project, such as authorizing project
start and each stage. They provide resources such as budgets and staff.

The project manager shown in blue, is called the managing level. They have day to day
responsibilities for managing the project within any constraints set by the project board on use
of the resources, including cost & time. There should only be one project manager on a project.

The fourth level shown in red is delivering. This team management level is concerned with getting
the specialist products made to the appropriate quality.
Lecture 2 – Process Model-Pre Project Preparation.

Projects are triggered by an idea or a need to do something. This may be new business objectives,
or even new legislation. This trigger is called Project Mandate also known as ‘Terms of Reference’
(T.O.R). They come in forms such as informal and verbal to formal written documents. If the
Project is part of a programme the mandate will be provided by programme management,
otherwise it will be provided by corporate management.

It should contain basic information such as:

 What the project is about.

 Why is it needed.
 Provide enough information to appoint a suitable project executive.

The project mandate triggers the first process called Starting Up A Project (SU). Much of the
information collated in the SU will go into a document called ‘Project Brief’.

The first thing is the Commissioning Organization (Corporate/Programme management) need to

appoint the main decision maker on the project. In Prince2 this would be the Executive for the
project. Then they appoint the Project Manager who will plan and run the project. Role
descriptions for both go into the Project Brief.
Once the project manager is on board a Daily Log is set, which is a place for the project manager
to keep the information together. Before the project manager does anything else, they should
think about what experiences and lessons they can bring to the project and set up a Lesson Log
to record them.

Next the project manager considers if any more people are required and creates any additional
role descriptions required and a project team management structure chart added to the brief. It
is important to understand why the project is required so the executives expand on the
information in the mandate and this is collated into a Project Business Case.

At the same time the project manager needs to understand what needs to be delivered so a
document called a Project Product Description is written. It describes the deliverables as a ‘thing’
and contains important quality information such as the Customers Quality Expectations (CQE’s).

Agreement is required on the how the project will be delivered before plans can be created such
as can it be done ‘in house’, is it something that can be bought or are external suppliers required,
this is defined as the Project Approach.

Finally, in SU the project manager creates a detailed plan for just the first stage of the project,
which is called the Initiation Stage. It will be essentially about creating a PID, which can take a
lot of time depending on the complexity of the project.

The project brief should not be a huge document, or take too long to pull together, but it must
give the project board enough information to make their decisions and form the basis for creating
a project plan. At the end of SU the project manager requests to move into the Initiation Stage
of the project by presenting the project brief and the initiation stage plan to the project board
triggering the DP process. (DP  Directing a Project).
Lecture 3 – Process Model-Initiation Stage.

The Directing a Project Process (DP) covers the projects board’s work and is where the major
decisions on the project are made. The DP process starts at the end of the SU process and then
runs throughout the whole project.

The diamond shape is used to signify that a decision is being made. This one is about to whether
to formally start the project. In order to know where you are in the process flow, Prince2 gives
the decisions names. This one is called ‘Authorize Initiation’ because if the project board does
decide to go ahead it will trigger the project manager to start the Initiating A Project process in
the Initiation Stage and this marks the official start of the project.

The Initiation a Project process (IP) is about putting in place solid foundations for the project by
understanding the work that needs o be done and creating the Project Initiation Documentation
(PID). It incorporates information from the project brief, adds he project plan and states how the
project will be managed. It acts as a contract between the manager and the board and considered
as a manual for the project. Prince2 presents a logical order for creating a PID.
Firstly, consider requirements for Tailoring use of the Prince2 methods, based on understanding
of existing standards and procedures. The tailoring requirements are then an input to writing the
Four Management Approaches, which state how certain aspects will be managed. They cover
things like procedures, tools, techniques and responsibilities for each of the four areas, which are
Risk, Quality, Change and Communication.

The project will need Three Project Registers for Risk, Quality and Issues. The registers are lists
so, for example, when a new risk is identified it will go in the Risk Register, not the Risk
Management Approach.

Next is a small section on Project Controls, which details things like frequency of reporting, where
stage boundaries will be and limits of authority (or tolerances).

Then we take the Outline Business Case in the project brief and refine it into a Detailed Business
Case by adding the costing and timescales from the project plan. The business case will list all the
expected benefits of the project. Therefore, a Benefits Management Approach is created to be
able to track if the benefits have been realized before progressing to the next stage. This
approach is different from the others and doesn’t go in the PID because those in charge of
measuring benefits will not need to know how the project is being run.

Towards the end of the IP process the project manager needs to use the Managing a Stage
Boundary process to create a more detailed stage plan for the next stage, and the project
manager will present the PID to the project board and request to deliver a project.
Lecture 4 – Process Model-First Occurrence of SB.

The Managing A Stage Boundary process (SB) will be used towards the end of every project
stage, except the last one, and is also triggered in exception circumstances. This process prepares
information for the project board whether continued investment can be justified.

The fist thing is to create a detailed stage plan for the forthcoming stage. As the project
progresses, creating the stage plan is a key time to look out for potential changes to the project
management team. A stage plan will cover the activities to build the required products and the
activities to check the quality of them, management activities and project administration.

When the stage plan is done implications need to be considered on the whole project. For
example, it may reveal that the next stage will take longer than was originally estimated, in which
case the project plan within the PID would need amending to reflect this and maintain a complete
and accurate picture for the whole project. The project manager will need to reconsider the
business case in the light of the stage plan and potentially update other sections of the PID.

The benefits management approach might also need to be updated if benefit reviews are
required during the next stage that have not been put in the management approach. Finally, the
project manager creates an End Stage Report to reflect how the stage that is finished wen and
pas on any lessons that have been learnt during this stage.
Lecture 5 – Process Model-Stage Two.

There are two decisions being made here.

The main decision is authorizing the PID which was created in the IP process. Even though the
official start of the project was before the IP process even began, his decision is called ‘Authorize
A Project’ because it is authorizing the project plan and the PID. At this time the project board
would also review and authorize the benefits management approach. When the project board
do ‘Authorize a Project’ this first version, version 1 of the PID is kept and known as a ‘base-line’
against which progress can be reviewed.

The other decision being made is on the stage plan which is an output from the SB process. This
second decision is called ‘Authorize A Stage Plan’. The project manager can’t progress to stage 2
until the project board are happy with both the PID and the stage plan for stage 2.

The Controlling A Stage process (CS) covers day to day project manager’s work. This entails
allocating work, monitoring, reporting and handling problems. The mechanism for allocating
work to the team is called ‘Work Package’ which is simply a set of instructions about what must
be done. Work packages are then given to team manager’s whose work is covered by the
Managing Product Delivery (MP) process. If the project does not require team managers, the
project manager gives the work packages directly to the project team members. To monitor the
work in progress, the project manager requires information. The team manager provides this via
regular Checkpoint Reports. The project manager would have described the required contents
and frequency of the checkpoint reports in the work package instructions.
In turn the project manager needs to report progress regularly to the project board while the
stage is in progress. To distinguish this from team manager’s reports, they are called Highlight
Reports. The frequency of these are agreed by the project board and is documented in the PID.
Towards the end of the stage the project manager will need to use the managing a stage
boundary process to prepare information for the project board’s decision.

As before, the first thing the project manager does is create the next stage plane ( in this case for
stage 3). The project manager will now need to update the project plan with two things.

Firstly, with data on the actual progress made during stage 2 that is finishing, and with any revised
forecasts in the light of the next stage plan. Then review the business case to make sure the
project is still viable and worthwhile and consider if any other PID updates are required. Then
update the benefits management approach if necessary. Finally, the project manager creates an
End Stage Report and submits everything to the project board.
Lecture 6 – Process Model-Stage Three.

The project board perform an end stage assessment by reviewing the next stage plan, any
updates to the PUD and benefits review apporach, and at the end stage report. Again, this
decision is called ‘Authorizing A Stage Plan’ and will trigger the project manager into then
Controlling A Stage for stage 3. The stage starts as normal with the project manager authorizing
work packages that trigger managing product delivery.

Prince2 calls problems that arise issues. An issue can come from anywhere, not just the project
team. They could be raised from the project board, the commissioning body (corporate,
programme management or customer) or even from outside the organization. Wherever, the
issue comes from, the project manager will document and analyze it. If it is something that can
be handled quickly and informally, it may just be noted in the daily log. However, if it is something
that needs to be handled formally it goes in the issue register and an issue report is started.

If the project manager has enough authority, they will take corrective action. Having authority
could be because the issue means that the stage remains within authorized tolerance, or even it
could be that the project manager has been appointed as the Change Authority. If the project
manager does not have enough authority, they will need to escalate it to the project board suing
an exception report if tolerances are threatened.

If the problem is large the board might have to further escalate to the commissioning body. The
board do have authority to close the project prematurely and the project manager simply would
us the Closing a Project process early.
Should the project board want to continue the project they would ask the project manager to
produce an Exception Plan, which is done in the SB process. The first thing to do is to create an
exception plan based on the project board’s decision, drawing on the existing stage plan and
exception report. The project plan will need updating to reflect new targets, and it is even more
important that the business case impact is considered by the project manager. When done the
exception plan and the updated PID are presented back to the project board.

The project board’s decision here is called ‘Authorize an Exception Plan’. This will trigger the
project manager into controlling a stage to continue authorizing work packages. Once an
exception plan is authorized, it becomes a new version of the stage plan and possibly a new
version of the project plan if the whole project was in exception.

The project manager continues with controlling a stage process until either another problem
occurs, or the work of the stage is complete. When the work of the stage is nearly done the
project manager will need to use managing a stage boundary process again, but this time to
create a stage plan for stage four, which will be submitted to the project board for approval. The
final stage plan will include the activities required within the closing a project process.
Lecture 7 – Process Model-Stage Four.

The project continues into the fourth stage with the project manager authorizing work packages,
reporting progress and problem handling. However, when the end of the final stage approaches
there are no further stages, so the SB process is not used, instead the Closing A Project is used.
The receiving and checking the quality of the products built in the final stage will be handled with
the managing product delivery, not the closing a project process.
There are two ways that the closing a project can be triggered. The usual is that the project
reaches its planned end. The first thing to do is update the project plan with the actual progress
data regarding time taken are resources used.

Then the project manager needs to ensure that all products have been handed over to the
customer and the Final Customer Acceptance is obtained against the acceptance criteria
documented in the project product description. It is the executives who formally accepts the
product because they funded the project. All post-project benefit reviews are detailed in the
benefits review approach and ready for handover. If there are any other outstanding customer
needs, the project manager collates them into ‘Follow on Actions Recommendations’.

Now the project manager can evaluate how the project has gone. Looking back to the first
approved PID (version 1) will refresh the project manager of the original project objectives so
that they can explain any changes that occurred along the way. The project manager creates an
End Project Report which looks at how the project has performed against its targets. This is also
to pass on lessons associated with the project in the lessons section. Afterwards, a draft of closure
notification is sent to the project board.

It is the project board who formally authorize the closure notification. At the end of the project
the project board need to make sure that both lessons and benefit review approach are passed
on to the corporate organization for appropriate action, such as conducting the review and
potentially amending corporate procedures and quality standards in the light of lessons learned.
Lecture 8 – Process Model Tips.

Creating a PID in the initiation stage can take some time and the project manager might want
some help with it. This means that the project manager is allocating work packages to get things
done. So, optionally, when managing a long initiation stage for a complex project, the controlling
a stage and managing product delivery processes can be used.

The second point is that process and stages are not the same thing. A management stage equates
to a chunk of time and the project board authorizing use of the resources to progress to the next
stage. Each management stage on a project has several processes that are used. For example,
the work of the initiation stage is more that just initiating a project process, it will always also use
managing a stage boundary and directing a project too. Another example is when a project needs
to be closed. There is no need to add a stage just for closing a project process. It will be part of
whatever is the last stage. In the diagram it is part of stage four, but if the project is to close early,
say as a result of the exception shown in stage three of the diagram, we would simply us the
closing a project process in stage three.
Lecture 9 – The Seven Processes.

Here are the 7 processes, most of them are the project manager’s responsibility shown in blue.

To summarize them:

 SU: Is the pre-project work. It is a bit like a sanity check getting basics in place before the
project formally starts.
 DP: Covers the project board’s work and is where key decisions on the project are made.
 IP: Establishes solid foundations for the project and enables the organization to
understand what work needs to be done through creation of the project plan that goes
in the PID.
 CS: Is day-to-day project manager’s work once the project is up and running.
 MP: Coves team managers work.
 SB: Is the project manager preparing information for a board decision on whether to
progress to the next stage.
 CP: Is bringing the project to a tidy close and getting acceptance for delivered products.
 Chapter 4 – Organization Theme.

Lecture 1 – Organization Theme Purpose.

Key message: The purpose of the organization theme is to define and establish the project’s
structure of accountability and responsibility (the who?). Identifying and analyzing stakeholders.

The Prince2 organization theme provides standard project organization structure that can easily
be tailored to suit any project. In Prince2 the focus is on roles rather than jobs because roles
provide flexibility. Roles are not necessarily full time and they can be combined. One person can
take on more than one role as long as there is clarity about who is doing which role and what the
responsibilities of the different roles are.

Lecture 2 – Introduction to Stakeholders.

Lecture 3 – Primary Stakeholders Interests.

Firstly, the Business perspective ensures that the investment in the project will meet a genuine
business need and provide value for money. It is represented by whoever secures funding for the
project. They will therefore be cost conscious, seeking value for money.

The User viewpoint represents those who will use or maintain the project outputs to realize the
benefits. This group will be interested in things like functionality and will therefore provide the
project requirements, including the quality criteria, for the project.

Finally, the third primary interest group is the Suppliers. Those who provide the specialist or
technical skills needed to create whatever it is that the project is delivering. Often the customer
organization does not have the necessary specialist skills to develop the project outputs, so
supplies are frequently from a different organization. If they are external suppliers, they will be
seeking to return a profit.
Lecture 4 – The Four Levels of Management.

At the top is the Commissioning Organization, the level to which the project reports. “Stand-
alone” internal projects report to Corporate Management, projects that are part of a larger piece
of work, called a programme, will report to Programme Management. If it is a commercial
situation this level may be known as The Customer.

Next, we have the Project Board. This is the directing level. The board make the major decisions
on the project and provide resources, such as budgets and staff. They therefore need to be senior
people and a smallish group is the best for decision making.

The Project Manager is the managing level. Project manager have day to day responsibilities for
managing he project and regardless of the project size there should only ever be one project
manager on project to ensure there is accountability.

The fourth level, delivery, is Team Managers who are responsible for getting the specialist
products made.

When one level of management on a project needs to escalate a problem, they should always
escalate to the next level of management above in this structure. Not doing so would undermine
the level above.
Lecture 5 – Project Management Team Structure.

The diagram shows the standard Prince2 organization structure for a project management team.
The color coding depicts how the roles relate to the levels of management. The Prince2
organization structure is built around roles and not individuals to provide flexibility. So, each role
shown here does not relate to one person.

Prince2 mandates that the roles shown here are fulfilled on every project, although there are a
few basic rules about how these roles can be combined within certain limits.
Lecture 6 – Project Board Roles & Responsibilities.

Suppliers can be internal, i.e. part of the same company or external. Sometimes not all external
suppliers are identified at the project start, and some organizations do not like having external
suppliers on their project board. In these situations, it is common to appoint a purchasing or a
contracts manager to this role.
Lecture 7 – Extended Project Board.

The project board effectively ‘owns’ the project and should try to provide unified direction for
the project manager and the project team if there are too many people involved getting
agreement is likely to be a challenge. Whilst Prince2 doesn’t specify a maximum number of
people on the board a good maximum number of people on the board a good maximum number
is around 7 or 8. If this presents a problem for your project, because there are a lot of different
people or groups that need to be represented there is a solution.

You can set up user and supplier groups and nominate one or two from these groups to represent
their interests on the board. User groups could include a wide range of stakeholders such as HR
and even members of the local community. Similarly, when many suppliers are required on the
project you could consider appointing one as a lead supplier to manage all the others or have
supplier groups.

If the board can’t agree on something the Executive, as the person funding the project, is the
ultimate decision maker. Therefore, there can only ever be one executive on a project.
Lecture 8 – Project Assurance.

As the project board are accountable for the project, they will want to assure themselves that
the project is being run properly. Each board member will want assurance on different aspects
of the project. Because project board members are usually senior, and therefore busy people,
they don’t always have time to check up on everything personally. If a board member chooses,
they can delegate this checking up to someone else, to several people, or even one task at a time.
This is the role of Project Assurance.
Lecture 9 – Project Manager.

Whilst the project manager is not a member of the project board, they attend project board
meetings to provide input and take direction from the board.

The project manager is likely to have additional responsibilities, not covered by Prince2, such as
line management, which will have to be planned for. The project manager is usually selected from
the customer organization because that gives the customer more control.
Lecture 10 – Team Manager.

Team managers oversee the work of specialist teams. The role is said to be ‘optional’ in that it is
not necessary to have separate people fulfilling the role, but someone needs to do .It is a role
that the project manager can preform if they have the right knowledge, skills and time to do so.
Lecture 11 – Project Support.

Project Support essentially provides administrative support to the project registers and files. It is
the responsibility of the project manager, and not optional as a role, but can optionally be
delegated by the project manager. If there is no one else available, then the project manager
must take the responsibility themselves.

Sometimes a central project support office can provide extended services such as being a ‘center
of excellence’ when they would provide advice and guidance on things like project management
methods and even planning tools.

One specific and essential responsibility of project support is that of configuration management.
It’s a term that may be unfamiliar to so some and is covered fully in the change theme.

It entails keeping the products of the project safe and secure and keeping track of different
versions when products change. If the project is creating many complex products that must
interact with each other this can be quite a job, and specialist software is commonly used to help.
Lecture 12 – Change Authority.

When the project is underway decisions will be required on potential change to scope, detailed
project requirements, or if products fall short of their requirements. This is the Change Authority
Role. As we know, the project board make the major decisions on the project so by default, they
are the change authority. The project board can therefore choose to delegate this decision
making. However, unlike project assurance this role can be delegated to whoever is most
suitable, including the project manager.

Details regarding who the change authority is and how a change budget might be used is
documented in something called the change control approach. This document is created during
initiating a project process and will be covered in the change theme section.
Lecture 13 – Tailoring Organization Design.

Prince2 mandates that all the roles displayed here are fulfilled on every project. The organization
structure may look like many people are required to manage a single project. But remember
these are roles, not people or even necessarily full-time roles. The Prince2 organization structure
is very tailorable, and one person could take more than one role.
It is quite common to see one person taking on both the Executive and Senior User roles, but not
common to combine Senior User and Senior Supplier because of potential conflict of interests.

The two board members could do their own assurance, so no extra people required here.
Because it is a small project, and if the project manager has the right technical knowledge, there
is no need for Separate Team Managers, the project manager then interfaces directly with the
project team members. The project manager does their own admin, assuming the project
support role. Finally, the change authority role is delegated to the project manager which leaves
us with a 3 person project management team.

When designing a project organization you need to ensure that the main stakeholders are
properly represented, make sure you have people with the right skills, experience and credibility
and time to fulfil their roles and if your project is part of a programme you may also have to take
into account the needs of the programme.
Lecture 14 – Project Management Roles in Context.

The diagram shows the key Prince2 roles in the context of different organizations that may be
involved in a project. This example will show a project that requires three different suppliers, one
internal to the customer organization and the two are external suppliers. When considering how
to represent the suppliers at board level it could be that one supplier does not need to be
represented by a senior supplier on the board, perhaps because they are only making a small
contribution to the project, but there will be senior suppliers for the other two.

The project manager will not give work instructions to the project board members, so this is
where the managers are required, especially for the external suppliers. In some circumstances
an external supplier may regard the work they are doing for a customer as a project in its own
right and the person running it could even have the job title of project manager, so we could say
they are wearing a blue ‘Project Manager Hat’. However, when looking at the whole project they
are in fact taking a team manager role. On small projects if the project manager has the right
technical expertise, there may be no need for separate individuals to be team managers. In this
type of scenario, the project manager assumes the role, effectively wearing a ‘Red Hat’ and they
would personally instruct individual team members.
Lecture 15 – Stakeholder Identification.

We have looked in detail making sure that the primary stakeholders are represented on the
project management team, but what about the other stakeholders?

We need to identify all our project stakeholders and decide how we are going to communicate
with them, bearing in mind that communication is two-way. All our stakeholders (including
project team members and external stakeholders) will be documented in the project’s
communication management strategy with their communication needs.

One technique to conduct stakeholder’s analysis is to use a grid something like this. You can put
the names of stakeholders on post-it notes and plot them on the appropriate place on the grid
according to their level of interest and influence on the project, remembering that stakeholders
may be individuals or groups. You can then use this to help drive how you are going to
communicate with the stakeholders.
Lecture 16 – Organization Theme Minimum Requirements.

Prince2 defines minimum requirements to be able to claim that a project is indeed following the
method. The organization theme is the Prince2 theme most affected by project size and
complexity but for a project to claim it is following Prince2 it must:

 Define its organization structure and roles

 Ensuring that all of the responsibilities in Prince2’s role description are fulfilled.
 Document the rules for delegating change authority responsibilities.
 Define its approach to communicating / engaging with stakeholders.

Prince2 therefore requires that two management products are created:

The PID, which provides a single course of reference regarding how the project is to be managed
as it includes the management structure and individual roles.

Within the PID there should be a communication management approach that describes the
means and frequency of communication to all stakeholders, whether they are internal or external
to the organization.
Let’s just have a look at Prince2’s rules for combining roles:
Lecture 17 – Organization Theme Key Responsibilities.
 Chapter 5 – Business Case Theme.

Lecture 1 – Business Case Theme Purpose.

Key message: The purpose of the Business Case Theme is to establish mechanisms to judge
whether the project is and remains Desirable, Viable and Achievable to support decision making
in its continued investment.

 Justifies the start of the project and its continuation.

 Drives decision making throughout the project.

We need to keep the business case up to date as the project progresses and keep assessing
whether continued investment is justifiable.

Lecture 2 – Desirable, Viable & Achievable.

Deciding to embark upon project isn’t a simple question of assessing of the project is:

It is important to keep a project’s business case aligned to what is going on outside of the project
itself, which means ensuring that it supports the corporate, or programme objectives.
Lecture 3 – Business Case Life Cycle.

This diagram shows the life-cycle of a project business case and how it relates to Prince2.

First the business case needs to be developed, which is about ensuring you have the right
information. During pre-project preparation (the SU process), some of the information provided
in the project mandate is used to develop an outline business case.

It is considered an outline business case because the project plan, which will provide a better
indication of project costs and timescales, has not yet been created. The outline business case is
presented to the project board in the project brief at the end of the SU process.

Developing the business case continues into the initiation stage (the IP process) where the costs
and timescales from the project plan are added. The business case is presented again, but this
time as part of the PID at the end of the IP process. It is the board who verify that the business
case shows the project to be, worthwhile. This all happens during the DP process.

The project board’s first decision on the business case marks the official start of the project and
continuation decisions are then made at each stage boundary.
When the project is underway, the business case still needs to be maintained to make sure that
the information within it is accurate and up to date, reflecting any revised forecasts.

As the project delivers specialist products the benefits start to be realized and can be confirmed.
On some, project’s benefits may be realized before the end of the project, but it is more common
for benefits to materialize after the project has closed.

Developing = Making sure you have the right information.

Verify = Project board assessing if the project is still worthwhile.

Confirm = Assessing if the benefits have been achieved.

Lecture 4 – Outputs, Outcomes, Benefits and Dis-Benefits.

Projects deliver specialist products, which are also known as ‘outputs. These outputs do not have
to be tangible things like a building for example it could be software of a set of processes.

These outputs enable business changes and when used they give rise to ‘outcomes. So, an
outcome can be described as the resulting change in behavior that occurs from a projects output.

Benefits are the measurable improvement that results from outcomes which therefore follow on
later. They don not have to be about profit. The business changes can also cause negative side
effects and consequences which result in Dis-Benefits.

It should be possible to track all the project’s benefits to the project outputs, that there is a line
of provenance; otherwise they cannot be claimed as benefits of the project.

Relating these terms to an example can help understand the difference between them,
particularly for outcomes and benefits.

If we consider a project to build a school. The output would be the school itself. Some outcomes
would be that the school is open, teachers are working at the school and children are attending
the school. Benefits would be things like improved choice of schools and increased capacity for
educating children in each area, perhaps reduced travel times for some families and several new
teaching jobs. A dis-benefit for the project could be increased traffic affecting people who live
close to the new school.
Lecture 5 – Business Case Contents.

Full understanding of the recommended contents of a good business case is tested during the
practitioner exam, but some knowledge is also useful for the foundation level.

The business case starts with the projects manager’s Executive Summary highlighting key points.

The Reasons section explains why the project is needed. It describes the problem, of situation
that led to the project being considered in the first place.

The Business Options section describes the different possible solutions to the problem. There
should be a do nothing option which acts as a starting point, as well as a do minimum option.

The Expected Benefits section should list all the benefits the project expects to be delivered.
While the benefits do not have to be financial and should be expressed in measurable terms.

Expected Dis-Benefits are not risky, they are predictable negative consequences of the project
that are expected by the stakeholders.
Timescale section of the business case covers both the period over which the project will run and
over what period the benefits will be realized.

Cost should include the all the project’s costs and detail the projects funding’s arrangements.

Investment Appraisal or (Return on Investment) compares the aggregated benefits and dis-
benefits to the project costs.

Major Risks section is not intended to repeat the entire contents of the project’s risk register.
The serious risks or (show-stoppers) to the project are detailed here to help assessing viability.

For the foundation exam you need to be clear on the purpose of each document so shown here
is he purpose of the Business Case.
Lecture 6 – Benefits Management Approach.

Measuring the achievement of benefits can only happen after the project has delivered some or
all the outputs. To help with measuring achievements of benefits a ‘Benefits Management
Approach’ is required.

This is first created during the initiating a project process to cater for managing and measuring
any benefits that occur during the project. The benefits management approach should be
reviewed, and if necessary updated, at each stage boundary and must be reviewed and updated
during closure to make sure that post-project benefits are reviewed and included.

Although the benefits management approach is created while the PID is being collated, it does
not form part of the PID.

A couple of things to note:

Firstly, the reason for the project and the benefits are not part of the benefits management
approach because this is already stated in the business case.

The other thing to note is that perhaps time should be allowed to identify if the project brought
about any un-expected benefits.
The purpose of the benefits management approach is shown here:
Lecture 7 – Minimum Requirements for Business Case Theme.

As we know, Prince2 specifies minimum requirements for each theme. For the business case
theme these are:

There are two principles being supported here, which are Continued Business Justification and
Defined Roles and Responsibilities.

In addition, Prince2 requires two management products are being produced / maintained for
this theme, which are:
Lecture 8 – Business Case Theme Key Responsibilities.

Shown here are some of the key responsibilities for this theme. One thing different is the mention
of the Senior Supplier being responsible for the business case. This occurs when there is a
commercial situation or project, involving more than one organization. So, there may be more
than one business case associated with a project.

Of course, the main Prince2 principle covered by this theme is Continued Business Justification.
 Chapter 6 – SU & IP Processes.

Lecture 1 – SU & IP Process.

Prince2 is about managing projects in a controlled way. Starting Up a project and Initiating a
Project processes ensure that projects have a structured and controlled start.

Starting up a project occurs before the project starts and culminates in the production of a
document called the project brief, along with a plan for the first stage of the work. Directing a
project process in project board’s decision making.

Initiating a project is always done in the first stage of a Prince2 project and culminates in the
production of a set of information called the Project Initiation Documentation or (PID). If the
project is not set up well the project manager is likely to find that they must spend a large
proportion of their time ‘fire-fighting’ as the project progresses. If the project is set up well the
project has a much better chance of running smoothly.
Lecture 2 – SU Purpose and Objectives.

Starting up a project abbreviates to ‘SU’ and as said it is a pre-project process, not an actual stage
of the project and containing the following purposes:

 Ensure that pre-requisites are in place for initiating a project.

 Do we have a viable and worthwhile project?
 Prevent poorly conceived projects from being initiated.

Shown here are the summarized objectives of this process. Most of them are self-explanatory
and links to the principles are obvious. One that might not be is that the work of initiation is
planned. This does not mean planning the whole project this early on. Planning the whole project
is quite a job and is only done when the board have given the project the go ahead after the SU
process. This is about creating a plan to make the project plan and the PID, which is the work of
the IP process.
Each process has several activities. Shown here is a diagram from the manual that depicts the
activities of the SU process.
Lecture 3 – Appoint Executive & Project Manager.

This activity is triggered by receipt of a project mandate, which is the initial Terms of Reference
for the project. It is the responsibility of the Corporate, Programme Management or the
Customer (Green) to appoint the Executive (Black) and then for the executive to appoint the
Project Manager (Blue). However, the Corporate, Programme Management or the Customer may
get involved.

It is usual not to set up full documentation for the project during SU because the project isn’t
going ahead. So, if registers have not been set up yet the Daily Log is used to record risks and
issues identified during SU. There may be more than one daily log on the project as other team
members may have them.
Lecture 4 – Capture Previous Lessons.

Before the project manager really gets going on the project, it is a good idea to consider if there
are any useful lessons from the past that can be applied to the project that is just starting. These
may come from own experience or from other projects the organization has undertaken.

At this point the project manager should set up a lessons log to record any lessons that can be
applied to the project. The purpose of the lessons log is shown here.
Lecture 5 – Design and Appoint the Project Management Team.

The size and complexity of the project, in addition to any lessons learned will influence how many
people are needed to manage the different project management team roles.

The project manager needs to design a management team appropriate for the project and create
further role descriptions that will be added to the project brief. It is possible that not all of the
management team will actually join the project at this time because it is common for suppliers
to join projects at different stages, as and when the are needed, but role descriptions for senior
suppliers and team managers can be created now so they are available at the appropriate time.

Corporate or programme management may want to approve the appointment to the project.
Any problems or risks identified at this time are recorded in the daily log.
Lecture 6 – Prepare Outline Business Case.

The project business case is the ‘WHY’ document, detailing the reasons for the project and the
benefits that can be expected from it. It enables the project board to make decisions on whether
they want to make the on-going investment that the project requires. Initial information will
come from the project mandate, but it is likely to be expanded in this SU process. If there isn’t
enough information in the mandate the project manager will have to go and plug the gaps. The
primary purpose of the business case is to justify the project investment.

This activity also includes creation of a project product description which details ‘WHAT’ the
project must deliver. It describes the final output as a product and includes some important
quality information that will help with planning later.

Whilst creating this description is the project manager’s responsibility, information regarding the
customer quality expectations or (CQE’s) should be gathered from the senior users. It is common
for the CQE’s to be a bit vague so the project manager will need to agree with the senior user
more measurable and detailed acceptance criteria that will clearly identify the standards
required to gain final acceptance of the project at the end.
Lecture 7 – Approach & Project Brief.

One of the final pieces of information to go into the project brief is to consider HOW the work of
the project should be done. For example, are the right skills to create the products available in-
house, can we afford external suppliers or is there an ‘off the shelf’ solution available?

The purpose of the project brief is shown above, it provides a foundation for project initiation
because it ensures everyone has a common understanding before the project properly gets
going. It enables the project board to decide on whether to formally start the project. If the
project board does decide to go ahead then the project brief will be expanded to form a PID in
the IP process.
Lecture 8 – Plan the Initiation Stage.

This is the last activity in the SU process.

Before the project board can decide on whether to formally commit to the project, they will want
to know what resources they need to provide to enable the first stage to happen. The first stage
includes creating the Project Plan and the PID. Depending on the complexity of the project, this
could take just a few days or extend to quite several weeks.

Bearing in mind the principle of manage by stages and the concepts of a planning horizon, in that
it is not a good idea to plan in too much detail a long time ahead, the project manager creates a
detailed plan just for the first stage of the project, which is called the initiation stage.

At the end of the SU the project manager can then present the project brief and the initiation
stage plan to the project board, requesting authorization to initiate the project. This request
triggers the start of the directing a project process, where the project board will decide.
Lecture 9 – IP Purpose and Objectives.

Initiating a project process abbreviates to IP and is always the main part of the first stage in a
Prince2 project. Essentially the process is about creating the Project Initiation Documentation, or
the PID, that will form the basis for how the project is going to be managed. It provides a full and
firm foundation for the whole project because it is a bit like a manual. The PID will draw on the
information in the project brief and expand on it.

Prince2 entails:

 Establish solid foundations for the project.

 Enabling the organization to understand the work that needs to be done before significant
spend.

The objectives of the IP process are shown here. Primarily they center on getting a deeper,
common understanding of the project regarding things like the reason for it, scope, quality and
how the project will be managed.
The IP process is triggered after the project board (in the DP process) have made the decision to
authorize progress into initiation. As shown above, in the process diagram, some of the activities
in this process can be done concurrently.
Lecture 10 – Agree the Tailoring Requirements.

This activity can start as soon as the project board have authorized the official start of the project.
Drawing on information in the project brief and perhaps any lessons already captured in the
lessons log, the project manager needs to understand the project context and what standards,
or methods are already in place to carry out this activity. The project board will need to agree
any proposed tailoring which could be done now, before it impacts other aspects of the PID, or
done when they review and approve the PID at the end of the IP process.
Lecture 11 – Project Management Approaches.

The four project management approaches for (Risk, Change Control, Quality and Communication)
are like ‘mini-manuals’, giving information on how these aspects of the project will be managed.
The first three can be worked on concurrently, although they are different activities within the IP
process, and can be started after the tailoring requirements have been agreed.

It’s best to wait until these three are complete before starting on the communication
management approach because stakeholders may be identified while doing the first three that
will need to be incorporated into communication management approach.

If an organization already has processes and procedures in place that address some of the aspects
covered in the management approaches, it is still necessary to create them. They include such
things as any tools and techniques that may be required and responsibilities assigned for the
project, which are likely to be different for each project.

At this time the three registers are also created, for holding information on risks, issues and
quality checks. There is no communication register, but records will be kept of communications
sent out and received by the project. These registers do not form part of the PID because they
will be added to frequently throughout the project, whereas the information in the PID should
be relatively stable and the PID will be version controlled. Any issues and risks already identified
are to be recorded in the daily log so now is an appropriate time to transfer to the correct register.
One of the key things to not here is the difference between a management approach and a
register. As we have said, a management approach is like instructions manual and state how
certain aspects will be managed, whereas the registers are places for actually ‘doing it’ i.e.
recording and tracking risks, issues and quality activities.

The purpose of each management approach is quite similar and shown here. The contents will
be covered in more detail in the appropriate theme sections.
Lecture 12 – Project Controls and Plan.

The management approaches may will have defined some project controls, but they haven’t
necessarily been set up. So, the project manager now re-considers what degree of control is
appropriate for the project in the light of the approaches and may need to refine the controls
section of the PID. Of course, thinking about things like stage boundaries, tolerances and
frequency of highlight reports. At the same time any appropriate procedures will need to be
established.

At the same time the project plan is created. It needs to cover the whole duration of the project
following the initiation stage and provides an overall budget for the project as well as the timeline
for entry into the business case, The project product description is refined if necessary, and the
major products that the project has to deliver are also identified and described. The project plan
will show key milestones, but it is not a good idea to go into a lot of detail. Remember the concept
of a planning horizon, if too much detail is included in the project plan it is likely to quickly become
inaccurate.
Lecture 13 – Refine the Business Case.

Now the project manager can revisit the outline business case contained in the project brief and
add the planned project costs and timescales from the project plan. This is an appropriate time
to also look at the risk register to see if there are any more major risks that need to be added to
the detailed business case.

Once the business case has been fully developed a benefits review approach should be created
to detail how, when and by whom the benefits listed in the business case can be measured for
their achievement. The benefits review approach is created now rather that at the end because
some benefits may be realized and need measuring while the project is in progress. Note that
the benefits review approach is not part of the PID because those measuring benefits probably
do not need the rest of the information in the PID.
It is important to note the differences between the business case and benefits review approach.
Lecture 14 – Assemble the PID.

Towards the end of the IP process the information that has been compiled should be collated
into the PID. Any additional information in the project brief, such as role descriptions,
organization design and the project definition are also incorporated.

PID’s take different forms, they can be a single document or a collection of several, but a good
PID should answer the main questions about the project and form the basis for its management.

The purpose of the PID and its three primary uses are shown here:
Lecture 15 – SU & IP Process Review.

To briefly re-cap on this section, the SU process provides a foundation to go into initiation and IP
provides a full and firm foundation for the rest of the project. SU’s main output is the project
brief, which is developed into the PID in the IP process.

Because these processes are about setting up the project in a controlled way it should not be a
surprise that all the principles are addressed:

 Continued Business Justification – Through creation of the outline business case and
adding detail in IP.
 Learning from Experience – In capturing and incorporating previous lessons.
 Define Roles and Responsibilities – Through creation of role descriptions and the design
of the management team incorporated in both the brief and the PID and appoint roles.
 Manage by Stage – Through creation of the initiation stage plan and through identifying
how many stages the project will have in IP.
 Manage by Exception – Because project tolerances are documented in the brief and PID.
 Focus on Products – Through creation and refinement of the project product description
and lower level product description when planning.
 Tailoring – You can tailor how the information is presented, the project approach will be
different for each project, the team design and use of Prince2 to name a few examples.
 Chapter 7 – Progress Theme.

Lecture 1 – Progress Theme Purpose.

The progress theme is about setting up and using appropriate controls for your project as it
progresses. It is about trying to make sure that you are staying On-Track.

To do this we need information, so Prince2 provides mechanisms to compare what is happening

against what was originally planned.

It is important to get the right amount of control for any project. Micro-management is time
consuming and usually de-motivating, but neither should managers have to make decisions in an
information vacuum. If we think things are going Off-Track, we need mechanisms to alert us so
appropriate action can be taken.
Lecture 2 – Why Have Controls?

Because projects are unique and implement change, they bring lots of uncertainty, which is one
of the reasons for needing robust project controls. The progress theme ensures that information
is provided at a project, stage and work package levels to help the different levels of management
make appropriate decisions.

It is important that each level of management on a project knows the limits of their decision
making authority. As we know, Prince2 calls these limits Tolerances.
Lecture 3 – Limits of Authority.

Usually they are expressed as a range, so for example on a building project we would have a
target data for completing the plastering, but perhaps the plastering work could start a bit early,
providing the roof is on, or it might be possible to delay if it isn’t to hold up other activities.

So, tolerances are the limits of delegated decision making authority that enable a Prince2 project
to implement manage by exception. Working in this way makes efficient use of senior
management time because it is not necessary to escalate every little thing.
Lecture 4 – Elements of Tolerance.

We set targets for the six aspects of a project that we need to manage. We can also set tolerances
for each target if it is appropriate to do so.

The ‘Standard Elements’ of tolerance are Cost and Time, which are straight forward. For
example, we may have a cost target for a stage on a project of spending say $50,000 and a cost
tolerance of $10,000 under, meaning it would be ok to spend just $40,000 and a tolerance of
$5,000 over meaning we could spend $55,000. Although the target is still $50,000 there is no
need to escalate if we are within the tolerances authorized. It is not always good for things to
come in under-budget, for example on a charity project when the money is allocated and meant
to all be spent on a cause.

Time tolerance works much the same way so +1 week would mean there is a tolerance to be 1
week past the target date, whereas -1 week would mean you come in a week early. Like cost
tolerance, it may not be good to deliver some things early, for example the opening ceremony
for an event like the Olympics.

Both cost and time tolerances are detailed in plans and work packages.
As we have said there are other areas that we can have tolerances.

Quality Tolerance relates to the project as a whole and is detailed in the business case.

Risk Tolerance may not be expressed as a range, but perhaps a score regarding the risk’s
probability and potential impact. So, risks scoring over a certain level might have to be escalated.
Another risk tolerance could be if a risk is identified that impacts a certain area, perhaps losing
sensitive data, and that might have to be escalated. Risk tolerances are primarily documented in
the risk management approach.

Scope Tolerance is often the area that must give when a project or stage is running out of time
and money. To implement scope tolerance, use the MoSCow Technique. Before a project, stage
or work package starts you allocate one of these values to each product to be created and agree
with your manager where the ‘Line’ is, then if there are any problems it is clear what products, if
any, can be dropped without having to escalate. Scope tolerance is detailed with cost and time.

Once tolerances are agreed as soon as you forecast that you cannot stay within them you are in
an exception situation and it is time to escalate. If you wait until you have run out of time or
money there will be fewer options available.
Lecture 5 – Levels of Tolerance.

Different levels of tolerance are set for different levels of management on a Prince2 project.

The Commissioning Level (Corporate / Programme Management or The Customer) set the
tolerances for the project. This is the limit of decision making authority that the project board
must work within. When project tolerances are to be exceeded the exception must be escalated
back up to the (Corporate / Programme Management or The Customer) for decision making.

The Project Board can then apportion stage tolerances to the project manager as each stage is
authorized to begin. When the project manager identifies a stage level exception it is escalated
as an exception to the project board.

If the Project Manager has stage tolerance, they can choose to allocate work package tolerance
to the Team manager. If the team manager then identifies a work package exception, they raise
it to the project manager. If the project manager is within their authority, they can take corrective
action, otherwise the situation needs to be escalated to the project board or higher.

Please note that although an exception can be identified at any level it is the project manager
alone who writes Exception Reports because they are intended to inform the project board or
even, higher, of the exception situation.

This diagram shows that Prince2 defines controls for all levels of management on a project, not
just for the project board and the project manager.
Lecture 6 – Project Board Controls.

Prince2 provides both Time and Event driven controls. The difference between the two is how
frequent they occur.

Time Driven Controls happen at regular pre-determined intervals.

Event Driven Controls, such as an end stage assessment will happen at a time, but it will not
happen on a regular basis, say every week or month.

Whether a control is time or event driven it will be used to aid decision making.
Lecture 7 – Project Manager Controls.

Regular checkpoint reports are provided by team managers to the project manager. The project
manager will need to make sure that these are timed to be received just before they must report
regular highlights to the board. So, there are just two time driven (or regular) controls on a
Prince2 project. One is Highlight Report and the other is Checkpoint Report.

Prince2 provides many mechanisms for the project manager to receive and track information
when there are issues and risks that need to be dealt with.
Lecture 8 – Minimum Requirements for Progress Theme.

Frequency of reporting is not prescribed and should reflect the needs of the project, the nature
of the work and the experience of the project team. For example, with a highly experienced team
reporting could be less frequent.

Prince2 is not prescriptive regarding how monitoring and controlling progress is achieved if the
minimum requirements shown are catered for.
Lecture 9 – Progress Theme Key Responsibilities.

Shown here are some of the key responsibilities for this theme, remembering that setting
tolerances is like a cascade down from the top and that reporting and escalating exceptions goes
the other way.
 Chapter 8 – Plans Theme.

Lecture 1 – Plans Theme Purpose.

The purpose of the plans theme is to facilitate both communication and control through the
information provided. It does this by defining the means or how products will be delivered. The
theme describes an approach to planning, the recommended types of plans for a project and
introduces the product based planning technique.

It is common for people to regard a plan as just being a chart or schedule showing timescales,
but Prince2 takes a broader view and states that it must also describe, what is delivered, how
and by whom.

In Prince2 a plan does not have to be in any format such as a Grant chart, but it will contain
information on things like the tasks that need to be done to make the products, where, when
and by whom. So, a good plan identifies the products to be delivered, details the budget required
and defines what resources are required.

In Prince2 there are only the following types of plan, project, stage, team, and exception. A final
word before we move on to the next unit, which is that the resources required to deliver a plan
need to be committed by those approving that plan to ensure they are available when needed.
Lecture 2 – Three Levels of Plan.

First, the Project Plan. It is produced by the project manager predominantly for the project board.
It needs to cover the whole duration of the project following the initiation stage. The project plan
will need to show how the project will be divided into stages, major decisions and milestones and
the resources that the board will need to provide. The project plan is mandatory because it
provides a complete picture of the project and provides the project budget for entry.

The second level is the Stage Plan. This is also produced by the project manager and it is the plan
they use for day to day control of the project, so it needs to be much more detailed. A stage plan
is required for each stage of the project, one for initiation stage and one for delivery stage.

The third level of plan is Team Plan. This level of plan is optional, and is created by the team
manager, if they are required. A team plan covers the work of one or more woke packages to
produce the specialist products. Because team managers often have more detailed technical
knowledge about the work being done than the project manager, it is possible that a stage plan
will entail pulling together information from different tam plans, remembering that some teams
may be external suppliers.

It is important to note that Exception Plans are NOT another level of plan. They are produced to
the same level of detail as either the whole project plan or stage plan because they will replace
them, becoming a new version.

So, Prince2 recognizes that their plans are not a one size fits all and there can be three different
levels of plan in a project even though they might not all be necessary in every circumstance.
Lecture 3 – Project Plans.

The project plan is mandatory because it is the only plan that provides a complete picture of the
project, and it provides details of the project budget to go into the business case. The project
board won’t want too much detail such as showing what goes into different work packages, but
will want to see things like stage boundaries, high level activities and project level tolerances. Of
course, the project plan should support high level objectives, so it needs to align with corporate,
programme or the customer’s plans.

Creating a project plan can take some time so it is not done in the SU process. We wait until the
project board have made the decision to authorize initiation, so it is created during the IP process.
Project plans are updated at each stage boundary to reflect what progress has been made to data
and any revised forecasts.
Lecture 4 – Stage Plans.

On a very small project, with one delivery stage you could potentially get away without using
stage plans, otherwise a stage plan is required for each management stage.

Remember it is not wise to plan in detail too far ahead, so stage plans provide more detail than
a project plan but will cover a shorter duration.

They are the project manager’s plan for day-to-day control and will detail budget for each stage
along with any agreed stage tolerances. Each stage plan should be developed based on the
experiences of previous stage plans, so as the project progresses estimating can improves.

The first plan to be created on a Prince2 project is a stage plan. During the SU process a stage
plan for the initiation stage is created. The rest of the stage plans are created during the SN
process, just one stage ahead. Stage plans are updated with actuals as part of day to day project
manager’s work during the CS process.
Lecture 5 – Team Plans.

In the definition of a Team Plan it is described as an optional plan, because there may not be
many management stages on a project, many people working on it and possibly no team
managers, in which case the project and stage plans would suffice.

Whilst team plans are optional, remember that they are still one of the three recognized levels
of planning detail that may be required.

A team plan, if created covers the work of one or more work packages. The project board do not
formally review or approve the team plans, and it is possible that the project manager may not
see them either, especially if the team in question is from an external supplier.

When team plans are required, they are created and updated by the team manager during the
MP process, but it is possible that a draft may have been created earlier to provide the project
manager with estimates to go into the stage plan.
Lecture 6 – Exception Plans.

Exception Plans are not a distinct level of plan because they are created at the same level of detail
as the plan they will replace, which is either a project or a stage plan, depending upon the scale
of the exception. If a stage is in exception the board have authority to decide, but if the whole
project is in exception then the project board will have to escalate higher.

The project manager creates an exception plan only when the project board asks for one. When
an exception plan is approved it will replace the plan that was in exception and will be base-lined
as a new version. All exception plans are created in the SB process.
Lecture 7 – Where Do We Plan?

The first plan to be created on a project is not the project plan but is a stage plan for the initiation
stage. It is created in the SU process before the official start of the project.

The next plan created is the project plan during the IP process for incorporation into the PID.

The delivery stage plans are created in the SB process, always just one stage ahead, and the team
plans are created by the MP process.

What is interesting to note is where no plans are created.

The DP and CP process are probably not a surprise, but no new plans are created during the CS
process.

Controlling a Stage (CS) is a process for day to day project managers work once the project is
properly up and running. In the CS process the project manager is delivering against a plan that
was created in the preceding SB process. Whilst the CS process does not entail creating a new
plan, it does entail updating the current stage plan with details of the actual progress being made.
Lecture 8 – Management Stages.

We have mentioned that authorizing a stage is a form of control, but haven’t advised yet where
to put stage boundaries, how long they should be, or how many are required on a project.

A stage boundary brings project board control, which can be very important on a high risk project.
Also, it can be especially useful for the board to understand and make a decision before a
particular risk element of the project starts.

Prince2 doesn’t prescribe what this should be, but there are some fundamentals considerations:

 How far ahead is it sensible to plan? – the Planning Horizon.

 Project key decision points – Where?
 Amount of anticipated project risks.
 Management overhead vs required level of control.

On a simple project, perhaps one that might only last 3 or 4 months, have a very small team and
be low risk, the project profile may look like this.

First there is always an initiation stage to create the PID and project plan and then one delivery
stage to create the specialist products on the project. This could be perfectly adequate.
However, this won’t be sufficient for larger projects, but where to put the stage boundaries and
how many should there be?

With stage boundaries being decision points giving the project board control, the riskier or even
complect the project, such as if new technology is being employed, then the more stages you
should plan to have.

Also of course the longer the project duration the more stages you should have because you
don’t want to be planning in detail too far ahead. In which case your project could look like this.

There is no upper limit on the number of stages.

There needs to be a balance between having sufficient control of the project and the overhead
of the preparation work that is entailed in each stage boundaries.
Lecture 9 – Aligning Stages and Delivery.

One of the considerations for where to put stage boundaries is the potential alignment with the
technical work or the project. Prince2 refers to different types of technical work as delivery steps.
Work of a management stage is grouped by the different techniques being used, as shown here.

It is great if we can map management stages neatly against the delivery steps, so that they
coincide. Sometimes this happens when a senior decision is required before a particular piece of
work can commence. But it isn’t always possible for this to happen.

Notice that this diagram is showing the delivery steps are overlapping in time. This is a very
common situation, and work must be scheduled like this to get it all done in a sensible timeframe.

Now let’s apply management stages to our diagram:

A good place to put a stage boundary can be to align with other events and decisions being made
on the project. In this example a contract is going to be signed with the supplier doing the building
work, hence the placement of the second stage boundary, just before the work commences.

When a delivery step does span a management stage boundary as shown here, it is important to
be clear on how complete products should be at that stage boundary.

One solution to trying to make things clearer is to do this:

Break down the products and work packages so that they do fit within a single management
stage. In this example the design work has been divided into three products – overall design in
one stage, detailed design in a second stage and peripheral design in a third stage.

Princs2’s approach with management stages is for management to focus on the management
stages as they form the basis for project planning and control rather than let the project be driven
by the specialist teams.
Lecture 10 – Management Stages Summary.
Lecture 11 – Introducing Product Based Planning.

Product Base Planning is a strongly recommended Prince2 technique. It is based on the premise
that when planning a project, it is best to think about the products you must create before
planning the activities required to make them.

If we equate it to the simple example of preparing a meal, it is necessary to think about the menu
before you do something like turning on the oven to preheat because it might not be necessary.

There are four steps to product based planning as shown in the diagram:

In Prince2 a specialist product can be many things such as a selected date or a business process
through to more tangible physical items.
Lecture 12 – Product Descriptions.

Product Descriptions describe the products, or deliverables, of your project. In effect they are
requirement documents.

There are two different types of product descriptions on a Prince2 Project, and both will contain
information on quality.

Firstly, we have the Project Product Description, shown here is its purpose.

So, it is a special form of product description. Each project will have only one project product
description that details what the project must deliver to gain acceptance at the end.

Two important sections in it are the Customers Quality Expectations (CQE’s) which may rather
be vague statements about quality and the more tightly defined Acceptance Criteria, which
should ideally be prioritized.

An example of a customer quality expectation could be to have a modern kitchen, whereas an

acceptance criteria could be integrated appliances and soft close cabinets.

It is the project manager’s responsibility to make sure the document gets written, but the
information come from the senior user.
Then we have Lower Level Product Descriptions, one for each specialist product to be made.
These provide a good understanding of the detailed nature and purpose of the products. The
quality criteria for these will vary tremendously from one product to another.

Product descriptions are like templates that could possibly be re-used, so it can be useful to keep
a library of them for future projects. Get the users involved and start writing product descriptions
as soon as the products themselves are identified. Descriptions for the major products of a
project should be created in the IP process. It is common for more products to be identified and
documented later during stage planning in the SB process.

Product descriptions will form part of a plan, so when a particular stage plan is authorized by the
project board the product description for products to be made in that stage are base-lined with
the stage plan. If changes are required later, then the formal change control procedure are used.
Lecture 13 – Product Breakdown Structure.

Creating a Product Breakdown Structure is the second step in product based planning. This is a
hierarchy diagram that shows the sub-products (or scope) of a project.

The project product description is a good start point because it will detail the major sub-products
of the project. It is a good idea to involve others when creating this diagram.

To do it, place the project product at the top and the sub-products are placed in logical groupings
below bearing in mind a few basic rules. Each sub-product should only appear once on the
diagram even if it is going to be used in several places. You will need to decide on the most logical
place for it to go.

This diagram is all about products so there should be no activities (or verbs) – they will be
identified later.

Also, the diagram doesn’t have any arrow representing a direction or flow – it is a de-composition
diagram.

Finally, it can be useful to identify and show on the diagram externally sourced products, on this
diagram they have been shown in green.
These are things that the project will need, or use, but the project manager is not responsible for
their creation. This is because either they already exist, or because they are being developed or
supplied by parties outside of the project team. However, the project manager will be responsible
for other products that are created using externally sourced products.

A key reason for identifying externally sourced products on our diagrams is to identify threats to
the project, such as something not turning up on time or being defective. Threats that are
identified will be added to the risk registered and consideration given regarding what can be done
about them. This will be covered more fully in the risk theme section later.
Lecture 14 – Product Flow Diagram.

The fourth and final step of product based planning is to create a Product Flow Diagram. The
purpose of this diagram is to show the order in which the products need to be created, what you
can start on straight away and where there are dependencies.

This diagram ca be drawn either top to bottom or left to right. Left to right looks like a timeline.

Place the project product at the end, so either bottom or the right hand side of the diagram
depending on your orientation. There will only be one end point on this diagram as all the sub
products should flow into it because they should all be contributing to the result.

Then you are going to take the sub products already identified in the product breakdown
structure and add them to this diagram. First, put any external sourced products that already
exist at the start along with any internal products that you can get on with straight away. There
are often several start points on this diagram.

Then, place the remaining sub products in n appropriate place according to dependencies on
other products. There are still no activities (or verbs) shown, but this diagram does require arrows
to show which way the diagram flows.

Externally sourced products are shown on this diagram. Where you had groups of products on
the breakdown structure diagram, these groupings are not necessarily brought across to the
product flow diagram as it can get confusing.
For example, on our example product breakdown structure for the hotel we had something called
‘Furniture Group’, but we will not actually be making it. It is therefore not shown on the flow
diagram. Sometimes a group is a product. For example, we could have brochure as both a group
and a product. The sub-products could be the different sections of the brochure.

The product flow diagram identifies dependencies between products. Later in this will help with
identifying dependencies between activities. The definition for a dependency is shown here:

Note the difference between an internal and external dependency, which is based on whether
the project team have full control over the situation or not.
Lecture 15 – Benefits of Product Based Planning.

To re-cap, the first step in product based planning is to create the project product description.
Then in alphabetical order – Breakdown, Descriptions, Flow.

Product based planning is a very powerful technique that provides several benefits.

Diagrams are a great way to communicate and sometimes they make it easier to spot errors.

Because the scope is clearly shown on the product breakdown structure it helps reduce the risk
of missing something and of reducing uncontrolled change ( or scope creep).

Once the plan and diagram are signed off if any new products or requirements are identified they
are subject to formal change control.

The product descriptions are a great way to manage expectations and remove ambiguity because
it is made very clear what must be delivered.

The process of writing product descriptions involves the users which reduces the likelihood of
disputes later.
Lecture 16 – Structured Approach to Plans.

Structured Approach to Planning entails more than just the product based planning technique.

First, Designing the Plan is done once per project and is a pre-requisite for the rest of the steps.
It entails thinking about things like presentation and layout – what do the different levels of plans
need to look like bearing in mind their intended audience. Do we indeed need all levels of plan
for our project and do we nee to buy or use any planning tools?

After designing the plan, the remaining steps are iterative and done for each plan created,
whether it is a project, stage, or team plan.

The second step ‘Define and Analyze the Products’ is the product based planning technique that
we have already looked at.

Once products are identified we can thing about Activities required to make them and make sure
we have the dependencies between the activities identified. One way to do this is to use the
product flow diagram and think about what needs to be done to turn one product into the next.

Activities can then be Estimated, which also entails identifying the type of resource required.
Resources include tolls and equipment as well as human resources. Although Prince2 doesn’t
advocate any method for estimating tasks it is a good idea to get the appropriate technical
specialists involved. This is called ‘bottom-up’ planning and will usually produce more accurate
timescales than ‘top-down’ planning where the manager comes up with estimates on their own.
The activities dependencies and estimates can then be combined into a Schedule, or timeline,
for the whole plan. This could be presented as a Gantt chart, and techniques like critical path
analysis are resource levelling applied.

Planning is a key time for the project manager to think about Risks. It might be that actions to
deal with risks (called risk responses) need to be added to the plan, and any new risks identified
during planning should be recorded in the risk register and properly analyzed.

Finally, we need to Document the Plan. The purpose of a plan and its contents is shown here:

Although plans contain the schedule for the activities, you will notice that a good plan contains
more than that. We need to include the product descriptions, state how the plan will be
monitored and controlled, such as updating it with actual progress, and we also need to include
budgets, not forgetting monies set aside for change requests and risk responses.
Lecture 17 – Plans Theme Minimum Requirements.

For the plans theme, a project claiming to be following Prine2 must:

Prince2 requires that 4 management products are created and maintained which are:
Lecture 18 – Plans Theme Key Responsibilities and Summary.

Shown here are some of the key responsibilites for the plans theme:

It should not be a surprise that the highest level set project level tolerances and approve
exception plans when the whole project is in exception, nor that the project manager is
responsible for creating all plans except teams plans.

To briefly summarize the plans theme, Prince2 recommends Three Levels of Plan:

 Project.
 Stage.
 Team.

Although exception plans are required in certain situations, they will be prepared either at the
project or stage level of plan.

Use of Management Stages is mandatory – we could put it as (thou shalt use stages). Stages need
planning and help to solve the planning horizon issue. They also enable the project board to
delegate in stages.

Prince2 takes a Product Oriented approach to planning which states that the required products
are identified before project activities.
 Chapter 9 – Risk Theme.

Lecture 1 – Risk Theme Purpose.

Key Message: The purpose of the Risk Theme is to identify, asses and control uncertainty and, as
a result improve the ability of the project to succeed.

We know that projects introduce change and are a step into the unknown, so they bring more
uncertainty than business-as-usual work. To give projects the best chance of success that
uncertainty needs to be managed and controlled.

In Prince2 the terms Uncertainty and Risk are interchangeable. However, risks should not be
confused with issues. Issues are certain not uncertain. Things like, problems that have occurred
and a decision or action is required to resolve them.

The risk theme describes what risks are, the two different type of risk, and provides a procedure
for identifying and managing them.

If we do take the time to identify and analyze the risks (or potential problems), because they
haven’t happened, yet we have the possibility of doing something about them.

Supporting the continued business justification principle!

Lecture 2 – Threats & Opportunities.

Risks come in two flavors:

Threats are events that, should they occur would have a negative impact on project objectives.
We want to try to prevent the threats from happening and it is these risks that we tend to focus
most of our attention on.

When we see the term risk there is a tendency to just think about threats, the bad stuff, however,
we should not overlook opportunities.

Opportunities are the things that should they occur would have a favorable impact on the project
objectives. We would want to encourage the opportunities to happen. An example would be
when holding a social event, we could additionally raise money for a charity.

Managing risks is a continual activity and we need to make sure that the level of risk is acceptable
when considered against what the project is trying to achieve.
Lecture 3 – Introducing the Risk Management Procedure.

Risk management is not something that happens once on a project, it is an on-going activity and
the loop of the Prince2 risk management procedure shown above reflects this.

The procedure follows a logical order. First you cannot do anything until you have identified the
risks and recorded the information to make sure that there is common understanding.

You need to assess the risks to decide how bad they really are, and when you have done that you
can plan what actions of any you want to take. Then of course you need to implement the actions.
All the while you need to be communicating about what is happening.
Lecture 4 – Identify Step.

There are two parts to risk identification:

The Identify Context aspect is about understanding the nature of the project and its complexity,
to identify which project objectives may be at stake. This incorporates things like understanding
how many organizations are involved and the relationships between them, corporate policies,
and the organization’s Risk Appetite, which is its unique attitude to risk taking. All of this will help
the project manager formulate the project’s risk management approach, which is in effect a
manual for how risks will be managed on a project.

The second aspect is to Identify Risks. There are many way to do this, including running
workshops or using risk categories and checklists as prompts, but it is important for the project
manager to realize that they are unlikely to identify all the risks themselves. Some risks may only
be apparent to technical specialists, so it is wise to encourage everyone on the project to identify
risks for consideration.
The individual risks identified should all be added to the risk register. When we do record risks in
the register it is important that they are properly described in terms of the Risk Cause (which is
the source or trigger of the risk), the Risk Event itself, and the Risk Effect or impact the risk would
have should it materialize.

If a risk is not adequately described we may end up making assumptions, particularly about the
risk cause which, in turn, could lead us to take ineffective actions to manage that risk.

For instance, consider the risk of a shipment of materials not arriving; there could be many
reasons or triggers for such a risk, such as piracy, bad weather, the ship sinking or the specific
containers getting lost in transit. Each of these triggers would require different types of action to
mitigate them, so to be able to effectively manage risks they must first be properly describes.
Lecture 5 – Assess Step.

The second step in the risk management procedure is to Assess the risks that have been
identified. This assess step also have two parts, Estimate and Evaluate.

Estimating means looking at the individual risks in the register and assessing them in terms of:

Probability  how likely is it that the risk will happen?

Impact  How bad is the effect if it happens?

Proximity  When might the risk happen, or how close in time are we to it happening?

The information is added to the risk register for each risk.

There are different techniques that can be used to assess risks. For estimating individual risks,
you can use a Probability/Impact Grid as shown above. You can use different scoring systems,
percentages or even just terms like high, medium, and low to provide profile for each risk. When
you have a scoring system for risks it is easy to set the project’s risk tolerance, for example risks
scoring over a certain value must be escalated. Where the risk tolerance lies will depend upon
factors such as the organization’s risk appetite, the nature of the project and project board.
The second part of the assess step is to Evaluate. This means considering the net effect of all the
risks against the project’s objectives.

To present information on evaluating the project risks you could use RAG (red, amber, green)
reporting, as shown above. Each dot on the grid will relate to a risk on the register. RAG risk
reporting can be a useful technique for reporting the risk profile to the project board.
Lecture 6 – Plan Step.

The third step in the risk management procedure is about Planning Countermeasure Actions,
which Prince2 calls Risk Responses. Prince2 recommends several different categories of risk
response that may help you identify the most appropriate actions to a specific risk.

The first one for threats is to Avoid the risk, which means ensuring that the risk cannot happen.
If we take an example of a shipping container not arriving, we could source the materials locally
rather than importing them. The materials might be a higher price, but we do not have to wait
so long to get them and no shipping container is required.

The converse for this with opportunities is Exploit, which could be implementing the cause of an
opportunity. Sometimes this can be done with no extra cost, or it could entail changing plans. If
we think of a pharmaceutical company who have a drug that is effective for a particular condition,
but through its use, it is discovered that it helps with another different condition. To exploit this
would prescribing the drug for the other condition.
Then we have Reduce, which can be through reducing the probability or likelihood of the risk
occurring or the impact it would have. In the shipping container scenario, you could ensure that
you select a reliable shipping company with routes that avoid known pirates’ areas. You could do
this by placing consignments on several different ships.

For opportunities, the converse in Enhance, which is about making the opportunity more likely
to occur. Again, thinking about a pharmaceutical company, if they have a drug that they suspect
might be suitable for another condition but hasn’t been proven they could put it through clinical
trials. The trials would of course cost money and may not give the desired outcome, but the trials
are a way of increasing opportunity.

Transfer is a risk option that can be used for both threats and opportunities. This option aims to
pass part, but not all the risk to a third party. A very common form of transferring threats is to
take out insurance. It is less commonly used for opportunities, but an example is that an
organization could use a 3rd party organization to telephone sales leads for a fee, but the first
organization retains the customer.

Sharing the risk is also common to both threats and opportunities, but it’s different in nature
from transfer in that it operates on a basis of sharing both the pain and gain, a bit like a marriage
or joint venture. There must be multiple parties involved to use this option and there must be
potential up and downside for both parties for it to be a shared risk. This option is not the same
as engaging a third party organization or contractor to undertake a task for the project for a fee.

Accepting a risk, either threat or opportunity means that the organization is going to take the
chance that the risk might not occur. Nothing is going to be spent to mitigate a threat or to
encourage an opportunity. This option would not be appropriate if the risks were judged to
exceed any risk tolerance thresholds for the project. Risk that are being accepted are still
recorded in the risk register and monitored.

The final option is to Prepare Contingent Actions. What this means is preparing a plan that is not
actioned straight away and is sometimes referred to as Fallback Plan. Contingent plans can be
made in conjunction with any of the other risk response options as they can be applied if any
initial response actions are seen to not be working or the situation changes and the risk occurs.
This option provides flexibility for future actions at a smaller committed cost.

It is worth noting that sometimes opportunities my be rejected because perhaps there isn’t
enough time or money to take actions without affecting project objectives.
Lecture 7 – Risk Planning Considerations.

There are other considerations when planning responses to risks. We need to consider the likely
effects that our planned risk responses would make, how many actions are required, and any
potential knock-effects of our actions.

The Inherent Risk is the risk as first identified. Let’s say with the shipping example we have
assessed the risk of the shipment not arriving as medium probability and high impact. By taking
a reduction activity and selecting a route known to avoid common piracy areas we might reduce
the probability to low, but we are still left with some element of residual risk. Another action of
identifying fall back suppliers might reduce the impact to medium, but still left with some risk.

So, it may be necessary to apply more than one response to a single risk, but even then, there
may still be a residual risk remaining. It may not be cost effective, or even possible to completely
remove a risk. During this plan step the cost responses need to be weighed up against the
potential impact of the risk when deciding which and how many risk responses to use.

One last thing to consider when planning responses is to think about is, if the risk response itself
will give rise to any new risks. So, with selecting a route that avoids known piracy trouble spots
and taking a longer route, there could be a secondary risk that the shipment might arrive late.

While planning risk responses consider the following:

 Possible effect on plans & work packages.

 Business case / justification & tolerances.
 Effect on corporate/programme management/the customer.
 Most appropriate body to manage the risk (may not be within project team).
Lecture 8 – Implement Step.

Once risk responses have been planned, they need to be implemented, which is the next step in
the procedure.

To make sure risk responses do get implemented each risk should be assigned a Risk Owner. This
person should be whoever is best placed to manage that particular risk, which could be anyone,
including project board members. Risk owners keep a watchful eye on the risks assigned to the.
Carrying out the specific risk response actions is the role of the Risk Actionee. The risk actionee
and risk owner could be the same person, or in some cases there could be several risk actionees
carrying out different risk responses, but there is always only 1 risk owner for an individual risk.

Who these people are will be recorded in the risk register against the specific risk ,as different
risks will have different risk owners.

Often risk responses require funding. So, to pay for the risk responses some of the general project
and stage budget are ring-fenced specifically for this purpose. It is called a Risk Budget. If we are
going to set up a risk budget, and how it will be used will be detailed in the risk management
strategy, but the actual amount set aside for the project or a particular stage will be in the
associated plan along with all of the budgets.
Other risk management activities such as creating the risk management approach and
maintaining the risk register, which are part of running any project are not paid for by the risk
budget but are part of the general project budget. The risk budget is intended to purely pay for
specific risk responses.

Sometimes there is a temptation for the project budget to be treated as a pot of money that is
available to the project manager to be used on things other than risks, such as covering the cost
of a change. This practice only creates problems further down the line so to guard against it, i=the
risk management approach should detail how the risk budget can be used.
Lecture 9 – Communicate Step.

Communication is the final step in the Prince2 risk management procedure.

As we have said, management of risks is on-going throughout the whole project lifecycle and
during the project we will need to communicate about the project risks and the management.

Firstly, in the PID is the Risk Management Approach which communicates how risks will be
managed on the project. The purpose of the strategy is shown above.

The PID also contains the Communication Management Approach which will identify
stakeholders who need to be informed about risks and how.

Of course, the risk register also helps us communicate about risks and the purpose of this is
shown above, it will show information on all the identified risks for a given project.

The difference between a risk management approach and the risk register. The strategy provides
information on how risks will be managed, but the register is a place for doing it.

Then there are many documents that will report on risks and any progress being made on risk
responses both drawing on and adding to information in the risk register such as:

 Checkpoint Reports.
 Highlight Reports.
 End stage Reports.
 Lessons Reports.
Lecture 10 – Risk Theme Minimum Requirements.
Lecture 11 – Risk Theme Responsibilities and Summary.

Shown here are some of the key responsibilities for the Risk Theme and its summary:
 Chapter 10 – Change Theme.

Lecture 1 – Change Theme Purpose.

Key Message: The purpose of the change theme is to identify, assess and control any potential
and approved changes to the baselines.

As we know projects introduce change to organizations. However, the Prince2 change theme is
not about managing the organizational change; rather it is about managing any changes to the
project’s agreed scope and requirements.

Change can only be assessed in terms of its impact on an agreed situation. This situation is called
a Baseline, and it’s like a snapshot at a point in time. Baselines are therefore defined as reference
levels against which something can be monitored and controlled.

If we do not manage, change projects can quickly get out of control and scope-creep prevails. So,
this theme is about assessing and controlling that change.
We need to be clear that Prince2 is not advocating that changes must be prevented on a project,
but before we agree to implement any change, we should understand the impacts to the project.

There are only two reasons to implement a change, which are:

 Introduce a new benefit.

 Protect n existing benefit.

The theme therefore provides a procedure for managing change, which includes thinking about
who makes decisions on change and how to pay for it.

To manage change requires that baselines are established so changes can be monitored and
controlled when new versions are required. This could be quite a simple version system; IT
projects often have complex inter-dependencies between items that need managing and
engineering based organizations will often use asset or product management systems. These are
essentially configuration managements systems, which also guard against un-authorized change.
Lecture 2 – Types of Issue.

Prince2 identifies three different types of issue. The reason we differentiate between them is to
identify who should pay for any associated costs and who should decide what to do.

Firstly, let’s look at the Request for Change type. This is when someone comes up with a
suggestion for improvement to a product being developed after the product description has been
approved by the project board. Often requests for change originate from the customer, but the
project team and suppliers can make recommendations too. If the customer decides to go ahead
with a change, any additional costs will have to be paid for by the customer, and this is what a
change budget pays for. Changing requirements are inevitable, but they can be very costly, and
is often where suppliers will escalate costs if they are working on a fixed price arrangement.
Requests for change includes when the customer forgot to include something in the product
description because it wouldn’t be reasonable to expect a supplier to do extra work for free.

Then we have an Off Specification type. This is when a supplier does not delver what the
customer has asked for in a product description, so the products falls short in some ways, it is off
the specification. In this situation the onus if on the supplier to fix the problem and pay for
corrective work. There are occasions when this might be difficult to do; perhaps there just isn’t
time to fix things, in which case the customer may grant a concession, which means that they
must live with the situation. Exactly how off specifications are handled and paid for will ultimately
depend upon any formal terms and conditions with that supplier.

When there is an ‘Off Spec’ the customer may grant a ‘Concession’.

Finally, any other type of issue falls under General Problem or Concern. This covers a whole range
of things, such as under-estimating a task. Any costs will have to be met by the customer,
probably from cost tolerance in the first instance.
Lecture 3 – Technique, Issue and Change Control Procedure.

The first thing to do when an issue is identified is to Capture it. We need to decide which of the
three types of issue it is, how bad it is and then record it in the correct place. We have a choice
regarding where this is. If it is an informal issue, we can simply record it in the daily log, however
if it is something that requires a more formal approach it gets recorded in the issue register.

The next step is to Examine the issue and consider what impact it will have on the project. The
project manager could seek advice from the project board or may require a technical expert to
examine the full implications of the issue. The issue register and report are updated for findings.

Then the project manager needs to identify and weigh up what options are available and propose
a course of action. If the issue causes an exception this will entail creating an exception report
for the project board. The right person then needs to decide on what to do.
Who makes the decision depends upon the circumstances. For example, if the issue is a ‘request
for change’ or an ‘off specification’ the decision is made by the change authority, whoever that
is. By default, the project board are the change authority, but of course this role may have been
delegated to anyone, including the project manager, or there could even be a designated change
board. The change authority could decide to approve a request for change, reject or even defer
it for later, perhaps a future project. If it is an off-spec the decision could be to grant a concession
and live with the product as it.

If the issue is a general problem or concern it will come down to tolerances. If the problem is
within stage tolerance the project manager can make the decision, otherwise it will have been
escalated via an exception report. Then the project board must refer the decision even higher.

Once a decision has been made the project manager needs to ensure that the right actions are
taken, which could be amending product descriptions to reflect the change or even creating an
exception plan.

To ensure that a project has effective issue and change control this procedure is documented in
the project’s configuration management strategy and applied in the controlling a stage process.
Lecture 4 – Issue & Change Control Documentation.

The daily log is used to record and monitor informal issues. For issues we are managing formally
we add and entry into the issue register and start an issue report, the purpose is shown above.

The reason we have two different documents is that whilst the register provides a summary of
all issues and their history, it’s not a good place to document full details of the impact assessment
and recommendations. Those deciding on a particular issue will want full information about that
issue and don’t need to see the whole summary information of the project. The information on
the two documents will need to be consistent and kept in line.

So, when the issue is Examined the register and particularly the issue report will be updated with
information on the analysis.
As the project manager weighs up the options, again the documents get updated. The project
manager’s recommendation is added to the report. If the issue puts the project or stage in
exception it is time to create an exception report. The purpose is shown above.

This does not repeat the information in the issue report but adds to it. It explains the
consequences of the exception, explains what options are available, the effect of each option
and makes a recommendation of how to proceed.

Using the issue report and/or the exception report the right person will decide. As we have said,
who this is will depend upon the circumstances of the issue.

Once the decision has been made then the project manager implements the decision. This will
entail updating the issue register and report. If the board have requested one, the project
manager needs to create and exception plan and potentially amend or create work packages.
The purpose of work packages are covered in the CS and MP module and exception plans where
covered in the plans theme.
Lecture 5 – Configuration Management.

Configuration Managements is fundamentally about taking care of the assets of your project.
Changes to one product can affect other products on your project. If you think of your project as
a Jigsaw and if one piece, or product, in the middle of the jigsaw changes it can affect others.

Typical activities for managing configuration are:

 Planning – What level of control is required?

 Identification – Ensuring sub-products / components can be uniquely identified / tracked/
recalled.
 Control – Who authorizes change? Where will products be stored & keeping them secure/
who can access?
 Status Accounting – Reporting.
 Verification & Audit – Is it working well?

If we take the example of a project to design and build a new type of car. The parts of the car are
things that the project will need track. They are called configuration items.

Information about them is contained in Configuration Item Records (or CIRs), one for each
product that needs to be tracked. The CIR’s hold information such as the version number, status
of items, any variants such as languages, and details of important relationships between items.

Definition – Configuration Item Record (CIR): A record that describes the status, version and
variant of a configuration item, and any details of important relationships between them.

The collection of configuration items is known as a Configuration Library, it’s kind of a database.

This data can then be used to produce reports called Product Status Accounts. A report could be
produced for all the products of a project, sub-set of them, perhaps those being produced in a
management stage, or even in a single product, perhaps if the project manager is concerned
about something. So, a product status account report could be scheduled for the end of a stage,
or they can be produced on an ad-hoc basis.

Definition – Product Status Account: A record of the status of products. The required products
can be specified by identifier or the part of the project in which they were developed.
Lecture 6 – Change Theme Minimum Requirements.

Although several different management products can be used in managing change, Prince2
mandates the use of just 2.

The project must have a Change Control Approach which states how, when, and by whom, the
project’s products will be controlled and protected. It answers fundamental questions such as:

 How and where products will be stored.

 What storage & retrieval security will be established.
 How products, versions and variants will be controlled.
 Detail responsibility for change control.

Prince2 also requires some form of Issue Register is used.

Prince2 does recommend an approach to managing issues, it isn’t prescriptive about it.
Lecture 7 – Change Theme Responsibilities.

Shown here are some of the key responsibilities and summary for this theme:
 Chapter 11 – CS & MP Processes.

Lecture 1 – Purpose of CS & MP.

The two processes of Controlling A Stage (CS) and Managing Product Delivery (MP) cover the
day to day work of the project manager and team manager roles, and the important interactions
between them. They help us control the project when it is up and running.

Controlling A Stage, covers the project manager’s work, which is essentially about assigning work
to team managers, or team members, checking up on what is going on with the teams, keeping
the project board regularly updated regarding progress and handling problems that may occur
potentially by taking corrective action. All the while with a focus on trying to deliver within any
stage tolerances.

Managing Product Delivery covers team managers’ work and focuses on controlling the link
between the team manager and the project manager. Bear in mind that team managers work for
suppliers, who may be external organizations so thought needs to be given to the formality over
which this happens.
Lecture 2 – Controlling a Stage Normal Process.

The controlling a stage process is triggered by the project board authorizing either a stage or
exception plan, and although at first glance this diagram looks complicated, we can easily break
it down into two different aspects.

Firstly, let’s take problems aside and consider what we could call Normal Progress.

The first thing that needs to be done is to get the teams working, so the first activity is the project
manager writing and authorizing work packages. Work by the teams does not start until the
project manager authorizes it.

The definition and purpose of work packages is shown here:

Definition: The set of information relevant to the creating on one or more products. It will contain
a description of the work, the products description, details of any constraints on production, and
confirmation of the agreement between the project manager and the person or team manager
who is to implement the work package that the work can be done within the constraints.

Purpose: A set of information about one or more required products collated by the project
manager to pass responsibility for work or delivery formally to a team manager or member.
It is the key source of information for the team manager and will incorporate the product
description that relate to the work package. It is an important management product and will
contain things like how the team manager report progress should, escalate problems, and tell
the project manager when the work is complete. On a larger project with many teams there will
be several work packages in progress at any one time.

The project manager will need to Review the Work Package Status as each work package is in
progress. This entails receiving and reviewing checkpoint reports and the quality register,
updating the stage plan and if necessary, risk and issue registers.

When a work package is completed the project manager will need to receive it, checking
everything is as it should be, including the status in the configuration item records and update
the stage plan.

Reviewing the stage status is a continual activity for the project manager. It is essentially deciding
what they need to do next based on an accurate and current picture of what’s going on. It entails
reviewing any of the project documentation and as a result doing things like authorizing a new
work package, identifying that the project manager is no longer within authority and needs to
escalate, or simply it’s time to move on to managing a stage to plan the next stage or closing a
project process.

Reporting Highlights will happen at the frequency defined in the controls section of the PID.
Therefore, this frequency will have been agreed by the board.

The purpose of a highlight reports is shown here:

Purpose: Provide the project board and other stakeholders with a summary of the management
stage status at intervals defined by them. The project board uses the report to monitor
management stage and project progress. The project manager also uses it to advise the project
board of areas where the project board could help.

Highlight reports provide the project board, and possibly other stakeholders, with regular
progress information.
Lecture 3 – Controlling a Stage Handling Problems.

The rest of controlling a stage process focuses on handling problems. As we know, in Pince2
problems are called issues and potential problems are called risks.

When a new issue is first notified it needs to be documented. In the change theme we explained
the choice, informal issues go in the daily log, but issues requiring a formal approach go in the
issue register and an issue report is started. If a new risk is raised it is recorded in the risk register
and this has been described in detail in the risk theme section.

The project manager then needs to use the Review Stage Status activity to ascertain what should
be done considering the new issue or risk. If necessary, they could refer to the project board for
advice. If the issue is a request for change or off-spec and the project manager has been assigned
the change authority role they can handle it providing the issue doesn’t breach any agreed limits.
Being within authority also includes a problem that doesn’t breach tolerances.
So, if the project manager is within their limits of authority, they should take corrective action.
Taking corrective action would include updating project documentation, such as a work package,
the stage plan and project registers.

If the project manager is not within authority, they will need to escalate the situation. Again,
project documents would have to be updated. We have already covered the issue and change
control procedure in the change theme section, but as a recap. If it is a request for change or off-
spec it goes to the change authority, who may be the project board, a panel for people, or even
the project manager, and the issue report is used to aid decision making. If the situation is a
forecast threat to tolerance an Exception report is also required.

Here is a quick recap of the purpose of that:

Purpose: Produced when a stage plan or project plan is forecast to exceed tolerance levels set. It
is prepared by the project manager to inform the project board of the situation, and to offer
options and a recommendation for the way to proceed.

Exception reports prepared by the project manager to inform the project board, and possibly
corporate or programme management, of the exception situation. It does not duplicate
information in the issue report but add to it by offering options and a recommendation for a way
forward. It may take some time to compile an exception report so it may be pragmatic for the
project manager to alert the project board to the situation quickly while the report is created.
Lecture 4 – Managing Product Delivery.

One of the first things to bear in mind is that team managers work for suppliers, who may be an
external organization and may not be using Prince2. This process therefore needs to be simple,
and it is. It’s agreeing the work to be done, doing it and handling it back to the project manager.

The first activity Accept a Work Package is where the team manager understands and agrees
what must be delivered; understanding any constrains is carrying out the work and the project
manager’s reporting requirements. The team manager needs to make sure that the requirements
are reasonable, and this is where any work package tolerances are agreed. The team manager
then produces a team plan if they need one.

Execute a Work Package covers not only creating the specialist products, but also obtaining
approval for completed products, updating the quality register regarding test results, notifying
the project manager of any new risks or issues that may arise, and creating checkpoint reports.

Checkpoint Reports are provided at the frequency defined in the work package to update the
project manager regarding the status of the work package.

Finally, when all the products associated with the work package are completed and approved the
team manager needs to deliver a work package.

Deliver a Work Package entails reviewing the quality register and maybe approval records to
check everything is done before following any notification procedures in the work package to
inform the project manager that it is complete. Exactly how this is done will of course depend
upon what the products are.
Lecture 5 – CS & MP Summary.

This slide summarizes the CS and MP processes.

The formality with which this occurs will depend upon the circumstances. If the suppliers are
external suppliers, it is likely to be quite formal.

Key principles that are being supported here are Manage by Exception because this is where
issues are identified that may become exceptions that need escalation.

Of course, also Manage by Stage and Focus on Products because this is delivering a stage with
the specialist products being created and approved in accordance with their product
descriptions.
 Chapter 12 – Quality Theme.

Lecture 1 – Purpose of Quality Theme.

Quality can be quite an emotive subject, and the term itself has certain connotations. Often, we
think of quality as being high end, even luxury goods and services. This I not what the Prince2
Quality Theme is about.

In Prince2 quality is about making sure that the project delivers products that are fit for purpose
whatever that is. So, first we need to understand what fit for purpose looks like.

Over-build can be just as bad on a project as under-build. If we overbuild say by delivering a Rolls
Royce when the budget requires a basic car then we will probably blow the business case.
However, delivering products that are sub-standard may mean that benefits might not be
realized or worse still; the products might not be even useable.

Furthermore, it is not good being so focused on meeting deadline to the extent that quality is
overlooked. Delivering something of sub-standard quality can have serious repercussions on an
organization’s reputation.

We will see that quality is certainly not an after-though in Prince2.

The Prince2 approach to quality ensures that:

 Products meet expectations.

 Enables benefits to be achieved.
Lecture 2 – Quality Management Systems.

A Quality Management System is an approach to quality that applies to a whole organization.

Different organizations have different quality management systems. Probably the most widely
recognized are the ISO standards.

When an organization embarks on a project any external suppliers to that project could well have
quality management systems in place that differ from those of the customer organization.

Regardless of whatever different quality management systems are in use across a whole project
there should only be one project Quality Management Strategy. This strategy must therefore
cater for any differences in varying quality management systems.
Lecture 3 – The Quality Assurance Role.

It is important to understand the quality assurance role and how it might impact your projects.

Quality Assurance is an organization-wide role that establishes the organization’s quality

management standards and systems; and assesses if they are being met. This role is outside of,
or independent of the organization’s projects and reports to corporate management. Quality
assurance is the responsibility of corporate management.

The quality assurance role should not be confused with project assurance. As we know, the
project assurance role is part of the project management team. Project assurance is the
responsibility of the project board and the board may even undertake the role themselves. If they
don’t the role reports to the project board.

Whilst project assurance must be independent of the project manager and the project team
because they are checking the work, they are certainly not independent of the project.

Although quality assurance is independent of the whole project, they will have an interest in the
project. They will want assurance that the project is abiding by whatever standards are in place
and may even require that project assurance is in place.
Lecture 4 – Quality Planning and Quality Control.

Managing quality on a project entails both planning and doing.

Firstly, Planning which is largely within the project manager’s domain.

The project manager needs to ensure that the required quality levels are understood and
documented, with input from the users. So, this includes writing the project product description
and lower level product descriptions, both of which were covered in detail in the plans theme.

The project manager also needs to set up the quality management approach, which is used to
define the quality techniques and standards to be applied for the project.

The purpose of this document is shown here:

Purpose: Describes how quality will be managed. This includes the specific processes,
procedures, techniques, standards, and responsibilities to be applied.
Quality planning also entails the project manager setting up the quality register.

The purpose of that is shown here:

Purpose: A quality register is used to summarize all the quality management activities that are
planned to have taken place.

Its purpose is to:

 Issue a unique reference for each quality.

 Activity.
 Act as a pointer to the quality records for a product.
 Act as a summary of the number and type of quality activities undertaken.

The quality register will show a summary of all the quality tests and activities undertaken on the
project. It is likely to be a table or a spreadsheet, and each test will have its own entry so if a
product is tested twice it will appear here twice. It is very useful for compiling reports.

Quality Control will involve both team managers and the project manager. It entails carrying out
whatever quality methods have been specified.

The lower level are individually approved and any approval documents, possibly even certificates,
are retained and filed. During product approval the quality register will be updated with the date
and results of the quality activity, and who carried it out.

At the very end of the project, the project manager obtains acceptance for the overall project’s
product from the senior user’s and the project’s executive.
Lecture 5 – Quality Audit Trail.

Quality is not an afterthought in Prince2. The Quality Audit Trail shows how quality in integrated
into the project lifecycle and the processes.

First, in the SU process, key quality information provided by the customer is recorded in the
project product description. Because customer’s quality expectations are often expressed in
vague terms, they are refined into more specific acceptance criteria. The definitions are shown
below, and it is important to understand the difference between these two as it is often tested
in exams. So, CQE’s are initial vague statements and acceptance criteria must be clear.

Definition – Customer Quality Expectations: A statement about the quality expected from the
project’s products, captured in the project product description.

Definition – Acceptance Criteria: A prioritized list of criteria that the project product must need
before the customer will accept it, i.e. measurable definitions of the attributes required for the
set of products to be acceptable to key stakeholders.
Then, in the IP process, the project manager documents the project’s response by creating the
quality management approach, whilst also creating the project plan and many of the lower level
product descriptions. Each product description will have its own Quality Criteria and tolerances,
with methods for checking against them which may involve different people. If we take the
example of a car, the quality components for the engine of the car will be very different from
those required for something like the car’s dashboard or the car seats.

Definition – Quality Criteria: A description of the quality specification that the product must
meet, and the quality measurements applied by those inspecting the finished product.

When stage plans are created during the SB process more work is done on product descriptions.
It may be that some product descriptions were not even created during IP, or that some were
started but require more detail to be added before work can commence. The project product
description and lower level descriptions is covered by the Product Based Planning Technique.

Finally, as part of quality planning the project manager sets up the quality register and ensures
that there is a starter entry in the register for each product identified.

Then we mover into quality control. As specialist products are created in the MP process each
product is quality checked by the method specified during planning. The team manager
assembles any quality documentation and the quality register is updated with the specific results
and the documents are filed away. So, the quality register falls into both quality planning and
quality control.

Finally, in the CP process, the project manager obtains formal acceptance against the acceptance
criteria as detailed in the project product description. The diagram shows how to get approval
product by product and acceptance at the very end. It also summarizes what quality planning
entails versus quality control.
Lecture 6 – Quality Theme Minimum Requirements.

Key Message: Prine2 does not prescribe a, detailed, approach to quality management. Any
approach that meets the requirements below can be said to be following Prince2.
Lecture 7 – Quality Theme Responsibilities.

Shown here are some of the key responsibilities for this theme.

To summarize what we have covered in this theme, here are some of the key concepts such as
the Quality Management Systems apply to the quality approach for a whole organization, and
the different organizations involved on a project may have different quality management.
Quality Planning is about thinking ahead and defining things like Customer Quality Expectations
which may be a bit vague, and the more tightly defined and measurable acceptance criteria.
Quality Control is about carrying out the quality activities that have been planned and gathering
approval and acceptance records.

Don’t confuse quality assurance with project assurance role. Quality assurance relates to quality
activities for a whole organization, whereas project assurance is about checking that the project
is being run properly. We have seen that quality is really embedded in Prince2, the quality audit
trail provides a great summary of how it works, and of course product based planning and use of
product descriptions.
 Chapter 13 – DP, SB & CP Processes.

Lecture 1 – Introducing SB, DP & CP Processes.

In this section we cover the remaining processes in detail.

Managing a Stage Boundary (SB) will occur at the end of each management stage and in
exception situations. The process in project manager’s work, planning, re-considering the
business case and preparing information form project board decisions on progress.

Directing a Project (DP) process as we know covers project board work and is where the main
decisions are made. It starts at the end of the SU process and then runs for the whole duration.

Closing a Project (CP) is project manager’s work in preparing for closure. It is used to close the
project regardless of whether the project reaches its planned end.
Lecture 2 – SB Purpose & Activities.

As we have said the managing a stage boundary process I about the project manager collating
and providing the project board with good quality information to decide on progress and if they
want to continue investing in the project.

Purpose: To enable the project manager to provide the project board with sufficient information
to be able to:

 Review the success of the current stage.

 Approve the next stage plan.
 Review updated project plan.
 Confirm continued business justification and acceptability of the risk.

Note that this process is not the stage boundary itself, or where the decision is made because
that happens in the directing a project process.

The activities in this process look like this:

There are essentially two different ways to use this process. As we have said, one way is close to
the end of a management stage when there is more work on the project to come, another stage.
As this could be either at the end of the initiation stage, or a delivery stage the triggers come
from the IP or CS processes. Managing a stage boundary is not used at the end of the final
management stage because closing a project process will be used instead.

The other way to use this process is an exception situation when the project board ask the project
manager for an exception plan.

Once a stage or exception plan has been created the rest of the activities are followed keeping
the documentations up to date, re-considering the business case, and creating exception reports.
Lecture 3 – SB End of Stage.

We will first look at the activities when the process is used at regular stage end.

As we have said, triggered by either the IP or CS Process, the first thing to be done is to plan the
next stage. To do this the project manager looks back to the project plan to see what was planned
at a high level and adds detail by creating a new stage plan. This may entail creating new product
descriptions or refining some already drafted, and make sure that all products to be created in
the next stage are recorded in the quality register for testing and the quality activities are put in
the plan. As this is looking ahead, it is a key time to identify any changes to the project team.

Next the project manager needs to update the project plan. As the project plan is the complete
picture of the project it is important to keep it up to date and in-line with what is happening. It is
updated with two things. Firstly, the Actuals regarding time and cost from the stage plan just
completed and any Revised Forecasts from the new stage plan.
Then the project manager can update the business case if there are any changes to things like
costs and benefit timescales. When considering the business case, it is important to also look at
the risk profile to make sure it’s still acceptable. The Benefits Review Approach may also be
updated if there are any changes to expected benefits or benefit reviews to be conducted during
the next stage that need adding.

Of course, if changes are made to the project plan and business case this would in turn be
updating the PID as they are part of it.

Finally, the project manager creates an End Stage Report. A product status account will provide
current information on the status of products for the stage that is finishing if you a configuration
management system. The purpose of the end stage report is shown here:

Purpose: Gives a summary of progress to date, the overall project situation, and sufficient
information to ask for a project board decision on what to do next.

It provides a summary of progress to date, the overall project situation and the project manager’s
forecast. The project board will use the report in the DP process, in tandem with the next stage
plan to decide on what to do next.

The end stage report may include a lessons report, drawing on information in the lessons log. A
lessons report is designed to provoke action so that positive lessons can become embedded in
the organization’s way of working and negative lessons are hopefully avoided on future projects.

However, lessons reports can be created at any time. It is not necessary to wait for the end of a
stage or the project.
Lecture 4 – SB Exception Handling.

Now let’s look at using managing a stage boundary in an Exception Situation.

This time SB is triggered by the DP process and the project board’s request for an exception plan.
So, the first thing to do is create the Exception Plan. The project manager can use the original
stage plan as a start point and the exception report that has already been sent to the board.

Then the process follows the same path, the project plan is updated, and it is even more
important to reconsider the business case in the light of the exception.

Depending on the circumstances it may still be appropriate to create and end stage and pass on
lessons.

At the end of the process the project manager does not just start working on the new plan but
presents the exception plan and any revised project documents to the project board, triggering
the DP process.
Lecture 5 – DP Purpose and Overview.

Next, we come onto the DP Process, which covers all the project board’s work on the project.

This process is where the project board provides direction and makes the main decisions on the
project, so it enables them to be accountable for the success of the project.

Purpose: 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.

The process diagram is shown here, and you can see there are four different types of decisions
that get made and one further activity that covers everything the project board do.
Lecture 6 – DP Activities.

The first, or initial decision the board makes is to Authorize Initiation.

It is triggered by completion of the SU process and the project manager requesting to progress
to initiation. The board will look at the project brief and decide if the project is viable and
worthwhile and something, they want to use resources on.

They will also review and approve the stage plan for the initiation stage. This decision only
happens once on a project, and assuming the project board says yes it marks the Official Start of
the project. There may be a few stakeholders, including corporate or programme management
or the customer, that need to be informed, so a formal initiation notification might be issued.

This decision will trigger the project manager to start the IP process.

The Second decision is for the board to Authorize a Project, so called because it entails
authorizing the PID which of course contains the project plan and now the detailed business case.
This is another activity that happens once on a project and again the project board are
considering if the project is viable and worthwhile.

It is also the first opportunity for the board to review and authorize the benefits review approach.
Once again, there may be a formal authorization notification to inform stakeholders, and
assuming the project is authorized it triggers the CS process and the project manager will start
authorizing work packages.
Of course, the board could decide not to authorize the project in which case the CP process is
triggered.

The next activity is to Authorize a Stage or Exception Plan, which will be used at the end of every
management stage except the final stage, to authorize a new stage plan and continued
investment in the project. In addition to the stage plan, the project board will receive an end
stage report to help inform their decision.

The activity is also used whenever an exception plan has been created and presented to the
board for authorization.

The PID, and any of its constituents’ parts may have been updated and need re-approval. When
progress is approved by the board, the project manager will continue with the CS process to
authorize more work.

Of course, the board may decide not to continue in which case the CP process will be invoked.

Apart from authorizing project closure the activity of Giving Ad Hoc Direction, covers everything
else the project board does. There are many potential triggers from the project manager
providing reporting regular Highlight Reports from the CS process to asking for some general
advice and guidance or even escalating an exception via an Exception Report.

As the project board are responsible for communicating with the corporate or programme
management or the customer, the activity could be triggered by a new issue from outside the
project that needs to be passed on to the project manager.

There are also many ways out of this activity. It could be that the project manager continues with
the CS process, or that the project board requests and exception plan triggering SB. The board
may be further escalating a project exception to corporate or programme management.

Finally, it could be that the board decide upon a premature closure that would trigger the CP
process. So, the project could be closed prematurely at any time, not just at a stage boundary.

The final activity in DP is to Authorize Project Closure. It is triggered at the end of the CP process
when the project manager hands over the end project report.

The board will want to understand what benefits, if any have been achieved at project closure,
and make sure that ownership of the benefits review approach is transferred to corporate or
programme management or the customer, to conduct the post-project benefit review.

Lessons will also need to be passed on to the corporate group responsible for any organizational
quality management systems. There may be quite a formal project closure notification to be
issued to appropriate stakeholders.
Lecture 7 – CP Purpose.

As we know, Prince2 is about running projects in a controlled way. The Closing a Project Process
ensures that projects are brought to a tidy close, that work is not just abandoned or that the
project doesn’t drift into BAU.

The process ensure that acceptance for the final deliverable is confirmed and the project is
reviewed against the original objectives.

Purpose: To provide a fixed point at which acceptance for the project is confirmed and to
recognize that objectives set out in the original PID have been achieved (or approved changes to
the objectives have been achieved), or that the project has nothing more to contribute.

The activities are shown here:

Remember, there are also two different circumstances in which the process is used.

Firstly, if the project reaches its planned end.

The other way is if the board have asked for a premature close.

There are five activities in the process. Two of them relate to how the process has been triggered
so depending on the circumstances, only one of them will be used. Then the remaining three
activities are used in either circumstance.
Lecture 8 – CP Normal Closure Activities.

First, we will look at what happens when the project reaches its planned end.

The first thing to note is that the activities for a planned closure should have been included in the
stage plan for the final stage. This plan was created in the SB process in the penultimate stage.

In the first activity the project manager needs to ensure that the expected results have been
achieved. A product status account will help check that all products are completed, and the
project plan is updated with the final actuals so there is clarity regarding how much time and
resources have been used. The project product description is used to check that the results meet
the acceptance criteria. If everything is done, then the project manager can seek approval to
release those who have been working on the project for other work.
Then the final completed products need to be handed over. The change control approach is an
input as it should contain information about handover procedures and responsibilities. If there is
any associated work that needs to be done post-project then a list of Follow on Action
Recommendations is drawn up, which may include items from the issue, risk register or the daily
log. We check for or create any necessary acceptance records and the benefits management
approach is updated regarding how and when to measure the expected post-project benefits
that are yet to be realized. We will not wait for all the benefits to be realized before closing the
project because that could take some time. The configuration item records can be updated to
reflect the status of the products; that they have been handed over.

Evaluating the project entails the project manager creating an end project report. To do this we
look back to the PID v1 because that will refresh us regarding the original project objectives and
then we can explain any changes that have happened along the way. A final lessons report is
incorporated at the end project report. The purpose of this is to encourage continual
improvement in project management in the organization.

Finally, the project manager creates draft closure notification for the board to approve and issue.
This can be quite a formal document, especially if there are many external stakeholders to be
informed or even members of the public. External suppliers will need to know if there is a cost
code that will be closing to get their invoices in on time. The communication management
approach is an input to ensure that no stakeholders will be overlooked in this communication.

Then the project files and registers can be closed and archived away.

At the end the project manager send everything to the board, triggering the final decision,
authorizing closure, in the DP process.
Lecture 9 – CP Premature Closure Activities.

Now let’s look at a premature closure.

As we know, this is triggered by the project board requesting a premature closure. Such a decision
does not have to come from corporate management or programme management.

Instead of preparing a planned closure the first activity in this scenario is to prepare a premature
closure. Again, a product status account will be useful to identify what products are complete
and what aren’t. Often it isn’t possible, or advisable, to just abandon all work and walk away.
Sometimes it might be necessary to make things safe or good, or it might be that for a little extra
effort something can be salvaged from the project, so the project manager identifies any
additional work estimates. This is in effect the plan for the premature closure. The project plan
should still be updated with how much time and money was used and resources will be released
when any additional work is complete. Then the other activities are conducted as before.

The project needs to handover to the customer, or a live environment whatever can be used. The
change control approach will detail information for this. Any associated follow on actions and
post project benefit reviews should still be documented if there are some benefits still expected.

The project should still be evaluated, looking back to the original PID, and lessons passed on. Not
forgetting to update the issue register with details of the issue that caused the closure.

Finally, the project manager drafts the closure notification, again making sure that it will go to
the relevant stakeholders detailed in the communication management approach. As before, it is
the board who authorize closure in the DP process.
Lecture 10 – CP Premature Closure Activities.

It shouldn’t be a surprise that all the principles are supported during processes.

Key principles are shown here:

 Continued Business Justification – The business case is reconsidered at each stage end.
 Learn from Experience – Lessons reports are typically created at stage and project end.
 Manage by Stages – Because SB is about reviewing the stage that is finishing and planning
the next stage and progress to a stage is authorized in the DP process.
 Manage by Exception – Because exception plans are created during the SB process and
stage and project exceptions must go to the board.

The key documents created and used during these processes are the End Stage and End Project
Reports.

The purpose of both is shown here:

So, the end stage report is used for decision making while the project is still in progress, and the
end project report is used at the very end to analyze how the project performed.

They are both likely to include lessons reports, the purpose is which is shown here: