Home / Aerospace and defense program execution
Engineering programs rarely fail from one large change. They fail from a hundred small ones that entered the baseline without being priced, scheduled or approved. Set Boundaries puts scope and the technical baseline under control: clear baselines, traceable requirements, a change process people actually use, and configuration discipline aligned with AS9100 and the EIA-649 standard.
Why does baseline drift cause cost and schedule problems?
Every hour in the program budget and every task in the schedule is tied to a defined scope of work. When the technical content drifts without a formal change, the work grows while the budget and schedule stay the same. The result shows up later as cost overruns and slips that nobody can explain, because the extra work was never recorded as a change. By the time the variance is visible, the design decisions behind it are months old and the chance to negotiate them with the customer has passed.
Controlling the technical baseline is therefore not paperwork for its own sake. It is how a program protects its budget, its schedule and its relationship with the customer.
What are the three baselines, and when is each set?
| Baseline | What it defines | Typically established at |
|---|---|---|
| Functional baseline | System-level performance requirements and verification methods | System requirements and system functional reviews |
| Allocated baseline | Requirements allocated to each configuration item, including interfaces | Preliminary design review |
| Product baseline | The detailed design, drawings and specifications production builds to | Critical design review, confirmed by the physical configuration audit |
Each baseline builds on the one before it. Changes to an earlier baseline ripple forward, which is why late changes to system requirements are so expensive: they can reopen design, test and production documentation all at once.
How should a change process work?
- Every change request is written down. Customer requests, internal ideas and discovered problems all enter the same process, with the originator and reason recorded.
- The request is checked against the baseline. The traceability matrix shows whether it is already in scope, a clarification, or a genuine change.
- Impact is assessed across the program. Engineering, cost, schedule, interfaces, verification, supply chain, production and data deliverables.
- The change is classified. Major changes that affect the customer's baseline need customer approval; minor ones follow the program's internal authority.
- The configuration control board decides. Approve, reject or defer, with the decision and rationale recorded.
- Approved changes are implemented everywhere. Drawings, specifications, the schedule, the budget and the earned value baseline are updated together.
- Implementation is verified. The change is confirmed in the documentation and, where applicable, in the hardware.
The most common failure is step six: a change is approved and built into hardware, but the drawings, schedule or budget never catch up. That gap is exactly what surfaces at closeout as unincorporated changes.
What does requirements traceability look like in practice?
A traceability matrix connects each requirement to its parent requirement or contract source, to the design elements that satisfy it and to the test, analysis, inspection or demonstration that verifies it. Maintained properly, it answers three questions quickly. Is this request already in scope? What would this change affect? Has every requirement been verified? Programs without traceability answer those questions by meeting, which is slower and less reliable.
Which metrics show whether scope is under control?
| Metric | What it reveals |
|---|---|
| Requirements volatility | Share of requirements added, deleted or changed per period; high late volatility predicts rework |
| Open to-be-determined and to-be-resolved items | Unfinished requirements that will become changes later |
| Change request backlog and age | Whether the board is keeping up, or decisions are stalling the program |
| Change cycle time | Days from request to decision to implementation |
| Approved but unincorporated changes | Gaps between decisions and documentation, the future closeout problem |
| Unexplained cost and schedule variance | Often the signature of unrecorded scope growth |
How does this align with AS9100 and EIA-649?
AS9100D requires aerospace organizations to plan and control configuration management appropriate to the product, and to control changes to design and production. ISO 10007 gives general guidance on configuration management, and the EIA-649 standard, widely used across defense, organizes the discipline into planning and management, configuration identification, change management, status accounting, and verification and audit. A baseline and change process built along those lines meets the standards and, more importantly, keeps the program's documentation, hardware, budget and schedule telling the same story.
What goes wrong most often?
Changes agreed in meetings. An engineer agrees to a customer request on a call, and the work begins without a change request. The fix is simple and cultural: no work without a written, dispositioned request.
Requirements left ambiguous. Vague requirements invite interpretation, and interpretation grows scope. Clarifying them early, with the customer, is cheaper than negotiating later.
Boards that meet too rarely. A monthly board on a fast-moving program creates backlogs that teams work around. The cadence should match the rate of change.
Supplier changes that never reach the prime. Suppliers change processes, materials and sub-tier sources. Flow-down clauses and supplier notification requirements keep those changes visible.
How do you recover a baseline that has already drifted?
Start by reconstructing what actually happened. Compare the current design, drawings and work in progress against the last approved baseline and list every difference. For each one, find out where it came from: a customer request, an internal design decision, a problem discovered in test, or an undocumented workaround on the shop floor. That list becomes the recovery backlog.
Each item then needs a decision. Changes the customer asked for and the program cannot absorb are candidates for a formal change proposal, with cost and schedule impact. Changes that were genuinely needed but internally driven are brought into the baseline through the board and paid for from reserves. Changes that nobody needs are reversed or stopped. Finally, the schedule and earned value baseline are updated so the performance numbers reflect the real scope again. Programs that go through this once usually find their unexplained variance was mostly unrecorded scope, and the relief of seeing honest numbers again tends to make the new change discipline stick.
How much process does a small program need?
Less than a large one, but not none. A small program can combine the change board with its weekly program meeting, keep traceability in a simple matrix and handle minor changes with a one-page form. What must not be skipped is the principle: no work on a change until it is written down, assessed and approved by the person with the authority to approve it. Scale the paperwork to the program, never the discipline.
The answer is a controlled path for customer requests rather than a slower team. Every new request is checked against the contract before work starts: is it a requirement, and what does it do to cost and schedule? Engineers keep working at full speed on the agreed scope while leadership decides what to do with the request.
How does Set Boundaries bring a drifting baseline back under control?
The first step is a comparison many programs have never made: what the team is actually working on against what the contract actually requires. It comes before any recovery plan. The current design and the open activities are laid against the contractual requirements, and each piece of work is sorted into required, not required, or unclear and needing a decision. Our guide to the requirements-to-work assessment explains the method.
The finding is usually the same. Engineering has been responding in good faith to requests from the customer's technical organization, without anyone determining whether each request was a contractual requirement or what it did to cost and schedule. Over time the team loses sight of what "done" means.
What does a controlled path for customer requests involve?
- One agreed route for new requests from the customer's technical staff, so nothing enters the work through a side conversation.
- Each request checked against the contract and the compliance matrix before work starts.
- Cost and schedule impact assessed and shown to leadership, who decide whether to proceed, propose a change or decline.
- Out-of-scope work priced and put to the customer as a change, so it is funded rather than absorbed. Our guide to scope-change claims covers the commercial side.
None of this slows the engineers down. They keep working at full speed on agreed scope, and they are protected from the uncontrolled work that erodes both the budget and their own credibility with the customer. Leadership, for its part, gets to decide on scope growth with the cost and schedule in front of it, rather than finding it months later as unexplained variance.
How does Set Boundaries help?
We establish or repair the baselines, build the traceability matrix, set up a change process and board proportionate to the program, and connect approved changes to the schedule and earned value baseline so they are paid for and planned. On programs already suffering from drift, we reconstruct the change history, identify unauthorized scope and help the program decide what to regularize with the customer and what to stop. The work connects directly to earned value and configuration management at closeout.
If your engineering scope keeps growing without the budget growing with it, schedule a call.
References
- SAE International, EIA-649, Configuration Management Standard, and EIA-649-1 for defense contracts.
- US Department of Defense, MIL-HDBK-61, Configuration Management Guidance.
- SAE International, AS9100D, configuration management and control of changes.
- International Organization for Standardization, ISO 10007, Guidelines for configuration management.
- US Department of Defense, MIL-STD-881, Work Breakdown Structures for Defense Materiel Items.
Questions
Common questions
What is a technical baseline?
A technical baseline is the approved, documented definition of a product at a point in its development: the requirements it must meet and the design that meets them. Defense programs usually manage three: the functional baseline for system requirements, the allocated baseline for requirements assigned to each configuration item, and the product baseline for the detailed design that production builds to. Once approved, a baseline changes only through formal change control.
What is scope creep on an engineering program?
Scope creep is work entering the program without being authorized, estimated and scheduled. On engineering programs it usually arrives as small technical requests from the customer, design refinements engineers add on their own, or requirements that were ambiguous and quietly expanded. Each looks minor. Together they consume budget and schedule the baseline never paid for, which is why they surface as unexplained cost and schedule variance months later.
What is the difference between a Class I and a Class II engineering change?
In defense configuration management, a Class I change affects the approved baseline in ways that matter to the customer, such as form, fit, function, interfaces, cost or schedule, and needs customer approval. A Class II change is minor, such as a documentation correction, and can usually be made by the contractor with customer concurrence on the classification. Getting the classification right early avoids both delay and unauthorized change.
What does a configuration control board do?
A configuration control board reviews proposed changes to a baseline and decides whether to approve, reject or defer them. Its members represent engineering, program management, quality, manufacturing and, where relevant, the customer. A good board looks at the full impact of each change on cost, schedule, interfaces, verification and production before approving it, and records the decision so the baseline history is traceable.
Can a program recover control after scope has already drifted?
Yes. The recovery starts by comparing the current design and work against the last approved baseline, listing every difference and tracing where it came from. Each difference is then regularized with the customer, approved internally and funded, or reversed. The schedule and earned value baseline are updated to match, so performance reporting becomes honest again and new changes go through the board from then on.
How does requirements traceability help control scope?
A traceability matrix links every requirement to its source, the design elements that satisfy it and the verification that proves it. When a new request arrives, the matrix shows immediately whether it is already in scope or a change. It also shows what a change would ripple into, which is the information a change board needs to price and schedule it honestly.
What are the 5 pillars of configuration management?
The five pillars of configuration management usually refer to the five functions defined in the EIA-649 standard and reflected in MIL-HDBK-61: configuration management planning and management, configuration identification, configuration change management, configuration status accounting, and configuration verification and audit. Together they define what is controlled, how changes are approved, how the current configuration is recorded and how the product is checked against its documentation. Set Boundaries uses these functions as the backbone of technical baseline control on aerospace and defense programs.
What are the different types of baselines?
Programs use two families of baselines. Project management baselines are the scope, schedule and cost baselines, which together form the performance measurement baseline used for earned value. Technical baselines are the functional, allocated and product baselines, which define the system requirements, the requirements allocated to each configuration item and the detailed design that production builds to. Both families have to stay aligned: a technical change that is not reflected in the scope, schedule and cost baselines is how programs drift. Set Boundaries manages both together through one change process.
What are the three baselines in project management?
The three project baselines are the scope baseline, the schedule baseline and the cost baseline. The scope baseline is the approved scope statement, work breakdown structure and WBS dictionary. The schedule baseline is the approved schedule with its start and finish dates. The cost baseline is the time-phased budget. On earned value programs, the three are integrated into the performance measurement baseline. They are different from the functional, allocated and product baselines used in systems engineering, and Set Boundaries keeps both sets synchronized when changes are approved.
Have a question that is not here? Ask Holly on a short call
