Configuration Management is necessary

Not always complicated.

Many of the topics in PRINCE2 are familiar with people who show up to class, in varying degrees. However, without exception the discussions around configuration management usually start off with confused looks from class participants.

• Windows x vs Windows x
• Director’s cut of a movie vs General Release Version
• English vs French version of a book
• Microsoft Office Student vs Microsoft Office Professional
• 2020 vs 2018 edition of your car

All of these are examples of configuration management alive and well. It is not just for software or electronic copies of things. It is for anything that needs to have changes to it managed and tracked.

There are two main topics within the change theme of PRINCE2.  The first is issue and change control, which many people are familiar with. The second is configuration management which often causes confusion.  These two topics are tightly tied together to do one without the other is just asking for trouble. The frameworks for both are established for a project in the Configuration Management Strategy.

PRINCE2 defines configuration management as follows (Section 9.2.2):

• Configuration management is the technical and administrative activity concerned with the creation, maintenance and controlled change of configuration throughout the life of a product (or item). 

I grossly over simplify this by indicating that configuration management is about version control.

PRINCE2 continues by defining what exactly is subject to configuration management / version control:

• A configuration item is an entity that is subject to configuration management. The entity may be a component of a product, a product or a set of products that create a release.

This statement applies to both specialist and management products.

Situation 1: You are at a meeting to review the contents of a certain document. There are several different versions of this document held by the various participants.

Situation 2: A scope or quality change request is estimated to be a minimum amount of work. Once work starts, it is discovered that you cannot make this change without making a change to several related items. This extra work was not included in the original estimate.

Situation 3: A person asked to make a change to a product gets a copy of the current product description and it is inconsistent with the existing product.

All of these situations are issues relating to configuration management.

The most difficult part of configuration management is deciding, what are the items that will be subject to configuration management. Prince 2 describes the first of the 5 core activities in configuration management as:

• Deciding what level of configuration management will be required by the project and planning how this level is to be achieved.

At a minimum this should include:

• All management products that are approved and baselines are created.
• Completed and approved specialist products.

For document type management products or paper based specialist products:

1. Configuration management can consist of a simple table inserted at the front or back of the document indicating the change history. This table should cross reference to the relevant issues/change requests that have led to the changes. For Example:
   
2. Establishing a place where all final or approved source documents is stored is crucial. This can be by way of a shared network drive, dropbox, sharepoint or other storage place. Write protection on an approved document is crucial to prevent accidental changes being made.
3. It is also common for the document/file name to include the current version number and possibly a date. This can also minimize confusion over which is the current version.
   In any project, it is critical for all stakeholders to understand that things will change after they have been approved. Changes occur for many reasons including:
   • A detail was forgotten
   • A detail was misstated
   • Someone just changed their minds.

How these changes are captured, examined, and decided upon is a crucial part of configuration management. It is this flow of change requests and the reasons for these changes that lead to new versions being created. The relationship between products / configuration items is integral to understanding the full impact of the change request on the project.

For example: a stakeholder might request that a certain field on a web page that is used by customers to purchase items needs to be longer in length. On the surface this might sound like a simple task for 1 web page. Upon further analysis, it is discovered that this same piece of information is on many other web pages and is downloaded into our corporate financial system and is used on many reports generated. This means that the original request has turned into something much more complex than originally thought and much more effort will be required to complete the full change. Without adequate configuration management, the original change would be approved and the full impact would not have been known until a much later point in time.

Configuration management on a project is necessary and can be as simple as:

• Establishing formal change control
• Understanding the relationships between products/items
• Tracking changes so that the most recent version of anything is clearly known.