Rescuing a Project That's On Fire

Three times in my career, I've been handed projects that were completely off the rails. Months behind schedule. Team demoralized. Stakeholders losing faith.

Each time, we turned it around. Not by working harder — by working smarter. Here's the playbook.

First: Stop The Bleeding

Don't try to fix everything at once. Figure out what's actively making things worse and stop that first.

Common bleeding sources:

• Scope creep: New requirements being added mid-sprint
• Context switching: Team pulled in too many directions
• Thrashing: Decisions being made, then unmade, then remade
• Missing information: People blocked waiting for answers

Week one: Identify the top 2-3 things that are draining team productivity. Fix those. Nothing else.

Second: Assess The Actual Situation

Not what the project plan says. Not what people hope. What's actually true right now.

Questions I ask:

• What's actually done and working? (Verify, don't trust status reports)
• What's the minimum viable scope for launch?
• What's the team's actual capacity?
• What are the real dependencies and blockers?

This usually reveals that the project is either better or worse than people think. Rarely the same.

Third: Reset Expectations

Here's where most people fail. They want to be optimistic. They promise they'll catch up.

Don't.

Have the hard conversation:

• "Based on what I'm seeing, we cannot hit the original date with the original scope."
• "Here are three options: reduce scope, extend timeline, or add resources."
• "I recommend Option X because..."

Stakeholders respect honesty. They don't respect optimism followed by missed deadlines.

Fourth: Simplify Ruthlessly

Every troubled project I've seen has one thing in common: trying to do too much.

Cut scope. Cut it more than feels comfortable.

Ask for each feature:

• Is this truly required for launch?
• What's the simplest version that delivers value?
• Can this wait for v2?

You can always add things later. You can't un-miss a deadline.

Fifth: Create Clarity

Troubled projects usually have unclear ownership, unclear priorities, or both.

Fix it:

• One clear owner for the project (one person, not a committee)
• One prioritized list of what needs to be done
• One source of truth for project status
• Daily standups (short, focused, problems surface fast)

If people don't know what they should be working on, they'll work on the wrong things.

The Turnaround Plan Template

CURRENT STATE:
- What's done: [list]
- What's blocked: [list]
- Team capacity: [realistic hours/week]

REVISED SCOPE:
- Must have for launch: [list]
- Cut from launch: [list]
- Moved to v2: [list]

REVISED TIMELINE:
- New target date: [date]
- Key milestones: [list with dates]

RISKS:
- [Risk 1]: Mitigation [X]
- [Risk 2]: Mitigation [Y]

DECISION NEEDED:
- [What you need stakeholders to approve]

One page. Clear. Actionable.

What Actually Saves Projects

It's not working nights and weekends. That burns people out and rarely helps.

What actually helps:

• Focus: Doing fewer things, but doing them completely
• Clarity: Everyone knowing exactly what matters
• Quick decisions: Problems don't fester
• Morale: People believing the project can succeed

That last one matters more than people think. A team that believes they can do it will find ways to make it work. A team that's given up will fail even with the right plan.

Signs It's Working

Within 2 weeks of a turnaround, you should see:

• Team energy improving (they can see progress)
• Blockers getting resolved faster
• Fewer fire drills
• Status updates matching reality

If you don't see these, something's still wrong. Go back to step one.

When to Walk Away

Sometimes projects can't be saved. The codebase is too broken. The team is too depleted. The stakeholders won't make hard decisions.

Signs it's time to recommend killing the project:

• Core architecture is fundamentally flawed
• Team has completely lost faith
• Business case no longer makes sense
• Stakeholders refuse to make scope cuts

Killing a project isn't failure. Continuing a doomed project is failure. Better to acknowledge reality and redirect resources to something that can succeed.

Not every project can be saved. But most can, with the right combination of honesty, focus, and leadership. The key is acting fast — the longer a project stays on fire, the harder it is to rescue.