Project milestones: how to set them and how they differ from deadlines

A milestone typed in with a date and no link to the work before it stays on that date whatever happens to the work. The pattern turns up in plans rebuilt from spreadsheets and in older .mpp files, next to two relatives: an outside date entered as a milestone, and a milestone pinned with a “must finish on” constraint.

This guide explains what project milestones are, who needs them, how they differ from deadlines and date constraints, and the two checks every milestone should pass. Then it follows a stand at a trade fair from brief to build-up, where the same date is modelled three ways and only one of them moves when the work slips and flags the missed deadline.

What project milestones are#

A project milestone is a point in the schedule with zero duration that marks a significant event, such as a sign-off or a hand-over between teams. It takes no time and no effort; it records the moment the work before it ends and the work after it can start. Without linked milestones, a three-day slip in a review shows only as a bar that moves somewhere in a 40-row plan, and nobody is asked whether the hand-over date still holds until it is missed.

PMI’s lexicon defines a milestone as a significant point or event in a project^[1]. Gantt charts draw it as a diamond on a single date. Inside the network the milestone is scheduled like any task, so it carries float and can sit on the critical path.

Name a milestone after a finished state. A task gets named after an action: “Review the design” is two days of work, and “Design signed off” is the moment that work ends. Typical milestones are “Contract signed”, “Data migrated and reconciled”, “Acceptance test passed” and “Go-live”.

Who needs project milestones, and when#

As a rule of thumb, project milestones pay off on any plan longer than two weeks with at least one hand-over in it: teams of 3 to 15 people, plans of 30 tasks or more. The project manager sets them.

The readers are the people who wait on them. A sponsor or client reviewing progress can read eight milestone rows instead of 60 tasks, and a supplier reads the one hand-over that tells them when their own work starts.

A one-person to-do list does not need milestones. Neither does a continuous flow of support tickets, where nothing is handed over and a milestone would only record a date.

Add them as soon as the first version of the plan exists and before any date is promised outside the team, because the links decide where each milestone sits. In a 40-task plan, linking eight milestones takes minutes. Agreeing the verifiable event with each owner takes longer, about one conversation per milestone.

Milestones, deadlines and date constraints#

A milestone is an event in the plan, and it moves with the work before it. The deadline attached to it stays fixed. Its only job is to report how far the event lands from the promise. Date constraints work differently again: the scheduling engine has to place the task on or around the constraint date. In plans rebuilt from a spreadsheet the three get confused, because a spreadsheet has one date column for all of them.

A milestone with no predecessor behaves like a date written on a wall chart. A “must finish on” constraint does something harder to spot: it keeps the milestone on its date when the work behind it finishes later, and the gap moves to the float column. Microsoft Project, which calls float “slack”, documents negative slack both when a predecessor finishes too late for a constraint date and when a task is scheduled to finish after its deadline^[2]; Planitude’s scheduling engine calculates float the same way. The critical path guide explains how float is calculated and why it can go below zero.

Our recommendation: put every outside date on a linked milestone as a deadline. The milestone then shows where the work will really land, and the deadline shows how far that is from the promise.

Use a constraint only when the outside date limits when work can happen, such as the day a venue opens for build-up. Sometimes other work has to be scheduled from an exact date, for instance press visits booked for the day after the opening. Give the press visits a “start no earlier than” constraint and leave the milestone free to move.

A milestone pinned with “must finish on” finishes on the deadline by definition, so even with both set on the same milestone the deadline is never reported as missed.

Two checks every milestone should pass#

A good milestone passes two checks: it has a predecessor, and its event can be verified on the day.

It has a predecessor. A milestone with no incoming link has no reason to move, so it never reports a delay. Link it to the last task, or tasks, that must finish for the event to happen.

Two kinds of milestone can stand alone. The project start is one. The other records an input from outside the team, such as client data received or a permit granted: give it a “start no earlier than” on the expected date and treat that date as an assumption to check with the sender.

Successors matter too. Apart from the final milestone, each one needs at least one successor, because a milestone that nothing depends on only records a date. The dependencies checklist asks the same of every task.

Its event can be verified. Someone has to answer “did it happen?” with yes or no by pointing at something: an email with the sign-off, a delivery note, a test report, a page that loads. “Design 80% complete” fails the check, since nobody can point at the missing 20%. A pass looks like “Design signed off by the sales director”.

As a rule of thumb, set one milestone for each decision or hand-over that changes who works next. On a three-month project with five people that usually means six to ten. Each hand-over between two companies adds one, because the receiving company plans its own people around that date. Past about one milestone a week on average, 13 on a three-month plan, the milestones turn into a second task list. With fewer than three, a month or more goes by with no check at all.

Where milestones go in the schedule#

Put each milestone at the end of the work it closes, linked finish-to-start from the last tasks of that work, and link the first tasks of the next stage to the milestone instead of to the tasks before it.

Routing links through the milestone saves work and shows the decision point. If three tasks feed “Design signed off” and four follow it, linking them directly takes 12 links. Through the milestone it takes 7. A fifth task after the sign-off then needs one new link instead of three.

Milestones are also how phases appear in a plan built around deliverables: the work breakdown structure guide keeps phases out of the WBS and shows them as milestones in the schedule. Once a baseline is saved, the milestone rows are the ones to put in front of a sponsor, because “Design signed off, 3 days later than the baseline” is a date and a cause the sponsor can check against an email (see baseline and variance).

A worked example: a stand at a trade fair#

A company that makes industrial sensors is exhibiting at a trade fair. The team is the marketing manager, a freelance designer, the product team that prepares the demo units and a stand builder who works first in their own workshop and then in the hall; a print supplier produces the graphics. The organiser sets two dates: the hall opens for build-up on day 24 of the plan, and every stand must be finished by the end of day 26, when the hall closes for cleaning before the opening.

Durations are in working days and every link is finish-to-start. Float is measured against the end of the plan, day 25.

The critical path is brief, design, review, build, shipping and set-up: 3 + 6 + 2 + 10 + 2 + 2 = 25 days, one day inside the organiser’s limit.

Five milestones on a five-week plan is one a week, right at the ceiling given above, and each one is there because the next person works for a different company. “Brief and budget approved” is the email in which the marketing manager sends both to the freelance designer. The sign-off is the sales director’s written approval of the final drawings, which the builder needs before cutting anything and the printer before printing. “Graphics delivered” and “Demo units ready” are delivery notes signed at the builder’s workshop. They sit on branches with 6 and 13 days of float, so the builder learns well before shipping day whether a crate will be missing. For “Stand ready”, the builder sends the marketing manager a photo of the finished stand with the graphics up and the demo units switched on.

The constraint on set-up does nothing in this version, because shipping ends on day 23. It covers the other case: if the workshop finished early, the stand still could not enter the hall before day 24.

Now the review runs over. The sales director is travelling, and the approval arrives after 5 days instead of 2, at the end of day 14. The build moves to days 15–24, printing to 15–18, shipping to 25–26 and set-up to 27–28. The work now ends on day 28, two working days after the hall closes. What Planitude shows depends on how “Stand ready” was entered:

The second version shows the slip only to someone who reads the float column or the conflict list; the diamond still says day 26. The third moves the date and flags the missed deadline on day 14, as soon as the marketing manager updates the review to 5 days, twelve working days before the hall closes.

The graphics are now delivered on day 18, six working days before shipping starts; measured against the deadline on day 26, that is 4 days of total float. The demo units have been ready since day 8. So the 2 days have to come out of the critical tasks still ahead. The builder can drive the stand to the venue in one day with their own van and add two fitters to finish set-up in one day: shipping on day 25, set-up on day 26, “Stand ready” at the end of day 26. The stand meets the deadline with no margin left, for the cost of the van and two extra fitter-days. That trade-off is crashing, covered in how to recover a delayed project.

Common mistakes#

Four patterns account for most broken milestones in imported plans:

• Milestones with a duration. “Testing milestone, 5 days” is a task. If something takes time, schedule it as work and put the milestone at its end.
• A milestone after every task, which buries the few real decisions under rows named “Task done”.
• Meetings as milestones. Use the decision the steering committee on the 14th should take as the milestone: “Budget for phase 2 approved”. If the committee meets and decides nothing, the milestone stays open and the delay is visible.

The fourth is dragging the diamond to the date someone wants, and it is the hardest to see afterwards. In Planitude, moving a task by hand sets a “start no earlier than” constraint on the new date, and the milestone keeps following its predecessors. A date earlier than the work allows has no effect: the diamond returns to where the links put it. A later date holds even if the work finishes sooner, until someone resets the constraint to “As soon as possible” in the task panel.

When milestones are not enough#

A milestone reports only when the work before it is updated. In the example the 10-day build has no milestone of its own, and the next one is “Stand ready” on day 25; for critical tasks longer than a week, our rule of thumb is a progress update at least once a week in between.

A single milestone date also hides how uncertain it is. Day 25 assumes every estimate holds. With six tasks in a row the chance that none of them runs over is small: if each has an 80% chance of finishing on time, all six do so about 26% of the time (0.8 to the sixth power), a constructed figure for illustration (the guide to estimating task durations shows why). For a date promised outside the team, quote a date with a stated probability, such as the 80th-percentile date (P80), and keep the gap to the deadline visible as margin.

Contract milestones that trigger a payment need more than a date. If 30% of the price is tied to “Acceptance test passed”, the contract has to say what happens when the test passes with reservations. The schedule only tracks when the event is expected.

How to do it in Planitude#

Ask the AI assistant to add a milestone after a task, or import one from a .mpp file or a spreadsheet, where a duration of 0 becomes a milestone. In the Gantt chart it is a diamond; link it like any task. Put the outside date in its Deadline field. The milestone keeps following its links, and the deadline marker turns red when the milestone goes past it.

The Summary lists the milestones due in the next 14 days. Deadline reminders email assignees around 8:00 Central European time about next-day deadlines and overdue tasks, and a private iCal link puts tasks, milestones and deadlines in Google Calendar, Outlook or Apple Calendar. The Risk tab gives P50, P80 and P95 dates for each milestone, with the probability of meeting its deadline.

Two limits. Typing a date or dragging the diamond sets “start no earlier than”, and that constraint stays until you set it back to “As soon as possible” in the task panel. There is no sign-off field either, so write the verifiable event in the task notes.

Frequently asked questions#