Pankaj ppt version 3.0

PRINCE2 Workshop
By
Pankaj Sharma
Author - Pankaj Sharma

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 Objectives

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 1

Themes
Business Case
Organization
Plan
Quality
Risk
Change
Progress
Discussion on Sample Papers
Workshop Agenda – Day 2

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.
What is PRINCE2?

History of PRINCE 2
PRINCE2 methodology was first established in 1989 by the British Government’s
CCTA (the Central Computer and Telecommunications Agency).
The method was originally based on PROMPT, a project management method
created Simpact Systems Ltd in 1975. PROMPT was adopted by CCTA in 1979 as
standard to be used for all government information system projects. When
PRINCE2 was launched in 1989, it effectively superseded PROMPT within
government projects.
Currently PRINCE2 is a registered trademark of Cabinet Office (HM, Govt of
UK) in the United Kingdom and other countries.

PRINCE2 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 common, 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

PRINCE2 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 Examination 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 Format
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 Software

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 Repetitive
Closes after attaining the objectives Objective is to sustain business
Examples are : Launching the new
car model
Examples are : Assembly line
production, Monthly Payroll

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 be 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 be impacted by the programme
structure and the reporting requirements.
Programme Management may be 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."

PRINCE2 Integrated 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

Embedding and Tailoring PRINCE2

PRINCIPLES
Continued 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
Progress

PROCESSES
The seven processes listed below describe the project
lifecycle from getting started to project closure.
Controlling a Stage
Managing Product Delivery
Directing a Project
Closing a Project

PRINCIPLES , PROCESSES AND THEMES

PRINCE2 PROCESS TIMELINE

Processes
PROCESSES

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 Case. 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.

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 Case or a business reason and this should be documented in the
outline Business Case. The Business Case 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.

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 ProjectAuthor - Pankaj Sharma

The Executive is responsible for Appointing the Project Manager, the Project
Management Team and creating the outline Business Case.
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.

The purpose 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?

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 required will be achieved
• How baselines will be established and controlled
• How risks, issues and changes will be identified assessed and controlled
• How progress will be monitored and controlled
• Who needs information, in what format and at what time

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)

Overview of Initiating a Project Process

Prepare the Risk Management Strategy

Prepare the Configuration Management Strategy

Prepare the Quality Management Strategy

Prepare the Communication Management Strategy

Setting up the project controls

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 be 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 be 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 be
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 Work 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 Work 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 Work Package as completed
Review the Stage Plan (current stage) for products to be produced,
cost, effort and tolerances available

Controlling a Stage
Controlling a Stage Overview

Controlling a Stage
Authorize the work package

Controlling a Stage
Review work package, the main input file in this activity is checkpoint
report , a time driven report through which Team manager updates
project manager on the status of work.

Controlling a Stage
Receive completed work package

Controlling a Stage
Review the stage status

Controlling a Stage
Report Highlights, Project Manager uses Highlight reports to update the
Project Board about the stage status.The frequency of these reports is defined
in communication management strategy

Controlling a Stage
Capture and Examine Risks and Issues

Controlling a Stage
Escalate Issues and Risks

Controlling a Stage
Take corrective actions

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 be 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.

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.

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.

Accept a Work Page

Execute a Work Page

Deliver aWork Page

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.

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)

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 Closing a Project Process for the Project Manager 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
Overview – Closing a Project Process

Closing a Project
Prepare Planned Closure – 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

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 Action Recommendations
• Prepare the follow-up on action recommendations for the products.These are mostly taken from the
Issues and Risk Registers.
• Check 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.
Configuration Management
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) Check 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 required by the Project 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
Evaluate the Project
The objective of this activity is to assess how successful or unsuccessful the project was and to learn
from this project.
End Project 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.
o How 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.

Closing a Project
Remember, it is the Project Manager that prepares the project for closure but it is
the Project Board who closes the project or, in PRINCE2 words,“authorizes
project closure.”

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.

Directing a Project

Themes
Themes

Themes – Business Case
The Business Case 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 such as ;
 Mandatory Project: The projects that are initiated to fulfill some government mandate, rules or
regulation.
 Not – for – profit project: The NGO 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 be
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 be 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 Pre-Project; it is refined in
initiation stage. It is then verified and updated at the critical
points during the project, such as at the end of delivery stages.

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 gather 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 Management and will update the Benefits Review Plan.
And after the project is completed, the Corporate or Program Management
will be responsible for the Benefits Review Plan.They have the responsibility
of following up to ensure that the benefits have been realized.

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.

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.

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.

Project Assurance
Project Assurance provides a kind of audit service on each project
to check that it is progressing as planned.
From a Business Case 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
Create a sample Business Case for a CRM Project.
0R
Create a Sample Business Case for project that involve
construction of three high rise residential towers

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

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 Communication Management Strategy
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 & techniques, such as e-mail, intranet, newsletter.
 Reporting: Types of reports and the information they should contain.
 Timing states when communication activities will be 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
They appoint the Executive and possibly the Project Manager.
They can also provide some information for the project as will be defined in
the Communication Management Strategy document.
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
Project Manager
Preparing the Communication Management Strategy
Reviewing and updating the Project Management structure
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 be realized as a result of the project will not be 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 be 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
Quality 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
Quality Methods
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, integration 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 be 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
Below is the example of sample 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
against 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)
Check 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, deciding 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)

Quality
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.

Quality
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.

Quality
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 targets for time, cost, quality, scope, risk and benefits
Provides a baseline against which progress can be measured.

Plan
PRINCE2 recommends three levels of plan
Project
Stage
Team plans (Optional)
The first plan to be created in PRINCE2 is an initiation stage plan; this
plan is created in starting up a project process.

Plan
PRINCE2 uses the principle of management by exception.Whenever a plan
is forecast to exceed the allowed tolerance, then an exception report must be
created , the purpose is to effectively utilize the managements time.
If required, an exception plan will now be 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 be 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 be exceeded, then
an issue is raised to bring this to the attention of the project manager, who will
determine if this issue can be 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
Write the Project Product Description
Create the Product Breakdown
Structure
Write the Product Description
Create the Product Flow Diagram
Product Based Planning Technique

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
Create Product Breakdown Structure

Plan
Each product description must include the following information
Description of the product
Quality Criteria
Quality Method
Tolerances
Producer
Approver
Reviewer

Plan
Create Product Flow Diagram

Plan
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.
Identify Activities and Dependencies

Plan
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
Prepare Estimates

Plan
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
Prepare The Schedule

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
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.
Assess and Assign Resources

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
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.
Agree On Control Points

Plan
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.
Define Milestones

Plan
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.
Total Resource Requirements and the Cost

Plan
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.
Present the Schedule

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
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
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 an uncertain event that can 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 management
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
The PRINCE2 procedure for risk management is summarized as
follows;
Risk

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

Risk
Plan
This is where appropriate responses for each of the threats
and opportunities are identified in order to reduce the
former and maximize the latter. Following are the strategies
for negative and the positive risks.
Negative Risks Positive Risks
Avoid Enhance
Reduce Exploit
Transfer Reject
Accept
Fallback
Share Share

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
Implement. 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.
Communicate. 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 assigned to
them.
 The Risk Actionee is someone who is assigned to carry out a
particular action and they support the Risk Owner. 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
 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
 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

Change
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.

Change
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.

Change
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

Change
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.

Change
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.

Change
Possible Options – Request for Change
Approve the Change
Reject the Change
Defer Decision
Request for more information
Ask for an Exception Plan
If a request for
change requires an
additional cost there
are following ways to
fund it
- Use Change Budget
- Increase the Project
Budget
- De Scope other
element of the Project
Budget

Change
Possible Options – Off Specification Management
Grant a Concession
Instruct that Off- Specification must
be resolved
Defer Decision
Request for more information

Change
Possible Options – Problems/ Concern Management
Provide Guidance

Change
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 be 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 be spent in any one stage.

Change
There are three types of management 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 Case
 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

Change
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

Change
Reports are management Products providing a snapshot of the status of certain
aspects of the project. These are;
 Checkpoint Report
 End Project Report
 End Stage Report
 Exception Report
 Highlight Report
 Issue Report
 Lesson Report
 Product Status Account

Change
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

Change
olesanResponsibiliti
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

Progress
 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.

Progress
Three of the seven principles are represented in the Progress
Theme; 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.

Progress
Let us look at when tolerances can be decided on:
Time and Cost Tolerances: These are decided in the Project Plan, Stage
Plans and Work Packages.
Scope Tolerances: Decided in Project Plan, Stage Plan and Work Packages.
Note: Scope changes would require change 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

Progress
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

Progress
 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 Manager 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.

Progress
Delegating Tolerance and reporting process

Progress
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.

Progress
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.

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
balancing act. Start by considering the following
How far ahead is it sensible to plan?
Where do key decision points have to be made in the project? (Example:
Maybe after creating a prototype or after completion of a major part of the
product. This would be a good point for stage end.)
The amount of risk and the complexity in a project. (If similar to another
project, then there will be less.). Higher the risk and complexity more will
be 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.
Progress

Progress
 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 be 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 be 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

Progress
 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 business case on the basis 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.

ThankYou!

Pankaj ppt version 3.0

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (20)

Semelhante a Pankaj ppt version 3.0

Semelhante a Pankaj ppt version 3.0 (20)

Último

Último (20)

Pankaj ppt version 3.0