Programs fail in two ways. The first is execution failure: the work is not getting done, the team is not performing, the velocity is too slow. The second is structural failure: the conditions that make execution possible have broken down.

Execution problems are visible and relatively straightforward to diagnose. Structural problems are harder to see because they hide behind execution symptoms. The team looks busy. Meetings are happening. Status reports are being written. The work is moving, just not in the right direction, at the right pace, toward the right outcome.

Bringing in more execution capacity into a structural failure does not fix the program. It makes the failure more expensive. These are the five signs.

1. Meetings end without decisions

Every program has a rhythm of recurring meetings: status calls, steering committees, risk reviews, vendor syncs. In a structurally healthy program, these meetings exist to produce decisions. In a failing program, they exist to produce updates.

The signal to look for is not whether the meetings are well-run or whether the information presented is accurate. It is whether, at the end of the meeting, anyone has committed to a decision that was not already made before the meeting started. If the answer is consistently no, the governance structure is decorative.

2. Nobody can name the actual critical path

Ask the program team what the critical path is and most people will point to the project plan. Ask them what is actually blocking delivery right now, today, and the answer is almost always different.

In programs with structural problems, the plan has lost contact with reality. Dependencies get removed because nobody wants to own them. Estimates get quietly adjusted without updating the baseline. Float gets consumed without acknowledgment.

When the people closest to the work cannot articulate a coherent critical path that matches the current state of the program, every decision being made against that plan is based on fiction.

3. The RAID log has items open for more than 30 days

A RAID log is a diagnostic tool. What is in it tells you what the team felt safe escalating. What has been sitting unresolved for weeks tells you where the program has structurally given up.

Risks and issues open for more than 30 days without resolution or escalation are not tracking failures. They are organizational failures. They mean that the escalation path does not work, that the people who own those items do not have the authority to resolve them, or that resolving them would require a conversation that nobody wants to have.

4. Scope has grown without a change record

In almost every program recovery, there is a gap between what was in scope at the start and what is in scope now. Some of that gap is legitimate and has been formally managed. Most of it has not.

Unmanaged scope growth means the program does not have effective governance over its own boundaries. Work gets added because a stakeholder asked for it, because a vendor included it in a delivery, or because the team made a reasonable judgment call without the authority or process to formalize it.

When you ask the team why the schedule has slipped and the answer involves work that is not in the original plan, that is a structural problem. The change control process either does not exist or is not being followed.

5. The sponsor is surprised by bad news

Executive sponsors should not be surprised by the state of their programs. If a sponsor is hearing for the first time in a steering committee that a milestone was missed three weeks ago, the reporting structure has failed.

This happens for understandable reasons. Teams under pressure optimize their reporting for approval, not accuracy. Bad news gets softened, delayed, or framed in ways that make it easier to absorb. By the time the severity makes it through the reporting layers, months have passed and the options available to the sponsor have narrowed significantly.

---

These five signs share a common thread. They are all symptoms of a program where the structure that should be making execution possible has broken down. The execution problems that show up on top of them are real, but fixing execution without fixing structure is like clearing the symptoms without treating the condition.

The diagnosis has to come first.

When a program is in trouble, the first instinct is usually to find a better project manager. Someone more organized. Someone who will actually keep the tracker updated and run the weekly status meeting on time.

That instinct is wrong. Not because project management does not matter, but because a program in crisis does not have a project management problem. It has a structural problem. And structural problems do not get solved by better tracking.

What a project manager does

A project manager manages the execution of a defined plan. They track tasks, manage dependencies, run cadence meetings, escalate issues through established channels, and report progress against the baseline. They are the connective tissue of a running program. When things are working, they keep them working.

Good project managers are essential. They are also not equipped, and should not be expected, to step into a program where the plan is wrong, the governance is broken, the sponsor is misaligned, and the team has stopped trusting the outputs.

What a program recovery lead does

A recovery lead steps in when the conditions that make normal execution possible have broken down. Their first job is not to manage the program. It is to diagnose what broke and reset the conditions that allow the program to function.

In practice, that means a few things that fall well outside normal project management scope.

The first is forensic assessment. A recovery lead reads the history of the program, not just the current state. They look at where estimates changed, where dependencies were quietly removed from the plan, where status reports started using language that obscured what was actually happening.

The second is organizational intervention. Decision authority in a failing program is almost always fragmented or absent. The recovery lead identifies who actually has the authority to make which decisions, establishes clear ownership, and builds a governance structure that produces decisions instead of updates.

The third is stakeholder alignment, specifically with the executive sponsor. In most program recoveries, the sponsor has been receiving reports that understated the severity of the situation. The recovery lead has to deliver a clear and accurate picture of where things actually stand, what decisions are required, and what happens if those decisions are not made. That requires credibility, directness, and a willingness to make an executive uncomfortable.

None of that is project management.

Why the confusion persists

Programs are run by project managers. When a program fails, the natural response is to replace or reinforce the project management function. The framing assumes that the problem is in the execution layer, and execution is what project managers manage.

But most programs that fail have not failed because of poor task tracking or missed status meetings. They have failed because decision authority collapsed, because the critical path was displaced by political convenience, because the sponsor was not told the truth about the schedule, or because nobody owned the cross-vendor dependencies that were quietly blocking everything.

Those are structural failures. They show up in the execution layer, which is why they look like project management problems. But fixing them requires someone operating at a different level, with a different mandate.

The question to ask

If you are trying to figure out whether you need a project manager or a recovery lead, the question is not whether the program is being managed well. The question is whether the program has the structural conditions that make good management possible.

If the answer is yes, a strong project manager is the right intervention.

If decision authority is unclear, if the critical path does not reflect reality, if the sponsor is not aligned to the actual situation, if the reporting has been optimized for optics rather than accuracy, then what the program needs is not better management. It needs the structure reset.

Most programs that fail do not fail because of bad execution. They fail because nobody is willing to say out loud what everyone already knows.

By the time a recovery lead steps in, the situation has usually been visible for months. The status reports have been green. The steering committee has been receiving updates. The team has been busy. And the deadline has been quietly moving.

The first 30 days of a recovery engagement are not about fixing the program. They are about creating the conditions under which the program can be fixed. That distinction sounds subtle. It is not. Get it wrong and you spend 30 days optimizing a structure that was never going to work.

Here is what actually derails recovery in the first month.

The assessment is treated as a formality

Every recovery starts with an assessment. In most cases, that assessment is a series of interviews and a slide deck that confirms what the sponsor already suspects. It is polite. It is thorough. And it almost never surfaces the real problem.

A real assessment is forensic, not diplomatic. It means reading the last six months of status reports and identifying where the language changed. It means pulling the RAID log and looking at what has been open for more than 30 days without resolution. It means asking the technical leads, not the program leads, where the actual blockers are.

If you skip it or soften it, you build the recovery on the wrong foundation.

Decision authority is assumed, not established

Programs in crisis almost always have the same structural problem: nobody knows who can make which decisions. There is a steering committee, a sponsor, a program lead, vendor leads, and a chain of escalation that has never been tested. When a decision needs to be made, it goes into a meeting. The meeting produces an action item. The action item goes into the tracker. The tracker gets reviewed at the next meeting.

Nothing moves.

The second thing a recovery engagement has to do, before anything else, is anchor decision authority explicitly. For every open issue, there is one person who owns the decision. Not a committee. Not a workstream. One person, with a name, and a date by which the decision gets made.

This sounds simple. It is almost always politically uncomfortable. The people who have been running the program are not excited about having their authority clarified. That discomfort is exactly why it has to happen in the first week, not the third.

The critical path gets rebuilt from the plan, not from reality

Every delayed program has a plan. The plan has a critical path. The critical path is almost certainly wrong.

Not because the people who built it were incompetent. Because the plan was built to get approved, not to reflect reality. Optimistic estimates made it through. Dependencies that nobody wanted to own got removed. Float got consumed months ago and nobody updated the baseline.

Rebuilding the critical path from the plan is a trap. You end up with a recovery schedule that is based on a fiction. Rebuilding it from reality, from the actual state of the work, the actual blockers, and the actual capacity of the team, takes longer and produces numbers that are harder to present to executives. It also produces numbers that are accurate.

If the honest schedule shows that the deadline cannot be met, that is information the sponsor needs to have in week one, not week eight.

The governance reset gets delayed

Once the assessment is done and the critical path is rebuilt, there is usually a moment of hesitation before the governance reset. The existing meeting structure is still running. The existing reporting cadence is still producing its weekly update. The recovery lead does not want to disrupt a team that is already under pressure.

This hesitation is expensive.

Every week that the old governance structure keeps running is a week of decisions not being made, escalations not happening, and the program continuing to operate on the same patterns that created the crisis. The governance reset has to happen in the first two weeks. Not after the assessment is presented. Not after the sponsor approves the recovery plan. In the first two weeks.

The sponsor is managed instead of aligned

The most common mistake in the first 30 days is treating the executive sponsor as an audience rather than a decision-maker.

Real sponsor alignment means one conversation, early, that covers four things: where the program actually is versus where it was reported to be, what decisions the sponsor needs to make in the next 30 days, what the recovery trajectory looks like, and what happens if those decisions are not made on time.

That conversation is uncomfortable. It involves telling an executive that the program they were told was on track is not on track. It involves asking for commitments, not just approval.

Programs that drag on are almost always programs where the sponsor was protected from the truth for too long.

---

Recovery is not a project management problem. It is a structural and organizational problem that requires someone willing to say what needs to be said, establish what needs to be established, and move at a pace that feels uncomfortable to everyone who has been moving slowly for months.

The first 30 days set the trajectory for everything that follows.

The difference between a delayed program and a dead one is not the number of weeks lost. It is whether the conditions to recover it still exist.

A delayed program has an execution problem. Capacity is missing, there is a technical blocker, a dependency that did not arrive on time. The plan is still valid. The structure still functions. With the right intervention, the program can stabilize.

A dead program is something else. The conditions that would make recovery possible are gone. And the most dangerous thing about a dead program is that from the outside it still looks like a delayed one.

How the fiction is built

The program does not die all at once. It dies slowly, while everyone keeps reporting.

It starts with an optimistic estimate that nobody wanted to challenge at approval. Then a dependency slips and gets absorbed without updating the baseline. Then another. The team starts working against a plan they know is unrealistic, but nobody says so because saying it has a cost and staying quiet does not. Not yet.

The status reports become more careful. The language shifts. "In progress" replaces "completed." "Pending validation" replaces "blocked." The dashboard stays yellow even though everyone knows it should be red.

The sponsor receives updates. The steering committee approves the next cycle. And the program keeps consuming budget, capacity, and time while the gap between what is being reported and what is actually happening grows a little wider every week.

By the time the situation becomes impossible to conceal, the program has been dead for months. It just had not been said out loud.

The four signs of clinical death

It is not the delay that kills a program. It is the combination of conditions that make the delay unrecoverable. When all four coexist, what the program needs is not a recovery plan. It needs a different decision.

The deadline is non-negotiable but also not real. There is a date in the plan. There are contractual, regulatory, or commercial commitments tied to that date. And there is an honest schedule that shows that date cannot be met under any reasonable configuration of resources and scope. When all three elements coexist and nobody puts them in the same conversation, the program is operating on a fiction that everyone knows and nobody names.

The team has stopped believing in the plan. There is a difference between a team working against a difficult plan and a team working despite a plan they no longer trust. The second produces movement without direction. People do their part, solve what is in front of them, but nobody acts as if the final outcome is achievable. When you ask the technical leads, privately, whether they believe the program will deliver, and the answer is silence or evasion, you already have your answer.

The sponsor is making decisions based on information they know is false. This is the hardest point of no return to admit. It is not that the sponsor is uninformed. It is that at some point, consciously or not, they decided not to push too hard because the answers they would get would be uncomfortable. The report arrives, gets read, gets approved. And everyone continues. When the sponsor stops asking hard questions not because the answers are good but because they no longer want to hear them, governance has stopped functioning.

Nobody can name an alternative path. In a delayed program, when you ask what it would take to recover the date, there are answers. More resources. Reduced scope. Extended timeline. The options may be costly or unpopular, but they exist. In a dead program, when you ask that question, the answer is silence, or a list of conditions that everyone knows will not be met. The solution space has closed. What remains is managing the appearance of progress.

What the executive needs to do

The first instinct when a program is in trouble is to ask for more information. Another report. A schedule review. An update session with the team.

That does not help. If the program is dead, more information from the same system that produced the fiction only produces more fiction in greater detail.

What the executive needs to do is change the question. Not "how are we doing?" but "what would have to be true for this program to deliver what it promised on the agreed date?" And then listen carefully to whether the answers describe real conditions or hypothetical ones that nobody is going to create.

The second question is harder: "What are we losing every week we keep funding this?" Not in abstract terms. In concrete ones. Capacity that is not available for other initiatives. Budget consumed without producing value. Options that close while the program stays alive.

An executive who asks those two questions and listens to the answers honestly has everything they need to make a decision. The problem is not lack of information. It is the willingness to act on what the information says.

What the program manager needs to say

The program manager almost always knows first. They see the real numbers. They know the state of the dependencies. They talk to the technical leads. They know the plan is not going to work.

And they do not say so. Not out of dishonesty, but because the incentive system punishes bad news and rewards expectation management. The person who reports the problem becomes the problem. The person who keeps the dashboard yellow stays part of the team.

Saying it has a real cost. It may end the project, or end the role of the person who says it. That cost is genuine and should not be minimized.

But there is a larger cost in not saying it. Every week the dead program keeps operating as if it were alive consumes resources that could be elsewhere, closes options that will not be available later, and builds a narrative that will collapse at some point regardless, but under worse conditions.

When the program manager finally says what they know, two things almost always happen. First, relief. The team already knew. The sponsor at some level already knew. Naming the reality does not create it, it only makes it possible to work with it. Second, the conversation that should have happened weeks or months earlier finally takes place.

It does not always end well for the person who says it. But it almost always ends better than waiting.

The dead program is not the failure

Closing a program is a hard decision. It means acknowledging that the resources invested are not going to produce the expected outcome. It means uncomfortable conversations with sponsors, clients, teams.

But a dead program that gets closed in time frees capacity, clarifies priorities, and allows the organization to make decisions about what to do with what has already been built. That has value.

A dead program that keeps operating has none. It consumes without producing, erodes the credibility of everyone involved, and makes every week the conversation that inevitably has to happen harder to have.

The sign of an organization that knows how to execute is not that its programs never die. It is that when they do, someone says it out loud as early as possible, and the organization acts on that information instead of continuing to fund the fiction.

---

A dead program is not a failure. It is information. The failure is continuing to fund it as if it were not.