Home / Aerospace and defense program execution / Aerospace and defense program recovery
Your team is busy, capable and working long hours, and the program is still late and over budget. When that happens on an aerospace or defense development program, the first question is not how fast the team is working. It is what the team is working on, and whether the contract actually requires it. A requirements-to-work assessment answers that question directly, and it is usually the first step in a real recovery.
What is a requirements-to-work assessment?
It is a structured comparison between what the contract requires and what the program is actually doing. On one side sit the contractual requirements: the statement of work, the specifications, the flowdown clauses, the data deliverables and any approved changes. On the other sit the current design, the test plans, the open action items and the work people are charging hours to this week. The assessment maps one against the other and sorts every piece of work into a small number of categories: required, required but being done in a different way, not required, and unknown.
The output is not a report for a shelf. It is the basis for stopping work that should not be happening, finishing the work that must happen, and planning the rest with a realistic date. It also gives leadership and the customer the same factual picture of where the program stands.
What are the signs a program needs one?
The clearest sign is effort that keeps rising while progress toward the milestones the customer pays for does not. Programs that need a requirements-to-work assessment tend to show several of these at once:
- Hours charged to the program keep climbing, but the date for qualification or first article keeps moving out.
- The design has gone through more iterations than anyone can explain from the contract or the approved changes.
- Engineers can describe what the customer's engineers want, but not which paragraph of the specification requires it.
- Test plans include tests, margins or analyses that the verification requirements do not call for.
- Contracts staff learn about technical commitments after they have been made.
- Different people give different answers to a simple question: what does done look like on this program?
Any one of these can have an innocent explanation. Several together usually mean the program is doing work the contract never asked for, and the fastest way to find out is to put the requirements and the work side by side.
Why do engineering teams drift away from the contract?
Because engineers respond to engineers. During design reviews, test witness events and routine technical calls, the customer's technical organization asks questions and makes suggestions: add a margin here, run this extra test, change this interface, show this analysis another way. The contractor's engineers want the product to be good and the customer to be satisfied, so they say yes. Nobody stops to ask whether the request is a contractual requirement or whether it changes cost and schedule.
In government contracting this is a well known problem. Only a contracting officer has authority to change the contract, and technical representatives are generally not authorized to direct changes to price, quantity, quality or delivery. On commercial programs the same principle holds through the purchase order or subcontract terms. Yet informal technical direction still gets followed, a little at a time, until the product being designed is no longer the product that was bought. The team loses sight of what done means, and the schedule and budget quietly absorb the difference.
Which documents make up the contract baseline?
More than most teams expect, and the assessment is only as good as the baseline it starts from. A common failure is to build the matrix from the top-level specification alone and miss requirements that live in attachments, referenced standards or contract clauses. The first job is to gather everything that governs the work and agree which revision of each applies.
| Document | What it governs | Where drift tends to hide |
|---|---|---|
| Statement of work | The tasks the contractor must perform, reviews, meetings and support | Extra reviews, analyses or support activities that grew out of meetings rather than the statement of work |
| Product specification | Performance, interfaces, environments and verification requirements for the hardware or software | Margins and features added beyond the stated requirement, often during design reviews |
| Contract data requirements list | The data deliverables, their format and due dates, usually on DD Form 1423 for defense contracts | Reports and data delivered in more detail or more often than the list requires |
| Contract clauses and flowdowns | Quality system, configuration management, cybersecurity, export and other obligations passed down from the prime or the government | Obligations nobody tracked, which surface late as findings or rework |
| Referenced standards | Test methods, quality requirements and processes the specification calls up by reference | Using a newer or different revision than the one the contract cites |
| Approved changes and modifications | Every formal change to scope, price or schedule since award | Changes agreed informally and never formalized |
When documents disagree, the contract normally says which one wins. Federal contracts in the uniform contract format include an order of precedence clause for exactly this reason, and commercial subcontracts usually carry a similar provision. Settling precedence early keeps the assessment from turning into an argument about which document to believe.
What does a good compliance matrix look like?
The compliance matrix is the core tool. It is related to the requirements traceability matrix used in systems engineering, but it is built for a different question: not only where each requirement is satisfied, but whether the current design and activities are driven by a requirement at all.
| Column | What it records |
|---|---|
| Requirement reference | Document, revision and paragraph number, so every line traces to the contract |
| Requirement text | The requirement as written, not a paraphrase |
| Verification method | Test, analysis, inspection or demonstration, as the contract defines it |
| Current design or activity | What the program is doing today to meet it |
| Compliance status | Compliant, partially compliant, non-compliant, or not yet shown |
| Evidence | The test report, analysis or drawing that proves the status |
| Source of current approach | Contract requirement, approved change, or informal request, with who and when |
The last column is the one most matrices leave out, and it is the one that finds the drift. When a design feature or a test cannot be traced to a requirement or an approved change, it came from somewhere else, and that somewhere usually has a name and a date.
How does the assessment work?
At a summary level, the sequence is consistent from program to program:
- Establish the requirements. Collect the contract baseline, including every approved change, and agree internally which revision of each document governs.
- Determine current status. Record what has been designed, built, tested and delivered, and what the team is working on now.
- Compare the two. Build the compliance matrix and trace current design features and activities back to their source.
- Stop uncontrolled out-of-scope work. Work that is not required is paused until someone with authority decides whether it should continue and who pays for it.
- Establish a controlled path for new requests. From this point, customer technical requests are logged, assessed for cost and schedule impact and routed to the people who can accept them.
- Plan what remains. Build a detailed plan to completion, usually to qualification and the next payment milestone, from the work that is genuinely required.
- Brief the customer. Explain exactly what was found, where the program is, what remains and how it will proceed.
Set Boundaries uses more detailed internal templates for each step. The principle behind them is public and simple: separate what is required from what is being done, and make every difference visible.
How do you stop out-of-scope work without damaging the relationship?
By being direct and factual, and by not blaming anyone. Most out-of-scope work was requested in good faith by customer engineers who wanted a better product, and accepted in good faith by contractor engineers who wanted to help. Stopping it is not a refusal to help. It is a decision about who authorizes the work and who funds it.
In practice that means telling the internal team clearly which activities are paused and why, giving them a simple way to route new requests, and telling the customer the same thing in the same words. A single, controlled communication path for technical requests protects the engineers from being pulled in several directions and protects the customer from surprises. Customers generally respond well to clarity, especially when it comes with a credible plan to the milestones they care about.
What should the customer briefing cover?
The goal of the briefing is to eliminate ambiguity. It should answer three questions that everyone on the program, on both sides, should be able to answer afterwards: where are we, where are we going, and what has to happen next to get there. In practice that means presenting the compliance findings, the work that has been paused and why, the remaining work and plan to completion, the decisions needed from the customer, and how new requests will be handled from now on. Where the assessment shows that significant out-of-scope work has already been performed, the briefing is also where the program signals that it will be raised through the proper commercial channel.
How do you sort the work once it is mapped?
Into a small number of categories, each with a clear next action. The value of the assessment is not the list itself but the decision it forces on every line.
| Category | What it means | What happens next |
|---|---|---|
| Required | The work traces to a requirement or an approved change, and the approach meets it | Keep it, and make sure it sits on the plan to completion |
| Required, done differently | The work answers a real requirement, but in a way that adds cost or time the requirement does not demand | Decide whether a simpler compliant approach exists, and what switching would cost at this stage |
| Not required | No requirement or approved change supports the work | Pause it until someone with authority decides whether it continues and who pays for it |
| Unknown | Nobody can yet say where the work came from or what it satisfies | Assign an owner and a short deadline to resolve it, because unknowns tend to hide the largest surprises |
A program rarely lands entirely in one column. The usual result is a large block of required work, a meaningful block of work that is either unnecessary or over-built, and a smaller set of open questions. That mix is what turns a vague sense that the team is busy into a specific plan.
Why does configuration control matter to the assessment?
Because without it, nobody can say which version of the product a requirement was checked against. Configuration management, as described in the EIA-649 standard, covers identifying each configuration, controlling changes to it, recording the status of every change and verifying that the product matches its documentation. When those disciplines are weak, a program can build several iterations of the same assembly with no clear record of what changed between them or why.
A requirements-to-work assessment therefore looks at the configuration history as well as the current design. Each change between iterations is traced to its source, whether a requirement, an approved change or an informal request. On a troubled gearbox development program for Triumph and SAAB, Holly Dekle reviewed the product and activities against the actual requirements through a full compliance matrix, stopped the uncontrolled work and set a definitive plan to qualification. The program completed qualification testing and the development program was closed. Putting the program under disciplined technical baseline management afterwards is what keeps the same drift from coming back.
What if the customer directed the extra work?
Then it may be a change to the contract even though nobody issued a change order, and it should be handled through the proper commercial channel rather than absorbed. In government contracting, the changes clauses in the Federal Acquisition Regulation set out how the government may change the work, and many contracts also include a notification of changes clause that asks the contractor to tell the contracting officer promptly when it believes government conduct has changed the contract. Work directed informally and performed without that notice is harder to recover later.
This is one more reason to run the assessment early. It establishes, with dates and names, which work came from informal direction, and it gives contracts and legal staff what they need to decide how to raise it. The assessment does not decide entitlement, and this page is not legal advice. It produces the facts that those decisions depend on, and those facts feed directly into scope-change claims and requests for equitable adjustment where they are warranted.
What comes after the assessment?
Two things. The first is execution: the plan to completion becomes the schedule recovery plan, run by an interdisciplinary team with a weekly look-ahead and immediate attention to anything that threatens the critical path. The second is commercial: the work already performed outside the contract does not disappear. Tracing it, pricing it and presenting it is the subject of scope-change claims and requests for equitable adjustment. The compliance matrix built during the assessment is usually the backbone of that effort.
How Set Boundaries helps
A requirements-to-work assessment is the first step in most Set Boundaries program recovery engagements, and often part of an independent program assessment. We build the compliance matrix with your engineers, stop the work that should not be happening, set up the controlled path for new requests, build the plan to completion and stand beside you when it is presented to the customer. Then we stay to execute it. If your team is working hard and the program is still slipping, schedule a call.
Related guides
- Aerospace and defense program recovery
- Scope-change claims and requests for equitable adjustment
- Building a schedule recovery plan
- Technical baseline management
- Gearboxes and drive systems programs
- Case studies
References
- Federal Acquisition Regulation, Subpart 1.6, Career Development, Contracting Authority, and Responsibilities, including FAR 1.602-1 on contracting officer authority.
- Defense Federal Acquisition Regulation Supplement, 252.201-7000, Contracting Officer's Representative.
- NASA, Systems Engineering Handbook, NASA/SP-2016-6105, on requirements traceability and verification.
- INCOSE, Systems Engineering Handbook, on requirements management and traceability.
- Federal Acquisition Regulation, 52.215-8, Order of Precedence, Uniform Contract Format.
- Federal Acquisition Regulation, 52.243-1, Changes, Fixed-Price, and the related 52.243 Changes clauses.
- Federal Acquisition Regulation, 52.243-7, Notification of Changes.
- US Department of Defense, DD Form 1423, Contract Data Requirements List.
- SAE International, EIA-649, Configuration Management Standard.
Questions
Common questions
What is a requirements compliance matrix?
A compliance matrix lists every contractual requirement, with its document, revision and paragraph, and records how the current design meets it, how it will be verified, its compliance status and the evidence. In a program recovery it also records where the current approach came from: a contract requirement, an approved change or an informal customer request. That last column is what reveals work the contract never asked for.
What is the difference between a compliance matrix and a requirements traceability matrix?
A requirements traceability matrix follows each requirement down through the design to its verification, so nothing is missed. A compliance matrix used in a recovery also works in the other direction, starting from what the team is actually designing and testing and asking which requirement drives it. The first question finds gaps in compliance. The second finds work being done that no requirement or approved change supports.
Can the customer's engineers change contract requirements?
Generally not on their own. On government contracts only a contracting officer can change the contract, and technical representatives are normally not authorized to direct changes affecting price, quantity, quality or delivery. Commercial subcontracts usually reserve changes to the buyer's authorized purchasing or contracts staff. Technical requests are still valuable, but they should be logged, assessed and accepted through the proper channel before the team treats them as requirements.
What happens to out-of-scope work that was already done?
It should be documented, not forgotten. The assessment records which design changes and activities were driven by informal requests, when and by whom. That record becomes the basis for pricing the work from the company's own financial data and raising it with the customer as a change order, a request for equitable adjustment or a claim, with contracts and legal staff involved. Whether to continue the work is a separate decision.
Who should be involved in a requirements-to-work assessment?
The program manager leading it, the engineering leads who know the design, the quality and test leads who know the verification status, and contracts staff who know the contract baseline and approved changes. Department leaders need to be in the room when the results are reviewed, because stopping out-of-scope work and routing new requests changes what their people do on Monday. The customer is briefed once the facts are clear.
How do you tell the customer you are stopping work they asked for?
Directly, factually and with a plan. Explain what the assessment found, which activities are paused and why, what remains to reach the milestones the customer cares about, and how new requests will be handled from now on. Avoid blame, because most of the work was requested and accepted in good faith. Customers usually respond well when they see a controlled path for their requests and a credible route to qualification.
Have a question that is not here? Ask Holly on a short call
