What Is a Gantt Chart? How to Read One, Make One, and When a Board Is Enough

A Gantt chart is a bar chart laid over a calendar. Each row is a task, each bar runs from the day the task starts to the day it finishes, and a diamond marks a milestone, a single date when something is due. When the bars are linked, so that one task cannot start until another ends, the chart also shows the critical path: the chain of tasks that sets the finish date, where any slip moves the whole project. You read it left to right as time and top to bottom as work. You make one by listing tasks, estimating how long each takes, deciding what waits on what, and drawing the bars. Below: the parts, where the chart came from, how to read one, a template you can copy, a plain-text example, and when a board with a few dates is all a small team needs.

The parts of a Gantt chart

• The time axis. Across the top, in days, weeks or months. Everything else is positioned against it.
• Task rows and bars. One row per task, listed down the left. The bar’s left edge is the start date, its right edge the finish date, and its length the duration. A bar is often shaded to show how much is done.
• Summary bars. Related tasks are grouped under a heading row whose bar spans from the first task’s start to the last task’s finish, so you can read a phase at a glance.
• Milestones. A diamond or triangle on a single date: “design approved,” “beta live,” “launch.” A milestone has no duration; it marks a result.
• Dependencies. Arrows from the end of one bar to the start of another. The common kind is finish-to-start: B cannot begin until A is done.
• The today line. A vertical line at the report date. Any bar that should be finished to its left and is not is behind.

NASA’s Schedule Management Handbook↗ (opens in a new tab) describes the chart the same way, horizontal bars along a time axis, milestones as diamonds or triangles and a vertical line for the report date, and adds a warning worth remembering: in its typical form a Gantt chart does not show task dependencies, so you cannot tell how one task slipping affects another. Bars alone are a picture of the plan. Linked bars are a schedule.

The critical path, in plain words

Link the tasks and follow every chain from the first task to the last. The longest chain is the critical path. Its length is the shortest time the project can take, because nothing on it can run in parallel with the rest of it. Every task on that chain is critical: if it finishes two days late, the project finishes two days late, unless you claw the time back somewhere else on the chain.

Tasks off the critical path have slack, also called float: room to slip without moving the finish date. A task with five days of slack can start late or run long by up to five days and nobody outside the team notices. That is the practical use of the critical path for a small team. It tells you which handful of tasks deserve daily attention and which can wait a day without harm.

Where the Gantt chart came from

The chart is named for Henry Laurence Gantt (1861 to 1919), an American engineer and management consultant. The management engineer Wallace Clark set out its history in The Gantt Chart: A Working Tool of Management↗ (opens in a new tab), published in 1922. According to Clark’s preface, the Army’s Chief of Ordnance retained Gantt in 1917 to help with production, first at the Frankford Arsenal and then in Washington, because orders for arms had jumped “from hundreds to millions” and tables could not show whether they were being met on time.

Gantt’s answer was a chart that compared “performance and promises” against the passing of time. Clark records that during 1918 the charts were used in US arsenals, in naval aircraft production and by the Emergency Fleet and the Shipping Board, and that Gantt never tried to patent them. The original charts tracked planned output against actual output; the task-and-dependency charts in scheduling software today grew from the same idea of putting work on a calendar so a slip is visible at a glance.

How to read a Gantt chart

1. Find the today line. Everything to its left should be done; everything crossing it should be under way.
2. Scan for bars that cross the line but show little progress. Those are the late tasks.
3. Follow the arrows out of each late task. If they lead to a milestone, that milestone is at risk.
4. Look for the critical path, often drawn in a different color. A late task on it moves the finish date; a late task off it may not.
5. Read the milestones last. They are the dates people outside the team care about, and the chart tells you which ones the current slips threaten.

How to make a simple Gantt chart

1. List the tasks. Use results, not activities, and keep each one between a day and two weeks. Anything longer hides problems inside one bar.
2. Estimate a duration for each, in working days.
3. Write down what each task waits on. Most tasks wait on one other; if a task seems to wait on five, it is probably two tasks.
4. Add the milestones, the handful of dates someone outside the team will ask about.
5. Draw the bars from the first task forward, starting each one when everything it waits on is done.
6. Mark the longest chain. That is your critical path, and it is the part of the chart to check every week.

A spreadsheet is enough for this. Here is a Gantt chart template as columns you can paste into one; the chart itself is a bar drawn from Start to Finish on each row.

ID | Task (a result)           | Owner  | Start      | Days | Finish     | Waits on | Milestone?
1  | [ ]                       | [name] | [date]     | [n]  | [date]     | -        | no
2  | [ ]                       | [name] | after 1    | [n]  | [date]     | 1        | no
M1 | [What is true on this day]| [name] | [date]     | 0    | [date]     | 2        | yes

A plain-text Gantt chart example

A small website relaunch, four weeks, one week per column. Design waits on content, the build waits on design, and launch waits on the build and on the client signing off.

Task                      Oct 5   Oct 12  Oct 19  Oct 26
1 Content inventory       #####
2 Page designs                    #####
3 Client approves design                 <>
4 Build pages                            ##########
5 Test on staging                                  ###
6 Launch                                              <>

# = work   <> = milestone
Critical path: 1 > 2 > 3 > 4 > 5 > 6 (no slack anywhere)

If you would rather type the chart than draw it, Mermaid’s Gantt syntax↗ (opens in a new tab) turns a few lines of text into a rendered chart: each task gets an id, a start date or an after dependency, and a duration, and a milestone tag marks a single date. Many documentation and note tools render Mermaid, so the plan can sit in the same file as the rest of the project notes.

gantt
    title Website relaunch
    dateFormat YYYY-MM-DD
    section Content and design
    Content inventory      :a1, 2026-10-05, 5d
    Page designs           :a2, after a1, 5d
    Client approves design :milestone, m1, after a2, 0d
    section Build
    Build pages            :crit, b1, after a2, 10d
    Test on staging        :crit, b2, after b1, 3d
    Launch                 :milestone, m2, after b2, 0d

Gantt chart software, briefly

Dedicated scheduling tools such as Microsoft Project link bars for you and move every later task when an earlier one slips. Microsoft’s guide to linking tasks↗ (opens in a new tab) lists four dependency types, finish-to-start, start-to-start, finish-to-finish and start-to-finish, with finish-to-start as the default. Many work-management tools offer a timeline or Gantt view on their paid plans, spreadsheets can draw the bars with conditional formatting, and text tools like Mermaid suit teams who keep plans in files. What matters more than the tool is that someone updates the dates every week; a chart nobody updates describes a project that no longer exists.

When a board with a few dates is enough

A Gantt chart earns its upkeep when the order of work is physical and the dates are fixed from outside: a build, an event, a contract with dated milestones, several vendors handing off to each other. Most small software and service teams have a different shape of work. Items are small, mostly independent, and their order changes weekly. For them a full chart is a second plan to maintain, and it goes stale first.

The lighter version: keep five to eight milestones with dates on one page, put the work on a board, and name the milestone and its date in the note of each task that serves it. Once a week, look at each upcoming milestone’s open tasks and decide whether they fit. Draw a real Gantt chart only for the stretch that is truly sequenced, then retire it. The full side-by-side is in Gantt chart vs Kanban, and a one-page version of the milestone list is in the project timeline template.

Where fenbs fits, and where it does not

fenbs is a board, not a scheduler. It has no Gantt view, no due dates, no timeline and no dependencies that block one task on another, so if your project is defined by a sequenced timeline, keep that part in a scheduling tool. What it does is the board half: four lanes, To Do, Next Up, In Progress and Completed; tasks of three kinds, feature, enhancement and bug; and a priority from 1 to 10, where 1 is the most urgent. A task’s note says what the problem is, so “Needed for: design approved, October 30” goes there, in words. Related tasks can be linked both ways, but a link records that they belong together; it does not move dates or block anything.

AI assistants join the board over MCP as members with their own role, move tasks and add notes, and History records who changed what. For the weekly check against the milestones, Copy as Markdown copies the board so you can paste it beside the dates. If you broke the project down first, the leaves of a work breakdown structure are the tasks to paste in.