How to read a Gantt chart: a beginner's guide

Learning how to read a Gantt chart takes about ten minutes, and it pays off every time someone hands you a project plan. At first glance a Gantt chart looks like a staircase of coloured bars. Once you know what each part means, it becomes a one-page answer to three questions: what has to be done, when, and what depends on what.

This guide walks through a chart from left to right, using a small example project, so you can read any Gantt chart with confidence.

The example project

Imagine a team preparing a product launch event. The plan has three phases: Planning, Preparation and Event week. We will refer to this plan throughout the guide.

Task	Duration	Depends on
Set budget and date	3 days	None
Book venue	5 days	Set budget and date
Design invitations	4 days	Set budget and date
Send invitations	1 day	Design invitations
Confirm catering	3 days	Book venue
Event day	1 day	Send invitations, Confirm catering

Start with the layout

A Gantt chart has two halves. On the left is a list of tasks, usually grouped and indented. On the right is a timeline, a calendar that runs from left to right in days, weeks or months. Each task in the list has a row, and the bar in that row shows when the work happens.

If you only remember one rule, remember this: time runs horizontally, tasks run vertically. Anything further left happens earlier. Anything further right happens later.

Read the bars

Each bar has two properties you can read at a glance.

• Position. The left edge of the bar is the start date. The right edge is the end date.
• Length. A long bar is a long task. A short bar is a short one.

In our example, "Book venue" is a five-day bar, so it is visibly longer than "Send invitations", which is a single day. You do not need to read a single number to see that the venue takes longer.

Many charts also shade part of a bar to show progress. If "Design invitations" is half shaded, the work is about 50% done. Compare the shaded portion with today's date: if today is past the end of the bar and the bar is not fully shaded, the task is late.

Follow the dependencies

The arrows or connecting lines between bars are dependencies. They show that one task cannot start, or cannot finish, until another one has done so.

The most common type is "finish to start": the second task begins when the first one ends. In our plan, "Send invitations" cannot start until "Design invitations" is finished, so the chart draws a line from the end of one bar to the start of the next.

Dependencies explain why bars form a staircase. When a task waits for another, it sits to the right of it. When two tasks do not depend on each other, such as "Book venue" and "Design invitations", they can run side by side. If you want a deeper look at the four dependency types, see task dependencies in a Gantt chart.

Why dependencies matter when you read a plan

If "Book venue" slips by three days, everything linked after it moves too: "Confirm catering" and then "Event day". Tasks without a link to the delayed one do not move. Reading the arrows tells you which delays are painful and which are harmless.

Understand groups and subtasks

Real plans have dozens of tasks, so charts organise them into groups. A task group is a parent row, often shown in bold or with a collapse arrow, that contains related subtasks underneath.

In our example, "Planning", "Preparation" and "Event week" are groups. The group bar usually stretches from the start of its earliest subtask to the end of its latest one. That means you can read a chart at two levels:

1. Collapsed, to see the big picture: three phases, one after another.
2. Expanded, to see the individual tasks inside a phase.

Start collapsed when you present a plan to someone senior. Expand only the phase you want to discuss.

Spot the milestones

Milestones are usually drawn as small diamonds or flags rather than bars. They have no duration. They mark a moment, such as "Venue confirmed" or "Invitations sent".

A milestone helps you read the plan because it tells you where the team expects to be at a given date. If a milestone sits at the end of a chain of dependencies and any task in that chain is late, the milestone is at risk. For examples of good milestones and how to choose them, read what is a milestone in a Gantt chart.

Find the tasks that decide the end date

Not every task is equally important to the finish date. Look for the longest chain of linked tasks from the start to the end of the project. In our example, that chain runs from "Set budget and date" through "Book venue" and "Confirm catering" to "Event day". Together those tasks take 3 + 5 + 3 + 1 = 12 working days.

The other branch, designing and sending invitations, takes 3 + 4 + 1 + 1 = 9 working days. It has some slack: it could slip by up to three days before it delays the event. The longest chain is often called the critical path. A delay on the longest chain moves the end date; a delay on a shorter branch may not.

When you read a new plan, ask which chain is the longest. That is where your attention should go first.

Check people and tags

Many Gantt charts also show who is responsible for each task and may let you label tasks with tags such as "design" or "finance". Used well, these let you answer a second set of questions:

• Who is working on the same days? If one person has three overlapping bars, they may be overloaded.
• Which tasks belong to a particular area or client?

ProGantt Flow supports assigning people and tags to tasks, so you can read a chart by person or by theme as well as by date.

A quick checklist for reading any Gantt chart

Next time someone sends you a plan, run through these questions:

1. What is the date range of the timeline, and where is today?
2. Which phases (groups) make up the project?
3. Which tasks are done, in progress or late, judging by shading and today's date?
4. Which tasks depend on others, and what moves if one slips?
5. Where are the milestones, and which chain of tasks leads to each one?
6. Which chain is the longest, and does it have any slack?
7. Who is assigned to what, and does anyone appear overloaded?

If you can answer these seven questions, you have read the chart.

From reading to building

Reading a chart is the first half of the skill; building one is the second. When you are ready to create your own, how to create a project schedule step by step shows the order that works: list the work, estimate durations, add dependencies, then place milestones.

You can try this with the launch event example in the ProGantt Flow editor: add the six tasks, link them as shown in the table and watch how moving one bar moves the others.