Gantt charts are not the enemy — bad dependencies are

The standard objection to Gantt charts is that they are obsolete waterfall artefacts that fall apart on contact with reality. What actually falls apart is a schedule where every task is chained finish-to-start to the one before it. That is not planning, it is a queue with dates attached.

The four dependency types, and when each is correct

• Finish to start (FS). B cannot start until A finishes. Correct when there is a genuine hand-off: you cannot pour foundations before the excavation is done. Overused everywhere else.
• Start to start (SS). B cannot start until A starts. This is the one most teams need and never use. Copywriting and design can run together; they just cannot begin before the brief is signed off. SS with a lag of two days models real parallel work.
• Finish to finish (FF). B cannot finish until A finishes. Ideal for QA trailing development, or documentation trailing a feature.
• Start to finish (SF). Rare and usually a modelling mistake. Legitimate for shift handovers. If you reach for it, check whether you actually mean FS reversed.

Lag and lead are not cheating

A three-day lag on an FS link ("concrete cures") is real information. Teams instead insert a fake task called "wait for curing", which pollutes throughput metrics and assigns a human to waiting. Use lag.

Stop modelling resource contention as a dependency

The most common bad link: "B depends on A because Sarah does both." That is not a logical dependency, it is a capacity constraint. Model it in the workload view, not the schedule. If you encode it as a dependency and Sarah goes on holiday, your whole chain shifts for a reason that no longer exists — and nobody remembers why the link is there.

The critical path is a question, not an answer

The longest chain of dependent work tells you where a one-day slip becomes a one-day slip to the deadline. Everything off the path has float. The useful move is not to stare at the path but to ask: can I break a link on it? Converting one FS link to SS with lag on the critical path shortens the project more than any amount of pressure on the team.

A schedule you can maintain

Three rules. First, no dependency without a stated reason — if you cannot say why in one sentence, delete it. Second, prefer SS and FF for work that overlaps in reality. Third, keep the dependency graph shallow: milestones as anchors, dependencies within a phase, not a 200-link chain from kickoff to launch. Then when a date moves, the chart shifts what genuinely has to shift, which is the entire reason to have one.

---