How to track delays in a Gantt chart

1. How does a Gantt chart show a delay?

A Gantt chart shows a delay when a task's real dates stop matching its planned dates. In most tools this shows up as a progress bar that has not reached where it should be by today, or a task bar that has been pushed past its original end date. The visual gap between plan and reality is the delay.

This is one of the quiet strengths of a Gantt chart over a plain task list. A checklist can tell you a task is not done, but it cannot show you that being two days late on it will push the launch back two days. The chart puts the task in the context of time and everything around it, so a slip is visible as a shape, not just a missed checkbox.

For that to work, the chart has to reflect reality. Tracking delays only helps if someone is actually updating task progress as the work happens. A chart that was accurate at kickoff and never touched since will not show you anything useful.

2. How do you compare planned dates to actual progress?

The clearest way to track a delay is to keep the original plan as a baseline and compare the current dates against it. A baseline is a saved snapshot of your planned start and end dates. Once you have one, the chart can show both the plan and the current reality, and the distance between them is the delay in plain sight.

Without a baseline, you lose the memory of what you promised. If you only ever see the current dates, a task that has slipped three times just looks like it was always going to end on that date. The baseline is what lets you say a task is late at all, and by how much.

If your tool does not have a formal baseline feature, a simple stand-in works: note the original end dates of your key phases somewhere before the project starts, and check the live chart against them at each review. It is less automatic, but it preserves the same idea of plan versus actual.

3. How does one delay spread to other tasks?

A delay spreads through the chart along its dependencies. When task B depends on task A finishing, and A runs three days late, a well-set-up chart pushes B three days later automatically, and anything depending on B moves with it. That cascade is exactly what you want to see, because it turns a single late task into an honest new end date.

This is why task dependencies matter so much for delay tracking. If your tasks are not linked, a delay stays local: the chart shows one late task and gives no hint that the whole back half of the project just moved. If they are linked correctly, one update ripples through and the real picture appears without you recalculating anything.

There is a balance to strike. Over-linking every task means one small slip triggers a cascade across the whole plan, which is noisy and often wrong. The guide on milestones and dependencies covers how to link only the tasks where the order genuinely matters, which keeps delay tracking meaningful.

4. How do you spot delays early?

Spot delays early by watching the critical path and any task whose progress is falling behind its position in time. The critical path is the longest chain of dependent tasks, and a slip anywhere on it moves the project end date directly. Tasks off the critical path have some slack, so a small delay there may not matter at all.

A few habits make delays visible before they become a crisis:

• Check progress against today. If a task is 30 percent done but its bar says it should be 70 percent done by now, it is quietly slipping even though it is not officially late yet.
• Watch the tasks with dependents. A late task that nothing depends on is a local problem. A late task that five others wait on is a schedule problem.
• Look at the critical path first. If nothing on the critical path is behind, the end date is probably safe even if a side task is late.

The goal is to catch the slip while there is still room to absorb it. A delay found at the review before delivery leaves you no options. The same one found three weeks earlier usually does.

5. What should you do when a task slips?

When a task slips, update the chart to reflect the real dates first, then decide how to respond. Seeing the honest new end date is what lets you make a real choice instead of pretending the problem away. From there you usually have a few options:

• Absorb it. If the late task is not on the critical path, or a later task has slack, the delay may not move the end date at all.
• Compress a later task. Add people or narrow the scope of a downstream task to claw back the lost time.
• Move the deadline. Sometimes the honest answer is a later end date, and saying so early is far better than saying it at the last minute.

The one thing not to do is drag the bars back to make the plan look on track. A chart that has been quietly edited to hide slippage is worse than no chart, because now people are making decisions on a plan that is not real. If a delay affects a client, the guide on presenting a timeline to clients covers how to communicate the change without eroding trust.

Common questions about tracking delays

What is a baseline in a Gantt chart?

A baseline is a saved snapshot of your original planned dates. Comparing the live chart against the baseline shows how far tasks have slipped from the plan, which is the difference between a task simply being where it is and a task being late.

Why does one late task move so many others?

Because they are linked by dependencies. When later tasks depend on an earlier one finishing, delaying the earlier task pushes all of them. This cascade is intentional - it reveals the true impact of the delay instead of hiding it.

How do I know if a delay will affect the deadline?

Check whether the late task is on the critical path, the longest chain of dependent tasks. A slip on the critical path moves the end date directly. A slip on a task with slack may not affect the deadline at all.

Should I move task dates to hide a delay from stakeholders?

No. Editing the chart to look on schedule removes the one thing that makes it useful. Track the real dates and communicate the impact - a plan that no longer matches reality helps no one.

Next steps

Start by saving a baseline of your planned dates, then keep the chart honest as work happens: update progress, let dependencies cascade, and check the critical path at each review. A delay you can see early is a delay you can usually still manage.