Gantt chart with dependencies: linked bars that move when a date slips

A Gantt chart with dependencies is supposed to answer one question: if this task slips by three days, what else slips. Most Gantt charts cannot answer it. They show bars in date order, arrows are drawn between them by hand, and when a date moves the arrows keep pointing at the old positions. The chart is a picture of a plan rather than a model of it, and the difference only becomes visible on the day something goes wrong.

The distinction worth holding on to is between drawn dependencies and calculated dependencies. A drawn dependency is a line on a diagram. A calculated dependency is a rule the tool enforces, so that moving one bar moves every bar downstream of it. Everything else in this topic, meaning the four link types, lead and lag, and the critical path, only works if the second kind is in place.

The four link types, and the two that get used

Project scheduling defines four relationships between two tasks. The names describe which end of each bar is tied to which.

Finish to start. The successor cannot start until the predecessor finishes. Drafting has to finish before review starts. This is the default in every tool and accounts for most real links.

Start to start. Both tasks start together, or the successor starts once the predecessor has started. Writing documentation can begin once development begins, without waiting for development to finish.

Finish to finish. Both tasks have to finish together, or the successor cannot finish until the predecessor does. Testing cannot be declared complete before the last feature is complete, even though testing runs alongside development.

Start to finish. The successor cannot finish until the predecessor starts. This appears mainly in handover situations, such as a night shift that cannot end until the day shift has begun. It is rare enough that some tools omit it.

In practice, finish to start and start to start cover the large majority of links on a working schedule. The temptation worth resisting is modelling every relationship. A chart with a dependency on every pair of tasks becomes impossible to change, because a one day move triggers a cascade through forty bars and the schedule no longer matches reality. Link the relationships that would actually stop work, and leave the rest as ordering.

Lag and lead are part of the link, not part of the task

A common modelling mistake is to absorb waiting time into a task bar. Concrete has to cure for seven days. Writing a seven day task called "curing" puts a bar on the chart that nobody is working on, which distorts the workload view and makes the resource plan wrong.

The correct home for that time is on the link itself, as lag. A finish to start link with seven days of lag says the successor starts seven days after the predecessor finishes, without inventing a task. The same applies to review cycles where an external party has a fixed turnaround, and to any delay imposed from outside the team.

Lead is the mirror image and is written as negative lag. A finish to start link with two days of lead lets the successor begin two days before the predecessor finishes, which models a legitimate overlap. It is safer than splitting a task in two just to create an overlap, because the link keeps the relationship visible.

The test for whether something is a task or a lag is simple: if it would show up on somebody's workload for the week, it is a task. If it is waiting, it is lag.

Why the critical path stops being useful

Once dependencies are calculated rather than drawn, the tool can compute the longest chain through the schedule. That chain is the critical path, and everything on it has zero float, meaning a one day slip on any of those tasks moves the end date by one day. Everything off it has some slack.

The critical path is genuinely useful for one purpose: deciding where attention goes. It stops being useful in two situations that are both common on small team projects.

The first is when almost everything is on it. That happens when dependencies have been over-modelled, so nearly every task is linked to nearly every other. If 80 percent of a schedule is critical, the concept has no discriminating power left and the correct response is to remove links, not to work harder.

The second is when the real constraint is people rather than sequence. A two person team running six parallel workstreams is not limited by which task follows which. It is limited by the fact that the same person is on four of the six. The critical path does not see that, because it models sequence and not capacity. Reading a resource or timetable view alongside the Gantt is what catches it, which is why tools that keep schedule and workload on the same data are easier to trust than tools where the two views come from separate files.

What each option actually does when a date moves

The practical question about any tool is what happens after dragging a bar. The table below separates the tools that draw dependencies from the tools that calculate them, based on what the vendors document.

Option	Dependencies supported	What happens when a predecessor slips	Availability
Excel stacked bar chart	Not part of the chart type	Nothing. Bars are chart data, and links are shapes drawn on top	Microsoft states Excel "doesn't have a predefined Gantt chart type"
Excel or Sheets template with formulas	Start dates can be formula driven	Downstream dates recalculate only where a formula was written for them	Depends entirely on the template
Desktop scheduling software	All four link types, plus lag, lead and critical path	Full recalculation, with calendars and working days respected	Paid licence, single file per project
Asana	Task dependencies available	Recalculates on the plans that include them	Dependencies, timeline and custom fields start on the Starter plan
monday.com	Dependency column with configurable behavior	Recalculates according to the dependency setting chosen on the column	Timeline and Gantt views are listed from Standard, the second paid tier. Dynamic dependencies are listed on Pro
Trello	Not a native board feature	Card due dates are independent of each other	Free plan allows up to 10 boards and up to 10 collaborators per Workspace

The Excel row is the one worth pausing on, because spreadsheet Gantt charts are still the most common starting point. Microsoft's own instructions describe building one by "customizing a stacked bar chart to show the start and finish dates of tasks," and the documented method covers removing the fill from the start date series and reversing task order. Dependencies are not mentioned, because the chart has no concept of them. Arrows in a spreadsheet Gantt are drawn objects. They are as accurate as the last time somebody dragged them, which is the source of the specific failure where a chart looks maintained and is three weeks stale.

Setting the links up so they survive contact with the team

The order of work matters when dependencies are being added to an existing schedule. Building the full network first and inviting the team afterwards produces a chart that collapses on the first real change, because the links encode one person's assumptions about how work queues.

A sequence that holds up better starts from the tasks rather than the arrows. First, get every task on the chart with an owner and a duration, and nothing linked. Second, ask each owner one question: what has to be finished before you can start. The answers are the links that matter, because they come from the person who would be blocked. Third, add only those links, then drag the first task two days later and watch what moves. If the cascade surprises anyone, the surprise is information about the plan, not a bug in the tool.

Give the durations somewhere to absorb a slip

A schedule where every task is estimated at exactly its expected duration will always finish late, because half of the tasks overrun and there is no room anywhere. The usual fix on a small team is not padding each task, which hides the slack and invites it to be consumed. It is holding a small number of visible buffer periods before the dates that are promised outside the team, so the cascade has somewhere to land.

Decide who is allowed to move a bar

Calculated dependencies mean one drag changes many dates. That is the point of the feature and also the reason a schedule needs a named owner for structural changes, while individual task completion stays with whoever does the work. Without that split, either nobody touches the chart or everybody does, and both outcomes end with a plan nobody believes.

The cost that does not appear in the tool comparison

A Gantt chart with working dependencies removes a specific piece of labour: recalculating dates by hand after every change. On a project with thirty tasks and a weekly change, that is a real saving and it is why the feature sits behind paid tiers.

It also introduces a cost that comparisons rarely mention. A calculated schedule has to be fed. Someone has to mark tasks as actually finished, not just planned to finish, or the recalculation runs on fiction. The chart will confidently move fifteen bars based on a completion date that nobody confirmed, and the output looks more authoritative than the hand drawn version while being less true.

This is why the update path matters more than the feature list. If marking a task complete requires opening a separate scheduling file that one person owns, the updates will lag by days and the dependency engine will be computing from stale inputs. If the same task can be moved on a board by the person doing the work, and the Gantt view reads from that same task, the inputs stay current without anyone maintaining a schedule as a second job. Checking whether a tool keeps its board, calendar and Gantt views on one underlying task rather than on synchronised copies, which a Features page should state plainly, is a better predictor of whether the chart stays accurate than any comparison of link types.

One more practical point on ownership. A schedule held in a file has one editor at a time, so everyone else is reading a version. A schedule held in a shared tool can be read by everyone while one person edits it. For a small team, that difference decides whether the Gantt becomes the shared reference or a document that gets exported to PDF and emailed, which is the same as not having dependencies at all.

What to change first

Open the current Gantt chart and drag one bar two days later. If nothing downstream moves, the dependencies are drawings and the chart is a picture, so the next decision is about tools rather than technique. If bars do move, check instead whether anyone is marking real completion dates, because a recalculating chart fed stale data is the more expensive failure. Comparing how tools handle the same schedule side by side, starting from All comparisons or the plan limits on Pinateca, makes the trade between link types and update discipline easier to see.

Q1. Can a Gantt chart with dependencies be built in Excel?

Bars can be built in Excel, and Microsoft documents the method as customizing a stacked bar chart, while stating that Excel has no predefined Gantt chart type. Dependencies are a different matter. Arrows between bars are drawn shapes and do not recalculate, so a date change has to be carried through by hand or by formulas written for each link.

Q2. Which dependency type should be the default?

Finish to start, because it matches how most work actually queues. Start to start is the useful second option for tasks that run in parallel after a common trigger. Finish to finish and start to finish exist for specific cases such as testing that must end with development, or a handover between shifts, and using them without a clear reason makes a schedule harder to change.

Q3. Why does the whole schedule turn critical?

Usually because too many dependencies were created. If nearly every task is linked to nearly every other, the longest chain runs through almost everything and the critical path loses its ability to point anywhere. The fix is to remove links that describe preference rather than genuine blocking, and to keep only the relationships that would actually stop work.

Q4. Is it worth paying for dependency features on a small team?

It depends on how often dates change. On a project where the plan holds, ordering tasks by date is enough. On a project where an external review or a client approval moves a date every second week, recalculating by hand is where the hours go, and the paid tier pays for itself. Note that dependencies commonly sit on the first or second paid tier rather than on free plans.