Dependencies without the spaghetti

Dependencies are the most useful and most abused feature of any Gantt chart. A few rules keep them helpful.

A dependency says "this can't start until that is done." Used well, it's the fastest way to see how a delay ripples through a project. Used badly, it turns the chart into a web of arrows nobody reads.

Link blockers, not relationships. A dependency means real blocking. "Design the page" blocks "build the page." "Write the blog post" and "update the pricing page" might be related, but neither waits on the other. Relationships belong in comments or labels.

Prefer finish-to-start. Almost every real dependency is finish-to-start: B starts when A finishes. Start-to-start and finish-to-finish have their uses, but if you find yourself reaching for them often, the tasks are probably split in the wrong place.

Keep chains short. If a chain runs ten tasks deep, a one-day slip at the start moves the end by a day even when later tasks had slack. Look for places where work can start in parallel with a draft or a stub.

Add lag only for real waiting. Lag means waiting time that isn't work: a vendor's lead time, a legal review, paint drying. Don't use lag to pad estimates. Padding belongs in the estimate, where everyone can see it.

Review the critical path weekly. The critical path is the chain that sets the end date. Those are the tasks where a delay really hurts, so that's where to look first in every planning meeting.

A quick test. Pick any arrow on your chart and ask: if the first task slips a week, should the second one move? If the answer is "not really," delete the arrow.