The instinct, when a program is in trouble, is to immediately start fixing things — reassign work, renegotiate a vendor contract, push a new timeline. Almost none of that should happen in the first 30 days of a real recovery. The first month is about understanding what’s actually true, because a recovery plan built on the same assumptions that got the program into trouble in the first place will fail the same way, just more slowly.
Here’s roughly how the first 30 days actually go.
Week 1: Listen before you diagnose
The first week is spent talking to people — the sponsor, the workstream leads, the vendor delivery managers, and critically, people a few levels down who are close to the actual work but rarely get asked directly. Everyone has a theory about why the program is struggling, and those theories usually disagree with each other. That disagreement is itself useful data: it tells you the program has lost a shared understanding of its own status, which is often the real root cause underneath whatever technical or schedule problem triggered the recovery conversation.
No decisions get made in week one. The only job is to build an honest, current picture — not the picture from the last steering committee deck, but what’s actually true today.
Week 2: Separate the real problems from the symptoms
A program that’s six months late is rarely six months late because of one thing. By the second week, the pattern usually clarifies: is this a scope problem, where the program is trying to do more than it was ever resourced for? A governance problem, where decisions aren’t getting made or aren’t sticking? A vendor problem, where commercial incentives have drifted from what the program actually needs? Or a sequencing problem, where dependencies were never realistically mapped?
Most troubled programs are a combination of two or three of these. Naming them precisely — not generically — is what makes the next steps possible. “The program is behind” isn’t a diagnosis. “Governance stopped functioning as a decision-making forum in month four, and scope grew 30% without a corresponding budget conversation” is.
Week 3: Build the re-baseline, and make the trade-offs explicit
Once the real problems are named, the third week is spent building a plan grounded in the program’s actual current state — not a plan that assumes the original timeline was ever achievable given what’s now known. This is where the hardest conversations happen, because a credible re-baseline usually requires someone with executive authority to make an explicit trade-off: less scope, more time, more budget, or some combination. Recovery plans that skip this conversation and just produce a new optimistic date tend to fail exactly the same way the original plan did.
Week 4: Reset governance, and make it real
The last week of the first month is spent re-establishing how the program will actually be governed going forward — not just who attends which meeting, but what decisions get made where, how trade-offs get surfaced, and how the risk register gets used as a working tool instead of a compliance exercise. This is often the most important structural change in the entire recovery, because it’s what prevents the same drift from happening again six months later.
What changes after day 30
By the end of the first month, a recovery engagement should have produced three things: an honest, shared picture of where the program actually stands; a re-baselined plan with the trade-offs made explicit and owned; and a governance structure that can catch the next problem early instead of six months late. None of that is technical work. It’s the discipline that makes the technical work possible again.
I’ve led recovery efforts on programs ranging from a single delayed rollout to a $50M+ multi-year divestiture that closed on a strict contractual deadline with zero impact to EBITDA. If your program needs this kind of reset, take the free Program Recovery Assessment for a structured read on what’s actually broken, see how Program Recovery works, or let’s talk about where things actually stand.