How to read a Gantt chart: an annotated example

Where do you start reading a Gantt chart?

Start at the edges, not the bars. The left side lists the work, usually grouped into phases, and the top shows the timescale. Until you know both, a bar's length tells you nothing useful.

In the launch plan, the groups include Product readiness, Documentation, Support readiness and Go/no-go and launch. A group's summary bar spans its tasks. Read those labels first to understand the shape of the project, then expand the detail you need.

Check whether the columns represent days, weeks or months. A one-day review can be a sliver in week view, while a ten-week plan may need scrolling in day view. Shaded weekends also matter: a Friday finish followed by a Monday start is not necessarily a delay.

Many charts also carry columns beside the task names. Ganttile's include the start date, the duration and an estimate for each task. When you need an exact date, read it there rather than judging it from where a bar sits against the scale.

What does each bar actually tell you?

A bar tells you two things: when a piece of work starts and how long it is planned to run. Bars that overlap are happening at the same time, and bars that line up end to start are happening one after another. Most of what a Gantt chart is for comes down to those two patterns.

Start with Engineering: finish the release. It runs about three weeks from the middle of week 2. After it finishes in week 5, the beta, help articles and sales script run alongside one another until the end of week 6. Their overlap shows parallel work; their incoming arrows explain what must happen before they can start.

Bar length shows elapsed time on the chart, not hours of work. The release build carries an estimate of 120 hours, while the roughly week-and-a-half beta carries 20 hours because much of it is waiting for feedback. Check the effort estimate before deciding how busy a team is.

A bar often does not tell you who, either. Some tools write the owner's name on the bar or in a column. The launch plan puts the role at the front of each task name, as in Support: team training or Sales: pitch and demo script. If the chart you received shows neither, ask. A task with no visible owner is the one most likely to be found late.

Which way do the arrows run, and what is waiting on what?

An arrow runs from a predecessor to a successor. The edges it connects matter: end-to-start means the successor cannot start until the predecessor finishes. All 36 links in this launch plan are finish-to-start, so read them as "finish this before starting that".

Other charts may use start-to-start, finish-to-finish or start-to-finish links. Those constrain different events; they do not all mean one task must finish before the next starts. Check the four dependency types if an arrow connects different edges.

The useful reading is less about the type and more about the pattern of arrows around a task:

• Many finish-to-start arrows in: the task waits for every predecessor to finish. Launch team: readiness review has six arrows coming in from the five readiness tracks, with Documentation sending two (the screenshots and the release notes), so it waits on whichever of them finishes last. On a launch plan, that is the row to watch.
• Many arrows out: check who is affected. Here the release build feeds the beta, help articles and sales script with little or no gap. Elsewhere, a successor may have enough spare time to absorb a delay.
• A gap before the next task: ask what it represents. In this example, the escalation work finishes in week 3 and training starts in week 7. That may leave flexibility, but on another chart the gap could be required waiting time, a fixed date or limited availability. Check the link and calendar before calling it float.
• No arrows at all: either the task genuinely does not depend on anything, or nobody linked it. The chart cannot tell you which. It is worth asking, because an unlinked task stays where it is when the work around it moves.

In tools that reschedule for you, the arrows are also why one change ripples through the plan. In Ganttile, with Auto schedule turned on, moving a task moves the tasks its arrows point to, so a chart that was updated recently shows the knock-on effects already worked out.

What do the diamonds and markers mean?

A diamond usually marks a milestone: an event with no work duration, such as an approval, handover or launch. The Association for Project Management's glossary associates milestones with key events and acceptance of deliverables. Read the name to see what must be true at that point.

Ganttile's templates represent these events with short, coloured one-day task rows. They stand for milestones, but are not zero-duration scheduling objects: their dates and links still need checking when the plan moves. The launch plan includes Launch brief agreed, Release candidate ready, Go/no-go decision and Launch day. Those names tell a useful short version of the plan.

Two things are worth checking on each milestone. First, is it linked? A milestone with arrows running into it moves when the work before it moves. One sitting on a fixed date with nothing attached keeps showing the original date long after the work behind it has slipped. Every milestone in the launch plan is linked. Second, what does the name commit to? "Release candidate ready" is clear. "Phase 2 complete" often is not, and it is fair to ask what has to be true for it to count. What makes a good milestone goes further into that.

How can you tell what is done and what is late?

Compare the bars with today. Anything that should have finished before today and is not marked done is either late or not updated, and the chart alone cannot tell you which. That comparison is the most useful thing a reader can do with a chart, and it is also where charts are most often out of date.

Most tools mark today with a vertical line down the chart. In Ganttile, today's column is shaded when the chart is zoomed to days. Everything to the left of it is the past, and the past is where you find out whether the chart is being kept up.

Some charts fill each bar to show percent complete. Read the legend and ask how progress is measured: 60 percent might mean six of ten deliverables accepted, or it might be someone's rough judgment. The display is only as useful as the measure behind it.

Ganttile marks tasks done or not done. Look for unfinished bars to the left of today, then ask whether the work is late or the chart needs updating.

What neither version shows is how far the plan has moved since it was first agreed: unless someone kept a baseline of the original dates, a launch day that has slipped twice just shows the new date as if it had always been there. Comparing plan against actual covers how the person running the plan keeps that comparison.

Is the critical path marked, and what is it telling you?

The critical path is the sequence that controls the forecast finish. In a simple schedule without imposed date constraints, its tasks have no total float: a delay pushes the finish unless the plan changes. Ganttile highlights critical tasks when Critical path is on. More than one path can be critical.

In the launch plan, follow the product work through the build, beta, fixes and release candidate into the readiness review and launch. In this template, the release candidate, support training and sales training have no spare time. Screenshots and marketing readiness each have two working days; release notes have three.

Those float figures use a working-day calendar. In Ganttile, that means Hide weekends is on. With Auto schedule also on, a three-working-day beta overrun moves the launch, while a two-day screenshot overrun can use its available float. Check the settings before applying those numbers to another chart.

If the critical path is not marked, ask the schedule owner to identify it or calculate it from durations, links and calendars. Touching bars alone are not proof: required waiting time and constraints can change the result. Finding the critical path walks through a worked example.

What should you ask the person who sent it?

Six questions establish what the dates on a chart you have been sent really mean:

• When was it last updated? A chart is a snapshot. An image or PDF exported three weeks ago shows dates that are three weeks old, however tidy it looks.
• Which dates are fixed? Some dates are promises to someone outside the team, like a launch already announced to customers, and some are estimates. On the chart they look identical.
• What is on the critical path? If it is not marked, ask which tasks would move the end date if they slipped. A quick, clear answer is a good sign that the plan has been thought through.
• Who owns each task? If names are not on the chart, ask for them, at least for the tasks your own work depends on.
• What is not on the chart? The launch plan deliberately covers only the handoff to marketing, because the campaign has its own plan. Most charts leave something out, and knowing what saves a surprise later.
• What happens if my part is late? Find your own tasks, follow their arrows forward, and ask about the first task that waits for you. That is the conversation to have early rather than in the week it matters.

Some charts answer a few of these already, in an update date, a list of assumptions or scope notes, so check for those before you send the questions.

If you are the one sending a chart rather than receiving it, these are the questions your audience will have, and walking a client through a timeline covers how to answer them before anyone asks.

Smaller questions about reading charts

Why are the bars different colours?

Colour means whatever the person who built the chart decided: phase, team, status or nothing at all. Many charts have no legend, so ask rather than guess. A red bar is often on the critical path, but not always.

What if I only need the key dates?

Read the milestones and the phase rows and skip the individual tasks. If you receive charts regularly, ask for a version trimmed to phases and milestones. It is quicker to read and less likely to start a conversation about a task that does not affect you.

What do words like float, lag and baseline mean on a chart?

They are scheduling terms for room to slip, a planned gap between linked tasks and a saved copy of the original plan. The plain-English glossary defines each of them, and about thirty more, with a one-line example.

Practise on the example

Once you can identify a task's dates, predecessors and progress, you can ask better questions: what is blocking it, what happens if it slips, and is the information current?