B Prince2 templates' list management
logo
A PM's workshop

Prince2 template list





Directing




Managing






Delivering









back to top

Template name

Vers.

Notes

Life span




Inc.

Def

Impl.

H/over

Acceptance Criteria

--

Included in the Product Description

X

X

X

-

Benefits Review Plan

1.0.0

It is the “governing” document for conceiving the product and quality.

-

X

X

-

Business Case

2.3.0

There are lots of posts about this topic.
2010-01-28: "Benefit Realization Management"

X

X

X

X

Checkpoint report

N.A.

It could be integrated within the Highlight Report

-

-

X

X

Communication Management Strategy

1.0.0

The rules for improving and checking the quality of communications

X

X

X

X

Communication plan

1.0.0

In essence a register for mapping stakeholders

X

X

X

X

Configuration item register

1.0.0

Some posts will be released. Mostly about integration of Product Breakdown Structure and WBS

-

X

X

X

Configuration management plan

--


-

X

X

X

Configuration Management Strategy

1.0.0

How to manage the ongoing versions of any project’s outcome.

X

X

-

-

Daily log

N.A.

“The palest ink is better than the best memory”. However, everyone has his/her own system to trace all the events that make the day.

X

X

X

X

End project report

1.0.0

Passing the product from implementation to handover.

-

-

X

X

End stage report

--

It could be incorporated into “End Project Report”

-

X

X

-

Exception report

1.0.0

Integrated with Risks, Issues and Impact

-

X

X

-

Highlight report

--

See post

-

X

X

X

Impact Analysis Register

1.0.0

It is useful for integrating the Change Management.

-

X

X

X

Impact Analysis Report

1.0.0

How to communicate the result of the Impact A.

-

X

X

X

Issue (log) Register

1.0.0

Where all issues are collected for further analysis

-

-

X

X

Issue Report

1.0.0

How to present the outcome of the “Issue Management

-

X

X

X

Lesson learned log

N.A.

It has been included in the Lesson Learned Report

X

X

X

X

Lesson learned report

1.0.0

A tool for delivering what has to be updated in the templates and policies

-

X

X

X

Off specification

N.A.

It has been included in the Issue Management Register

-

-

X

X

Project Brief

1.0.0

It is an introduction to the Business Case

X

X

-

-

Post project review plan

--

See “Lesson Learned”

-

-

-

X

Product Structure Breakdown

1.0.0

It based on the Architectural Document and includes "Product Checklist"

-

X

X

X

Product description

1.0.0

PBS

X

X

X

X

Project feasibility

N.A.

Included in the Project Brief

X

X

-

-

Project Brief

1.0.0

Some integrations with PMBook

X

X

X

-

Project plan

--

A tool for integrating Products, Activities and Resources.

-

X

X

-

Project quality plan

--


-

X

X

-

Quality Management Strategy

1.0.0

.

X

X

-

-

Quality log

1.0.0


-

-

X

X

Request for change

N.A.

See Issue Register

-

-

X

-

Risk Register

1.0.0

It is a very articulated tool for managing risks

-

X

X

-

Risk Management Strategy

1.0.0


X

X

-

-


back to top

Forewords

One of the biggest challenges offered by Prince2 is the tailoring the templates’ system to the project’s needs. This is the reason for framing all documents into the new edition’s logic. This means to consider all information made available from other sources (e.g. PMBook and Agile Alliance). My job, mainly as PMO, consists in guiding Project Managers to deliver successful projects. This can only be done through an honest and intense review of the best available ideas.

The mission’s site

Complex projects cannot be managed with standalone documents marooned in some forgotten shared directory with no versioning (configuration) system available. The whole site is dedicated to hone techniques and processes for increasing the chances of delivering successful projects. As “seasoned” professional, I found that the best way to test our acts passes through their publication. Peer review is the most powerful metric for gauging the meaningful of our deeds.

The production documents’ logic

Until now (November 12th 2009) there are available 15 templates. Mostly, to cover the Risk and Issue management, an area that is critical for any “non menial project” (when no jobs are at stake). I am moving toward the Product area (from Configuration Management to Quality); this policy is for leaving the most important coveted area: the roles and mandate. It is possible to describe a responsibility only when all the tasks and policies are clearly defined.

Respect the “spirit”

Insofar as my utmost concern is about the usability, all efforts are made to preserve the Prince2 (and PMBook) logics in order to grant a usability of the whole system. Thereby, the “vanilla” version is enriched by the following factors:
  1. Logical integration of each document that will easily form a CMS web based system.
  2. A special attention to Risk Management (MoR).
  3. Multi-tier integration focused on the PM Office viewpoint, especially when teams are working off-shore.
  4. Some integration from PMBook, Agile and any other consolidated best practice available on the web.
  5. Trying, wherever is possible, to reduce the number of documents for decreasing the workload. Insofar, some integration has been made possible, more in the next versions.
However, the choice and priority of documents are based on the IT professional needs. If you're looking for the “official” version, please check in with Project in a Box.

Wet paint! (working in progress)

There are some caveats:
  1. All documents are under revision. I have planned no more than three versions; this is the adopted logic:
    1. Draft based on the “vanilla version” and adapted to the IT needs. Less attention to graphical details and links. All efforts are spent on caring about the correct logic.
    2. Complete review based on confronting my colleagues and peer reviews.
    3. Final issue for checking all links and producing related mind maps.
  2. Any bit of knowledge is supplied with the only intent of being discussed for improvement. The configuration system will be maintained (a s a p) through SVN.
  3. Each document can only find its fully fledged logic with the ongoing comments contained in the blog. Contradictions are not only due to my lunacy, they are the living proofs that listening (and sometimes reading our scripts) is still the fundamental value for any person (especially ones with some responsibilities).
Project managers and clerical work
People are the most valuable asset. Spending energy in filling and crunching wordy reports in does not increase the control neither on production nor on the environment where the output will work and yield the stated benefits. Information about what people are doing is the stuff that, properly managed makes the project manager’s job. Thereby, dealing with people having the correct figures makes the difference between babbling empty promises (or menaces) and hard facts. After the list of the documents, and their statuses, there are some comments directed to improve their usability.
Choosing the templates
In the process of conceiving the system, I carefully decided to include only the templates that could increase the ability to communicate the current situation and the next trend. These are the adopted principles:
  1. Focusing on the product
  2. Modularization of each process (WBS concept)
  3. Privileging the people instead of complex procedures
  4. Enabling the management to take informed decisions in the most efficient way
Scope of the system
Each document is conceived starting from the statements dictated by Prince2 2009 edition. This offers more opportunities for increasing the consideration of the project as a part of a program. It is a big gain; splitting big projects into smaller ones that are managed as program improves the output. In this scenario, each PM can spend more energy in leading the team, leaving the bureaucratically aspects of the management to a dedicated central structure that is automatically fed through a well calibrated testing policy. However, this approach requires a more mature approach, where synergies are created and exploited. Every bit of energy spent on filling forms in (often with cut and paste from the previous report) is a waste that damages the project. It takes away resources from leading for privileging the dullest part of the management.
Focusing on the product
Project money comes from customers, who are entitled to receive timely what has been explicitly agreed. This means that every activity has to be clearly linked to the realization of the benefits; thereby each outcome has to be detailed (either using traditional activity or stories) with the aim of creating a meaningful line of action that will be checked against the strategy.
X-breakdown structure
Taxonomy is part of our nature. Our brain uses symmetry for classifying the surrounding reality. This process is based on the possibility of splitting the project’s scope into meaningful elements that are bound by the same (functional) logic. The huge mass of details created by this process can only be managed by a DB. It has to be fed with automatic procedures; thereby data are collected and stored for both reasons:
  1. Creating statistical analysis.
  2. Populating (using a simple mail-merge technique) reports.
People first
Producers (from developers to technical writers) are the project’s assets. Whatever is their role, communication is still the key value for their job. The data regarding the production (quantity and quality) should be collected automatically. This offers the following advantages:
  1. Less friction about the evaluation; in fact it will be done using accepted parameters creating a solid and common ground for negotiating the value.
  2. More reliability. Both parties (producers and management) can discuss on the whole history that remains neutral.
  3. Less filling forms in, more negotiation. PMs are less engaged with their chores and more available for speaking with the people who will use them.
Informed decisions
Any report should not exceed one page. The information has to be correctly framed into its scenario made by history and trend. This means using simple and powerful diagrams instead of a patchwork of worn phrases and insulated figures.
Document structure
Every document shares the same elements, as listed here below:

Title

Document’s name

Scope

Its reason for being

Quality

Essential parameters

RACI (who does what)

People and roles

Document structure

Specific elements

Registrar section

Where to put the details

Technical domains

References

Financial / Commercial domains

References



Versioning In this project, for communications’ reasons, the second digit indicates also the preparedness’ status. The schedule is not available yet; however, the figures give the set priority.
[i] Check this wonderful site for a security flaw.

back to top