Configuration Management: The Control Most Projects Notice Too Late
The moment configuration management becomes interesting is always the same. Two people are discussing the same item and describing different things, and it takes twenty minutes to establish that one of them is looking at a drawing issued in March and the other at what was built in July. Nobody did anything wrong. The project simply never maintained a reliable answer to the question of what is currently there.
Configuration management is the discipline that keeps that answer available: for every item under control, which version is current, where it is installed or held, what it depends on, and what changed since the last time anybody asked. It sounds like record keeping until the first time its absence costs a weekend.
Among the artefacts listed in Section 4 of the PMBOK® Guide Eighth Edition is a configuration management plan. Reading it alongside change control shows why the two are described separately.
Two different jobs
Change control governs decisions. Somebody proposes an alteration, the impact is assessed, an authority approves or rejects it, and the decision is recorded. The subject is whether something should happen.
Configuration management governs facts. Once the decision has been taken and the work has been done, it records what now exists: the new version number, the date it was applied, the environment it went into, the items affected by it. The subject is what is true today. A project can run change control immaculately and still be unable to say what is installed, because approving a change and recording its result are separate pieces of work and only one of them is exciting.
What is worth controlling
Specifications and drawings, where the current issue has to be identifiable at a glance and superseded versions have to be visibly out of use. On engineering projects this is routine practice. On business change projects the same documents circulate as attachments, and the fourth version of a process design will be in use somewhere for months after the sixth was agreed.
Software builds and their environments, including which release is in which environment and what configuration each one holds. A defect that cannot be reproduced is often a defect being tested against a different configuration from the one it was found in, and that is an expensive way to discover an uncontrolled environment.
Physical assets, once they exist. Serial numbers, firmware levels, the parts fitted, the modifications made. On anything that will be operated and maintained for a decade, the as-built record is the deliverable the operator lives with long after the project team has gone.
The baseline itself: the agreed set of items at a point in time that constitutes an approved state. Without a defined set, there is nothing to have a version of, and changes are assessed against whatever the individual assessing them believes the current position to be.
The breaker that was changed at three in the morning
A water company brought a refurbished pumping station back into service. During the commissioning period, a breaker in the main control panel failed on a Saturday night. The duty engineer did what any competent person would do: found an equivalent unit from a different manufacturer in the depot stores, fitted it with an adapter plate, restored supply by four in the morning, and went home.
Nothing was recorded beyond a line in the callout log. The as-built drawings and the asset record still showed the original unit, and nobody made a connection between a night repair and a document set that had already been signed off.
Eighteen months later the station's protection settings were reviewed as part of a wider programme. The review was done from the records, the settings were calculated for the original breaker, and the discrepancy was found only because a technician doing the physical work noticed that the unit in front of him did not match the sheet in his hand. That was fortunate. The cost was a fortnight of re-verification across every site the programme had touched, because once one record is known to be wrong, none of them can be relied upon. Deciding which items on a project genuinely need that level of control, and how to keep the record honest without drowning the team, is tailoring that Omega's PMP® Exam Preparation gives proper time to.
Keeping it proportionate
Control what would hurt to get wrong. The test is what happens if somebody acts on a stale version: where the answer is a wasted afternoon, informal versioning is fine, and where the answer is a safety consequence, a regulatory finding or a failed migration, the item belongs under control with a named owner.
Keep one place that answers the question. The commonest failure is three partial records, each maintained by a different group, none complete and all slightly different. One authoritative source that people actually trust beats a comprehensive scheme that half the project ignores.
Write the rule for the three in the morning repair before it happens. Urgent work will sometimes bypass the process, and that is usually the right call operationally. The useful control is a short, unambiguous retrospective route: what has to be recorded, by whom, within how long, so the record catches up with reality within days instead of never.
For a PMP® candidate, the distinction worth carrying is between authorising a change and knowing the resulting state. A scenario describing approved changes, a properly maintained change log and a team that still cannot say which version is in production is describing a configuration management gap, and the response that helps is establishing the record, not reviewing the approvals again.
The quickest check is to pick one item that matters and ask two different people which version is current and where they looked. Where the answers differ, or where both people looked in places nobody else knows about, you have found the control that is missing before it finds you.
Interested in going further?
Knowing when a project needs formal configuration control, and how much of it to impose on a team that is already busy, is a tailoring decision with long consequences for whoever operates the result. Omega's PMP® Exam Preparation covers change control, configuration and the project artefacts as one connected system.
The PMBOK® Guide Eighth Edition is where the configuration management plan sits alongside the other artefacts a project maintains.
Ad · Amazon affiliate link.
References
A167: Project Charter Explained: Purpose, Content and Common Misunderstandings
A168: Business Case vs Project Charter: What’s the Difference?
A169: Assumption Log vs Risk Register
A170: Decision Log: The Forgotten Project Control
A171: Change Log vs Issue Log
PMP and PMBOK are registered marks of the Project Management Institute, Inc.
