How to Make a Gantt Chart: A Practical Guide

To make a Gantt chart, break the work into tasks small enough to have an owner, give each one a start and a duration, then draw a dependency wherever one task genuinely cannot begin until another finishes. Mark the fixed dates as milestones, and read the longest chain of dependent tasks — that chain is your critical path, and it is the only part of the plan where a day lost is a day late.

Live interactive diagramUse the player controls to follow the steps

Website launch planPlaying silently in this guideWatch with narrationOpen in editor

When a Gantt chart is the right choice

A Gantt chart answers one question: what has to happen before what, and will it fit in the time we have? It earns its place when work has real dependencies and a date somebody outside the team cares about — a launch, a migration, a conference, a regulatory deadline.

It is the wrong tool for continuous work. If tasks arrive unpredictably and the question is "what is in flight right now?", you want a kanban board. If you only need to show that things happened in an order, without modelling what blocks what, a timeline is lighter and easier to read.

A bar chart of dates is a report. A Gantt chart is a bar chart that knows which bars are load-bearing.

Tasks, durations, dependencies and milestones

• Task. A bar on the chart: a piece of work with an owner, a start and an end. Name it as an outcome — "Migrate customer records", not "Migration".
• Duration. How long the work takes in working days. This is not the same as how long it will sit on the calendar, and conflating the two is where most plans go wrong.
• Dependency. An arrow from one task to another, meaning the second cannot start until the first finishes. Draw it only where that is literally true.
• Milestone. A zero-duration marker for a moment rather than a stretch of work: a go-live, a freeze, a sign-off. It is the thing you are actually being held to.
• Phase. A group of tasks that belong together — Discovery, Build, Launch. Phases make a long plan readable; they are not work themselves.
• Critical path. The longest chain of dependent tasks. Its length is the project duration.

Read the chart along its arrows, not down its rows. A row tells you when one team is busy; a chain of arrows tells you what happens to the end date when that team slips.

Why the critical path is the whole point

Every task not on the critical path has slack — room to run late without moving the finish. Every task on it has none. That single distinction is what a Gantt chart gives you that a task list cannot:

• A task with three days of slack running two days late is noise. Do not escalate it.
• A task on the critical path running one day late moves the launch by one day, today, before anyone notices.

If you build a Gantt chart and never identify the critical path, you have drawn a calendar with extra steps. The dependencies are what make it a model, and the critical path is what you get back for drawing them.

How to make a Gantt chart, step by step

1. Write down the deliverables first. Start from what must exist at the end, not from what the team will be doing on Monday. Work backwards from there.
2. Break each deliverable into tasks with one owner. If two people would both say "that's mine", it is two tasks. If nobody would, it is not a task yet.
3. Estimate duration, not dates. Ask how many working days the task takes with the person actually doing it. Dates fall out of the dependencies; entering them by hand is how a plan becomes fiction.
4. Draw only the real dependencies. For each arrow, say out loud: "B cannot start until A is finished." If the honest answer is "B would be easier after A", that is a preference, not a dependency — and drawing it inflates your critical path.
5. Add the milestones you are measured on. The launch, the freeze, the approval. Put them in even when they are somebody else's to hit.
6. Find the longest chain and mark it. That is the critical path. Everything else has slack, and now you know how much.
7. Check it against the deadline. If the critical path runs past the date, the plan does not work. Shorten a task on that chain, remove a dependency, or move the date — but do not shorten a task with slack and call it progress.

Worked examples you can open and edit

Real, editable plans — open one, drag a task longer, and watch which dates move and which do not.

A practical example: a website launch

The website launch plan above is the shape most projects start from: discovery, design, build, content, launch. What makes it worth reading is the place where two chains converge — build and content run in parallel, and launch depends on both. The bars look comfortable until you notice that the launch milestone inherits whichever chain finishes later.

This is the most common planning mistake made visible. Content is usually the one with slack, so it gets deprioritised all quarter, right up until it becomes the critical path in the final fortnight and the launch moves. The chart shows that risk in advance; a task list shows it the week it happens.

A second example: a plan with a freeze in it

The software release plan is a different beast because it contains a constraint, not just work: the code freeze. Everything before it must finish; everything after it is verification. A freeze splits a plan into two problems with different rules, and the milestone is what makes the split explicit rather than assumed.

Plans like this fail when the freeze is drawn as a task rather than a milestone. A task can absorb a day of overrun quietly. A milestone cannot — it either happened or it did not, which is exactly the honesty you want at that point in a release.

Building one in Diagramium

Open the Gantt chart editor and work on the canvas.

1. Add a task and give it a name, a start and a duration.
2. Group tasks into phases so a long plan stays readable at a glance.
3. Drag from one task to another to create a dependency — the arrow records what blocks what.
4. Mark the fixed dates as milestones so they read as moments, not as work.
5. Highlight the critical path so the chain with no slack is visible without tracing arrows by hand.
6. Press Present to walk a room through the plan one phase at a time, instead of putting the whole year on screen and talking over it.

Presenting a plan phase by phase is worth more than it sounds. A full Gantt chart shown all at once invites everyone to look for their own row; revealed in order, it makes people follow the dependencies — which is the conversation you called the meeting to have.

Presenting and exporting

A plan is a document other people have to act on, so it has to leave the editor. Export to SVG or PDF for a document, PNG for a slide, or record the walkthrough as a video for the people who were not in the room. The chart stays editable afterwards — a plan that cannot be updated stops being read within a fortnight.

Mistakes worth avoiding

• Dependencies that are really preferences. Every false arrow lengthens the critical path and makes the plan look tighter than it is.
• Tasks longer than two weeks. A three-week bar hides its own progress; nobody can tell a slipping one from a healthy one until it ends.
• No milestones. Without them there is no moment to hold anyone to, and the plan degrades into a wall of bars.
• Typing dates instead of durations. Hand-entered dates stop responding to change, so the first slip silently invalidates the rest of the chart.
• Planning at 100% capacity. Nobody spends five days a week on project work. A plan with no slack anywhere is a plan that is already late.
• Never redrawing it. A Gantt chart is a model of a decision, not a monument. Update it when the decision changes, or stop showing it.

Related diagram types

• A timeline shows when things happened or will happen, without modelling dependencies — lighter when nothing blocks anything.
• A kanban board tracks work in flight rather than work scheduled; pair it with a Gantt chart for continuous delivery against fixed dates.
• A RASCI matrix answers who is responsible for each task, which the Gantt chart deliberately does not.
• A process map shows the repeatable flow of work; a Gantt chart schedules one run of it.

Questions people actually ask

What is the difference between a Gantt chart and a timeline?

A timeline places events on a date axis. A Gantt chart adds durations and dependencies, so it can tell you what happens to the end date when one task slips. If nothing in your plan blocks anything else, a timeline is the clearer picture.

How detailed should the tasks be?

Small enough to have a single owner and to finish inside about two weeks. Longer bars hide their own progress; much shorter ones turn the chart into a to-do list nobody maintains.

What is the critical path, in plain terms?

The longest chain of tasks that depend on each other. Its total length is the shortest time the project can take, and any delay on it delays the finish by the same amount. Tasks off it have slack.

Do I need to show every dependency?

Only the real ones. Draw an arrow when the second task genuinely cannot start until the first finishes. Sequencing preferences drawn as dependencies make the plan look more constrained than it is.

Should milestones have a duration?

No — a milestone marks a moment, so its duration is zero. If something you called a milestone takes three days, it is a task, and the milestone is the point at which it is signed off.

How often should I update it?

Whenever a date or a dependency actually changes, not on a fixed cadence. A chart that is refreshed weekly regardless of whether anything moved trains people to ignore it; one that changes only when the plan changes stays worth reading.