Why baselines are the most misunderstood concept in configuration management
Ask ten people on a defense program what a "baseline" is and you will get ten different answers. Some will say it is a document. Others will say it is a build. A few will gesture vaguely at a folder on SharePoint. Almost none will give you an answer tied to EIA-649C, the standard that actually defines these terms.
The confusion has real consequences. When a program does not have a clearly established baseline, change requests get evaluated against the wrong reference point. Engineering teams debate what is "in baseline" and what is not. Configuration control boards approve changes that nobody can trace back to a formal requirement. Audits find discrepancies between what the documentation says and what the hardware or software actually does.
EIA-649C, Configuration Management Standard, defines three primary baselines: functional, allocated, and product. Each one corresponds to a stage in the system development lifecycle and carries a distinct set of documents, a specific approval authority, and a defined relationship to change control. Understanding what each baseline is and when to establish it is not optional on any program subject to configuration management requirements - which, in the DoD and NASA context, includes most development and integration work above a certain threshold.
What is the functional baseline and when do you establish it?
The functional baseline captures the functional and performance requirements for a system. It is established when the system requirements are formally approved, typically at the end of System Requirements Review (SRR) or at Milestone B in the DoD acquisition framework. The primary document that defines the functional baseline is the System Requirements Specification (SRS) or equivalent.
The functional baseline answers the question: what must this system do? It does not say how the system will do it. That comes later. The functional baseline is the reference against which you evaluate changes to requirements - if someone wants to add a new capability or modify a performance threshold, that is a potential change to the functional baseline and goes through the Configuration Control Board (CCB).
Common mistake: programs that do not have a single, formally approved SRS at Milestone B. Requirements are scattered across technical interchange meeting minutes, emails, and SOW paragraphs. Nobody can tell you what the functional baseline is because it was never formally established. Every subsequent decision in the program is made without a clean reference point.
What is the allocated baseline and when do you establish it?
The allocated baseline is established when the system design is approved at Preliminary Design Review (PDR). It captures how requirements have been allocated from the system level down to subsystems and configuration items. The allocated baseline includes the system architecture, interface requirements, and the allocation of performance parameters to individual components.
Where the functional baseline says "the system shall detect objects at 500 meters," the allocated baseline says which sensor subsystem owns that requirement, what the interface to the processor is, and what the subsystem-level specification looks like.
The allocated baseline is the foundation for the development contracts or work orders that go to subsystem teams. Without a clean allocated baseline, subsystem developers are working against shifting targets. Interface control documents (ICDs) should be under formal change control by this point.
On NASA programs, the allocated baseline typically ties to the Critical Design Review (CDR) entry criteria. On DoD programs under JCIDS and DoDI 5000.02, it is anchored to Milestone C preparation. The naming and timing varies by program type, but the concept is the same: approved design documents, controlled at the CCB level, traceable to the functional baseline above.
What is the product baseline and when is it established?
The product baseline is established after the system is built, tested, and accepted. It describes the system as it was built - not as it was designed, not as it was planned, but as it actually exists. The product baseline includes the final design documentation, the as-built configuration records, and the acceptance test results.
For software, the product baseline corresponds to the released version: source code, build configuration, and test results, all tied to a specific version identifier. For hardware, it includes the as-built drawing package, the bill of materials at the manufactured configuration, and the acceptance test data.
The product baseline is what you hand to the customer, what goes into the logistics baseline for support, and what the sustainment contractor works from. If the product baseline is wrong or incomplete, every repair, upgrade, or modification done in the field is starting from bad information.
How do baselines relate to change control?
The whole point of a baseline is that it gives the CCB a defined reference for evaluating changes. Without a baseline, the CCB cannot tell whether a proposed change is a correction to the current configuration or an increase in scope. It cannot assess the full impact of a change if nobody knows what the current approved state is.
Once a baseline is established, any change to the items under that baseline requires a formal change request - an Engineering Change Proposal (ECP) for engineering changes, a Deviation or Waiver for departures from the approved configuration. The CCB reviews, approves or rejects, and the baseline is updated to reflect approved changes.
The relationship is bidirectional. Baselines require change control to stay current. Change control requires baselines to be meaningful. Programs that implement one without the other end up with either a static document nobody trusts or a change process that loops back to nothing.
Why do organizations either skip baselines or create too many?
Two failure modes dominate. The first is skipping baselines entirely. This happens most often on programs that grew organically - an initial contract, a series of modifications, a new task order. Nobody ever stopped to formally establish a baseline because there was always something more urgent. By the time the program is large enough to need a DCMA audit or an FCA/PCA, the CM team is trying to reconstruct a baseline retroactively from whatever documentation exists.
The second failure mode is baseline proliferation. Every incremental delivery, every patch release, every minor design change gets called a new baseline. Within a year the program has 40 "baselines" in a folder structure that nobody navigates. When an engineer asks what the current approved configuration is, the answer is unclear because there is no naming convention, no index, and no formal process for superseding old baselines.
The fix for the first problem is discipline at the program milestone gates. Establish the functional baseline at SRR and do not proceed to PDR without it. Establish the allocated baseline at PDR. The fix for the second problem is a clear baseline naming convention, a CM plan that defines what constitutes a new baseline vs. an update to the current one, and a configuration index that shows the current approved version at a glance.
What does a government CM audit actually look for?
Functional Configuration Audits (FCAs) and Physical Configuration Audits (PCAs) are the formal verification events in DoD and NASA programs. The FCA verifies that the product's test results confirm it meets its functional requirements. The PCA verifies that the as-built configuration matches the product baseline documentation.
Auditors are looking for traceability. They want to trace a requirement from the SRS through the design documents to the test procedures and test results. They want to pull any item in the product baseline and find the corresponding drawing, specification, or code version. When those traces are broken - requirements that do not map to design documents, test procedures that reference old document versions, hardware that was modified after PCA without a formal ECP - that is a finding.
The most common PCA findings in defense programs: as-built drawings do not match the fielded configuration because field modifications were made without ECPs, software versions in the build configuration do not match the source code repository, and component part numbers on the BOM do not match what was actually installed. All of these trace back to inadequate baseline control during development.
FAQ
Q: Do we need all three baselines on every program? A: On most DoD and NASA development programs, yes. The three baselines map to the acquisition lifecycle and are required by contract on programs with formal CM requirements. On smaller programs or sustainment-only efforts, you may only be maintaining a product baseline for an already-delivered system.
Q: What is the difference between a baseline and a configuration item? A: A configuration item (CI) is an individual element under configuration control - a hardware assembly, a software component, a document. A baseline is the formally approved aggregate of configuration items and their documentation at a point in time. Baselines contain CIs; CIs are not baselines themselves.
Q: Who has authority to establish and change a baseline? A: Baseline establishment requires approval from the Configuration Control Board, which on government programs typically includes the program manager, chief engineer, and customer representative. Day-to-day changes to items within a baseline go through the same CCB. The approval authority for a change scales with the impact - minor changes may be delegated, changes to the functional baseline typically require government approval.
Q: How do we handle a baseline when the program has already been running for years without one? A: Start by documenting what the current state actually is. Build a configuration index of existing documentation, identify the items that should be under control, and establish a product baseline from the as-is configuration. Then work backward to document the requirements and design baselines as best you can. It is imperfect but far better than continuing without any baseline at all.
Q: What tools are typically used to manage baselines? A: On large DoD programs, specialized PDM and PLM tools like Windchill, ENOVIA, or Teamcenter are common. Software-centric programs often use git with formal tagging and release processes. Smaller programs may use SharePoint with strict version control conventions. The tool matters less than the discipline - a well-run SharePoint with defined naming conventions beats a PLM tool that nobody maintains.
Q: How does EIA-649C relate to MIL-HDBK-61? A: MIL-HDBK-61 is the DoD implementation handbook for configuration management and aligns closely with EIA-649. EIA-649C is the current industry standard; MIL-HDBK-61 provides the government-specific context and contractual references. On DoD programs, both are relevant. EIA-649C defines the concepts; MIL-HDBK-61 explains how to apply them in a defense acquisition context.