What You Need to Know (Even If It’s Not Your Job Title)
Systems engineers and Configuration Managers exist in a relationship that is frequently functional, occasionally fractious, and almost never as well defined as it should be.
The systems engineer’s view of CM tends to be shaped by their experience of it. In practice, that experience is usually the change control process - specifically, the friction of it. Change requests that come back incomplete. Class I determinations that feel disproportionate to the change involved. CCB reviews that add weeks to a schedule that is already strained. The paperwork.
What tends to be less visible, from the systems engineering seat, is what all of that friction is protecting. And why, when CM breaks down on a program, the consequences rarely look like CM failures. They look like engineering failures, delivery failures, or program failures.
This article is written for systems engineers who want to understand the CM function well enough to work with it effectively. Not to become CM practitioners. Just to understand what the discipline is actually trying to do, and why the decisions you make as a systems engineer either support or undermine that effort.
What CM is actually Protecting
If you strip away the process and paperwork, Configuration Management exists to protect three things.
The first is the truth about what the product is supposed to do. This is the Functional Baseline - the approved specification that defines performance requirements, interface constraints, and design intent at the system level. Once it is established, any change to that approved truth requires a formal process. Not because CM practitioners love bureaucracy (although I’ve certainly met some that do!), but because everything downstream - the allocated requirements, the design documentation, the verification planning, the test procedures --is built on top of it. A change that alters the foundation without being properly assessed and controlled can invalidate work that nobody has gone back to check
The second is the truth about what the product is designed to do. This is the Product Baseline - the design documentation, drawings, interface definitions, and parts lists that describe the product in enough detail to build it, test it, modify it, and support it across its service life. These documents are the record of every design decision that has been made and approved. CM controls changes to this record because change is rarely localised. The interface implications, the downstream test impacts, the supplier effects - these are what the change classification process is designed to surface before implementation, not after.
The third is the verifiable chain of custody between those two truths. The product that is delivered must be traceable back to the specification that was approved. Every change made along the way must be authorised, documented, and reflected in the configuration record. That chain is what configuration audits verify. When it breaks, you don’t have a CM problem. You have a program problem that CM failed to prevent.
As a systems engineer, your work touches all three of these.
The CI selection conversation you should be part of
Configuration Identification is the process of deciding which elements of a system are Configuration Items - what gets a unique identifier, what sits under formal change control, and at what level of the product hierarchy that control is applied.
This is a decision with long consequences, and it is one that systems engineers are often underrepresented in. The tendency is for CM teams to drive it, sometimes without access to the system architecture detail that would drive a better decision.
The tension might seem familiar. CM teams tend toward more CIs, because more controlled items means more visibility into change and more explicit traceability. Systems engineers tend toward fewer, because more CIs means more overhead on every change, more documentation to maintain, and more process to manage. Both instincts reflect legitimate concerns. Both, taken too far, create problems.
The right answer is not a compromise between those two positions. It is driven by the system architecture. CIs should align with real functional and physical boundaries - the places where interfaces exist, where separate development or procurement occurs, where independent maintenance will be needed, where a change in one area could have flow-on effects to another. The systems engineer’s functional decomposition and interface analysis are the inputs that should be driving that decision. They usually aren’t, because the conversation does not happen at the right time.
If you have influence over CI selection on your program - and at some level, most systems engineers do - the value of that influence is highest before the Functional Baseline is established. After that point, the CI structure is largely fixed and the consequences of a poor selection decision are borne by everyone for the life of the program.
What change classification is actually assessing
A frequent source of friction between systems engineers and CM is the change control process, and the most common cause of that friction is scope.
A systems engineer identifies a change to a component. They assess the impact within that component. They determine it is contained, minor, within existing design parameters, and submit it as a Class II change request. The CM team or the CCB reviews it and identifies that the change affects an interface definition, which references a downstream subsystem, which has implications for a test procedure that has already been completed against the previous configuration. The Class II becomes a Class I, the change request goes back for a broader impact assessment, and the schedule impact doubles.
This pattern isn’t indicative of a process failure. It is the process functioning as intended, catching an impact that the initial assessment missed. But it’s also avoidable, because the expansion of scope is almost always detectable at the point of initiation for a systems engineer who has traced the change beyond its immediate context.
The question that change classification is designed to answer is not whether the change is large or small in isolation. It is whether the change affects form, fit, or function - not just of the CI itself, but of anything it connects to. For systems engineers, whose job fundamentally involves managing those connections, this should be a natural part of how a change is assessed before a request is submitted. In practice, the interface tracing step often doesn’t happen, because it takes time and because the assumption tends to be that a contained local change has contained local effects.
That assumption is wrong often enough that the change control process exists specifically to catch the exceptions.
Status Accounting and the quality of information
Configuration Status Accounting is the recording and reporting function of CM. It’s the ongoing tracking of what has been approved, what has been implemented, and what the current verified state of the product actually is at any point in time.
Most systems engineers interact with Status Accounting primarily as consumers. They query the CM system to find the current approved version of a specification, or check whether a change has been formally implemented before beginning dependent design work. What is less obvious is how much the quality of that record depends on information that comes from the engineering team.
If a design change is implemented without the corresponding document update being tracked through the CM system, the status accounting record becomes unreliable. If a test result is filed without being formally linked to the configuration it verified, the chain between specification and product breaks. These are CM failures in form, but they originate in engineering activities - and in many cases, in the assumption that CM will pick up the status implications automatically from information that was never provided.
CM systems are not self-updating. They reflect what is reported to them. A configuration record that accurately represents the state of the product at any given point in time requires deliberate, timely input from the engineers doing the work. This is frequently seen as an administrative burden instead of what it actually is. A design control.
Audit preparation is not the CM team’s job
The Functional Configuration Audit (FCA) verifies that the product’s performance meets the requirements of its approved specification. The Physical Configuration Audit (PCA)verifies that the product as-built matches its technical documentation. Both are primarily dependent on work that systems engineers have already done.
The FCA draws on test results, analysis reports, and requirements traceability matrices. The PCA draws on drawings, parts lists, assembly records, and the documented resolution of every deviation and waiver that was granted during production. If that documentation is incomplete, inconsistent, or not formally released under CM control, the audit will find it. The finding is then a CM record of an engineering problem-- not because CM created the problem, but because the audit is where the problem becomes visible.
The most useful thing a systems engineer can do to support both audits is to treat the documentation as a live record rather than a post-activity requirement. Current specifications, released drawings, closed verification records, and a clear disposition of every outstanding deviation - these are audit readiness, but they are also just the documentation that would be needed to hand the product over to a new team and have them understand what it is, how it was built, and whether it performs as specified.
Early Engagement = Less Pain
The programs where CM works well are not, in my experience, the ones with the most rigorous CM processes or the most experienced CM teams. They’re the ones where the engineering function understands what CM is protecting and engages with it early enough for that understanding to shape the decision making process.
The systems engineer who is part of the CI selection conversation at program set-up, who traces interface implications before submitting a change request, who ensures the CM record reflects design decisions as they are made, and who treats audit preparation as ongoing rather than event-driven isn’t doing CM’s job. They’re doing their own job in a way that makes CM possible.
The programs where it goes wrong usually share a common pattern. CM is set up after the architecture is defined and the CI structure is imposed on a design that was not developed with CM boundaries in mind. The change control process becomes adversarial because the engineering team has learned to expect that changes will be reclassified and scoped upward. The status accounting record falls behind because the updates depend on information that nobody is formally responsible for providing. And the first PCA reveals a gap between the as-built product and the technical documentation that was never identified.
None of that is inevitable.
Most of it is a consequence of a conversation that didn’t happen early enough, between two functions that were operating on parallel tracks rather than a shared understanding of what they were both trying to achieve.
Baseline exists to professionalise Configuration Management and make its value explicit. Not as an afterthought, and not as a clerical function, but as a strategic capability that underpins delivery confidence. The CM Practitioner’s Handbook is available at BaselineCM.com.au.