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.
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.
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.
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.
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
