Say a project was scoped for six weeks. You're now in week nine, the client has stopped asking for status updates and started asking for calls, and nobody on the team can say with confidence when this actually ships. This happens to disciplined teams as often as disorganized ones, usually because a "small" scope addition in week two never got re-estimated, or because the client's own approvals took twice as long as planned and nobody adjusted the internal deadline to match. Whatever got you here, the instinct to work harder and hope the gap closes itself is the wrong move. What closes the gap is triage, a straight conversation, and a plan you actually believe in.
In this guide
Find out how behind you actually are Stop the bleeding before you start digging out Have the conversation before they force it Build a new plan you can actually defend Frequently asked questions
Find Out How Behind You Actually Are
Most teams skip this step and go straight to damage control, which means they're managing a guess instead of a number. Pull the original estimate and the actual hours logged against it so far. If your project was scoped at 240 hours and the team has already logged 310 with two weeks of build left, you're not "a bit behind," you're roughly 45% over budget with more coming. That's a different conversation than "we're running a few days late," and it needs a different response.
Separate the delay into its actual causes while you're at it: internal underestimation, scope that got added without a change order, client-side delays like slow approvals or late content, or something outside anyone's control. This matters because the fix is different for each one. A project that's late because the client sat on feedback for eleven days needs a conversation about their turnaround time, not a heavier internal sprint. A project that's late because three developers were pulled onto a different account for two weeks is a staffing and capacity problem, and it's worth checking whether your team actually had the headroom to take this project on in the first place before you plan the recovery.
Stop the Bleeding Before You Start Digging Out
You cannot recover a schedule while new requests keep landing on top of the old backlog. Before any recovery plan means anything, freeze intake. Every "quick addition" that comes in this week goes on a separate list, reviewed after the current scope is stable, not folded into the sprint because saying no felt awkward.
- Freeze new requests, in writing, and route anything new to a "phase two" list instead of the current sprint
- Split must-ship from nice-to-have across what's left, most projects can hit a real deadline once 15-20% of the remaining scope gets deferred
- Get sign-off on any cut scope from the client directly, not just from your own project lead, so nobody discovers a missing feature at launch
- List every dependency you're waiting on, credentials, content, third-party approvals, and chase them today instead of assuming they'll show up on time
- Re-run the estimate on what's genuinely left, using the pace the team has actually been shipping at, not the pace from the original proposal
Software teams recovering a slipped sprint often find the freeze alone buys back a surprising amount of time. If your delivery process doesn't already have a hard line between "committed this sprint" and "everything else," it's worth borrowing a few habits from a tighter sprint planning process even for non-engineering work, the discipline of a fixed, protected scope per cycle is what keeps a recovery plan from re-breaking a week after you fix it.
Have the Conversation Before They Force It
The gap between when you know a project is late and when the client hears it from you is the most expensive stretch of time in the whole delay. Every day you spend hoping to close the gap quietly before saying anything is a day the client isn't planning around reality. When they eventually find out, and they always do, the story becomes "you knew and didn't tell us," which is a trust problem on top of a scheduling problem.
Bring the new date, not a promise to find one. Don't schedule a call to say "we're behind, we'll circle back with a plan." Do the triage first, then bring the revised date, the reason for the delay, and one concrete change you're making so it doesn't happen again, all in the same conversation. Clients forgive a slip. What they don't forgive is finding out you sat on it.
Be specific about the cause, even when it's your team's fault. "We underestimated the integration work in week one" lands better than a vague "there were some challenges," because it tells the client you understand what went wrong well enough to fix it. If the delay was partly on their side, say that too, plainly, without turning it into a blame session. A 42-person marketing agency we've talked with runs this as a standing rule: any project more than five business days behind its milestone gets a client call within 24 hours, not an email. The call is shorter, and it's harder to dodge follow-up questions over email that erode trust further.
Build a New Plan You Can Actually Defend
A recovery plan built on hope doesn't survive contact with the next surprise. Build the new timeline off logged hours and real velocity, not off what the team wishes it could do this time. If the team has been averaging 32 billable hours a week against a planned 40, plan the recovery around 32, and treat anything faster as a bonus rather than a baseline.
This is where most teams get burned twice: they miss the first date because the estimate was optimistic, then miss the recovery date because the recovery plan was built on the same optimism. Breaking recovery into smaller checkpoints, weekly rather than one big date six weeks out, gives you a chance to catch a second slip while there's still time to adjust instead of finding out on the new deadline itself. If your team is tracking hours against budget in a spreadsheet that gets updated once a week, you're finding out about slippage days after it happened rather than the day it happens. That's the gap Autovella's project and time tracking are built to close, logged hours roll up against the estimate in real time so a project that's drifting shows up before it's a full-blown miss. Worth a look at the features overview if status updates keep surprising you.
Recovery also isn't free, and it's worth being honest with leadership about that. Adding a contractor, paying overtime, or pulling a senior developer off another account to unblock this one all cost real money against a project that's already over budget. Whether that trade-off is worth it depends on the relationship and the contract, not on a rule of thumb, but it's a decision someone should make on purpose rather than by default. If the pattern of scope creep and late-stage fire drills keeps repeating across projects, it's usually cheaper to fix the estimating and time-tracking setup than to keep absorbing the overtime, and a quick look at what a connected system costs is a fast way to check the math.
Stop finding out a project is behind after the fact
See how Autovella surfaces slipping projects in real time, before the client has to ask.
Frequently asked
Stop planning around the original date and get a real read on the gap. Pull actual hours logged against the original estimate, list what's genuinely left to build, and be honest about whether the delay is a few days or a few weeks. Most teams lose their first week of recovery time arguing about whose fault the delay is instead of measuring it.
Rarely, and almost never in the first week. New people need ramp time from someone who is already behind, which slows the project further before it speeds up. Adding headcount only helps once the remaining work has been broken into pieces that a new person can pick up without heavy hand-holding, which is usually week two or three of recovery, not day one.
Tell them before they have to ask, and bring a revised plan in the same conversation, not a promise to have one later. State the new date, what caused the slip, and what you're doing differently so it doesn't happen again. Clients tolerate a late project far better than they tolerate finding out about it from a missed check-in.