How to handle changes to a project timeline
When a date moves, update the plan the same day, including the work that follows it, record what changed and why, and tell the people affected before they find out another way. Keep the version everyone agreed to, so you can show exactly what moved. Moving the bars is the easy part; keeping everyone on the same plan is the job.
By the NeoGantt team · Updated
Why a timeline change causes more trouble than the delay
A task running a week late is rarely the real problem. The damage comes from what happens around it: three copies of the plan in three inboxes, a client quoting the old launch date to their board, a designer who didn’t hear that their start moved, and a meeting a month later about what was agreed in the first place.
Handle the change well and the delay stays a delay. Handle it badly and it becomes a trust problem.
What to do when a date moves, step by step
- Pin down the change. What slipped, by how many working days, and why. “Content is late” isn’t enough; “homepage copy arrives on the 14th instead of the 7th” is.
- Move the knock-on work, not just the task. Walk down the plan and ask of each later task whether it can still start on time. Tools with dependencies do some of this for you; otherwise, it’s a five-minute read of the chart, and worth doing properly.
- Check the milestones. These are the dates people remember. Note which ones moved and which held, because that’s what everyone will ask first.
- Record the change. Give the new version a name and date (“v3, 14 Oct: content delay”), list what moved, and write down the reason while everyone still remembers it.
- Tell people in the right order. First the people whose work moves, then the client or sponsor. Lead with the milestone impact, then the cause, then anything you need from them.
- Get the new plan agreed. Once it’s accepted, it becomes the version you compare against next time.
Keep the version everyone agreed to
Project managers call it a baseline: a frozen copy of the plan as it was approved, kept so you can compare the current plan against it. Without one, “we’re two weeks behind” is an opinion. With one, it’s a fact you can point to.
Scheduling tools such as Microsoft Project store baselines formally. In a spreadsheet, save a dated copy each time the plan is agreed (plan-v2-2026-10-09.xlsx) and never edit it again. Whatever you use, the rule is the same: one live plan that changes, and a trail of agreed versions that don’t.
How to write a timeline change update
Keep it short enough to read on a phone. Clients and sponsors want to know three things: does the date they care about move, why, and do they need to do anything. An update that answers those in the first few lines rarely turns into a meeting.
Subject: Website timeline, v3 (launch unchanged)
The homepage copy is now arriving on the 14th rather than the 7th, so design review moves back five working days, to the 27th. We’ve shortened build by overlapping content entry with development, so go-live stays on 4 December.
What we need from you: feedback on the designs by the 29th, so the launch date holds.
The live plan is at the usual link, with the change noted on the design review task.
If the launch date does move, say so in the subject line. Burying a slipped milestone in the third paragraph is how updates lose people’s trust.
Common causes of timeline changes, and how to get ahead of them
| Cause | Early warning | What to do in the plan |
|---|---|---|
| Late client content or approvals | Questions go unanswered for more than a few days | Put the client’s jobs on the chart as their own tasks, with dates, from day one |
| Extra feedback rounds | New stakeholders appear at review | Show one bar per review round; agree the number of rounds up front |
| Leave, illness, public holidays | Nobody checked the calendar when planning | Block out holidays and known leave before sharing the first version |
| Scope change | “Could we also…” in a status meeting | Add the new work as separate tasks so the cost of the change is visible |
| Supplier or third-party delay | Quotes or deliveries without firm dates | Mark their deadline as a milestone and chase it a week before |
Should you tell the client about every change?
No. If an internal task moves and nothing the client sees or owns changes, update the plan and move on. Tell them when a milestone moves, when one of their tasks moves, or when a later date is now at risk even though it hasn’t moved yet. That last one is the hardest to send and the most valuable: a warning three weeks out is a planning conversation; the same news three days out is an argument.
For the wider question of what clients should see in a plan at all, see how to share a Gantt chart with clients.
A quick checklist for every change
- The cause is written down, in one sentence.
- Every later task has been checked, not just the one that slipped.
- You know which milestones moved and which held.
- The new version is named, dated and saved; the old one is untouched.
- The people affected heard it from you before they saw it on the chart.
- The client’s update leads with the milestone that matters to them.