The takeover: your first two weeks on someone else’s failing project

The first instinct is to relaunch it. The right first move is to read it.

The handover meeting is on your calendar. The invite says “transition.” It’s 40 minutes.

The departing PM shares their screen. Forty tabs. A Confluence space last touched in spring. A board with three status columns nobody seems to agree on. They talk fast, the way people talk when they’re already gone. “Any questions?” You have four hundred. You ask two. The meeting ends on time.

An hour later, the sponsor sends you the entire strategy in one line: “Just stabilize it.”

Here’s the translation, because that sentence is doing a lot of work. “Just stabilize it” means: make the surprises stop. The sponsor can live with bad news. What they can’t live with is a project that tells a different story every week. So for the next two weeks, your job isn’t to save anything. It’s to make this project predictable again.

Which is why the first instinct almost everyone has is the wrong one.

Don’t relaunch. Read.

The first instinct on a failing project is to relaunch it. New plan, new board, new cadence, a kickoff deck with the word “reset” in the title. It feels decisive. It photographs well.

It’s also how you inherit the failure instead of the project.

Relaunch before you understand the failure and you’re building plan two on the same ground that swallowed plan one. Whatever killed the first plan is still down there: the dependency nobody owned, the stakeholder who approves things twice, the estimate that was always a wish. And the team, who watched the last plan die, watches you print a new one and quietly concludes: this one doesn’t want to know either.

A failing project doesn’t need a new plan first. It needs a reader.

Find the week the stories split

Start with the last eight status reports. Then pull up what actually happened: the board, the release dates that moved, the tickets that aged. You’re not reading for information. You’re reading for the gap. Call it the divergence audit. It’s the highest-value work you’ll do all month, because it rebuilds the one thing this project has lost: a single true story of where it actually is.

Somewhere in those eight weeks, the two stories split. The reports kept saying on track while the board started saying something else. Find that week. Not roughly. Exactly.

On one takeover, the reports had been green for six straight weeks. The board disagreed from week three: the same integration epic sliding sprint to sprint, UAT dates walking backward, a vendor ticket open for almost a month with no movement. Week three was also the week the client’s test environment went down. The report that week called it “minor environment issues.” Every report after it was a patch on that sentence.

That’s how status reports fail. They don’t lie all at once. They drift. One optimistic sentence survives review, gets quoted upward, and becomes load-bearing. After that, an honest update would mean admitting the earlier ones weren’t. So the gap grows.

Here’s the uncomfortable truth: the project didn’t start failing when you got the call. It started failing the week the stories split, and everyone below the reporting line knew.

So dig there. What happened that week? What got renamed instead of reported? Who went quiet? That week holds the real problem. Most of what came after is symptom.

Triage is three questions, not a spreadsheet

You don’t have time for a full audit, and you don’t need one. Week-one triage is three questions.

• What breaks first? The nearest hard edge: a contract date, a compliance deadline, an integration freeze, a demo somebody senior already announced. That’s your clock.

• Who is waiting on us? Every team, vendor, and customer blocked by this project is out there shaping its reputation. That list is also where the next escalation comes from.

• What is irreversible? Money about to be spent, people about to be released, data about to be migrated, contracts about to be signed. Anything you can’t undo gets decided slowly. Everything else can wait a week.

Three questions, one page, two days. If a problem doesn’t touch one of those three, it isn’t a week-one problem.

Credibility has a one-week window

While you’re reading the project, the team is reading you. You get about a week before their opinion sets. Three moves fill it.

Fix one small visible thing

Not the architecture. Not the roadmap. Something the team trips over daily: the standup that takes forty minutes, the board with six statuses nobody uses, the meeting that exists because it always has. Pick one, fix it, skip the speech. Small proof beats big promises, and right now the team has no reason to trust your promises.

Send one honest message up

Three parts. What I know so far. What I don’t know yet. The date I’ll know it. No diagnosis you can’t back, no confidence you haven’t earned. Mine tend to read like this: the reported plan and the delivery data stopped matching around week three. I’m auditing the gap now. You’ll have a re-baselined plan with a recommendation by the twelfth. That’s the whole message.

It feels thin to send. It lands as the first update in months without spin on it, and it buys you the second week you need.

Run one listening round down

Sit with each person, or each pair, and ask the question that matters: what did you stop saying out loud here, and why? The team knew this project was failing before anyone above them did. They always do. Somewhere along the line, they learned that saying it changed nothing, or cost something.

Don’t defend anything you hear, and don’t explain what you’d have done differently. Write it down. The first person who gets corrected mid-answer is the last person who answers honestly. Their answers hand you two things: the real risk list, and a map of exactly where the last system went deaf.

The predecessor rule

In every one of those conversations, you’ll be tempted to spend the previous PM. It’s the cheapest credibility on the market: no wonder it’s failing, look at this mess.

Don’t. Not directly, not obliquely, not as a joke.

Partly because it’s usually unfair. You’re seeing their decisions without their constraints, and some of this mess was the org, not the person. But mostly because of what it signals. The team is watching how you talk about the person who left, and they hear it as a preview of how you’ll talk about them. Trash the predecessor and everyone in the room updates the same rule: nothing I admit to this person is safe.

“The plan didn’t survive contact with reality, and here’s what we’re changing” gets you everything blame would. Without the tax.

Week two: re-baseline from evidence, not blame

By the middle of week two, you know enough. Now you do the thing the last plan never got: an honest reset, in one conversation.

The move is separating two numbers that have been fused for months: what was promised, and what is possible. Promised is a fact about the past. Possible is a claim about the future, and you now have evidence for it: the split week, the triage page, the things the team finally said out loud. Walk the sponsor from one number to the other. In practice it’s a short deck: where we really are and how I know, three options with costs, the one I recommend, and what I need from you to do it. No blame anywhere in it.

There are two ways to blow this meeting. The obvious one is flinching: shaving the bad news to soften the room, which just schedules the next surprise. The quieter one is sandbagging: padding the new baseline so heavily you can’t miss, which sponsors can smell, and which turns your reset into the old fiction with the sign flipped. A re-baseline is only worth doing if the new number is the honest one.

Done right, this conversation is the actual takeover. Everything before it was preparation.

Keep the log. It becomes the story.

From day one, keep a takeover log. Every surprise, dated, one line each. Found out the vendor contract lapsed in June. QA has been testing against an old spec for three sprints. Sponsor and product disagree on what done means for phase one.

In the short term, it’s protection. When someone asks in October why the date moved, you have receipts, with dates, written before anyone was arguing.

In the long term, it’s better than protection. It’s the raw material for the most valuable story you’ll ever tell in an interview. Rescue stories are senior-interview gold. Every panel leans in for the candidate who has walked into a burning building. But listen to how people tell them. The weak version is heroics: it was chaos, I worked nights, I turned it around. Impossible to verify, and it makes the interviewer wonder what you’re like to work for. The strong version is diagnosis: the reports and the board had split six weeks before I arrived, here’s how I found the split, what it told me, how we re-baselined, and what shipped. Same project. One sounds like adrenaline. The other sounds like a method you could hand your next mess to.

Heroics impress for a minute. Diagnosis gets hired.

Two weeks. Read it, find the split, triage on three questions, fix one small thing, send one honest message up, listen down, protect the predecessor’s name, re-baseline from evidence, and write down every surprise. None of it is glamorous. All of it is the job. And “just stabilize it” was never really the brief anyway. It was the test.