What Is Configuration Management in Systems Engineering?
Ask a software engineer what configuration management means and you will likely hear: version control, branching strategies, maybe CI/CD pipelines. Ask a systems engineer the same question and you should hear something different — a discipline for defining what a system is, controlling how it changes, accounting for its current state, and verifying that the physical reality matches the documented intent.
These are not the same thing. The conflation of software version control with configuration management as a systems engineering discipline is one of the more consequential category errors in engineering practice. It leaves hardware programs without the formal structure they need to manage complexity, and it leaves program managers surprised when a production unit doesn’t match the drawing package they approved six months ago.
This article defines configuration management as a discipline, explains its four core functions, and describes the artifacts — plans, items, baselines, and boards — that make CM operational rather than ceremonial.
Configuration Management: A Working Definition
Configuration management is the discipline of establishing and maintaining consistency between a system’s documented definition and its physical or functional realization across its entire lifecycle.
The key phrase is across its entire lifecycle. CM is not a phase. It is not something you do before first article inspection and then stop. It begins when you first define what you are building — often during concept development — and it persists through production, fielding, and eventually disposal. The system’s configuration at any given time is the complete, authorized description of what that system is: its functional requirements, allocated performance parameters, physical design, and verification status.
Two standards anchor most serious CM practice: MIL-HDBK-61B (the US Department of Defense configuration management guidance) and EIA-649 (the commercial standard maintained by SAE International). Both define CM around the same four functions.
The Four Functions of Configuration Management
1. Configuration Identification
Configuration identification is the process of selecting which system elements will be formally managed as configuration items (CIs), defining those CIs with sufficient precision that they can be unambiguously reproduced or audited, and organizing them into a logical hierarchy.
A configuration item is any hardware element, software component, firmware module, document, or data set that is designated for separate configuration management. Not everything needs to be a CI — designating too many items creates administrative overhead that collapses under its own weight. The engineering judgment is determining which elements, if changed, would have consequences significant enough to require formal control. A commercial off-the-shelf bolt with a standard spec is not a CI. A custom-machined structural fitting carrying load in a flight-critical assembly is.
CI selection produces a configuration structure — a hierarchy that mirrors (and often maps directly to) the system’s work breakdown structure and functional architecture. This hierarchy defines what you are managing and at what granularity.
Baselines are the formal snapshots within this identification process. Three types matter:
- Functional baseline: Established when the system-level functional requirements are approved — typically at System Requirements Review (SRR) or equivalent. It documents what the system must do.
- Allocated baseline: Established when requirements have been decomposed and allocated to subsystems and components — typically at Preliminary Design Review (PDR). It documents how performance is distributed across the architecture.
- Product baseline: Established when the detailed design is complete and verified — typically at Critical Design Review (CDR) and confirmed through first article inspection. It documents exactly how the system is built.
These baselines are not milestones. They are artifacts — controlled documents that persist and against which future changes are assessed.
2. Configuration Control
Configuration control is the process of managing changes to a baselined CI so that every change is evaluated for impact, approved by the appropriate authority, implemented consistently, and recorded.
The mechanism is the change control board (CCB). A CCB is a formally constituted group with the authority to approve, defer, or reject proposed changes to a controlled baseline. Membership typically includes the chief engineer or system architect, affected subsystem leads, quality, program management, and — for customer programs — a customer representative. The CCB is where technical authority and programmatic authority meet. A change that is technically elegant but would break interface agreements with a parallel subsystem gets rejected by the CCB, not by an individual engineer working in isolation.
The inputs to a CCB are engineering change proposals (ECPs) and requests for deviation or waiver. An ECP proposes a permanent change to a baselined CI. A deviation is a pre-production authorization to depart from a requirement on a specific unit. A waiver is a post-production acceptance of a unit that doesn’t meet its requirement. These distinctions matter: conflating deviations and waivers with actual requirement changes obscures the true configuration of what has been built and fielded.
Configuration control is where CM intersects most visibly with program cost and schedule. Every formal change has administrative cost. The incentive to bypass formal control is always present, especially under schedule pressure. Programs that allow informal changes accumulate what systems engineers call configuration debt — a growing divergence between what the documents say and what the hardware actually is. That debt is always collected, usually at the worst possible time: during a failure investigation, a contract audit, or a fleet modification campaign.
3. Configuration Status Accounting
Configuration status accounting (CSA) is the recording and reporting function of CM. It answers the question: what is the current approved configuration, and where is every unit relative to that configuration?
CSA tracks the lifecycle of every approved change: when it was proposed, when it was approved, when it was incorporated into the design, and when it was verified in production hardware. For fielded systems with multiple serial numbers, CSA tracks which changes have been incorporated into which units — a capability that becomes essential when a field anomaly is reported and the investigation team needs to know whether a particular unit has a particular modification.
Effective CSA requires a configuration management information system — a database that links CIs, baselines, change records, and as-built records. The discipline of keeping that database accurate is unglamorous and underestimated. It requires process discipline from every function that touches the hardware: design engineering, manufacturing, quality, and logistics.
4. Configuration Audit
Configuration audit is the verification function that confirms the system’s documentation matches its physical reality. Two audit types are standard:
- Functional Configuration Audit (FCA): Verifies that the system’s demonstrated performance matches its functional and allocated baselines — that it actually does what the requirements say it must do. Executed against test data.
- Physical Configuration Audit (PCA): Verifies that the as-built product matches the product baseline — that the hardware on the table matches the drawings and specifications. Executed by direct inspection.
FCAs and PCAs are typically conducted before major program milestones — before initial operational capability, before a production contract, before a major delivery. They are the formal mechanism for closing the loop between the CM record and physical reality.
The Configuration Management Plan
The configuration management plan (CMP) is the governing document for all CM activities on a program. It defines the CI structure, the baseline schedule, the change control procedures, the CCB membership and authority levels, the CSA tools and processes, and the audit plan.
A CMP that exists only to satisfy a contract data requirement is useless. A CMP that engineering teams actually reference when making decisions is the difference between CM as discipline and CM as paperwork. The quality of a CMP is best measured not by its length but by its specificity: does it tell an engineer, unambiguously, how to submit a change request for a specific CI? Does it tell a quality inspector exactly what documentation to check during a PCA?
Why This Is Not Version Control
Software version control — Git, Subversion, and their relatives — solves a specific problem: tracking changes to files, enabling parallel development through branching, and merging divergent histories. It is valuable. It is also not configuration management in the sense described above.
Version control has no concept of a formal baseline approved by a decision-making authority. A Git commit is not a CCB decision. Merging a pull request is not an engineering change proposal. Version control records what changed and who changed it; CM records what was authorized to change, why, and with what technical assessment of impact.
For software-only programs, the gap between these two paradigms is narrow enough that it is often bridged informally. For hardware programs — and especially for integrated hardware-software systems — the gap is consequential because hardware is physically irreversible in ways software is not.
A software defect discovered after release can often be corrected with a patch. A hardware defect discovered after production involves rework, scrap, field replacements, or — in aerospace and defense — potential safety consequences. The cost asymmetry between a change made at requirements definition versus a change made after first article inspection is typically measured in orders of magnitude. That asymmetry is what makes rigorous CM non-negotiable on hardware programs and what makes the confusion with software version control actively dangerous.
How Requirements Traceability Tools Integrate with CM
Requirements management and configuration management are distinct disciplines that share a boundary. That boundary is the requirements baseline. When a requirements baseline is formally established — the functional baseline at SRR, the allocated baseline at PDR — those requirements become controlled artifacts. A change to a controlled requirement is a configuration change. It requires the same formal treatment as a change to a drawing or a specification: an ECP, a CCB decision, and a status accounting record.
In practice, many programs manage their requirements in tools that have no formal connection to their CM processes. Requirements change informally, allocated performance shifts during design, and the functional baseline drifts away from the actual design intent without a formal change record. The audit trail that would explain why a requirement was changed, what trade analysis supported the change, and what verification evidence covers the new requirement simply doesn’t exist.
Modern requirements traceability tools address this gap by treating requirements baselines as first-class configuration artifacts. Flow Engineering, built specifically for hardware and systems engineering teams, implements this through a graph-based model where requirements, design decisions, and verification evidence are formally linked nodes. When a requirement baseline is established in Flow Engineering, it creates a snapshot of not just the requirement text but the full traceability context: the parent requirements it derives from, the design elements that implement it, and the test cases that verify it.
This means a proposed change to a requirement can be assessed for its downstream impact before the CCB reviews it — not manually traced through a matrix, but computed from the live traceability graph. The CCB sees, concretely, that changing a power budget requirement has implications for three downstream subsystem allocations and invalidates two existing test cases. That is the kind of information a CCB needs to make an informed decision, and it is exactly the information that requirements documents divorced from CM processes cannot provide.
Flow Engineering’s approach reflects a broader architectural principle: requirements are not just inputs to design, they are configuration artifacts that evolve with the system and must be controlled with the same rigor as any other CI. The tool’s deliberate focus on this hardware and systems engineering use case means it handles the complexity of multi-level requirement hierarchies and baseline management where general-purpose document management systems fall short.
Practical Starting Points
If you are standing up CM on a program that doesn’t have it, or tightening CM on one that has it in name only, three actions move the needle faster than anything else:
Define your CI structure before your first baseline. You cannot control what you haven’t identified. Spend the time at program start to determine what elements require formal management, what level of granularity makes sense, and how your CI hierarchy maps to your system architecture and WBS.
Make CCB authority levels explicit and enforce them. Distinguish between changes that require customer CCB approval, program-level CCB approval, and internal engineering authority. Ambiguity about approval authority is the primary driver of informal change.
Connect your requirements tool to your baseline schedule. If your requirements baselines are established on a different schedule than your design baselines — or not connected to them at all — you will accumulate requirements drift that is invisible until an audit or a failure forces it into view.
Configuration management is administrative in its mechanisms and consequential in its effects. Programs that treat it as overhead rather than discipline discover the difference late, and at high cost.