Home / Aerospace and defense program execution / Aerospace and defense project closeout
At the end of a program the customer needs to know, with certainty, what they are getting: which design, at which revision, with which changes built in. Configuration management is how a program answers that. When it has been neglected, closeout turns into an archaeology project.
The five functions
The EIA-649 standard, widely used across aerospace and defense, describes configuration management as five connected functions.
| Function | What it does | What goes wrong when it is weak |
|---|---|---|
| Planning and management | Defines how configuration management will be done on this program, and by whom | Every team invents its own process and nothing lines up |
| Configuration identification | Selects the items under control and the documents that define them | Nobody is sure which documents are authoritative |
| Change management | Evaluates, approves and tracks changes, deviations and waivers | Changes are built in before they are approved, or approved and never built in |
| Status accounting | Records the current approved configuration and the status of every change | The as-designed and as-built configurations drift apart silently |
| Verification and audit | Confirms the product matches its requirements and its documentation | Mismatches are discovered by the customer instead of the program |
Baselines
Defense programs typically manage three configuration baselines. The functional baseline captures the system level requirements. The allocated baseline captures the requirements assigned to each configuration item. The product baseline captures the detailed design that production will build to, and it is usually established through the functional and physical configuration audits. By closeout, the product baseline is the thing the customer is accepting.
What closeout exposes
Unincorporated changes. Engineering changes that were approved but never rolled into the drawings, or built into hardware without the drawings catching up.
Open deviations and waivers. Temporary departures from requirements that were approved for specific units and never closed.
As-built records that do not match the design. Serial numbered hardware whose records show a different revision or a part that was substituted without a documented change.
Supplier configuration gaps. Supplier parts built to a revision the program no longer recognizes, or supplier changes that were never reported upstream.
Each of these has to be found, dispositioned and documented before the product baseline can be accepted and the technical data package delivered.
How to close configuration cleanly
Reconcile as-designed against as-built. Walk the configuration item list, the drawing tree and the as-built records side by side, unit by unit, and log every discrepancy.
Work the change backlog to zero. Every open change needs a decision: incorporate it, cancel it or carry it forward formally to a follow-on contract. Nothing should be left in an undefined state.
Prepare the audits like a review, not an inspection. The physical configuration audit goes smoothly when the program has already done its own audit and resolved what it found.
Hand over records the customer can use. The status accounting records should let the customer, or a follow-on contractor, understand the product without calling anyone.
Software and firmware belong in the baseline too
On modern aerospace hardware, and on engine and flight controls especially, the software and firmware loaded into a unit are part of its configuration just as much as its machined parts. They need the same discipline: identified versions, controlled changes, and records showing exactly which build is installed in each serial numbered unit.
At closeout, gaps here are easy to miss because the hardware looks identical from the outside. A unit tested with one software version and delivered with another, or a field update that was never recorded against the unit, can undo the value of an otherwise clean configuration audit. Reconciling loaded software against the approved baseline should be part of every as-built review.
What is the difference between the functional and physical configuration audits?
| Functional configuration audit | Physical configuration audit | |
|---|---|---|
| Question it answers | Does the item perform as its specification requires? | Does the built item match its design documentation? |
| Evidence | Test, analysis, inspection and demonstration results against requirements | Comparison of the as-built item with drawings, parts lists and specifications |
| Typical timing | After verification testing of the configuration item | On a production-representative unit, before or at the start of production |
| Result | Confidence the functional and allocated requirements are met | The product baseline is established |
What does status accounting look like in practice?
Status accounting is the record that answers, at any moment, what the approved configuration is and where every change stands. In practice it is a controlled list of configuration items with their current documents and revisions, every change request with its status and effectivity, every deviation or waiver with the units it applies to, and the as-built configuration of each serial numbered unit. Good status accounting makes audits and closeout routine, because the answers are already recorded. Poor status accounting turns both into investigations.
What goes in a configuration management plan?
- The configuration items and how they were selected
- The baselines and when each is established
- Change classification rules and approval authority
- The configuration control board: members, cadence and records
- How deviations and waivers are requested and tracked
- Status accounting records and reports
- Planned audits and their entry criteria
- How supplier configuration is controlled and reported
How is configuration controlled at suppliers?
Through the purchase order and the supplier's own quality system. Orders should state the drawing and specification revisions, require notification and approval before changes to design, process, material, sub-tier source or manufacturing location, and flow down the relevant configuration requirements. Supplier changes that bypass this route are one of the most common causes of as-built records that do not match the design, and they often surface only at a first article, an audit or closeout.
The practical safeguard is a regular supplier change review: every notified supplier change is logged, assessed for its effect on form, fit, function and qualification, and dispositioned before the supplier implements it. Where a change is significant, a partial first article confirms the result. That keeps the prime's configuration records aligned with what its suppliers actually build.
Which metrics show configuration management health?
| Metric | What it reveals |
|---|---|
| Approved but unincorporated changes | Decisions that never reached the documents; tomorrow's closeout problem |
| Open deviations and waivers by age | Temporary departures that are becoming permanent |
| Change cycle time | Whether the change process is fast enough that people use it |
| As-built discrepancies found at audit | How well status accounting reflects reality |
How are engineering changes classified?
By their effect, which decides who has to approve them. On defense contracts, MIL-HDBK-61A describes two classes. A Class I change affects an approved baseline in a way that matters to the customer, such as performance, interfaces, safety, reliability, interchangeability, cost, schedule or delivered units that would need retrofit. It needs customer approval through an engineering change proposal before it is built in. A Class II change has none of those effects, such as correcting a drawing error or adding a clarifying note, and the contractor can approve it, with the customer usually only confirming that the classification is right.
| Context | Larger change | Smaller change | Who approves the larger change |
|---|---|---|---|
| Defense contract | Class I: affects the baseline, cost, schedule, interfaces or fielded units | Class II: no effect on any of those | The customer, through an engineering change proposal |
| FAA type design, 14 CFR 21.93 | Major: an appreciable effect on weight, balance, structural strength, reliability, operational characteristics or other airworthiness characteristics | Minor: no appreciable effect on any of those | The FAA, while minor changes follow a method the FAA has accepted |
| Supplier to a prime | Any change to design, process, material, sub-tier source or location that the purchase order requires them to report | Changes the order leaves to the supplier | The prime, before the supplier implements it |
Misclassification is the quiet failure here. A change filed as minor to save time, and later judged to be major, can mean rework, retesting, a reopened audit and a difficult conversation with the customer. When a classification is borderline, decide it deliberately and record the reasoning.
What is the difference between a deviation and a waiver?
Timing. In the MIL-HDBK-61A terms, a deviation is approved before the product is built: permission to depart from a requirement for a stated number of units or a stated period. A waiver is approved after the fact: permission to accept units that were found not to meet a requirement but are judged usable as they are or after repair. Newer editions of the EIA-649 family group both under the single term variance. Either way, neither one changes the baseline. A recurring deviation is a sign the requirement or the design should be changed properly, and an open one at closeout is a decision someone still has to make.
How do you decide where a change takes effect?
Every approved change needs an effectivity, the point from which it applies, stated by serial number, lot, block or date. Without one, nobody can say which delivered units have the change and which do not, and the as-built records stop meaning anything. Three questions drive the decision.
- Is the new item interchangeable with the old one? Standard drawing practice, reflected in ASME Y14.100, is that an item that is no longer interchangeable in form, fit or function gets a new part number, so the two can never be confused in stock or in the field.
- What happens to units already built? Retrofit, rework at the next overhaul, or leave as is. Each answer has a cost and a schedule, and on a Class I change the customer usually decides.
- What happens to material and work in process? Parts already bought or in work to the old revision need a disposition before the change reaches the line, not after.
Write the effectivity into the change record and the integrated master schedule together. A change that slips one unit later than planned is a minor issue. A change whose effectivity nobody recorded is a closeout problem.
How does configuration management fit AS9100D?
AS9100D makes it a requirement rather than good practice. Clause 8.1.2 requires an organization to plan, implement and control a configuration management process appropriate to its products, so that their physical and functional attributes are identified and controlled throughout the product's life. The standard points to ISO 10007 for guidance, and defense contracts typically add EIA-649 or EIA-649-1 on top. For a supplier, a weak configuration process shows up as findings at a quality system audit, a failed first article or a customer that stops trusting its delivered records.
The same discipline matters in recovery. When a program has been driven by informal customer requests, the first step is to compare the current design and work against the actual requirements, which is only possible when the configuration is known. See the requirements to work assessment for how that comparison is done, and manufacturing transition for why a moved line needs its configuration baselined before the first unit is built at the new site.
Related guides
- Scope control and technical baseline management
- Delivering a complete technical data package
- First article inspection under AS9102
- Aerospace and defense project closeout
How Set Boundaries helps
During project closeout, Set Boundaries reconciles the configuration, drives the open changes, deviations and waivers to a decision, prepares the program for its configuration audits and assembles records the customer can accept. It pairs naturally with closing out first article inspection, since both are about proving the delivered hardware is exactly what the documents say it is.
If a program is stuck near the end because nobody can say for certain what was built, schedule a call.
References
- SAE International, EIA-649, Configuration Management Standard.
- SAE International, EIA-649-1, Configuration Management Requirements for Defense Contracts.
- US Department of Defense, MIL-HDBK-61A, Configuration Management Guidance.
- International Organization for Standardization, ISO 10007, Quality management: Guidelines for configuration management.
- SAE International, AS9100D, Quality Management Systems: Requirements for Aviation, Space and Defense Organizations.
- Code of Federal Regulations, 14 CFR 21.93, classification of changes in type design.
- ASME Y14.100, Engineering Drawing Practices.
Questions
Common questions
What is configuration management?
Configuration management is the discipline of knowing exactly what a product is at every point in its life: which requirements it meets, which design documents define it, which changes have been approved and which have been built in. In aerospace and defense it is usually organized around the functions described in the EIA-649 standard.
What are the five functions of configuration management?
Planning and management, which sets up how configuration management will be done; configuration identification, which defines the items and documents under control; change management, which evaluates and approves changes; status accounting, which records the approved configuration and the status of every change; and verification and audit, which confirms the product matches its documentation.
What are the functional and physical configuration audits?
The functional configuration audit, or FCA, confirms that the item has achieved the performance and functional requirements in its specification, using test and analysis results. The physical configuration audit, or PCA, confirms that the as-built item matches its design documentation. Together they establish the product baseline.
Why does configuration management matter at closeout?
Because closeout is when the customer accepts a product baseline and the program hands over its technical data. Every unincorporated change, undocumented deviation or mismatch between drawings and hardware surfaces then, and each has to be resolved before the program can close cleanly.
What is a configuration item?
A configuration item is a hardware, software or firmware element, or an aggregation of them, that is designated for configuration management and treated as a single entity. Each has its own documentation, baselines and change control. Choosing configuration items well matters: too many creates administrative load, too few hides changes that affect interfaces, performance or support.
What should a configuration management plan include?
It should identify the configuration items and baselines, define how changes are classified and who can approve them, describe the configuration control board, set out how deviations and waivers are handled, specify status accounting records and reports, list the planned audits, and explain how supplier configuration is controlled. The plan should match the size of the program so the team actually follows it.
What is a configuration management process?
A configuration management process is the set of steps a program uses to define, control, record and verify its product configuration. It starts with a configuration management plan, then identifies configuration items and their governing documents, routes every change through evaluation and approval, records the approved configuration and change status, and audits the product against its documentation. EIA-649 and MIL-HDBK-61 describe these steps as five connected functions. Set Boundaries sets up or repairs this process so the as-designed and as-built configurations match at closeout.
What is the main objective of configuration management?
The main objective of configuration management is to establish and maintain consistency between a product's requirements, its design documentation and the physical product throughout its life. In practice, that means anyone can tell exactly which design and revision a unit was built to, and which changes are incorporated and why. This protects safety, supports maintenance and makes production repeatable. On defense programs, it is also what allows the customer to accept the product baseline with confidence, which is why Set Boundaries treats configuration status as a closeout priority.
Have a question that is not here? Ask Holly on a short call
