Product documents

The extent and detail of product documentation is very dependent upon the context of the work. Rather than prescribe separate documents, Praxis provides a list of fields from which suitable documents should be constructed according to the needs of the project or programme.

This may result in a simple approach with one document per product or a more extensive approach with separate documents for product descriptions, configuration items and quality records.

For convenience, the fields have been listed in three sections. Where these are expanded into separate documents, fields will often need to be duplicated across the separate documents.

Descriptive information

• Identifier

• A unique identifier that may be made up of components such as a project or programme code; product code; version number and so on.

• Title

• The name by which the product is known.

• Description

• A description of the product possibly including its purpose and how it fits into the overall output.

• Composition

• For a simple product, this section may be enough to describe the components and nature of the product. More complex products will need cross references to technical specifications.

• Owner

• If the product is a deliverable then the owner will be the stakeholder to whom the product is handed over. Otherwise it will be a member of the management team who is responsible for accepting the product before it is integrated into the output as a whole.

• Cross references

• Links to other documents that provide further information about the product, e.g. risk register, stakeholder map, lessons log etc.

 

Development information

• Developer
  The person, team, department or contractor that is responsible for the development of the product.

• Planned dates
  When the product is planned to be developed.

• Actual dates
  When the product was actually developed.

• Quality criteria
  These are the quality criteria that will be tested in quality control. This could be references to external quality standards, criteria unique to the product or a combination of both.

• Quality tolerances
  For each quality criterion the range of measurements within which the product would be acceptable should be listed.

• Quality control methods
  The control methods that should be used will be defined here. These could range from qualitative user reviews to mechanical inspection and statistical analysis.

• Quality control responsibilities
  The individuals or groups that are responsible for implementing the quality control methods.

• Test dates
  The planned and forecast dates for most testing or review activities are entirely dependent upon a delivery schedule that is being updated on a regular basis. To avoid duplication of effort, the planned and forecast dates may simply be covered by a cross-reference to the appropriate delivery plan. Such cross-references may be supplemented with information such as “product must be tested within one week of completion”.

• Test results
  The results of quality control could be a simple as a pass/fail or extensive test data. Either way, the consequence of the test results should be documented. If the quality is acceptable the product may be passed on for integration with other products or it may be handed over to the owner. If the quality is unacceptable the product may be reworked or discarded. In some circumstances it may be possible or necessary to accept a product that has not met it’s criteria but that is a decision that will have to be made by the sponsor.

• Cross references
  Typically these cross-references will be to delivery plans that show the context of the planned and actual dates.

 

Configuration information

• Current version
  An identifier indicating the most recent version of the product. The configuration management section of the scope management plan will define the system for incrementally labelling the versions of a product.

• Status
  A classification of the current status as defined in a configuration management plan, e.g. in development, under review, approved, handed over etc.

• Date of last change
  When the latest version of the product was released for test or handover.
  

• Previous versions
  When the date of the latest version is recorded, it does not replace previous dates. Each ‘current version’ identifier and ‘date of last change’ remain in the document to show the product’s development timeline.
  

• Location
  Where the item is situated or stored. This is applicable to a ‘soft product’ such as an electronic file or a physical component that can be moved around prior to installation. It is not relevant to products that are built in to the overall output, such as the foundations of a building or the keel of a ship.
  

• Current holder
  The current version of a product may be with the original producers or a test team. Where the product is a physical and uncopiable this is simply useful information.

  In the case of electronic files (documents or computer code for example) where a download or email attachment creates a copy, it is vital to understand who has the sole authority to work on the product. This is essential to ensure that there are not multiple people making simultaneous changes to a product.
  

• Relationships
  This section explains how the product works with other products. It is the key field when assessing a change request as it identifies how a change to this product may affect other products.

 

Typical documents

Many different types of document can be assembled from the menu of product information. The ones described below are chosen on the basis that they commonly occur in guides and methods for P3 management. This is not intended to be a definitive or prescriptive list.

• Product description
  This document is a mini-specification for a particular component of the project, programme or portfolio’s objectives. It enables people to understand the detailed nature, purpose, function, appearance and acceptance criteria of the product. It should contain sufficient information to identify: what activities will be needed to develop, test and approve the product; the resources needed to develop it; the costs of the product; where further information may be found.

• Product register
  This register summarises information from the product descriptions to provide an index of products and a quick overview of their status. Sometimes referred to as a product checklist.

• Quality register
  The quality register summarises quality control activities for all products and provides a central reference for a potentially very varied portfolio of quality control documentation.

• Configuration item
  This document provides a record of an item that has been placed under configuration management. It covers information such as history, current status, version and connections to other items.

• Status account

• The status account summarises information about the current state of a defined set of configuration items, e.g. ‘all products due for completion in the next month’ or ‘all products being developed by XYZ contractors Ltd.’ The scope of the status report should be described before listing the information shown in the table.

   

• Field	Product register	Product description	Quality register	Configuration item	Status account
  Identifier	X	X	X	X	X
  Title	X	X	X
  Description		X		X
  Composition		X
  Owner				X	X
  Description cross-references	X	X	X	X	X
  Developer				X	X
  Planned dates	X		X		X
  Actual dates	X		X		X
  Quality criteria		X
  Quality tolerances		X
  Quality control methods		X	X
  Quality responsibilities		X	X
  Test dates				X	X
  Test results				X	X
  Development cross-references	X	X	X	X	X
  Current version	X			X	X
  Status				X	X
  Date of last change				X	X
  Previous versions				X
  Location				X
  Current holder				X
  Relationships				X