PRINC E2 Workshop

By
Faisal Iqbal
Workshop O bjectives

Understanding the formal project management

framework using PRINCE2

Understanding PRINCE2 Principles, Themes and

Processes

Building confidence for facing PRINCE 2 Foundation

and Practitioner Exams
Workshop Agenda - Day 1
Introduction to PRINCE2

Overview of PRINCE2 Principles, Themes and

Processes Processes

Starting Up a
Project Initiating a
Project
Controlling a Stage

Managing Product Delivery

Managing a Stage
Boundary Directing a
Project

Closing a Project
Workshop Agenda - Day 2
Themes

Business
Case
Organization
Plan

Quality

Risk

Change

Progress
Discussion
on Sample
Papers
What is PRINCE2?
PRINCE2 (an acronym for PRojects IN a Controlled
Environments) is a de facto process-based method
for effective project management.

PRINCE2 can be tailored and applied to any project

regardless of project scale, type, organization, geography or
culture.
PRIN C E2 Benefits
PRINCE2's formal recognition of responsibilities within a project, together with its
focus on what a project is to deliver (the why, when and for whom) provides
projects with:

A c ommon, consistent approach

A controlled and organized start, middle and end

Regular reviews of progress against plan

Assurance that the project continues to have a

business justification

Flexible decision points

Management control of any deviations from the

plan
PRIN C E2 Benefits

The involvement of management and stakeholders at the right time and place
during the project

Good communication channels between the project, project management,

and the rest of the organisation

A means of capturing and sharing lessons learned

A route to increasing the project management skills and competences of the

organisation's staff at all levels
PRINCE2 Foundation & Practitioner Exams
Following two examinations applicable to PRINCE2:

Foundation examination

Practitioner examination
 Foundation Exam ination
Details
The Foundation is the first of the two PRINCE2 Examinations you are
required to pass to become a PRINCE2Practitioner.

This is a basic level exam that aims to measure whether a candidate would
be able to act as an informed member of a project management team using the
PRINCE2 method within a project environment supporting PRINCE2.

The candidate should have good understanding of

Four Integrated Elements of Prince2 - Principles ,Processes, Themes

and the Project Environment

Prince2 Project organization structure, key roles and the

responsibilities associated with the roles

Purpose and Contents of the major management products

Foundation Exam
Form at
Multiple-choice

One hour duration

75 questions

35 correct answers are required to pass

Closed-book
Practitioner Examination Details
The Practitioner is the second of the two PRINCE2 Examinations you are required to pass to
become a PRINCE2 Practitioner.

This level aims to assess whether a candidate would be able to apply PRINCE2 to the real time project
within an environment supporting PRINCE2. To demonstrate this candidate needs to exhibit the
competence required for the Foundation qualification, and show that they can apply and tune PRINCE2
to address the needs and problems of a specific project.

Precisely the candidates must be able to:

Produce detailed explanations of all processes, components and techniques, and worked examples
of all PRINCE2 products as they might be applied to address the particular circumstances of a given
project scenario.

Show they understand the relationships between Principle, Themes, Processes and the PRINCE2
products and can apply this understanding

Demonstrate their ability to tailor PRINCE2 to different project environments.

Practitioner Exam Format

The Practitioner exam presents the following main

characteristics:

9 questions, with a scenario background and

appendices
Each of the 9 questions is worth 12 marks

An overall score of 59 out of possible 108 is required to

pass (55%)

2.5 hours duration

Open book examination (only the PRINCE2 Manual

is allowed) This will be available to each delegate
For Practitioners & Registered Practitioners

All PRINCE2 Practitioners should be re-registered within 5

years of their original certification. This Re-Registration
comprises a 1-hour examination set at the same standard as the
Practitioner examination.
Project Management Basics

What is a Project?

PRINCE2 Definition

“A temporary organization that is created for the purpose of

delivering one or more business Products according to an
agreed Business Case”

Some of the other Project Management frameworks define

project
as:

“A temporary Endeavour undertaken to create a unique product,

service or result”
Some examples of the project are:

Filming a Motion Picture

Construction of a building - Office, Hospital or a shopping

mall Moving the office from one building to another

Hosting an event

Creating a new

process

Creating a Product

Developing a software

Implementing a software product

Major Enhancement to a
Characteristics of the project
They bring about Change. All the projects brings change, the change can be in the form
of process, products, tools and techniques, organization structure or at the least
expectations.

They are temporary (They have a defined Start and a defined End).

They are usually Cross-functional. Projects involve a team of people with different
skills working together. Examples - Engineers, Testers, Business Analyst and so on.

Every Project is Unique. Though there may be common elements in the project but the
two projects will differ in terms of the team, location and environment. Example
constructing a shopping mall providing similar offerings in two different locations.
Characteristics of the project

There is a degree of Uncertainty associated with all the projects

Projects are progressively elaborated. A project starts with a vision or

goal. The goal is converted into a high level plan and as you proceed forward
the requirements unfold and you get more clarity on the requirements and
this helps you to plan the immediate future at a detailed level.

The diagram below depicts High level view of a project life cycle
(Single Phase)
Project Vs Operations

PROJECTS OPERATIONS

Temporary Ongoing

Unique Repetitiv
e

Closes after attaining the Objective is to sustain business

objectives Examples are : Examples are : Assembly line

production, Monthly Payroll

Launching the new

car model
What is Project Management?
Project Management is the application of knowledge, skills, tools and
techniques to project activities to meet the project requirements.

The project team carries out the work needed to complete the
project, while the project manager schedules, monitors, and controls
the various project tasks.

The project manager requires knowledge, performance, and

personal
skills to perform better at their jobs.

The typical work of a project manager involves:

1. Requirements gathering
2. Managing stakeholder expectations
3. Managing key projects Aspect including scope, quality,
schedule,
resources, Benefits, and risk.
 Six Aspects of Project

The 6 Aspects or variables / performance targets are : Timescales, Costs,

Quality, Scope, Benefits and Risk
What is a Programme?

What is a Programme?

A Project can run as a stand-alone entity or can b e part of a programme of

related projects.

A Programme is a temporary flexible organizational structure created to

coordinated, direct and oversee the implementation of a set of related
projects and activities in order to deliver outcomes and benefits related to
organization’s strategic objectives.

A programme is likely to have a longer life than a single project. A project

which forms the part of a programme may b e impacted by the
programme structure and the reporting requirements.

Programme Management may b e defined as the co-ordinated organisation,

direction and implementation of a portfolio of projects and activities that
together achieve outcomes and realise benefits that are of strategic
importance."
PRIN C E2 Integ rated
Environment
The PRINCE2 methodology is based on four integrated elements and these
elements are Principles, Themes, Processes and the Tailoring PRINCE2
to
Project Environment as depicted in the figure below
Emb edding and Tailoring
PRIN C E2
PRIN C IPL E S
C ontinued Business Justification

Learn from Experience

Define Roles and Responsibilities

Manage by Stages

Manage by Exception

Focus on Products

Tailor to suit the project

environment:
THEMES
Business Case

Organization

Quality

Plans

Risks

Change

Progres
s
PROCESSES
The seven processes listed below describe the project
lifecycle from getting started to project closure.

Starting Up a Project
Initiating a Project
Controlling a Stage
Managing Product Delivery
Managing a Stage Boundary
Directing a Project
Closing a Project
PRINCIPLES , PROCESSES AND
THEMES
PRINCE2 PROCESS
TIMELINE
Processes

PRO C E SSES
Starting Up a Project

Purpose of the Starting Up a Project Process

The purpose of this process is to answer the question, “Do we have a worthwhile and
viable project?” The project mandate is usually the only document that exists when this
process starts, and this is not enough information for the Project Board to make the
decision to start the Initiation Stage.

Therefore, the purpose of this process is to provide the Project Board with the
necessary information to judge if the project is worthwhile. They use the Project Brief,
which will contain information on the Business C ase. Another important purpose of
the Starting Up a Project process is to prevent poor projects from starting up.

This process should be brief; perhaps that’s where we get the name Project Brief. In
fact, the aim is to do the minimum necessary just to see if the project is worthwhile
doing the Initiation stage.
Starting Up a Project

The Objectives of the Starting Up a Project Process

The objectives of the Starting Up a Project process are to prepare and make sure that
the following is done during and by the end of this process:
There is a Business C ase or a business reason and this should be documented in the
outline Business C ase. The Business C ase document will not be completed until the
Initiation Stage.
Look at the project approach, which examines the best way to go about doing this
project and obtaining advice from other projects in the form of lessons learned,
specialists or even outside knowledge.
Choose the people who will do the work to initialize the project, and other roles in
the project team.
Create the Project Brief, which provides information on the scope of the project and
most of the information collected to date in this process.
Create a detailed Stage Plan to plan the work to be done in the Initiation Stage.
So as you can see, the Starting Up a Project process objectives are to provide the
Project Board with certain information and to prepare the Initiation Stage.
Starting Up a Project

The ’starting up a project’ process ensures that sufficient planning is in

place before initiating a project. The process is triggered after the
mandate is received from the corporate program management.The
primary output of this process is project brief.

The key activities in this process are

Capture Previous Lessons

Appoint the Executive and Project Manager
Design and Appoint Project Management Team
Prepare the Outline Business Case
Create Project Product Description
Select the project approach and assemble the
Project Brief
Plan the initiation stage
Triggers the directing the project process with request to initiate the
project
Starting Up a Project

The Executive is responsible for Appointing the Project Manager, the Project
Manag e ment Team and creating the outline Business C ase.

The Project Manager is responsible for Roles descriptions, capturing previous

lessons, project approach, assembling the Project Brief, creating and updating
the Daily Log, and creating the Initiation Stage Plan.
Initiating a Project
The purpos e of this Process is to establish solid foundations for the project , enabling
the organization to understand the work that needs to be done to deliver the project’s
product before there is a commitment to significant spending.

This understanding is needed before deciding to continue with the project. Like any
project there are a number of important items to discover and so there are a number
of questions to ask about the project:

• What are the reasons for doing the project and the Benefits and Risks?
• Scope: What is to be done and what will not be included?
• When can the products be delivered?
• How to ensure that quality will be achieved?
• How risks, issues and changes will be identified and followed up?
• How project progress will be monitored, who needs to be informed and how often
do
they need to be informed?
• And lastly how PRINCE2 will be tailored to suit the project?
Initiating a Project
The key objective of this process is to ensure that there is a common understanding of
;
• The reason for doing the project, the benefits expected and the associated Risks,

• The Scope of what is to be done and the products to be delivered

• How and when the project’s products will be delivered and at what cost

•, Who is to be involved in the project decision making

• How the quality re quired will be achieve d

• How baselines will be established and controlled

• How risks, issues and changes will be identified assessed and controlled

• How prog re ss will be monitored and c ontrolle d

• Who needs information, in what format and at what time

Initiating a Project
Following are the Activities performed in Initiating a Project Process

Prepare Risk Management Strategy

Prepare Configuration Management Strategy

Prepare the Quality Management Strategy (QMS)

Prepare the Communication Management Strategy

Set up the Project Controls

Create the Project Plan

Refine the Business Case

Assemble the Project

Initiation Document
(PID)
Initiating a Project
The Project Manager assembles the Project Initiation Documentation and
includes the following information and documents:

• Project Brief
• Project Management Team Structure and Roles Descriptions
• Business Case
•Four Management Strategy documents: Quality, Configuration Management,
Risk and Communications
• Project Plan
•Project Approach, Project Controls and how PRINCE2 was tailored to suit the
project

Project Assurance will check that it contains the necessary information and
can b e put forward to the Project Board

The last task done by the Project Manager is the request to deliver a
project. This request is made to the Project Board and they will decide if the
project can continue or stop. This request can b e formal or informal and
depends on the culture of the company and size of the project.
Controlling a Stage
The purpose of the Controlling a Stage process is to assign work to be done to the
specialist teams, monitor such work, manage risks and issues, report progress of
the stage to the Project Board, and if required take corrective actions to ensure that
the stage remains within tolerance in terms of the six aspects (Scope, Time, Cost,
Risk, Quality and Benefits).

The objective of the Controlling a Stage process is to ensure that:

Attention is focused on the delivery of the products.

Keep Risks and Issues under control.
Keep the Business Case under review.
Deliver the products for the stage to the agreed quality within agreed cost and
time & achieve the defined benefits.
Controlling a Stage
The key activities performed in this process are :

Authorize a Work Package as a result of approval of a stage or an exception plan

by the board. Obtain the product descriptions of the entire product to be included
in the Work Package and define the techniques, processes and procedures to b e
used.

Review a Work Package Status through Checkpoint Reports and

receive completed Work Packages

Review the team plan with team manager to forecast whether the
work will be
completed on time and budget.

Review the Project Initiation document for the project controls such as reporting
method required, Quality Management Strategy and the
Review the stage status, report highlights and take corrective actions if
required.

Watching for, assessing and dealing with issues and risks. This includes
maintaining Issue and Risk registers. Escalate Issues and Risks
Controlling a Stage
Quality standards required, Configuration management strategy for
how the products are to be hand over
Reviewing the product quality and triggering the new W ork Package or
update the existing ones.
Review entries in the Quality Register related to products in the work
package to understand the current status of quality management
activities and ensure that each product in the W ork Package has
gained its requisite approval.
Confirm that the configuration item record for each approved product is
updated
Update the stage plan to show the W ork Package as completed
Review the Stage Plan (current stage) for products to be produced,
cost, effort and tolerances available
Managing Product Delivery Process
Purpose
The purpose of the Managing Product Delivery Process is to manage and control
the work between the Project Manager and the Team Manager by placing
certain
formal requirements on the accepting, executing, and delivery of products.

Objective:
The objective of the Managing Product Delivery Process is to ensure that:
Products assigned to the team are authorized and agreed.
The team is clear about what has to b e produced & understands the effort, time
and cost.
The planned products are delivered to the expectations and within
tolerance.
Accurate progress information is provided to the Project Manager by the Team
Manager.
Managing Product Delivery Process
The key activities in this process are:

Work on products allocated to the team is authorized and agreed

Team Managers, team members and suppliers are clear as to what

is to be produced and what is the expected effort, cost or timescales

The planned products are delivered to expectations and within

tolerance

Accurate progress information in the form of checkpoint reports is

provided to the Project Manager at an agreed frequency to ensure
that expectations are managed.
Managing Product Delivery Process
Products that are created or updated during this process are:

Team plans with actual dates.

Risk register with any identified work package level risks.

Quality register with all quality work that is being undertaken.

Configuration Item Records with the latest status of products produced.

Project Issues with status information and impact analysis for current or
new issues identified.

Checkpoint Reports providing regular progress information to the

Project Manager.
Managing a Stage Boundary

The purpose of Managing a Stage Boundary Process has two parts:

The Project Manager has to provide the Project Board with certain information.
The outputs of the Stage Boundary process are all for the Project Board.

This information will enable the Project Board to review the current
stage, approve the next stage, review updated Project Plan, and confirm
continued business justification.

The objective of the Managing a Stage Boundary Process gives an overview of

the main work that the Project Manager must do, which is:
Assure the Project Board that all products in the current stage are produced
& approved.
Review and update, if necessary, the usual documents, which are the
Project
Initiation Documentation, Business Case, Project Plan, and Risk Register.
Record any lessons in the Lessons Log that can help in later stages or in
future projects.
Prepare the Stage Plan for next stage and Request Authorization to start the
next stage.
Managing a Stage Boundary
Following are the activities performed by the project manager in Managing a
Stage Boundary Process.

Ensure and communicate to the Project Board that all products in the Stage Plan
for the current stage have been completed and approved

Review and, if necessary, update the Project Initiation Documentation (in

particular the Business Case, Project Plan, project approach, strategies,
project management team structure and role descriptions)
Managing a Stage Boundary

Provide the information needed for the Project Board to assess the
continuing viability of the project and the aggregated risk exposure such as

An End Stage Report produced by the Project Manager and given to the
Project Board, outlining information on the current stage achievements.

Current Stage Plan Actuals showing the performance against the original
Stage Plan

An updated Risk register, together with the Updated Business Case and
Project Plan, which is used by the Project Board to review that the Project has
continuing ongoing viability.

An updated Configurable item record and Product Status Account Any

changes to the Project Management Team with updated Job Descriptions.
Closing a Project

The purpose of the Closing a Project Process is to provide a fixed point to

check that the project has reached its objectives and that the products
have been accepted.

The objective of the Closing a Project Process is to:

Verify user acceptance of the project’s products.

Ensure that products can be supported after the
project is disbanded.
Review the performance of the project. This is done by comparing
the project to the baselined documents.
Assess the benefits already realized and plan review of benefits that
will be realized after the project is complete.
Address open issues and risks with follow-up on
action recommendations.
Closing a Project
The activities performed in this process are:

There are 5 activities in the C losing a Project Process for the Project Manag er
and they are:

•Preparing planned closure, i.e., confirming the completion of products and

their acceptance.

•Preparing premature closure:This is done instead of the “prepare planned

closure” activity if requested by the Project Board.

•Handover of products: Hand over products to customer, as described in the

Configuration Management Strategy document.

• Evaluating the project, i.e., comparing the project objectives with the
actuals
and writing the End Project Report.

•Recommending project closure, i.e., sending a notification to the Project

Board to close the project.
Closing a Project
Prepare Planned C losure - Activities

The Project Manager does the following :

• Project Plan: Update the Project Plan to show what products have been delivered.

•Product Status Account: Request from Project Support a document called “Product Status
Account.” This is a short report on the status of all products, such as Product Identifier,
Status: Accepted and so on.

•Meet Acceptance Criteria: Confirm that the project has delivered what is defined in the
Project Product Description, and that the acceptance criteria defined in the Project
Description has been met. The Project Board will also check that all products have been
accepted and signed for and the acceptance criteria have been met; and

•Lastly, seek approval that project resources can be released (e.g., equipment used for the
project, contractors and rooms) so that these do not continue to be charged to the project.

Once these steps are done, the Project Manager is ready to hand over the products,
complete the End Project Report and then recommend project closure.
Closing a Project
Prepare premature closure

Sometimes the Project Board will instruct the Project Manager to close the project. The Project
Manager will not just abandon the project but should try to salvage anything of value so it can be
used again.

PRINCE2 recommends the following actions:

• Record Premature Close: Record the Premature Close Request in the Issues Register.

•Project Plan: Update the Project Plan with actuals from the current stage. The Project Plan will show
what was completed when the project was closed.

•Product Status Account: Request from Project Support a Product Status Account so that you can
identify Products developed, currently under development, to start, etc. Products that need to be
made safe and may be useful to other projects.

•Products: Agree what to do with the completed products and products that are currently under
development. This might require extra work, as there may be a request to complete one of the
products first before shutting down.

•Lastly, seek approval from the Project Board that project resources can be released, so that the
project can stop being charged for these resources.

Once this is done, the Project Manager will follow the next activities which are to hand over the
products, complete the End Project Report, and recommend project closure.
Closing a Project
PRINCE2 recommends the following in Handover products activities:

Follow on Ac tion Rec om m endations

•Prepare the follow-up on action recommendations for the products. These are mostly taken from
the Issues and Risk Registers.

•Ch eck that the Benefits Review Plan includes post-project activities to confirm benefits that cannot
be measured until after the products have been in operation for some time.

C onfig uration M anag ement

The Configuration Management Strategy document will describe how the products should be
handed over. Some common steps here are:

a) Confirm that correct operation and maintenance environment is in place.

b)Consider the early life-support requirements of products, as this is often where the most support
is needed.
c) Ch eck if a support contract is required and get it drawn up if necessary.
d) Confirm acceptance from the operations for the products and obtain acceptance records, as
these
are require d by the Proje ct Board.
e) Lastly, transfer responsibility to operations for the products and register this in the Configuration
Item Records to show who the current owner of the products is.
Closing a Project
Closing a Project
Evaluate the Project

The objective of this activity is to assess how successful or unsuccessful the project was and to learn
from this project.

E nd Projec t Report:

•The Project Manager will compare the current documents in the Closing a Project Process such as
the Project Plan and the Business Case with the baselined documents.

•The Project Manager will do the following to create the End Project
Report: o Prepare a summary of how the project performed.
o Review the project benefits delivered so far compared to the expected
benefits.
o Review how the project performed against its planned targets and
tolerances.
o Review team performance.
o Review of the Project Products.

Lessons Learned Report:

•The Project Manager will work with the Project Management team to prepare a Lessons Learned
report. This will be used to benefit future projects. The Lessons Learned report should include the
follow information:
o A review on how the project went, what went well and what could be improved.
oHow effective the Quality Management Strategy was in designing, developing and delivery for
purposed products; and
o Any useful information gained regarding the tailoring of PRINCE2.
Directing a Project
The purpose of the Directing a Project Process is to enable the Project
Board to be accountable for the project by making key decisions, and to
have overall control

Objective:What are the objectives of Directing a Project?

The objectives of Directing a Project Process are to:
Provide authority to initiate the project.
Provide authority to deliver the project’s products. The products are the
reason to do the project.
Provide direction and control during the project.
Be the interface to Corporate or Program
Management. Provide authority to close the project.
Ensure that post-project benefits will be reviewed.
Directing a Project
The key activities in this process are:

There is appropriate authority to initiate the project

There is authority to deliver the project products
The project remains viable and management direction and control are
in place throughout the projects life.
The project board executive Interface is regularly with corporate or
programme management
There is authority to close the project
A benefit review plan for realizing the post project benefits is created,
managed and reviewed.
The Directing a Project process starts when the Starting Up a Project
process completes and is triggered by the request from the project
manager to initiate a project.
The project board uses the technique management by exception. It
monitors via reports and provides control via a number of the decision
points.
Directing a Project
For management by exception to work, the project board must set
tolerance, and if at any point this is forecasted to be exceeded, the
project manager will inform the project board via an Exception Report to
bring the situation to the project board’s attention.

With management by exception there is no need for progress

meetings. As already mentioned there must be an information conduit
between the project board and corporate or programme management,
how this is to occur should be documented in the Communication
Management Strategy.

Although it is the executive of the project board who has the veto on
any decisions and direction given, the project board should provide a
unified direction and guidance to the project manager and other key
stakeholders. The project board is responsible for assuring that there is
continued business justification, and this is why the project Board
Executive owns the project Business Case.
Themes

Them es
 Themes - Business
Case
The Business C ase describes the business justification of the project, it explains
whether the investment in the project is worthwhile or not.

The Business case of a project can be based on financial benefits (Based on ROI,
NPV and so on) as
well as other reasons suc h as ;

Mandatory Project: The projects that are initiated to fulfill some government mandate, rules
or regulation.

Not - for - profit project: The N G O projects such as improving the literacy rate of a particular
state by 25% or to reduce poverty.

Evolving Project: This include research projects originated as an idea or to resolve an issue. This
can also include a software development project in which requirements might not be known
clearly in the beginning and is elaborated as we move ahead and is delivered stage wise.

Customer/supplier project: PRINCE2 is based on a customer/supplier environment. Therefore

the customer and supplier can have their own Business Case. By default Business Case refers to
the Business Case of the customer. The Business Case is owned by the Executive.

Multi-organization project: Some examples are joint ventures, research and government
projects.
Programme Vs Project Business
Case
The programme will define the standards that the project will need to use when
developing the Business Case. The project Business Case will be aggregated
into the overall programme Business Case and therefore it is likely to b e
reduced in content. It may comprise just the details of the budget, a list of
benefits (and the benefits tolerance), and a statement as to how the project is
contributing to the programme blueprint, with the justification aspects of the
project Business Case sitting in the programme Business Case. In some cases,
the Business Case might b e produced and maintained by the programme and
even exist in detail prior to initiating the project.

Benefits will be defined, tracked and managed by the programme management

team - and any benefit reviews relating to the project will be part of the
programme’s benefits realization plan.
Business
Case
The diagram below depicts the development path of a business case

The outline Business Case is created in the startup stage; it is detailed in

initiating a project stage. It is then verified at the critical points during
the project, such as at the end of each stage.
Benefit Review
Plan
The purpose of the Benefits Review Plan is to identify the benefits and
most importantly, to select how the benefits can be measured so that
it is possible to show that they have been reached.You can then
compare the new results to the current situation, which leads us to the
next point, which is to collect the baselined measures.

Benefits Review Plan must include information on the expected

timeline for these benefits, i.e., when the benefits can be expected
and measured, and who will g ather the information.
Business
Case
The Business Case should describe the reasons for the project and includes
information on the estimated costs, risks and expected benefits. It should
contain the following parts:

• Executive Summary

• Reasons

• Business Options

• Expected Benefits and expected dis-benefits

• Timescale

• Costs

• Investment Appraisal

• Major Risks
Business
Case
The output of a project is the specialist products, the outcome is the result of
the change derived from using the projects outputs and benefit is the
measurable improvement resulting from an outcome seen as an advantage by
at least one of the stakeholders.

Example for a project that involves implementing an ERP to improve

operational efficiency the output is ERP itself, the outcome is improvement in
operational efficiency.The benefit is the reduction in the cost by 1 million USD
per annum due to reduction in wastage.
Business Case -
Responsibilities
Corporate or Program Management

They provide the project mandate, which will most likely include some
information on the Business Case.

The Corporate or Program Management is interested in hearing about the

Benefits of the project.

During the project, the Project Manager will report on the Benefits to the
Program Manag e ment and will update the Benefits Review Plan.

And after the project is completed, the Corporate or Program Management

will b e responsible for the Benefits Review Plan. They have the responsibility
of following up to ensure that the benefits have been realized.
Business Case -
Responsibilities
Executive

The Executive is responsible for the Business Case and the Benefits
Review Plan during the project.

The Executive is also responsible to develop a viable Business Case,

securing funding for the project and ensuring the project is aligned
with corporate strategy.
Business Case -
Responsibilities
Senior User

The Senior User is responsible for specifying the Benefits and then
for ensuring that they are realized by the project.

They are also responsible for ensuring that the products produced
by the project deliver the desired outcomes, in other words, that
they can be used as expected.
Business Case -
Responsibilities
Senior User

The Senior User is responsible for specifying the Benefits and then
for ensuring that they are realized by the project.

They are also responsible for ensuring that the products produced
by the project deliver the desired outcomes, in other words, that
they can be used as expected.
 Business Case -
Responsibilities
Project Manager

Project Manager can assist the Executive in preparing the Business

Case.

For each new or revised issue and risk, they will also do Impact
Analysis of the Business Case to see if the issue or risk affects
the Business Case.

They also assess the Business Case at the end of each stage, this
information is required by the Project Board and they also keep the
Benefits Review Plan updated during the project.
Business Case -
Responsibilities
Project Assurance

Project Assurance provides a kind of audit service on each project

to check that it is progressing as planned.

From a Business C ase point of view, they can assist in the

development of the Business Case and they will monitor the Business
Case for external events. Remember, the Project Manager operates
inside the project, so they only see internal events.

Project Assurance also verifies and monitors the Benefits

Review
Plan.
Exercise
C reate a sam ple Business C a se for a C R M Project.

0R

C reate a Sam ple Business C a se for project that

involve
construction of three hig h rise residential towers
Organization
This Theme defines and establishes the project’s structure of roles and
responsibilities. PRINCE2 is based on Customer and Supplier
environment; it defines and the set of responsibilities very clearly.
Following are the four levels in an organization
Organization

Three Levels in the Project Team

Organization
Project Management Team Structure - Simple Overview of Corporate or
Program management, Directing, Managing and Delivering levels
Organization

Project Management Team Structure - Simple Overview of three Project

Assurance functions, Business, User and Supplier Assurance
Organization

Project Management Team Structure - Simple Overview of all the role

along with Change Authority and Project Support
Organization

Three project interests

As per the PRINCE2 principle of define roles and responsibilities, a

project will always have three primary categories of stakeholders
and the interest of all three must be satisfied if the project is to be
successful. The figure below shows the three primary interests which
make up the project board
Organization
Three project interests
PRINCE2 recommends that for effective function the project board
should include representation from each of the business, user
and supplier interests at all times.

Business
The Executive Role on the Project Board looks after the Business
interests. There must be a Business Case, otherwise the project cannot
start.

User Interests
The Senior User role will represent the User interests on the Project
Board. In a PRINCE2 project, a user is also referred to as the
customer and the will most likely pay for the project.
Organization

Supplier Interests

The Supplier provides the resources and the skills to create the
products. In an organization, this could be either internal or external.
For example, an internal IT department or external IT company. The
Supplier interests are represented on the Project Board by the Role
Senior Supplier. This Senior Supplier role can be assigned to an
external or internal person or persons.
Organization
Stakeholder Engagement

Stakeholder Engagement is the process of identifying and

communicating effectively with those people or groups who have an
interest in the project’s outcome. It’s also: Managing relationships as a
way of achieving influence and positive outcomes.
Organization
The C om m unication M anagem ent Strateg y

The Project Manager is responsible for creating the Communication

Management Strategy during the Initiation Phase of the project. This
should be reviewed during the Managing a Stage Boundary Process to
ensure that key stakeholders are receiving the required communication
Organization
The Communication Management Strategy document contains the
following information:

An introduction to remind the reader on the purpose of the document for this
project.
Communication Procedure: A description of the communications
methods that will be used, such as electronic mail, meetings, and
presentations.
Tools & tec hniques, such as e -mail, intranet, newsletter.
Reporting: Types of reports and the information they should contain.
Timing states when c ommunication activities will b e done.
Roles & Responsibilities:Who will handle the communication?
Stakeholder Analysis:Type of Stakeholder and the relationship desired with
Stakeholder.
Information Needed: Information required from project, including the
frequency of the communication and the format of it.
Organization
Roles and Responsibilities

Corporate or Program Management

They appoint the Executive and possibly the Project Manager.
They can also provide some information for the project as will be defined in
the C ommunication Manag e ment Strategy doc ument.

Executive
Appointing the Project Manager if not done by Corporate or Program
Management.
Confirm appointments to the Project Management Team.
Approving the Communication Management Strategy Document.

Senior Supplier
Providing supplier resources

Senior User

Providing User Resources

Defining & verifying user requirements & expectations
Organization
Roles and Responsibilities

Project Manager

Preparing the C ommunication Manag e ment Strategy

Reviewing and updating the Project Manag e ment
struc ture Preparing Role Descriptions

Team Manager

Managing Project Team Members

They can advise on the selection of project team members

Project Assurance

Advising on the selection of project management team

members
Advising on Stakeholder Engagement
Ensuring the Communication Management Strategy is appropriate and the
planned communication activities actually take place.
Quality

The purpose of the knowledge in the Quality Theme is to define and

implement a system that will create and verify that products are fit for use. So
the Quality Theme defines the PRINCE2 approach to ensure that products
created during the project meet the expectations, and that the end-product
can be used as intended.

If the quality of the products is not as expected, then the expected benefits
that should b e realized as a result of the project will not b e achieved. The
products must work as expected for the project to deliver the expected
benefits.

Product focus is one of the principles of PRINCE2, which means that a

project’s products should be clearly defined at the start of the project. This
includes the Quality criteria information, so that all project stakeholders have
a common understanding of the products that will b e created.
Quality

In PRINCE2, quality focuses on ensuring that the project’s products are

fit for purpose. The approach, defined in the project’s Quality
Management Strategy, requires that there be an explicit understanding
of project scope and the quality criteria against which the products will
be assessed.

There are three key aspects to quality within the project:

Quality Planning

Quality Control

Quality Assurance
Quality

Quality planning is needed for control and covers definition

of the products within the project along with their quality
criteria, quality methods and quality responsibilities.
Quality
Q uality control is reactive, and covers techniques and
activities as

Quality inspections or testing

Finding ways of eliminating causes of and satisfactory

performance. This is where the application of lessons learned
can be helpful.
Quality

Q uality M ethods

In-Process method allows you to detect flaws earlier, as

The products are tested while they are being developed.
Examples include unit testing in software, integ ration testing ,
checklists and inspections. In the new laptop project, integration
tests will be done to make sure the different products work
together.
Quality
Quality Methods

Appraisal Method: This involves testing the finished product and will
depend on the type of product you are creating. In the new laptop
project, some tests can b e done on the finished product, which could
include a full software diagnostic, shaking the device, and so on.
Now let us look at the Elevator product:

The Technician who installs the elevator could do an In-Process test

to check different parts of the elevator as it is being installed.

The Safety persons will use the Appraisal Method, as they will look
at the finished product.
Quality

Quality Records provide evidence that each product has met its
requirements as specified in its Product Description. These records support
the entries made in the Quality Register, as the Quality Register just provides a
very high- level overview of the activities. For example, these Quality Records
provide evidence or proof of (1) who approved what, (2) the reports and audits
that have taken place and (3) audit reports to show that products have met
specific Quality criteria.
Quality
The Quality Register is a diary of the Quality events that take place during
the project, such as workshops, reviews, testing and acceptance.

At first, the Quality Register will be empty and the Project Manager can start to
add the data towards the end of Quality Planning. Most Project Managers will
use a spreadsheet for a Quality Register.
Quality
Quality Assurance This must be independent of the
project management team

It ensures that the project’s direction and management remains

aligned with relevant corporate or programme management
standards and policies.

Quality assurance therefore, is all about independently checking

that the organization and processes are in place for quality
planning and control.
Quality
The PRINCE2 quality review technique is used to assess a
product ag ainst set quality criteria, and works well for a document
walkthrough or analysis of test results.

The quality review technique confirms that the product is complete,

ready for approval and that it can be baselined and placed under
change control.

The quality review technique consist of the following three steps

Prepare for Quality Review

Conduct the Quality Review Perform

Quality Review Follow - up

Quality
Prepare for Quality Review

The following activities are performed in preparation for a quality review meeting
on a PRINCE2 project:

Make administrative arrangements for the review (Chair or Administrator)

Chec k that the product is ready for review and confirm reviewer availability (Chair)

Distribute product copies to reviewers along with the Product Descriptions

(Presenter)

Review the product relative to its quality criteria(Reviewer)

Submit question list to chair and presenter prior to review (Reviewers)

Annotate product copy for copy edit errors and return to presenter (Reviewers)

Produce consolidated question list for the review meeting and send to presenter

(Chair)
Quality
Conduct The Quality Review

The following activities are performed when conducting quality review

meeting on a PRINCE2 project:

Introduce attendees and the product being reviewed (Chair)

Invite reviewers to contribute major questions about the product (Chair)

Agree actions on each question as it is raised (Review Team)

Record the actions and responsibilities (Administrator)

Lead review team through the product and review the consolidated
question list (Presenter)

Agree actions on each question as it is raised (Review

Team) Record the actions and responsibilities

(Administrator)
Quality

Conduct The Quality Review

The following activities are performed when conducting quality review

meeting on a PRINCE2 project:

Read back and confirm actions (Administrator)

Determine review results, dec iding if the product is

complete, conditionally complete or incomplete (Chair)

Close the review and inform interested parties of the

results (Chair)
Quality
Perform Quality Review Follow Up

The following activities are performed to follow up on action items after a

quality review meeting has been completed for a PRINCE2 project:

Coordinate and track the actions (Presenter)

Sign off on actions as they are completed (Reviewers)

Sign off on product completion after all actions are complete (Chair)

Communicate quality review outcome and store quality records

(Administrator)

Request formal approval for the product (Presenter)

Qualit
yPerform Quality Review Follow Up
The following activities are performed to follow up on action items after a
quality review meeting has been completed for a PRINCE2 project:

Coordinate and track the actions (Presenter)

Sign off on actions as they are completed (Reviewers)

Sign off on product completion after all actions are complete (Chair)

Communicate quality review outcome and store quality records

(Administrator)

Request formal approval for the product (Presenter)

Qualit
y
Roles and Responsibilities

Corporate or Program Management

Provide details of the Corporate or Program Quality Management System. (They inform
the project about the existing Quality systems in place.)
Provide Quality Assurance to the project.

Senior User
Provide the companies’ Quality Expectations and Acceptance Criteria for the Project
Product. This makes sense, as the Senior User is also responsible for the product
specifications.
Approve the Project Product Description and Quality Management Strategy. This could
also be done by the Executive.
They can also approve the Product Descriptions for key products.
Provide acceptance of the Project Product.
Qualit
y
Roles and Responsibilities

Executive

They can also approve the Project Product Description & Quality Management Strategy
with the Senior User.

Senior Supplier

Provide resources to undertake supplier Quality activities.

Project Manager

Document the customer’s Quality Expectations and Acceptance Criteria. They will work with the
Senior User on this.
Prepare the Project Product Description with other persons involved in the project.
Prepare the Quality Management Strategy document, which defines how Quality will be done
in the project.
Ensure that the Team Managers implement the Quality Control measures agreed in the Product
Descriptions and Work Packages.
Qualit
y
Roles and Responsibilities

Team Manager

Produce products consistent with Product Descriptions. Advise

the Project Manager of the product Quality status.

Project Assurance

Advise the Project Manager on the Quality Management Strategy and on suitable
reviewers and approvers.
Assure the Project Board members on the implementation of the Quality Management System.

Project Support

Provide administrator support for Quality Control.

Maintain Quality Register and the Quality Records.
Plan

The purpose of the Plans theme is to provide the following information

to all the project team members and thereby facilitate effective
communication and control.

What is required

How it will be achieved and by whom and details on any specific

resource such as specialized hardware or equipment required

Details on activities and milestones

The targ ets for time, cost, quality, scope, risk and benefits

Provides a baseline against which progress can be measured.

Plan
PRINCE2 uses the principle of management by exception.Whenever a plan
is forecast to exceed the allowed tolerance, then an exception report must b e
created , the purpose is to effectively utilize the managements time.

If required, an exception plan will now b e prepared for the appropriate

management level to show the actions required to recover from the effects of
a tolerance deviation. If an exception plan is approved it will replace the
original hence become the new baselined plan (for the project or stage
level).
Plan
An exception plan at project level must b e referred by the project board
up to corporate or programme management as they alone have the
authority to approve such a plan.

If the exception plan is to replace the stage plan, then the project board has
the authority to approve it.

If the project manager has set tolerances at work package level, and the
team manager is now forecasting that such tolerances will b e exceeded, then
an issue is raised to bring this to the attention of the project manager, who will
determine if this issue can b e resolved within stage tolerance levels. If
corrective action is needed and approved by the project manager, then this
may result by an update to the current work package or authorizing a new
work package.
Plan
The benefits review plan defines schedule for measurement of the benefits
generated from the project’s outcome (how and when measurement of the
achievement of the project benefits).

The benefits review plan is created within the initiating a project process and is a part of
PID, and it is updated at each stage boundary.

The benefits review plan is used during the Closing a project process where it is
updated to reflect any benefits that have already been realized, and most importantly
those benefits along with the resources that have yet to be realized after the project has
been completed.
Plan
Product Project Description

This is the first step, and although the senior user is responsible for
specifying the project product, it will often be created by the project
manager in close communication with both the senior user and the
executive of the project board.

The project product description describes the purpose of the project

product and who will use it. It also contains the specialist skills
required along with the customer quality expectations and the
acceptance criteria, tolerances, acceptance method and exception
responsibilities.
Plan
Identify Activities and Dependencies

It involves

Define activities required to create the products of the project

Dependencies between the activities and their relationship. The

relationship can be (FS - Finish-to-Start), (SS - Start -to - Start), (FF-
Finish -to - Finish) and (SF-Start -to -Finish)

Dependencies between each activity and appropriate products

must now be identified and these will include both internal and
external dependencies.
Plan
Prepare Estimates
Following Methods can be used for estimating include:

Top down estimating

Top down and Bottom up approach

Bottom - up estimating

Comparative and Parametric

estimating

Three-point estimating

Single point estimates

Delphi technique
Plan
Prepare The Schedule

This is the generation of a bar chart or Gantt chart showing the

activities, then dependencies, and the sequence in which they must
be performed. Critical path analysis is normally used here, and
hence the identification of critical and non-critical activities to
determine the earliest project finish date along with the critical path
and the client or slack of non-critical activities.

Note that the critical path by definition as zero float or slack,

whereas non-critical activities will have some amount that determines
the amount of time that such an activity can slip or extend without
affecting future activities or the end date of the project
Plan
Assess and Assign Resources

The first step here is to identify who is available in terms of knowledge

skills and experience, to carry out the work. This will also include the
identification of available non human resources such as facilities.

The next steps is to assign such resources to each appropriate activity,

taking into consideration work effort estimates and that their
availability. As a consequence of this the critical path may be modified.
Plan
Assess and Assign Resources

The first step here is to identify who is available in terms of knowledge

skills and experience, to carry out the work. This will also include the
identification of available non human resources such as facilities.

The next steps is to assign such resources to each appropriate activity,

taking into consideration work effort estimates and that their
availability. As a consequence of this the critical path may be modified.
Plan
Resource Leveling

There are two situations which may now be present; the first is that
large resource peaks will be evident at certain points within the
project, and this can result in management or logistical problems.

The second may result in over utilization of some resources. The act of
resolving either of the above is called leveling. The critical chain
technique may also be helpful at this step.
Plan
Agree On Control Points

By now, a draft schedule would have been created for the plan and key
Control points need to be identified. These will include at project plan
level, the end stage points, and that stage plan level, control points
such as product completion, quality checking, and authorization or
audit points.
Plan
Define Milestones

The definition of a milestone is a zero duration activity, and similar to

the above, shows key control points. Such milestones may
highlight key review points or early indication of issues, as well as
indicating completion of key aspects within the plan.
Plan
Total Resource Requirements and the Cost

It is at this point for the first time, that resource requirements and other
costs can be calculated to produce the planned as budget. Such a
budget must include the cost of the management and specialist
activities, any optional risk or change budgets, and the cost tolerances.
Plan
Present the Schedule
A project schedule can be presented in the form of Gantt charts,
Project Network Diagrams, or an excel sheet.

PRINCE2 also includes a management document called the product

checklist, which basically is a list of the major products plus key
dates in their delivery within a particular plan. Such dates may
include draft product ready, planned quality check, and approval.
Plan

Analyze The Risks

This activity will run in parallel with all the other steps as risks may be
identified at any point during the creation or update of a given plan.

The main purpose here is having identified risks, their responses and
associated resources are built into the plan so that the risks can be
managed.

By the very act of planning new risks may consist of those related to
the plan itself or the information contained within it.
Plan

Analyze The Risks

This is the final step and leads to the creation of the complete plan
document. Aspects that need to be included here will include the
schedule, the costs, the required controls and supporting text which
will be added here to explain the plan, any constraints on it, external
dependencies and assumptions, monitoring and can trolling activities
along with risk responses.
Plan
Roles and Responsibilities
Corporate Programme management set project tolerances and are
responsible for approving Exception plan when project-level
tolerance are forecast to be exceeded.

Executive approves the project plan and defines tolerance for each
stage and approve the stage plan. Approves the Exception plan when
stage -level tolerance are forecast to be exceeded. Commit
business resources to the stage plan

Senior User ensures that project plan and stage plans remain
consistent from the user perspective and commit user resources to
stage plans

Senior Supplier ensures that project plan and stage plans remain
consistent from the supplier perspective and commit supplier
resources to stage plans
Plan
Roles and Responsibilities
Project Manager prepares the project plan and stage plans and
decides how the management and technical stages are to be applied.
Defines the work package level tolerance and instruct corrective
action when the work package level tolerance are forecast to exceed.

Team Manager prepares the team plans and prepares schedules for
each work package

Project Assurance monitors changes to the project plan to see

whether there is any impact on the project business case.

Project Support assists with the compilation and the

distribution of
plans
Risk

PRINCE2 definition for Risk is as follows

Risk is a set of events that, should they occur, will have an effect
on achieving the project objectives.

Another definition of Risk is:

Risk is an uncertain event that if it occurs, will have a positive or

negative effect on a project objective.
Risk
The purpose of the Risk theme is to identify, assess and control
uncertainty and, as a result, improve the ability of the project to
succeed.

A Risk is a known unknown that impact the outcome of the project

negatively or positively

Effective management of risks prevents them from turning into issues

and this is the primary aim of risk theme. The risk manag ement
involves the process of identifying, assessing planning and
implementing the risk response plan.

A key responsibility of a project manager is to continuously anticipate

risk and respond to them so that they are not converted into issues.

The risks can be positive as well as negative. The positive risks are
based on opportunities and strengths; however the negative risks are
based on weakness and threats.
Risk
How to Express the Risk?

The risk is always expressed in terms of three variables.

• Cause - What is the original cause of the Risk ?

• Event - What is the threat ?

• Effect - What is the risk ?

Farmers’ crops might get damaged due to heavy rain, as fields will get flooded.

What is original cause? The cause is heavy rain.

What is the threat? The threat is that fields might get flooded

What is the risk? The effect if the risk does happen is that the crops will get damaged.
Risk
Identify. First the context of the project is determined to
understand the specific objectives that are at risk, and develop the
risk management strategy.

Assess. The qualitative risk analysis is done by determining the

probability (Likely hood of happening), impact and Proximity (How
soon a Risk might materialize) of the risks. Based on the
multiplication of these two factors urgency of the risk is decided and
risk profiling is done

After the risk profiling is done. The quantitative risk analysis is

conducted for high priority risks only as it is an expensive process.
Techniques such as expected monetary value analysis, decision tree
and sensitivity analysis using tornado diagrams can be used for
quantitative risk analysis.
Risk
Plan - Negative Risks
Avoid. This entails taking some action upfront and hence changing some
aspect of the project such that the risk probability becomes zero and/or
there will be no impact.
Reduce. Another term for this is mitigating the risk and unlike avoid,
taking action to reduce will either reduce probability of happening or
impact of the risk.
Transfer. The risk is transferred to a third party by making it or
responsible for all or some of the financial impact of the risk, and this is
normally done in the form of contract clauses that come into force as a
result of such a risk.
Share .This response is a form of risk sharing between two or more
parties and is normally built into a contract.
Risk
Plan - Negative Risks

Accept. This means taking no response action. This is usually the

response strategy if severity of the risk is less than the cost or
complexity of implementing a response action.

Fallback. This is also called as contingency planning and is different to

the first three in that no action is taken up front. This is a reactive
approach and entails creating a fallback plan with actions to be
implemented only if the risk occurs. For Example a business continuity
and disaster recovery plan.
Risk
Plan - Positive Risks

Exploit. This entails taking some action upfront that will seize the
opportunity ensuring that it will occur and that the positive impact will
be realized.

Enhance. Enhancing a risk involves identifying the root cause of a

positive risk so that you can influence the root cause to increase the
probability of happening of the positive risk.

Reject. It also means you are acknowledging that you’d rather not
Exploit, Share, or Enhance the risk. This is normally chosen much
like the accept response to threats, that is, because it is not
economical to take such an action.
Risk
Plan - Positive Risks

Share. This can be used for both, negative risk (threat) or a positive
risk (opportunity) type of risk. These responses will be included as part
of creating the next stage plan or exception plan. This response is a
form of risk sharing between two or more parties and is normally built
into a contract. It uses some form of a pain/gain formula, and
prescribed limits are used between the parties that divide up either the
financial pain or gain if the opportunity or threat does not materialize.
Risk
Implement and Communicate

Im plem ent. The risk responses identified above, are now

implemented, and how effective each response is will be monitored and
corrected where necessary to achieve the desired effect.

C om m unicate. Unlike the first four sequences above, this is a

parallel and ongoing activity to ensure that information on all of the
threats and opportunities are communicated both internally and
externally to the project. The risks are generally communicated
through time driven reports (such as Highlight Report, Checkpoint
Report and so on) and event driven reports (such as end Stage report,
end Project report and so on)
Risk
The Risk Owner is responsible for managing & monitoring risks
aspects. They can also carry out actions that have been assig ned
to them.

The Risk Actionee is someone who is assigned to carry out a

particular action and they support the Risk O wner. So they are
not responsible for monitoring or managing the risk.

The risk that remains after implementing a response to a particular

risk is called as Residual Risk and the new risk that arise as a
result of response to a particular risk is called as Secondary Risks
Risk
Residual and Secondary Risks

The risk that remains after implementing a response to a particular risk

is called as Residual Risk and the new risk that arise as a result of
response to a particular risk is called as Secondary Risks
Risk
Risk Budget

Risk budget is a sum of money included within the project

budget and set aside to fund specific management responses to the
project’s threats and opportunities (for example, to cover the costs of
any fallback plans should they need to be implemented).
Risk
Risk Tolerance and Risk Appetite

Risk tolerance looks at acceptable/unacceptable deviations from

what is expected.
Risk appetite looks at how much risk a company is willing to accept.
There can still be deviations that are within a risk appetite. A
organization can be a Risk seeker, Risk Neutral or Risk Averse.
Risk tolerance can be related to other tolerance parameters; risk to
completion within time scale and/or cost and to achieving product
quality and project scope within the boundaries of the Business Case.
Perceptions of risk tolerance have to be considered in detail to
establish the optimum balance of a risk occurring against the costs
and value for money of limiting that risk.
Risks
Roles and Responsibilities

Corporate or Programme Management provides the corporate

level policy for the risks

Executive is responsible for ensuring that the risk management

strategy exists and the risks associated with the Business case are
identified, assessed and controlled.

Senior User is responsible for ensuring that risks related to users are
identified, assessed and controlled.

Senior Supplier is responsible for ensuring that risks relating to

supplier aspects are identified, assessed and controlled.
Risks
Roles and Responsibilities

Project Manager creates the Risk Management Strategy, creates and

maintains the risk register. Ensures that the project risks are
identified , assesses and controlled throughout the lifecycle of the
project.

Team Manager participates in the identification, assessment and

control of risks at Work Package level.

Project Assurance review risk management practices to ensure that

they are performed in alignment with the project’s Risk Management
Strategy

Project Support assists the project maintaining the project’s risk

register
C hang e

The purpose of the knowledge in the Change Theme is

to help you identify, assess and control any potential
changes to the products that have already been
approved and baselined. The Change Theme is not
just about handling change requests but also handling
issues that arise during the project. In fact, it is better
to say that the Change Theme provides a common
approach to issue and Change Control.
C hang e
The PRINCE2 Manual uses the Change Theme to
describe how change control should be executed. All
changes are dealt with as a type of project issue. An
issue can be

General issues

Request for Change

Off Specifications.
C hange
General Issues
First of all, any general issue could be dealt with 'face
to-face' if appropriate - logging it as a 'formal' project
issue would be done if that were the best and only
option. As an example, 'general' issues could include:

A question or query

A good idea or a suggestion

An observation

A concern
C hang e
Request for Change

This is a change requested from the Customer/User

side, and would, if implemented, cause a change to
what had been originally agreed, to the Acceptance
Criteria, Specifications/Scope.

It might be a request to add or subtract to the original

agreement. If you were having a house built, two
examples might be you requesting an extra
bathroom, or asking for a dividing wall to be removed.
As such, any extra costs relating to this change should
be paid for by the Customer/Users.
C hang e
Off Specification

This covers errors or omissions either in work already carried out,

or planned for the future. This will result in NOT being able to
meet the originally agreed Acceptance Criteria,
Specification/Scope.

An example similar to above would be if the builder of your new

house advises that they can't include your patio area within the
price. As such, any extra costs (either in re-work to fix the off-
specification, or reducing the price to you), should be met by
the builder. Suppose that (possibly in order to meet your
timescale...) you agreed to accept what the builder could give
you (that is, house without the patio), then in PRINCE2 terms, this
is called a CONCESSION.
C hang e
Change Authority and Change Budget

The Change Authority is a person or a group who consider requests for

change and off-specifications. It is the responsibility of the Project Board,
so they can do it themselves, which is more common where few changes
are expected, or they can assign this to other persons. If a lot of changes
are expected then this will take up too much time from the Project Board
and it is better to give the authority to another person or group of persons

The Change Authority will have a change budget, which is a sum of

money that the customer and supplier agree to use to fund the cost of
Requests for Change. It is advisable to always have a change budget for
each project unless you are sure there will b e very few or no change
requests. The Project Board can still exert control, as they can put a limit
on the cost of a single change or the amount to b e spent in any one stage.
C hang e
There are three types of manag ement product:

Baselines , records and reports .

Baseline management products are those that define aspects of the project and
,once approved are subject to change control. These are;

Benefit Review Plan

Business C ase
Communication Management Strategy
Configuration Management Strategy
Plan
Product Description
Project Brief
Project Initiation
Documentation
Project Product Description
Quality Management Strategy
Risk Management Strategy
Work Package
C hang e
Records are dynamic management Products that maintain information
regarding project progress . These are;

Configuration Item Record

Daily log
Issue Register
Lesson Log
Quality
Register
Risk Register
C hang e
Roles and Responsibilities
Corporate Programme Management provides the corporate level
strategy for change control, issue resolution and configuration
management

Executive determines the change authority and the change budget,

sets the severity ratings and priority for issues, respond to request for
advice from the project manager and make decision on escalated
issues with the focus primarily on continual business justification.

Senior User takes decision on escalated issues with the primary focus
on safeguarding the expected benefits.

Senior Supplier takes decision on escalated issue with primary focus

on safeguarding the integrity of the complete solution
C hang e
Roles and Responsibilities

Project Manager manages the configuration management procedure,

manages issue and change control procedure, creates and maintain the
issue register

Team Manager implements corrective actions for Work Package level

issues

Project Assurance advises on examining and resolving issues

Project Support maintains the configuration item records, produces

product status account and assists the project manager to maintains the
issue registers
Prog res
s To establish how to monitor and then to compare actual
achievements against those planned during the project life cycle.

To provide a forecast for the project objectives and the project's

continued viability.

To be able to control any unacceptable deviations.

Progress is about checking progress compared to the plan,

checking project viability and controlling any deviations.
Prog ress

Three of the seven principles are represented in the Progress

Them e; they are:

Manage by stages: the Project Board is to use stages as a control

point.

Continued business justification, as the Business Case is

continually
checked that the project is still worth doing.

Managed by Exception. Where tolerances are used, refer

certain
issues up to the next management level.
Prog res
set us look at when tolerances can be decided on:
L

Time and Cost Tolerances: These are decided in the Project Plan,
Stage Plans and Work Packages.

Scope Tolerances: Decided in Project Plan, Stag e Plan and Work

Packag e s. Note: Scope chang e s would require chang e control.

Risk tolerances will be first defined in the Risk Management Strategy

document and the Project Board can change risk tolerance for the Stage
Plan. The Project Manager may change risk tolerances for the Work
Package.

Quality Tolerances are defined in the Project Product Descriptions and

the Product Descriptions, as Quality is related to the products.

Benefits tolerances are defined only in the Business Case and this is kept
up to date during the project. The Benefits are also defined in the Business
Case
Prog res
s
The PRINCE2 approach to Progress and the four main controls
provided by PRINCE2: (1) Delegating Authority, (2) Using Stages, (3)
Time & Event-driven reports, and (4) Raising Exceptions
Case
Prog res
s
All controls can be divided into two parts in PRINCE2: Event-Driven
and Time-Driven.
Event-driven controls take place when something happens, in other
words when an event happens in the project. (For example, at the end of a
stage, at complementation of the PID, when a stage goes out of tolerance,
at the end of project and change request. All of these events produce
documents like an End Stage Report, Exception Report and Issue Report.
Time-driven controls take place at pre-defined periodic intervals. For
example, the Project Board will agree with the Project Manag e r to send
a
Highlight Report every 2 weeks to the Project Board, and the Project
Manager can agree with the Team Manager to send a Checkpoint
Report
each week. So time-driven controls don't have to wait for an event to
happen.
Prog res
s
Why are Management Stages used as controls by the Project Board?

Management stages are partitions of the project with decisions points for
the Project Board between each stage. A management stage is a
collection of activities to produce products and is managed by the Project
Manager.

Why are Management Stages important for the Project Board?

They provide review and decision points at end of each stage and before
the next stage. They can authorize one stage at a time, or choose to stop
the project.

They review the End Stage Report of the last stage and Review plan for next
stage.

Then can check project progress compared with baselined Project Plan at
the end of each stage.
Prog ress

The minimum number of stages in a PRINCE2 project is

two: the Initiation Stage to define and agree what needs to
be done, and at least one other stage to produce the
products.
Prog ress

How to decide the number of stages?

This depends on a number of items and as you can see, it’s a bit of a
b alancing act. Start by c onsidering the following

How far ahead is it sensible to plan?

Where do key decision points have to b e made in the project? (Example:

Maybe after creating a prototype or after completion of a major part of the
product. This would b e a good point for stage end.)

The amount of risk and the complexity in a project. (If similar to another
project, then there will b e less.). Higher the risk and complexity more
will b e the number of management stages.

The number of management stages in a project, and is a bit of balancing

act as the more number of management stages provide better control on
the project, however increases the administrative overhead.
Prog ress
Roles and Responsibilities

Corporate programme management provides the project tolerances

and the document them in project mandate and make decisions related to
exceptions when project - level tolerance is forecast to exceed.

Executive provides stage level tolerances and makes decision when stage
level tolerances are forecast to b e exceeded. Ensures that progress
towards the outcome remain consistent from business perspective.
Recommend future action on the project to corporate or programme
management if the project tolerance is forecast to b e exceeded

Senior User ensures that progress towards the outcome remain consistent
from user perspective.

Senior Supplier ensures that progress toward the outcome is

consistent from the supplier perspective
Prog ress
Roles and Responsibilities

Project Manager authorizes the Work Package level tolerances and

monitor progress against the stage plan. Produces highlight reports, End
Stage report, lesson report and end project report. Produce exception
reports when the stage level tolerances are forecast to be exceeded.

Team Manager agrees on work package with the project manager,

produce checkpoint reports and notify the project manager of any forecast
deviation from work package tolerance.

Project Assurance review and verify the business case against

the external events, verify impact on the b usiness case on the
b asis of progress or due to change in the plan.

Project Support assist with the compilation and distribution of

reports, assist the project manager in maintaining the issue and risk
registers.
Thank
You!