Which promises can the plan actually keep?

Milestone dates typed into a plan are wishes. These are derived from the work that feeds them, so a target and a forecast that disagree show up immediately.

HomeProject Management › Milestones

Milestones, checked against the work that feeds them

A milestone date is a promise. This works out when the prerequisites actually finish and tells you which promises the plan cannot keep.

Local tool — your project data stays in your browser
A planning aid, not a commitment. Everything here is calculated from figures you typed. A schedule is only as good as its estimates and its dependencies, and neither of those is something arithmetic can check for you. Treat the output as a way to test a plan, not as a promise to anyone about a date.

The work

The activities that feed your milestones. Same syntax as the critical path calculator.

The milestones

Prerequisites are activity ids, comma-separated. The forecast is the latest finish among them.

Timeline

Milestone by milestone

See the whole schedule →
Your project stays in this browser. Task names, owners, durations, dates and estimates are calculated on your own device. Nothing is uploaded, stored on a server, or included in analytics — project content is never passed to the advertising or analytics scripts on this page.
How the forecast is derived

Each milestone's forecast is the latest finish among its prerequisites, computed from a full CPM pass over the activities. It is not entered and cannot be adjusted independently of the work.

That is the entire point. A milestone date typed in by hand agrees with the plan only by coincidence, and it keeps agreeing right up until someone checks.

A milestone with no prerequisites cannot be forecast and is reported as such rather than assumed to be fine.

A milestone is not a date, it is a conclusion

Milestone dates are usually typed into a plan directly, which makes them wishes. The date that matters is the one the work implies, and the two agree only by accident.

Deriving the forecast from the prerequisites means the milestone cannot quietly drift out of agreement with the schedule. If the target and the forecast diverge, that is visible immediately rather than at the review where somebody finally checks.

Zero duration, real meaning

A milestone consumes no time. It marks an instant — a decision made, a thing accepted, a gate passed — and adds nothing to the project's length.

That is what makes them useful for external commitments: they are the points where something must be true, without implying anything about how the work leading to them is arranged.

Acceptance criteria are what stop the argument

"Design complete" means something different to the person who drew it and the person who has to build from it. Without written criteria the milestone is declared complete by whoever is under the most pressure to declare it.

The criteria do not need to be elaborate. They need to be specific enough that two people can disagree about whether they are met, and settle it by looking.

Too many milestones is the same as none

A plan with a milestone every week has turned them into progress reporting. Milestones work because they are few and consequential — points where a genuine decision is made or a genuine commitment falls due.