®

Implementing PRINCE2
A case study for the PRINCE2® Foundation and Practitioner course.

Disclaimer

• The scenario presented is completely a work of fiction.

• No rights can be derived by using this case study.
• Please use this as an example only.
• Simplilearn doesn’t hold any responsibility of your project’s failures or incidents if
you follow this case study.

PRINCE2® is registered trademark of AXELOS Limited, used under permission of AXELOS

Limited. All rights reserved.

AXELOS® is a [registered] trade mark of AXELOS Limited, used under permission of AXELOS
Limited. All rights reserved.
Table of Contents
1. Introduction .........................................................................................................................................3
1.1. Search Service Provider ................................................................................................................3
1.2. Organization Structure ..................................................................................................................3
2. Background..........................................................................................................................................4
2.1. Current Business Process .............................................................................................................4
2.2. Problem Statement ........................................................................................................................4
2.3. Solution .............................................................................................................................................5
3. PRINCE2 Implementation .................................................................................................................6
3.1. Tailoring Considerations ...............................................................................................................6
3.1.1. Role Assignments ...................................................................................................................6
3.1.2. Principles ..................................................................................................................................6
3.1.3. Themes .....................................................................................................................................6
3.1.4. Processes..................................................................................................................................7
3.1.5. Terminology .............................................................................................................................7
3.1.6. Tools and Techniques ............................................................................................................7
3.2. Pre-Project Phase ...........................................................................................................................8
3.2.1. Starting Up a Project Process ..............................................................................................8
3.2.2. Directing a Project After Starting Up a Project Process ...............................................11
3.3. Planning Phase – Initiation Stage (Management Stage 1 in the Project) .........................12
3.3.1. Initiating a Project Process (Initiation Stage) ..................................................................12
3.3.2. Managing Stage Boundary After Initiating a Project Process .....................................19
3.3.3. Directing a Project After Initiating a Project Process ....................................................21
3.4. Project Execution Phase – Management Stage 2 ..................................................................22
3.4.1. Controlling a Stage ...............................................................................................................22
3.4.2. Managing Product Delivery ................................................................................................28
3.4.3. Directing a Project During Project Execution Phase .....................................................29
3.4.4. Managing Stage Boundary towards the end of a Management Stage .....................31
3.4.5. Next Steps ..............................................................................................................................33
3.5. Project Closure Phase..................................................................................................................35
3.5.1. Closing a Project ...................................................................................................................35

1|Page
4. Conclusion..........................................................................................................................................41
4.1. Conclusion Remarks ....................................................................................................................41
5. References .........................................................................................................................................42
5.1. References .....................................................................................................................................42

2|Page
1. Introduction

1.1. Search Service Provider

The customer is a search service provider that offers its services on mobile and web.
The end users are required to call a hotline number, provide their email id, ask the
operator for the service they are looking for (e.g. restaurants, banks etc.) and specify
the area. In turn, the operator will send them an email and a text message with the
information. Apart from this, customers can search for the information of any specific
business on the Website and Mobile Application.

The customer has approximately 890 employees working across the country from 9
regional offices in various cities and several area offices in various towns. Marketing
department team members will call the shops and establishments to get their consent
to meet Field Sales team members. The field sales team members visit given shops and
establishments and collect details such as services offered, contact numbers, hours of
operation etc. on a day-to-day basis.

1.2. Organization Structure

The following is the customer’s organization structure relevant to this case study. VP
indicates Vice President and IT indicates Information Technology.

Chief Executive
Officer

Company
VP - Marketing VP - Sales VP - IT VP - Operations
Secretary

Regional Regional Support Call Centre Data Centre

IT Manager
Manager Manager Manager Managers Manager

Area Sales Site 24*7 Support

Area Manager Team Leads Team Leads
Manager Administrators Team

Network and
Field Sales team Database
Team Leads Infrastructure Team Members Team Members
members Administrators
Team

Development
Team Members
Team

Figure 1.2-3.1.1-1 Organization Structure

3|Page
2. Background

2.1. Current Business Process

Every day, the Field Sales area managers get inputs from their marketing counterparts.
Area Managers will allocate the Field Sales team members to meet and engage with
potential leads. The expenses incurred for these assignments, such as fuel, travel
charges, purchase of any stationary items, informal discussions over
tea/coffee/lunch/drinks with potential leads, etc., are borne by Field Sales team
members and later reimbursed by the customer.

On a monthly basis, Field Sales team members will collate their expenses and submit a
printed form with relevant attachments. Field Sales team members will get this
approved by their respective Area Managers first. The Office Administrator will collect
all the expense reimbursement forms, do an initial verification of expense claimed
versus bills submitted and courier them together to their respective regional office.

At the regional offices, Regional Managers will review the received expense
reimbursement forms and then process them. After that, the forms are sent to Head
office for final review and approval. The payouts to respective Field Sales team
members happen in subsequent payroll cycle.

Customer has laid policies for approval of reimbursement of these expenses. The
following table illustrates the expenses reimbursement policy.

Expense Range Approver 1 Approver 2 Approver 3

Less than £500 Area Manager Not required Not required
Between £501 to £800 Area Manager Regional Manager Not required
Above £801 Area Manager Regional Manager VP – Sales
Table 2.1-1 Expenses reimbursement approval policy

2.2. Problem Statement

Office Administrators are overwhelmed by the number of expense reimbursement
forms that have to be validated. Because of this, most of the times, the Office
Administrators courier the collected expense reimbursement forms only after a week.
A few times, the expenses forms submitted by the Field Sales team members along with
relevant attachments are misplaced by courier companies. Tracking these reports is a
herculean task.

4|Page
A few Field Sales team members have started leaving the organization due to delay in
getting their expenses reimbursed. It is estimated that about 12% of Field Sales team
members have left the organization.

A lot of negative articles have started appearing on social media and job search sites –
discouraging potential new employees from joining the organization.

2.3. Solution
Chief Executive Officer took note of the situation and asked the VP – Sales to come up
with a solution. VP – Sales discussed with VP – IT and came up with the idea of digitizing
the expense reimbursement forms and doing away with paper-based forms. VP – IT
suggested that the IT team will be able to do this digitization internally.

Chief Executive Officer agreed to this solution and stressed the need for ensuring that
company’s money is not wasted as the IT Team may take this as a learning opportunity
at company’s expense. Chief Executive Officer also insisted on following the well-
established 3 level governance meetings and reviews.

5|Page
3. PRINCE2 Implementation

3.1. Tailoring Considerations

From the given information, this project will be done internally. Therefore, this project
can be classified as a simple and small project.

3.1.1. Role Assignments

• For this small project, there is no dedicated Corporate or Programme
management layer. Chief Executive will operate at Programme management
layer.
• VP – Sales will play the role of both Executive and Senior User. VP – Sales will
be assisted by Regional and Area Sales Managers from Requirements and
User Assurance perspective.
• VP – IT will play the role of Senior Supplier.
• VP – Marketing and VP – Operations are also considered Senior Users as
their inputs are required for the project.
• IT Manager will act as Project Manager and Project Support.
• The IT Development Team Member with most experience will work as a
Team Manager.
• VP – Sales delegated Change authority for small Requests for Changes that
cost less than £300 to the Project Manager. Any Request for Change
exceeding £300 will be reviewed by VP – Sales and Chief Executive Officer.
• Chief Executive Officer’s Company Secretary will play the role of
independent Quality Assurance and Business Assurance.
• IT Support Manager is designated to play the role of Supplier Assurance.

3.1.2. Principles
• Principles can’t be tailored. All 7 Principles are applicable as they are.

3.1.3. Themes
• For this small project, the Project Manager proposed to follow the minimum
management products required for each theme as mandatorily to be
created and maintained.
• Other management products that may be used in the Project are arrived at
during Initiating a Project process.
• The management products required for each theme are as follows:
o Business Case
▪ Business Case

6|Page
 ▪ Benefits Management Approach
o Organization
▪ Project Initiation Documentation
▪ Communications Management Approach
o Quality
▪ Quality Management Approach
▪ Quality Register
o Plans
▪ Project Product Description
▪ Product Description
▪ Product Breakdown Structure
▪ Project Plan and Stage Plan
o Risk
▪ Risk Management Approach
▪ Risk Register
o Change
▪ Issue Register
▪ Change Control Approach
o Progress
▪ Lessons Report

3.1.4. Processes
• All processes will be followed as they are.

3.1.5. Terminology
• Project Brief will be renamed as Project Feasibility Study.
• Project Support will be termed as Project Administration.

3.1.6. Tools and Techniques

• PRINCE2’s recommended techniques, such as Quality Review Technique, will
be followed.
• Microsoft Project software will be used to create the necessary Plans. All
Plans will have Gantt Chart-style presentation.
• For Corporate-level reviews with Chief Executive Officer, Critical Path
Method diagram will be used along with Project Milestone chart.
• All project documents will be stored on a Microsoft SharePoint site.
• Project Source code will be stored and managed on an open-source source
control system GitHub.

7|Page
3.2. Pre-Project Phase

3.2.1. Starting Up a Project Process

3.2.1.1. Appoint the Executive and Project Manager

• For this project, Executive (VP – Sales) has already been identified and
appointed during project’s conception.
• Project Manager (IT Manager) has also been identified and appointed by
Executive.

3.2.1.2. Gather Previous Lessons

• Project Manager will seek to gather lessons learned from similar projects.
• Sources for lessons learned are:
o Project team members
o Organizational units such as Project Management Office (PMO) if
one exists, Centre of Excellence if one exists, etc.
o Internet
• Project Manager will record the relevant lessons for this project in the
lessons log.

3.2.1.3. Design and Appoint Project Management Team

• For this small project, all required roles are already taken.
• Project Manager will prepare job descriptions for each role, get them
reviewed by Project Board, share them with the relevant individuals who
are going to play those roles and get their consent.
• If any concerns are raised by the individuals selected to play roles in the
project, such as their availability, lack of knowledge if any etc., Project
Manager will make a note in Daily Log as issues or risks.

3.2.1.4. Prepare Outline Business Case

• Outline Business Case is prepared by Executive.
• Outline Business Case gets a few inputs (for example, timescales and cost)
from Project Approach. Therefore, in most cases, the Outline Business
Case and Project Approach design will be carried out simultaneously.

3.2.1.5. Select the Project Approach and Assemble the Project Brief
• Project Approach answers these critical questions on how the work of the
project is going to be approached:
o Will the solution be developed in-house or contracted to a third

8|Page
 party?
o Will the solution be a modification to an existing product or built
from scratch?
o Will the solution be based on a commercial off-the-shelf product
(often referred to as a COTS) or something that is custom-designed?
o What delivery approaches should be used? Will the delivery
approach use agile working methods (for Software projects)?
• For this project:
o The IT team is going to develop the software, and no commercial
off-the-shelf (COTS) software will be used
o Delivery approach will be non-agile (this project doesn’t need an
iterative approach as the scope of the project is mostly known and
fixed. Agile approach is most suitable when scope is volatile, i.e.,
scope keeps on changing during the project)
• While preparing the Project Approach, the Project Management team
evaluates the possible delivery solutions and decides upon the project
approach appropriate to delivering the project product and achieving the
outline business case.
• Project Brief is assembled by
o Defining the project, i.e., confirming the status of the project –
background and any preparatory work carried out so far
o Confirming the objectives and desired outcomes
o Confirming ‘in scope’ and ‘out of scope’ deliverables
o Identifying constraints and assumptions
o Identifying project-level tolerances on cost, timelines, quality, scope,
benefits and risk (the six project objectives that must be monitored
and controlled)
o Carrying out stakeholder identification and identifying impacted
users
o Embedding Outline Business Case (i.e., a link to Outline Business
Case)
o Embedding the Project Product Description (which contains Project-
level scope and quality expectations)
o Embedding the Project Approach
• For this project:
o Project Brief is termed Project Feasibility Study.

3.2.1.6. Plan the Initiation Stage

• Initiating a Project consumes both time and resources.
• The work to be carried out in ‘Initiating a Project’ stage must be planned
9|Page
 and approved so that initiation is not aimless and unstructured.
• Based on Project Approach, suitable management controls must be
decided for initiation
• Initiation Stage Plan that will outline the work to be carried out during
Project initiation must be produced.
• For this project:
o Hosting environment will be identified and hardware and software
requirements will be finalized – this work is planned, reviewed and
authorized by Project Board and later carried out during initiation.
o Procurement requirements such as new hardware, servers,
document scanners, team recruitment if required, etc. are planned
and approvals are sought to carry out this work during initiation
o Creation of Project management approaches, i.e., Risk
Management Approach, Quality Management Approach, Chance
Control Approach and Communication Management Approach is
planned and assigned to appropriate resources

3.2.1.7. Next Steps

• Project Manager seeks authorization of Initiation Stage of the Project (i.e.,
to execute Initiating a Project process) from Project Board.
• Project Board operates in ‘Directing a Project’ process and uses the activity
‘Authorize Initiation’ to authorize initiation.
• This is shown diagrammatically below.

Figure 3.2.1-1 Next steps from Starting Up a Project process

10 | P a g e
 3.2.2. Directing a Project After Starting Up a Project Process

Please note, in this case study, activities in Directing a Project are not shown together.
They are shown as they happen during PRINCE2® Project process flow.
For this reason, Directing a Project process will be presented multiple times with
relevant activities.

3.2.2.1. Authorize Initiation

• Project Board will review and approve Project Brief, Project Product
Description and Initiation Stage Plan
• Project Board will also verify that Outline Business Case demonstrates a
viable project
• Project Board will notify all relevant stakeholders that project is being
initiated
• For this project:
o Project Board will review Project Feasibility Study (i.e. Project Brief),
Project Product Description and Initiation Stage Plan and approve
them.
o Project Board will also verify Outline Business Case.

3.2.2.2. Next Steps

• Project Board will authorize the Project Manager to carry out Initiation
Stage
• This is shown diagrammatically below.
• ‘Initiating a Project’ is presented in detail in the next section.

11 | P a g e
 Figure 3.2.2-1 Next steps from Authorize Initiation activity in Directing a Project process

3.3. Planning Phase – Initiation Stage (Management Stage 1 in the Project)

3.3.1. Initiating a Project Process (Initiation Stage)

3.3.1.1. Agree on Tailoring Requirements

• Tailoring requirements for the project are planned in detail, documented
in Project Initiation Documentation (PID) and presented to Project Board
for review and approval
• For this project:
o Role assignment tailoring has already been presented earlier in
3.1.1 Role Assignments
o To meet the 3-level governance requirements proposed by Chief
Executive Officer (operating at Programme Management layer), the
following tailoring requirements are considered:
▪ Project must have a weekly Level 1 governance review.
Project Board must lead this review.
▪ End-Stage Reports (prepared at the end of a Management
Stage in PRINCE2) will be shared with Programme
Management and reviewed.
▪ Monthly Programme-level review at Level 2 governance will
12 | P a g e
 include review of this project.
▪ If the project duration exceeds more than 6 months, the
Project’s performance will be subject to company-level half-
yearly review at Level 3 governance
o PRINCE2’s CheckPoint Reports will be delivered informally by the
Project Manager by an email.
o Any new recruitment must be reviewed and approved by
Programme Management layer.

3.3.1.2. Prepare the Risk Management Approach

• Project Manager will review existing management products – Daily log,
Outline Business Case, Project Brief and Lessons log for risks that have
already been identified
• Project Manager will define Risk Management Approach and set up Risk
Register
• For this project:
o Project Manager will prepare Risk Management Approach using
PRINCE2’s recommended 5-step Risk Management process as the
project’s Risk Management process
▪ Risk checklist will be used as risk identification technique and
probability tree will be used as risk assessment tool.
▪ Scales will be defined for Probability and Impact.
▪ Proximity will be defined.
▪ Risk categories will be identified and recorded.
▪ Timing of Risk Management activities will be discussed and
reviewed by relevant stakeholders and recorded.
▪ Roles and Responsibilities for Risk management will be
identified and discussed with individuals who will play those
roles. The project manager will get their agreement to play
those roles.
o Project Manager will setup Risk Register and copy already identified
risks from other management products such as Daily log, Outline
Business Case, Project Brief and Lessons log.

3.3.1.3. Prepare the Quality Management Approach

• Project Manager will review Project Product Description to understand
customer’s quality expectations and will check if acceptance criteria are
sufficiently defined.
• Project Manager will review Project Brief for any applicable quality
standards and processes, as required by Corporate or Programme
13 | P a g e
 Management.
• Project Manager will prepare Quality Management Approach and set up
Quality Register
• For this project:
o Project Manager will prepare Quality Management Approach with
Quality Management process or procedure relevant to this project.
This following will be identified, reviewed and agreed with Project
Board and documented:
• Quality control activities, such as peer review of code,
unit testing using an automated tool, template for
raising defect and relevant defect metrics
• Project assurance responsibilities of the Project Board
and compliance audits to be carried out in the project
▪ Tools and techniques, such as usage of SonarQube for
continuous code quality, will be identified, reviewed with
Senior Suppliers, agreed on and documented.
▪ Records, such as approval of products by email and project
sign-off in format given by customer, will be agreed on and
documented.
▪ Reporting, such as weekly issue summary report (in PRINCE2,
defect is known as Off-specification, a type of issue) using
customer’s standard template, will be agreed on and
documented.
▪ Timing of quality management activities, such as peer review
of code, schedule of testing, PRINCE2’s Quality Review
Technique used at the end of each management stage, etc.,
will be reviewed and agreed on by Project Board and
documented.
▪ Roles and Responsibilities, such as Regional and Area Sales
Managers playing the role of reviewers, VP – Sales as
approver, will reviewed with individuals who are going to play
those roles, agreed on and documented
o Project Manager will also prepare Quality Register and populate
planned quality events such as Peer reviews, quality review
techniques and other testing activities

3.3.1.4. Prepare the Change Control Approach

• Project Manager will review tailoring requirements and their impact on
change control
• Project Manager will prepare Change Control Approach and set up Issue
14 | P a g e
 Register
• For this project:
o Project Manager will prepare Change Control Approach with
PRINCE2’s recommended 5-step process (Capture-Assess-Propose-
Decide and Implement) as this project’s issue and change control
procedure.
▪ Issues will be raised by email and fish-bone diagrams will be
used for issue assessment.
▪ The issue register will have a custom calculated column ‘Age
of Issue’ that is automatically calculated as the difference
between the data the issue was raised and the date it was
resolved.
▪ Weekly issue summary report will have reporting
requirements.
▪ The timing of issue management and change control
activities will be discussed during weekly change control
meetings.
▪ Roles and Responsibilities for issue and change control will
be reviewed and agreed on by individuals who are going to
play those roles and will be documented
▪ Scale definition for priority and severity will be reviewed and
agreed on by relevant project stakeholders and documented.
o Project Manager will also set up Issue Register with necessary
PRINCE2 recommended columns and the custom calculated
column ‘Age of Issue’ as outlined above.

3.3.1.5. Prepare the Communication Management Approach

• Project Manager will review tailoring requirements and their impact on
communication management
• Project Manager will also review Project Brief to understand whether any
Corporate or Programme Management standards, policies, or templates
related to communication are applicable to the project
• Project Manager will also undertake a series of activities to:
o Identify and review stakeholders, consult them for their information
needs and decide on communication channels to be used
o Establish the information needs associated with quality
management approach (for example, who should receive weekly
issue summary report), risk management approach (for example,
who should be informed if a new risk is identified) and change
control approach (for example, who should be receiving the
15 | P a g e
 schedule of Request for Changes deployments)
• Project Manager will set up Communication Management Approach
• For this project:
o Project Manager will set up Communication Management Approach
with:
▪ Communication procedures to be used in the project, such as
formal notifications versus informal notifications
▪ Tools and techniques for communication to be used in the
project, such as email broadcast, release of updates on a
SharePoint site, etc.
▪ Records for communication, such as minutes of meeting
applicable to the project
▪ Reporting on communication activities
▪ Timing of communication activities, such as publishing
change request status, project review meetings, etc.
▪ Roles and responsibilities for communication reviewed and
agreed on by those individuals who will be playing those roles
▪ Stakeholder analysis, which includes identification of
interested parties, current relationship, desired relationship,
interfaces, key messages to be delivered, etc.
▪ Information needs of each interested party

3.3.1.6. Setup the Project Controls

• Project controls include:
o The frequency and format of communication between the project
management levels, i.e., various levels of management (as per
Organization theme)
o The number of management stages and hence end stage
assessments (as per Plans theme)
o Mechanisms to capture and analyze issues and changes (as per
Change theme)
o Mechanisms to monitor tolerances and escalate exceptions (as per
Progress theme)
• For this project:
o Tolerances on six objectives of the project will be confirmed with
respective management levels
o Delegation of decision-making between various management
layers will be confirmed
o Project and Stage reviews, meetings (including the Chief Executive
Officer’s requirement of 3 level governance), etc., will be agreed
16 | P a g e
 upon and documented in Project Initiation Documentation (PID)

3.3.1.7. Create the Project Plan

• Project Manager will:
o Decide on the format and presentation of the project plan in
consultation with project board
o Identify any planning and control tools to be used by the project
o Choose the methods for estimating
o Review the management approaches (Quality, Risk, Change Control
and Communication) to estimate and plan the resource
requirements to carry out relevant activities for those management
approaches (for example, preparing and sharing Weekly Issue
summary report needs time and effort, which must be estimated)
o Create Product Breakdown Structure and Product Descriptions for
major products using Product based planning technique
• For this project:
o Project Board wanted to use Microsoft Project Plans in a Gantt chart
format for presentation of Project and Stage Plans. Therefore,
Project Manager prepares the Project Plan in Microsoft Project
software
o The customer already has expertise in Function point estimation.
Therefore, Project Manager has chosen Function point estimation
as the estimation method, discussed with Board and received their
approval
o Project Manager created Product Breakdown Structure and Product
Descriptions for major deliverables
o Though Product Flow diagram is not a mandatory Management
Product as per PRINCE2, Project Manager wanted to create Product
Flow diagram to sequence the major products to be created

3.3.1.8. Refine the Business Case

• The Outline Business Case created in Starting Up a Project process will
have less details as not much information about the project would be
available at that time
• In Initiating a Project process, there would be more details available. The
Outline Business Case will be revised with more details and it becomes
(Detailed) Business Case.
• Benefits Management Approach also will be created along with (Detailed)
Business Case.
• For this project:
17 | P a g e
 o Project Manager will revise existing Outline Business Case with
▪ The cost and timelines as calculated in the Project Plan
▪ The major risks that affect the viability and achievability of the
project
▪ The benefits to be gained along with their tolerances (for
example, reduction in attrition from 12% to 6% in next 6
months)

3.3.1.9. Assemble the Project Initiation Documentation (PID)

• The Project Initiation Documentation will contain
o Project management team structure and role descriptions
o Business case (a reference or link)
o Quality Management Approach (a reference or link)
o Change Control Approach (a reference or link)
o Risk Management Approach (a reference or link)
o Communication Management Approach (a reference or link)
o Project Plan (a reference or link)
• It also includes reference to project controls and how the project has
tailored PRINCE2

3.3.1.10. Next Steps

• Initiating a Project is also a management stage
• Therefore, at the end of management stage, Project Manager will visit
Managing Stage Boundary process to prepare Stage Plan for upcoming
stage
• After preparing the Stage Plan for upcoming stage in Managing Stage
Boundary process, Project Manager will visit Directing a Project process to
obtain authorization to deliver the project (green line in the diagram)
• This is shown diagrammatically below

18 | P a g e
 Figure 3.3.1-1 Next Steps from Initiating a Project process

3.3.2. Managing Stage Boundary After Initiating a Project Process

Please note, in this case study, activities in Managing Stage Boundary are not shown
together. They are shown as they happen during PRINCE2® Project process flow.
For this reason, Managing Stage Boundary process will be presented
multiple times with relevant activities.

3.3.2.1. Plan the Next Management Stage

• The stage plan for the next management stage is produced near the end
of the current management stage
• Project Manager prepares the Stage Plan for next management stage by
19 | P a g e
 o Reviewing the components of Project Initiation Documentation
(PID) to update, if necessary, changes in customer’s quality
expectations, acceptance criteria or project approach
o Documenting changes to project management team and their role
descriptions (For example, some team members may not continue
for next management stage if they have resigned or if their skill is
not needed for developing products in the next management stage)
• For this project:
o The upcoming Management Stage is the first stage in Delivery (i.e.,
Project Execution phase)
o Project Manager will prepare Stage Plan by
▪ Describing the plan, i.e., it is for the management stage
▪ Documenting the prerequisites that must be in place for the
plan to succeed, such as confirmed availability of
development team members, necessary development
environment and development tools
▪ Identifying and documenting external dependencies, such as
any new team members who are recruited for the project –
as they may or may not join on time or they may not join at
all
▪ Outlining the delivery approach, such as waterfall or agile (for
this project, it is waterfall approach)
▪ Listing the lessons incorporated, such as impact of
ambiguous requirements on quality from previous projects
▪ Establishing monitoring and controlling mechanisms for this
plan, such as weekly status meetings, end stage reviews, etc.
▪ Documenting the budget – time, cost, change and risk. For
this project, this stage plan will contain the duration of the
stage, the cost for developing the products of the stage and
change and risk budgets as necessary
▪ Listing out tolerances, such as Stage cost can be £4500 to
£5500, duration can be 3 to 4 weeks, etc.
▪ Writing Product Descriptions that capturing the scope of
deliverables of this plan along with applicable quality
tolerances, such as the format of online expense
reimbursement form
▪ Presenting a schedule for the plan in the form of Gantt Chart
(please note that it was agreed earlier that Microsoft Project
Plans will be used with Gantt Chart format for this Project)

20 | P a g e
 3.3.3. Directing a Project After Initiating a Project Process

Please note, in this case study, activities in Directing a Project are not shown together.
They are shown as they happen during PRINCE2® Project process flow.
For this reason, Directing a Project process will be presented multiple times with
relevant activities.

3.3.3.1. Authorise the Project

• Project Board must confirm that
o an adequate and suitable business case exists and that it shows a
viable project
o the project plan and the benefits management approach are
adequate to deliver the business case
o the project’s approaches and controls support delivery of the
project plan
o the mechanisms for measuring and reviewing the projected
benefits are established and planned
• For this project:
o Project Board will review and approve Project Initiation
Documentation (PID) by
▪ Confirming that project definition is accurate and complete
and that the project approach is achievable
▪ Confirming the management approaches are appropriate for
the project and sufficient measures are in place for managing
Quality, Risk, Change and Communications
▪ Confirming that all members of the project management
team have agreed on their roles
▪ Reviewing and approving Product Descriptions (i.e. scope of
the plan)
▪ Obtaining or committing resources needed for the project
and releasing them on a stage-by-stage basis to the Project
Manager

3.3.3.2. Next Steps

• There are two possibilities as next steps after ‘Authorise Project’ activity in
Directing a Project process
o If the Project Board authorises the project, Project Manager will
begin Project Execution phase by launching the next management
stage (it is Stage 2 in the project after Initiation as Stage 1)

21 | P a g e
 o If the Project Board doesn’t authorise the project, Project Manager
must close the project prematurely
o This is shown diagrammatically

Figure 3.3.3-1 Next steps from Authorise Project activity in Directing a Project process

3.4. Project Execution Phase – Management Stage 2

3.4.1. Controlling a Stage

3.4.1.1. Authorise a Work Package

• A work package covers the work to create one or more products
• To create a Work Package, Project Manager
o Examines current Stage Plan to understand the products to be
created, cost and effort that the work is expected to consume along
with tolerances available
o Examines Project Initiation Documentation (PID) to understand the
project control requirements, quality standards required and
product handover procedures if any
• For this project:
o Project Manager will create Work Packages by

22 | P a g e
 ▪ obtaining the relevant product descriptions, i.e. scope for
inclusion in the work package
▪ defining the techniques and processes and procedures to be
used such as code review, source control tools, procedure for
moving code from Development to Quality and to Production
environments
▪ defining the development interfaces to be maintained
▪ defining the operational and maintenance interfaces to be
maintained such as post project support interfaces
▪ defining the change control requirements such as how to
raise issues, how to prioritize them and how Request for
Changes will be assessed
▪ defining the approval method for the Work Package such as
how to obtain sign off for completed deliverables
o Project Manager will review Work Packages with relevant Team
Managers to ensure that they accept that and authorize them to
begin work and review their Team Plans

3.4.1.2. Review Work Package Status

• Project Manager receives Checkpoint Reports that are prepared by
relevant Team Managers and reviews Work Package status
• Risk and Issue registers are updated as required
• Stage Plan is also updated with actuals to date, forecasts and adjustments
• For this project:
o Checkpoint Reports will be delivered informally by email (as agreed
earlier)
o Weekly Status meetings will be held to review Work Package status
o Weekly issue summary report will be reviewed and shared

3.4.1.3. Receive completed Work Packages

• Project Manager ensures that the team manager has completed the work
defined by the work package
• Project Manager checks that the quality register entries relating to the
product(s) are complete
• Project Manager liaisons with Senior Users to ensure that each product in
the work package has gained its requisite approval
• Project Manager also updates the Stage Plan to show that the Work
Package is completed
• For this project:
o Project Manager will check with Team Manager for completed Work
23 | P a g e
 Package and verify with Regional and Area Sales Managers
o Team Manager will update Quality Register with the status of
completed Quality activities, and Project Manager will verify the
same

3.4.1.4. Review the Management Stage Status

• Project Manager reviews Management Stage status by
o reviewing checkpoint reports for the period
o reviewing the current stage plan forecast and actuals
o requesting a product status account from project support to
identify any variation between planned progress, reported progress
and actual progress
o checking issue, risk and quality registers
o assessing utilisation of resources
• For this project:
o The informal email replacing Checkpoint report will be reviewed by
the Project Manager
o As Project Manager is also playing the role of Project Support,
Project Manager will update Product Status Account for stage’s
deliverables and seek assistance of User Assurance for an
independent review
o As per Chief Executive Officer’s (Executive) instruction, the Project
Manager provide resource utilization reports regularly

3.4.1.5. Report Highlights

• Project Manager prepares Highlight reports by assembling the
information from the checkpoint reports, risk register, issue register,
quality register, lessons log, product status account and any significant
revisions to the stage plan for the current reporting period
• For this project:
o Because Checkpoint reports are replaced by informal email reports,
Highlight Reports are essential to keep Project Board and other
relevant stakeholders updated about project progress

3.4.1.6. Capture and Examine Issues and Risks

• Informal issues are recorded in daily log, whereas formal issues are
recorded in Issue Register
• For issues to be managed formally, agreed Issue Management process is
used
• If Team Managers forecast any tolerance deviation, they raise an Issue to
24 | P a g e
 the Project Manager.
• For this project:
o As outlined earlier, when an issue raised by email is a problem or
concern, fishbone diagrams will be prepared for its root cause
analysis
o Project Manager will operate within delegated Change Management
guidelines, i.e. any Request for Change that is estimated to cost less
than £300 will be handled by the Project Manager by notifying
Project Board
o For identified risks, agreed PRINCE2 recommended Risk
Management Process will be followed

3.4.1.7. Escalate Issues and Risks

• When an issue is captured or risk is identified, Stage Plan and Project Plan
are reviewed to assess the impact of the extent of deviation on the Stage
and Project
• Options for recovery are determined and assessed against Business Case
• Project Manager may compose an issue report or exception report (as
appropriate) by putting the situation, options and recommendation to the
Project Board
• Project Board may
o Request for more information or more time to consider its decision
o Approve, defer or reject a Request for Change
o Grant a concession for Off-specification or defer or reject it
o Request the Project Manager to close the project prematurely if
continuous business justification becomes invalid due to the issue,
risk or exception
• For this project:
o Let us explore this activity with few issues as outlined below
o Issue 1: Problem or Concern
▪ During this stage, customer decided to buy a few
multifunction printers that operate on network with scanning
capabilities to digitize the bills supporting expense claims
▪ When the printers arrived, facilities administration team
found out that the network port required for these printers
was not available at office premises
▪ Facilities administration team raised this as an issue
▪ Project Manager classified this issue as Problem or Concern
as it doesn’t fall under either Request for Change or Off-
specification
25 | P a g e
 ▪ Project Manager discusses with facilities administration and
prepares an Issue Report outlining the issue, options
available (such as setting up a new network port or exploring
connecting via Wi-fi) and recommendation (such as setting up
a new network port)
▪ Project Manager also estimated the effort and cost required
to set up the new network port
▪ Project Board reviewed this issue report and decided to grant
the required cost from project Risk Budget
▪ Project Manager created a new Work Package to set up the
new network port and assigned it to facilities administration
team (also see Corrective Action in next section)
▪ Project Manager also updated Stage and Project Plan with
efforts and cost incurred for the Work Package
o Issue 2: Request for Change that caused an exception
▪ When testing the approval workflows, Area Managers came
up with a request to access the expense reimbursement
reports on mobile and take necessary action
▪ They raised an issue to the Project Manager
▪ Project Manager reviewed approved Product Description for
this stage and came to know that this request was not part of
original scope. Therefore, Project Manager classified this
issue as Request for Change
▪ Project Manager notified the Area Managers and Project
Board about Request for Change and requested the team
manager to come up with required effort and cost
▪ Team Manager reverted with a concern that the team doesn’t
have necessary skill to develop mobile application interfaces
and proposed to hire a contractor from an external firm
▪ Project Manager reviewed the impact of this Request for
Change on Stage and Project level tolerances and found that
it exceeds Project level tolerances
▪ As a first step in handling exceptions, Project Manager
prepared an Exception Report and sent to Project Board
▪ On Project Board’s request for an exception plan in response
to the received Exception Report, in Managing Stage
Boundary process, Project Manager composed an Exception
Plan with the Request for Change, option to hire a contractor
from an external firm, the effort and cost involved and a
recommendation to hire a contractor from an external firm

26 | P a g e
 (please see Produce an Exception Plan in Managing Stage
Boundary for more details)
▪ After reviewing this Exception Plan, Project Board under
Corporate or Programme Management guidance (because of
Project level exception) felt that this requirement can be
rejected at this point of time as the effort and cost involved
exceed allowable Project level tolerances (also see Authorize
a Stage or Exception Plan in Directing a Project process during
Project execution)
▪ This was conveyed to Project Manager, and Project Manager
updated the Issue Register accordingly
o Issue 3: Off-specification
▪ During testing, a Regional Manager found that the email
request triggered by the system for an approval is not
displayed properly in Microsoft Outlook software
▪ The Regional Manager raised this as an issue
▪ Project Manager reviewed the Product Description’s
acceptance criteria and found that it was agreed with Team
that the approval email format should support HTML and it
should work with any email client software
▪ Project Manager tagged this issue as Off-specification (as it
was agreed but not delivered)
▪ Project Manager informed the Regional Manager who raised
this issue that this is a defect and will be fixed by the team
▪ Project Manager composed an issue report and informed the
team to fix the issue
▪ Project Manager also created a corresponding Quality
Activity to test this defect (also see Corrective Action in next
section)
▪ When the team fixed the issue, the reviewer assigned to this
role tested the defect and found it to be fixed
▪ Project Manager updated the Quality Register and Issue
Register accordingly

3.4.1.8. Take Corrective Action

• Corrective actions are created to implement actions that will resolve
deviations from the plan within the limits of the management stage and
project tolerances
• Corrective action is triggered during the review of the management stage
status and typically involves dealing with advice and guidance received
27 | P a g e
 from the project board and with issues raised by team managers
• For this project:
o In the previous section, for Issue 1: Problem or Concern, creation
of the new Work Package to address the setup of network ports is
an example of taking corrective action
o In the previous section, for Issue 3: Off-specification, Project
Manager instructing the team to fix the issue is an example of taking
corrective action

3.4.2. Managing Product Delivery

3.4.2.1. Accept a Work Package

• When a Work Package is allocated to a team, there should be an
agreement between the Project Manager and the respective Team
Manager about what is to be delivered
• Team Manager reviews assigned Work Package to
o Obtain any relevant documentation
o Clarify with Project Manager what is to be delivered
o Negotiate with Project Manager on constraints if required
o Agree the tolerances for Work Package
o Understand and agree the Reporting requirements
o Understand how approval of products is to be obtained and who
will approve
o Understand how Project Manager is to be informed about
completion of Work Package
• For this Project:
o When a Work Package is created by the Project Manager, the Team
Manager will review and raise any issues or concerns with Project
Manager
o Team Manager will also create a task list (please note in this project,
Team Plans are not required as per Tailoring decision on themes)

3.4.2.2. Execute a Work Package

• The respective Team Managers
o develop the products required by the Work Package to the quality
criteria defined in the Product Descriptions that are part of Stage
Plans
o ensure that the development work is conducted in accordance with
the required techniques, processes and procedures specified in the
Work Package
28 | P a g e
 o capture and record the effort
• For this project:
o Team Manager will work with the team to develop the Work Package
as per agreed quality criteria
o Team Manager will also ensure that the team follows agreed tools
and techniques such as peer reviews
o Team Manager will capture the actual effort in developing the Work
Package and provide the information to the Project Manager
o Team Manager will raise any issues or risks to the Project Manager
as appropriate
o Team Manager will compose informal report by email that replaces
Checkpoint Reports and share with Project Manager
o Team Manager will also assist the Project Manager in composing
Weekly defect summary report

3.4.2.3. Deliver a Work Package

• The respective Team Managers will
o review the quality register to verify that all the quality activities
associated with the work package are complete
o review the approval records to verify that all the products to be
delivered by the work package are approved
o update the team plan to show that the work package is complete
o check the work package and follow the procedure to deliver the
completed products
o notify the project manager that the work package is complete
• For this project:
o Team Manager will follow the approval methods documented in
Work Package

3.4.3. Directing a Project During Project Execution Phase

Please note, in this case study, activities in Directing a Project are not shown together.
They are shown as they happen during PRINCE2® Project process flow.
For this reason, Directing a Project process will be presented multiple times with
relevant activities.

3.4.3.1. Authorise a Stage or Exception Plan

• If an exception has occurred during the management stage, the project
board may request that the project manager produces an exception plan
29 | P a g e
 for project board approval
• Only exceptions to stage plans or project plans need to be escalated for
approval
• Deviations from the project plan may need corporate, programme
management or customer approval
• For this project:
o The situation of exception was presented in Issue 2: Request for
Change

3.4.3.2. Give Ad Hoc Direction

• Ad hoc direction may be given collectively or by individual project board
members
• Situations that may prompt ad hoc direction include:
o responding to requests (e.g. when options need clarifying or where
areas of conflict need resolving)
o responding to reports (e.g. highlight report, exception report, issue
report)
o responding to external influences (e.g. changes in corporate
priorities)
o project board members’ individual concerns
o responding to changes in project board composition
• For this project:
o Let us explore this activity with a situation as outlined below
o Situation for ad hoc direction
▪ During Planning phase of the project, it was decided that
employees will be provided with individual user ID and
passwords to login to the expense reimbursement
application and their respective email ID will be used as user
ID
▪ Project Manager created Work Package accordingly and
development team started developing the required login
functionality
▪ VP – IT brought to the notice of Project Board that during a
recent ISO 27001 audit, the auditors raised concerns about
using individual user IDs for applications. Auditors are
advised to use single sign-on. Single-Sign On (SSO) occurs
when a user logs in to one application and is then signed in
to other applications automatically, regardless of the
platform, technology, or domain the user is using. The user
signs in only one time

30 | P a g e
 ▪ VP – IT insisted that SSO must be enabled for expense
reimbursement application; otherwise they would fail in ISO
27001 certification audit
▪ Project Board reviewed the situation and gave ad hoc
direction to Project Manager to treat this as a Request for
Change and sanctioned cost from Change Budget

3.4.4. Managing Stage Boundary towards the end of a Management Stage

Please note, in this case study, activities in Managing Stage Boundary are not shown
together. They are shown as they happen during PRINCE2® Project process flow.
For this reason, Managing Stage Boundary process will be presented
multiple times with relevant activities.

3.4.4.1. Plan the next management stage

• The stage plan for the next management stage is produced near the end
of the current management stage
• Please see Plan the next management stage that was presented earlier at
the end of Initiation Stage for more details about this activity
• For this project:
o By this point in time, in this project, 2 Management Stages are
complete (Initiation and another one)
o Now Project Manager will plan the last and final Management Stage
o Because this is the last and final Management Stage, Project
Manager will plan Project Closure activities in this stage plan

3.4.4.2. Update the Project Plan

• At the end of a Management Stage, Project Plan must be updated with
o actuals from the current stage plan, i.e. completed stage
o forecasts from the next stage plan
o any changes to the project product description, i.e. project-level
scope
o the implications of any issues or risks
o any new or changed PRINCE2 process-tailoring requirements for
the project
o any changed or extra products sanctioned by the project board
o any changes within the Project Initiation Documentation (PID)
• For this project:
o Project Manager will carry out the actions listed above

31 | P a g e
 o As given in ad hoc direction example in Directing a Project process,
Project Manager will update Project Product Description to include
the extra product (i.e. enabling the Single-Sign On SSO) sanctioned
by the Project Board

3.4.4.3. Update the Business Case

• Project Manager will
o update the benefits management approach with the results from
any benefits management actions undertaken during the
management stage
o examine and review:
▪ risks
▪ issues
▪ project plan
▪ benefit reviews for next management stage
▪ the impact of approved changes on anticipated benefits
• For this project:
o Project Manager will update the Business Case with actuals from
current stage
o Project Manager will also forecast the six performance targets (i.e.
Benefits, Cost, Quality, Risk, Scope and Timelines) from the Stage
Plan for the last and final stage

3.4.4.4. Report Management Stage End

• The results of a management stage should be reported to the project
board so that progress is clearly visible to the project management team
• Project Manager
o reviews the status of updated Business Case with respect to
achievement of any benefits
o reviews the Stage Plan to verify whether the planned objectives are
met or not
o reviews team performance for the completed stage
o uses Product Status Account and reviews Management Stage
performance
o reviews risks and issues
o prepares an End Stage Report for the completed Management
Stage
• For this project:
o Project Manager will carry out the above actions
o In Communication Management Approach, if there is a requirement
32 | P a g e
 to share the End Stage Report (as it is the end of a milestone in the
project) to Corporate or Programme Management, it will be shared

3.4.4.5. Produce an Exception Plan

• If a management stage or the project is forecast to deviate beyond its
agreed tolerances, it no longer has the approval of the project board
• Exception plans are requested by the project board in response to an
exception report
• Project Manager produces an Exception Plan by
o examining the stage plan to identify the products planned to be
created during the management stage
o examining the exception report for details (such as recommended
actions) that contribute to the exception plan
o examining the quality management approach for the quality
standards and procedures required if the exception plan requires
new products to be created
o updating the product breakdown structure, product descriptions
and product flow diagram for the products to be created by the
exception plan
o updating the quality register for planned quality management
activities
• For this project:
o The example presented for exception Issue 2: Request for Change
showed that Project Board rejected the Request for Change
o To illustrate how an exception is handled, let us assume that
Corporate or Programme Management extended Project-level
tolerances to the Project Board to accommodate this Request for
Change
o In such situation, Project Manager will prepare the Exception Plan
with details about the cost and effort required in developing the
mobile enablement of approval of expense reimbursements, create
necessary quality activities in Quality Register to track the planned
quality activities and revise existing Project Product Description,
Product Description and Product Breakdown Structure to include
the new requirement

3.4.5. Next Steps

• At the end of each Management Stage except the last and final
Management Stage, Manage Stage Boundary process will be executed as
shown in Managing Stage Boundary towards the end of a Management
33 | P a g e
 Stage
• During the Stage, if there is a forecast exception, next steps would be
visiting Managing Stage Boundary process to produce an Exception Plan
as shown in Produce an Exception Plan
• To provide complete context, the diagram below shows Controlling a
Stage, Managing Product Delivery, Directing a Project and Managing Stage
Boundary processes together to illustrate a Management Stage in
execution in an easy way that helps understand better

Figure 3.4.5-1 Management Stage during Project Execution phase

34 | P a g e
3.5. Project Closure Phase

3.5.1. Closing a Project

• A PRINCE2 project can be closed in two ways:
o Planned Closure
▪ This closure happens when the Project is closed as per plan, i.e.
the project is executed completely as per planned duration
▪ From Controlling a Stage process of the last and final Management
Stage, Project Manager would visit Closing a Project process
directly
o Premature Closure
▪ This closure happens when the Project Board decides against
continuing with the project anytime in the project
▪ Premature closure may be invoked by Project Board due to
continued business justification becoming invalid or project
becoming no longer relevant due to some strategic changes, etc.
▪ From Directing a Project process, Board would ask the Project
Manager to invoke Premature closure

Figure 3.5.1-1 Planned and Premature closure

3.5.1.1. Prepare Planned Closure

• Project Manager will
o Update the Project Plan with actuals from the final management
35 | P a g e
 stage.
o Using Product Status Accounts updated by Project Support, verify
that
▪ project’s products (i.e., complete scope) have been approved
by relevant stakeholders identified in the product
descriptions
▪ all quality criteria have been met
o In liaison with Senior Users (and Operations stakeholders when
required), confirm that project has delivered what is defined in
Project Product Description (i.e., complete scope).
o Request approval from corporate or programme management or
customer to release resources.
• For this project:
o Project Manager will check with Operations users about the
deployment of expenses reimbursement application.
o Project Manager will update Product Status Account (as Project
Manager is also playing the role of Project Support in this project)
and get it verified by Senior Users and User Assurance.
o Because this is an internal project, there may not be any need to
release resources, but Project Manager will release resources from
playing PRINCE2 project roles.

3.5.1.2. Prepare Premature Closure

• In some situations, the project board may have instructed the project
manager to close the project prematurely.
• In such circumstances, the project manager must ensure that work in
progress is not simply abandoned but that the project salvages anything
of value created to date. The project manager must also check that any
gaps left by the cancellation of the project are raised to corporate,
programme management or the customer.
• Project Manager will
o Update Issue Register to record the premature closure decision
o Update the Project Plan with actuals from final management stage
o Use Product Status Account updated by Project Support to
determine
▪ Which products have been approved (i.e., completed Work
Packages)
▪ Which products are currently in development (i.e., in-
progress Work Packages)
▪ Which products are yet to be started (i.e., Work Packages not
36 | P a g e
 yet started)
▪ Which products must be made safe (i.e., Work Packages that
might need secure storage or need to be moved to a safe
location)
▪ Which products may be useful to other projects (i.e., Work
Packages that can be reused in other projects)
o Consult Project Board and development teams and come to an
agreement on what should be done with in-progress Work Packages
to complete them.
▪ If Project Board agrees to complete them, create an
Exception Plan to capture the effort, cost and resources
required to complete the in-progress Work Packages and
seek Project Board’s approval.
o Seek approval from corporate or programme management or
customer for early release of resources
• For this project:
o Let us explore a situation to understand Premature closure better
o During the project development, IT Manager (who is the Project
Manager) has found an Open source solution that is free and suits
the expense reimbursement requirements of customer with few
minor changes
o Project Manager brought this to the notice of Project Board and
Project Board asked the Project Manager to come up with details on
completed, in-progress and yet to start Work Packages
o Project Manager presented the following information on Work
Packages
▪ Work Packages completed
• Procurement of multifunction printers (printers have
arrived and are in boxed condition)
• Establishment of network port at offices
• Single Sign-On integration
▪ Work Packages in-progress
• 3 level approval workflows
• Integrating image storage on cloud
▪ Work Packages yet to start
• Report generation
• Integration with Payroll software for processing
expense reimbursement claims in payroll cycle
o Project Board advised the Project Manager as follows:
▪ Work Packages completed

37 | P a g e
 • Procurement of multifunction printers
o As per initial plan, two multifunction printers
were purchased for each office location
o Project Board advised the IT Manager (i.e.,
Project Manager) to retain one multifunction
printer, return the other one and claim a refund
from printer supplier
• Retain network port established at offices
• Keep the Single Sign-On Integration Work Package in a
safe repository to be used in future for other projects
when required
▪ Work Packages in-progress
• 3 level approval workflows should be abandoned.
Whatever work has been completed to date must be
deleted from company’s repository
• Integrating image storage on cloud – Project Board felt
it would be good to have this capability in the
development team. The board advised Project
Manager to come up with an Exception Plan that
captures the effort, cost and resources required to
complete the remaining work in the Work Package
▪ Work Packages yet to start
• Report generation – to be abandoned
• Integration with Payroll software for processing
expense reimbursement claims in payroll cycle – to be
abandoned

3.5.1.3. Hand over Products

• The project’s products must be passed to an operational and maintenance
environment prior to the project being closed
• When handing over products, the benefits management approach may
need to be updated to include the post-project benefits review(s) of the
performance of the project’s products in operational use
• Project Manager will
o Prepare follow-on action recommendations for the project’s
products (in consultation with the project management team) to
include any uncompleted work, issues and risks
o Check that the benefits management approach includes post-
project activities to confirm benefits
o Confirm that the correct operational and maintenance environment
38 | P a g e
 is in place and obtain approval from operations and maintenance
teams
o Consider the early life-support requirements of each product being
handed over
• For this project:
o Project Manager will check with Data Centre managers that
required Production Environment is fully configured and required
code libraries have been migrated to Production Environment
o Project Manager will check with VP – Operations for ongoing
support required for this project
o If there is a requirement to conduct training on how to use and
maintain the expense reimbursement system, Project Manager will
initiate the sessions and ensure that relevant knowledge transition
takes place

3.5.1.4. Evaluate the Project

• When evaluating the project, the objective is to assess how successful or
unsuccessful the project has been
• Project Manager will
o Review Project Initiation Documentation (PID) prepared at the end
of Initiation Stage (it was the first version of that document) to verify
the project’s original intent and final result
o Prepare an End Stage Report (in consultation with project
management team) that includes
▪ Project Manager’s summary on how the project has
performed
▪ An assessment of project’s performance against its planned
targets and business case
▪ A review of team performance
o Review lessons log (in consultation with project management team)
and identify any lessons that could be useful for future projects
• For this project:
o Project Manager will prepare End Project Report and Lessons
Report with the content outlined above
o Project Manager will also present any useful knowledge gained
regarding tailoring of PRINCE2 for the project

3.5.1.5. Recommend Project Closure

• After the project manager has confirmed that the project can be closed, a
closure recommendation should be raised to the project board
39 | P a g e
 • Project Manager will
o Communicate with relevant stakeholders (as recorded in the
Communication Management Approach) that the project is closing
o Close the project’s issue register, risk register, quality register, daily
log and lessons log
o Make sure that all project information is secured and archived
o Prepare and send a draft project closure notification for review by
the project board stating that the project has closed
• For this project:
o Project Manager will carry out the above actions
o It will be a good idea for the Project Manager to throw a small party
after successful project completion

40 | P a g e
4. Conclusion

4.1. Conclusion Remarks

• This Case Study presented a walkthrough of how PRINCE2 can be used in a
project situation
• The project management method PRINCE2 can be applied to any project in any
domain
• Care must be taken to ensure that the themes, processes, roles, terminology and
management products are adequately tailored to meet the needs, complexity
and scale of the project.

41 | P a g e
5. References

5.1. References
• Managing Successful Projects with PRINCE2®, 2017 Edition © Axelos.com, all
rights reserved

42 | P a g e