I remember, many years ago, attending my first training course on Quality. Management could not get enough people to attend, so they bribed them with a free scientific calculator (back then worth about $ 200) – so I attended.
To be honest, I found it a whole lot more compelling than I expected.
After lunch on the second day, they had an expert talk about Configuration Management.
Well, she certainly knew her stuff – but I came away thinking that CM was a bit 'academic'.
How Wrong Can I Be? Configuration Management is BUSINESS CRITICAL!
I'm serious. Would you buy another auto from your dealer if they were not set up with the right tools to service your car?
How about if they fitted the wrong replacement parts? Or if the Manual had errors in it?
There's a famous story about the Space Shuttle incurring huge extra costs because European suppliers used the metric system and the USA used Imperial measurements. Tolerance errors built up and parts did not fit together properly.
Change Configuration Management would have stopped that from happening, and it would have helped to spot any such problems much earlier on.
Let's talk about change control within Prince2
Changes usually come in three categories:
Request For Change (RFC). This is usually a request from the customer or users asking for a change from what was originally requested.
It may be a change to the requirements, specification, acceptance criteria, or scope – or all or any re-work – or accept some form of price reduction.
The final category is a general one. reserved for any general issues, observations or concerns (for example, my design engineer has resigned!).
All the above may be seen as just different categories of an Issue.
So what is Configuration Management? Well it's basically an
internal service group with resources, tools, procedures and systems to control multiple versions of the products (deliverables) of projects.
Each product is termed an "Asset". The name for the combined set of these assets is called a configuration.
And the configuration of a projects end product is the sum of its parts.
So why should we care about using CM?
Changes to your project WILL happen – so prepare for it. I was talking about Change Management, which by the way, should be under the wings of CM.
So when changes occur, your project will end up with multiple versions of a product.
If you do not have appropriate tracking and knowledge of these versions, what was changed, and why it was changed, then your project is going to end up in turmoil.
Suppose you are a design engineer, and a colleague asked you for a copy of the specification document as they are about to design something from it.
What if you had changed the document in some way since it was agreed – maybe because you could see it was an improvement?
Your colleague now designs against this different spec to the spec that others are using – and his product does not work or fit with other designs of the same system. Chaos Reigns.
How about this. A client rings up and says they're using an old version of one of your products (because it's compatible with the rest of their system), and can you build some more for them as a special custom order please?
You say 'no problem' – you go to your design shop only to find that they've lost the drawings – worse, the designer retired last year.
You'd have the same problem if customers said it had a design fault, and could you fix it, or if a customer wanted a modification based on an old design.
And the same problems could exist if you run a 'service' corporation.
Are your staff using the right tools, procedures and guidelines?
Are they trained to provide that service?
Let me ask – does senior management have a set of business plans based on a set of strategic directions? And do different parts of the corporation base their operational plans on these documents?
Sheesh! I sure hope they are all using the correct versions of these things …
Okay, let's get back to your project, and how CM will help.
I hope I've convinced you that CM should be a permanent fixture in your organisation and not just set up by and during, a project (because the end products have got to be sustained during their whole life).
The person who provides the CM service is called the Configuration Librarian. Yeah, I know, it sounds kind of dated – but do not let that put you off. This role can also be called the Configuration Administrator.
Here's how they can help your project:
1. CM has a completed library of all items that have ever been produced in your organisation (including anything that has been 'bought-in' from a third party).
In modern times, these records will probably be held on a database of some sort. In the past they would have been held in hard copy form in a traditional filing system.
2. Each of these records will have information stating who has got what, where it is held, and why.
These records will also hold details of any changes made.
3. The library will also hold master copies of multiple baseline versions of products.
If you work for a small organisation and run small simple projects, then you would expect the way that CM is carried out to be small and simple too. As long as you have control of all versions of all of your products and services.
Next, I want to explain what services the CM Library can give to your project.
It is the project managers' responsibility to ensure that CM is being properly used by the project.
To help ensure this happens a CM Plan can be created.
Note. For a small and simple project, the plan may just be a list of points to discuss and agree with CM.
The Plan may form part of any quality planning or be included within the Project Plan.
Do what is sensible – but here are the areas that should be covered:
A short narrative explaining what configuration method to be used (or a simple reference to the 'usual' system.
What corporate standards will be used (or why they will be varied in some way).
Linkages to any other configuration management systems (or any tools) that will be used. An example may be a third party who is contributing products to the project.
How and where the products will be stored. Are they just documents?
Or are they other physical items – in which case will they be installed on the customer site, or stored elsewhere, such as a bonded storehouse.
How will filing be carried out, and what is the process
for secure retrieval?
What form of version control be used – explain how they
will be identified.
Who within the project and external to it will be
responsible for implementing configuration management?
The Configuration Librarian will provide the FIVE
following services to any given project:
1. Planning. Working with the project manager, to establish what level of detail is required (this is dependent upon the complexity of the total end-product configuration).
2. Identification. Agreeing what products will be under configuration control (for example, the Project Plan may not be included, as long as the project manager has a simple 'off-line' system for keeping it under their own version control).
3. Control. Procedures to 'freeze' baselines of products and bring them under control of the CM library.
Freezing means no changes are allowed to the product without the right level of authority (for example the project sponsor).
There is another point to be brought out here.
Take the development of a new mountain bike.
One person is designing the wheels, another is developing the frame, yet another, the gearing system.
As each goes through the many design versions the others need to make sure the entire configuration of the bike remains 'harmonized'.
The CM database will recognise such linkages and alert the team (via reports as described later in this article); of the relationships each product has to each other.
4. Status Accounting. This is the CM database for the recording and reporting of all products.
This goes back into history to the first version, and all the way up to the current version. This data can be given to the project manager at key points, such as an end stage review as accurate proof of the true status on all the projects products.
5. Verification. CM provides reviews and audits to ensure that the project team are using the correct versions of documents and other products during the project (and that they match the 'master' copies of such that are held in the library).
This should be seen as a service – not as 'the management police'!
Finally, there are two important reports that the project manager will use from the CM Librarian:
1. The Configuration Record. This is a record of all the information required about each product's status, and includes; the latest version number, who is creating the product, where the product is to be kept / stored, and what its status is.
2. Product Status Account. This is a report (usually requested by the project manager at key review points), and provides information about the state of all products within some defined time frame (for example "give me a report of all products and their status that have been created during the current project stage "
The PSA will, for each product within that time frame, contain data such as when each product was baseline and when any changes were approved.
Here is a short synopsis of key points within a Prince2 project when Configuration Management is used:
The Configuration Management Plan is created, prior to the
development of the Project Plan. The Project Manager to liaise with Configuration Librarian to discuss how the project will use / work with their Configuration Management (CM) System.
Setting Up Project Files
Takes information from the Project Plan, and adds project filing structure to the Configuration Management Plan. CM system may already have these facilities.
Authorising Work Package (WP) / giving work to the team
Update the Configuration Item Record to "under development" Configuration Librarian will do this.
Ensure the WP contains information regarding how version control will work for the developer, obtaining copies of products or product descriptions, submission the Configuration Librarian, and passing product status information.
Assessing Project Progress.
Capturing "actuals" and updating the status of products Configuration Item Record (CIR). Configuration Librarian can provide a Product Status Account (PSA) if needed.
Capturing and Examining Project Issues / Changes
Configuration Librarian could receive / document all Changes / Issues as well as maintain the Change / Issue Log.
Taking Corrective Action.
When any changes are to be made, the Configuration Librarian to make any products or their copies available, add new copies given out to the CIR, and update CIR for any status changes.
Receiving Completed Work Package (when the team have completed each product / deliverable)
Configuration Librarian to update the CIR to a status of 'completed'.
Product is now baselined if not already done.
As products / deliverables are completed Specialist Team to advise Configuration Librarian to update
CIR status of each product.
Completing a Work Package.
Configuration Librarian to handle the return of completed products (if appropriate), and to assist Project Assurance in confirming customer / user acceptance of products.
Regular Management Reports
Configuration Librarian with assistance of Project Assurance to confirm the CIR is same as actual status of products by carrying out a Configuration Audit.
Also check that version numbers are correct / updated.
Replanning as a result of change.
Configuration Librarian will provide a Product Status Account of products to be replaced / incomplete.
New CIR's created if needed.
Closing down a Project.
CIR checked for completeness, and used as an input to
Product Status Account – confirmation from customers configuration management records that all products are approved.
Refer to the Configuration Management Plan for how the products are to be handed over to those with support / operational responsibilities.
Carry out a Configuration Audit to check that all products are approved and complies with their CIR's.
During Project Planning.
The Configuration Item Record is created with reference to the Configuration Management Plan.
A simple numbering system for each product could be structured as: project name / type of product / product name / source / status / version number
So for example, if a project exists to create a new notebook PC, and a unique numbering system as above is used for the hard drive bought in from a 3rd party:
New Notebook Project / hardware / hard drive / external / in development / vA.2
Here is a detailed guide of the information needed in the
documents referred to in this article:
Configuration Management Plan.
– CM method to be used
– Links to other CM systems or tools
– Where and how products are to be stored
– Security arrangements for filing and retrieval
– Identification and numbering for
products / versions
– Who is responsible for CM
Configuration Item Record.
– Unique Project identifier
– The type of product (web, hardware, etc)
– Product Name
– The Latest version number
– A full Description of the product
– Life Cycle steps for product (ie.draft,
approved, in-service, etc)
– Who owns the product (User? Ops Manager? Etc)
– Who created the product?
– The date allocated to them
– The library or location where it is kept
– Product source (internal, external)
– Links to related products (physical, electrical,
– Status (where in the life-cycle is it?
– Copy-holders and potential users
– References to issues (if any) that caused change
to this product
– Any relevant correspondence
Product Status Account
– Project name
– Product type
– Product identifier
– Version number
– Product description – baseline date
– Product – baseline date
– List of related products
– Date copy of product was issued for a change
– Planned date for next baseline
– Planed date for next release
– Relevant notes (change pending / under review, etc)