Skip to content

Milestone Plan

At a glance

  • Purpose: Define the few points in the project where a decision is made or an outcome is verified — not every date, but the ones that matter.
  • Use it when: From initiation onward, refined as the schedule firms up. Milestones are what executives track when they will not read a full schedule.
  • Owner: The project manager, agreed with the sponsor.
  • Related: Module 06 · Module 11 · Lab 10

How to use this template

  1. A milestone is a point of decision or verification, not a progress marker. If nothing changes at a milestone, it is a date, not a milestone.
  2. Give each one entry and exit criteria: what must be true to begin it, and what must be demonstrably true to declare it met. "Development complete" is not a criterion; "every P1 defect closed and the release candidate passes the regression suite" is.
  3. Name the decision and its owner at each milestone. A gate with no possible negative outcome is a ceremony.
  4. Keep the number small — roughly one per two to four weeks. A plan with thirty milestones tells a sponsor nothing.
  5. Re-baseline only through change control, and record what the change did to downstream milestones.

Field descriptions

Field What goes in it Watch out for
ID M1, M2, M3… used consistently in reports Renumbering between documents
Milestone A named event, not a task Naming activities as milestones
Planned date A date the project controls Dates that depend on an external party with no agreed slot
Entry criteria What must be true before it starts Vague "ready" states
Exit criteria The evidence that it is met Criteria that only the project can judge
Decision What is decided here, and by whom Gates with no decision
Evidence The artefact or demonstration required Verbal assurances
Tolerance How late it can be before it becomes an exception Unstated tolerance — every slip then feels like a crisis
Status Not started / at risk / met / missed / re-baselined Leaving a missed milestone marked "at risk"

Blank template

# Milestone Plan — [Project name]

| | |
| --- | --- |
| **Version** | [1.0] |
| **Baseline date** | [YYYY-MM-DD] |

| ID | Milestone | Planned date | Entry criteria | Exit criteria | Decision (owner) | Evidence | Tolerance | Status |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| M1 | [Named event] | [YYYY-MM-DD] | [Condition] | [Testable condition] | [Decision — owner] | [Artefact] | [±n days] | Not started |

## Governance calendar

| Milestone | Forum where it is reviewed | Attendees | Reporting input |
| --- | --- | --- | --- |
| M1 | [Steering committee / sprint review] | [Roles] | [Status report, dashboard] |

## Change history

| Date | Milestone | Change | Reason | Approved by | Impact on later milestones |
| --- | --- | --- | --- | --- | --- |

Worked example

A six-milestone plan for a 16-week delivery, with invented dates for teaching:

ID Milestone Planned date Exit criteria (abbreviated) Decision (owner)
M1 Charter approved Week 2 Scope statement and assumptions signed by the sponsor Approve the project (sponsor)
M2 Baseline accepted Week 4 Schedule, budget, and risk register agreed; variance tolerances set Release funds (sponsor)
M3 Design agreed Week 7 Data model and interface decisions recorded and reviewed Freeze interfaces (technical lead)
M4 First working increment Week 10 One end-to-end path demonstrable on test data Continue, adjust scope (product owner)
M5 UAT entry Week 14 All P1 defects closed; test data loaded; users trained Begin acceptance (business owner)
M6 Closure Week 16 Acceptance signed; lessons learned logged; handover pack complete Accept the deliverable (business owner)

Note what this plan deliberately omits: there is no milestone called "50% complete". Percentage milestones measure effort, not outcomes — a project can be 50% complete by effort and 0% demonstrable. Equally, note the failure mode visible in Lab 25: M4's evidence was demonstrated on a dataset that broke in production, because "demonstrable on test data" was accepted without a data-realism criterion.

Common mistakes

  • Milestones used as progress percentages. They answer "has an outcome been verified?", not "how far along are we?".
  • No exit criteria, or criteria only the team can judge. A milestone that cannot be independently checked will be declared met on schedule and fail later.
  • Gates with no real decision. If the answer is always "continue", the milestone is theatre and will be skipped when the schedule tightens.
  • Too many milestones. Beyond roughly one every two to four weeks, the plan stops communicating.
  • Unstated tolerance. Without it, every variance is escalated, and the tolerance that matters is invisible when a real exception occurs.
  • Silent re-baselining. Moving a milestone without a recorded change destroys the project's ability to explain its own history.