The Product Description

The PRINCE2 Product Description.

If the product based planning technique is the crown of PRINCE2, then product descriptions are the jewel in the crown.

Whether creating the project, stage, exception or the optional team plans, the Product-based planning technique will be used and hence at least one product description will be created.

These should not be confused with the project product description, which is a description of the end product of the project along with the customers quality expectations, acceptance criteria plus method and resources.  There is obviously one of these per project.

A product description should be created directly by needed for the product has been identified, and this is why product descriptions are created for the first time after the creation of the product breakdown structure within the Product-based planning technique.

A project plan may describe Top-level Products and hence their descriptions, these Top-level Products may be split into a lower level products when planning the relevant stage able hence have new product descriptions created for them act stage plan in time.

When initially producing a plan, not all of the information required within the product description may be known at that time, and therefore some of the details within a product description may be progressively elaborated.  However, once a plan is approved vendor the product descriptions contained within it are baselined along with the plan and hence under change control.

The senior user and involvement of representatives from the user areas should be consulted when creating a product description even though it is the project manager or team manager who is responsible officially for writing the product descriptions.

Reference to the quality management strategy and configuration management strategy documents may be helpful here in the drafting of product descriptions.

Whenever a product description is created or updated then there configuration item records and quality register should also be updated as required.

The product description is passed to the specialist team within the work package and used as a basis upon which the design and development of the product itself can begin.  The quality criteria contained within the product description clarifies and defines when the product is fully complete.

The value of a product description is that it removes the ambiguity between the product creators stating that they have finished the work, verses that the product is 100% complete and acceptable to the customer and users.

The product description document.

Each product description should contain the following information:

Identifier.  Configuration management will normally allocate a unique Alpha numeric key encompassing the project and item name along with its version number.

Title.  This is the name given to the product itself and should be in the form of a noun or outcome so that the product is not confused as describing an activity.

Purpose.

By understanding the purpose that the product will fulfil, this will help in defining other attributes such as functionality, size, quality criteria, service ability, etc.  Referring to the product breakdown structure, it may be evident that this particular product is an end in itself or simply a means to an end – and they should be clarified here.  For example if this product description describes the creation of a set of test criteria upon which another product is to be tested, then this product is nearly a means to an end rather than an end itself.

Composition.

This is a list of the products or parts that make up this particular product.  This may also consist of ancillary products or parts that are needed; for example the parts list if the product itself is in the form of a ‘do it yourself’ kit.  If the products were a document this may merely describe the sections or chapters within the document.

Derivation.

This describes the predecessor products that are needed from which this particular product is derived.  Referring to the product flow diagram may give clues here.  However, its derivation may be external to this particular project.  Some examples are that if a product is provided by a supplier (this of course is where it is derived from), another example is a specification document from which this product will be designed and built.

Derivation may also be data gathered that points to the need for this particular product such as a set of features or expected benefits.

Format and presentation.

There are two aspects here, format, which offer an points to the size or category such as ‘A4’ or ‘Letter’ if the product were to be a document, and presentation often refers to the form in which the product is to be presented – such as a CD or memory stick if the product were software code, or a spreadsheet or database in the case of data.  Format and presentation therefore may simply point the reader toward a standardised form such as a container or protocol.

Development skills required.

This may detailed the number of people with knowledge skills and experience needed to create all develop the product, or it may point to a department, group or organisation that is responsible for providing them.  If this product description were being created as part of the project plan, then this information may not be known until planning the relevant stage within which this product will be created.

Quality criteria.

This is the key part of a product description.  If this is wrong, incomplete or ambiguous, then although the product that is derived from this product description may be correct, it will fail in some way to satisfy its operational use.  Therefore, careful thought is required when defining a product’s quality criteria.

In some cases, the quality criteria need only make a reference to standards that are documented elsewhere.  If not, then the quality measurements that must be applied need a full explanation here.

This section must lay out the quality specification and measurements that the product must meet, so that when those who are responsible for carrying out the quality method are clear about the criteria that this product must meet.

In some cases they products may have more than one ‘state’.  For example, if the product will exist as a manufactured pre-delivery state and as an installed state, then either separate product descriptions will be required for each, or the quality criteria for each state must be documented here.

Quality tolerance.

There are very few absolutes in life, and that goes for the operational readiness of products too.  Therefore, be above quality criteria will normally have plus or minus ranges, within which, the product is being acceptable and to meeting the required quality criteria.

An exception to this would be when the quality criteria simply refers the reader to a standard that must be met, in which case the product either reaches that standard or it does not.

Quality method.

This describes the way that the quality criteria will be checked, and there are obviously an infinite variety of methods that may be used.  The method should be chosen as the best way to conclude that the quality criteria have indeed been met.  It would be a disaster if, having correctly identified the criteria, that it is measured using an inaccurate method.

Examples of the type of method that may be considered are; carrying out tests, walkthroughs, fall quality reviews, verification testing, user acceptance testing, customer trials, questionnaires, physical inspections, or even the customer using the product in the form of a pilot.

Quality skills required. 

In a similar way to the development skills, this should describe the knowledge, skills and experience of those required to carry out the quality method against a quality criteria.  It may be sufficient to merely reference the group, department or organisation that is supplying the skills.  Identification of the precise people needed may be left until planning the relevant stage within which this product is to be created.

Quality responsibilities.

This lays out the quality responsibilities of the producer or creator of the product, the reviewer all reviewers, and those who will approve the product after its successful quality check.

An example of a product description.

For more help in passing your PRINCE2 Foundation and Practitioner exams CLICK HERE