Home / Aerospace and defense program execution
A program in trouble rarely has one problem. It has a schedule no one fully trusts, suppliers running late, a customer losing patience and a team working hard on the wrong things. Recovery means seeing all of that clearly, deciding what actually matters, and then running the program until it holds.
Signs a program needs recovery
- Milestones keep moving and each new date feels as uncertain as the last
- The integrated master schedule would not survive a DCMA 14-point assessment
- Earned value numbers say one thing and the program floor says another
- The customer is asking questions the program cannot answer cleanly
- Suppliers are driving the critical path and nobody is managing them as a priority
- The team is working hard and the program is still sliding
How we recover a program
1. Diagnose the real cause
Symptoms are visible to everyone. Causes usually are not. We start with the schedule, because it is the model the whole program is steering by, and test whether it is structurally sound: logic, constraints, float, durations and whether the critical path is real. Then we compare it against what is actually happening on the floor and in the supply chain.
The first thing Holly establishes is what the team is actually working on compared with what the customer is contractually requiring. The root cause she finds most often is not a lack of effort. Engineering teams keep responding to requests from the customer's technical organization without stopping to ask whether each request is a contractual requirement, or what it does to cost and schedule. Over time the team loses sight of what "done" means. Recovery starts by comparing the current design and activities against the real requirements, stopping the work that is not required, and putting new requests through a controlled path.
2. Stabilize execution
Before a program can recover, it has to stop getting worse. That means deciding what the team works on this week, putting control around changes, and getting accurate status flowing up to leadership and out to the customer.
3. Build a plan that holds
A recovery plan is only useful if the customer can check it and the team can execute it. We build it from the real constraints rather than from the date everyone wishes for, and where the evidence says the baseline cannot be met, we make that case with data.
4. Execute to it
This is where an execution firm differs from an advisory one. We stay. Our project engineers work inside the program, managing suppliers, driving technical work and tracking earned value, until the program is delivering to the new plan.
Supplier recovery
On aerospace programs the critical path often runs through a supplier. Recovering the program means recovering that supplier: understanding their constraints, agreeing a credible plan with them, and managing it as closely as internal work. Our engineers are comfortable on a supplier's floor, not only in a status meeting.
Where castings or other long-lead parts are the constraint, additive manufacturing can sometimes break the dependency entirely. Holly led the effort to replace 18-week aerospace castings with additive-manufactured hardware, and that experience informs how we look at supply-constrained programs.
What usually causes a program to need recovery?
Recoveries rarely start with one failure. The common causes, often several at once, are a schedule that was never a real network and so could not warn anyone, a baseline built on optimistic durations, requirements or scope that grew without formal change, a critical supplier that slipped quietly, key people stretched across too many programs, and reporting that softened bad news on its way up. Most of these are visible in the program's own data well before the customer notices. Part of recovery is learning to read those signals so the program is not surprised again.
What does a phased recovery look like?
| Phase | Typical duration | What happens | What you get |
|---|---|---|---|
| 1. Assess | First two to three weeks | Schedule structural checks, earned value and variance review, supplier status, interviews with the people doing the work | An honest picture of where the program really is and why |
| 2. Stabilize | Weeks three to six | Repair the schedule network, stop scope leaks, set a weekly rhythm, attack the top supplier and technical constraints | A program that stops getting worse and a schedule that can be trusted |
| 3. Replan | Around weeks four to eight | Rebuild durations with the owners, decide whether to recover within the baseline or propose a new one, agree it with the customer | A credible plan the customer has seen and accepted |
| 4. Execute and prove | From then until the program holds | Run to the new plan, report honestly, hit the next milestones as promised | Restored confidence, milestone by milestone |
The durations are typical, not promises; a large program or one with deep supplier problems takes longer, and a small one can move faster. What does not change is the order. Replanning before the schedule can be trusted only produces a more detailed version of the wrong answer.
What should the customer see during a recovery?
Early, specific and honest communication. Customers are rarely surprised that programs have problems; they are frustrated when they find out late or hear a vague story followed by a worse one. The pattern that rebuilds trust is a clear statement of what happened and its impact in days and dollars, the root cause as far as it is known, and a recovery plan with dated milestones the customer can track. Then the program hits the next milestone it promised. Our guide to program communication covers the review format in detail.
Which numbers show that a recovery is working?
| Measure | Recovering programs usually show |
|---|---|
| Baseline execution index | Trending up toward 0.95 as the team starts finishing what it plans |
| Forecast stability | The forecast finish date stops moving month to month |
| Schedule structural checks | Missing logic, constraints and invalid dates falling toward the DCMA thresholds |
| Cost and schedule performance indices | Current-period values at or above 1.0 even while cumulative values recover slowly |
| Top risks | Retiring on their burn-down dates rather than aging on the register |
| Customer actions and concerns | Fewer open, and closed faster |
What recovery is not
It is not a new schedule on its own. A redrawn Gantt chart without repaired logic and honest durations slips again. It is not blame. The cause is usually a system that let problems hide, not individuals, and treating it as blame stops people from reporting the next problem. It is not forever. The aim is a program team that can run the recovered program without outside help, and a clear point at which that happens.
What is the recovery sequence?
Every recovery Holly runs follows the same order, because each step depends on the one before it: establish the requirements, determine current status, stop uncontrolled and out-of-scope work, establish boundaries, create the recovery plan, then execute, monitor, intervene, communicate and deliver.
The first step is the one most often skipped. Before anyone replans, we compare what the team is actually working on with what the customer is contractually requiring, usually through a requirements-to-work assessment. That comparison shows what is done, what remains, and which work is being performed because someone asked for it rather than because the contract requires it. That work stops, and new customer requests go through a controlled path so each one is judged against scope, cost and schedule before anyone acts on it. Only then do we build a detailed plan to completion in an integrated Microsoft Project schedule.
The last step before execution is a conversation with your customer. We explain exactly what was found, where the program stands, what remains and how it will proceed. The aim is to remove ambiguity, for the customer and for your own team. The objective of the whole sequence is that within a few months your organization is consistently delivering on its commitments and the customer's confidence has been restored.
What do the first weeks of a recovery feel like from the inside?
Busy at first, and then calmer than the team expects. In the first days Holly talks with the department managers and with the engineers, planners and buyers doing the work, because the people closest to the hardware usually know where the program really is. Within the first weeks the team has one integrated schedule, a critical path everyone can see and an agreed list of work it is no longer doing. Customer communication is frequent at the start, sometimes almost daily, and settles into at least a weekly update. Senior leadership receives formal program status at least monthly, and more often while the program is critical.
Anything that threatens the critical path is raised immediately. Holly calls this a Critical Path Red discussion: the right stakeholders see the problem and its impact, and leadership makes an informed decision about it instead of the program quietly absorbing it. Surprises still happen on recovering programs. The difference is that they are treated as plot twists to be worked rather than emergencies, and anyone on the team can answer three questions at any point: where are we, where are we going, and what has to happen next to get there?
What has this looked like on real programs?
On a development program for a mission critical airframe mounted component, the team had been doing significant work driven by customer requests that were not necessarily contractual requirements. Holly built a full compliance matrix, compared the existing product and activities against the actual requirements, stopped the uncontrolled work and set a definitive plan to qualification. The program completed qualification testing and the development program was closed. Tracing each configuration change back to either an informal request or a contractual requirement, and costing it from the company's own financial data, also substantiated scope-change claims. Her engagement ended before the final commercial disposition of those claims. Our guide to scope-change claims covers how that is handled commercially.
At the defense display manufacturer described below, the same sequence was applied across several programs at once. Commitments became predictable and milestone payments resumed, and what remained afterward was a technical program office that helps the team execute rather than simply reporting status.
Should you recover within the baseline or ask for a new one?
Recover within the current baseline whenever the evidence says you can, and ask for a new one only when it says you cannot. A new baseline is a formal step with your customer, not a way to make variances disappear, so the decision has to rest on a schedule and estimate the customer can check.
| Option | What it means | When it fits | What to watch |
|---|---|---|---|
| Recover within the baseline | Keep the contract dates and budget, and close the gap through resequencing, added resources, scope control and supplier recovery | The critical path can still meet the contract milestones once uncontrolled work stops and the schedule is repaired | Workarounds that only move risk later, and overtime the team cannot sustain |
| Replan remaining work | Rework the plan for future work inside the existing budget and dates, without touching completed work or reported variances | The overall targets still hold but the detailed plan no longer reflects how the work will be done | Replanning in-progress or completed work, which hides history the customer relies on |
| Over target schedule | Schedule dates that run past contract milestones, set as the basis for measuring the rest of the work | The milestones cannot be met by any credible plan, but the budget is still adequate | It needs customer agreement, and it does not change the contract dates themselves |
| Over target baseline | A performance baseline whose total budget exceeds the contract budget base, so remaining work is measured against a realistic plan | The remaining budget is so far below the realistic cost that performance data has stopped meaning anything | It is formal reprogramming that needs the customer's approval, and it does not change the contract price |
Where a new baseline is the honest answer, the case is made with data: a repaired integrated master schedule, durations built with the people who own the work, and an estimate to complete that ties to the program's own cost history. Resetting cumulative variances is not something a contractor does on its own; it happens, if at all, as part of formal reprogramming the customer has agreed. Our page on EIA-748 earned value management explains how baselines and variances are meant to be controlled.
What information should be ready when a recovery starts?
The more of this a program can hand over on day one, the faster the assessment moves. None of it needs to be tidy. A messy schedule tells us as much as a clean one, and gaps in the list are findings in their own right.
- The contract and statement of work. Including modifications, the contract data requirements list and any specifications and interface documents the requirements flow from.
- The native schedule file. The working Microsoft Project file rather than a PDF, plus the baseline it is measured against and the last few status updates if they exist.
- Cost and earned value data. Recent performance reports, budgets by control account and actual cost to date, even if the program does not run a formal earned value system.
- The risk and issue registers. Whatever exists, however out of date, along with any open corrective actions.
- Supplier status. Purchase orders, promised and actual delivery dates and recent correspondence for the parts on or near the critical path. Our supplier recovery guide covers what we do with it.
- Customer correspondence. Open action items, recent review slides, technical direction letters and any formal notices about performance.
- The change history. Engineering changes, customer requests and how each one was handled, which is the raw material for a requirements-to-work assessment.
Access to people matters as much as access to files. The engineers, planners and buyers doing the work usually know where the program really stands, and the assessment depends on hearing from them directly.
When is a recovery finished?
A recovery is finished when the program is delivering on its commitments without outside help, not when a new schedule is approved. For a development program, that usually means milestone payments are being achieved again and production deliveries have started. At that point the customer decides whether continued support adds value, and if it makes sense and there is capacity, we can support the transition into production.
Production programs are different. We take on a production recovery when the problem needs significant engineering intervention, which is really a small development program inside production. Routine production management, where the issues are normal supply chain and obsolescence, is better handled by a strong internal team. If you are unsure which situation you are in, a program health check is a sensible first step, and our guide to why aerospace programs run late covers the patterns behind most slips.
What clients say
Holly is able to quickly formulate and execute detailed project plans transforming chaotic programs into predictable successes. Key to Holly's triumphs is her deep project management knowledge, work ethic and clear communication style.
Holly was always proactive in managing the team and ensuring that we stay on schedule and meet customer needs. Holly also is good to ensure we follow process and always incorporated any lessons learned from previous programs into her own.
A defense display manufacturer brought Set Boundaries in after another consulting organization had been supporting its programs. Customers were frustrated, contractual commitments were being missed and significant business was at risk. The team was responding to customer requests without knowing whether they were in scope. We compared the designs and activities against the actual requirements, brought the department leaders together, set executable plans to each major and payment milestone, and communicated almost daily at first. Within weeks the customer relationships began to change: commitments became predictable, milestone payments resumed, and the company has since won additional work.
References
- US Government Accountability Office, Schedule Assessment Guide: Best Practices for Project Schedules, GAO-16-89G.
- US Government Accountability Office, Cost Estimating and Assessment Guide, GAO-20-195G.
- SAE International and the Electronic Industries Alliance, EIA-748, Earned Value Management Systems.
- US Department of Defense, Earned Value Management System Interpretation Guide (EVMSIG).
- US Department of Defense, Over Target Baseline and Over Target Schedule Guide.
- Defense Contract Management Agency, EVMS program analysis guidance, the source of the 14-point schedule assessment.
- US Department of Defense, Integrated Program Management Data and Analysis Report (IPMDAR) data item description.
Questions
Common questions
When should a program bring in outside recovery help?
When the schedule keeps slipping despite effort, when the customer has started asking harder questions, or when the team can no longer say with confidence what will be delivered and when. Cost and schedule performance indices drifting below plan for several months are another strong signal. The earlier recovery starts, the more options remain, including recovering within the existing baseline.
What happens first in a program recovery?
An honest assessment of where the program really is, separate from where the reports say it is. That usually starts with testing the schedule itself, because a schedule that fails basic structural checks cannot be used to recover anything. We also review earned value and variance data, supplier status and open technical issues, and talk to the people doing the work, who usually know the real constraints.
Does recovery always mean re-baselining?
No. Some programs recover within the existing baseline once the real constraints are visible and managed, which is the better outcome where it is achievable. Others need a new, credible baseline, agreed with the customer through the proper change process. The assessment decides which, and the conversation with the customer is shaped by that evidence rather than by hope.
How do you restore a customer's confidence?
With a plan they can check and reporting they can trust. That means telling the customer clearly what happened and what it costs in time and money, showing a recovery plan with dated milestones, and then hitting those milestones as promised. Confidence returns when the program starts saying what it will deliver and then delivering it, month after month, without surprises.
How long does a program recovery take?
It depends on the size of the program and the depth of its problems, especially in the supply chain. As a typical pattern, assessment takes the first few weeks, stabilization and replanning follow over the next month or two, and execution continues until the program reliably hits its milestones. The goal is always a clear handover point, not an open-ended engagement.
Can recovery work if the root cause is a supplier?
Yes, and supplier problems are among the most common causes. Supplier recovery means visibility into the supplier's own schedule and constraints, direct engagement on the critical items, second sources where they are realistic, and bringing the supplier into the program's weekly rhythm. The program schedule is then updated to show the true supplier dates, so everyone plans around reality.
What does a military consultant do?
The term covers several roles: former officers advising on strategy or training, specialists supporting government acquisition offices, and firms that help defense contractors deliver hardware under contract. Set Boundaries is the last kind. On a defense program in trouble, we compare what the team is actually working on against what the contract requires, stop uncontrolled out-of-scope work, build a recovery plan to the next major and payment milestones, and keep the customer informed until commitments are predictable again. Our experience includes programs associated with the U.S. Air Force, U.S. Navy and U.S. Coast Guard, delivered through the contractors that build the equipment.
Have a question that is not here? Ask Holly on a short call
