How to Recover a Project That Is Behind Schedule

A project that is behind schedule is not a failed project. It is a derailed project. The difference matters because derailed projects can be recovered. Most project managers do not know the recovery process because no one taught them one. This post does.

The three-step recovery process below works regardless of how far behind the project is, how long it has been off track, or how complex the project is. What it requires is honesty about the current state and the willingness to stop adding work before you start fixing the problem.

Step 1. Stop All New Work Immediately

The first action in any project recovery is a full stop on new tasks. No new features. No new deliverables. No additional requests from stakeholders until the recovery plan is approved and the baseline is reset. This is the step most project managers skip because it feels counterintuitive. The project is already behind. How does stopping help?

It helps because adding more work to a project that is already behind makes it more behind. Stop first. Diagnose second. Restart with a clear plan third. Use the free Project Recovery Checklist to walk through every step of the recovery process so nothing gets missed during the reset.

Step 2. Find the Root Cause, Not the Symptom

A missed deadline is a symptom. The root cause is what needs to be identified and addressed. Common root causes include scope that expanded beyond what the team can deliver in the available time, resource availability that changed after the project started, external dependencies that were delayed, or unrealistic estimates in the original plan that no one challenged at kickoff.

Ask three questions to find the root cause. What was the first sign that this project was going to miss its date? What changed between when the plan was made and when the problem appeared? What would need to be different for this project to deliver on a revised timeline? The answers to these three questions identify the root cause in most cases.

Step 3. Build a New Plan, Get Written Approval, Restart

Once the root cause is identified, build a revised plan. This means a new baseline: a reset scope if necessary, updated milestones with realistic dates, and a clear statement of what will be delivered by when. Present this revised plan to your sponsor with three things: what happened and why, what the new plan is, and what you need from the sponsor to make the new plan work.

Get written approval before restarting any work. A verbal yes in a meeting is not enough. An email confirmation that the sponsor approves the revised scope and timeline creates accountability and prevents the revised plan from being revised again at the next status meeting.

Once approval is in writing, restart. Brief the team on the new plan. Assign clear owners to every milestone. Run the daily sprint system from day one of the recovery. Check milestone progress weekly against the new baseline using the Weekly Progress Dashboard. Do not allow new scope additions until the project is fully recovered.

How to Communicate a Recovery Plan to Stakeholders

Stakeholders handle project delays better than they handle surprises. A project manager who comes to a stakeholder with a problem and a solution earns credibility. A project manager who comes to a stakeholder with a problem and no plan loses it.

The communication template is: The project is currently behind schedule by X days due to the root cause you identified. I have developed a recovery plan that delivers the revised scope by the new date. I need your approval on the specific decision required to proceed. I can present the revised plan today. Short, factual, solution-focused.

If you want the complete recovery framework with scripts for stakeholder communication and a step-by-step plan for getting back on track, The Accidental Project Manager covers the full recovery system in one place.