The Gantt chart

Henry L. Gantt · 1910s

Every task drawn as a bar against a calendar, so that duration, overlap and sequence can be seen at once.

Its place in the frameworkTime Core›Project management

What it does

More than a century old and still the default way work is shown over time. What it does well is expose two things that are invisible in a task list: how much is happening at the same moment, and which things cannot start until something else finishes. Adding the dependencies is what turns it from a picture into a plan.

Reach for it when: When a schedule exists only as a list of dates and nobody can see where the load falls.
Where it stops: It shows the plan, not the risk in it, and it invites false precision — a bar drawn to the day looks like a commitment even when the estimate behind it was a guess. For work that is discovered as it goes, it ages within a week.

Developed by Henry L. Gantt around 1910–1915; a similar chart was published by Karol Adamiecki in 1896.

Why it sits at Project management

Getting defined work done by a date: agreeing what it is, sequencing what depends on what, running it, and ending it properly.

A model is only useful when you reach for it at the right moment. This one answers a question that arises here — so it is filed here, and nowhere else. These are the working areas it serves:

Defining the workScope-definition practice and the requirements literature on ambiguity as the dominant source of rework.
SequenceCritical-path analysis, and the constraint literature on dependencies rather than effort as the binding limit.
Running itEarned-value and flow-based approaches to progress, and the research on optimism bias in self-reported status.
ClosingPost-implementation review practice, and reference-class forecasting, which uses recorded outcomes to correct estimation.

All of Project management

What it touches elsewhere

Nothing in a business is decided on its own. A conclusion reached with this model at Project management lands in these other cores, whether or not anyone follows it there.

Goal CoreA project exists to achieve a goal; where it cannot be traced to one, it is activity.
Business CoreProjects consume the capacity of people who also have operational work, which is where most delays originate.
Contingency PlanningWhat happens when a project slips is decided there, and it should be decided before it slips.
Data CoreEstimate accuracy is measurable and improves only when it is measured.

Filed at the same place

These answer questions that arise at Project management too. Where they disagree with this one, the disagreement is the useful part.

The critical path methodThe longest chain of dependent tasks sets the finish date, and only that chain does.
Stage-gateWork proceeds in stages separated by decision points where a project can be stopped.
ScrumFixed short cycles producing something usable, with the plan reconsidered at the end of each one.
The RACI matrixFor each task, name who does it, who answers for it, who must be asked and who must be told.

Elsewhere in Time Core

These are other people’s models, named here so you can go to the source and use them properly. The Omnigoal is not affiliated with their authors and is not endorsed by them; nothing of theirs is reproduced here — no canvas, no diagram, no wording. Each is described in our own words, with the originator credited, because the framework is a place to put thinking, not a replacement for the people who did it. Model names and trademarks belong to their respective owners and are used here only to refer to the work itself.

All 125 models