PRINCE2-SampleProject-Premium-MP847

y Management Plaza 

The Pen Project 

A fully documented sample PRINCE2® project 

ISBN: 9789082114706 

PRINCE2® is a Registered Trade Mark of the AXELOS. The Swirl logo is a Trade Mark of the AXELOS. 

© Management Plaza 

By: Frank Turley, Nader K. Rad 

Date: 19/9/2013 

Version: 

01.14 Premium Edition 

Check for Updates: www.mgmtplaza.com/latestversion 

Please send feedback to: frank.turley@mgmtplaza.com 

P2P-SampleProject-EN Version V01.14 – Premium Edition 

1

Copyright © 2013 Management Plaza 

All rights reserved. With the exception of brief 

passages and quotes for reviewing or commenting 

purposes, no part of this publication may be 

reproduced or transmitted in any form or by any 

means without prior consent of Management Plaza. 

PRINCE2® is a registered trade mark of AXELOS Limited. 

The Swirl logo is a trade mark of AXELOS Limited. 

ISBN: 9789082114706 



By: Frank Turley, Nader K. Rad 

Date: 28/8/2013 

Version: 

01.12 Premium Edition 

Check for Updates: www.mgmtplaza.com/latestversion 

Please send feedback to: frank.turley@mgmtplaza.com 

P2P-SampleProject-EN Version V01.14 – Premium Edition 

2

About the authors 

Frank Turley has been a Project Manager for more than 15 years and a PRINCE2® Practitioner. He is also a 

PRINCE2 and Project Management trainer and coach and has written a number of PRINCE2® and Project 

Management related books. Frank is best known in the PRINCE2 world for his work in creating the most 

popular PRINCE2 Self Study training including: 

• The PRINCE2 Foundation Training Manual and video course 

• The PRINCE2 Practitioner Training Manual 

• The PRINCE2 Sample Project 

Website: http://www.mgmtplaza.com 

LinkedIn Profile: http://linkedin.com/in/frankturley 

Nader K. Rad is a project management consultant, author, and trainer at Management Plaza. His career 

started in 1997 and he has been involved in many projects in different industries. He has designed a number of 

project management courses, prepared a number of e-learning materials, and written more than 40 books and 

plenty of practical articles on project management concepts and standards, planning software, scheduling, etc. 

He is certified as PMP®, PRINCE2® Practitioner, AgilePM® Foundation, CSM®, and PSM I. 

Website: http://www.mgmtplaza.com 

LinkedIn Profile: http://www.linkedin.com/in/naderkhorramirad 

Thanks to every one who has given us feedback/suggesDon, especially Henny Portman 



P2P-SampleProject-EN 

Version V01.14 – Premium Edition 

3

Who 

Document: 

Who is this sample PRINCE2 project for 

1) PRINCE2 Foundation Students 

• View (browse over) the main PRINCE2 docuemnts, this will help your understanding of PRINCE2. 

• E.g. 1) Project mandate, 2) Project Brief, 3) IniDaDon Stage Plan, 

• 4) Product DescripDon, 5) PID, 6) Register Files, 7) Log files 

2) PRINCE2 Practitioner Students 

• You need to be familar with all PRINCE2 Management documents and their structure (contents) 

• It is therefore best to become familar with the scenario used in this sample project and then and then become familar 

with each Management Document 

• This is perhaps the best way to prepare for the PracDDoner Exam as the exam uses a project scenario and you are 

expected to know how to apply PRINCE2. 

3) Gaining PRINCE2 experience 

• Many people never get a chance to work in a PRINCE2 environment and don’t understand how to apply PRINCE2. 

• We suggest to re-‐create this sample project based on another scenario (e.g. a project you have done) 

• This is perhaps the best way to pracDce PRINCE2 as you cover the full project. 

4) Implementing a PMO 

• Many companies are now considering implemenDng a PMO but are not sure where to start 

• SuggesDon: IdenDfy a standard project from your organizaDon and document it like this project 

• Start of as simple as possible so you can deliver a first internal sample project (a reference project) 

• The PMO can then gradually update this reference project to introduce new techniques and lessons 





4

The 

Project Scenario 





5

Project Scenario 

Document: 

Project Scenario: CopyWorld365 

Company: CopyWorld365 

CopyWorld365 is a company that sells printing / photo copying machines. They have 15 employees (4 sales 

people) and they would like to start a project to give their clients a good quality promotional pen to help 

improve the relationship with clients and to reduce the loss in client turnover. 

The Sales Manager chaired a meeting and the outcome of the meeting was as follows: 

• We will give a quality pen/pencil out to all clients to help reduce client turnover and improve relationships 

• The Pen will mostly be given out by the sales people from Dec 5th to Jan 10th 

• Pen must be good quality so people will be happy to use it (not be embarrassed to use it) 

• Budget of €6 to €8 each 

• Presentation of pen/pencil is important 

• Company logo must appear on pen 

Project Scope 

• Define quality requirements 

• Choose & test Pens/Pencils 

• Order Pens with logo 

• Choosing clients to give pen to 

Out of Scope 

• Giving out the pens/pencils is not part of the project 

• Designing the logo 

• Original list of clients 

This text provides in introducDon to 

the project scenario. 

It is important to read this first. 





6

Pre-Project 

Starting up a Project 





7

Project mandate 

Pre-Project Stage 1 (initiation) Stage 2 Stage 3 (Final) 

Processes 

Star.ng up a Project Ini.a.ng a Project Controlling a Stage Controlling a Stage 

Managing a Stage Boundary 


Closing a Project 

Management Products 

Project 

mandate 

The project mandate is the 

trigger for the project 

Other documents will be gradually added to this diagram. They will be presented in 

one of the following colors: 

Blue: prepared once in the project 

Green: prepared once in every stage 

Orange: could be prepared/updated mulDple Dmes in every stage 

Dark Red: similar to orange, but used between the management and delivery levels. 

Note: this diagram only contains the 

sample documents of this training 

course, rather than all the necessary 

documents in each stage. 





8

Project mandate 

Document: Project mandate 

Project: Pen Project Author: Project Manager 

Date: 

1. Project Definition 

The project will choose a quality pen and give out about 400 pens to 

our clients. 

Project ObjecDves 

• Choose a pen that meets specificaDons 

• Choose a pen that users will be perceived as a quality pen 

Project Scope: 

1. Choose a pen 

2. Sales people list 

2. Reasons 

3. PromoDonal pen catalogues 

4. List of clients that will receive a pen 

Build beber relaDonships with clients and reduce the loss in the 

renewal of maintenance contracts by 50%. CopyWorld365 had 4,200 

maintenance contracts with a profit of €150 per contract = €630k 

4% loss each year costs €37,800 

3. Project Product Description 

To be created 

4. Approach 

Do the project internally 

5. Project Management Team 

The ExecuDve should be the CEO 

The project mandate does not have to 

contain much informaDon 

Normally just the reasons and the 

Execu.ve. 





9

Lessons Log 


Processes 






Project 

mandate 

Daily Log, Lessons Log 

The PM will facilitate the gathering 

of lessons. All project stakeholders 

are invited to provide lessons 









10

Lessons Log 

Document: Lessons Log 


Date: 

ID + -‐ Recommenda.ons 

1 J We used the business gig company “BizGigs” last year and 

they offered a good service 

2 L The Dme to deliver gigs always seems to take longer than 

agreed by most companies (add Dme buffer) 

3 L The business gig company “Gigs4All” provided a poor service 

for our neighboring company. 

Seen 

before 

Date 

Logged 

Logged 

by 

Priority 

Stage 

Yes 12/1 PM 3 2 

Yes 12/1 PM 2 1 

No 13/1 PM 2 2 

4 J There is a ISO standard for pens: ISO 12757-‐2 No 13/1 PM 2 SU 

5 

… 

The PM will facilitate the gathering of lessons. Lessons can come from users, 

Team Managers, past project Lessons Report files, consultants, … 

Risk seen 

before 

+-‐: 

Risk before: 

Priority: 

Stage: 

(J) Posi(ve effect on the project, (L) nega(ve effect, 

Has the risk been seen before (if yes, how did the project deal with it) 

Importance for project – The PM will want to make sure, they are using the important lessons 

The PM can see which lessons have value for the next stage 





11

Daily Log 

Document: Daily Log 


Date: 

ID 

Date of 

Entry 

Descrip.on 

Responsible 

Target 

Date 

Result 

01 2013-‐06-‐17 

When we were preparing the list of potenDal suppliers, I 

realized that one of them is owned by an old friend of mine 

(conflict of interest) 

Project 

Manager 

2013-‐06-‐17 

I believe I’m capable of evaluaDng the 

suppliers honestly. I’ve also informed 

the project board about this conflict of 

interest. 

02 2013-‐06-‐18 

A sales man from one of the potenDal suppliers came to 

our office today to meet me, while I was in a meeDng. He 

leg me a gig and leg the building before I could meet him. 

This can be considered a bribery. 

Project 

Manager 

2013-‐06-‐18 

I returned the gig and put the supplier 

in the company’s black list. 

03 2013-‐06-‐22 

Daniel Ross, who’s responsible for the logo, is asked to 

prepare its vector version, but he doesn’t seem to know 

how. 

Project 

Manager 

2013-‐06-‐23 

He’s replaced by Julie Gates, who’s 

more expert on graphic design. We’ve 

lost two days, but the acDvity has a lot 

of float and we won’t get into any 

problems. 

04 2013-‐06-‐25 

The communicaDon between Julie Gates and the supplier 

needed for the design of the logo is not effecDve enough. It 

takes a lot of Dme for each version to be reviewed and the 

new version is released. 

Project 

Manager 

2013-‐06-‐25 

Julie Gates is asked to meet with the 

responsible person in the supplier 

company to discuss the requirements of 

the logo and to prepare it together. 

05 2013-‐06-‐26 

I had a meeDng with the selected supplier to discuss the 

price, when we also talked about the quality, and 

especially about the quality of the printed logo and the 

best technique to use for this. 

Project 

Manager 

The Daily Log is used to capture issues and risks in the Star(ng up a Project process 

AOer that, it is used as a (private) daily journal for all informa(on by the Project Manager 

Note: the content of this sample Daily Log belongs to next stages of the project 





12

Project Product Description (part of Project Brief) 


Processes 






Project 

mandate 


Project Brief 

Project Product Descrip.on 

The Project Product Descrip(on defines what the 

project must deliver in order to gain acceptance. It 

usually defines the scope, requirements, quality 

expecta(ons, acceptance criteria, acceptance method, 

and acceptance responsibili(es. 









13

Project Product Description (Workshop) 

The Project Manager hosted a workshop to create the Project Product Description. The main workshop goals: 

1. Get buy-in from the necessary stakeholders 

2. Identify the most important requirements for the pen and prioritize them 

3. Complete the Project Product Description during the workshop 

Requirements Exercise 

• The PM gave each person post-its and reminded them about the project goals 

• The PM asked each person to list 10 requirements for the pen that will be given to each client 

• After this exercise, the PM categorized each requirement and identified the top requirements 

• The requirements are listed below using the MoSCoW technique 

Document: 

Project Product Descriptions Requirements (MoSCoW) 

1. Must Have Requirements 3. Could have requirements 

• Quality looking pen 

• 5 year guarantee 

• Logo display correctly 

• Pen easy to write with 

2. Should have requirements 

• Easy to find refills for the pen 

• Guarantee no leak pen 

• USB memory stick in pen 

A number of requirements have been grouped under “5 year 

guarantee” (all parts working, color fading....) 

4. Other (Won’t have for now) 

• Write upside down 

The acceptance criteria and acceptance method for each Must 

have will be detailed in the Project Product Descrip(on 





14

Project Product Description (part of Project Brief) 

This is a good example of the Project Product Descrip(on (Main Product Descrip(on). It does not have to be a 

large document. This examples has outlined 4 main features and defined the quality level for each feature. 

Document: Project Product Description Project: Pen Project Author: Project Manager 

Date: 

1. Purpose 

The purpose of the pens will be to provide a constant reminder of our 

company to most of our clients and reduce the loss of maintenance 

contracts renewals by 50% in the next 12 months. 

2. Composition 

3. Derivation 

1. Business Gift Catalogs 

2. Client list 

4. Development skills required 

1. Pens to evaluate 

2. Chosen Pen 

3. Reviewed client list 

4. Distributed Pens 

Purchasing skills 

Account (Client) management 

Quality 

This example has outlined four main features and defined the quality level for each feature. 

See the next slide for more informa(on 

Quality ExpectaDon 

Acceptance Criteria 

Tolerance 

Acceptance method 

Quality looking pen 

AC1: Look like it cost > €10 

AC2: Look like a professional pen 

None 

AC1: Confirm that 8 of 10 see value > €10 

Priority 

AC2: Confirm that 9 of 10 see pen as professional 

M 



Tolerance 


Logo display correctly on pen 

AC1: Correct size on pen 

Priority 

AC2: Logo will not erase in 5 years of normal use 

AC1: Size ± 10%, 2) Logo erase: + 100% 

AC1: Measure logo on pen with ruler 

AC2: Logo: Ask for Logo guarantee 

M 

ResponsibiliDes 

AC1: Susan Kelly, AC2: Susan Kelly 


AC1: Susan Kelly, AC2: Susan Kelly 



Tolerance 



5 year guarantee 

AC1: 5 year guarantee from supplier 

AC1: ± 50% 

AC1: Accept guarantee noDce 

Priority 

AC1: Sales Manager will accept guarantee 

M 



Tolerance 



Pen easy to write with 

Priority 

AC1: 9 of 10 people find pen easy to write with 

AC1: ± 10% 

AC1: Provide survey report 

AC1: Susan Kelly 

M 





15

Introduction to the quality information 

This slide provides informa(on about the quality data required in a Project Product Descrip(on 

Most Project Managers find it very difficult to understand this from the official PRINCE2 Manual 

Read the informa(on provide for each heading. 

Quality heading 

Quality Expecta.ons 

Priority 

Acceptance Criteria (AC) 

Project Tolerance 

Acceptance Method 

Acceptance Responsible 

Quality heading descrip.ons 

What feature/requirement does the customers want (list one at a Dme) 

e.g. Quick search (speed of results) 

MoSCoW: (Must, Should, Could, Won’t) or 1,2,3 e.g. M 

Acceptance criteria states what the Customer agrees to accept (measurable) 

QuesDon: How can we prove that we have meet your expectaDons 

QuesDon: What tests should be done & expected results 

Note: There may be a number of number of tests for each Quality expectaDon 

AC 1: Expect speed result < 2 seconds 

AC 2: Expect speed result < 2 seconds 

What is the tolerance(s) for each Acceptance Criteria 

AC 1: ± 15%; AC 2: ± 10% 

How will each quality criteria be checked 

AC 1: Manual tesDng 

AC 2: Unit tesDng with load tesDng 

List the persons name for each quality criteria or complete quality expectaDon 

AC 1: Frank Klein 

AC 2: Frank Klein 





16

Project Management Team Structure (part of Project Brief) 


Processes 






Project 

mandate 




Project Management Team 

Structure 

One of the PRINCE2 Principles is “Defined Roles and 

Responsibili(es”. This document is one of the tools used to 

realize this principle, and consists of defined and agreed 

roles and responsibili(es and a means for effec(ve 

communica(on among people involved in the project. 









17

Project Management Team Structure (part of Project Brief) 

Document: Project Management Team Structure Project: Pen Project Author: Project Manager 

Date: 

These are their normal job func(ons 

CopyWorld365 Employees & Job titles 

John King: CEO 

Susan Kelly: Sales Manager 

Terry Clinton: Purchasing & Accounts 

Rose Carr: Client Project Manager 

Tailoring comments for the PMT 

Delivery Management Direction Corp.. 

Corporate or Programme Management 

Senior User Executive Senior Supplier 

Susan Kelly John King Terry Clinton 

Project Assurance 

Project Manager 

Rose Carr 

Change Authority 

These are the PMT roles for the project 

Project Support 

Rose Carr 

Tailoring comments for the Project Management Team: 

• The Project Manager will have the roles and responsibilities of Team Manager and Project Support. 

• The Project Board will have the role of Project Assurance. 

• The Project Manager, Executive, Senior User, and Senior Supplier will have the change authority role. 

• The management (Project Manager) and delivery (Team Manager) levels have been merged 





18

Outline Business Case (part of Project Brief) 


Processes 






Project 

mandate 





Structure 

Outline Business Case 

The Outline Business Case is prepared at the Star(ng Up a Project process, 

when detailed informa(on is not available yet. It’s used to determine if 

there’s a business jus(fica(on for ini(a(ng the project. Detailed 

informa(on would become available in ini(a(on and the “business case” 

will be prepared then. 









19

Outline Business Case (part of Project Brief) 

Document: Outline Business Case 

Project: Pen Project Author: Executive 

Date: 

1. Reasons 

Build beber relaDonship with clients and reduce the loss in the renewal 

of maintenance contracts by 50%. CopyWorld365 had 4,200 

maintenance contracts with a profit of €200 per contract = €840,000 

A 5% loss instead of a 10% loss would be a gain of €48,000 

2. Expected Benefits 

• Reduce loss of maintenance contracts by 50%±15% : €42,000/year 

• Increase new machine orders by 5%±1%: 16,000/year 

3. Expected dis-benefits 

None 

4. Timescale 

12 weeks (3 months) 

7. Major risks 

Clients may not hold on to the pen and use it each day and there will 

not be reminded of CopyWorld365. 

The outline Business Case does not have to contain much data 

This informa(on will be expanded later into the Business Case 

document in the Ini(a(on stage. 

It is wri_en by the Execu(ve with normally some assistance from 

the Project Manager 

5. Costs 

• Pen costs: €9 by 400 pens = €3,600 

• Other project costs: €600 

6. Investment appraisal 

See Business Case (IniDaDon stage) 





20

Project Brief 


Processes 






Project 

mandate 





Structure 


The Project Brief is usually a collec(on of other documents and 

refers to them instead of containing the actual informa(on. It 

provides a full and firm founda(on for the ini(a(on. A detailed 

Project Ini(a(on Documenta(on (PID) will be created in 

ini(a(on and will replace the Project Brief. 









21

Project Brief 

Document: Project Brief 


Date: 


The project will give choose a quality pen and give out about 400 pens 

to our clients. 

Project ObjecDves 

• Choose a quality that meets specificaDons 

• Choose a pen that users will perceive as a quality pen 


1. Choose a pen 3. PromoDonal pen catalogues 

2. Sales people list 4. List of clients that will receive a pen 

Constraints and assumpDons 

• Possible to find a pen in the catalogues provided 

Project Tolerances 

1. Time: 3 months + 30% 

2. Cost: €7 for a pen: EsDmate €3400 for the project +-‐ 10% 

3. Quality: Pens must meet quality requirements 

3. Project Product Description 

Abached: Project Product DescripDon (PPD) 

4. Approach 

The company will choose a pen that meets the requirements from an 

exisDng business gig company. Project will be run internally. 

This is a good example of the Project Brief. It does not 

have to be a large document. 

2. Outline Business Case 

Reasons: 

Build a beber relaDonship with clients and reduce the loss in the 

renewal of maintenance contracts by 50%. CopyWorld365 had 4,200 

maintenance contracts with a profit of €150 per contract = €630k 

4% loss each year costs €37,800 

Expected Benefits 

• Reduce loss of maintenance contracts by 50% : €18,000 (each year) 

• Increase new machine orders by 2%: 16,200 (each year) 

Risks 

• Clients may not hold on to the pen and use it each day. 

Costs 


• Other project costs: €800 

The outline Business Case has 

been slightly updated. 

5. Project Management Team 

Abached: Project Management Team (PMT) 

6. Role Descriptions 

This project uses the roles descripDon as defined by PRINCE2 

-‐ Link to the Roles DescripDons document 

The Project Product Descrip(on and the PMT are not 

displayed here but are part of Project Brief 





22

Initiation Stage Plan 


Processes 






Project 

mandate 





Structure 


Ini.a.on Stage Plan 

This plan 

-‐ is used by the Project Manager to execute the Ini(a(on Stage. 

-‐ shows what will be produced and when 

-‐ documents the cost of the Ini(a(on Stage 









23

Initiation Stage Plan 

Document: Initiation Stage Plan 


Date: 

1. Plan description 

This is the plan for the IniDaDon Stage of the Pen Project 

2. Assumptions - Dependencies 

Sales Manager provides the necessary Dme for the project 

Twenty sales person will be available to evaluate the pens 

A business gig company will have to provide the pens to evaluate and 

the 400 of the chosen pens. 

Internal resources will not be charge to the project 

3. Lessons incorporated 

Allow buffer Dme for delivery of pens (Lessons Log) 

InvesDgate the ISO standard for pens: ISO 12757-‐2 

4. Monitoring & Control 

The PM will use the standard PRINCE2 documents 

A highlight will be sent at the end of week one to the Project Board 

An ExcepDon report will be used if forecasted to go out of tolerance 

5. Budgets 

IniDaDon stage budget: € 200 (internal people Dme is not charged) 

Risk Budget: €0, Change Budget: €0 

This example has merged Assump(ons and Dependencies 

6. Tolerances 

Time: ± 50% : Cost: ± 50% : Scope: 0% 

7. Products Description(s) 

Abached: Project Product DescripDon 

8. Schedule 

Deliverables -‐ March 

Strategy documents 

PBS (WBS) 

Product DescripDons 

Risk & Issues 

Project Plan 

Benefits Review Plan 

Business Case 

PID 

Next Stage Plan 

4th 5th 6th 7th 8th 11th 12th 13th 14th 15th 

2 hrs 

4 hrs 

8 hrs 

4 hrs 

3 hrs 

2 hrs 

2 hrs 

This is a simple example of the schedule, the focus is on the 

products created and not the ac(vi(es 

1 hrs 

2 hrs 





24

Interested in our CBT for this 

“A Fully Documented Sample PRINCE2 Project” 

Coming soon…. CBT $ 95 / € 72 

The CBT (approx. 8 hours) will walk you through each document covering each entry. 

This will be by far the best way to learn how to use PRINCE2 

Send an email to use at: support@mgmtplaza.com to receive a 33% discount 

Existing courses 

www.mgmtplaza.com/P2Intro 



www.mgmtplaza.com/ 

P2FSelfStudy P2P-SampleProject-EN 

www.mgmtplaza.com/ 

Version V01.14 – Premium P2PSelfStudy 

Edition 

25

The pre-‐project ac(vi(es are now complete and the Project Board 

will give permission for the Ini(a(on Stage to begin 

Stage 1 

Initiation (Planning) 

Approx. 80% of the work in this stage is focused on planning (product breakdown, 

requirements, product descrip(ons, es(ma(ng, scheduling) 





26

Communication Management Strategy (part of PID) 


Processes 






Project 

mandate 

Risk Register, Quality Register, Issue Register 





Structure 


Project Ini.a.on Documenta.on 

Four Strategy Docs 

There are four strategy documents, these are guidelines for the project. 

Normally the Project Manager will just copy in these strategy documents from 

as they are standard in each company. There are 

1) The Communica(on Management Strategy 

2) The Risk Management Strategy Document 

3) The Quality Management Strategy 

4) The Configura(on Management Strategy 


The Communica>on Management Strategy document: 

-‐ provides a guideline on how communica(on should be done 





This sample project just gives an example of the Communica(on Management 

Strategy as the others do not change very much from the templates provided. 





27

Communication Management Strategy (part of PID) 

Document: Communication Management Strategy Project: Pen Project Author: Project Manager 

Date: 

1. Introduction 

This document describes how communicaDon will be done during the 

project: It is based on the standard strategy document for all projects. 

2. Communication Procedure 

The PM will is responsible for all internal project communicaDon and 

will report each week to the Project Board using a Highlight Report. 

Other PRINCE2 documents reports will also be used as expected. 

The Sales Manager is responsible for all external communicaDon 

3. Tools and techniques 

• The PM will use the intranet portal site for all internal 

communicaDon and project document. 

• The Sales Manager will use an electronic newsleber and site visits to 

communicate with clients. 

4. Records 

The following documents will be used for internal communicaDon 

-‐ Highlight Report, End Stage Report, End Project Report, Issue 

Reports, Lessons Report, Project DescripDons and registers 

5. Timing of communication activities 

The PM will meet with Project Board each two weeks 

The PM and Project Board will meet at the end of each stage 

6. Reports / Stakeholder Matrix 

Report Name Timing Recipients 

Highlight Report 

Weekly Project Board 

End Stage Report End of stage Project Board 

End Project Report End of project Project Board 

Issue Report AnyDme PM/Project Board 

Electronic Newsleber Once Clients 

7. Roles & Responsibilities 

Project Board 

Project Manager 

Senior User 

Inform the rest of the management team 

All internal communicaDon (project team) 

Create the required PRINCE2 documents 

Communicate with clients 

8. Scales: Priority & Severity 

Priority 

Use MoSCoW (Must, Should, Could, Wont..) 

Severity levels 1 = Project Manager, 2 = Project Board 

9. Stakeholder Analysis 

Stakeholders A\tude Current Rela.onship Desired Rela.on 

Clients Neutral 90% Good 95% Good 

Sales Team Support Excellent Excellent 

Co. Mgmt Support Good 

Good 

Most of the effort will go into recognizing the stakeholders, deciding the 

desired rela(onship and how to communicate during the project. 





28

Product Breakdown Structure (part of the next Stage Plan) 


Processes 






Project 

mandate 








Structure 




PBS 

Product Breakdown Structure (PBS) 

Normally, the first step aOer the strategy documents is to 

breakdown the main product into sub-‐products, to get a be_er 

idea of what needs to be done. 

The Project Manager will facilitate this process and they can use 

a breakdown diagram, indented list or mind-‐map to do this. 









29


Document: PBS for Stage 2 (Mindmap) Project: Pen Project Author: Project Manager 

Date: 

1. Mindmap presentation of PBS 

Legend 

This is an example of the mind-‐map diagram. 

e.g. Supplier 

-‐ Supplier is a group of products 

-‐ Supplier has three sub-‐products 

-‐ Each sub-‐product will be described 





30


Document: PBS for Stage 2 (hierarchy chart) Project: Pen Project Author: Project Manager 

Date: 

1. Hierarchy presentation of PBS 

Pen Project 

Supplier 

Evaluation Pens 

Internal 

Evaluation 

Distribution 

Final Pens 

List of potential 

suppliers 

Catalog of pens 

List of evaluators 

List of clients 

requirements 

Short list of 

potential suppliers 

Short list of pens 

to be evaluated 

Evaluation forms 

List of sales 

people 

logo 

Selected supplier 

Purchase order for 

evaluation pens 

Evaluation and 

filled in forms 

Sales people 

delivered 

Purchase order for 

the finalized pen 

Sample pens for 

evaluation 

Evaluation report 

Received pens 

Legend: 

This is an example of an hierarchy diagram. 

External products 

Products 

Group of 

products 

e.g. Supplier 

-‐ You can compare with the mind-‐map diagram 





31

Product Description(s) (part of PID) 


Processes 






Project 

mandate 






Structure 




Product Descrip.ons(s) 

A Product Descrip(on can be created for each product iden(fied in 

the Product Breakdown Structure (PBS) 



PBS 









32

Product Description: Client List 

Document: Product Description: List of Clients Project: Pen Project Author: Project Manager 

Date: 

1. Identifier: PEN03.2 

2. Title: Client List 

3. Purpose 

List of all exisDng clients that will receive a pen 

4. Composition 

• Contact and company names 

• Contract value for each company 

• Contact person at CopyWorld365 

5. Derivation (Source) 

• ExisDng client list 

• Client contract 

This is an example of a Product Descrip(on and the objec(ve 

is to make it clear what the finished product will be. 

6. Development skills required 

Customer knowledge 

7. Quality Criteria 

1. Contract value must be the current contract value 

2. Client name must be the decision maker or main influencer 

Criteria Method Tolerance Skills Required 

1 Review None Contract knowledge 

2 Review None Contract knowledge 

Producer: 

Gerry Malone 

Reviewer 

CFO 

Approver 

Sales Manager 

The Product Descrip(on also includes the quality criteria, 

how the product will be tested (method), tolerance, skills for 

tester and quality reviewer. 





33

Risk Register 


Processes 






Project 

mandate 






Structure 






The Project Manager will facilitate the gathering of risks 

-‐ Run workshops and invites users and suppliers 

-‐ Review old lessons reports, Risk Registers and Issue Registers 

Risks can also be iden(fied for each product listed in the PBS 


PBS 









34

Risk Register 

Document: Risk Register 


Date: 

This is a rather simple project, so there are not many risks. 

However the risks s(ll need to be managed 

Project Name Pen Project Risk / Impact 

Project No 008 High Risk > € 7,500 

Project Manager Rose Carr Medium > € 1000 

Project ExecuDve John King Low Risk < € 1000 

Amounts are related to the value 

of the expected benefits 

Expected gain is: €58,400 

ID 

Risk 

Author 

Date Risk 

Register Category 

1 P Smith 6/3/13 Ordering 

2 S. Kelly 7/3/13 Product 

3 S. Kelly 9/3/13 Product 

Risk DescripDon 

A risk that pens will be delivered 2-‐4 weeks 

later which will impact the Dme of the 

project 

Users may not like the pens and therefore 

not keep using them which result in 90% -‐ 

100% reducDon in benefits 

Some sales people may not distribute the 

pens as intended, therefore the benefits 

will not be realized for these users 

Probability 

x Impact 

Proximity 

Response 

Category 

Status 

Risk Risk 

Owner AcDonee 

€550 Stage 2 Reduce AcDve P Smith J Bell 

€ 11,200 Year 1 Reduce AcDve S. Kelly R Clark 

€ 5,600 Year 1 Reduce AcDve S. Kelly S. Kelly 

How to calculate Probability * Impact 

Likelihood that almost all users will not like pen: 20% 

Impact if almost all users don’t like pen: €58,400 

Probability * Impact = 20% * €58,400 = €11,200 

The response text is not included in this example 

New risks will con(nue to be iden(fied 

as we plan and execute the project 





35

Benefits Review Plan 


Processes 






Project 

mandate 





Structure 








PBS 

The Benefits Review Plan is a plan to review the 

benefits. Benefits can be reviewed at each stage 

boundary or aOer the project has been completed. 









36

Benefits Review Plan 

Document: Benefits Review Plan Project: Pen Project Author: Project Manager 

Date: 

1. Introduction 

This document describes what benefits are to be measured, how 

and when they will be measured, and the investments needed to 

carry out those measurements. 

This plan lists the activities to check if the benefits have been 

realized 

2. Benefit 

1. Reduce loss of maintenance contracts by 50% : €42,000 

2. Increase new machine orders by 5%: €16,200 (each year) 

3. Baseline measurements 

1. Current loss of maintenance contracts is 10% (420 contracts) 

• Value of 10% loss is : €84,000 

2. New machine orders today will have a profit value of €320,000 

5. Review 

1. Show proof that the loss of maintenance contracts has been 

reduced by 50% 

2. Show proof that machine orders have increased by 5% 

6. Plan to Review 

6 months: ager project is complete 

-‐ Check if loss of orders is reduced by 50% for previous 6 months 

-‐ Check if increase in machine orders is 5% for previous 6 months 

1 year: ager project is complete 

-‐ Check if loss of orders is reduced by 50% for previous 12 months 

-‐ Check if increase in machine orders is 5% for previous 12 months 

4. Accountable for Benefits 

Accountable Benefit 

1. Susan Kelly: Reduce loss of maintenance contracts by 50% 

2. Susan Kelly: Increase new machine orders by 5% 

The Project Manger will ask the Senior User 

1. What are the expected benefits 

2. When do you expect to get these benefits 

3. How to measure these benefits 





37

Project Controls (part of PID) 


Processes 






Project 

mandate 






Structure 






Project Controls 



PBS 

This defines the level and mechanism of control by 

the Project Board, Project Manager, and Team 

Managers in accordance with “manage by 

excep(on” principle. This informa(on might be a 

duplicate of the similar informa(on in management 

strategies. 









38

Project Controls (part of PID) 

Document: Project Controls 


Date: 

1. Management Stages 

The project will be managed in three stages: 

• Stage 1 – iniDaDng the project 

• Stage 2 – preparing everything to start evaluaDng sample pens, 

including preparing requirements, selecDng the supplier, selecDng 

and buying sample pens, preparing evaluaDon forms, and selecDng 

evaluators 

• Stage 3 – preparing the final pens, including the evaluaDon of 

sample pens, selecDng, buying, and expediDng the receive of the 

final pen, and preparing the list We’ve of the preferred sales people to define who are some 

supposed to distribute the pens, customized and clients assessments who are supposed to be used to 

receive them 

throughout the project. They will provide 

us a good founda(on for controls. 

2. Communications 

CommunicaDons will be conducted based on the communicaDons 

management strategy, and the assessments described in this 

document. 

3. Controlling Issues and Risks 

Issues and risk will be submibed in the issue register and risk register 

by the project manager, and will be handled as described in the risk 

management strategy and configuraDon management strategy. 

4. Assessments 

Cost is assessed for the whole project and each stage. Cost = Planned 

Cost / Forecasted cost. This parameter will be compared to the 

tolerances set for the whole project or each of the stages. 

Time is assessed for the whole project and each stage: Time = 

Forecasted duraDon / Planned duraDon. This parameter will be 

compared to the tolerances set for the whole project or each of the 

stages. 

5. Escalation and delegation 

• Time: 15% 

• Cost: 20% 

• Quality: 

• Scope: 

• Benefits: 20% 

• Risk: > €7000 

escalated if forecasted Dme increases more than 15% 

escalated if forecasted cost increases more than 20% 

quality defined in project product descripDon 

each product is prioriDzed using MoSCoW 

escalated if expected benefits drop by 20% or more 

escalated it the risk has an impact of €7000 or more 

The above project management tolerances are set for issues, project 

plan, and stage plans. The decision will be escalated to the project 

board when either of the tolerances are exceeded. 

The way each issue or measurement affects above six variables will be 

documented in their respecDve registers or reports. 

This shows how we’re going to 

manage by excep(on. 





39

Project Plan (part of PID) 


Processes 






Project 

mandate 






Structure 




Product Descrip.ons(s) Project Plan 



The Project Plan is a high-‐level plan for the 

whole project, the basis for the 

performance measurement of the whole 

project, and the source for crea(ng 

detailed stage plans. 



PBS 









40


Document: Project Plan (Part 1) 


Date: 


This is the high-‐level plan for the whole Project. 

How much (me and money do we have 

2. Prerequisites, Assumptions, and external dependencies 

for the whole project How much 

Sales Manager and CEO will provide tolerance the necessary is acceptable Dme for the project, 

resources needed for evaluaDon are available, receiving sample pens is 

possible in a short Dme, evaluators will fill in the forms in Dme and 

precisely, supplier will prepare the pens in an appropriate Dme, 

Internal recourses will not be charge to the project. 


Allow buffer Dme for delivery of pens 

6. Tolerances 

Time: ±30% | Cost: ±40% | Scope: MoSCoW 

7. Products Description(s) Be careful, a “plan” is not an “schedule”; 

Abached: Project Product DescripDon (me schedules are just a part of each plan. 

8. Schedule 

Abached: Schedule for stage plan 1 

9. Product Breakdown Structure 





5. Budgets 

Project budget: €3,840 (internal people Dme is not charged), 45 days 

Risk Budget: €0, 0 days | Change Budget: €480, 5 days 

This is only a high-‐level PBS in the Project 

Plan, and will be detailed in Stage Plans. 





41


Document: Project Plan (part 2) Schedule Project: Pen Project Author: Project Manager 

Date: 

1. Activity bar chart 

This is the high-‐level schedule for the whole 

project; a part of the Project Plan. This is used 

to create (mephased informa(on such as 

resource alloca(ons and cash flows. 

2. Resources 

We should also prepare a list of the resources 

needed for the plan. It’s best to prepare it as a 

(mephased table, extracted from the schedule. 





42

Business Case (part of PID) 


Processes 






Project 

mandate 






Structure 





Project Controls Business Case 


Now that we have all the detailed informa(on 

in place, it’s (me to turn the “Outline Business 

Case” (which was only approximate) into a 

detailed and solid “Business Case”. 



PBS 









43

Business Case (part of PID) 

Document: Business Case 


Date: 

1. Executive summary 

Give out a quality pen to clients to increase contracts renewals 

Main Benefits 

• Reduce loss of maintenance contracts by 50% : €58,600 

• Increase new machine orders by 5%: €16,000 

Return on Investment: Cost = €4,800: Gain = €58,600 

2. Reasons 

Build a beber relaDonship with clients and reduce the loss in the 

renewal of maintenance contracts from 10% to 5%. 

CopyWorld365 had 4,200 maintenance contracts with an average 

profit of €200 per contract = €840,000. 

A 10% loss in contracts is a loss of €84,000 

3. Business options 

OpDon 1: do nothing : ConDnue losing contracts: loose €84,000 

OpDon 2: offer a calendar: 

• Value: not perceived as a quality item 

OpDon 3: offer pen that clients will conDnue to use : 

• Value: Contacts will hold on to the pens 

• Believe this will have the effect to reduce loss 

4. Expected benefits 

• Reduce loss of maintenance contracts by 50%±15% : €42,000/year 

• Increase new machine orders by 5%±1%: 16,000/year 

5. Expected dis-benefits 

• none 

6. Timescales 

• Project start: March 5 th , Project End: May 31 st (12 weeks) 

• Measure benefits on 28/12/2013 and 31/05/2014 

7. Costs 


• Other project costs: 

We’re 

€800 undertaking this project because its 

expected benefits are higher than its costs. 

8. Investment appraisal 

• Project cost: 

€4,800 

• Expected gain: €58,400 

• Time : 1 year 

• ROI: 1120.80% (to update) 

9. Major risks 

• There is risk that we can choose the wrong pen which the majority 

clients will not keep using the pen as expected 

The Business Case is an updated (refined) version of 

outline Business Case (with a lot more details) 





44

Tailoring of PRINCE2 (part of PID) 


Processes 






Project 

mandate 






Structure 




Four Strategy Docs Tailoring 





PBS 

The seventh PRINCE2 principle: Tailor to suit the 

project environment. 

So, how are we going to tailor PRINCE2 for this 

small project, to have enough control and not to 

overdo the management efforts 









45

Tailoring of PRINCE2 (part of PID) 

Document: Tailoring of PRINCE2 


Date: 

1. Adapting the Principles 

All PRINCE2 principles will be fully applied in the project. 

2. Adapting the Themes 

Build beber relaDonships with clients and reduce the loss in the 

renewal of maintenance contracts from 10% to 5%. 

CopyWorld365 had 4,200 maintenance contracts with an average 

profit of €200 per contract = €840,000. 

A 10% loss in contracts is a loss of €84,000 

3. Adapting the Terms 

The default PRINCE2 terminology will be used in the project, except for 

the Project Brief, which may also be called “project charter” in some 

documents or verbal communicaDons; they will both address the same 

management product. 

4. Adapting the Management Products 

The default PRINCE2 management products will be kept separated 

(each in a single document), with the same default PRINCE2 product 

descripDons, except that: we would not use formal and documented 

Work Packages except for those that are handled by a Team manager 

other than the Project Manager. Checkpoint Reports would be verbal 

too. 

5. Adapting the Processes 

All PRINCE2 processes will be kept separated and will be 

handled formally. 

6. Adapting the Roles 

• The same person will handle both the ExecuDve role and represent 

the corporate level. 

• The Project Assurance and Change Authority roles will be merged 

into the Project Board. 

• The Project Support role will be handled by the Project Manager. 

• The Project Manager will also have the role of Team Manager in 

most cases. 

Our objec(ve here is to apply the simplest possible -‐ 

yet full -‐ form of PRINCE2 so you can view the 

majority of PRINCE2 documents and get a be_er 

idea of how a typical midsize project works and see 

that all the PRINCE2 principles are applied. 

It’s common for small projects to 

handle the Star(ng up a Project 

process informally, or to combine it 

with Ini(a(ng a Project process; 

A small project like this would usually be 

tailored differently, but we’ve not 

simplified it enough, because we have 

demonstra(on purposes. 





46

Project Initiation Documentation (PID) 


Processes 






Project 

mandate 






Structure 









PBS 

The PID is a collec(on of a number of 

documents, it defines the whole project and 

provides a basis for its management (it acts as 

a contract between the Project Board and the 

Project Manager) 









47

Project Initiation Documentation (PID) 

Document: Project Initiation Documentation Project: Pen Project Author: Project Manager 

Date: 


The project will give choose a quality pen and give out about 400 pens 

to our clients. 

Project ObjecDves: 

• Choose a quality that meets specificaDons 

• Choose a pen that users will perceive as a quality pen 


This is mostly an assembly of other documents, 

1. Choose a pen 3. PromoDonal pen catalogues 

so we only have references to other documents 

2. Sales people list 4. List of clients that will receive a pen rather than embedding the informa(on here. 

Constraints and assumpDons: 

• Possible to find a pen in the catalogues provided 

Project Tolerances: 

1. Time: 3 months + 30% 

2. Cost: €7 for a pen: EsDmate €3400 for the project +-‐ 10% 

3. Quality: Pens must meet quality requirements 

2. Project Approach 

The company will choose a pen that meets the requirements from an 

exisDng business gig company. Project will be run internally. 

3. Business Case 

Abached: Business Case document 

4. Project Management Team Structure 

Abached: Project Management Team Structure document 

5. Role Descriptions 

This project uses the roles descripDon as defined by PRINCE2 

-‐ Link to the Roles DescripDons document 

6. Quality Management Strategy 

Abached: Quality Management Strategy document 

7. Configuration Management Strategy 

Abached: ConfiguraDon Management Strategy document 

8. Risk Management Strategy 

Abached: Risk Management Strategy document 

9. Communication Management Strategy 

Abached: CommunicaDon Management Strategy document 

10. Project Plan 

Abached: Project Plan document 

11. Project Controls 

Abached: Project Controls document 

12. Tailoring of PRINCE2 

Abached: Tailoring of PRINCE2 document 





48

Dependencies Diagram (part of the next Stage Plan) 


Processes 






Project 

mandate 







Structure 




Tailoring 

Project Plan 






PBS 

Dependencies 

This provides the dependencies between 

project elements which will later turn into a 

schedule. 









49


Document: Dependencies Diagram 


Date: 

1. Dependencies Diagram 

Requirements 

Logo 

Selected Supplier 

Legend: 

Stage 1 Stage 2 


suppliers 

Short list of qualified 

suppliers 


Short list of pens to 

be evaluated 

Dependencies can be provided with a network 

diagram (such as this), a table, etc. 

Purchase order of 

pens to be evaluated 


evaluation 



Received pens 

Evaluation form 

Sales people 

delivered 


Evaluation and filled 

in forms 



List of sales people 





50

Schedule (part of the next Stage Plan) 


Processes 






Project 

mandate 







Structure 




Tailoring 

Project Plan 






PBS Schedule 

Dependencies 

Now it’s (me to schedule the next stage in 

detail (compared to the Project plan) 









51


Document: Schedule for Stage 2 Plan Project: Pen Project Author: Project Manager 

1. Product Schedule 

Date: 

We can use a project planning soOware for 

scheduling the project. 

Note: durations shown for the groups of products are based on a rollup of products on all stages, rather than this specific stage. 





52

Next Stage Plan 


Processes 






Project 

mandate 






Structure 







Tailoring 

Project Plan 


Again, the “schedule” is not the “plan”, but 

only a part of it. We need more informa(on for 

a Stage Plan. 



PBS Schedule 

Dependencies 









53


Document: Plan for Stage 2 (description) Project: Pen Project Author: Project Manager 

Date: 


This is the plan for stage 2, during which we will prepare everything for, 

and conduct evaluaDon of the sample pens. 

2. Prerequisites, Assumptions, and external dependencies 

Resources needed for evaluaDon are available, potenDal sellers will 

respond quickly, and receiving sample pens is possible in a short Dme, 

Internal recourses will not be charge to the project. 


BizGigs company offers a good service 

Gigs4All provides a poor service 

6. Tolerances 

Time: ±20% | Cost: ±40% | Scope: ±0% 



8. Schedule 


9. Resources 





5. Budgets 

Stage budget: €640 (internal people Dme is not charged), 10 days 


Budgets ((me and money) and tolerances of each stage are 

determined separately; however, they should always be consistent 

with the budget and tolerances of the whole project (Project Plan). 

The End Stage Report and the Lessons Report are 

also submi_ed with the Next Stage Plan 





54

The first stage was ini(a(ng stage, when we 

only focus on planning the project. Execu(on 

starts from the second stage and in this 

sample, con(nues to the third (last) stage. 

Stage 2 

From now on, we’ll execute the project, 

monitor and control it, revise the plans, and 

prepare new plans in boundaries. 





55

Work Package 


Processes 






Project 

mandate 





Structure 








Tailoring 

Project Plan 



PBS 

Schedule 

Dependencies 


Work Package 

A Work Package is a set of informa(on about 

a certain deliverable or set of deliverables 

collated by the Project Manager (based on the 

Stage Plan) to formally pass the responsibility 

of its delivery to the team manager(s). 









56

Work Package 

Document: Work Package #1 


Date: 

1. Date 

2013-‐06-‐29 

2. Authorized body 

IT Department 

3. Description 

An evaluaDon form should be designed in a way that covers everything 

menDoned in the requirements document, yet simple enough for the 

evaluators to fill in. 

4. Techniques 

Since the data is to be collected in an spreadsheet later, the forms 

should be designed in a database friendly form. 

5. Interfaces 

If there are any quesDons about the requirements, the senior user 

would answer. 

5. Joint agreement 

A clear defini(on of the deliverable to be 

delivered by the team manager. 

The way we’re going to 

manage by excep(on. 

The project will not pay for internal resources, including the ones 

working on this work package. The original duraDon for this work 

package is two days; however, we are behind schedule and would be 

able to recover if it’s done earlier (less than one day) 

6. Tolerances 

Time: 0% | Cost: 0% | Scope: 0% | 

7. Constraints 

none The way they should report back to the 

Project Manager (in the form of 

8. Reporting arrangement Checkpoint Reports) 

All reports on this work package will be verbal and none-‐official, at 

least twice a day. 

9. Problem handling and escalation 

Any problem which has an effect on the Dme should be immediately 

escalated to the project manager. 

10. Approval method 

The senior user will approve this form, based on how well it covers the 

factors stated in the requirements document. 

When the package will be accepted 





57

Issue Register 


Processes 






Project 

mandate 








Tailoring 

Project Plan 

We should document and follow on important 

issues all the way through the project. 


Structure 






Work Package 


PBS 

Schedule 

Dependencies 









58


Document: Issue Register 


Data Date: Jun 30, 2013 

ID Descrip.on Type 

Date 

Raised 

Raised 

By 

Report 

Author 

Date: 

Priority Severity Status 

Closure 

Date 

01 

Selected supplier sent the catalog two 

days later than expected 

Problem/ 

concern 

Jun 29, 

2013 

Rose 

Carr 

Rose 

Carr 

High 

Level 2 

Open 

(last updated 

Jun 30, 2013) 

We have only one issue up to now, which is 

s(ll open. When the (me passes, this issue will 

be closed and other issues may arise. 

Issues with less importance will be 

documented and followed on in the Daily Log 

instead of the Issue Register. 

We should always try to close any open 

issues as soon as possible. 





59

Issue Report 


Processes 






Project 

mandate 





Issue Report 



Structure 







Tailoring 

Project Plan 



PBS 

Schedule 

Dependencies 

Work Package 

Issue Reports are only created when we need 

to handle an issue formally. They consist of the 

descrip(on, impact assessment, and 

recommenda(ons for a certain issue. 









60

Issue Report 

Document: Issue Report for ID-01 Project: Pen Project Author: Project Manager 

Data Date: Jun 30, 2013 

Date: 


Date 

Raised 

Raised 

By 

Report 

Author 

Priority 

Severity 

01 

Selected supplier sent the catalog two days 

later than expected 

Problem/ 

concern 

Jun 29, 2013 Rose Carr Rose Carr High Level 2 

1. Impact Analysis 

AcDviDes contained in this product are criDcal (zero float), and 

therefore, the two day delay on receiving the catalog makes the whole 

project late. Given that we had some problems arranging to have 

access to resources for the future acDviDes and they are booked for the 

planned dates, this delay might cause problems in resource 

availabiliDes in future too. So, it’s important to recover this Dme as 

soon as possible. 

1. Recommendation 

Two future acDviDes for preparing the evaluaDon forms and preparing 

the list of evaluators can be crashed by using more resources. The best 

opDon for extra resources is the IT Department; they are capable of 

helping us doing these two acDviDes faster. 

1. Decision 

Accept 

1. Approved by 

Senior Supplier, Terry Clinton 

1. Decision date 

Jul 1, 2013 

1. Closure date 

Jul 1, 2013 

This is the issue we’re going to 

handle formally through the 

Issue Report. 

This instance of the report shows the issue 

aOer its closure. The report might have 

been ini(ally created as soon as the issue 

is captured. 





61



Processes 






Project 

mandate 








Tailoring 

Project Plan 

Issue Report 

All registers, including the Issue Register, 

are maintained con(nuously. It is created 

during the ini(a(on stage. 


Structure 






Work Package 


PBS 

Schedule 

Dependencies 









62


Document: Issue Register 


Data Date: Jul 19, 2013 

Date: 


Date 

Raised 

Raised 

By 

Report 

Author 

Priority Severity Status 

Closure 

Date 

01 

Selected supplier 

sent the catalog 

two days later than 

expected 

Problem/ 

concern 

Jun 29, 

2013 

Rose Carr Rose Carr High Level 2 Closed 

Jul 1, 

2013 

02 

Five evaluators did 

not return the 

forms in Dme 

Problem/ 

concern 

Jul 18, 

2013 

Rose Carr Rose Carr High Level 2 

Open 


Jun 30, 2013) 

03 

EvaluaDon forms of 

four evaluators do 

not seem precise 

Off-specificaDon 

 

Jul 18, 

2013 

Rose Carr Rose Carr High Level 0 

Open 


Jun 30, 2013) 

The first issue is now closed and two 

new issues captured. 





63

Highlight Report 


Processes 






Project 

mandate 





Issue Report 



Structure 






Tailoring 

Project Plan 



Project Manager uses a Highlight Report to 

inform the Project Board (and possibly other 

stakeholders) of the performance of the stage 

and the whole project at predefined intervals. 


Work Package 


PBS 

Schedule 

Dependencies 









64

Highlight Report 

Document: Highlight report # 4 


Date: 

1. Date and period of the report 

End of the second week of Stage 2, for a period of one week. 

2. Status summary 

TF: +5% | CF: ±0 | Project is going well so far. 

3. Work packages in this period 

• Selected supplier – completed 

• Catalogs of pens – completed (behind schedule) 

• Short list of pens to be evaluated – completed (behind schedule) 

• Purchase order of pens to be evaluated – not finished (behind 

schedule) 

• Sample pens for evaluaDon – not started (behind schedule) 

• Logo – completed 

I took two extra days for the supplier to send us the catalogs, and it 

made a delay in this and all successor work packages. 

5. Stage tolerances 

Time: TF = +5%, inside the tolerances set for the stage, and for the 

management level. 

Cost: CF = ±0% 

6. Change requests 

• We fell behind schedule because the supplier sent us catalogs two 

days later than we expected. We designed a correcDve acDon to get 

help from the IT department for two of our future work packages. 

We will recover Dme by this. (approved by project manager) 

7. Key issues and risks 

No excep(on yet. 

We might have more delays in receiving evaluaDon pens and the final 

pens from the supplier. 

4. Work packages for the next period 

• Purchase order of pens to be evaluated (moved from this period) 

• Sample pens for evaluaDon (moved from this period) 

• List of evaluators û 

• EvaluaDon form û 

• Next stage plan 

û We are going to get help from IT department to conduct these 

two packages faster and catch up on the planned schedule. 





65



Processes 






Project 

mandate 





Issue Report 



Structure 




Tailoring 

Project Plan 




PBS 

We need to define a more 

detailed PBS for the next stage. 




Work Package 


PBS 

Schedule 

Dependencies 









66


Document: PBS for Stage 2 (Mindmap) Project: Pen Project Author: Project Manager 

Date: 

1. Mindmap presentation of PBS 

Legend 

The deliverables that are supposed to be 

delivered in next stage will be broken down into 

more details now. 





67



Processes 






Project 

mandate 






Structure 





Tailoring 

Project Plan 


Issue Report 



PBS 

Dependencies 

And we need to define 

dependencies for the 

elements of the next stage. 




Work Package 


PBS 

Schedule 

Dependencies 









68


Document: Dependencies Diagram 


Date: 

1. Dependencies Diagram 

Requirements 

Logo 

Selected Supplier 

Legend: 

Stage 1 Stage 2 


suppliers 


suppliers 



be evaluated 

Usually the dependencies 

of the next stage are not 

defined up to now. 


pens to be evaluated 


evaluation 



Received pens 

Evaluation form 

Sales people 

delivered 


Evaluation and filled 

in forms 



List of sales people 





69



Processes 






Project 

mandate 





Issue Report 



Tailoring 




Structure 



Project Plan 


PBS Schedule 

Dependencies 




Work Package 

And now it’s (me to 

schedule the next stage. 


PBS Schedule 

Dependencies 









70


Document: Schedule for Stage 3 Plan Project: Pen Project Author: Project Manager 

Date: 

1. Activity bar chart 

This schedule is compa(ble with the 

one in the Project Plan; however, we 

can update the Project Plan schedule 

based on the detailed informa(on 

produced here. 

2. Resources 

2. Product Breakdown Structure 

Abached: Product Breakdown Structure 

Note: durations shown for the groups of products are based on a rollup of products on all 

stages, rather than this specific stage. 





71



Processes 






Project 

mandate 





Issue Report 



Tailoring 




Structure 





Project Plan 


PBS Schedule 

Dependencies 

Now we assemble and 

add more informa(on to 

the previous documents to 

create an Stage Plan. 


Work Package 


PBS 

Schedule 

Dependencies 









72


Document: Next Stage Plan (for Stage 3) Project: Pen Project Author: Project Manager 

Date: 


This is the plan for stage 3, during which we will prepare the pens for 

distribuDon, by selecDng the supplier and the type of pen based on 

evaluaDons in the last stage, place order, and expedite the order. 

2. Prerequisites, Assumptions, External Dependencies 

Evaluators will fill in the forms in Dme and precisely, supplier will 

prepare the pens in an appropriate Dme, Internal recourses will not be 

charge of the project. 

6. Tolerances 

Time: ±50% | Cost: ±30% | Scope: MoSCoW 



8. Schedule 



Allow buffer Dme for delivery of pens 

InvesDgate the ISO standard for pens: ISO 12757-‐2 





5. Budgets 

Stage budget: €3,200 (internal people Dme is not charged), 25 days 


This plan defined the next stage, 

based on the scope, (me, cost, 

quality, etc. 





73

Configuration Management 


Processes 






Project 

mandate 

Configura.on Management 





Structure 







Tailoring 

Project Plan 



Issue Report 


Configura(on Management is used 

throughout the project to track all the 

changes and states of the 

Next Stage Plan configura(on of the project (its 

building parts). 

PBS 

Schedule 

Dependencies 


Work Package 


PBS 

Schedule 

Dependencies 









74

Configuration Management 

Document: Configuration Management Project: Pen Project Author: Project Manager 

Data Date: 2013-07-20 

ID 

01 

02 

Title 

List of potenDal 

suppliers 


suppliers 

Current 

Version 

Date of last 

update 

Mngmnt 

Stage 

Product 

Group 

Status Source Owner 

1 2013-‐06-‐21 2 Supplier Approved Int. Purchasing dep. 02 

1 2013-‐06-‐21 2 Supplier Approved Int. Purchasing dep. 03 

03 Selected supplier 1 2013-‐06-‐25 2 Supplier Approved Int. Purchasing dep. 04 

04 Catalog of pens 1 2013-‐06-‐28 2 Supplier Received Ext. Purchasing dep. 05 01 

05 

06 


be evaluated 


pens to be evaluated 

1 2013-‐06-‐29 2 

1 2013-‐06-‐29 2 

07 List of evaluators 1 2013-‐07-‐03 2 

EvaluaDon 

pens 

EvaluaDon 

pens 

Internal 

EvaluaDon 

Succe-ssors 

 

Approved Int. Purchasing dep. 06 



08 EvaluaDon form 2 2013-‐07-‐03 2 

Internal 

EvaluaDon 


This is a list of all deliverables, their 

09 EvaluaDon results 1 2013-‐07-‐19 3 

Internal 

EvaluaDon 

Approved informa(on, Int. and state. Purchasing This informa(on dep. 10 would 02, 03 

be updated regularly, and watched to be sure 

10 EvaluaDon report 3 

Internal 

EvaluaDon 

In development that everything Int. is closed 

Purchasing 

appropriately, 

dep. 15 and 

changes are not out of control. 

11 List of clients 3 DistribuDon Pending Ext. Sales dep. 

This library is set up in the ini(a(on stage, and 

12 List of sales people 3 DistribuDon Pending Ext. Sales dep. 

updated/revised through delivery stages. 

13 Requirements 2 2013-‐06-‐20 2 Final Pens Approved Int. Purchasing dep. 05 

14 Logo 4 2013-‐06-‐27 2 Final Pens Approved Int. Purchasing dep. 15 

15 

Purchase order of the 

finalized pens 

3 Final Pens Pending Int. Purchasing dep. 

Date: 

Issues 

Risk 

s 





75

Configuration Item Record 


Processes 






Project 

mandate 






Issue Report 



Tailoring 




Structure 



Project Plan 


Configura.on 

Item Record 

PBS Schedule 

Dependencies 




Work Package 


PBS 

Schedule 

Dependencies 









76

Configuration Item Record 

Document: Configuration Item Record #14 Project: Pen Project Author: Project Manager 

Data Date: 2013-07-20 

Date: 

Item ID 

Item Name 

Current version 

Date of last update 

Management stage 

Item Type 

Status 

Source 

Owner 

Users 

LocaDon 

Related 

Cross Reference 

14 

Logo 

4 

2012-‐06-‐27 

2 

MarkeDng 

Approved (ready for use) 

Internal (MarkeDng Department) 

Purchasing Department 

All (Public) 

MarkeDng Pack 

MarkeDng Guidelines Doc (MKT045) 

MarkeDng Pack 

NA 





77

End Stage Report and Lessons Report 


Processes 






Project 

mandate 






Issue Report 

End Stage Report 



Structure 




Tailoring Highlight Report Next Stage Plan 

Now that we’re reaching the end of the stage, it’s 


Configura.on PBS Schedule 

(me to prepare an End Stage Report to provide the 

Project Board Controls with a summary Business Case of the overall 

Item 

project 

Record 

 

Dependencies 

state and ask them for their next decision. 

Lessons Report 

Benefits Review Plan This report also included a Lessons Report, which 

describes all the lessons End Stage learned Report through the stage. Work Package 


PBS 

Schedule 

Dependencies 









78

End Stage Report 

Document: End Stage Report #2 


Date: 

1. Project Manager’s report 

This stage went well, and we were on schedule and on budget. We had 

some minor delays in the middle of the stage, which we could recover 

with the help of the IT Department. 

2. Review of the business case 

The business case stays viable and unchanged. We’ve realized that we 

are actually able to buy quality pens in 6 to 8 Euros range. Either of the 

four selected pens for evaluaDon meet all the requirements. 

3. Review of the objectives 

• Time: 

• Cost: 

• Scope: 

• Quality: 

• Risks: 

• Benefits: 

10 days, on schedule 

€560, on budget 

as defined 

as defined 

as defined 

as defined 

4. Review of the team performance 

How we’ve performed so far 

(Six project variables) 

All team members spend enough Dme for the project, and performed 

as planned. 

5. Review of the products 

• Supplier: potenDal suppliers were reviewed, and the best opDon 

selected for the project. 

• EvaluaDon Pens: four of the pens selected to be evaluated in the 

next stage. 

• Internal EvaluaDon: evaluators are selected to evaluate the sample 

pens in the next stage. 

• Logo: an appropriate version of the logo was prepared to be printed 

on the pens. 

6. Forecasts 

TF: 0% | we forecast the project to be in Dme for the whole project. 

CF: -‐17% | we forecast the project to be finished with a cost 17% less 

than the planned cost. 

7. Issues and risks 

Issue: Supplier provided us with the catalogs with two days delay. 

Risk: the supplier might have more delays in preparing the final pens. 

8. Lessons learned 

Abached: Lessons Report #2 

No excep(on yet 





79

Lessons Report (part of End Stage Report) 

Document: Lessons report #2 


Date: 


We had a successful stage, and learned a lesson, which helps us avoid 

problems in future. We also had some posiDve points, and we believe 

that we can experience them in future by paying abenDon to their root 

causes. 

2. Scope of the report 

The second stage of the project 

What we’ve learned through the stage. 

3. Lessons 

What went well: 

• We could easily choose the supplier, because the team provided us 

with needed informaDon in Dme, and had good communicaDons and 

expediDng capabiliDes. We should always take help from such 

people in our projects. 

• We could easily choose the evaluators, because of the historical 

records we had in our database of employees. This kind of 

informaDon will always be handy. 

• The help of IT Department was really useful, and we couldn’t 

recover the delay without their help. Having cross-‐funcDonal 

employees in IT Department. 

What didn’t went well: 

• There were delays in receiving catalogs to choose evaluaDon pens, 

and this delayed all its successors. In retrospecDve, we realized that 

we could ask them for the catalogs sooner and avoid such problems. 

We should be more careful with scheduling our acDviDes. 





80

This is the last stage of the project. 

Stage 3 

Final Stage 

We should also perform the Closing a 

Project process at the end of this stage. 





81

Quality Register 


Processes 






Project 

mandate 







Structure 







Tailoring 

Project Plan 


Issue Report 


Configura.on 

Item Record 

End Stage Report We should also have a Quality 

Register to document all the quality 


management ac(vi(es that are 

PBS Schedule planned or have taken place 

Dependencies throughout the project. This is 

created during the ini(a(on stage. 





Work Package 

PBS 

Schedule 

Dependencies 









82

Quality Register 

Document: Quality Register 


Data Date: 2013-07-20 

Date: 

Quality ID 

Product ID(s) 

Product Name 

Quality Method 

Producer 

Quality 

Reviewer 

Approver 

ProducDon date 

Target Quality 

Review Date 

Actual Quality 

Review Date 

Target Approval 

Date 

Actual Approval 

Date 

Result 

Records 

01 01 List of potenDal suppliers InspecDon John Bob Frank 6-‐21 6-‐20 6-‐21 6-‐20 6-‐21 Pass Link 

02 02 Short list of qualified suppliers InspecDon John Bob Frank 6-‐21 6-‐21 6-‐21 6-‐21 6-‐21 Pass Link 

03 03 Selected supplier InspecDon John Bob Frank 6-‐25 6-‐25 6-‐26 6-‐25 6-‐27 Fail Link 

04 05 

Short list of pens to be 

evaluated 

¢ Data is taken from the Project, Stage, Team Plan (Schedule) 

¢ Data is taken from the Product DescripDons (Project Plan) 

¢ Results of Quality Tests + Links 

InspecDon John Bob Frank 6-‐29 6-‐30 6-‐30 6-‐30 7-‐1 Pass Link 

05 06 

Purchase order of pens to be 

evaluated 

InspecDon Robin Stephan Frank 6-‐29 6-‐30 6-‐30 6-‐30 7-‐2 Pass Link 

06 

07, 

08, 

09, 10 

EvaluaDon of pens InspecDon Robert Stephan Frank 7-‐28 7-‐29 

07 11, 12 List of clients and sales people inspecDon Mary Bob Frank 7-‐30 7-‐30 

08 13 Requirements inspecDon Tom 

Stephan, 

Bob 

Frank 6-‐20 6-‐20 6-‐22 

09 14 Logo InspecDon Daniel Mary Frank 6-‐27 6-‐27 6-‐27 





83

Product Status Account 


Processes 






Project 

mandate 







Structure 





Tailoring 

Project Plan 


Issue Report 


Configura.on 

Item Record 



PBS Schedule 

Dependencies 

Product Status 

Account 







Work Package 

PBS 

Schedule 

Dependencies 









84

Product Status Account 

Document: Product Status Account #6 Project: Pen Project Author: Project Manager 

Date: 

1. Scope 

All products for the third stage 

2. Date Produced 

2013-‐07-‐20 

ID 

Title 

Current 

Version 

Date of last 

update 

Mngmnt 

Stage 

Product 

Group 

Status Source Owner 

Succe-ssors 

 

Issues 

Risk 

s 

09 EvaluaDon results 1 2013-‐07-‐19 3 

Internal 

EvaluaDon 

Approved Int. Purchasing dep. 10 02, 03 

10 EvaluaDon report 3 

Internal 

EvaluaDon 

In development Int. Purchasing dep. 15 

11 List of clients 3 DistribuDon Pending Ext. Sales dep. 

12 List of sales people 3 DistribuDon Pending Ext. Sales dep. 

15 

Purchase order of the 

finalized pens 

3 Final Pens Pending Int. Purchasing dep. 





85

End Project Report and Lessons Report 


Processes 






Project 

mandate 







Structure 








Tailoring 

Project Plan 




PBS 

Schedule 

Dependencies 

Issue Report 


Configura.on 

Item Record 



PBS 

Schedule 

Dependencies 

We should prepare a End Project Report 

at the end of Lessons the project Report to review how 

the project performed against the ini(al 

PID. This Work also Package includes a Lessons Report, 

which review all the lessons learned 

through the project. 


Account 

End Project Report 










86

Lessons Report (part of End Project Report) 

Document: Lessons report #3 


Date: 


The project was successful; however, we learned that we should be 

more careful with evaluators, and Dming of the tasks of the supplier. 

There were some posiDve points in the project which we should try to 

keep in our future projects. 

2. Scope of the report 

The end of the project 

3. Lessons 

What went well 

• We could easily choose the supplier, because the team provided us 

with needed informaDon in Dme, and had good communicaDons and 

expediDng capabiliDes. We should always take help from such 

people in our projects. 

• We could easily choose the evaluators, because of the historical 

records we had in our database of employees. This kind of 

informaDon will always be handy. 

• The help of IT Department was really useful, and we couldn’t 

recover the delay without having cross-‐funcDonal employees in the 

IT Department. 

3. Lessons (continue) 

What could have gone beber 

• There were delays in receiving catalogs to choose evaluaDon pens, 

and this delayed all its successors. In retrospect we realized that we 

could ask them for the catalogs sooner and avoid such problems. 

We should be more careful with scheduling our acDviDes. 

• 9 out of 20 evaluators did not do their tasks properly. We realized 

that they are not serious enough in their other tasks too. we can add 

some extra informaDon in our employee database to conDnuously 

capture these informaDon, and be able to have more educated 

selecDons in future. 

What we’ve learned through this 

project. This informa(on would be 

useful for our future projects. 





87

End Project Report 

Document: End Project Report 


Date: 

1. Project Manager’s report 

Pens were prepared according to the requirements, in Dme (with a 

lible more Dme, within the tolerance of the project), and within 

budget. We faced minor troubles in the second and third stages, which 

were resolved appropriately. 

2. Review of the business case 

The final product of the project is delivered according to the plans, and 

aligned with the business case. We forecast the benefits to be 

achieved; however, we can only be sure ager the 6 month and 12 

month review of the benefits. 

3. Review of the objectives 

• Targets: 

• Time: 

49 days, within tolerance 

• Cost: 

€3760, on budget 

• Scope: 100%, as defined 

• Quality: as defined 

• Risks: 

as defined 

• Benefits: as defined 

• Strategies: 

• CommunicaDons: very effecDve 

• Risk: 

a lible ineffecDve in risk assessment 

• ConfiguraDon: effecDve 

• Quality: effecDve 

How did we perform the whole project 

4. Review of the products 

Final product: 400 quality pens within the range of €6 to €8, ready to 

be distributed among clients 

Product groups in product breakdown structure: 

• Supplier: we were saDsfied with the selected supplier. 

• EvaluaDon Pens: four types of pens were selected and purchased to 

be evaluated by internal staff. 

• Internal EvaluaDon: 20 evaluators tested the four sample pens, and 

filled-‐in the respecDve forms. The forms were analyzed to find the 

best choice. 

• DistribuDon: the list of the clients to receive the pens and the sales 

people responsible for distribuDng them was prepared, and the pens 

were handed over to them. 

• Final Pens: the requirements of the pens were defined, the logo 

redesigned, and the order for 400 pens placed. Team expedited the 

order to receive it in Dme. 

5. Review of the team performance 

Most team members spent enough Dme on the project, and performed 

as planned. The only excepDon was the evaluators of the pens; 9 out of 

20 evaluators did not return their forms on Dme, or seemed like they 

have not truly tested the pens. Their results were omibed, in order to 

keep the evaluaDon high-‐quality, and to stay on schedule. 

6. Lessons learned 

Abached: Lessons Report #3 





88

Summary 





89

Summary 

What we practiced in this sample project: 

• Pre-Project 

• Project mandate 

• Daily Log 

• Lessons Log 

• Project Brief 

• Project Product Description 

• Project Management Team Structure 

• Outline Business Case 

• Initiation Stage Plan 

• Stage 1 

• Benefits Review Plan 

• Risk Register 

• Project Initiation Documentation 

• Communication Management Strategy 

• Product Description(s) 

• Project Controls 

• Tailoring of PRINCE2 

• Business Case 

• Project Plan 

• Next Stage Plan 

• End Stage Report 

• Stage 2 

• Work Package 

• Issue Register 

• Issue Report 

• Lessons Report 

• Highlight Report 

• Configuration Management 

• Configuration Item Record 

• Next Stage Plan 

• End Stage Report 

• Stage 3 

• Product Status Account 

• Lessons Report 

• End Project Report 





90

Summary 


Processes 






Project 

mandate 







Structure 





Issue Report 


Configura.on 

Item Record 



PBS Schedule 

Dependencies 


Account 

End Project Report 








Work Package 

PBS 

Schedule 

Dependencies 









91

Summary 

How this sample project helps you and your company: 

• Helps you to better understand PRINCE2 in practice 

• Helps you document a standard project 

• Can be shared with other team members and even external stakeholders of your projects 

• Can be used as a reference in your projects 

• Can be updated and tailored based on the feedbacks in your projects 

(continuous improvement) 





92

Summary 

Management Plaza’s 

PRINCE2 Founda.on Course 


Sample PRINCE2 Project 


PRINCE2 Prac..oner Course 


Live Implementa.on of the 

Pen Project in CorePM 


PRINCE2 Training Manuals 


PRINCE2 Templates 


PRINCE2 Flashcards 

And even more… 





93

Summary 


PRINCE2 Founda.on Course 


Sample PRINCE2 Project 


PRINCE2 Prac..oner Course 


Live Implementa.on of the Pen 

Project in CorePM 


PRINCE2 Training Manuals 


PRINCE2 Templates 


PRINCE2 Flashcards 

mgmtplaza.com 





94

Recommended material: 

Introduction 

An Introduction to PRINCE2 

By Frank Turley 

The PRINCE2 Foundation 

Training Manual 

By Frank Turley 

PRINCE2 in Practice 

A practical approach to create 

project management documents 

By Henny Portman 

http://bit.ly/1d6WcFd 



http://bit.ly/16g7uy4 


http://bit.ly/16yGGwB 


95

Notes Page 

Notes 





96

Notes Page 

Notes 





97

Notes Page 

Notes 





98

Notes Page 

Notes 





99

Notes Page 

Notes 





100

Notes Page 

Notes 





101

PRINCE2-SampleProject-Premium-MP847

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?