← Blog
How-to·2 June 2026·5 min read

In-chart milestones vs symbol columns: when vs what state

They look like the same object — a little shape on a schedule — so planners reach for whichever is nearest. But a diamond on the timeline and a stoplight in a column answer two completely different questions. Put the wrong one in the wrong place and your one-pager either buries a key date or clutters the timeline with traffic-light confetti. Here's the rule, and how to run both on one clean row.

A board opens your programme summary and their eyes do two things at once. They scan left-to-right to read time — when does this land, when's the gate, when do we hand over. And they scan top-to-bottom down the row labels to read health — what's green, what's slipping, who's in trouble. Two axes, two questions. Your symbols need to respect that geometry.

The mistake is treating "milestone" as one thing. There are two, and they belong on different axes:

Get that distinction straight and every placement decision downstream becomes obvious.

Two axes, two questions time → answers WHEN rows → answer WHAT STATE ◆ milestoneposition = the date ● column dotcolour/shape = the state
Fig 1. The whole article in one picture. A milestone lives on the horizontal time axis — where it sits is its meaning. A column symbol lives on the vertical row axis — its horizontal spot is fixed and irrelevant; only its colour and shape carry meaning.

When each one wins

Use an in-chart milestone when the reader's question is temporal and comparative: is the gate before or after the freeze? does delivery land inside the window? which handover is first? Because the eye reads distance along the axis, a diamond lets someone judge sequence and slack without reading a single date label. That's its superpower — and it's wasted the moment you use it for anything that isn't fundamentally about position in time.

Use a column symbol when the question is categorical and per-row: what's the status? how far along? is this one healthy? A RAG stoplight, a %-complete pie or a status shape sits in a fixed column so the eye can run straight down and compare rows against each other. You're not asking "when" — you're asking "which of these needs attention," and a tidy vertical stack of dots answers that in half a second.

The reader is really asking…UseWhy
When does this land? Is it before the gate?In-chart milestone (◆/★/▮)Position on the time axis carries the answer
Which phases are slipping right now?RAG dot in a status columnFixed column lets the eye compare rows top-to-bottom
How far through is this activity?%-complete pie in a columnFill fraction reads as progress, independent of dates
Is this a gate, a payment, a handover?Milestone shape on the timelineShape encodes type; position encodes the date
Approved / at-risk / on-hold?Status shape or icon in a columnCategorical state belongs beside the name, not on time

Size them independently — because they compete for different attention

A milestone and a column symbol are not sized by the same logic, and coupling them is a common beginner error. The two live in different visual budgets.

A timeline milestone has to read against bars and gridlines, so it wants to be the boldest thing at its date — a crisp filled diamond, sized to stand a touch proud of the bar height so it punctuates rather than blends. If it's too small it disappears into the Gantt; too large and it smears across neighbouring dates and you lose the very precision you put it there for. Aim for a shape roughly the bar's height, filled, high-contrast.

A column symbol is sized to the row, not the chart. It should sit comfortably inside the row band with air around it, consistent from row to row so the vertical scan feels even. RAG dots want to be small and uniform; a %-pie wants to be legible but calm; nothing in the column should shout louder than the milestones on the timeline, because the column's job is quiet reference, not headline. In Sketchedule both are independent style properties — milestone glyph size on the timeline, symbol size within the column — so you tune each to its own axis instead of one dial fighting the other.

Independent sizing — each glyph tuned to its own axis Timeline milestone (vs a 12px bar) too small — lost in the bar right — proud, precise ✓ too big — smears across dates Column status dot (in a 22px row) too small — hard to read right — calm, even ✓ too big — shouts Rule of thumb: milestone ≈ bar height and bold; column symbol snug inside the row and uniform. They draw from different budgets — a big milestone is punctuation; a big status dot is just noise.
Fig 2. Same idea, two axes. On the timeline the milestone should sit slightly proud of the bar and stay crisp; in the column the status symbol should be small, uniform and quiet. Size them separately — they're competing for different kinds of attention.

The best summaries use both on one row

This isn't an either/or. The strongest board line does both at once, and it's beautiful precisely because each symbol stays in its lane: a %-complete pie and a RAG dot in the left-hand columns tell you the health of the phase, while a milestone diamond on the bar tells you the date that phase is racing toward. One glance down the columns reads status; one glance across the timeline reads schedule. Nothing overlaps, because they were never asking the same thing.

Here's how to build a row that carries both cleanly.

  1. Put state in columns, on the left. Add a %-complete pie SmartColumn and a RAG stoplight column beside the activity name. These answer "what state" and belong where the eye starts the row.
  2. Put the date on the timeline. Promote the key date — a gate, delivery, handover — to an in-chart milestone on the bar. Its position is the answer, so it stays out on the axis where distance is meaningful.
  3. Pick shapes that don't collide in meaning. Use milestone shape for type (◆ gate, ★ contract, ▮ handover) and column colour for health. Don't also colour milestones for status here, or the two languages blur — one job per glyph.
  4. Size to axis, not to each other. Milestone bold and bar-height on the timeline; status symbols small and uniform in the column (Fig 2). Two dials, tuned apart.
  5. Let the data drive it, and it stays honest. Bind the pie and the stoplight to your % complete and status fields so they recompute on every import; the milestone tracks the underlying date. Nobody hand-recolours anything at 9pm.
Both at once — status in columns, dates on the timeline · built in Sketchedule Activity Start Fin % JanFebMarAprMayJun ▾ Package A — Delivery 58% Detailed design 05 Jan20 Feb Procure long-lead 18 Jan30 Mar ◆ Delivery Fabricate skid 01 Mar15 May ▾ Package A — Commissioning 12% Mechanical completion 18 May18 May ◆ MC gate Handover to ops 28 Jun28 Jun Handover data date · 28 Feb Columns answer WHAT STATE (pie + RAG). Timeline answers WHEN (◆ milestones, flag handover, dashed data date).
Fig 3. A faithful Sketchedule redraw. The left grid carries state — a %-complete pie and a RAG stoplight per row; the right chart carries time — task and summary bars, milestone diamonds, a flag handover and a dashed data-date line. Two questions, two axes, one clean page.
One glance, two answers. Read the columns top-to-bottom and you know the health of every phase. Read the timeline left-to-right and you know when each one lands. That only works because each symbol stays on its own axis — the moment they trade places, both reads get harder.

Two ways it goes wrong

Cluttering the timeline with status

The tempting mistake is to colour milestones red/amber/green for status and dot the chart with them. Now the timeline is doing two jobs — position and health — and it does neither well. A row of coloured diamonds pulls the eye across the axis chasing colour instead of reading dates, and because status doesn't live at a specific time, you've smeared a categorical fact across a temporal axis where it has no natural home. Keep status in the column. Let the timeline mean when.

Hiding a key date in a column

The opposite error: stashing an important date as a text value in a narrow column — "Delivery: 30 Mar" — instead of a diamond on the bar. Now the single fact a director most wants (is delivery before or after the freeze?) requires reading tiny text and doing the arithmetic themselves, when a milestone would have shown the answer as pure distance. If a date matters, it goes on the timeline where the eye can judge it against everything else.

The corrective for both is the same one line: time on the timeline, state in the columns. Whenever a symbol feels wrong, check which question it's answering and move it to the matching axis.

Why data-driven matters here. Because Sketchedule computes the pie, the stoplight and the milestone locally from your columns and dates — no macros, no server — the two languages never drift apart. Re-import next period and status recolours itself while the milestone shifts to the new date, both in the same pass. You're never hand-syncing a colour to a date that already moved.

Key takeaways

Try it on your own programme

Open Sketchedule in a browser — free, no install, nothing uploaded. Add a %-pie, a RAG column and a milestone, and watch both drive off your data.

← BlogAll articles

Primavera and P6 are trademarks of Oracle Corporation; Microsoft Project is a trademark of Microsoft Corporation. Sketchedule is an independent product and is not affiliated with, endorsed by or sponsored by Oracle or Microsoft. Figures are illustrative, drawn in Sketchedule.