In this video Paul Naybour, Business Development Director at Parallel Project Training, and hands-on project management professional, explains the importance of configuration management in certain types of project s and suggests a simple way to remember what the different steps and processes are to ensure configuration management is successfully implemented in a project.
A full transcription of the video is also given below.
[youtube]http://www.youtube.com/watch?v=GpJq0QzhmVI[/youtube]
One of the topics people struggle with in the APMP is configuration management and that’s because not many projects need the formal control that you get from configuration management; it’s about controlling the design and making sure that all parts of the design move together step by step. So it’s a technical process about controlling the drawings, bills of materials and the documents that constitute the design. So typical documents you would control would be the specifications: requirements specifications, functional specifications, and then all the drawings and the parts lists and the tests that go with those. It’s not just documents but everything technically associated with the project. The steps involved can be remembered by the mnemonic PICSA – not the same as the video company but almost.
P stands for planning – that’s setting up the configuration management system at the beginning of the project – it is usually a database or it can be a filing system – and how we are going to number the documents, what version control process we are going to use, what document templates we are going to use – all that sort of stuff.
I is Identifying all parts we are going to control in this formal way – that will include all drawings, all the design documents and specifications, but not maybe the risk register, and not maybe the budget, and not maybe emails and letters so it’s the formal things associated with the design.
C is the configuration control that is controlling the changes that happen to documents by issuing a change request or raising a change request before any design document is changed and these might lead to a commercial change but it may, for example, be changing the colour of a wall from green to purple. This is not going to cost any more but it makes it fit with our corporate colour scheme so they are technical changes. And you can imagine there are lots and lots of changes that might happen in projects.
S stands for status accounting and that means making sure we are keeping track of all the changes; the changes that haven’t been done and the latest drawings, and which have been updated and which have not been updated.
And finally we need to make sure that all this information is aligned and make sense and that’s what A is:
A is auditing and that is checking that the configuration documentation all fits together and that we haven’t got any open change requests that haven’t been processed properly .
So that is configuration management and the simplest way to remember the process is with the mnemonic PICSA – P I C S A.
If you have any question for Paul or would like to share your own experiences of configuration management (good or bad!) then why not leave a comment?
In the material I have read on Configuration Management I have not seen explicit reference made to the need for ongoing project alignment with ‘design intent’. I find this useful in conjunction with the injunction for configuration management to focus on the deliverables while change control is concerned with management of the project. There is overlap sometimes?
I understand too that configuration management attends the product through its lifecycle to termination while change management is project lifecycle specific ending with handover to operations and their own controls?