Gantt chart dependencies: which tasks to link and why

What does a dependency actually do to your schedule?

A dependency tells the chart that one task cannot proceed until another has reached a certain state. Visually it is an arrow between two bars, pointing from the task that has to happen first. Functionally it is a rule the chart enforces: if the first task moves, the second one moves with it.

That second part is the whole value. A list of tasks with dates is a set of independent guesses; every date has to be corrected by hand when something changes, and in practice most of them never are. A linked chart holds the relationships, so a single honest update to one task produces an honest picture of everything downstream.

Dependencies also make two other things possible that a plain task list cannot support. They are what lets a chart identify the chain of tasks setting your end date, since that chain is defined by the links. And they are what turns a slip into information rather than a note in a status update. If you are new to the basic parts of a chart, it is worth covering what a Gantt chart shows before adding links to one.

What are the four dependency types?

There are four standard types. You will use finish-to-start almost all of the time, and knowing the other three is mostly useful for recognising when a relationship does not fit the default.

An opinion worth stating plainly: if you find yourself using start-to-start and finish-to-finish frequently, the problem is usually the task breakdown rather than the dependency type. Two tasks that must start together and finish together are often one task described twice. Splitting them and then linking them back together adds rows without adding information.

A worked example

Here is a website launch with finish-to-start dependencies connecting each phase:

• Define goals - no dependency, this starts the project.
• Write content - depends on Define goals. You need the goals before you know what to write.
• Design mockups - depends on Write content. Designs should reflect the actual content.
• Build pages - depends on Design mockups. Developers need approved designs before building.
• Review and test - depends on Build pages. There is nothing to test until pages exist.
• Launch - depends on Review and test.

If design slips by three days, the chart immediately shows build, review and launch all shifting by three days. Nobody has to work that out; the arrows do it.

It is worth noticing what this example is not doing. Writing content and designing mockups are linked here because these designs are meant to fit real copy. On a project where the design work could genuinely start from a brief, that link should not exist, and removing it would let the two run in parallel and pull the launch date forward. Same tasks, different project, different answer.

Which tasks should you link, and which should you leave alone?

Link two tasks when the second one is genuinely impossible until the first is finished. Leave them unlinked when the order is a habit, a preference, or just how the team happens to work through a list.

The test that settles most cases: if the first task were delayed by a week, would the second one actually be blocked, or would somebody simply get on with it anyway? If the honest answer is that the work would carry on, the dependency does not belong in the chart. Real blocks usually come from one of a few places:

• A physical or technical prerequisite. The plaster has to dry before painting; the API has to exist before the client can call it.
• An approval or handover. Work cannot proceed without a sign-off, a permit, or a delivery from someone else.
• A shared person or resource. One person cannot do two full-time tasks at once. This is a real constraint, though it is a softer one, and it disappears the moment the work is reassigned.

What is usually not a dependency: tasks assigned to the same team, tasks in the same phase, tasks that feel like they belong in a sequence, and tasks that a template put in that order. Those links get added quickly and are hard to spot later, because a chart full of arrows looks thorough.

When do lag and lead time matter?

Lag is a deliberate gap between two linked tasks. Lead time is the opposite, an allowed overlap. Both exist because "immediately after" is often wrong even when the dependency itself is right.

Lag is the more common and the more useful of the two. Concrete has to cure, paint has to dry, a client has five working days to respond, a legal review takes a fortnight of somebody else's time. Adding three days of lag between pouring and building is more honest than inventing a three-day task called "curing", because nobody is working on it and it should not appear in anyone's workload.

Lead time lets a task start before its predecessor finishes, which is a useful way to model a phase that can begin once the first part of the previous one is available. It is also the easiest thing in a plan to be optimistic about. A two-week overlap between design and build assumes the early designs will not change, and if they do, the overlap converts straight into rework.

If your tool does not support lag, the workaround is simply to leave a gap between the dates and note why. That loses the automatic recalculation, but it keeps the plan readable, which matters more.

What does an over-linked chart cost you?

An over-linked chart is one where nearly every task is chained to the one above it. It has a distinctive look: a long diagonal staircase of bars with almost nothing running in parallel. It is the most common failure in small project plans, and it does three things, all bad.

It hides real parallel work. If two tasks could genuinely happen at once, but the chart says otherwise, the plan shows a longer project than the one you actually have. Teams then plan around a deadline that was never real.

It makes every change explode. One task slipping a day shifts forty bars, most of which did not need to move. After that happens twice, people stop updating the chart, which is the end of it being useful.

It makes the critical path meaningless. If everything is on one chain, everything is critical, and you have lost the ability to say which tasks matter most. That is precisely the question the chart was supposed to answer.

A sensible ceiling for a small project: link the three or four sequences where a delay would genuinely cause a problem elsewhere, and leave the rest. You can always add a link later when you discover it was real. Removing dozens of invented ones is a much bigger job.

What happens when a linked task slips?

The chart moves everything downstream, and you get an honest new end date to react to. That reaction is usually one of four things: absorb the delay if a later task has slack, compress a downstream task, cut scope, or accept the later date and say so early.

What you should not do is drag the bars back so the plan looks on track. A chart that has been quietly adjusted to hide slippage is worse than no chart, because people are now making decisions on a schedule that is not real. The guide on tracking delays goes through spotting slippage early enough to have options.

In Ganttile, linked tasks shift automatically when a predecessor moves, so the cascade happens as soon as you change one date rather than after a round of manual recalculation. That is the practical reason to put dependencies into a tool at all rather than tracking the order in your head.

Common questions about Gantt chart dependencies

Can two tasks share the same predecessor?

Yes, and this is how parallel work gets modelled. If four workstreams can all begin once a kickoff is complete, all four get a finish-to-start link from that kickoff and then run independently.

What is the difference between a dependency and a milestone?

A dependency is a rule between two tasks; a milestone is a single point in time marking a checkpoint. Milestones can have dependencies attached, but they have no duration of their own. The two are compared directly in the guide on milestones and dependencies.

How do I remove a dependency without breaking the schedule?

Delete the link, then check the dates of the task you unlinked. It will keep whatever dates it currently has rather than moving back, so the schedule stays valid but may now show work starting earlier than is realistic.

Where to start

Add your tasks and dates first, then link only the three or four sequences where a delay in one task would genuinely block another. Check that the chart still shows work happening in parallel where it really does, and add further links only when you find a real block you missed.