< PRINCE2 Templates by Management Plaza >
< Template: Project Product Description >
< Company Name >
[Project Name]
Project Product Description
Date:
Version:
PRINCE2 & Project Management Template
10/06/2012
0.000
[Project Name] Project Product Description
Document Control Information
Settings
Value
Document Title:
Project Product Description
Project Name:
[Project Name]
Document Author:
[Author name]
Executive:
[Executive]
Project Manager:
[Manager]
Revision Status:
0.000
Issue Date: (?)
10/06/2012
Document Approver(s):
Approver Name
[Name]
[Name]
Role
<Type in role in project>
<Type in role in project>
Document Reviewers:
Reviewer Name
[Name]
Role
<Type in role in project>
Summary of Changes:
Revision Date
[1]
Add date.
Add date.
Created by
[Name]
Short Description of Changes
[Initial Version of approved document]
Configuration Management: Document Location
The latest version of this controlled document is stored in [type in location].
Project Product Description - [Project Name]
Document Version 1.00 dated Error! Unknown document property name.
Page 2 / 7
[Project Name] Project Product Description
TABLE OF CONTENTS
1. INTRODUCTION ..................................................................................................................................... 4
2. PURPOSE OF THE PROJECT PRODUCT ........................................................................................ 4
3. COMPOSITION........................................................................................................................................ 4
4. DERIVATION (EXTERNAL PRODUCTS) ........................................................................................... 5
5. DEVELOPMENT SKILLS REQUIRED ................................................................................................ 5
6. CUSTOMERS QUALITY EXPECTATIONS ........................................................................................ 5
7. ACCEPTANCE CRITERIA (ACCEPTANCE CHECKLIST) ............................................................. 6
8. PROJECT-LEVEL QUALITY TOLERANCES .................................................................................... 6
9. ACCEPTANCE METHOD ...................................................................................................................... 6
Project Product Description - [Project Name]
Document Version 1.00 dated Error! Unknown document property name.
Page 3 / 7
[Project Name] Project Product Description
1. INTRODUCTION
States the purpose, objectives and scope, and identifies who is responsible for the strategy.
This text is generally the same for the vast majority of projects
Example text (you can use this):
The Project Product Description defines what the project must deliver in order to gain
acceptance, it provides a description of the main product that will be produced by the project.
This document is used in the following ways during the project:




Provides a clear description for all stakeholders of what the project must deliver.
Gain agreement from the user in the project’s scope and requirements
Define the customer’s quality expectations (describes what the product must deliver to
be used as intended)
Define the acceptance criteria (acceptance checklist), method and responsibilities for
the project
The Project Product Description is created during the SU process and becomes part of the
Project Brief. It is further refined during the IP process when creating the Project Plan which
includes the creation of the Product Descriptions (descriptions of the main components of the
project’s product).
The Project Product Description is basedlined (signed off) and is therefore subject to formal
change control (all changes have to be documented, assessed and approved). If changed
during the project, then this usually happens during the Managing a Stage Boundary process.
At the end of the project, in the Closing a Project process, it is used to confirm that the project
has delivered the required product and that the acceptance criteria (acceptance checklist)
defined in the SU process has been met.
Responsibilities:



The Project Manager is responsible for facilitating the activities to gather the necessary
information to create this document and controls any changes during the project.
The Project Board is responsible for approving any changes to this document.
Project Assurance checks that this document is in line with the corporate strategy and
advises the Project Manager.
2. PURPOSE OF THE PROJECT’S PRODUCT
Describe the purpose that the project’s product will fulfil and who will use it. The description can
also give an indication to the product’s functions, project size, quality, complexity and
robustness.
Example Text:
The purpose of this project’s product is to add much needed new functionality to the existing
inhouse document management system to improve the overall experience for all current users.
E.g. This project will provide the following functionalities.





Much simpler search interfaces and offering combined searches
Ability to save searches to MySearches so they can be used again by the user
A link to the 10 previous documents used by the user.
Provide a separate URL to each document making it easier to add links from email and
other applications.
…
3. COMPOSITION
Describe the major products to be delivered by the project. In other words, just list the major
components of the system. This is the same information that will come from the top level of the
Project Product Description - [Project Name]
Document Version 1.00 dated Error! Unknown document property name.
Page 4 / 7
[Project Name] Project Product Description
Product Breakdown Structure. It can also be a good idea to note external components that will
be delivered to the project (components that willl come from outside the project).
Example Text: This example text lists the main components that will be installed and developed,
as well as the training material that will be updated.







Search Library Module (External)
Document Management System Core Update (External)
Combined search
MySearches
MyRecent
URL link for each document
Training Material (update)
4. DERIVATION (EXTERNAL PRODUCTS)
State the products that already exist and will be used by the project to create the project’s
product but may not be delivered with it.
Question to ask to uncover derivation products: Which information/products will come from
outside the project?
Example text: Doc Management System
Example text: Office Move
 Existing Doc Management System
 User wish list
Example text: Annual Conference
 Floor plans (existing)
 Contractor information
 Existing networking information
 Lessons from previous move
Example text: Yearbook








Mailing list
Lessons from previous concerts
Agreed Date
Agreed City
Books from previous years
Lessons from previous years
Corporate image guidelines
List of potential advertisers
5. DEVELOPMENT SKILLS REQUIRED
State the skills (knowledge) required to develop the product. This can refer to specific skills from
a person or department (e.g. Legal Department).
Example text for the Document Management Project:






Business Analyst (elicit requirements)
Document Management System administration knowledge
.Net development
Testing
User interface design
Tech writing (training material)
6. CUSTOMER’S QUALITY EXPECTATIONS
Describe the quality expected of the project’s product and the standards and processes that
needs to be applied to achieve that quality. Prioritize the expectations where possible.
Example text for the Document Management Project
This Project Product Description uses a table to list the Customer’s Quality Expectations,
Priority (using MoSCoW), how to measure and the tolerances for each quality expectation.

The first Customer Quality Expectation is: Combined search must be easy to use. Easy
can be defined as 9 out of 10 persons say that this is easy to use.
Project Product Description - [Project Name]
Document Version 1.00 dated Error! Unknown document property name.
Page 5 / 7
[Project Name] Project Product Description



The priority is “M” which stands for “Must have”. This means that the project’s product
will not work as expected without this quality expectation. See the end of this document
for more information on the MoSCoW technique.
Measure defines how to measure that this quality exist: In this case a survey is used
(e.g. we ask 10 persons to use the combined search functionality and ask them to give
their feedback).
Tolerance: The quality test requires that 9 out of 10 persons should find it easy to use.
With -10% tolerance, it is also acceptable if 8 out of 10 people find this functionality
useful. So with a -10% tolerance, the acceptable range is 8,9 or 10 persons out of 10.
Customer Quality Expectations
Combined search – Easy to use: Self intuitive
Quality check: 9 of 10 persons have to find it easy to use
Combined Search results in < 2 seconds –
Quality check: Time 10 searches and work out average
MySearches – Easy to add searches to MySearch –
Quality check: 9 of 10 persons have to find it easy to use
MyRecent - self intuitive
Quality check: 9 of 10 persons have to find it easy to use
Training Document – easy to read
Quality check: 8 of 10 persons have to find it easy to understand
MoSCoW
Measure
Tolerance
M
Survey
+-10%
M
Inspection
+-20%
M
Survey
+-10%
M
Survey
+-10%
M
Survey
+-10%
7. ACCEPTANCE CRITERIA (ACCEPTANCE CHECKLIST)
Acceptance criteria are the prioritized list of criteria that the project’s product must meet before
the customer will accept it. It is easier to understand this if you think of Acceptance Criteria as a
checklist that will be used by the persons (the customer) who will accept the product to check
off that each quality criteria has been met.
Example Text:



The Acceptance Criteria information comes from the above Customer’s Quality
Expectations column. It is a short description of the quality.
The Priority is also taken from the Customer’s Quality Expectations information.
Yes / No: This is filled in the Closing a Project process at the end of the project.
Acceptance Criteria
Combined search – Easy to use: Self intuitive
Combined Search results in < 2 seconds –
MySearches – Easy to add searches to MySearch –
MyRecent - self intuitive
Training Document – easy to read
MoSCoW
M
M
M
M
M
Yes/No
8. PROJECT-LEVEL QUALITY TOLERANCES
Specify any tolerance that may apply for each of the acceptance criteria listed above.
Example text:

In this case, the tolerances for the Acceptance Criteria have already been included in
the Quality Expectations table in the Tolerances column (see above).
9. ACCEPTANCE METHOD
Describe who will be responsible for confirming acceptance.
Project Product Description - [Project Name]
Document Version 1.00 dated Error! Unknown document property name.
Page 6 / 7
[Project Name] Project Product Description
Example text:

The Senior User is responsible for accepting the project’s product.
You can remove the following information
Priority technique: MoSCoW
There are many ways to prioritize a change request and PRINCE2 introduces the
MoSCoW technique to help with this. MoSCoW stands for Must have, Should have,
Could have and Won’t have for now.
Must have:
The change is essential for the viability of the project and its
absence would affect the project objectives. (For example, the end
product may not work as required.)
Should have:
The change is important and its absence would weaken the
Business Case; the project would still meet its objectives, however.
Could have (nice to
have):
The change is useful but its absence does not weaken the
Business Case.
Won’t have for now:
The change is not essential or important, so it can wait.
However, it may be difficult to explain these four prioritize levels to a requester, and
most of the time they want to say that their request for change is very important. So
here are some simple questions to ask that should help you get the correct
information from the requester
 Must have:
Will the end product work if not resolved? (Yes)
 Should have:
Does it affect the Business Case (Yes), ask how
 Could have:
Does it affect the Business Case (No)
 Won’t have for now
Is change essential or important (Yes)
Project Product Description - [Project Name]
Document Version 1.00 dated Error! Unknown document property name.
Page 7 / 7