PRINCE2 Foundation Guide - Sample - by Frank Turley

PRINCE2®
Foundation
Booklet
By Frank Turley
PRINCE2 Foundation course booklet
Ver 0.5e

PRINCE2®
2017 Foundation Booklet ii
PT0079
Colophon
Title: PRINCE2®
Foundation Booklet
Authors: Frank Turley
Expert reviewers: Nader K. Rad, Eralp Tezcan, Rouzbeh Kotobzadeh
Edition: First edition, first impression, December 2017
Copyright: © Professional Training Centre of Excellence N.V. (PTCoE)
ITIL®, PRINCE2®, PRINCE2 Agile®, MSP®, M_o_R®, P3O®, MoP® and MoV® are registered
trademarks of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved.
The Swirl logo is a trade mark of AXELOS Limited, used under permission of AXELOS Limited.
All rights reserved.
Although this publication has been composed with most care, neither Author nor
Editor nor Publisher can accept any liability for damage caused by possible errors and/or
incompleteness in this publication.
Thank you for reading this PRINCE2 Foundation Booklet. The main objective of this booklet is to
provide an easy-to-read overview of the PRINCE2 Foundation online training. This booklet should
not be used on its own, it is just meat to provide a summary of PRINCE2 and supports the
PRINCE2 online and classroom training.
PT0079

PRINCE2®
2017 Foundation Booklet iii
PT0079
Table of Contents
1 Introduction – PRINCE2........................................................................................................1
2 PRINCE2 and project management......................................................................................3
2.1 Five characteristics of a project.................................................................................3
2.2 PRINCE2 project variables........................................................................................3
2.3 Projects in context .....................................................................................................4
2.4 Projects in a commercial environment ......................................................................4
2.5 PRINCE2 Foundation exam and syllabus.................................................................5
2.6 What you need to know............................................................................................. 5
3 Principles............................................................................................................................... 6
4 Themes introduction..............................................................................................................9
4.1 Introduction to themes............................................................................................... 9
4.2 List of themes ............................................................................................................9
5 Business case theme ..........................................................................................................10
5.1 Introduction..............................................................................................................10
5.2 Output, outcomes, and benefits ..............................................................................10
5.3 Minimum requirements for the business case ........................................................ 10
5.4 The business case path .......................................................................................... 12
5.5 Business case example:.......................................................................................... 14
5.6 Roles and responsibilities........................................................................................ 14
5.7 What you need to know........................................................................................... 14
6 Organization........................................................................................................................ 15
6.1 Introduction..............................................................................................................15
6.2 Three project interests / three stakeholder categories............................................15
6.3 The four levels of a project organization .................................................................16
6.4 PRINCE2 minimum requirements for organization.................................................17
6.5 Project roles and responsibilities.............................................................................17
6.6 The communication management approach (CMA) document .............................. 20
7 Quality .................................................................................................................................22
7.1 The quality knowledge provided by PRINCE2 ........................................................ 22
7.2 Quality definitions ....................................................................................................22
7.3 Introduction to the PRINCE2 approach to quality ...................................................22
7.4 Part 1: Quality planning introduction .......................................................................23
7.5 Part 2: Quality control.............................................................................................. 24

PRINCE2®
2017 Foundation Booklet iv
PT0079
7.6 Quality documents...................................................................................................24
7.7 PRINCE2 minimum requirements for quality .......................................................... 26
7.8 Project assurance vs quality assurance..................................................................26
8 Plans....................................................................................................................................28
8.1 Introduction..............................................................................................................28
8.2 Plans definitions ......................................................................................................28
8.3 Three levels of a plan .............................................................................................. 28
8.4 Planning overview ...................................................................................................29
8.5 Exception plan – if out of tolerance .........................................................................30
8.6 Product-based planning steps.................................................................................30
8.7 Product-based planning steps 1 to 7.......................................................................31
8.8 Number and length of management stages............................................................ 32
8.9 Delivery steps vs management stages? .................................................................33
8.10 PRINCE2’s requirements for the plans theme ........................................................ 33
9 Risk Theme ......................................................................................................................... 35
9.1 Purpose of the risk theme .......................................................................................35
9.2 Risk definitions ........................................................................................................35
9.3 Risk management products.....................................................................................35
9.4 The recommended PRINCE2 risk management procedure ...................................36
9.5 Step 1: Identify.........................................................................................................36
9.6 Step 2: Assess risk..................................................................................................37
9.7 Step 3: Plan the responses .....................................................................................38
9.8 Step 4: Implement the responses ...........................................................................39
9.9 Step 5: Communicate.............................................................................................. 39
9.10 What is a risk budget?............................................................................................. 40
9.11 PRINCE2 requirements for risk management......................................................... 40
10 Change................................................................................................................................ 42
10.1 Purpose of the change theme .................................................................................42
10.2 Change definitions...................................................................................................42
10.3 Types of issues........................................................................................................42
10.4 The PRINCE2 approach to change.........................................................................43

PRINCE2®
2017 Foundation Booklet v
PT0079
10.5 How to prioritize issues and track severity.............................................................. 43
10.6 Change authority and change budget .....................................................................43
10.7 Management products used by the change theme.................................................43
10.8 Issue and change control procedure.......................................................................45
10.9 PRINCE2 minimum requirements for change control.............................................47
11 Progress .............................................................................................................................. 49
11.1 Purpose of the progress theme...............................................................................49
11.2 Progress definitions.................................................................................................49
11.3 PRINCE2 requirements for approach to progress ..................................................49
11.4 Types of control.......................................................................................................51
11.5 How does the project manager review progress?...................................................51
11.6 Raising exceptions ..................................................................................................53
11.7 Using stages to control the project..........................................................................53
12 Starting up a project ............................................................................................................54
12.1 Purpose of the SU process .....................................................................................54
12.2 Objectives of the SU process..................................................................................54
12.3 Project mandate ......................................................................................................54
12.4 SU activities.............................................................................................................54
12.5 SU input / output diagram........................................................................................ 55
13 Initiating a project ................................................................................................................57
13.1 Purpose of the IP process.......................................................................................57
13.2 Objectives of the IP process....................................................................................57
13.3 IP activities ..............................................................................................................57
13.4 IP inputs and outputs............................................................................................... 58
14 Directing a project ...............................................................................................................60
14.1 Purpose and objectives of directing a project ......................................................... 60
14.2 DP activities.............................................................................................................60
14.3 DP inputs and outputs............................................................................................. 60

PRINCE2®
2017 Foundation Booklet vi
PT0079
15 Controlling a stage ..............................................................................................................62
15.1 Purpose and objectives of controlling a stage ........................................................ 62
15.2 CS activities.............................................................................................................62
15.3 CS inputs and outputs............................................................................................. 63
16 Managing product delivery ..................................................................................................64
16.1 Purpose and objectives of the MP process............................................................. 64
16.2 Managing product delivery activities .......................................................................64
16.3 MP inputs / outputs..................................................................................................64
17 Managing a stage boundary................................................................................................ 66
17.1 Purpose and objectives........................................................................................... 66
17.2 SB activities.............................................................................................................66
17.1 SB inputs and outputs ............................................................................................. 66
18 Closing a project..................................................................................................................68
18.1 Purpose and objectives........................................................................................... 68
18.2 Closing a project activities.......................................................................................68
18.3 CP inputs and outputs............................................................................................. 68

PRINCE2® 2017 Foundation Booklet 1
Based on AXELOS PRINCE2® material. Reproduced under license from AXELOS. All rights reserved. Some material in this document has been sourced
from Managing Successful Projects with PRINCE2® 2017 Edition. No part of this document may be reproduced in any form without the written permission.
1 Introduction – PRINCE2
The PRINCE2 Foundation Booklet
The objective of this official PRINCE2 foundation booklet is to support the PRINCE2 online
foundation course and provide an overview of the PRINCE2 Foundation syllabus. The majority of
people will not need to use this booklet after watching the online training, but some people like to
have a blended approach to learning (watching, reading and quizzes).
What are projects?: Here are a definition from Wikipedia
A project is a unique series of actions designed to accomplish a unique goal within specific
time and cost limitations.
PRIINCE2 definition:
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.
• The word organization refers to the project team (people involved in the project)
• The word temporary refers to the fact that each project as a definite start and end date.
• The business case includes: reasons for the project, expected benefits, costs and time
What is PRINCE2?
PRINCE2 is a project management method that can be used for any project, from running a 1 day
event to interfering in the US elections to help elect an idiot ☺.
Benefits of using PRINCE2
There are numerous advantages to using PRINCE2 (like most methods).
1. Best practice: PRINCE2 has been around more than 40 years in many thousands of projects,
and it learns from these projects.
2. PRINCE2 can be used for all kinds of projects
3. PRINCE2 provides a structure for roles and accountability meaning that all should know what
is expected of them and what they can expect from others.
4. PRINCE2 is product-focused, meaning that products are well-defined before work begins.
5. PRINCE2 uses Management by Exception. This allows each layer to get on with their work and
only escalate if needed. More on this later.
6. PRINCE2 assess the viability of the project from a business case from start to finish.
PRINCE2 structure (elements)
PRINCE2 consists of 4 main parts, (also referred to as elements or integrated elements). These
elements are: Principles, Themes, Processes, and Tailoring.

Principles: Each project should consist of all 7 PRINCE2 principles
Themes: Themes are knowledge areas: e.g., business case, organization, quality…
Processes: Processes provide information on the activities that are carried out during the project and
by whom. There are seven processes
Project environment: All projects need to be tailored to suit the project environment.
What you need to know
• Recognize the PRINCE2 definition of a project
• List the 4 integrated PRINCE2 elements (integrated elements)
• Recognize the benefits of using PRINCE2 (and how wonderful you are to be studying it ☺)
You don’t need to be able to remember all the information in this book, you just need to be able to
recognize it in the multiple questions.
Principles
Procesess
Themes
Project environment

2 PRINCE2 and project management
2.1 Five characteristics of a project
Projects have a number of characteristics, which is how projects differ from business as usual or a
repeating process. You should be able to see these characteristics in all projects.
Change: Projects are a way to introduce change. Example: A new service
Temporary: A project should have a definite start and end.
Ongoing maintenance of a product is after the project
Cross-
Functional:
A project teams includes people from different silos (departments) and level
of seniority that work together for the duration of the project.
Unique: All projects are unique as there is always something in the project that has
not been done before.
Uncertainty: As parts of the project are unique, you can never 100% sure how it is going
to work out useless you have a crystal ball.
2.2 PRINCE2 project variables
The two most common variables to control in a project are time and cost. There are 6 variables
(performance targets) to control in a project and these are: Timescales, Costs, Quality, Scope,
Benefits, and Risk. Also known as: 6 aspects of project performance.
Tip to remember them: Use TeCQuila SoBeR. This will give you Timescales, Costs, Quality, Scope,
Benefits, and Risk. Or you can use: “BC QRST.”
The above image shows a dial for each of the 6 performance targets, and the project manager will
keep monitoring these during the project. In fact, the PM can just present this diagram (project
cockpit) to anybody who wants to know how the project is going.
Time Cost Benefits
Scope Quality Risk
Project Cockpit

Timescales “When will the project be finished?”
Cost Projects need to give a return on investment and costs need to be controlled.
Quality Are products passing their quality checks and will users be able to use the project
product as expected when delivered
Scope Is the scope clear to all stakeholders? The first scope document is the PPD
Benefits Expected benefits must be known, agreed and measurable.
Risk All projects have risk, so risk needs to be managed so the project has a better
chance to succeed.
2.3 Projects in context
PRINCE2 assumes that each project will have a customer and a supplier.
- The customer specifies the desired result (requirements) and perhaps pay for and use the
business products delivered by the project.
- The supplier will provide resources, knowledge and skills to deliver the desired products.
The requests for projects come from somewhere outside the project. e.g.: 1) a programme, 2) upper
management (corporate), or 3) a customer. PRINCE2 refers to the level in the organization that
commissions a project as “corporate, programme management, or the customer” (CPC).
2.4 Projects in a commercial environment
Contracts between Customer / Supplier
Some projects can use a formal contract which will detail the customer’s requirements (product
descriptions) and what the supplier must deliver to satisfy the contract. This contract can include the
following information:
• Overview of the project approach (or product approach)
• How progress reporting will be done and frequency
• Roles and responsibility of the customer (customer must be involved)
• Procedure for dealing with change requests
• Procedure for reporting issues to the project manager
• How products will be tested and accepted and role of quality register, etc.
In larger projects, there may be many subcontract supplier and therefore many contracts.
• Contracts between the customer and all suppliers directly OR
• Between the customer and a prime supplier which will have contracts with all subcontractors
Each supplier may have their own way of viewing the project and they will have their own:
• reasons for doing the project (so their own business case)  
Portfolio
Projects
Projects
Standalone projects
Programme XY
Projects
Programme ERP

• procedures for running projects (they don’t have to use PRINCE2)
• procedures for making decisions (governance) and organization structure  
• project management culture (e.g., behaviors, cultures, risk appetite)  
2.5 PRINCE2 Foundation exam and syllabus
Here is some information on the PRINCE2 Foundation exam: (tiny.cc/P2F-exam)
Time: 1 hour (Extra time is available who have English as a 2nd
language)
Questions: 60 questions
Type: Multiple choice (A, B, C, D)
Pass Rate: 55% pass mark (33 questions)
The PRINCE2 Foundation level aims to measure whether a candidate can participate in a PRINCE2
project. Therefore, the candidate must show they understand the following:
• The seven PRINCE2 principles and how they are applied
• The characteristics and context of a project and the benefits of using PRINCE2
• The purpose of the PRINCE2 roles, management products, and themes
• The purpose, objectives, and context of the seven PRINCE2 processes
2.6 What you need to know
• Recognize the 5 characteristics of a typical project and understand them
• Recognize the 6 aspects of project performance (Tip: TeCQuila SoBeR or BC QRST)
• Recognize that PRINCE2 projects happen in a customer/supplier context
• Be aware of the type of information that may be included in a contract between a customer
and supplier. (eg: roles and responsibilities, reporting, acceptance procedure).
• Be aware that each supplier can have their own view on the project (their own business
case)

3 Principles
Introduction to principles
Each PRINCE2 project should include the 7 principles and you can also use the principles to do a
quick health check on your project e.g. 1) Does the project have a business case? 2) Is the project
learning from experience?
What is a principle? A principle is a core value that must always exist in a PRINCE2 project.
Continued business justification Must be a business reason for doing the project
Learn from experience Learn from other projects, people and stages
Define roles and responsibilities Everybody needs to know what is expected of them
Manage by stages Break projects up into stages (chunks)
Manage by exception Give people some tolerance to work within
Focus on products Create the product descriptions before starting work
Tailor to suit the project environment Make PRINCE2 fit your project size and type of
project. Use only parts of PRINCE2 that bring value.
Principle: Continued business justification
A PRINCE2 project must have business justification; therefore, each project should have a business
case that shows that the project is value for money. So there must be a business reason to start and
continue with a project and there must be a clear Return on Investment.
“Does the project have business justification?” = “Does the project have a valid business case?”
If at any time during the project, the expected Return on Investment falls (for example, by about
80%), then the project will most likely be stopped.
The business case document details the full business case, showing why the project should be done,
the costs, the expected benefits, and timescales. This information is also referred to as the business
justification information. The business justification is checked throughout the lifetime of the project.
E.g., at the end of each stage.
Principle: Learn from experience
PRINCE2 projects should learn from previous projects and should take the necessary initiative to
uncover lessons from previous projects and experience and take these into. It is the responsibility of
everyone involved with the project to seek lessons and the PM should remind everyone.
Projects are unique, meaning that there is always something new and therefore all project can learn
from other people. “Learn from experience” covers the full lifetime of the project, from the SU to the
CP process. All lessons learned during the project should be documented and these should be
passed on so they are available for future projects. The project board should also ask for proof that
the project is learning from lessons.
Principle: Defined roles and responsibilities
In any project, people need to know what is expected from them and what they can expect from
others. A PRINCE2 project should have defined and agreed roles and responsibilities. Each project
should have a clear team structure and this needs to be known and accepted.
A PRINCE2 project has 3 primary stakeholders:
Business sponsors: They mace sure that the project delivers value for money (Executive)

Users: They will use the project products and receive the benefits.
Suppliers: They provide the resources and expertise to produce the products.
These 3 primary stakeholders must be represented in the project management team description and
in the project board. So this principle answers the questions “What is expected of me?”, “What can I
expect from others?” and “Who makes what decisions?”
Principle: Manage by stages
How do you eat an elephant? one bite at a time (this is just an expression). How do you do a large
project? one stage (chunk) at a time. PRINCE2 refers to these chunks as stages (management
stages). A PRINCE2 project should be planned, monitored, and controlled on a stage-by-stage basis
and each stage is separated by a project board decision.
At the end of each stage, the project board should assesse the performance of the last stage by
reading the end project reports and checking the business case and stage plan for the next stage.
They will then decide to proceed to the next stage or stop the project.
If the project board wish to have more control over the project, the increase the number of stages so
they have more control points and more work. Some advantages of stages are:
1. Allow the project to be divided into pieces which are easier to manage
2. Have a very detailed stage plan and a high-level project plan for the whole project
3. Use lessons from previous stages in future stages
Principle: Manage by exception
Each layer (CPC, direction, management) wishes to manage the level below them but still give them
some room to work and make decisions and manage by exception is used for this. The layer below
gets on with their work and notifies the above layer if there is a big issue (exception) that is outside
their tolerance. So an Exception is a big issue that takes a level out of their agreed tolerance.
Imagine you are sitting on the project board and of all is going OK with the PM you will just get normal
reports. If the PM hits a big issue, then they will contact the project board immediately as this big
issue is an exception. The definition for Manage by Exception is: A PRINCE2 project has defined
tolerances for each project objective to establish limits of delegated authority.
PRINCE2 lists 6 tolerances that can be set. Time, Cost, Quality, Scope, Risk, and Benefits. Both
time and cost are easy to understand so I will just comment on the other four.
Tolerance quality: e.g. Power button on smartphone to work for 10 with a tolerance of ±5%.
Tolerance scope: Projects can use MoSCoW to decide on scope
Tolerance benefits: These are benefits for the project stakeholders.
Tolerance risk: Risks can be assigned values and can be escalated if > a certain value.
Mange by Exception provides the above management layer with a system to manage and control
the lower management layer.
Principle: Focus on products
If a product requirements are not correctly defined, then all project stakeholders can have a different
idea on what the product should be. This will cause a lot of issues during the project and most likely
produce an end product that cannot be used.
Detailed product descriptions of the products will help build correct expectations and make life easy
for the teams who deliver the products. A PRINCE2 project should focus on the definition and delivery
of products, in particular, their quality requirements.

A detailed product description also makes it easier for the team managers to determine resource
requirements, dependencies, and activities. The focus on products principle states that a product
description with quality requirements should be written as soon and as clearly as possible.
Principle: Tailoring or tailor to suit the project environment
No projects are 100% the same and each PRINCE2 project should be tailored to suit the project’s
size, environment, complexity, importance, capability, and risk.
The purpose of tailoring is to:
Ensure that the project method is project’s environment into account. (i.e., if working in a financial
environment, then align it with the existing management structure).
Ensure with the project board that the project’s controls are based on the project’s scale, complexity,
importance, capability, and risk.
What you need to know
Expect 2 to 3 questions on principles. So, make sure you have an understanding of each principle,
so that you will:
• Be able to recognize the principle names if mentioned
• Have a basic understanding of each principle
• Know how many principles each PRINCE2 project should have

4 Themes introduction
4.1 Introduction to themes
Themes are knowledge areas; they are the parts of the project that need to be continually addressed
throughout the project lifecycle. Each theme provides knowledge (how to go about) on a specific
area of project management, such as the business case, planning, quality, risk, etc.
Themes should also be tailored to suit the project and only use what is required to do the project.
This will of course depend on the project and the environment you are working in. For example, if
you are building a lunar module, then quality and risks themes would be used in detail.
The PRINCE2 processes address the flow of the project, in other words, the processes guide you
through the typical activities that you need to do to run a project.
4.2 List of themes
Theme Question Answered
Business case Why? ROI? Benefits?
Organization Who? Responsibilities?
Quality Level of quality for each product characteristic?
Plans How? How much? When? What (Product description)?
Risk What if X happens?
Change How to deal with changes requests and issues?
Progress Where are we now compared to the plan, show progress
Tailoring the themes
All 7 themes should be tailored according to the risk, scale, nature, complexity, or simplicity of the
project so. Each PRINCE2 theme specifies minimum requirements for each theme.
Note: Tailoring is covered in the PRINCE2 Practitioner syllabus so you don’t need to know much
(this is all) any more about tailoring the themes for the Foundation syllabus

5 Business case theme
5.1 Introduction
The business case theme provides information to help the project make better decisions regarding
the business case. The purpose of the business case theme is “to provide a structure to judge
whether the business case is desirable, viable, and achievable.”
• Desirable: Determine if the output is really required by the users
• Viable: Is it technically possible to deliver this product?
• Achievable: Is it possible to deliver the future benefits?
Business justification means that there should be valid business reason for doing the project and
this reason remains valid throughout the project. If the business case becomes, then the project
should be shut down. The business case is used to document the business justification.
5.2 Output, outcomes, and benefits
PRINCE2 introduces the terms: “Output, Outcome, and Benefits.” which help to describe what we
get from a project. I will use a question to help explain what these mean.
Output question What product that will be delivered by the project?
Outcome question What can the users do better when using this product (features)?
Benefits question What are the measurable improvements of using this product?
Output: These are the products that the users will use and why the project was started.
Outcome: An outcome is the result of the change derived from using the project's outputs. Outcomes
describe what users can do better; e.g., faster reporting or better-looking reports.
Benefits: Benefits are the measurable improvements resulting from an outcome that is perceived
as an advantage by one of the stakeholders.
Dis-benefit: A dis-benefit is an outcome that is seen as negative by one or more stakeholders.
• One admin person will lose their job due to the new sales system.
• 1% of clients may not like the new way of working and will stop their contract.
5.3 Minimum requirements for the business case
PRINCE2 has the following minimum requirements for the business case:
• Document the business justification (business case) for the project
• Keep the business justification updated during the project as the following may change:
o Desirability: Check if output is still required
o Viability: Check if still technically possible to create the output
Outputs
(aka Products)
Benefits
(and dis-benefits)
Outcomes
(aka Results)
Sales System
Easier to create reports
Quicker searchers
Easier to import data
30% reduction in sales costs
15% increase in sales
20% reduction in admin costs

o Achievability: Check if benefits are still possible to realize
• Define the follow up actions in the benefits approach document that will ensure the following:
o The project outcomes will be achieved (meet expectations)
o The benefits will be realized
• Define the business case roles and responsibilities and benefits management.
The two required business case released documents are:
1. Business case
2. Benefits management approach
The business case
The business case document contains the information to allow the management to judge if a project
is desirable, viable, and achievable. The business case is normally developed at the start of the
project (SU process) by the executive unless it is provided by corporate, programme, or customer.
Once created, it is then updated throughout the project.
The benefits management approach
The purpose of the benefits management approach is to define benefits actions and benefits reviews
that will take place to ensure that the project’s outcomes are achieved and to confirm that the project’s
benefits are realized.
The typical contents of a business management approach document are:
• Persons who are accountable for the expected benefits (e.g., senior user)
• The required actions to ensure that the project’s outcomes are achieved
• How to measure expected benefits (benefits must be measurable)
• Timeline of when benefits can be measured
• Resources that are needed to check benefits (e.g., a person from the finance department)
• Baseline measures from the start of the project so they can be compared in the future.
o e.g., support costs are €65,000
o e.g., average sales increase per year for 5 years: 4%
Business case: develop, maintain, and verify
The steps for creating and keeping the business case updated are:
1. Develop business case (SU & IP process)
o The outline business case is created in the starting up a project process
o This is expanded into the business case in the IP process
2. Maintain business case
o Keep the business case up to date (each SB process)
• Executive summary
• Reasons for the project
• Expected benefits & dis-benefits
• Timescale
• Costs
• Options (approach)
• Invest appraisal (ROI)
• Major risks
Business Case

3. Verify business case
o Check and verify that the business case makes good business sense
o The business case is verified throughout the project by the project board.
Confirm benefits
Confirm the benefits is checking that the intended benefits have been realized. Confirming benefits will
mostly happen after the project, but in some projects benefits may be realized during the project.  
5.4 The business case path
Pre-project: Project mandate
- The project brief may already contain some business case information
- E.g., if the project is triggered from a programme or portfolio
SU process: Outline business case
- The executive is responsible for creating the outline business case
- The project manager may provide the executive with assistance.
- This does not have to be a very detailed document (just an estimate).
IP process: business case
- The outline business case is expanded into a more detailed business case document.
- Some important inputs for the business case are:
1. The project time and costs estimates are taken from the project plan
2. A summary of the benefits from the benefits management approach (BMA)
IP process: benefits management approach (BMA)
- The project manager will document the benefits (plus current status) and the actions that
will be put in place that will help to ensure that benefits will be realized.
- The expected benefits information will be provided by the senior user.
- A summary of the expected benefits will be copied to the business case document.
Pre-Project Initiation Delivery Stages Final Stage
Verify outline
Business Case
Verify updated
Business Case
Maintain business case
Verify detailed
Business Case
Outline
Business Case
Business
Case
Develop business case
Business CaseBusiness Case
Updated in SB
Pre-Project Initiation Final Stage Post-Project
BMABMA BMA BMA
Confirm
Benefits
Delivery Stages
Create Benefits
Review Plan
Confirm
Benefits
If realized during the
project
Confirm
Benefits
If realized during the
project

SB process: Update the business case
- After each stage, the business case is updated to reflect changes. E.g.:
o The costs of the project may decrease or increase.
o The forecasted estimated time to complete the project may be lengthened.
- The project board will then review the business case at the end of each stage.
SB process: Update the benefits management approach
- Some products have already been made available to users, and then we can already check
if users are able to benefit from using the product so far.
CP process: Final update the business case
- We only know the true cost of a project at the end of the project.
- The business case at the end of the project can also be compared to business case at the
start of the project to judge the performance of the project.
CP process: Update the benefits management approach
- Some projects may deliver products during the project, so expected benefits can be realized
and these can be confirmed.
- The PM will also plan the benefits review meetings that will take place after the project is
complete and project board will check that this is done.
Project
Board
Project
Manager
SU
Outline
Business
Case
StagePlan
DP?
IP
Project Plan
Business Case
Benefits M.A.
Registers
StagePlan
SB
??
MP
CS
StagePlan
SB
End StageReport
Business Case
Project Plan
?
MP
SB
Business Case
Project Plan
Exception
Plan
Exception
Report
CS
?
CP
End Proj Report
Benefits M.A.
Business Case
Project Plan
?
Etc.Etc.
Benefits M.A
Benefits M.A

5.5 Business case example:
This example is from the sample PRINCE2 project: “U2 Driving School” See url: tiny.cc/U2-DS
5.6 Roles and responsibilities
Role Responsibilities
CPC • Project mandate is provided by CPC (contain reasons…)
• They are interested in the expected benefits
Project board • Verifies the business case (at each decision point)
Executive • Responsible for the business case and securing funding for the project
• Responsible for the benefits management approach
• Ensures the project is value for money and remains value for money
Senior user • Specifies the benefits and ensures the benefits will be realized
Project manager • Creates the business case and keeps it updated (maintains it)
• Examines the effect of issues and risks on the business case
• Keeps the benefits management approach up to date
• Recognize the purpose of the business case theme and the purpose of the business case
and benefits management approach
• Recognize the difference between an Output, Outcome & Benefit
• Describe the minimum requirements for the business case theme
• Describe what is meant by “maintain and develop the business case”
• Describe what is meant by “confirm the benefits”
• Be aware of the roles and responsibilities (mainly, PM, senior user and project board)
- Sales arefalling 4% each year
- CreatefreeonlineDriving Test Exam Simulator
- Increasesocial media exposure
- Need to increasesales
2. Reasons
- Increasesales by 10% for threeyears
- Increasesocial media posts by100%
4. Expected Benefits
- Do nothing: Andcontinueto loose4% each year
- Big marketing campaign: Toocostly
- Createonlinedriving test exam simulator*
3. Options
6. Costs
Other driving schools may dothesame
8. Major risks
- CreatefreeonlineDriving Test Exam Simulator
- Increasesales by 10% for threeyears
1. Executive Summary
Yearly Costs Year 1 Year 2 Year 3
Cost: Hosting & Software €420 €420 €420
WebsiteSetup (48 hours) €6,700 €0 €0
WebsiteSupport (yearly) €950 €950 €950
Total Costs €8,070 €1,370 €1,370
Project - ROI Year 1 Year 2 Year 3
10% increaseper month €1,512 €1,663 €1,829
10% increaseper year €18,144 €19,956 €21,948
Total costs per year €8,070 €1,370 €1,370
Expected Benefits €10,074 €18,586 €20,578
7. ROI / Investment appraisal
Business Case Date:Document: Author: Executive Jan 4th

6 Organization
6.1 Introduction
The purpose of the organization theme is to help define and establish the project's structure of
accountability and responsibilities. PRINCE2 states that a project is based on a customer/supplier
environment where one party is the customer, who will specify the results and most likely pay for the
project (and use the products), and the other party is the supplier, who will provide the resources, do
the work, and deliver the required products.
PRINCE2 states that a project team should:
1. Have correct business, user, and supplier representation
2. Have defined responsibilities for directing, managing, and delivering the project
3. Have regular reviews (end of each stage) of the project to check that all is on track
4. Have a good communication flow to and from stakeholders
So each project needs to have direction, management, control, and communication.
Stakeholder: A stakeholder is any person or group that can be affected by the project or can affect
the project. This includes the project team, potential users and other persons external to the project
as well as those who may be negatively affected.
Note: A stakeholder may be internal or external to the corporate organization.
6.2 Three project interests / three stakeholder categories
A PRINCE2 project has 3 primary categories of stakeholders (3 primary stakeholders) which should
also be represented in the project board. These are business, user, and supplier.
Business interests: The executive role on the project board looks after the business interests. There
must be a business case; otherwise, the project should not start. The executive should keep asking:
“Is this project value for money?”
User interests: Users must be represented in the project as they:
- benefit from the delivered products as they will use the products
- can also operate, maintain, or support the project outputs
The users help to describe their requirements and they are represented in the project board by the
senior user role which can be one or more persons.
Supplier interests: The supplier provides the skills and resources to create the products. The
supplier wishes to make sure they can deliver the products as requested and get paid.
User Supplier
Business

6.3 The four levels of a project organization
The PRINCE2 project management structure has 4 levels, and the project management team has 3
levels. The 4 levels of a project management structure / project organization are as follows:
The corporate, programme management, or customer (CPC) level sits above the project
management team. The 3 levels of the project management team are:
Level: Corporate, programme management, or customer
• This CPC level is responsible for commissioning the project and identifying the executive.
• The CPC decide the project tolerances that the project board will work within.
Directing level: Project board
They directing the project and are accountable for the success of the project. They,
1. Approve all project resources and plans, e.g., project plan, stage plans
2. Authorize any deviation if stage tolerances are forecast to or have exceeded
3. Approve the completion of each stage and authorize each new stage (after SB process)
4. Communicate with stakeholders outside the project which includes the CPC.
Managing level: Project manager (PM)
The PM is responsible for the day-to-day management of the project and to ensure that the project
produces the required products in accordance with the project objectives, which are time, cost,
quality, scope, risk, and benefits.
Delivery level: Team manager
The Team manager is responsible for delivering the project’s products at a certain quality and
within a specific timescale and cost. A team manager can have the authority and responsibility of
creating plans and managing a team to create and deliver the required products.
The process managing product delivery is where the teams produce the specialists' products.
Direction Level
Management Level
Delivery Level
Corporate, programme
management or customer
Project Board
(they make decisions)
Project Manager
(day to day runs the project)
Team Manager
(creates the products)
1
2
3
4
Direction Level
Management Level
Delivery Level
Project Board
(they make decisions)
Project Manager
(day to day runs the project)
Team Manager
(creates the products)
1
2
3

6.4 PRINCE2 minimum requirements for organization
A PRINCE2 project must do the following:
- define its organization structure
- define the PRINCE2 responsibilities (use the ones provided by PRINCE2)
- agree on the rules for delegating change authority responsibilities
- define approach to communicating and engaging with stakeholders
PRINCE2 requires that 2 organization related products (documents) are produced and maintained
and both these documents should be created during the initiating a project process:
- PID: The PID sets out the project management team structure and roles and includes
information on how the project is to be managed.
- Communication management approach (CMA): The CMA provides an overview of
all identified stakeholders and how the how and frequency of communication to these
internal and external stakeholders during the project. 
A project management team should have:
- business, user, and supplier representation
- governance overview (how decisions are made)
- project role review at the end of stage and take action if needed
- an approach to manage communication during the project (CMA)
6.5 Project roles and responsibilities
Project roles are documented in the PID (section: project management team) and this if first created in
the SU process.
Project board
The project board has three roles: executive, the senior user, and the senior supplier. Only one
person can be the executive while the senior user and senior supplier roles may be assigned to one
or more persons. The executive has the final word on decisions that are taken (no democracy)
The project board has the following duties:
1. Accountable for the success or failure of the project
2. Provide unified direction to the project and project manager
3. Provide the resources and authorize the funds for the project
4. Provide visible and sustained support for the project manager
5. Ensure effective communication within the project team and with external stakeholders
Delivery
Management
Direction
Senior
User
Executive
Senior
Supplier
Project
Manager
Optional Role
Team
Manager
P2FMT

The project board roles
The executive: is appointed by the CPC (first activity in the project). The executive is responsible
for the project and is supported by the senior user and senior supplier roles.
The executive is the single point of accountability for the project. Normally the executive will be
responsible for designing and appointing the project management team which includes the rest of
the project board and the project manager.
The executive is responsible for developing the business case during the SU process and they keep
asking “Is the project still value for money?” during the project.
The senior user: has the following responsibilities:
Specify the needs of the users that will use the project products
Liaise between the project and the users
Make sure the solution will meet the needs of the users (quality and ease of use)
Supply the benefits information for the benefits management approach (BMA)
The senior supplier: this role represents the interests of the persons designing, developing and
implementing the project’s products. The senior supplier role provides supplier resources to the
project and ensure that the right people, tools, equipment, and knowledge are in place, and that the
products meet the expected criteria, including quality criteria.
The senior suppler can come from the customer organization (e.g., purchasing manager) or they can
come from a supplier (e.g. account manager) and can be one or more persons.
Project assurance: user, business, and supplier
Business assurance (the executive) wishes to ensure that the business aspects of the project are
correct and that they have the correct financial and business information.
User assurance wish to ensure that the project will deliver the correct products and that these
products will meet the expected requirements. So they will be asking for proof of quality testing and
proof that products have been accepted. The senior user is responsible for user assurance.
Supplier assurance wish to ensure that the products will be delivered as expected and that the right
materials and people are in place to do the work. The senior supplier is responsible for supplier
assurance.
The project board can decide to do this assurance (business, user and supplier) or they can assign
these assurance tasks. Project assurance persons should support the project manager and make
them aware of standards which they should use in the project.
Delivery
Management
Direction
Senior
User
Executive
Senior
Supplier
Project
Manager
Optional Role
Project Assurance
Business Assurance
User Assurance
Supplier Assurance
Team
Manager

The change authority role
Change authority is a person or group decide on requests for change or off-specifications, and this
role is part of the PMT. The change authority may be given a change budget and can approve
changes within that budget.
Change authority may be delegated to a number of levels including (project board, project manager)
depending on the severity of the change. Different roles can have change authority responsibilities:
Severity - Change request Who decides?
Level 5 Corp / programme management
Level 4 Project board
Level 3 Change authority
Level 2 Project manager
Level 1 Project support / Help desk
?
If very few changes are expected, then the project board can do this. If many changes are expected,
then it is better to use a separate change authority group as this is more efficient and less time is
demanded from the project board, as they are busy people.
The project manager role
The project manager manages a project on a day-to-day basis and this role can never be shared.
They run the project on behalf of the project board within specified constraints.
The project manager normally (preferred by PRINCE2) comes from the customer. They are also
responsible for project support and team manager roles. In smaller projects the project manager can
manage the Team Members directly so there is no need for a team manager
Note: If there is no person of take on the project support tasks, then the project manager must do
them.
Team manager role
The role of the team manager is optional in a PRINCE2 project. This role can be used:
• If the project is large and there are many team members
• If there is a need for specialized skills or knowledge of the products to be produced
• For geographic reasons, where some team members are situated at another site and the
PM wishes to talk with one person instead of each team member
• If you are using an external company and it is easier and more efficient to coordinate with a
team manager rather than all the team members directly
Delivery
Management
Direction
Corp..
Senior
User
Executive
Senior
Supplier
Corporate, programmemanagement or customer
Project
Manager
Change
Authority
Project
Support
Team
Manager

The team manager has the responsibility to produce the products that were assigned in work
packages (contains product descriptions) and to provide regular status reports.
Project support role
This role provides a number of services to the project:
Administrative services and advice or guidance on the use of project management tools or planning or
risk management services
The most common responsibility of project support is configuration management and, therefore, follows
the guidelines in the change control approach document
Combining PRINCE2 project roles
PRINCE2 does allow some of the roles to be combined except for the following situations:
The executive and project manager roles cannot be combined.  
The senior user, senior suppler, or project manager should not be combined.
There can only be one project manager and one executive in a project
The PM, team manager, or project support should not have project assurance roles.
When combining roles, you should check if there are any conflicts of responsibilities. It is not
recommended to combine the roles of senior user and senior supplier as this will create conflicts of
interest. Each of the roles can be tailored to suit the project.  
Stakeholder engagement
Stakeholder engagement is where the PM identifies and communicates effectively with those people
or groups who have an interest in the project’s outcome. Stakeholders in a project can
- Support or oppose the project and become very active
- Gain or lose as a result of project delivery
- See the project as threat or opportunity to their position (e.g., career can grow)
Communication with stakeholders is the key to the project’s success and this is something that the
project manager and executive should keep in mind during the project. Communication with
stakeholders during the project is defined in the CMA.
6.6 The communication management approach (CMA) document
The purpose of this document is to define how communication will be done during the project (e.g.,
what type of info to communicate, to whom it is being communicated, and how often). It contains a
description of the means (how) and the frequency of communication to internal and external parties.
The PM is responsible for creating the CMA during the IP process (planning stage) and this document
should be reviewed during the managing a stage boundary process to ensure that key stakeholders
are receiving the required communication.
The CMA contains the following information:
1. An introduction to the purpose of the CMA document
2. The communication procedure: Communications methods that will be used
3. The tools and techniques, such as e-mail, intranet, newsletter
4. Types of reports and the information they should contain
5. Timing of communication activities
6. Roles and responsibilities: Who will handle the communication?
7. Stakeholder analysis: Type of stakeholder and desired relationship

CPC • Appoint the executive in the SU process
• They can also suggest a project manager
• Can provide CMA template which make it easy for the PM
Executive • Appoint project manager if not done by CPC.
• Chooses project board and confirms project management team
• Approves CMA document
Senior user • Provides user resources (e.g. to help with requirements)
Senior supplier • Provides supplier resources
Project manager • Prepares CMA document in the IP process
• Checks role descriptions for project management team
Team manager • Manages team members
You should know:
1. The purpose of the organization theme
2. How to describe the minimum requirements for applying the organization theme
3. How to describe the roles and responsibilities of the main project team members
4. Understand which roles can be combined in a PRINCE2 project
5. How to explain the concept of stakeholder and stakeholder engagement
6. How to explain the 3 project interests (the 3 primary stakeholders)
7. The 4 levels in a project and 3 levels in a project management team
8. The purpose of the communication management approach (CMA)

7 Quality
7.1 The quality knowledge provided by PRINCE2
The purpose of the quality theme is to setup and implement a system that will create and verify that
products are fit for use and meet user requirements. The quality theme defines the PRINCE2
approach to ensure that products created during the project meet the users expectations and that
the end product can be used as intended, so users can realize the expected benefits
Product focus is one of the seven principles of PRINCE2, which states that products should be clearly
defined (including detailed quality requirements) and signed off before development is allowed to
start. Product descriptions must include the quality criteria information so that all project stakeholders
have a common understanding of the products that will be created.
For example, if you are creating a new can opener, some of the quality criteria might be:
• Rust free
• Easy to clean
• Plastic handle should keep its color for 30 years
• Dishwasher-proof
• Mechanical parts must open 35,000 cans
• Easy to use (8 years to 90 years)
7.2 Quality definitions
Quality can be defined as the total amount of features or characteristics of a product, so that it meets
expectations and satisfies the stated needs. This is the same as saying that all features of the product
have to work as expected for the user. Think of all the features or characteristics of the above can
opener, they are all expected to work.
Quality management is the activities to direct and control an organization or project with regard to
quality. Some of these activities are: defining quality, quality control, and quality assurance.
Quality Management Systems (QMS) is the complete set of quality standards, procedures, and
responsibilities for a site or organization. The vast majority of large manufacturing companies have
a Quality Management System in place.
Customer’s quality expectations are captured in the project product description; it lists the
expected quality from the main product to be produced by the project.
Acceptance criteria is a prioritized (MoSCoW) list of criteria that the main output must meet before
the customer will accept it. These criteria are gathered in the document project product description.
7.3 Introduction to the PRINCE2 approach to quality
The following activities have to be done on each project:
• agree on the customer’s quality expectations and acceptance criteria
• identify the project’s products (sub-products) that need to be created
• create product descriptions for each product (user requirements)
• include the quality criteria, the quality methods, and the quality responsibilities
The PRINCE2 approach to quality has two parts: Quality Planning and Quality Control.
Quality planning
Quality is about identifying all the products that the project wants to control. Then write a product
description for each product, which will include quality criteria, how the products will be assessed,
developed, accepted and the responsibilities of the people involved.

Quality control
Quality control focuses on the techniques and activities to inspect and test (control) products. This
would also include looking for ways to constantly improve overall quality.
7.4 Part 1: Quality planning introduction
The purpose of quality planning is to:
1. Agree on the overall quality expectations and acceptance criteria of the main product:
2. Communicate these agreements with all stakeholders (project product description):
3. Establish how quality can be controlled by the PM during the project:
The following questions should be asked in quality planning:
1. What are the customer’s quality expectations?
2. How to prove that we meet each of the product specifications?
3. What is the acceptance criteria (check list) that the customer will use to accept products
during or at the end of the project?
Quality planning steps
1. Gather the customer’s quality expectations: high-level requirements
• These are the key requirements for the main product to be produced
• The measurements can be used to assess quality (speed, size, noise, etc.)
2. Gather acceptance criteria from the senior user and add to the PPD.
3. Write the project product description (PPD): This document contains:
• Customer’s quality expectations + acceptance criteria
• Tolerances for the main product
• Acceptance method: how the project product will be accepted
• Acceptance responsibilities – who will be responsible for accepting
4. Create the quality management approach (QMA): the approach for quality in the project.
5. Write product descriptions: for each of the products (sub-products) and include the quality
information, such as:
• Quality criteria for each product and quality tolerances
• Quality method (i.e., how to carry out quality checks after product is created)
• Quality responsibilities for creating, quality checking, and approving the product
6. Set up the quality register. Most of the data will initially come from the plans
Pre-Project – SU Initiation – 1st Stage
Project Brief
PPD
QMA
Project Plan
Product
Descriptions
Acceptance
criteria
Project Product
Description
Quality
requirements
from Customer
Customer quality
expectations
Quality
responsibilities
Quality information in
Product Descriptions
Quality criteria and
tolerances
Quality methods
Quality Register
1
2
3
4
5
6

7.5 Part 2: Quality control
Quality control is carrying out the activities to control quality. There are 3 parts to quality control:
1. Carry out the quality methods
2. Maintaining quality and approval records
3. Get acceptance and passing the acceptance records to the customer
The quality register will be updated with the result of the quality tests. The configuration item
record is updated to show the product is now delivered and handed over.
7.6 Quality documents
Project product description
This is a project product description from the sample project: U2 Driving School. The sections
customer quality expectations and acceptance criteria document the quality requirements.
The quality management approach
A quality management approach describes how quality will be done during the project and this
includes the specific processes, procedures, techniques, standards, and responsibilities to be
applied. A QMA template is usually provided by the organization and only needs minor changes.
Delivery
TeamManager
by Frank Turley
Closing a Project
Management
ProjectManager
Work
Packages
CS: CIR
Quality Register
Update product status
Delivery Stages : Controlling a Stage & Stage Boundary
Project Manager assigns
work to team & includes
quality criteria
Quality Check
Results in Quality Register
Product (s)
Quality
Review
Technique
Acceptance
Records
Products are created
by the teams
Give to client

The quality management approach can contain the following:
1. The quality management system to use, i.e., from customer, supplier, or a mixture?
2. The standards will be used?
3. The tools and techniques will be used?
4. How quality assurance be carried out?
5. The responsible for documenting the quality expectations and acceptance criteria?
6. The records will be required and where will they be stored?
7. The timing of quality activities be executed?
Product descriptions
The product descriptions should be created for all the products before the plan can be completed.
Sections Product description content
Identifier Unique identifier for each product
Title Product name: e.g., Casing
Purpose Who needs the product, why they need it, and what it will do
Composition List the parts that the product will be made up of
Quality Criteria E.g., color, noise, size, durability, lifetime
Quality Tolerance E.g., color cannot fade in 10 years +-10%
Quality Method E.g., use machine to test color fading; use inspection
Quality Skills required E.g., what knowledge is required to be able to test
Quality Responsibilities E.g., responsible for producing, reviewing, and approving
Quality register
The quality register contains a list of the quality events that take place during the project, such as
delivery dates, quality reviews, and acceptance. See the example of a quality register, and as you
can see, you have columns for Producer, Quality Reviewer, and Approver.
1. Product ID: Unique identifier
2. Product name: A common name to refer to the product (ex: “Elevator”)
3. Quality method: Describes how testing will be done
4. Producer: Name of producer
5. Reviews: The product review(s) after its delivered?
6. Approver: The approves of the product (ex: “John from Safety Company”)
Purpose
Composition
Quality Criteria
Quality Testing
Etc.
Product Description

7. Target review date: Date the product should be reviewed (ex: “June 20”)
8. Actual review date: Actual date that review happened
9. Target approval date: Date project manager will get approval (ex: 1 week later)
10. Actual approval date: Actual date when project manager received approval
11. Result: Result of check: Pass or Fail
The PM can check whether the Actual Target Review date and Actual Approval date columns are
filled in or not. This allows the project manager to control quality. The quality register is updated
by the project manager and project support.
7.7 PRINCE2 minimum requirements for quality
A PRINCE2 project should be doing the following at a minimum:
• The project product description should contain:
o Customer’s quality expectations (requirements)
o Acceptance criteria (quality checklist)
• Define the quality management approach.
• Create product descriptions (also part of planning) which include quality criteria
• Maintain quality records
• Use lessons to keep learning and improving how quality is done
PRINCE2 also requires that 2 products are produced and maintained:
• 1) Quality management approach (QMA) and 2) quality register 􏰀
Note: Any approach that meets the requirements described will satisfy PRINCE2.
7.8 Project assurance vs quality assurance
Quality assurance provides a check that services and products in an organization are meeting the
organizational standards and policies. Quality assurance only checks that a project is following an
agreed project process (e.g. business case must be prepared for each project) and has nothing to
do with checking the quality of the products produced by the project.
The CPC is responsible for quality assurance and this role is outside the project management team,
while project assurance is within.
11 Wall
Insulation
Inspection JV WP RT 2/10 10/10 10/10 11/10 Pass links
12 Heating
Furnace
Inspection TM TL RT 21/10 21/10 27/10 30/10 Fail links
12 Heating
Furnace
Performanc
e test
MP TL RT 21/10 21/10 27/10 30/10 Pass links
13 Kitchen
Fittings
Inspection AM OH BD 5/11 7/11 14/11 18/11 Pass links
.. … ….. .. .. .. … …. …. …. … ….
ProductID
Reviewers
Quality
Method
Product
Name
Producer
Approver
TargetReview
Date
ActualReview
Date
Actual
ApprovalDate
Target
ApprovalDate
Result
Records

Project assurance: The project board is responsible for monitoring the project’s performance in the
user, supplier, and business areas.
CPC • Provide QMS and quality assurance to the project
Executive • Approve the PPD (SU process) & QMA
Senior user • Provide quality expectations and acceptance criteria for project product
• Approve the project product description
• Acceptance of the project product (end of project)
Senior supplier • Provide resources to undertake supplier quality activities
Project manager • Document customer’s quality expectations and acceptance criteria
• Prepare the PPD and PD’s
• Prepare the quality management approach
Team manager • Produce products consistent with product descriptions
Project support • Admin support and maintain quality register and records
• The purpose of the quality theme
• Be aware of the quality definitions
• Explain concept of quality planning and quality control
• Explain customer quality expectations and acceptance criteria (PPD)
• Understand the purpose of the following documents:
- Project product description (PPD: main product produced by the project)
- Quality management approach (QMA)
- Product description (requirements documents)
- Quality register
• Describe the minimum requirements for managing quality
• Explain project assurance and quality assurance (know the difference)
• Aware of the roles and responsibilities (PM, senior users and project board)
Corporate
Programme
Customer (CPC)
Executive
Project Manager
Senior User(s) Senior Supplier(s)
Project Board
Change Authority
Project Support
Managing
Direction
Project Assurance
QualityAssurance
Responsibility of
the Project Board
Responsibility of
the CPC

8 Plans
8.1 Introduction
The purpose of the plans theme is to provide a framework to design, develop, and maintain the
project plans to help plan, facilitate communication and control the project.
This theme helps to answer the following questions:
• What is required to be delivered?
• How will it be delivered and by whom?
• What is the best approach to creating the products?
• What will the execution steps be?
• How can product-based planning be done?
• What quality has to be reached and how to define this?
• How much will it cos to deliver the products and the project?
• The level of detail required for each plan?
The plans provide the backbone of information used to manage the project. Without a plan, there
can be no control as you have no baseline to compare your progress to. The act of planning helps
the project PM and the rest of the project management team think ahead and avoid duplication,
omissions, threats and other planning issues.
8.2 Plans definitions
Plan: A plan can be a document that describes how, when, and by whom a specific target or set of
targets is to be achieved. A plan should also to show that targets (for time, cost, quality, scope, risk,
benefits, and of course, products) can be achievable.
The project plan is considered to be the plan for any project and it is created near the start of the
project and continually updated during the project to show what has been realized and what is still
left to do. The original plan could also be compared to the plan during the project or the plan at the
end of the project to see how well the project is doing in relation to the original plan.
Planning: The term planning is used to describe the actions used to create the plans and associated
documents and keep them updated during the project.
8.3 Three levels of a plan
It is difficult to plan most project from the start in detail as you can only accurately plan in detail a
short time in advance, so you are limited by what you can see clearly in the next days or weeks. This
view of the future is known as the planning horizon. PRINCE2 recommends 3 levels of plan which
are: 1) project plan, 2) stage plan, and 3) team plan.
Project plan
• This is a high-level plan for the whole project and used at the direction level (project board)
• Created during the IP process (planning process) and becomes part of the PID.
• Shows the planning for products of the project and associated cost.
• This plan is a major control document for the project board and therefore the project manager
keeps the project plan up to date during the project (SB process)
Stage plan
• Stage plan is used at the Management Level (project manager) and required for each stage
• It is similar to the project plan but is a lot more detailed (day to day plan for the stage)
• It is produced close (SB process) to the time when the planned events will take place and each
new plan should learn from the previous stage.

PRINCE2 Foundation Guide - Sample - by Frank Turley

More Related Content

What's hot

Similar to PRINCE2 Foundation Guide - Sample - by Frank Turley

More from Frank Turley

Recently uploaded

PRINCE2 Foundation Guide - Sample - by Frank Turley