Prince2 header
products page

PRINCE2 - Product-based planning part 3



Writing a Product Description

Product Descriptions should be written for:

  • The final product
  • Simple products (lowest level)
  • Integration products (intermediate products)
  • Collective groupings are optional

Product Descriptions should be written as soon as possible after they have been identified even if they exist in a draft form.
These will be updated and must be baselined when the relevant plan is also baselined. If the plan is updated the Product Descriptions should be reviewed in case they require updating.

Product Description contents

A Product Description template is given as file ‘product description.doc’ in the product package.

The key headings are:

Identifier

Unique key, probably allocated by the configuration management method

Title

Name by which the product is known

Purpose

This defines the purpose that the product will fulfil.
Is it a means to an end or and end in itself?
It is helpful in understanding the product’s functions, size, quality, complexity, robustness, etc.

Composition

This is a list of the parts of the product.
For example, if the product were a document, this would be a list of the expected chapters or sections.

Derivation

What are the source products from which this product is derived?

Examples are:

A design is derived from a specification
A product is bought in from a supplier
A statement of the expected benefits are obtained from the user
A product is obtained from another department or team

Format and presentation

Any standard appearance to which the product must conform.

Allocated to

The person, group or skill type needed to create this product.

Quality criteria

To what quality specification must the product be produced and what quality measurements will be applied by those inspecting the finished product?
This might be a simple reference to one or more common standards that are documented elsewhere or it might be a full explanation of some yardstick to be applied.

Quality method

What kind of quality checking – for example, test, inspection or review – is to be used to check the quality or functionality of the product?

Quality tolerance

Details of any range in the quality criteria within which the product would be acceptable.
This may be accompanied by a series of time periods during which the product quality is required to improve so that it remains within tolerance.

Quality check skills and / or people required

Either identification of the people who are to check the quality, an indication of the skills required to do so or a pointer to which area(s) should supply the checking resources.
Identification of the actual people may be left until planning the stage in which the quality check is to be done.

Responsibility

Responsibility for the Product Description will be with the Project or Team Manager but should involve the Customer or user for discussion of quality standards and others with expertise to get the document as accurate as possible.

Key criteria

  • Are products unambiguously defined?
  • Will all quality checks confirm that the quality criteria have been met?
  • Do standards exist that can be referenced when defining the quality criteria and are they applied?
  • When Customer and supplier standards exist is there an agreed compromise?
  • Does the Customer or user insist on any specific standards?
  • So you have the right people involved in the writing of the Product Description?
  • Do suitable checklists exist that will help the checking of products?

Both the ‘purpose’ and the ‘composition’ help to understand the product better which will aid in any estimates.

Product Descriptions require time to get them right, particularly their quality criteria.

‘Is the product complete or has it just stopped?’ you will need to consider this question when checking against quality criteria.

A Product Description is no substitute for a detailed requirements specification.

Ultimately, the Customer has to accept the product. This will be helped by their input into the agreed quality criteria.
The same applies for others who have an interest in the product.

You may wish to use the services of a quality expert, when setting the criteria, especially when known standards are involved.

Steps

These steps summarise the ‘hints and tips’ in ‘Managing successful projects with PRINCE2®, 2005 edition’ and in addition may cross refer to sections of the appropriate Product Description outlines.

  • Firstly the Product Description for the final product is written
  • Write a Product Description for each integration product and each simple product
  • Check the ‘composition’ and ‘derivation’ sections for any extra product requirements that should be in the Product Breakdown Structure
  • Review the ‘purpose’ section with the user / Customer to make sure there are no hidden extras that will mean additional products
  • Make sure all quality criteria are measurable and that if met will ‘guarantee’ the product satisfies each of its stated purposes.

Non - PRINCE2 information

Product Breakdown Structure

Often the Product Breakdown Structure is called the ‘Work Breakdown Structure’.
This represents a series of tasks identified in a schedule leading to the completion of the project.

Product Flow diagram

PRINCE2 refers to the Product Flow diagram which is often referred to as a project schedule when presented in Gantt chart form.
It forms the basis of project control as it contains not only the tasks needed for the project but also the timings. It may also include resource information.

This product contains EVERYTHING in the publications:

Managing Successful Projects with PRINCE2 - 2005 edition
Managing successful Projects with PRINCE2 – 2009 edition
Directing Projects with PRINCE2.
plus:
The Complete Project Management package.

And much more besides - at a fantastic price.