What is Configuration Management?

Michael Gerards · 2026-01-05

An official definition from the Association for Project Management provides the following answer:

“Configuration management encompasses the technical and administrative activities concerned with the creation, maintenance, controlled change and quality control of the scope of work.

A configuration is the functional and physical characteristics of a product as defined in its specification and achieved through the deployment of project management plans.”

But if you stop reading there, you’ll walk away thinking this is a technical admin function, a governance layer, or something someone else (usually the CM team) should worry about.

It isn’t.

Configuration Management is the quiet force that determines whether an engineering organisation succeeds or fails. Talking about Configuration Management isn’t as exciting as talking about launching apps, modernising systems or impressive architecture diagrams.

But none of that determines whether an engineering organisation succeeds.

The real determinant — the boring, neglected determinant — is whether the organisation actually understands how its important things hang together.

That is Configuration Management.

If that sentence feels anticlimactic, that’s exactly the problem.

Walk into almost any enterprise software development shop and you’ll see:

• Millions spent on teams
• No one having any real confidence in the test suite and quality control process
• CCBs where nobody actually understands what is being changed or the associated risk

There is an unspoken acceptance that this chaos is simply the cost of doing business — that changing things for the better is always just a matter of a ‘fresh new direction’, a new leader, or better dashboards. However, none of these things ever seem to make any fundamental difference to the chaos.

Of course there’s no difference! Chaos is the bill you pay for ignoring configuration management.

Leaders feel this, even if they don’t name it. When they try to reconcile burn rates and headcount projections, they usually end up asking some version of “Why is delivery so slow?”.

Meanwhile, the answer sits there like gravity: nobody actually knows the state of the system well enough to change it safely.

And because no one names it as configuration, the organisation keeps paying — silently, expensively, indefinitely.

Why is Configuration Management neglected by leadership?

Because culturally, it has been defined as administration, not engineering.

You can see this in how almost every organisation behaves:

For leadership:

• CM is “owned by the CM team.”
• If change is slow, the CM process is blamed — not the lack of system state knowledge.
• CM is not seen as strategic — it does not appear on KPIs, roadmaps, or investment narratives.

For technical staff (developers, testers, engineers):

• CM is paperwork required to push a change.
• It is detached from their day-to-day reality of code, systems, outages, and fire-fighting.
• The CM plan exists, but nobody reads it — and when they do, it merely confirms it is irrelevant to how work is actually done.

For non-technical staff (change boards, document controllers, writers):

• CM is the only formal mechanism through which information is transferred from technical to non-technical teams.
• But even here, it is treated as a throughput mechanism, not a source-of-truth or control.
• The CM plan is read only when required — usually to check for compliance.

CM is neglected because the organisation does not believe it has anything to do with engineering outcomes.

This cultural view didn’t appear by accident. It emerged because we have collectively forgotten what engineering actually is.

To understand how CM became “paperwork,” we need to return to first principles.

What is Engineering?

Most definitions of engineering focus on technology — for example this is the Cambridge dictionary’s definition:

“the study of using scientific principles to design and build machines, structures, and other things, including bridges, roads, vehicles, and buildings”

Definitions like this miss the point — engineering is about the application of technology under constraints, not the technology itself. The following alternative is closer to reality.

Engineering is the discipline of creating or changing a system with limited time, money, and materials.

Every engineering discipline shares the same lifecycle:

• Requirements
• Design
• Implementation
• Testing
• Delivery
• Maintenance (which is explicitly all of the above, continuously)

At each phase, something new is created: knowledge, decisions, artefacts, dependencies, baselines. And every new thing consumes one or more of the three constraints: time, money, materials. Here, materials include information — especially in software, where libraries, bespoke code, configuration files, and data are the raw material of construction.

This combination (knowledge, baselines, etc) encompasses not just the engineering project’s output but also state. How well that state is managed directly affects the burn rate of time, money, and materials. If actions are not cognisant of system state, the risk of waste (I say “risk”, but in my observation it’s certainty!) compounds over time — leading to exponentially increasing losses. And the converse is true — effective management of system state yields massive increases in productivity, profitability, and peace.

Therefore, configuration management is not an administrative afterthought — it is the heart of engineering. Neglect it, and the negative effects will be disproportionately large, regardless of discipline elsewhere. That is because CM touches every aspect of the project — so whether it is done well or done poorly, its effects are multiplied everywhere.

Configuration Management — the heart of Engineering

Configuration Management is the heart of engineering because it regulates every other part of the engineering discipline. It truly is the “engineering behind engineering”. The definition below is simpler and more practical than the previous “official” one.

Configuration Management is knowing how the important stuff hangs together.

What is the “important stuff”? It is whatever elements the project decides are worth protecting — the things whose corruption, loss, or mismatch would cost time, money, or materials. Those elements become configuration items.

What does “hangs together” mean? It means knowing — at all times — how each configuration item relates to every other, and ensuring that any change is made with full awareness of its impact on the whole system.

Because when that knowledge is absent, the cost is not just technical — it compounds. Confusion becomes delay, delay becomes rework, rework becomes budget burn.

CM is the discipline that keeps system state knowable. Without it, engineering becomes accidental, expensive, and unwieldy.

How to know if Configuration Management is broken in your organisation

Most organisations think they are “slow” or “under-resourced” when, in reality, they are flying blind. If any of the following are true, CM is not functioning — regardless of how many documents, plans, or processes exist:

1. Nobody can state the version of the production baseline — not just the app version (which is straightforward), but the version of Production itself (servers, dependencies, external APIs, databases, data, load balancers, everything).
2. CCB documentation obscures rather than clarifies — changes cannot describe the before-and-after state of the system, and there is no extractable blast radius.
3. Production changes are anxiety-driven, and every deployment ends with self-congratulatory relief instead of quiet confidence.
4. Configuration audits are forensic investigations — requiring detective work instead of simple confirmation.

These are the signs that the chaos bill is compounding.

Conclusion

If there is one idea to take from this article, it is this:

Engineering only moves as fast as it understands its own state. Configuration Management is how that state stays knowable.

Most organisations don’t consciously choose chaos — they simply never named configuration as the cause of it. If reading this surfaced familiar pain, you’re not alone. The gap between intention and reality in engineering is widespread — not universal, but close.

I’m currently working on a project in this space — exploring how to make system state visible and change safe. With good configuration management, changes are boring. Mistakes still happen, but they’re never mysterious.

If you’d like to follow the progress or be part of the early conversation about solutions, leave your email below. If you just want to share your thoughts, you’re welcome to do that too — with or without an address.

References

1. The definition for Configuration Management from the Association for Project Management was taken from here and was current as of January 2, 2026.
2. The definition for Engineering from the Cambridge dictionary was taken from here and was current as of January 2, 2026.