A Gantt chart is just a task list with dates attached and bars drawn to scale. The chart itself takes ten minutes. The hard parts, estimating durations and sequencing honestly, are where projects live or die, and no software does them for you.
Down the left: every task, named with a verb ("Migrate product database," not "Database"). Across the top: calendar time, usually in days or weeks. In the body: one bar per task, positioned from start to end, with color coding by phase and a progress overlay if the work has begun. That's the whole machine. Dependencies, milestones, and owner columns are useful additions, but the bars do the talking.
Aim for tasks between one and five days. Longer bars hide slippage: a "Build feature X — 15 days" bar can run four days late and still look on schedule. Shorter than a day and you're maintaining a to-do list, not a schedule. A 40-day project should land somewhere between 10 and 25 tasks.
For each task, ask what genuinely must finish (or start) before it begins. Most people over-sequence. Design at 80% lets some build start; content drafting doesn't need the final CMS. The schedules that finish early are the ones with deliberate overlaps, because the calendar math compounds: three tasks run in sequence over 15 days, in parallel over 5.
The four dependency types you'll actually use: Finish-to-Start (B starts when A finishes — the default, ~90% of links), Start-to-Start (B starts alongside A), Finish-to-Finish (B ends when A ends), and the rare Start-to-Finish. When in doubt, it's Finish-to-Start.
| Task type | Estimate approach | Realistic multiplier |
|---|---|---|
| Pure execution, one owner, no waits | Your honest estimate | × 1.1 |
| Needs review or approval | Add one full review cycle | × 1.3 |
| Depends on an outside party | Add 50%, cap the risk visibly | × 1.5 |
| Never been done before | Estimate, then double it | × 2 |
Put buffer where the risk is, not spread evenly. A vendor delivery that could slip a week should show a visible buffer after it, so when it slips, the chart absorbs it instead of cascading.
Enter tasks with start day, duration, and phase. Weekends shade, progress overlays, SVG download.
Open the Gantt Chart Maker →Trace chains of dependent tasks and total each chain's length. The longest one is your project; it's the critical path. A day lost there is a day lost overall, while tasks with slack can drift without consequence. When someone asks for a status, the honest answer is "we're fine except the critical path is X days behind," and this is the analysis that tells you X.
A chart goes stale the week nobody updates it. Two habits keep it alive: update progress at the same weekly meeting, and re-baseline instead of editing history when reality shifts — keep the original dates visible so you can see drift. Charts that get rewritten to match reality quietly teach everyone to ignore them.
For the wider project picture, pair the timeline with an org chart so it's clear who owns each workstream, and drop final numbers into a bar chart when you report results. And if what you're actually mapping is a decision process rather than a schedule, a flowchart is the right tool, not a Gantt.
Three: a task list down the left, a calendar timeline across the top, and one horizontal bar per task positioned from its start date to its end date. Everything else, dependencies, progress shading, milestone diamonds, phase colors, is annotation on that skeleton.
List every task, mark which ones genuinely block others, and only then place bars. Most sequencing mistakes come from inventing dependencies that don't exist: design doesn't have to fully finish before any build starts. Ask of each pair: can B start if A is only 80% done? If yes, overlap them; that overlap is where fast schedules come from.
Trace dependency chains from the first task to the last and total each chain's duration. The longest chain is the critical path: any slip there slips the finish date. Tasks off the path have slack, the difference between their earliest start and latest allowable start. Slack is your schedule's shock absorber; protect it.
Add buffer at the project level or on external-dependency tasks, not invisibly inside every estimate. Padded individual estimates get consumed (work expands to fill them) and you lose the ability to see which tasks are genuinely risky. A visible two-day buffer after the vendor delivery is honest; a hidden extra day on every task is not.