How to handle project delays and keep your plan on track

Every project gets delayed. A supplier answers late, a review takes twice as long, someone is ill for a week. What separates a calm project from a stressful one is not whether delays happen, but how quickly you understand what a delay actually changes and what you do next. This guide shows how to handle project delays in a practical order: measure the slip, find out what it touches, pick a recovery option, tell the right people and update the plan.

Step 1: Measure the delay before you react

The first instinct is to panic about the date. Resist it for ten minutes and write down three facts instead:

• Which task slipped, and by how many working days.
• Why it slipped: a wrong estimate, a missing input, a person who was unavailable, a change in scope.
• Whether it is finished slipping. A task that is "two days late" but still not started may become five days late.

The reason matters because it decides the fix. A wrong estimate suggests the other estimates may be wrong too. A missing input means somebody has to be chased, not rescheduled. If you want to improve the numbers going forward, see how to estimate task duration in a project plan.

Step 2: Find out what the delay touches

A delay of three days on one task does not automatically move the launch by three days. It depends on what is connected to that task. Two things decide it.

Dependencies

Tasks that depend on the late task cannot start until it finishes, so they shift. Tasks that depend on those shift as well, and so on down the chain. This is why a plan with real task dependencies is so valuable at this moment: the chart already knows what is downstream, so you do not have to remember it.

Slack

Some tasks have room to move without affecting the end date, because the work that follows them is not ready to start anyway. If the late task has a few days of slack, the delay may be absorbed at no cost. If it sits on the longest chain of dependent tasks from start to finish (the critical path), every day of delay is a day added to the end date.

A simple way to check on any chart is to follow the dependency arrows from the late task forward and ask two questions. Does the chain reach a milestone? If so, how many days of space are there between the end of the chain and that milestone?

Example: a website relaunch

Imagine a website relaunch with this chain: Wireframes (5 days) then Visual design (8 days) then Build templates (10 days) then QA (4 days) then Go-live milestone.

Visual design slips by four working days. Because Build templates depends on it, and QA depends on that, the whole chain moves by four days. Go-live moves too, unless there is slack somewhere or the client date was set with a buffer.

At the same time, Content migration was running in parallel and only needs to finish before QA. It has six days of room, so the same delay does not affect it. The same slip, two different consequences, and only one of them hits the launch date.

Step 3: Choose a recovery option

Once you know the real impact, you have a short list of options. None is free, so name the trade-off for each.

Option	What you do	What it costs
Absorb it	Use existing slack or a buffer	Less safety margin for the next problem
Move the date	Accept the new end date and reschedule	The stakeholders must agree
Add resources	Give the late task more people	Handover time; not every task speeds up
Overlap tasks	Start downstream work before the late task is fully done	Rework if the early work turns out to be wrong
Cut scope	Drop or postpone something that is not essential	A smaller result on the original date

Be careful with "add people". Some work divides well (testing many pages), and some does not (one designer making one decision). Be equally careful with overlapping: it is a legitimate way to recover time when the early output is stable, and a risky one when it is not.

Often the honest answer is a mix: absorb part of the delay in slack, cut one small item and move a non-critical milestone by a couple of days. Write the chosen option down with the reason, so the decision is not re-debated next week.

Step 4: Tell people early and plainly

Bad news does not improve with age. A short message sent the same day is almost always better received than a perfect explanation sent a week later. A good delay update has four parts:

1. What happened, in one sentence.
2. What it changes (and what it does not).
3. The new date, or the options if the date is not decided.
4. What you need from the reader, if anything.

For example: "Visual design finished four working days late because the brand assets arrived late. Build and QA move by the same amount, so go-live moves from 20 November to 26 November. Content work is not affected. I need approval of the new date by Friday."

If the people involved can open the plan itself, they can see the updated chart instead of relying on your summary. Sharing a Gantt chart with a client or team as a viewer is a simple way to give them that view without letting them change anything.

Step 5: Update the plan, not just the date

A delay is only handled once the plan reflects it. Updating one bar is not enough. Go through this short checklist:

• Move the late task and everything that depends on it.
• Re-check each milestone that sits downstream and confirm its new date.
• Update the progress of tasks that are partly done, so the chart shows reality.
• Review the people assigned in the shifted period: a moved task can land on someone who is already busy.
• Note the reason for the change somewhere the team can find it, such as the task notes.

This is the part that people skip, and it is why plans go stale. When a plan is not updated, the team stops trusting it and goes back to private to-do lists.

Doing the update with an AI assistant

If you use ProGantt Flow with Claude, Cursor or VS Code through MCP, this is a good job to hand over. A prompt like the following works well:

In "Website relaunch", the Visual design task is running four working days late. Move it and everything that depends on it, then tell me the new go-live date and which milestones changed.

The assistant reads the project, follows the dependencies, applies the changes and reports back, and you review the result in the chart. Everything it does is a normal edit to your project, so the people you share the plan with see it too. The decision of which recovery option to choose should stay with you. The connector docs list what the assistant can and cannot do, and managing a project plan with Claude has more example prompts.

Preventing the next delay

You cannot prevent all delays, but a few habits make them cheaper:

• Add a visible buffer before important milestones instead of padding every task. A single, named buffer is easier to defend and to spend.
• Review the plan weekly for ten minutes: what finished, what is late, what starts next. Small slips found early are cheap.
• Keep tasks small. A three-day task that is late is obvious within days. A six-week task can hide its delay for a month.
• Make dependencies explicit, including the ones on people outside the team, such as a client approval.

A quick summary

To handle project delays well, measure the slip, follow the dependencies to see what it really touches, pick one recovery option and name its cost, tell people the same day, and update the whole plan. If you want a place to practise this on a real schedule, you can open ProGantt Flow and try it with a small project.