Gantt charts: what they are, how to build one and when they are worth it

What is a Gantt chart?

A Gantt chart puts work on a time axis. Time runs across the top in days, weeks or months; the tasks run down the side. Each task is drawn as a bar that starts the day it starts and ends the day it ends, so the length of the bar is the duration and its position is the dates.

So far that is a calendar laid on its side. Two further elements turn it into a plan:

• Dependencies. Arrows stating that a task cannot begin, or cannot close, until another one has reached a certain point.
• The critical path. The longest chain of linked tasks in the project, the one that sets the delivery date. If anything on the critical path slips a day, delivery slips a day.

A Gantt chart answers one very specific question: if this moves, what else moves? It does not tell you who is overloaded this week, whether today's artwork is ready for review, or how much the project has cost so far. Each of those has a better view.

Who was Henry Gantt, and what problem was the chart built for?

Henry Laurence Gantt was an American mechanical engineer working around the turn of the twentieth century, inside the scientific management movement. The problem his chart came out of belonged to the factory and the shipyard: processes with many linked stages, large crews to coordinate and expensive machinery standing idle whenever the previous stage ran late. Knowing where each stage stood and what was blocking what was not a nicety, it was money.

His contribution was to show two things in the same space and at the same scale that until then lived in lists and in people's heads: planned progress and actual progress. In Poland, Karol Adamiecki had developed a very similar idea earlier, the harmonogram, but Gantt's version spread and ended up giving the chart its name.

That origin explains both its strengths and its limits. The Gantt chart was designed for work that is sequential, known in scope and estimable in duration. The more a project resembles building a ship, and the less it resembles working out which ship the client wants, the better it performs.

How do you build a Gantt chart, step by step?

1. Break the work down

Before you draw a single bar you need the list of what has to be done. A useful test: a task is small enough when one person can call it finished and anyone on the team, reading the name, understands what finished means.

"Client website" is not a task. "Lay out the product detail template" is. If a task runs longer than a week or two it can almost always be split; if it takes less than half a day it usually does not belong on the chart at all and belongs on a checklist inside another task.

This breakdown underpins any planning system, so it is not wasted effort even if you later drop the Gantt chart. If you are building the process from scratch, start with the guide to project management for creative agencies.

2. Estimate duration, not effort

This is where most agency Gantt charts fall apart. Duration and effort are not the same thing. A task worth eight hours of work can run four calendar days when the person doing it is juggling three projects, and two weeks when a client sign-off sits in the middle.

The axis of a Gantt chart is calendar days. To get there you estimate effort and then convert it using each person's real availability and the dead time the project carries by default: internal reviews, client rounds, bank holidays, leave.

Logged hours from past projects are the best raw material for those estimates. If the team books hours against tasks — in Tasuki that is time tracking — every closed project leaves behind a table of real durations worth far more than anyone's instinct. How to put it to work is covered in the guide to project profitability in agencies.

3. Link the dependencies

With the list and the durations in hand, you declare the order. The question for every task is always the same: what has to have happened before this one can start? Nothing else. If the answer is "nothing", the task has no predecessor and can run in parallel.

The common mistake is linking out of habit rather than necessity. Two tasks having always been done back to back does not make the second one dependent on the first; sometimes they only depend on the same person being free, and that is a capacity problem, not a sequencing one.

4. Find the critical path

The critical path is the sequence of dependent tasks whose durations add up to the longest total in the project. It sets the earliest possible delivery date and has an uncomfortable property: its tasks carry no slack. Any delay on one of them passes straight through to the end date.

You find it by walking the plan forwards to get the earliest dates for each task, then backwards from the delivery date to get the latest ones. The gap between the two is that task's slack, and the tasks with zero slack form the critical path. Tools compute it for you, but it is worth understanding, because it hands you the one piece of prioritisation a Gantt chart gives away for free: when you have to choose who to help today, help whoever is on the critical path.

5. Place the slack and put names on the bars

A plan with no margin is not an ambitious plan, it is a plan that fails on day one. Margin goes where the real uncertainty sits — external dependencies, client approvals, work the team has never done before — and it is declared openly rather than smuggled in by padding every estimate a little. Visible buffer can be defended in a meeting; buffer hidden across forty tasks gets eaten by optimism.

Finally, every bar needs an owner. A task with no name on it does not run late. It vanishes.

What are the four types of dependency?

There are four, and only one of them gets daily use. Knowing the other three stops you contorting the plan to make everything fit the first.

Any of the four can carry an offset: a lag, when there is a wait between A and B (printed proofs that take two days to arrive), or a lead, when B can start before A is entirely done (beginning layout on the first templates while the design is eighty per cent there).

Lag is the most useful and the most forgotten of the two. Almost every unexplained gap in an agency Gantt chart is really a wait nobody declared: the time the client takes to reply. Modelling it as lag turns it into part of the plan instead of the same surprise every month.

When is a Gantt chart not worth it?

Hardly any guide answers this, and it is the part that saves the most work. A Gantt chart is expensive to build and, above all, expensive to keep alive. There are four situations where that cost never comes back.

Continuous work with no hard deadline. A content retainer, support, social media management or website maintenance have no beginning and no end: they have a steady stream of similar requests. There is no critical path to compute because there is no single delivery date to protect. What works there is a flow board with work-in-progress limits, covered in the Kanban methodology guide.

Small teams with high variability. In a team of three or four people hopping between clients, the plan changes several times a week for reasons that have nothing to do with the project: another client's emergency, someone off sick, a campaign brought forward. Keeping the chart in sync burns more time than it saves, and the plan you are left with is a snapshot of a moment that has already passed.

Scope you discover as you go. If the project opens with a discovery phase, with a creative concept still to be found or with requirements the client cannot yet articulate, there is no task list to break down. A Gantt chart over unknown scope is an act of invention dressed as engineering. The sensible move is to close the scope first — that is what the creative brief is for — and plan only the part you actually know.

Projects that are simply too short. If the whole job fits in a fortnight and two people are doing it, the chart tells you nothing a dated list does not. The upkeep swallows the entire benefit.

Why is a badly maintained Gantt chart worse than none at all?

Because the value of a Gantt chart is not in the drawing, it is in the propagation. Its promise is that when a task slips, the chart tells you what else moves and whether the delivery date is at risk. That promise only holds if real dates go back into the plan as they happen.

The moment it stops being updated, three things follow in order. First, the plan and reality drift apart quietly. Second, the team notices and stops looking at it, so coordination moves back into chat and into people's heads. Third — and this is the real damage — somebody outside the team, a client or a director, is still looking at it and still believing it.

Hence a simple rule: if nobody is going to maintain it, do not draw it. An ownerless Gantt chart is not half a plan, it is misinformation. And maintaining it is a specific job somebody has to be given, not something that happens spontaneously after the Monday meeting.

Gantt, Kanban or calendar?

The three get compared badly because they answer different questions. Side by side it is obvious they are not competing.

In practice an agency runs all three at once, and what matters is that they are views of the same work rather than three places to write the same thing down twice. In Tasuki the same cards can be read on a timeline, as a Kanban board or as a calendar, depending on which question needs answering. For the dependency management and critical path this guide describes, you still need dedicated planning software.

How do you keep a Gantt chart alive without it eating the project?

Three habits are enough, and none of them needs a long meeting.

1. A short weekly review. You move the real dates of what has actually happened; you do not rebuild the plan. Fifteen minutes with the chart on screen.
2. Touch it when a dependency changes, not when a task does. Something taking a day longer while it still has slack requires no edit. The order of two linked tasks breaking does.
3. Replan properly once the drift no longer fits in the slack. At that point, patching individual bars only prolongs the fiction. Rebuild the remaining stretch with the durations you now know to be true.

One last warning about detail. The finer the breakdown, the more precise the plan looks and the more expensive it is to maintain. A thirty-bar chart that is current is worth immeasurably more than a three-hundred-bar chart frozen on kick-off week.

Key points

• A Gantt chart is tasks with a start, an end and dependencies on a time axis; its value lies in showing what moves when something slips.
• It was born on the factory floor, for sequential work with known scope, and that is still where it performs best.
• Five steps build one: break down the work, estimate duration rather than effort, link dependencies, compute the critical path and place declared slack.
• Tasks on the critical path have no margin, so they are the ones to unblock first whenever you have to choose.
• Of the four dependency types, finish to start covers nearly everything; lags model the client waits that otherwise show up as unexplained gaps.
• It is not worth it for retainers, support, very small teams with volatile schedules, undiscovered scope or two-week projects.
• A Gantt chart with nobody maintaining it is worse than none: it looks precise long after it stopped being true.
• Gantt, Kanban and calendar answer different questions and should sit over the same work, not in three separate places.