Short answer
To recover a delayed client project, establish the real status, identify what prevents the next deliverable, rebuild the remaining schedule, and offer the client a realistic decision. Do not promise to “catch up” without checking capacity and dependencies. A credible recovery plan says what changes, who owns it, and when the next update arrives.
Free resource
Download the blank project recovery snapshot spreadsheet. No account is required. Save a copy before adding your project details.
What should you do in the first 48 hours?
The first 48 hours of a delayed client project should produce a clear diagnosis and a decision-ready recovery proposal. The following is an operational sequence, not a guaranteed turnaround time. Complex or high-risk work may require longer analysis.
First work session: Reconstruct the truth. List what is complete, what the client accepted, what is unfinished, and which approvals or resources are missing. Separate work that is internally late from delays caused by a decision or changed scope. Avoid assigning blame in the status summary.
Second work session: Identify the next critical deliverable. Ask which outcome the client actually needs first. A staged release may be feasible even when the original all-at-once launch is not.
Third work session: Re-estimate. Include remaining production, client review time, testing, and interruptions. Check who is available rather than assuming everyone can simply work faster.
Fourth work session: Present options. Offer at least one deliverable-first plan, a revised whole-project plan, or a scope-reduction option where appropriate. Obtain agreement before representing the new date as committed.
How do you tell whether a project can be recovered on its original date?
Compare remaining work with remaining usable capacity and the dates of critical dependencies. A schedule is feasible only if the work and necessary review can fit. Working late may sometimes help, but it does not manufacture client approval or reverse an unavailable vendor's lead time.
For a fictional website project, suppose 18 hours of production, four hours of QA, and one client review stage remain. If the team can dedicate only eight usable hours before the promised date, the original plan is not feasible without changing scope, adding suitably qualified help, or moving the date. These values are illustrative; calculate your own.
Atlassian's dependency guidance describes why linked prerequisites influence the schedule. In a recovery scenario, dependencies matter more than the number of checkboxes left open.
Which recovery option should you propose?
Present options in terms the client can evaluate: what they receive, by when, at what cost, and what remains deferred.
| Option | What the client receives | Tradeoff |
|---|---|---|
| Revised full launch | All agreed deliverables at a later date | Schedule moves |
| Staged launch | Critical approved work first | Lower-priority items follow |
| Scope reduction | Smaller agreed deliverable set | Some planned work removed or deferred |
| Added capacity | More delivery resources if feasible | Additional cost and onboarding risk |
Do not promise that adding another person automatically accelerates the project. Some work cannot be parallelized, and new contributors need context.
How do you write the recovery update?
A good project recovery message contains a status statement, the reason the plan needs adjustment, options, and the next decision. Keep it specific enough that the client can reply without another long meeting.
Subject: [Project] recovery plan and revised options
Hi [Name],
We reviewed the remaining work on [project]. [Completed outcome] is finished, while [specific dependent work] still needs [input or production]. Based on the current work and review windows, the original [date] is no longer a reliable commitment.
We recommend [option] to deliver [critical outcome] by [proposed date], with [remaining work] following on [date]. An alternative is [second option and tradeoff].
Could you confirm your preferred approach by [decision date]? We will update the project schedule after your choice.
When your team caused the delay, own that plainly. When a client decision contributed, state the dependency without using it as an excuse.
How do you prevent the same delay from recurring?
After the new plan is accepted, add review checkpoints where the previous plan failed: clearer acceptance criteria, earlier asset collection, realistic review windows, or better task estimates. Revisit the project weekly until it stabilizes, and communicate risks before they turn into missed dates.
The Noddis guide to project drift covers early warning signs, while the freelancer capacity planning guide explains how to avoid assuming unlimited delivery hours.
Noddis is a project management app that keeps project status, tasks, dates, and follow-ups connected. Use Portfolio to compare affected projects and Follow-Up for the decisions needed to restart work. The product will not generate an honest recovery commitment without your estimate and client agreement. See the live demo.
Your next step
Build a one-page recovery snapshot with completed work, outstanding critical tasks, missing decisions, realistic capacity, and two client options. Then communicate it promptly.
Common questions
Should you offer a discount when a project is late?
That depends on the agreement, responsibility for the delay, and the relationship. Do not substitute a discount for a credible recovery plan. Resolve contractual or refund questions using the actual terms and appropriate advice.
Should you tell a client about a delay before knowing the new date?
Yes, when a material commitment is at risk. State what is known, what is being checked, and when you will present revised options. Silence makes an avoidable surprise more likely.
Can a project be recovered without adding staff?
Often the first opportunity is sequencing: finish a critical outcome, remove unnecessary work by agreement, or unblock a dependency. Additional capacity helps only when the work can be delegated safely and realistically.
Katleen is the founder of Noddis. She runs client projects through her app studio, 693 Labs, and builds Noddis around the problems that work creates.
Last reviewed . Feature details reflect Noddis at the time of review.