Product Descriptions - do you need?

PRINCE2 has an excellent concept of Product Descriptions (PD) yet I, like many Project Managers, rarely produce them as part of Project execution. This may seem a contradiction but in most cases the objectives of the PD can be achieved by either other parts of your overall Project approach or in other ways that minimises the effort required. Where an alternative doesn't exist it is worth using the technique. Let me explain what I mean.

What is a Product Description (PD)?

Firstly a reminder what is a Product Description (PD)? A fundamental principle of PRINCE2 is Product Based Planning with a Product being a deliverable (either an intermediate one or the final one) and PRINCE2 says that for each Product you should produce a PD covering:

1. ID/Version - for configuration management
2. Title / Purpose
3. Composition - what are the "parts" which go to make up this Product
4. Derivation - what other Products which are needed to achieve this Product (e.g. from Project Product Flow Diagram or maybe an external dependency)
5. Format / Presentation - e.g. spreadsheet
6. Allocated to - person, group or skills required to produce
7. Quality criteria / tolerance / method / skills

Where else is the PD information?

In many projects most of your intermediate products are documents and using the 80/20 rule, I will focus here initially. Working through the 7 points above:

• Items #1 is only needed if you actually produce a PD!
• Items #2 and #7 are effectively covered in the Quality Plan I will produce. 
• Item #4 is often self evidence from a defined lifecycle or previous projects of a similar nature. For example, in IT System Development projects I often run, this would be a generic or organisation specific SDLC
• Item #6 needs to be identified during Planning
• Which leaves Items #3 and #5. In an ideal world the organisation has a Quality Management System containing document templates, best practice example documents, guidelines on approach to production and hopefully guidance of the quality processes (Item #7). Where this isn't the case, I will focus attention here to basically produce and agree a skeleton of the content of the document as early as possible - chapters, sections, diagrams needed etc. This both gives a better basis for detailed estimating and basically defines this key aspect of the PD which isn't defined elsewhere

So there you have it, there is no need to produce PDs in many cases but you still have all the good principles behind this PRINCE2 concept in place.

The ultimate Product for a Project is the end deliverable and PRINCE2 says this is an early PD to produce. Once again, the principle is excellent but I don't usually produce as I want all this information to be in the Project Definition so it is reviewed and approved by the Project Owner i.e. Sponsor or full Project Board.

Look out for the exceptions and produce PDs

Be on the lookout where a Product doesn't have PD defined elsewhere and plan to produce a PD document as early as possible in your Project life-cycle. It gains consensus on what the Product is, helps support detailed bottom up estimates / resourcing and how to ensure the Product is of suitable quality.