Written by Claudine – Wed 10 Oct 2012
Once you have gained your PRINCE2 Practitioner qualification, or attended Intro to Project Management training and started working on projects, you should be considering the different ways to keep projects running smoothly. One of these is configuration management.
The term configuration management conjures up all sorts of questions for project managers, firstly;
Whether we realise it or not, configuration management exists all around us. For example, the make and model of your car or phone, the version of software you use at home or at work and the documents you use in your daily lives could be version controlled.
Essentially what configuration management covers is how we identify things that need to be version controlled, track these items by keeping records, using naming or labelling the latest versions and control the items by getting approval and ensuring that master copies are kept safe.
In a project environment, you will at the very least be generating a large amount of paperwork that as a minimum you will need to manage by configuration management.
Have you ever experienced that situation in a meeting when glancing across at a colleague's collection of paperwork, you notice that they have a later or earlier version of the documentation you have?
If configuration were being managed in your project environment, this situation should not happen.
Ideally, you would at least manage your important documentation by ensuring that approved versions are baselined (approved) and then if changes are required, a new version number is generated. This provides a useful history to review where changes were made or for comparison at the end of the project to compare to the original objectives.
In addition, some projects may also create products or deliverables that would benefit from being managed through configuration. Consider the following questions:
These questions lead me onto the next big question which is:
For configuration management to be effective you first of all need to understand how you will approach it.
Usually this means looking to your corporate environment to see if you already apply configuration management at corporate level. If you do, then you need to see what system is being used and if it is appropriate for your project environment.
If you do not have a corporate approach, think of the questions raised in the previous section.
If you are able to answer these questions, you can put together a strategy that defines how configuration will be approached for your project.
Once you have done this, you will need to also think about the information you may find useful to have about each item that is being managed by configuration. For example:
This information can easily be held in a spreadsheet and furthermore can be easily filtered when you want to know for example what the status of your products are, or who has copies of the product or what is the latest version number.
So in summary, consider how this may make your life a lot easier. You will always have up to date information about your documentation and deliverables and hopefully avoid confusion about what is up to date and what is not.