Project Rescue: The First 30 Days of Taking Over a Failing IT Project

Nobody calls a rescue manager when things are going well. By the time an IT project rescue is on the table, the symptoms are usually the same: milestones slipping for the third time, a steering committee that has stopped believing the status report, a vendor and a client quietly blaming each other, and a sponsor who wants one thing: the truth, and then a way out.

We have written before about why IT projects fail. This article is about what happens next: the first 30 days after a new delivery lead takes over a troubled project, based on how we run rescue engagements in practice.

Days 1 to 10: Establish the truth

The first job is not to fix anything. It is to find out what is actually true, because on a failing project the official picture and reality parted ways months ago.

Read the contract before the plan. Scope, acceptance criteria, payment milestones and penalties define what “done” legally means. Many rescues turn out to be commercial disputes wearing a delivery costume.

Interview before you inspect. Ten one-to-one conversations (sponsor, product owner, tech lead, vendor delivery manager, testers, key users) reveal more than any dashboard. Ask everyone the same three questions: What is really blocking us? What are we pretending is fine? What would you do first?

Rebaseline the facts. Actual scope delivered versus contracted, real defect counts, true budget burn, honest dependency status. No interpretation yet, just verified facts with sources.

The deliverable of the first ten days is a short written assessment the sponsor can trust. If it doesn’t hurt a little, it isn’t honest.

Days 11 to 20: Reset expectations

With facts on the table, the conversation moves to the sponsor and steering committee, and this is where most rescues are won or lost.

Present the assessment without blame. The goal is a shared understanding of position, not a tribunal. Assigning fault can wait; in most cases the causes are systemic: optimistic planning, weak governance, scope added without replanning. These are exactly the patterns we described in our failure analysis.

Kill the fiction. Whatever the previous plan promised, the reset means a new baseline: reduced scope for the next release, a realistic date, or more budget, usually some combination. Executives handle bad news far better than they handle repeated surprises. Red must mean Red.

Secure the mandate. A rescue lead needs explicit authority: to change the plan, to re-open the vendor conversation, to stop work that isn’t contributing. Without a mandate in writing from the sponsor, the rescue is theatre.

Days 21 to 30: Replan on credible assumptions

The new plan is built bottom-up with the people who will deliver it, not imposed from a template.

• Shortest path to demonstrable value. Find the smallest release that proves the system works end-to-end and rebuilds stakeholder confidence.
• Estimate with the delivery team, then add the honesty margin. If the team says six weeks, plan eight and say why.
• Right-size the governance. Weekly steering with a one-page RAG report, a live risk and dependency log, and an escalation path that surfaces problems while they are still cheap to fix. Not more process, sharper process.
• Fix the vendor interface. Milestone acceptance criteria in writing, defect severity definitions agreed, and one named owner on each side.

By day 30 the project should have three things it did not have before: a truthful baseline, a sponsor who trusts the reporting again, and a plan the team itself believes in. Delivery speed comes back as a consequence: trust first, velocity second.

The uncomfortable question

One rescue in three, in our experience, ends with a recommendation the sponsor didn’t expect: stop, descope hard, or restructure the contract. A rescue assessment that can’t reach that conclusion isn’t an assessment. It’s a sales document. The willingness to say “this project should not continue in its current form” is precisely what makes the rest of the advice credible.

When to call for help

If your project shows the classic triad of slipping dates, contested scope and reporting nobody believes, the cost of an independent assessment is trivial compared to another quarter of drift. Our IT project management services include rescue and recovery engagements exactly like the one described here: short assessment first, honest verdict, then hands-on delivery leadership until the project is back under control.

Thirty years of delivery experience across banking, public sector and defence have taught us one thing above all: projects rarely die of a single wound, and almost all of them can be saved if someone is willing to tell the truth early enough.

---

Editorial note — This article was researched and drafted with the assistance of Claude (Anthropic), and reviewed and approved by Amazing Projects before publication.