Some definitions
Here are some definitions I have dug out from the web. Comprehensive no doubt but not great for readability so just scan and move on!- PMBOK - a collection of formal documented procedures used to apply technical and administrative direction and surveillance to: identify and document the functional and physical characteristics of a product, result, service, or component; control any changes to such characteristics; record and report each change and its implementation status; and support audit of the products, results, or components to verify conformance to requirements. It includes changes, documentation, tracking systems, and defined approval levels necessary for authorizing and controlling changes.
- PRINCE2 - the technical and administrative activity concerned with the creation, maintenance and controlled change of configuration throughout the life of a product (or item)
- Software Engineering Institute - a discipline for evaluating, coordinating, approving or disapproving, and implementing changes in artefacts that are used to construct and maintain software systems. An artefact may be a piece of hardware or software or documentation. CM enables the management of artefacts from the initial concept through design, implementation, testing, baselining, building, release, and maintenance
- ITIL - Process responsible for maintaining information about Configuration Items (CI) required to deliver an IT Service, including their Relationships. This information is managed throughout the Lifecycle of the CI
Benefits of Configuration Management to your Project
The minimum benefits of Configuration Management to your Project are:
- It enables management of Project products. So for example, if something "goes wrong" with a product it will enable you to find out who changed it and what changes were made. Without it, you can't be sure what version of documents are being approved as "fit for purpose".
- Without it, you have no basis for Change Management. With Configuration Management in place you understand the status of each product and the relationships between items. So it is a tool for Impact Assessing changes.
Depending on the type of Project it can be vital to control a huge number of lower level components. In IT Projects for example, a tailored software tool is often utilised to manage the complexities here, see later.
Start with documents produced by the Project
Any documents produced by the Project should be under Configuration Management control. A check-list of what this means is:
- Do you, as Project Manager, have a list of at least the major documents to be produced by the Project both management and technical including status? I like to combine this with my "Quality Plan" for the documents, see my post on the subject
- Each document should have a "Control section" defining the configuration control of the document such as where the master copy is stored (e.g. SharePoint site), the current version of the document and the change history (who changed the document, when and how in summary form). Again, I like to see elements of the Quality plan in this section, who is reviewing and approving the document.
- With regard to the Control section when I say EVERY document I mean it. I am amazed to find sometimes complex spreadsheet documents without configuration control. For my Projects, every key document which happens to be spreadsheet always has the first tab labelled CONTROL with this information in. The same applies if you are using a presentation software like PowerPoint etc etc. So, remember that ALL documents are to be configuration controlled.
- If your Project file is a shared server location then you should include the version of the document in the filename e.g. "Title v0-1.doc".
- If you are using a SharePoint site, then I suggest that you setup to maintain version control, check in / out etc. In this instance please do NOT include the version number in the document filename as you should have one URL for the document at the current version (which I believe should be maintained within the document, not rely on the SharePoint version history, this is just an extra insurance policy!)
Other tools depend on the complexity of the Products within your Project
The example which I am most familiar with is Software Configuration Management tools for IT Projects. You certainly need a tool such as TFS, PVCS, the free SVN etc, there are many such tools with differing capabilities.
As well as basis configuration management across a lot of small components that may go to make up a delivered software solution, things they may support which are important to an IT Project Manager are:
- ability to maintain multiple versions of components in differing baselines - this is often called code branching and is important as if your Project is changing a software application already in Production use. If so, the minimum you are likely to require is a Production branch (for support team use) and a Project branch - on some Projects I have been involved with, the situation has been somewhat more complex and without a good tool, clear processes and much policing we would have failed!
- Along with code branching are capabilities to compare and merge code between branch lines
- Ability to undertake automated unit / other testing sometimes as a quality check as part of allowing a check-in
- Ability to create "builds" of software
- Possibly deployment of builds to environments
- Etc Etc
Conclusion
Hopefully you now have a high level understanding of the subject of Configuration Management. Most important is the minimum to get in place with regard to your Project documentation. Good luck with your own Project jigsaw puzzle, Configuration Management can help you solve it!
.png)
0 Comments