gantt
Somebody upstairs wants one page that shows where the project stands. Not the task list, not the backlog, not the forty bar Gantt chart that nobody outside the team can read. One page, a handful of dates, and an honest answer about whether those dates are still real. That page is a milestone chart, and the hard part is not drawing it. The hard part is deciding which dates deserve to be on it, and then keeping the chart honest once the first one slips.
The most common way a milestone chart goes wrong is that it becomes a second task list with nicer icons. Thirty diamonds across eighteen months, each one a piece of work, and the page is now as unreadable as the Gantt chart it was supposed to replace.
A milestone marks a moment when something changes about how the project runs. It has zero duration. Nothing is worked on at a milestone. Something is either true or it is not, and the answer changes what happens next.
Three tests separate a real milestone from a task with ambitions. Does something outside the team depend on this date? A client sign off, a regulatory submission, a launch, a handover to support. Does missing it change the plan rather than just the schedule? If a slip means the next phase cannot start at all, that is a milestone. If it means the next phase starts late, that is a task. Can a person who has never seen the board tell whether it happened? "Design phase complete" fails this test. "Design signed off by the client" passes it.
Everything that fails all three tests belongs in the task list, where it is still tracked, just not shown on the one page that goes to people outside the team.
Search results treat these as one thing. They behave differently and they are read by different people.
The timeline strip is a single horizontal line with diamonds on it, ordered by date. No swimlanes, no dependencies, no bars. Its whole purpose is that someone can look at it for four seconds and know what is next. This is the version to put in a status email or a steering deck.
The milestone overlay is a Gantt chart with the bars left in and the milestones marked as diamonds on top. It answers a different question: not "what is next" but "what is between here and the next date, and is any of it late". This is the version the team works from, and it only makes sense to someone who already knows the work.
There is a third form worth knowing about, because it is the one that catches slippage earliest. A milestone trend chart plots reporting dates along the bottom and forecast dates up the side. Each milestone becomes a line. A flat line means the forecast is holding. A line that climbs to the right means the date is being pushed back, report after report, and the slope tells you how fast. Teams that only look at the current forecast tend to discover a four week slip as a single surprise. Teams that plot the trend watch it arrive over six weeks and get to act on it.
For a project measured in months, five to nine milestones is the working range. Below five, the chart has nothing to say between the dates and people stop opening it. Above nine or ten, readers stop being able to hold the sequence in their head and the page becomes decoration.
The way to get there is not to trim a long list down. It is to pick the moments where control passes from one group to another. On a software project that usually lands on: requirements agreed, design signed off, first working build, feature complete, testing complete, live. On a construction or fit out project it lands on permits granted, site handover, structural complete, services complete, handover. On an event it lands on venue confirmed, speakers confirmed, registration open, run of show locked, doors open.
Notice that each of those is a moment when somebody else becomes responsible for something. That is not a coincidence. Milestones are useful exactly where handoffs are, because handoffs are where projects lose time and where nobody owns the gap.
One more rule that saves arguments later. Give each milestone an owner, a single named person, not a team. The owner is not the person doing the work. The owner is the person who answers the question "is this date still real" when asked, and who is expected to raise a hand before the date rather than on it.
Before building anything by hand, it is worth checking what the current subscription already includes. Milestone and timeline views are a common upsell, and which tier they sit in varies a lot. All of the following was checked on each vendor's own pricing page on 27 September 2026, and prices exclude tax.
| Tool | Free plan | Timeline or Gantt view on free? | First tier that includes it |
|---|---|---|---|
| Jira | Free forever for 10 users, 2 GB storage | Yes. Backlog, list, board, timeline, calendar and summary views are all listed on Free | Included on Free |
| Trello | Up to 10 collaborators and 10 boards per Workspace | No. Timeline is listed under Premium | Premium, $10 per user per month billed annually, $12.50 monthly |
| Asana | Personal, up to 2 seats per project and team | No. Timeline and Gantt views are listed under Starter | Starter, $10.99 per user per month billed annually, $13.49 monthly |
| ClickUp | Free Forever, 60 MB storage, unlimited members | No. Unlimited Gantt charts are listed under Unlimited | Unlimited, $7 per user per month billed yearly, $10 monthly |
| monday.com | Free, up to 2 seats and 3 boards | No. Timeline and Gantt views are listed from Standard | Standard, the third tier |
Two things fall out of that table. Teams already on Jira have a timeline view on the free plan and often do not know it. Teams on Trello are two tiers away from one, which is why so many Trello users end up maintaining a milestone chart in a spreadsheet beside the board. And a free plan capped at two seats, as Asana's Personal and monday.com's Free both are, is not a free plan for a team of six, whatever else it includes.
A spreadsheet milestone chart is genuinely the right answer for a one off. Put dates in one column and labels in the next, make a scatter chart, set the marker to a diamond, add data labels. Twenty minutes, and the output is a picture anyone can paste anywhere.
It stops paying at the second update. The chart is a picture of what the dates were when somebody last typed them. Nothing in it is connected to the work, so every revision is a manual pass: change the date, check the label positions, re-export, re-attach. Teams do this twice and then quietly stop, and the chart on the shared drive is now three weeks stale while everyone still refers to it.
The break point is not a size of project. It is a question about frequency. If the chart will be read more than twice, it needs to be generated from the work rather than typed beside it. That means the milestone lives as a dated item in the same place the tasks live, so that moving it moves the chart, and so that anyone can see when it last changed and who changed it.
This is also the argument against keeping the milestone chart in a slide deck. A deck is a snapshot with a date on it, which is fine for the steering meeting and actively misleading for the six weeks afterwards.
A diamond and a date is not enough information to act on, and most milestone charts that get ignored are ignored because they carry nothing else.
Four fields cover almost every case. The label should be written as a state, not an activity: "client signed off on design", not "design review". A state can be checked by somebody who was not in the room. An activity cannot. The owner is one named person. The planned date and the current forecast sit side by side, so the reader sees both where the date started and where it is now.
A fifth field is worth adding on anything that runs longer than a quarter: the entry condition. One line saying what has to be true for the milestone to be declared met. For a sign off, that is which document and whose signature. For a go live, that is which environment and which checks. Teams that skip this end up arguing about whether a milestone happened, which is a worse argument than arguing about whether a date will hold.
What does not belong on the chart is percentage complete, effort, cost, and the names of everyone involved. All of those are real and all of them live better in the task list. A milestone chart earns its place by being the one view where the reader is not asked to filter anything, and every extra column chips away at that.
Colour is worth one mention. Use it for one thing only, usually whether the forecast has moved since the last report. Charts that colour by phase, by owner and by risk at the same time end up needing a key, and a page that needs a key is no longer a four second read.
Every milestone chart is accurate on the day it is made. What happens next decides whether it was worth making.
Three habits do most of the work. Re-forecast on a fixed cadence, not when something goes wrong. A weekly or fortnightly pass where each owner confirms or moves their date costs ten minutes and is the only thing that turns the chart into an early warning system rather than a record of surprises.
Keep the original date visible next to the current one. A chart that silently overwrites dates loses the information that matters most, which is the direction of travel. Two dates per milestone, planned and forecast, is enough to make a slip impossible to hide.
Never mark a milestone partly done. A milestone is binary by construction. The moment percentages appear on it, it has turned back into a task and the chart has lost the one property that made it readable. If a milestone genuinely needs a progress bar, it was scoped as a phase and should be split.
The failure mode to watch for is a chart that has not moved in a month. That almost never means the project is exactly on plan. It means nobody has been asked to re-forecast, and the chart has become a page people nod at rather than read.
Open whatever is currently being used as the status page and count the milestones. If there are more than ten, cut it to the handoffs and give each survivor a named owner and two dates. If the chart lives in a spreadsheet or a deck and gets read more than twice a month, the next change is to move the milestones into the same place as the tasks, so the chart is generated rather than retyped. Pinateca keeps Gantt and calendar boards on the free plan for up to five people, and the pricing page shows where the limits sit, so the check costs an afternoon rather than a procurement cycle.
A Gantt chart shows work as bars with durations and dependencies, so it answers what is happening between now and the deadline. A milestone chart shows only zero duration points, so it answers what has to be true by when. The two are often drawn together, with diamonds overlaid on the bars, but they are read by different audiences and the milestone only version is the one that travels outside the team.
Five to nine on a project measured in months is the working range for a chart that people actually read. The reliable way to land in that range is to mark the points where responsibility passes from one group to another, such as a sign off, a handover or a go live, rather than trimming a long task list down.
Yes. A spreadsheet scatter chart with diamond markers takes about twenty minutes, and Jira's free plan lists timeline and calendar views for up to 10 users. Free plans differ sharply in what they cap, so the useful question is not whether a tool has a free tier but how many people and boards that tier allows.
Move the forecast date, keep the original date visible beside it, and check whether anything downstream depended on the original. A slip that changes only the schedule is worth recording quietly. A slip that stops the next phase starting is worth raising the same day, because the cost of that one is paid by other people's calendars.
One named person, not a team and not the person doing the bulk of the work. The owner's job is to answer whether the date is still real, on a fixed cadence, and to raise a hand before the date rather than on it. Milestones with a team in the owner column are the ones that slip without anyone noticing.