Gantt Charts: Visualising the Schedule

OnceOnce a Work Breakdown Structure has produced a list of work packages, someone still has to lay them out in time and show how they depend on each other. The Gantt chart is the tool almost everyone reaches for first — a horizontal bar for each task, plotted against a calendar. It is one of the oldest visual tools in project management, and one of the most misunderstood: read correctly it is genuinely useful, read as more than it is it becomes a source of false confidence.

A More Complicated History Than the Name Suggests

TheThe chart is named for Henry L. Gantt, the American mechanical engineer and management consultant who published the design that spread through Western industry, in articles in 1910 and 1915, with adoption accelerating through the rest of that decade¹. That is the story most sources tell, and it isn't wrong — but it isn't the whole story either.

A functionally similar bar-chart scheduling tool, the harmonogram, was developed earlier by the Polish engineer Karol Adamiecki, with roots as early as 1896 and a public description by 1903². Adamiecki published in Polish and Russian, languages that did not travel into the English-language management literature of the period; by the time a wider English-language account of his work appeared in 1931, Gantt's version — publicised in English from 1910 onward and later popularised further by Wallace Clark's book on the subject — had already become the standard reference in the West². So the honest version of this history is: two engineers independently arrived at essentially the same idea a decade or so apart, and the one whose language reached a wider audience got the name attached to it. Worth knowing before treating "the Gantt chart" as a single clean origin story.

How to Read One

TheThe mechanics are simple, which is exactly why the chart is popular:

• Bars represent tasks, positioned on a horizontal time axis; bar length is the task's planned duration.
• Rows are typically ordered to roughly follow the WBS the tasks came from, so related work clusters visually.
• Arrows between bars show dependencies — which tasks must relate to which others before/after. These are the same dependency relationships used in Critical Path Method scheduling, just drawn rather than calculated.
• A vertical "today" line (in most modern tooling) shows planned vs. actual progress at a glance.

Dependency arrows come in four standard types, and knowing all four (not just the obvious one) matters for reading a real chart correctly³:

A Worked Example

HereHere is a small schedule for the room-booking project from the Work Breakdown Structure page, with task labels carrying the same objective codes (O1, O2...) this site's Project Initiation Document guidance recommends — the point of that coding scheme is exactly this: a task on a Gantt chart, a line in a risk register, and a paragraph in a report should all be able to cite the same stable identifier, rather than three different ad-hoc descriptions of what is supposedly the same piece of work.

Three things in this chart are doing different jobs, and conflating them is a common source of confusion when a schedule is first drawn.

Milestones, Tasks, and Continuous Activities

• Tasks are the ordinary bars — O1 through O7 above — each with a real duration, an owner, and a place in the dependency chain. Most of a WBS's work packages become tasks.
• Milestones are zero-duration markers — "Requirements sign-off" above — that represent a moment, not a span of work: a decision made, an approval granted, a phase gate passed. A milestone has no duration to estimate and nothing to resource; its only job is to be a stable point everyone can reference ("we're past the sign-off milestone") and, often, a formal go/no-go gate. Treating a milestone as if it were a very short task is a common mistake — there is nothing to "do" for a milestone, only something to confirm has happened.
• Continuous activities — "Project management" above — run for most or all of the project's duration rather than sitting inside the sequential flow of work packages. Project management itself, quality assurance, risk-register maintenance, and stakeholder communication are the classic examples: they don't precede or follow any particular task, they run alongside all of them. A WBS should still capture this work explicitly (see the 100% rule discussion above — "Project management" was its own sub-deliverable in the worked example precisely so this time doesn't disappear), but on a Gantt chart it's drawn as one long bar spanning the relevant period rather than threaded through the dependency chain like an ordinary task, because it genuinely isn't sequenced the way the other work is.

GettingGetting this distinction right matters for reading someone else's chart correctly: a bar that never seems to have a dependency arrow in or out is very often a continuous activity, not a task someone forgot to sequence.

What a Gantt Chart Doesn't Show You

TheThe chart's biggest risk is that it looks more authoritative than it is. Specific limitations worth naming explicitly rather than discovering the hard way:

• Resource contention is invisible. Two bars can sit side by side, perfectly non-overlapping in time, while both are secretly assigned to the same one person. The chart shows the schedule as if resources were infinite; it says nothing about who is actually available when.
• It creates false precision. A bar drawn to a specific day looks exact, which tempts everyone — including the person who drew it — into treating a rough estimate as a firm commitment. The visual doesn't distinguish "we measured this" from "we guessed this."
• It stops being readable at scale. A chart with a few dozen tasks is a useful communication tool. A chart with several hundred, several teams, and dense dependency arrows becomes visual noise that nobody actually reads task-by-task — it becomes decoration, not information.
• It has no native way to express uncertainty. Every bar implies a single, deterministic duration. Real task durations are distributions, not points — optimistic here, pessimistic there — and a plain Gantt chart has no way to draw that. This is precisely the gap PERT's three-point estimation was built to fill; the two techniques are best understood together, not as competitors.

None of this makes Gantt charts a bad tool — for communicating a schedule to stakeholders, at a scope where it stays readable, nothing beats it. The discipline is knowing what it isn't telling you. For the calculation that actually determines which tasks are schedule-critical (the ones a Gantt chart's arrows imply but don't compute), see Critical Path Method and PERT. For how the task list on the chart got decided in the first place, see Work Breakdown Structure.

References