How to make a Gantt chart

A Gantt chart shows a project’s work as bars on a timeline: where each piece starts, where it ends and what it depends on. Drawing the bars is easy. Keeping the chart true a month later, when half the dates have moved, is harder. Here is an order of work that makes it possible.

1. Start with the work breakdown, not the dates

First break the project’s outcome into parts: phases, work packages inside them, tasks inside the packages. This is the work breakdown structure (WBS). A good breakdown answers “what has to be done”, not “when”.

A rule that saves time: every task should end in a clear result — a document, a build, a sign-off. “Work on the module” is a poor task; “the module passed code review” is a good one.

2. Set durations in working days

Estimate how many working days each task takes. Don’t type dates by hand: with 40 tasks on hand-typed dates, every change has to be carried over 40 times.

Durations follow a production calendar with holidays and moved weekends. Otherwise a five-day task set right before a holiday ends earlier on the chart than in real life.

3. Link the tasks

A dependency says one piece of work relies on another. There are four types:

• Finish-to-start (FS) — the most common: testing starts after development finishes.
• Start-to-start (SS) — documentation starts together with development.
• Finish-to-finish (FF) — acceptance finishes together with the last fix.
• Start-to-finish (SF) — a rare case: the old system runs until the new one starts.

A dependency can carry a lag (“start two days after the finish”) or a lead (“start three days before the finish”).

Once dependencies are set, dates take care of themselves: when one task moves, everything that depends on it moves too.

4. Add milestones and goals

A milestone is an event with no duration: “architecture approved”, “pilot launched”. Milestones mark control points and let you talk to the customer in results rather than percentages.

5. Find the critical path

The critical path is the longest chain of dependent work. It sets the project end date: a delay anywhere on it moves the whole project. Work off the critical path has float — it can slip a little with no effect on the end date.

More in “The critical path in plain words”.

6. Record a baseline

When the plan is agreed, save it as the baseline. From then on you compare the forecast with it and see the slip, instead of guessing “how it was meant to be”. More in “Baseline and forecast”.

Common mistakes

• Typed dates instead of dependencies. The chart stops recalculating and soon lies.
• Tasks that are too small. Nobody maintains a 500-row plan of half-day tasks. A good grain is from a few days to a couple of weeks.
• No milestones. Without them you cannot tell whether the project is on track until it is too late.
• No baseline. Without one, any slip can be explained as “that was the plan”.

Where to do it

In Etapero the Gantt chart is built from a work breakdown you edit like a spreadsheet: all four dependency types, production calendars, the critical path and baselines work out of the box. Try it in the demo, no sign-up needed.