FREE PRINCE 2 Product Description Template

Posted by Kevin Brady on Sat 5th August 2006 at 10:25 PM, Filed in Document Templates & ToolsProject ManagementKey Document Templates

Click this to download a FREE PRINCE 2 Product Description Template. This template is an example Product Description for a Project Initiation Document (PID).

The question I often get asked by IT Professionals some of whom are surprisingly PRINCE 2 accredited, is:-

image

What is a PRINCE 2 Product Description?To answer this question we need firstly to define what PRINCE 2 means by the term “Product”:-

Typically, a product is a self-contained project deliverable, which is either a document or a system (hardware/software)or component thereof.

The product description is, therefore, a description of a product intended to be produced and developed or obtained – even before it is planned – to ensure that the people involved in its production know:

• Why it is needed

• What it will look like

• From what sources it will be derived

• The Quality specification to which it must be built.

The Product Description is a control document. It is written as part of the planning process. It defines the deliverable, the standards to be used in its creation, and the quality criteria to be applied to ensure it is fit for purpose. Not only is this information essential for the Author, but the Product Description also forms the initial checklist for checking the quality of the finished product.

Extract from Managing Successful Projects with PRINCE 2 (CCTA)

To answer this question we need firstly to define what PRINCE 2 means by the term “Product”:-
Typically, a product is a self-contained project deliverable, which is either a document or a system (hardware /software)or component thereof.
The product description is, therefore, a description of a product intended to be produced and developed or obtained – even before it is planned – to ensure that the people involved in its production know:

• Why it is needed

• What it will look like

• From what sources it will be derived

• The Quality specification to which it must be built.

The Product Description is a control document. It is written as part of the planning process. It defines the deliverable, the standards to be used in its creation, and the quality criteria to be applied to ensure it is fit for purpose. Not only is this information essential for the Author, but the Product Description also forms the initial checklist for checking the quality of the finished product.
Extract from Managing Successful Projects with PRINCE 2 (CCTA)

Over the past few years, I have expanded and modified the use of Product Descriptions in order to meet new challenges and to improve the odds of project /programme success :-

Key revisions (featured, where possible, in the attached template)

• I use product descriptions only to support the production of document related products. The reasoning behind this, is that document products mostly describe the system under construction, so further summary descriptions can be an unnecessary overhead.

• I always insist that Authors of Product Descriptions are product owners. Ownership means the author is responsible for the timely production of the final product in accordance with agreed quality criteria detailed in the description. Such ownership ensures that the author approaches the products production with an appropriate level of due care and attention born out of the author’s direct responsibility for its delivery. I always stress that product delivery performance will be a key aspect of any annual salary review in order to give meaning and focus to the teams delivery endeavours.

• My Product Descriptions documents detail the Quality Method, which is to be used to produce the description and the final product. I tend to expand this section of the description to include details of the review /rework /sign-off task breakdown for the products production. This usually includes specific iteration limits /constraints on the review /rework /sign-off cycles necessary to deliver the product or its description. This can be further explained by the following example Quality Method extract from attached template:-
“Both the description and the final product will be checked and agreed within a maximum of 3 quality review meetings. Each meeting will consist of a minimum of 3 people:-

• Chair Person,

• Author (Product Owner)

• Peer to the Author - Someone with the same role and job title but who is not attached to the author’s assigned project and has no involvement in the production of the final product or description under review.

Each meetings purpose is to identify the errors in the Description /Final Product, which prevent the quality reviewers from signing off these deliverables as ready for passing onto the sponsor /senior user for final approval /sign-off.

The product description, once agreed among the quality reviewers as being fit for purpose in accordance with the Quality Criteria, will be required to sign-off the description. Once signed off it is understood by the quality reviewers that such a document will be used as a quality control checklist for future quality reviews of the final product.

Final Product Quality reviews will be completed in a maximum of 3 meetings /cycles, with product rework times and the date of any future reviews set by reviewers attending each review meeting.

If rework /review cycles exceed 3 iterations then this must be recorded as an issue on the project issue log and is a matter for the Project Manager or the Project Board to authorise more time and budget towards the completion of the outstanding product.”

• I then use the expanded product description to help drive out from the Author / Owner all the necessary lower level task durations /effort estimates necessary to deliver the product. Without a product description as a task breakdown checklist, estimates given by product owners tend to be woefully inaccurate and are a major reason, in my view, behind many project stage slippages.

If you ask an IT professional for a “5 minute estimate you’ll get a 5 minute estimate”  which usually means it will miss 50% of the tasks required and invariably require 100% more time and cost to get the Product Delivered. Remember, most IT Professionals want to appear optimistic, so reality based delivery estimates tend to come a poor second to impressing the Project Manager or the Client. Product Descriptions are an excellent way of getting down to the “brass tacks” of what needs to be done to make a product delivery a reality.

*This process is the essence of bottom-up, team based project planning*

• Such bottom-up product planning meetings help drive out undetected issues /risks and assumptions preventing the Product Owner and associated production team from giving hard time /cost delivery estimates. I normally expect Project Managers to act more as facilitators in such meetings. Each product delivery should be run as a series of mini projects where the owner and his /her supporting resource are made totally responsible for the Products delivery failure or success. If the team feel that, their product delivery is under threat by a specific risk or issue, it is their duty at weekly team meetings to log these issues /risks and where necessary try to resolve them themselves or escalate them to the Project Manager.

In summary, the benefits from using Product Descriptions are significant:-

• Better quality control of products

• Helps generate between Projects more consistent project documentation of a common standard.

• Generate “best of breed” project documentation leading to better quality system delivery and easier system maintainability once delivered.

• Assists in keeping the IT project in line with customer expectations.

• Generates more accurate time /cost stage estimates

• Can reduce likelihood of stage slippages

• Help develop delegated delivery ownership by the Project Team.

• Can assist in developing increased project team commitment through being an integral part of the bottom-up planning process.

Despite all these benefits from the using Product Descriptions I have seen some truly horrifying interpretations of what Product Descriptions are and how they can be used.

Everything from simple “Post it” labels, describing what a document deliverable should be (in the same way I have labels on jars in my kitchen) too long drawn out documents written by the Project Manager and served up to the professional IT staff with the instructions “build this!” The later form of Product Description is invariably of such agricultural quality that they tend to serve no other purpose other than getting the backs up of the professional IT staff and galvanising opinion against the Project Manager. In short, you end up looking a complete FOOL.

Product Descriptions don’t have to be trying! If used correctly, Product Descriptions can significantly improve your chances of delivering a successful project /programme of work.

Download the template and try it out today !

This entry has been viewed 48247 times.

READER COMMENTS:

I would like to try PRINCE 2 Product Description Template

Posted by Naresh  on Fri 29th December 2006 at 10:16 AM | #

I shall be trying the template. The benefits are measurable and will solve some internal issues. Thanks

Posted by A Prescott  on Thu 18th January 2007 at 10:55 AM | #

The Product Description Form is a valuable tool and I will be using it with my current portfolio of projects.

Posted by T Topper  on Mon 28th April 2008 at 02:07 PM | #

Re:  your comment of • I use product descriptions only to support the production of document related products. The reasoning behind this, is that document products mostly describe the system under construction, so further summary descriptions can be an unnecessary overhead. - I am new to managing projects via Prince2 and our organization is definitley challenged by the paperwork around products.  In your recent experience, have you ran across any great ways to manage the volume of product descriptions?

Posted by Sheila  on Mon 12th May 2008 at 10:29 PM | #

Is the template still available?  Would like to try using it.

Posted by D. Brosious  on Thu 2nd October 2008 at 08:45 PM | #

yeap it is ! Just click on link above and download. I have emailed you a copy just in case you have issues with your browser set-up.

Posted by Kevin Brady  on Sun 5th October 2008 at 08:34 PM | #

Many thanks, this will be of immeasurable help in an assignment I am doing regrding project management techniques.

Posted by L Farrall  on Wed 11th March 2009 at 02:16 PM | #

Good day.

Can you please provide an illustration or example of PRINCE2

Regards

Posted by Theo  on Mon 10th August 2009 at 02:36 PM | #

POST A COMMENT:

Please feel free to submit relevant comments to this entry but note: inappropriate or purely promotional comments may be removed as will be personal abuse and defamatory remarks. Reasoned debate and substantiated critique on the topic in hand is encouraged and welcomed. Email addresses are never displayed, but they are required to confirm your comments.

Name:

Email address is required but will not appear publicly:

Add your comments below:

Remember my personal information for next time

Submit the word you see below:

18 + 2 =