Product Descriptions should be written for:
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.
A Product Description template is given as file ‘product description.doc’ in the product package.
The key headings are:
IdentifierUnique key, probably allocated by the configuration management method
TitleName by which the product is known
PurposeThis 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.
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.
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
Any standard appearance to which the product must conform.
Allocated toThe person, group or skill type needed to create this product.
Quality criteriaTo 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.
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 toleranceDetails 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.
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 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.
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.
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.