How do you build a Gantt with realistic dependencies?
A useful Gantt has explicit dependencies (FS/SS/FF/SF), a small number of clear milestones, and recalculates the critical path automatically when a task slips. Without that, it is just a coloured Excel calendar.
Fake Gantts are visual tools where everyone estimates "about 2 weeks" and no one tracks how a slip on task A moves the overall delivery. Real Gantts have coded dependencies (Finish-to-Start, Start-to-Start, etc.), a visible critical path and automatic updates as reality diverges — that is what turns them into a control instrument, not a slide.
1. The dependency types matter
Finish-to-Start (FS) is the most common: task B does not start until A finishes. But it is not the only one. Start-to-Start (SS): B starts when A starts (parallel, but not earlier). Finish-to-Finish (FF): B finishes when A finishes (shared deadline). Start-to-Finish (SF): rare, but real in maintenance scheduling.
A Gantt that only allows FS oversimplifies. "Infra setup must be done before deploy starts" is FS. "QA starts when dev starts (in parallel)" is SS — without SS you cannot model teams working end-to-end on the same feature.
2. The critical path must be visible
The critical path is the chain of tasks where any slip pushes the final date. Tasks off the critical path have "float" (slack) — they can slip without affecting delivery.
Without a visible critical path, PMs treat all slips equally and panic at the wrong ones. With it, decisions become clear: "This is on the critical path — add another dev. This is not — let it slip 3 days, it does not affect anything". The tool must recalculate the critical path on every move, not force you to recompute it in your head.
3. Few, concrete milestones
Max 5-7 milestones for a 3-6 month project. Each is a verifiable deliverable: "Backend API v1 deployed to staging", "Full UI user flow", "Live pilot with first customer". Not "Sprint 3 closed" — that is a calendar entry, not a milestone.
Milestones are your stakeholder communication points. Between milestones you give standard status updates; at milestones you give concrete demos. Too many (10+) and they lose meaning. Too few (1-2) and you catch deviations too late.
4. Buffer on the critical path, not everywhere
Add buffer (slack days) at the end of the critical path — not sprinkled across every task. Concentrated buffer absorbs the cumulative slip of all critical-path tasks.
Critical Chain Project Management (Goldratt) shows that a concentrated 30-50% buffer on the critical path is far more effective than 20% on each individual task — because tasks running ahead lend time to tasks running behind.
5. Daily updates, not monthly
A Gantt updated once a month is fiction. Reality diverges daily — dependencies surface, vendors slip, scope clarifies. The Gantt must reflect current state at any moment.
Practically: any change to a task (status, duration, start date) auto-recalculates dependencies, the critical path and the final date. The PM sees the impact of any change instantly — and can warn the stakeholder a week in advance, not a day after it happened.
Gantt with dependencies in 4myprojects
FS, SS, FF, SF — all dependency types native, the critical path visible on the timeline, milestones pinned to the board and, on the insights page, the tasks due in the next 7 days plus the project risk level.