How to Track Task Dependencies and Milestones in a Gantt Chart

A list of tasks with dates next to them is a calendar. A Gantt chart earns its name when it also shows what depends on what — because that's the difference between "here's when things are supposed to happen" and "here's what happens to the whole project if this one thing slips."

What a dependency actually means

A dependency exists when Task B genuinely cannot start until Task A is finished — not "shouldn't," not "would be nice if it didn't," but physically or logically cannot. Foundation work can't start before the permit is approved. Testing can't start before the feature is built. User training can't happen before the interface is finalised.

The test for a real dependency is simple: if Task A finishes three days late, does Task B's start date move by the same three days? If yes, it's a dependency. If Task B could technically start anyway (just awkwardly, or with a workaround), it's a preference, not a dependency — and treating it as one will make your chart overly rigid.

Don't map every possible dependency

New planners often try to link everything to everything, which produces a chart so tangled with arrows it becomes unreadable. Most projects only have a handful of dependencies that actually matter for the deadline — the ones sitting on the critical path. Map those precisely, and leave the minor sequencing (which is often just "these two people are doing this in whatever order suits them") unlinked.

Milestones: the dates that gate everything else

A milestone is a single point in time, not a duration — a permit approval, a client sign-off, a regulatory inspection, a product launch date. These deserve a different visual treatment than tasks, because they represent a decision or an event, not work being done.

Milestones are also where dependencies concentrate. A single milestone — say, "design sign-off" — often gates three or four downstream tasks at once. Making that visible on the chart tells everyone exactly which single date the rest of the schedule is waiting on.

Watch for the "everything depends on the slow thing" pattern

In almost every project, one slow-moving approval or delivery ends up gating far more downstream work than anyone planned for at the start — a procurement approval, a legal review, a long-lead-time material order. Once you've mapped dependencies properly, this bottleneck usually becomes visually obvious: it's the milestone with the most arrows coming out of it.

That's useful information on its own. It tells you exactly where to focus follow-up effort — chasing that one approval two weeks earlier is worth more than optimising ten other tasks that aren't actually gating anything.

Re-check dependencies when the schedule shifts

When a task slips, its dependents should shift with it — but people often update the late task and forget to check what was waiting on it. This is how schedules quietly drift out of sync with the plan they're supposed to represent. Whatever tool you use, make "check downstream dependencies" part of your weekly update routine, not an occasional afterthought.