Gantt Chart: A Clear Guide to All 6 Elements

A Gantt chart is a view of a schedule, not a schedule. That distinction sounds
pedantic until you meet the project whose plan is a set of coloured bars nobody can recalculate,
drawn once at kick-off and manually nudged rightwards every month until it quietly stops being
updated.

What a Gantt chart shows

Tasks run down the left, time runs across the top, and each task is a horizontal bar spanning its
start and finish. That is the whole idea, and its usefulness comes from what you layer onto it.

A chart with the first two and none of the others is a picture. It cannot tell you what happens if
a task slips, because nothing is connected to anything.

Dependencies are what separate a plan from a drawing

This is the single highest-value thing to get right. Once tasks are linked, moving one moves
everything downstream automatically, and the chart starts answering questions instead of just
displaying assertions. Without links, every slip has to be re-drawn by hand, which is why unlinked
charts stop being maintained by about week six.

Linking also exposes the critical path — the longest chain of dependent tasks, and therefore
the sequence where any delay moves the end date. Tasks off the critical path have float, and knowing
which is which is what lets you decide where to spend attention when something goes wrong.

Baseline it, or you cannot report variance

A Gantt chart without a saved baseline can only ever show you today’s plan. Baseline it at
authorisation — the same moment the
project initiation document is
agreed — and every subsequent view can show planned against actual. That comparison is the
entire reporting value of the chart, and it is unrecoverable if you skip it.

Where Gantt charts go wrong

• Too much detail. A 400-line chart is unmaintainable and nobody reads it. Plan the
  near term in detail and later phases at a coarser level, then refine as they approach.
• Durations that are really effort. Five days of work for someone who is 50%
  allocated is ten elapsed days. Charts built on effort run consistently and mysteriously late.
• No float anywhere. A plan where every task starts the day its predecessor ends is
  a plan with no tolerance for reality.
• Resources ignored. A chart can happily show one person doing four things at once;
  it will not warn you unless you have loaded resources.
• Updated by dragging. Moving a bar because the date passed, rather than recording
  progress and letting the schedule recalculate, is how a chart becomes fiction.

Building a Gantt chart that stays useful

1. Break the work down first. Decompose to the level where a task has one owner and
   a duration you can defend, then stop. Scheduling before decomposing produces bars with no meaning
   behind them.
2. Estimate in elapsed time, with availability applied. Or estimate effort and let
   the tool apply allocation — but be explicit about which you are doing.
3. Link every task to at least one other. An unlinked task is either genuinely
   independent or, far more often, a missing dependency.
4. Add milestones for external commitments. Board dates, regulatory deadlines,
   customer gates. These are what senior readers look for.
5. Load resources and look for over-allocation. Then fix it by levelling, not by
   hoping.
6. Baseline, then never edit the baseline. Changes to it go through change
   control.
7. Update by progress, not by date. Record percent complete or actual finish, and
   let the chart recalculate what that does to the end date.

Choose the format for the audience

The working chart and the reporting chart are different artefacts, and trying to make one serve
both is why executives get sent 400-line schedules they cannot read.

Keep the detailed chart in a scheduling tool for the delivery team. For the board, produce a
timeline view showing phases, milestones and the current position against baseline — usually a
handful of bars on one slide. Deriving the second from the first takes minutes; maintaining two
independent plans takes forever and they will disagree.

Where the Gantt chart fits with the standards

PMI’s PMBOK Guide
reached its Eighth Edition in November 2025, with schedule as one of its seven performance domains,
and ISO 21502:2020
covers scheduling as a practice without prescribing a technique. Neither mandates a Gantt chart —
it is a convention, and a good one, but the requirement is a schedule that can be managed, not a
particular way of drawing it.

Gantt chart, PERT and the critical path method

Three techniques get conflated because they all touch the schedule, and knowing which does what
saves a lot of confused meetings.

The Gantt chart is a presentation of the schedule against a calendar. It is where
you look to answer “when does this happen?”

The critical path method is a calculation over the dependency network. It answers
“which delays actually matter?” A Gantt chart can display the critical path once it has
been calculated, but drawing bars does not calculate it — the dependencies have to be there
first.

A PERT chart shows the same network as a node diagram rather than against a
calendar, and traditionally carries three-point estimates — optimistic, most likely, pessimistic
— to reason about duration uncertainty. It answers “how confident are we in this
estimate?”

In practice most teams build the network, let the tool calculate the critical path, and present the
result as a Gantt chart. The three-point estimating discipline is worth borrowing even if you never
draw a PERT diagram, because a single-point estimate hides how much you do not know.

What a Gantt chart cannot tell you

It is worth being clear about the limits, because charts project more authority than they earn.

• Whether the estimates are any good. A beautifully linked schedule built on
  optimistic durations is a precise picture of a fictional project.
• Whether the work is actually being done. Percent complete is self-reported, and
  the last 10% famously takes as long as the first 90.
• Quality. A task can finish on time and produce something that fails testing,
  which the chart will happily show as green.
• Whether the plan is still the right plan. Schedules encourage you to optimise
  delivery of what was agreed, which is a different question from whether it is still worth
  delivering.

None of that is an argument against Gantt charts. It is an argument for reading them alongside the
risk register, the quality gates and the business case rather than treating the chart as the project.

Frequently asked questions

What is a Gantt chart used for?
Showing what work happens when, how tasks depend on each other, and how actual progress compares with
the agreed baseline.

Do I need MS Project to build one?
No. Excel is perfectly adequate for small and medium projects, and a Word or slide version is often
better for reporting. Dedicated tools earn their place when dependency networks and resource levelling
get complex.

How detailed should a Gantt chart be?
Detailed enough that each task has one owner and a defensible duration, and no more. Plan imminent
work finely and distant work coarsely.

What is the critical path?
The longest chain of dependent tasks through the project. Any delay on it moves the finish date;
delays elsewhere consume float first.

Are Gantt charts useful on agile projects?
At the release and roadmap level, yes — for showing phases, dependencies and external
commitments. For sprint-level work they add little that a backlog and burndown do not already give
you.

Where this leaves you

A Gantt chart earns its keep when it can recalculate. Decompose the work, link every task, mark the
milestones other people care about, load the resources, baseline it, and then update by recording
progress rather than by dragging bars. Do that and the chart answers questions; skip the links and the
baseline and you have an attractive drawing that will be quietly abandoned by week six. Keep the
detailed version for the team and derive a one-slide timeline for the board from it, rather than
maintaining two plans that will eventually disagree.

References

• ISO 21502:2020 — Project, programme and portfolio management: guidance on project management.
• PMBOK Guide, Eighth Edition — schedule is one of the seven performance domains.

More on project management

• The Gantt chart — you are here
• Structured project management
• The project initiation document
• The RAID log
• The project status report
• Project closure and lessons learned

All of these are covered by the Project Management Toolkit, or start with the free ISO templates.