How to use a Gantt chart to plan a project

What a Gantt chart shows

A Gantt chart lays a project out against a calendar. Each task is a row, and each row has a bar that starts on the task's start date and ends on its finish date. Read across a row and you see how long one task takes. Read down a column and you see everything happening in that week.

Most charts add three more things:

• Links between bars, called dependencies, that show which task has to happen before another can begin or end.
• Milestones, usually drawn as diamonds, that mark a moment rather than a span of work, such as "contract signed" or "site goes live".
• Owners, so each bar has a name next to it.

That combination answers the questions a list cannot: what has to happen first, what can run in parallel, and what happens to the end date if something slips.

When a Gantt chart is worth the effort

A Gantt chart is useful when the sequence of work drives the deadline. Good fits include:

• Launches and events with a fixed date, where you need to work backward from the day.
• Construction, fit-outs and moves, where one trade cannot start until another finishes.
• Client projects with handoffs between teams, such as design to development to review.
• Any plan you need to explain to people outside the team, because a chart is easier to read in a meeting than a long list.

It is less useful when work arrives continuously and has no fixed order, such as a support queue or a content pipeline where each piece is independent. A board or a prioritized list fits that kind of work better, and a Gantt chart for that work adds upkeep without telling you anything new.

Building the chart step by step

Start away from the software. A chart is only as good as the task list underneath it.

• Write down every deliverable the project has to produce. Then break each one into tasks small enough that one person can own each and finish it in days rather than months.
• Estimate how long each task takes in working days. Ask the person who will do the work, not the person who wants it done.
• Mark the order. For each task, ask what must be finished, or at least started, before it can begin.
• Add milestones for decisions and approvals. Give them their own entries because they depend on people outside the core team and are easy to underestimate.
• Assign owners. A bar with no name is a task nobody is watching.
• Only now put it into a tool and let the tool calculate dates from the durations and links.

Keep the first version coarse. Twenty to forty well-defined tasks are easier to keep current than two hundred tiny ones. You can always split a bar later.

The four dependency types

Most dependency-aware tools support four kinds of link. Wrike and ClickUp both document all four.

• Finish-to-start: task B cannot start until task A finishes. Printing cannot start until the proof is approved. Use it unless you have a reason to pick another type.
• Start-to-start: task B cannot start until task A has started. Testing can begin once development has begun, without waiting for it to end.
• Finish-to-finish: task B cannot finish until task A finishes. Final documentation cannot be completed until the feature itself is complete.
• Start-to-finish: task B cannot finish until task A starts. This is rare; a typical example is an old system that must stay running until the new one goes live.

Some tools also let you add lead or lag time to a link. Wrike, for example, documents lead and lag as a way to overlap linked tasks or add a gap between them, such as a two-day wait for concrete to cure.

Critical path and slack

The critical path is the chain of linked tasks that sets the project's finish date. If any task on that chain is late, the whole project is late. Tasks off the critical path have slack, also called float: they can slip by some amount without moving the end date.

Knowing which is which changes how you manage. A one-day delay on a critical task is urgent. A one-day delay on a task with a week of slack is not. ClickUp documents Critical Path and Slack Time settings in its Gantt view, and Wrike documents a critical path filter that shows only the tasks driving the deadline.

Two cautions. The critical path is only as accurate as your dependencies, so a missing link can hide a real risk. And it changes as work progresses, so check it each time you update the plan rather than once at kickoff.

Baselines: comparing plan with reality

A baseline is a frozen copy of the schedule, usually saved when the plan is approved. Later, you compare the live chart with the baseline to see which tasks moved and by how much.

Without a baseline, a chart quietly rewrites history. Every time dates shift, the new plan looks like the only plan, and it becomes hard to explain why a three-month project took five. ClickUp describes saving a snapshot and overlaying it on the live Gantt. Wrike describes baselines stored in reportable fields so that schedule variance can appear in dashboards.

Keeping the chart current

Plan for upkeep from the start, because the chart is only useful while it matches reality. A short weekly routine is enough:

• Ask each owner to update progress and expected finish dates on their own tasks before a set time.
• Review only what changed: tasks that slipped, tasks on the critical path and milestones in the next two weeks.
• Move dates by moving tasks, and let dependencies shift the rest, instead of editing each later date by hand.
• Record why a major date moved, so the baseline comparison has an explanation attached.

If nobody owns this routine, assign it. A chart that is two weeks out of date does more harm than no chart, because people make decisions from it.

Common mistakes

• Planning every task to the hour. Detail beyond what you can track becomes stale first.
• Using dates instead of dependencies. If you type dates directly, the chart cannot react when something slips.
• Ignoring capacity. A chart can show three tasks in parallel that all belong to one person. Check workload separately.
• Leaving out approvals and external waits. Reviews, sign-offs and supplier lead times are tasks too.
• Treating the chart as the communication. Share a summary of what changed with stakeholders rather than expecting them to read the chart.

Gantt support in the tools we compare

Gantt and timeline features vary by tool and by plan. What the vendors listed when we checked on 8 October 2026:

• ClickUp: a Gantt view with four dependency types, automatic rescheduling of dependent tasks, critical path, slack time and baselines. Gantt is a limited trial on Free Forever and unlimited from the Unlimited plan.
• Wrike: a Gantt chart with four dependency types, lead and lag, critical path, baselines and milestone conflict checks, listed from the Team plan.
• monday.com: Timeline and Gantt views from Standard. Dependencies, which draw the connecting lines on the Gantt, are on Pro and Enterprise.
• Asana: timeline and Gantt views from Starter, with dependency lines that turn red when dates conflict.
• Smartsheet: a Gantt view and dependencies on every plan, starting with Pro. A separate Timeline view starts on Business.
• Jira: a timeline view on every plan, including Free. Dependencies work within one project on Free and Standard, and across projects on Premium and Enterprise.
• Trello: a Timeline view on Premium and Enterprise. Trello's pricing page does not list a Gantt view or dependencies.

Prices and plan names change, so confirm the tier on each vendor's pricing page before you commit.