You are on page 1of 44

HOW TO USE THIS TEMPLATE:

Introduction

The template reflects the steps set out in the PRINCE2 Method and is
designed to prompt the Project Manager and help in the creation of the
Project Initiation Document (PID). There is also a Product Description for the
PID at Appendix A of the PRINCE2 Manual.

The Project Initiation Document will reflect the information contained in the
Project Approach, mainly integrated within the Project Plan. The PID will be
created by expanding the Project Brief: there are separate Templates for the
Project Brief and Project Approach.

Loading the file

This template has been produced using Microsoft Word 2003. To use it, load
up the file directly from the directory and starting from page 1 follow the
prompts (in [...] brackets).

Deleting the [....] text

When the template is complete, the whole Project Initiation Document can be
printed and approved.

Prior to printing, you should delete all [....] prompt text.

Saving the Project Initiation Document under its own name

Save the Project Initiation Document by selecting the “SAVE-AS” command;


this will avoid overwriting the standard template. You must specify your own
Project Directory.
Once your PID is completed check the document against the following
Quality Criteria:

 The Project Initiation Documentation correctly represents the project

 It shows a viable, achievable project that is in line with corporate


strategy or overall programme needs

 The project organization structure is complete, with names and titles.


All the roles have been considered and are backed up by agreed role
descriptions. The relationships and lines of authority are clear. If
necessary, the project organization structure says to whom the Project
Board reports

 It clearly shows a control, reporting and direction regime that can be


implemented, appropriate to the scale, risk and importance of the
project to corporate or programme management

 The controls cover the needs of the Project Board, Project Manager
and Team Managers and satisfy any delegated assurance
requirements

 It is clear who will administer each control

 The project objectives, approach and strategies are consistent with the
organization’s corporate social responsibility directive, and the project
controls are adequate to ensure that the project remains compliant with
such a directive

 Consideration has been given to the format of the Project Initiation


Documentation. For small projects a single document is appropriate.
For large projects it is more appropriate for the Project Initiation
Documentation to be a collection of stand-alone documents. The
volatility of each element of the Project Initiation Documentation should
be used to assess whether it should be stand-alone, e.g. elements that
are likely to change frequently are best separated out
PROJECT DOCUMENTATION

PROJECT INITIATION DOCUMENT (PID)

Project:

Release:

Date:

PRINCE2

Author:

Owner:

Client:

Document Ref:

Version No:
1 Project Initiation Document History

1.1 Document Location


This document is only valid on the day it was printed.
The source of the document will be found at this location – [insert folder structure]

1.2 Revision History


Date of this revision:
Date of next revision:

Revision Previous Summary of Changes Changes marked


date revision
date
First issue

1.3 Approvals
This document requires the following approvals.
Signed approval forms should be filed appropriately in the project filing system.

Name Signature Title Date of Version


Issue

1.4 Distribution
This document has been distributed to:

Name Title Date of Version


Issue
2 Table of Contents

Page

1 Project Initiation Document History 1


1.1 Document Location 1
1.2 Revision History
1.3 Approvals
1.4 Distribution

2 Table of Contents

3 Project Definition

4 Project Approach

5 Business Case

6 Project Management Team Structure

7 Role Descriptions

8 Quality Management Strategy

9 Configuration Management Strategy

10 Risk Management Strategy

11 Communication Management Strategy

12 Project Plan

13 Project Controls

14 Tailoring of PRINCE2
3 Project Definition
[Extracted from the Project Brief. Explains what the project needs to achieve. It
should include:

- Background

- Project objectives and desired outcomes

- Project scope and exclusions

- Constraints and assumptions

- The user(s) and any other known interested parties

- Interfaces]

4 Project Approach
[Extracted from the Project Brief. Defining the choice of solution the project will use
to deliver the business option selected from the Business Case, and taking into
consideration the operational environment into which the solution must fit]

5 Business Case (for both options)


5.3 Executive Summary
[Highlights the key points in the Business Case, which should include important
benefits and the return on investment (ROI)]

5.4 Reasons
[Explains the reasons for undertaking the project and how the project will enable the
achievement of corporate strategies and objectives]

5.5 Business Options


[Analysis and reasoned recommendation for the base business options of: do
nothing, do the minimal or do something]

5.6 Expected Benefits


[The benefits that the project will deliver expressed in measurable terms against the
situation as it exists prior to the project]
5.7 Expected Dis-benefits
[Outcomes perceived as negative by one or more stakeholders]

5.8 Timescale
[Over which the project will run (summary of the Project Plan) and the period over
which the benefits will be realised]

5.9 Costs
[A summary of the project costs (taken from the Project Plan), the ongoing
operations and maintenance costs and their funding arrangements]

5.10 Investment Appraisal


[Comparison of the aggregated benefits and dis-benefits to the project costs
(extracted from the Project Plan) and ongoing incremental operations and
maintenance costs. The investment appraisal should address how the project will be
funded]

5.11 Major Risks


[A summary of the key risks associated with the project together with the likely
impact and plans should they occur]

[Describing the justification for the project based on estimated costs, risks and
benefits]

6 Project Management Team Structure


[A chart showing who will be involved with the project]

7 Role Descriptions
[For the project management team and any other key resources]

8 Quality Management Strategy (appendix 1)


[Describing the quality techniques and standards to be applied, and the
responsibilities for achieving the required quality levels]
9 Configuration Management Strategy (not to be included)
[Describing how and by whom the project’s products will be controlled and protected]

10 Risk Management Strategy (appendix 2 and 3)


[Describing the specific risk management techniques and standards to be applied,
and the responsibilities for achieving an effective risk management procedure]

11 Communication Management Strategy (appendix 4)


[To define the parties interested in the project and the means and frequency of
communication between them and the project]

12 Project Plan (appendix 5)


[Describing how and when the project’s objectives are to be achieved, by showing
the major products, activities and resources required on the project. It provides a
baseline against which to monitor the project’s progress stage by stage]

13 Project Controls
[Summarising the project level controls such as stage boundaries, agreed
tolerances, monitoring and reporting]
Example Having established that Time and Cost have restrictions, majority of our project
controls will be based around these. The three largest therefore are:

Time: Escalated if forecasted time increases more than 10%


Cost: Escalated if forecasted cost increases more than 1%
Risk: Escalated it the risk has an impact of £500 or more

Cost and Risk in particular have limited margins to work in due to the limited budget left for
emergencies, while Time has a greater degree of flexibility due to the project plan being
designed with break periods allowing for delays.

The remaining criteria are:

Scope: Escalated if any changes occur in the scope


Benefits: Escalated if expected benefits drop by 20% or more
The Benefits of the Service desk have been calculated at such a high rate it will take a
considerable about of change for them to become a worry as such it has been allowed a
greater range than the standard ones around costing.

Throughout the project, we will use Earned Value Analysis will be used for any Cost
Assessment, and Earned Schedule Analysis will be used for any Time assessments, this is due to
advice by Turley and Rad (2013).

14 Tailoring of PRINCE2
[A summary of how PRINCE2 will be tailored for the project]
Appendix 1

HOW TO USE THIS TEMPLATE:

Introduction

The template reflects the steps set out in the PRINCE2 Method and is designed to
prompt the Project Manager and help in the creation of the Quality Management
Strategy. There is also a Product Description for the Quality Management Strategy
at Appendix A of the PRINCE2 Manual.

Loading the file

This template has been produced using Microsoft Word 2003. To use it, load up the
file directly from the directory and starting from page 1 follow the prompts (in [...]
brackets).

Deleting the [....] text

When the template is complete, the whole Quality Management Strategy document
can be printed and approved.

Prior to printing, you should delete all [....] prompt text.

Saving the Quality Management Strategy document under its own name

Save the Quality Management Strategy document by selecting the “SAVE-AS”


command; this will avoid overwriting the standard template. You must specify your
own Project Directory.

Once your Quality Management Strategy is complete check the document


against the following Quality Criteria:

 The strategy clearly defines ways in which the customer’s quality expectations
will be met

 The defined ways are sufficient to achieve the required quality

 Responsibilities for quality are defined up to a level that is independent of the


project and Project Manager

 The strategy conforms to the supplier’s and customer’s quality management


systems
 The strategy conforms to the corporate or programme quality policy

 The approaches to assuring quality for the project are appropriate in the light
of the standards selected.
PROJECT DOCUMENTATION

QUALITY MANAGEMENT STRATEGY

Project:

Release:

Date:

PRINCE2

Author:

Owner:

Client:

Document Ref:

Version No:
1 Quality Management Strategy History

1.1 Document Location


This document is only valid on the day it was printed.
The source of the document will be found at this location – [insert folder structure]

1.2 Revision History


Date of this revision:
Date of next revision:

Revision Previous Summary of Changes Changes


date revision date marked
First issue

1.3 Approvals
This document requires the following approvals.
Signed approval forms should be filed appropriately in the project filing system.

Name Signature Title Date of Version


Issue

1.4 Distribution
This document has been distributed to:

Name Title Date of Issue Version


2 Table of Contents
Page

1 Quality Management Strategy History 1


1.1 Document Location 1
1.2 Revision History
1.3 Approvals
1.4 Distribution

2 Table of Contents

3 Introduction

4 Quality Management Procedure

5 Tools and Techniques

6 Records

7 Reporting

8 Timing of Quality Management Activities

9 Roles and Responsibilities


3 Introduction
[Purpose, objectives, scope and responsibility of the strategy]

4 Quality Management Procedure


[A description of (or reference to) the quality management procedure to be used.
Any variance from corporate or programme management quality standards should
be highlighted, together with a justification for the variance. The procedure should
cover:

l Quality planning

l Quality control: the project’s approach to quality control activities. This


may include:

o Quality standards

o Templates and forms to be employed (e.g. Product Description(s),


Quality Register)

o Definitions of types of quality methods (e.g. inspection, pilot)

o Metrics to be employed in support of quality control

l Quality assurance: the project’s approach to quality assurance activities.


This may include:

o Responsibilities of the Project Board

o Compliance audits

o Corporate or programme management reviews]

5 Tools and Techniques


[Any quality management systems or tools to be used, and any preference for
techniques which may be used for each step in the quality management procedure]

6 Records
[What quality records will be required and where they will be stored including the
composition and format of the Quality Register?]
7 Reporting
[Any quality management reports that are to produced, their purpose, timing and
recipients]

8 Timing of Quality Management Activities


[States when formal quality management activities are to be undertaken, for example
audits (this may be a reference to the Quality Register)]

9 Roles and Responsibilities


[Defines the roles and responsibilities for quality management activities, including
those with quality responsibilities from corporate or programme management]
Appendix 2

HOW TO USE THIS TEMPLATE:

Introduction

The template reflects the steps set out in the PRINCE2 Method and is designed to
prompt the Project Manager and help in the creation of the Risk Management
Strategy. There is also a Product Description for the Risk Management Strategy at
Appendix A of the PRINCE2 Manual.

Loading the file

This template has been produced using Microsoft Word 2003. To use it, load up the
file directly from the directory and starting from page 1 follow the prompts (in [...]
brackets).

Deleting the [....] text

When the template is complete, the Risk Management Strategy document can be
printed and approved.

Prior to printing, you should delete all [....] prompt text.

Saving the Risk Management Strategy document under its own name

Save the Risk Management Strategy document by selecting the “SAVE-AS”


command; this will avoid overwriting the standard template. You must specify your
own Project Directory.

Once your Risk Management Strategy is complete check the document


against the following Quality Criteria:

 Responsibilities are clear and understood by both customer and supplier

 The risk management procedure is clearly documented and can be


understood by all parties
 Scales, expected value and proximity definitions are clear and unambiguous

 The chosen scales are appropriate for the level of control required

 Risk reporting requirements are fully defined


PROJECT DOCUMENTATION

RISK MANAGEMENT STRATEGY

Project:

Release:

Date:

PRINCE2

Author:

Owner:

Client:

Document Ref:

Version No:
1 Risk Management Strategy History

1.1 Document Location


This document is only valid on the day it was printed.
The source of the document will be found at this location – [insert folder structure]

1.2 Revision History


Date of this revision:
Date of next revision:

Revision Previous Summary of Changes Changes


date revision date marked
First issue

1.3 Approvals
This document requires the following approvals.
Signed approval forms should be filed appropriately in the project filing system.

Name Signature Title Date of Version


Issue

1.4 Distribution
This document has been distributed to:

Name Title Date of Issue Version


2 Table of Contents
Page

1 Risk Management Strategy History 1


1.1 Document Location 1
1.2 Revision History
1.3 Approvals
1.4 Distribution

2 Table of Contents

3 Introduction

4 Risk Management Procedure

5 Tools and Techniques

6 Records

7 Reporting

8 Timing of Risk Management Activities

9 Roles and Responsibilities

10 Scales

11 Proximity

12 Risk Categories

13 Risk Response Categories

14 Early Warning Indicators

15 Risk Tolerance

16 Risk Budget
3 Introduction
[Purpose, objectives, scope and responsibility of the strategy]

4 Risk Management Procedure


[A description of (or reference to) the risk management procedure to be used. Any
variance from corporate or programme management quality standards should be
highlighted, together with a justification for the variance. The procedure should cover
activities such as:

l Identify

l Plan

1. Assess

2. Implement

3. Communicate]

5 Tools and Techniques


[Any risk management systems or tools to be used, and any preference for
techniques which may be used for each step in the risk management procedure]

6 Records
[Definition of the composition and format of the Risk Register and any other risk
records to be used by the project]

7 Reporting
[Any risk management reports that are to produced, their purpose, timing and
recipients]

8 Timing of Risk Management Activities


[States when formal risk management activities are to be undertaken, for example at
End Stage Assessments]

9 Roles and Responsibilities


[Defines the roles and responsibilities for risk management activities]
10 Scales
[Defines the scales for estimating probability and impact for the project to ensure that
the scales for cost and time (for instance) are relevant to the cost and timeframe of
the project. These may be shown in the form of probability impact grids giving the
criteria for each level within the scale, e.g. for ‘very high’, ‘high’, ‘medium’, ‘low’ and
‘very low’]

11 Proximity
[Guidance on how proximity for risk events is to be assessed. Proximity reflects the
fact that risks will occur at particular times and the severity of their impact will vary
according to when they occur. Typical proximity categories will be: imminent, within
the stage, within the project, beyond the project]

12 Risk Categories
[Definition of the risk categories to be used (if at all). These may be derived from a
risk breakdown structure or prompt list. If no risks have been recorded against a
category, this may suggest that the risk identification has not been as thorough as it
should have been]

13 Risk Response Categories


[Definition of the risk response categories to be used which depends on whether the
risk is a perceived threat or an opportunity]

14 Early Warning Indicators


[Definition of any indicators to be used to track critical aspects of the project so that if
certain predefined levels are reached, corrective action will be triggered. They will be
selected for their relevancy to the project objectives]

15 Risk Tolerance
[Defining the threshold levels of risk exposure, which, when exceeded, require the
risk to be escalated to the next level of management. The risk tolerance should
define the risk expectations of corporate or programme management and the Project
Board]

16 Risk Budget
[Describing if a risk budget is to be established and if so how will it be used]
Appendix 3

HOW TO USE THIS TEMPLATE:

Introduction

The template reflects the steps set out in the PRINCE2 Method and is designed to
prompt the Project Manager and help in the creation of the Risk Register. There is
also a Product Description for the Risk Register at Appendix A of the PRINCE2
Manual.

Loading the file

This template has been produced using Microsoft Word 2003. To use it, load up the
file directly from the directory and starting from page 1 follow the prompts (in [...]
brackets).

Deleting the [....] text

When the template is complete, the Risk Register document can be printed and ap -
proved.

Prior to printing, you should delete all [....] prompt text.

Saving the Risk Register document under its own name

Save the Risk Register document by selecting the “SAVE-AS” command; this will
avoid overwriting the standard template. You must specify your own Project
Directory.

Once your Risk Register is complete check the document against the
following Quality Criteria:

 The status indicates whether action has been taken

 Risks are uniquely identified, including information about which product they
refer to

 Access to the Risk Register is controlled and it is kept in a safe place.


RISK REGISTER FORM [029]
Ref:
Programme Name: Project Name:

Risk Identifier: Risk Description:


[A unique reference for every risk [In terms of the cause, event (threat or opportunity) and effect (descr
entered into the Risk Register words of the impact)]
e.g. 0001]

Probability: Impact: Expected Value


[These should be recorded in [These should be recorded in [These should be recor
accordance with the project’s accordance with the project’s accordance with the pr
chosen scales] chosen scales] chosen scales]
Pre-Response Post-Response Pre-Response Post-Response Pre-Response Post-R
[Estimate the [Estimate the [Estimate the [Estimate the [Estimate the [Estim
inherent values residual values inherent values residual values inherent values residu
(pre-response (post-response (pre-response (post-response (pre-response (post-
action)] action)] action)] action)] action)] ac
Risk Response Category:
[How the project will treat the risk – in terms of the project’s chosen categories

e.g. - For threats: avoid, reduce, fallback, transfer, accept, share

- For opportunities: enhance, exploit, reject, share]


Risk Response:
[Actions to resolve the risk (should be aligned to the chosen response categories. Note that more than o
Date Registered: Risk Author: Risk Owner: Risk Actionee
[Date the risk was [Person who raised the risk] [Person responsible for [Person(s) who w
identified] managing the risk] implement the ac
described in the
response]
Appendix 4

HOW TO USE THIS TEMPLATE:

Introduction

The template reflects the steps set out in the PRINCE2 Method and is designed to
prompt the Project Manager and help in the creation of the Communication
Management Strategy. There is also a Product Description for the Communication
Management Strategy at Appendix A of the PRINCE2 Manual.

Loading the file

This template has been produced using Microsoft Word 2003. To use it, load up the
file directly from the directory and starting from page 1 follow the prompts (in [...]
brackets).

Deleting the [....] text

When the template is complete, the whole Communication Management Strategy


document can be printed and approved.

Prior to printing, you should delete all [....] prompt text.

Saving the Communication Management Strategy document under its own


name

Save the Communication Management Strategy document by selecting the “SAVE-


AS” command; this will avoid overwriting the standard template. You must specify
your own Project Directory.

Once your Communication Management Strategy is complete check the


document against the following Quality Criteria:

 All stakeholders have been identified and consulted for their communication
requirements

 There is agreement from all stakeholders about the content, frequency and
method of communication

 A common standard for communication has been considered


 The time, effort and resources required to carry out the identified
communications have been allowed for in Stage Plans

 The formality and frequency of communication is reasonable for the project’s


importance and complexity

 For projects that are part of a programme, the lines of communication, and the
reporting structure between the project and programme, have been made
clear in the Communication Management Strategy

 The Communication Management Strategy incorporates corporate


communications facilities where appropriate (e.g. using the marketing
communications department for distributing project bulletins)
PROJECT DOCUMENTATION

COMMUNICATION MANAGEMENT
STRATEGY

Project:

Release:

Date:

PRINCE2

Author:

Owner:

Client:

Document Ref:

Version No:
1 Communication Management Strategy History

1.1 Document Location


This document is only valid on the day it was printed.
The source of the document will be found at this location – [insert folder structure]

1.2 Revision History


Date of this revision:
Date of next revision:

Revision Previous Summary of Changes Changes


date revision date marked
First issue

1.3 Approvals
This document requires the following approvals.
Signed approval forms should be filed appropriately in the project filing system.

Name Signature Title Date of Version


Issue

1.4 Distribution
This document has been distributed to:

Name Title Date of Issue Version


2 Table of Contents
Page

1 Communication Management Strategy History 1


1.1 Document Location 1
1.2 Revision History
1.3 Approvals
1.4 Distribution

2 Table of Contents

3 Introduction

4 Communication Procedure

5 Tools and Techniques

6 Records

7 Reporting

8 Time of Communication Activities

9 Roles and Responsibilities

10 Stakeholder Analysis
3 Introduction
[The purpose, objectives, scope and responsibility of the strategy]

4 Communication Procedure
[A description of (or reference to) any communication methods to be used. Any
variance from corporate or programme management standards should be
highlighted, together with a justification for the variance]

5 Tools and Techniques


[Any communication tools to be used, and any preference for techniques that may
be used, for each step in the communication process]

6 Records
[What communication records will be required and where they will be stored (for
example, logging of external correspondence)]

7 Reporting
[Any reports on the communication process that are to be produced, their purpose,
timing and recipients (for example, performance indicators)]

8 Time of Communication Activities


[States when formal communication activities are to be undertaken (for example, at
the end of a stage) including performance audits of the communication methods]

9 Roles and Responsibilities


[Describes who will be responsible for what aspects of the communication process,
including any corporate or programme management roles involved with
communication]

10 Stakeholder Analysis
l [Identification of the interested party (who may include accounts staff,
user forum, internal audit, corporate or programme quality assurance,
competitors etc.)
l Current relationship

l Desired relationship

l Interfaces

l Key messages

l Information needs for each interested party:

o Information required to be provided from the project

o Information required to be provided to the project

o Information provider and recipient

o Frequency of communication

o Means of communication

o Format of the communication]

(appendix 5)

HOW TO USE THIS TEMPLATE:

Introduction

The template reflects the steps set out in the PRINCE2 Method and is designed to
prompt the Project Manager and help in the creation of Project, Stage and Team-
level Plans. There is also a Product Description for Plans at Appendix A of the
PRINCE2 Manual.

Loading the file

This template has been produced using Microsoft Word 2003. To use it, load up the
file directly from the directory and starting from page 1 follow the prompts (in [...]
brackets).

Deleting the [....] text

When the template is complete, the whole Plan can be printed and approved.
Prior to printing, you should delete all [....] prompt text.

Saving the Plan under its own name

Save the Plan by selecting the “SAVE-AS” command; this will avoid overwriting the
standard template. You must specify your own Project Directory.

Once your Plan is complete check the document against the following Quality
Criteria:

 The plan is achievable

 Estimates are based on consultation with the resources, who will undertake
the work, and/or historical data

 Team Managers agree that their part of the plan is achievable

 It is planned to an appropriate level of detail (not too much, not too little)

 The plan conforms to required corporate or programme standards

 The plan incorporates lessons from previous projects

 The plan incorporates any legal requirements

 The plan covers management and control activities (such as quality) as well as
the activities to create the products in scope

 The plan supports the Quality Management Strategy, Configuration


Management Strategy, Risk Management Strategy, Communication
Management Strategy and project approach

 The plan supports the management controls defined in the Project Initiation
Documentation
PROJECT DOCUMENTATION

PLAN

Project:

Release:

Date:

PRINCE2

Author:

Owner:

Client:

Document Ref:

Version No:
1 Plan History

1.1 Document Location


This document is only valid on the day it was printed.
The source of the document will be found at this location – [insert folder
structure]

1.2 Revision History


Date of this revision:
Date of next revision:

Revision Previous Summary of Changes Changes


date revision date marked
First issue

1.3 Approvals
This document requires the following approvals.
Signed approval forms should be filed appropriately in the project filing
system.

Name Signature Title Date of Version


Issue

1.4 Distribution
This document has been distributed to:

Name Title Date of Issue Version


2 Table of Contents
Page

1 Plan History 1
1.1 Document Location 1
1.2 Revision History
1.3 Approvals
1.4 Distribution

2 Table of Contents

3 Plan Description

4 Plan Prerequisites

5 External Dependencies

6 Planning Assumptions

7 Lessons Incorporated

8 Monitoring and Control

9 Budgets

10 Tolerances

11 Product Descriptions

12 Schedule
3 Plan Description
[A brief description of what the plan encompasses (i.e. project, stage, team,
exception) and the planning approach]

4 Plan Prerequisites
[Any fundamental aspects which must be in place, and remain in place, for
the plan to succeed]

5 External Dependencies
[Any external dependencies which may influence the plan]

6 Planning Assumptions
[Any assumptions upon which the plan is based]

7 Lessons Incorporated
[Details of relevant lessons from previous similar projects which have been
reviewed and accommodated within this plan] and include lessons log from
this project too in appendix 6

8 Monitoring and Control


[Details of how the plan will be monitored and controlled]

9 Budgets
[Covering time and cost, including provisions for risks and changes]

10 Tolerances
[Time, cost and scope tolerances for the level of plan (it may also include
more specific stage or team level risk tolerances)]
11 Product Descriptions
[Covering the products within scope of the plan (for the Project Plan this will
be the project product; for the Stage Plan this will be the stage products; and
for a Team Plan this will be a reference to the Work Package assigned).
Quality tolerances are defined in each Product Description]

12 Schedule
[Which may include graphical representations of:

l Gantt or bar chart

l Product breakdown structure

l Product flow diagram

l Activity network

l Table of resource requirements – by resource type (e.g. four


engineers, one test manager, one business analyst)

l Table of requested/assigned specific resources – by name (e.g.


Nikki, Jay)]

Appendix 6

HOW TO USE THIS TEMPLATE:

Introduction

The template reflects the steps set out in the PRINCE2 Method and is
designed to prompt the Project Manager and help in the creation of the
Lessons Log. There is also a Product Description for the Lessons Log at
Appendix A of the PRINCE2 Manual.

Loading the file

This template has been produced using Microsoft Word 2003. To use it, load
up the file directly from the directory and starting from page 1 follow the
prompts (in [...] brackets).

Deleting the [....] text


When the template is complete, the whole Lessons Log can be printed and
approved.

Prior to printing, you should delete all [....] prompt text.

Saving the Lessons Log document under its own name

Save the Lessons Log document by selecting the “SAVE-AS” command; this
will avoid overwriting the standard template. You must specify your own
Project Directory.

Once your Lessons Log is complete check the document against the
following Quality Criteria:

 The status indicates whether action has been taken

 Lessons are uniquely identified, including to which product they refer

 A process by which the Lessons Log is updated is defined

 Access to the Lessons Log is controlled

 The Lessons Log is kept in a safe place


PROJECT DOCUMENTATION

LESSONS LOG

Project:

Release:

Date:

PRINCE2

Author:

Owner:

Client:

Document Ref:

Version No:
Insert Project Name
Project Initiation Document
Date: 20 January 2022

Page 2
Insert Project Name
Project Initiation Document
Date: 20 January 2022

1 Lessons Log History

1.1 Document Location


This document is only valid on the day it was printed.
The source of the document will be found at this location – [insert folder structure]

1.2 Revision History


Date of this revision:
Date of next revision:

Revision Previous Summary of Changes Changes marked


date revision
date
First issue

1.3 Approvals
This document requires the following approvals.
Signed approval forms should be filed appropriately in the project filing system.

Name Signature Title Date of Version


Issue

1.4 Distribution
This document has been distributed to:

Name Title Date of Version


Issue

Page 3
Insert Project Name
Project Initiation Document
Date: 20 January 2022

2 Table of Contents

Page

1 Lessons Log History 1


1.1 Document Location 1
1.2 Revision History
1.3 Approvals
1.4 Distribution

2 Table of Contents

3 Lesson Type

4 Lesson Detail

5 Date Logged

6 Logged By

7 Priority

Page 4
Insert Project Name
Project Initiation Document
Date: 20 January 2022

3 Lesson Type
[The type of lesson being recorded:

 Project – to be applied to this project

 Corporate or programme – to be passed on to corporate or programme


management

 Both project and corporate or programme management]

4 Lesson Detail
[Details may include:

 Event

 Category

 Effect (e.g. positive/negative financial impact)

 Causes/trigger

 Whether there were any early warning indicators

 Recommendations

 Whether it was previously identified as a risk (threat or opportunity)]

5 Date Logged
[The date on which the lesson was originally logged]

6 Logged By
[The name of the person or team who raised the lesson]

7 Priority
[In terms of the project’s chosen categories]

Page 5

You might also like