Handling schedule slippage

Here is a fact worth accepting before you start any project: some of your tasks will run late. Not because you planned badly, but because estimates are forecasts and forecasts are wrong. The difference between a project that recovers and one that quietly slides into a missed deadline isn't luck — it's whether the person running it can spot slippage early, work out whether it actually matters, and pick the right response instead of panicking or pretending.

This guide is the playbook for that moment. It assumes you've already done the groundwork — a plan with dependencies, durations, and a baseline. If you haven't, start with the project planning framework; you can't manage slippage against a plan that doesn't exist.

Step 1: Detect it early

Slippage is cheapest to fix the day it starts and most expensive the week before the deadline. Early detection is therefore the highest-leverage thing you can do, and it rests on two tools working together.

The first is a baseline — the snapshot of the plan you agreed to before work began. Without it, "we're a bit behind" is a feeling; with it, you can see the exact gap between where a task was supposed to be and where it is. The second is the today line, the vertical marker on the current date in your Gantt chart. When a task's progress shading hasn't reached the today line, that task is behind — visibly, instantly, no spreadsheet required. Glance at the chart, find any bar whose fill is to the left of today, and you've found your slippage before it has a chance to compound.

Step 2: Diagnose — does it actually matter?

This is the step almost everyone skips, and skipping it is why projects either over-react to harmless delays or ignore fatal ones. Not all late tasks are equal. The question that sorts them is: is this task on the critical path?

The critical path is the chain of dependent tasks that determines your end date. A task on it has zero slack: a one-day slip there pushes the whole finish out by a day. A task off it has float — spare time before it would affect anything downstream. A graphic-design task with four days of float that runs two days late hasn't cost you a thing; the same two-day slip on a critical task has cost you two days off the deadline. So before you reach for any fix, classify the slippage:

• Late, but off the critical path with float to spare? Note it, keep an eye on it, and do nothing dramatic. Spending a recovery effort here is wasted motion.
• Late on the critical path — or eating through a non-critical task's float? Now it matters. Move to the options below.

Step 3: Choose a recovery option

Once you've confirmed the slippage matters, you have five real levers. Each buys time at a different cost — there is no free one.

Fast-track (parallelise)

Take tasks you'd planned to do one after another and overlap them. If "write user guide" was set to start only when "build feature" finished, start the guide when the feature is 80% done. In dependency terms you're converting a strict finish-to-start link into an overlap using lead time. Fast-tracking costs no money, which is why it's usually the first move — but it costs risk: you're working on something before its input is fully settled, so if the feature changes in that last 20%, you'll redo part of the guide. Fast-track where the rework risk is low.

Crash (add resources)

Throw more people or hours at the critical task to shorten it. Crashing costs money directly and, crucially, doesn't scale the way intuition expects. Brooks's law — "adding people to a late software project makes it later" — captures why: new people need ramp-up, communication overhead grows with team size, and some tasks simply can't be split (nine women can't make a baby in one month). Crash tasks that are genuinely divisible and where the new hands can be productive quickly; don't crash a task whose bottleneck is one person's knowledge.

Re-scope (de-scope)

Cut work. Move features from "this release" to "the next one", drop the nice-to-haves, ship the four modules instead of six. This is often the cleanest recovery because it's the only one that reduces the actual work rather than compressing or reshuffling it — but it requires a real decision about what the project is for, and usually a conversation with whoever owns the goal. A tight scope, defined honestly up front, is what makes this lever available; this is exactly why naming what's out of scope matters from day one.

Move the deadline

Sometimes the honest answer is that the date has to move. This is not failure — a deadline that was a guess shouldn't be defended to the death once you have better information. The skill is moving it once, deliberately, with a credible new date, rather than letting it slip a few days at a time until all confidence is gone. A single, well-justified reset beats a dozen quiet slides.

Re-sequence

Sometimes you can't speed anything up, but you can reorder. If a critical task is blocked waiting on an input that's late, pull forward other work that's ready, so the blockage isn't also wasting calendar time. Re-sequencing doesn't shorten the critical path on its own, but it stops idle time from making a bad situation worse, and occasionally it reveals a shorter path you hadn't drawn.

A decision guide

When a critical task is late and you're not sure which lever to pull, run down this list and stop at the first yes:

1. Can downstream work start before this task fully finishes, with low rework risk? → Fast-track.
2. Is the task divisible, and can extra hands be productive quickly? → Crash (watch Brooks's law).
3. Is there scope you could honestly cut without breaking the goal? → Re-scope.
4. Is other ready work sitting idle while this one blocks? → Re-sequence to fill the gap.
5. None of the above, and the date genuinely can't be met? → Move the deadline — once, with a credible new one.

In practice you'll often combine them: fast-track what you can, crash one divisible task, trim a little scope, and accept a small, honest shift in the date. The art is using the cheapest levers first and reaching for the deadline only when the others are spent.

Communicate early and honestly

Whatever you choose, tell the people who care before they ask. Bad news travels best when it travels early and comes with a plan attached: "Task X slipped two days, it's on the critical path, here's the recovery, here's the revised forecast." That's a manageable update. The same news delivered the day before the deadline, with no plan, is a crisis. How you frame this for stakeholders is its own skill — see presenting a plan to stakeholders for handling the "can we go faster?" conversation that always follows.

Update the plan — don't re-baseline to hide it

When things slip, the temptation is to quietly redraw the baseline so the chart looks on-track again. Resist it. The baseline exists precisely to record what you promised; overwriting it every time reality disagrees turns your most useful diagnostic into a flattering mirror. Update the current plan freely — that's just keeping it honest — but treat re-baselining as a rare, deliberate act reserved for a formally agreed change of plan, with the old baseline preserved. A project whose baseline is rewritten weekly has no memory, and a plan with no memory can't tell you whether you're improving or just sliding more slowly.

Prevent the next one

Recovery is firefighting; the real win is fewer fires. The most common root cause of slippage is optimistic estimates with no allowance for the things that always happen — sickness, rework, the task that turned out to be three tasks. Better duration estimates, with explicit buffers placed where the risk genuinely lives rather than padding hidden in every task, do more to keep a project on time than any recovery technique. The slippage you handle best is the one you saw coming and left room for.

Frequently asked questions

What is the difference between fast-tracking and crashing?

Fast-tracking overlaps tasks that were planned in sequence, so it costs no money but adds rework risk if the earlier task changes. Crashing adds resources to shorten a task, so it costs money and runs into diminishing returns. Fast-track first because it is free; crash when overlapping is not possible.

A task is late but not on the critical path. Do I need to act?

Usually not immediately — a non-critical task has float, spare time before it affects the finish date. But watch it: if it slips far enough to use up that float, it becomes critical. Re-check the critical path after any large slip, because the path can shift.

Should I move the deadline as soon as something slips?

No. Moving the deadline is the last lever, not the first. Try fast-tracking, crashing, re-scoping, and re-sequencing first, since they protect the date. Move it only when those are exhausted — and then move it once, to a credible new date, rather than letting it drift a few days at a time.

Is it ever okay to re-baseline a slipped project?

Yes, but rarely and deliberately — when there is a formally agreed change to the plan, scope, or deadline, and you preserve the old baseline rather than erasing it. Re-baselining routinely to make the chart look on-track destroys the very comparison the baseline exists to provide.