They hand it over on a Tuesday, usually with a sentence that sounds calmer than the situation: the project just needs fresh eyes. Then you open the folder. The plan is 6 weeks stale, 3 workstreams are behind, the vendor has stopped replying to the last PM's emails, and the sponsor wants a recovery plan by Friday.
So you do what any competent person does with 40 visible problems: rebuild the plan, chase the vendor, run a session on the testing backlog, clean up the RAID log. It feels like control, and from outside it looks like movement for about 10 days.
Then week 3 arrives and the status is still red. None of it was the thing.
The Shift
What actually makes a project red?
A project goes red because one constraint stopped moving, and most of the red list is the wake behind it.
The list you inherit has 40 items and no ranking, sorted mainly by who complained loudest. Three workstreams are behind because all 3 need the same integration environment. The environment is not built because its budget line needs a call from someone 2 levels up, and that call has been open since April. The vendor silence, the stale plan, the testing backlog: all real, all downstream.
A red project is usually a project organized around a decision nobody has made. The longer that decision sits, the more work stacks up in front of it, until the stack looks like the problem.
Issue 06 called dependency load the fourth side of the iron triangle. On a project you inherit, that is usually where the constraint is hiding.
So the first 2 weeks have one job: find the item everything else is waiting behind, and prove it before you touch anything.
The System
What should you do in the first two weeks after taking over a troubled project?
Spend the 14 days proving what is actually red, then change one thing. Five moves, in order.
Days 1 to 3. Collect, do not repair. Talk to 6 or 7 people one at a time; a group meeting produces the official story, and individuals give you the real one. Ask 2 questions: what are you waiting on, and who owes it to you. What they are working on is already in the status report; what they are waiting on is not. Then read the last 6 status reports oldest first and mark the week green turned amber. Whatever changed that week is usually still there.
Days 4 to 6. Build the waiting map. One row per open item: what it is, who owes it, how long it has been open, and what is queued behind it. The row with the longest wait and the deepest queue is your candidate constraint. Most red projects have 1, some have 2. If you count 5, the constraint is the decision forum itself, which is a different conversation with a different person.
Days 7 to 9. Test the candidate. Take that one item and try to close it inside a week: force the decision, escalate it, buy it, whatever it needs. If closing it frees 3 other things, you found it. If everything stays stuck, take the next row on the map. Most recovery plans skip this step, and it is the one that turns a theory into evidence.
Days 10 to 12. Take one decision up, once. The sponsor gets the constraint, what the wait costs per week, the call you need, the date you need it by, and what happens by default if nothing comes back. Leave the 40-item list at your desk. Issue 05 has the format; a recovery conversation carrying 40 items turns back into a status meeting, and the call goes unmade again.
Days 13 to 14. Reset the cadence around the constraint. One weekly review with the constraint at the top, its queue underneath, and the date it clears. The status report changes from a list of activity to the state of the one thing and what moved behind it.
About the recovery plan the sponsor wants by Friday: hand over one page with what you know, what you are testing, and the date the real plan lands. A plan written on day 4 is a guess, and everyone in the room will treat it as a commitment.
The Asset
The asset for this issue is the Project Recovery Plan.
It is the 14 days laid out day by day: the 2 questions for the individual conversations, a blank waiting map and a worked example, the constraint test with its pass and fail conditions, the day 10 sponsor note, and the cadence reset. Built to be run in order by a PM who started this week.
You'll find the download button in The Move section below.
The AI Assist
Status reports are where the waiting hides, and reading 6 of them for pattern rather than content is slow, dull work. That hands off well.
Use this prompt with the last 4 to 6 status reports, plus any meeting notes you have:
I have taken over a project in trouble. Below are its recent status reports and meeting notes.
Extract every item described as blocked, at risk, waiting, delayed, or pending. For each one: what it is, what it is waiting on, who owes it according to the text, and the earliest report it appears in.
Then group the items waiting on the same thing, rank the groups by how many items are queued behind them, and mark any item that is itself waiting on another item in the list.
Write NO OWNER wherever the text names nobody. Do not invent owners, dates, or dependencies that are not in the text.
Reports and notes: [paste here]
The output is a first draft of your waiting map, and the days 1 to 3 conversations are where you find out which of it is true. Status reports round up: the item quietly open since April tends to read as "in progress, monitoring" in all 6 of them.
The Move
Take the project you are on right now, red or not, and build the waiting map from your last 3 status reports. If you cannot say what each open item is waiting on and who owes it, you have found the work of your first 2 weeks.
The Project Recovery Plan is free for Execution Signal subscribers. Enter your email and it lands in your inbox instantly, together with the Starter Pack.
Reply prompt: when you took over a project in trouble, what turned out to be actually red once you got underneath the list?
P.S. New here? Subscribe free and the Execution Signal Starter Pack lands in your inbox: get the Starter Pack.