Home / Aerospace and defense program execution / Aerospace and defense program recovery
When a program is late, everyone wants a new date. The date is the last thing to decide. A recovery plan that holds starts with an honest picture of where the program is, finds why it slipped, weighs the real options for recovering time, and only then commits to a date the program can defend in front of its customer.
Why do most recovery plans fail?
Because they are built on the same schedule that failed to warn anyone in the first place. A late program often has a schedule with missing logic, pinned dates and optimistic durations. Redrawing it with a later finish, without repairing those problems, produces a more detailed version of the wrong answer, and the program slips again a few months later. The second slip is far more damaging than the first, because the customer has now been let down twice. A credible recovery plan repairs the schedule before it relies on it.
What are the steps in building a recovery plan?
- Establish the true status. Update the schedule honestly against a fixed status date: actual dates, real remaining durations, no forecasts in the past.
- Repair the network. Fix missing logic, remove artificial constraints and break up tasks too long to status, using the DCMA 14-point checks as the test.
- Find the root causes. Separate symptoms from causes: a late test is a symptom, a supplier that never had capacity is a cause.
- Identify the driving path. Confirm what really drives the finish date now, and the near-critical paths close behind it.
- Develop recovery options. For each driver, list the realistic ways to recover time, with their cost and risk.
- Choose and plan the actions. Build the chosen actions into the schedule as real tasks with owners and dates.
- Test the result. Run structural checks and, ideally, a schedule risk analysis on the recovered schedule.
- Agree it. Internally first, then with the customer, with any baseline change going through formal change control.
Which recovery levers actually work?
| Lever | When it works | The catch |
|---|---|---|
| Resequencing | Work was planned in series that can safely run in parallel | Increases the chance of rework if assumptions change |
| Adding people to critical work | The work divides cleanly and skilled people are available now | New people slow the team at first; adding them late can make things worse |
| Extended hours or extra shifts | A short, defined push with facilities available | Productivity and quality fall if it lasts too long |
| Supplier acceleration | The supplier has recoverable capacity, often with expediting or partial deliveries | Costs money and depends on the supplier's own constraints |
| Removing waiting time | Reviews, approvals and handoffs are adding days between tasks | Needs decision makers to commit to faster turnaround |
| Scope deferral | The customer can accept some capability later | Needs formal agreement and usually a contract change |
| Alternative sources or processes | A long-lead item can be made another way, such as additive manufacturing for a casting | Requires qualification, which takes its own time |
How do you choose between options?
By their effect on the driving path, their cost, and how confident you can be that they work. An option that saves six weeks on a path with two months of float saves nothing. An option that saves two weeks on the critical path, at modest cost, with high confidence, is worth more than a larger but speculative saving. Laying the options out side by side, with the days saved on the driving path, the cost and the risk for each, makes the decision transparent and gives the customer a clear reason to support it.
What should the plan show the customer?
The customer needs five things: an honest statement of the current position and the impact, the root causes, the actions being taken, the recovery date with the confidence behind it, and near-term milestones that will show whether the plan is working. Presenting the plan with early, checkable milestones is deliberate. When the program hits the first two or three exactly as promised, the customer starts to believe the rest.
Which numbers show the recovery is on track?
| Measure | What good looks like |
|---|---|
| Recovery milestones hit | Early milestones achieved on the dates promised |
| Forecast finish date stability | Stops moving from one status period to the next |
| Baseline execution index against the recovery plan | Close to 1.0 as the team finishes what it planned |
| Critical path float | Holding or growing, not eroding each week |
| Recovery actions overdue | Few, and closed quickly |
What should the recovery plan document contain?
- The current position: status date, forecast finish, variance to the baseline and to contract milestones
- Root causes, separated from symptoms, with the evidence for each
- The driving and near-critical paths after the schedule repair
- Options considered, with days saved, cost and risk for each
- The chosen actions with owners and dates, and where they sit in the schedule
- The recovery forecast and its confidence, ideally from a schedule risk analysis
- Near-term milestones that will show whether the plan is working
- Any baseline or contract changes requested, and their justification
How long does a recovery plan take to build?
For most programs, a credible first version takes a few weeks: time to update the schedule honestly, repair its structure, understand the causes and work the options through with the people who own the work. Pressure to produce a date in days is common and understandable, but a date produced before the schedule can be trusted is usually wrong. A useful compromise is to give the customer a clear timeline for when the recovery plan will be ready, and meet it.
We do not give a customer a new date until we know what "done" means. The sequence is to establish the requirements, determine the real status, stop uncontrolled and out-of-scope work, set the boundaries, and then build a detailed plan to completion. Then we meet the customer and explain exactly what we found, where the program is, what remains and how we will proceed. The lever that works best is often stopping unnecessary work, which frees the team faster than adding people. Sometimes the better lever is time: solving a different customer need first can legitimately move a milestone to where the team can meet it.
Where does the time usually go on a late program?
Into a small number of causes that show up as many different symptoms. A recovery plan that treats each symptom separately ends up with dozens of actions and no real change to the finish date. Tracing each symptom back to its cause, and checking the cause against evidence, usually shrinks the problem to three or four things the program can actually fix.
| Symptom the team reports | Cause it often traces to | Evidence to check |
|---|---|---|
| Engineering is always behind | The team is doing work the contract does not require, often in response to informal customer requests | Compare open engineering tasks against the contract requirements and the statement of work |
| Tests keep slipping | Hardware, test articles or facilities were never ready on the planned date | Test readiness dates against part and fixture deliveries in the schedule |
| A supplier is late | The order was placed late, the supplier never had capacity, or the part kept changing | Purchase order dates, supplier commitments and the change history for the part |
| Reviews and approvals take too long | No one owns the decision, or the review was never planned as a task | Time between task finish and approval in the schedule history |
| Rework after test or inspection | Requirements were unclear or the design baseline was not controlled | Change records and the number of configurations built |
| The forecast moves every month | The schedule itself cannot be trusted: missing logic, pinned dates, optimistic durations | A structural check such as the DCMA 14-point assessment |
The last row matters most. If the schedule fails structural checks, every other number in the recovery plan is built on sand, so the repair comes first.
Why does scope control come before a new date?
Because a program cannot recover while the amount of work keeps growing. A pattern that repeats on troubled programs is an engineering team answering requests from the customer's technical staff without asking whether each request is a contractual requirement, or what it does to cost and schedule. The work feels productive, but the team slowly loses sight of what "done" means, and no new date can hold while that continues.
The fix is to compare what the team is actually working on against what the contract requires, stop the work that is out of scope, and set up one controlled path for new requests so each is assessed for cost and schedule before anyone starts it. Out-of-scope requests are not refused; they are priced and decided, so the customer chooses with full information. On a troubled development program, Holly Dekle built a full compliance matrix, compared the existing product and activities against the actual requirements, stopped the uncontrolled work and developed a definitive plan to qualification. The program completed qualification testing and the development program was closed.
When does a recovery plan need a schedule risk analysis?
Whenever the recovery date will be shared with a customer or tied to money. A single forecast date from the schedule assumes every remaining task finishes exactly on its planned duration, which almost never happens on a program that has already slipped. A schedule risk analysis gives each key duration a realistic range, simulates the schedule many times, and shows how likely the program is to meet any given date.
The GAO Schedule Assessment Guide lists conducting a schedule risk analysis as one of its ten best practices for a reliable schedule, alongside capturing all activities, sequencing them with logic and maintaining a baseline. For a recovery plan, the output answers the question the customer will ask: how confident are you? A plan that shows, for example, the date the program has a high probability of meeting, the main risks driving the spread, and the actions that reduce them is far easier to support than a single date offered with hope. The analysis is only as good as the schedule it runs on, which is another reason to repair the network before running it.
What changes when the contract requires earned value?
The baseline becomes a controlled record, and how you recover against it matters. Under an earned value management system that follows EIA-748, the performance measurement baseline is changed only through a disciplined process, and the history of each change must stay traceable. That rules out quietly moving the baseline to match the new forecast.
| Approach | What it means | When it fits |
|---|---|---|
| Forecast against the existing baseline | The baseline stays, variances keep showing, and the recovery appears in the forecast and estimate at completion | Most recoveries, especially when the slip can be largely recovered |
| Authorized baseline change | Scope, schedule or budget is revised through the contract's change process, for example when the customer adds or removes scope | Real changes to the work, agreed and documented |
| Over target baseline or over target schedule | A formal reset when the remaining budget or schedule is no longer achievable, so measurement becomes meaningful again | Rare, serious cases, handled with the customer under DoD guidance for over target baselines and schedules |
Choosing the wrong path creates its own problems. Forecasting against a baseline that is hopelessly out of reach makes every report meaningless, while resetting too early hides the real performance. The recovery plan should state which path it follows and why. For more on how the schedule and the earned value data fit together, see our guide to Microsoft Project scheduling for defense programs.
How does Set Boundaries help?
Set Boundaries builds recovery plans from the inside: updating and repairing the schedule, working out the root causes with the program team, developing and costing the options, and presenting a plan the customer can check. Then we stay to run it, because a plan without execution is just another schedule. It is the core of our program recovery work, often alongside supplier recovery when the slip starts in the supply chain.
If your program needs a date it can actually keep, schedule a call.
Related guides
- Aerospace and defense program recovery
- The DCMA 14-point schedule assessment
- Microsoft Project scheduling for defense programs
- Risk and opportunity management
References
- US Government Accountability Office, Schedule Assessment Guide, GAO-16-89G.
- Defense Contract Management Agency, EVMS program analysis guidance and the 14-point schedule assessment.
- National Defense Industrial Association, Integrated Program Management Division, Planning and Scheduling Excellence Guide (PASEG).
- Project Management Institute, Practice Standard for Scheduling.
- SAE International and the Electronic Industries Alliance, EIA-748, Earned Value Management Systems.
- US Department of Defense, Over Target Baseline and Over Target Schedule Guide.
Questions
Common questions
What is a schedule recovery plan?
A schedule recovery plan is a structured plan to bring a late program back to a date the program can actually meet. It sets out the true current position, the root causes of the slip, the options considered for recovering time, the chosen actions with owners and dates, and the forecast those actions support. It is agreed internally and, where the contract requires it, with the customer.
What are the main ways to recover schedule?
The common levers are resequencing work so more of it runs in parallel, adding resources to critical path tasks where more people genuinely shorten the work, working extended hours for a limited period, removing or deferring scope with the customer's agreement, accelerating supplier deliveries, and removing waiting time such as slow reviews and approvals. Each has a cost and a risk, so the plan should show why each chosen lever is realistic.
Should a recovery plan become the new baseline?
Only if the program cannot realistically recover to its existing baseline and the change is authorized through the contract's change process. Many recoveries run as a forecast against the existing baseline, which keeps performance measurement honest. When a new baseline is justified, it should be built with the same rigor as the original, agreed with the customer and documented so the history remains traceable.
How do you know a recovery plan is credible?
It is built on a schedule that passes structural checks, uses durations estimated by the people doing the work, shows the critical path clearly, and includes explicit margin rather than hidden optimism. A schedule risk analysis showing a reasonable probability of meeting the recovery date is strong evidence. A plan that only works if every task goes perfectly is not a recovery plan.
What is schedule compression?
Schedule compression means shortening the remaining duration without changing scope. The two classic methods are crashing, adding resources to critical activities to finish them faster, and fast tracking, overlapping activities that were planned in sequence. Both add cost or risk: crashing costs money and can reduce efficiency, while fast tracking increases the chance of rework, so each should be applied only where the benefit clearly outweighs it.
How often should recovery progress be reported?
Weekly inside the program and at least monthly to the customer, using the same data each time. The weekly review focuses on the critical and near-critical paths, the recovery actions due and any new risks. Reporting milestones as they are achieved, exactly as the plan promised, is what rebuilds the customer's confidence, so the plan should include near-term milestones that show progress early.
What are some ideas for a recovery plan?
Common ideas for recovering schedule include running tasks in parallel that were planned in sequence, adding people or shifts to critical work, removing or deferring scope with customer agreement, expediting long lead parts, qualifying a second source, and simplifying test or review steps where the risk is acceptable. Each option has a cost or a risk, and only options that shorten the true critical path actually recover time. Set Boundaries weighs these options against a repaired schedule, so the program commits only to recovery actions that change the finish date.
How do you write a recovery plan?
Write a recovery plan by first establishing true status, then finding why the program slipped, then testing recovery options in the schedule, and only then committing to a new date. The written plan should state the cause of the slip, the chosen recovery actions with owners and dates, the resulting forecast, the key risks to that forecast, and how progress will be reported. Keep it short enough that the team uses it weekly. Set Boundaries builds recovery plans on a repaired schedule so the date in the document is one the program can defend.
Have a question that is not here? Ask Holly on a short call
