Prince2 header
products page

PRINCE2 - Configuration management part 1

Purpose

The products from project management are key assets of an organisation.
These need to be managed just the same as many other assets.
The combined set of these product assets is a ‘configuration’.
The configuration of the outcome of a project is the sum of its products.

Its aim is to identify, track and protect the projects products.

The amount and formality of configuration management will depend on the size, type and environment of the project.
This must be addressed at the outset of the project.
All products reaching a minimum of completed draft stage should be included.

It is important, once all products have been identified, to decide which ones will come under the umbrella of configuration management.
Clearly, items such as Project Plans and the Business Case, where updated versions will exist must have a means of control.

It is probably a good idea to ask the question, ‘Could confusion occur from the update of a document if we fail to give it anew version number?’
If the answer is ‘Yes’, which would be the case from the examples, they must be controlled.

If later you find certain products are causing problems and would be best controlled then do so.

Definition

It can be thought of as an asset of product control.
It provides precise control over the organisation’s products.

This system allows for the management of the products in the following ways.

Version control

Each product can be tracked by a version numbering system, whether archived or in use.

Information

The status of each product will be known and tracked, for example, is it archived, in use ready for quality checking etc.
The person having ownership of the product.
The person authoring the product.

Records

The system will maintain a record of the information which is easily searchable and retrievable.

Change control

Makes sure that all changes are properly authorised.

Auditing

Regular auditing ensures that the system controls only the desired products and to the correct standard.

The benefit of such systems is evident in many production industries. The car manufacturing industry requires the integration of many components. All parts can be tracked with part numbers that ensure only the correct parts are fitted.

This type of example demonstrates the importance of configuration management not only during the design, construction and testing but during the lifespan of the product.

A good configuration management system will provide a minimum in terms of the scope of operation.

  • It must be able to track and control all the project’s products. Once products have been quality controlled they should be filed and archived with controlled access and records of their status.
  • There must be safe and secure storage. This will also involve controlled access.
  • A system for filing, logging and tracking all Project Issues.

The presence of configuration management has benefits to the product.

  • Management of change and product up grades is cheaper and less prone to errors
  • It helps in the identification of products that may be affected by problems in related products
  • Access to historical data on the products which may be able to identify the source of the problem

Baseline

This is seen most typically when a project plan is agreed by the Project Manager and the Project Board.
It is the first plan, usually, and the one from which you expect to meet particular levels of quality and scheduling.
As such it becomes the guide as to where you are (current plan) and where you should be (the baseline plan).

Any future modifications of this plan would have to be agreed by the Project Board and a revision number given.

In general, once a product is given a quality ‘pass’ status following review it would be sent to the configuration library where it becomes the ‘baseline’ or ‘standard’ for use in other areas of project management as necessary.

Baseline documents can be updated at intervals. The ‘original’ baseline is kept and a copy of the revised item is circulated and given a new version number. The originals are always kept archived. Eventually, the new version passes quality control as being acceptable and it in turn will become a new ‘baseline’. All of the old baselines are still kept. All of this process is recorded by the configuration management system. Original documents are never circulated and must remain archived so that copies are available in the future.

Release

A product release must be accompanied by any associated documentation.
All documentation must have a baseline version and any updated documentation a revision version number.
This might apply to an item of equipment that has associated documentation for maintenance and training manuals.
It must be clear which versions of documents are associated with the released product.

Product release will occur at significant milestones in the project as well as at the project end and the management of the handover.
Documents must be released prior to the beginning of a new stage for example. Materials must be released prior to their use.
A specification must be released prior to design activity. This could be considered as a ‘bill of quantities’ as it contains all of the products that constitute the design stage.

Managing the configuration

There are 5 basic functions:

Planning

All projects are of differing sizes. It is important to agree on the level of configuration management and how this will be achieved.

Identification

All components of the final product must be identified.

Control

This establishes agreed baseline products which then cannot be changed other than by new versions through appropriate channels of authorisation.

Status accounting

All product data must be recorded and reported in a controlled manner.

Verification

A series of reviews and audits to make sure that the records are accurate and a true reflection of the current status of products.

The person that operates the configuration management system is called the Configuration Librarian. The role provides precise control over all of the projects assets.
A typical role description for a Configuration Librarian appears in the file ‘Configuration librarian.doc’ as part of the product package.

As usual if the project is part of a programme it is usually better to adopt or create a system at programme level.

Configuration Management Plan

It is part of the Project Quality Plan.

It defines:

  • How and where products will be stored
  • The security of the filing and retrieval system
  • The method of identification of the various versions
  • Where the responsibilities lie

A full description is given in the Product Description file ‘Configuration management plan.doc’ which is in the product package.

Configuration identification

For maintenance of control each product (and new version) must have a unique identifier.

This should include as a minimum:

  • The name of the project for which it is being created
  • Product type, for example, document, software, hardware, equipment, intermediate etc
  • Product title
  • Latest version number

There may be a need to refine the level of the number or coding system to take into account slightly more complex situations.
Typical information that needs to be held can be found in file ‘Configuration item record.doc’ as part of the product package.

Purchase the full product

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.