A Gantt chart is a horizontal bar chart used to visualise a project schedule. Each bar represents a task or work package, positioned along a time axis to show when it starts, when it ends and how it overlaps with other work. Most Gantt charts also draw arrows between bars to show dependencies — task B can’t start until task A finishes.
Gantt charts originated in early 20th-century industrial planning and have been a staple of project management ever since. They are well suited to work where scope is fixed up front, dependencies are well understood and the critical path matters more than learning along the way.
Where Gantt charts work well
- Construction, manufacturing, event production — domains where the steps are knowable, sequential and rarely change once committed.
- Compliance and regulated programmes — where a defensible schedule is part of the deliverable.
- Coordinating across many fixed-deadline parties — when handoffs between teams or vendors are the main risk.
Where Gantt charts struggle
- Software product development — by the time a Gantt chart is detailed enough to be useful, the underlying assumptions have already changed.
- Discovery work — Gantt charts presume the answer is known. Discovery is the work of finding the answer.
- Long horizons — bars stretching beyond a quarter or two communicate false precision; the further out the bar, the less the date means.
Most modern product teams have replaced Gantt charts with roadmaps — Now-Next-Later horizons, outcome-based roadmaps, or release plans built on top of story maps — that show direction and intent without committing to specific dates that will inevitably move.
Gantt chart vs roadmap
A Gantt chart shows what will happen and when. A roadmap shows what we believe is worth doing and roughly when. The first is a commitment; the second is a current best understanding. For most software products, the second is more honest.
Further reading
