Charter Section Deep-Dive

Project Charter Milestones: Phase Gates That Drive Approval

Milestones in a charter are not a calendar. They are the gates the project must pass through, with named criteria, named approvers, and named consequences if missed. The 5-to-7 rule keeps the gate discipline; named approvers keep the accountability; explicit criteria keep the project honest.

Five Rules for Charter Milestones

1. 5 to 7 milestones, no more

Above 7, the milestone list becomes a task list. Below 5, the project lacks gate discipline.

2. Each milestone has a named approver

If no one approves the milestone, it has not been reached. Approval defines completion, not the calendar.

3. Each milestone has explicit gate criteria

What evidence does the approver need to see? Without criteria, the approval becomes a vibe check.

4. Each milestone has a target date and a dependency

Targets without dependencies are wishful thinking. The dependency is the reason the milestone cannot happen earlier.

5. Milestones are outcomes, not tasks

"Design complete and signed off" is a milestone. "Hold design workshops" is a task. Tasks belong in the project plan, not the charter.

Filled Milestone Plan: Aurora Pricing Engine Migration

A 12-month software migration project with 5 milestones. Each has explicit criteria, a named approver, a dependency, and the consequence of missing the date.

Project: Aurora Pricing Engine Migration (legacy to cloud-native)

M1

Discovery complete

31 July 2026

Gate criteria: Functional requirements signed off by PM and Engineering Lead. Technical assessment of the legacy pricing engine documented. Migration approach (lift-and-shift vs rebuild) selected and justified. Initial backlog of 40-60 stories drafted.

Approver: Engineering Director (Sarah Chen)

Dependency: None (project start)

If missed: Build phase cannot start without approved approach. 4-week delay translates to USD 92K additional team cost.

M2

First production deployment of any new module

30 September 2026

Gate criteria: At least one new pricing module live in production, behind feature flag at 5% traffic. SLOs met for 7 consecutive days. Observability dashboards live. Rollback procedure tested.

Approver: VP Engineering + SRE Lead (joint sign-off)

Dependency: M1 complete; staging environment provisioned (week 8)

If missed: Confidence in incremental migration approach broken. Recommend pause and replan if M2 slips past 31 Oct.

M3

50% of pricing requests routed to new engine

31 December 2026

Gate criteria: 50% of production pricing requests served by new engine with error rate at or below 0.1%. P95 latency at or below 250 ms. All 12 high-volume product lines migrated. Customer-facing rollback playbook tested in production.

Approver: VP Engineering + CTO

Dependency: M2 complete; vendor billing integrations live

If missed: Year-end go-live target at risk. Charter re-baseline conversation with Sponsor required.

M4

100% migration complete; legacy engine in shadow mode

31 March 2027

Gate criteria: 100% of production traffic served by new engine. Legacy engine running in shadow mode for cross-validation. No P0 or P1 incidents in 14 consecutive days. CFO sign-off on cost-tracking reconciliation (new engine within 5% of legacy run-rate).

Approver: VP Engineering + CFO + CTO

Dependency: M3 complete; cost-validation framework operational

If missed: Legacy engine decommissioning timeline slips. Each month of dual-running adds USD 38K infrastructure cost.

M5

Legacy engine decommissioned

30 June 2027

Gate criteria: Legacy engine off. All hardware returned or reallocated. Code repository archived. Final post-implementation review presented to steering. Lessons-learned document published.

Approver: VP Engineering + Steering Committee

Dependency: M4 complete; minimum 90-day shadow-mode validation period

If missed: Project officially open beyond planned envelope. Sponsor decision required on extension vs reduced scope.

Timeline (ASCII)


M1 ████ Discovery (8 weeks)
                M2 ████ First mod (8 weeks)
                                M3 ████████ 50% routing (12 weeks)
                                                        M4 ████████████ 100% migrated (12 weeks)
                                                                                    M5 ████████████ Decom (12 weeks)
   Jul 26    Sep 26    Dec 26       Mar 27       Jun 27

Stage-Gate Mapping

Cooper's Stage-Gate model maps cleanly to most charter milestone structures. The charter itself is the artefact for Stage 2 (Concept Definition); the milestone list is the gate structure for Stages 3 through 6.

StageArtefactApprover
Stage 1: Idea ScreenProject brief or one-pagerManager or PM
Stage 2: Concept DefinitionProject Charter (this document)Sponsor
Stage 3: Build / DevelopmentSprint Reviews + Phase-gate reviewSponsor + steering committee
Stage 4: Testing and ValidationTest sign-off + acceptance criteria evidenceSponsor + senior user / acceptance team
Stage 5: LaunchLaunch readiness review + go / no-go decisionSponsor + executive team
Stage 6: Post-Launch ReviewBenefit realisation report at 3, 6, 12 monthsSponsor + benefits owner

Source: Robert G. Cooper, "Winning at New Products", 5th edition (2017); PMI Standard for Program Management.

Milestone Failure Modes

Calendar milestones instead of outcome milestones.

"End of Sprint 3" is a calendar event. "First production module live" is an outcome. Calendar milestones do not say whether the project is making progress.

Too many milestones (12+).

Becomes a task list. Sponsor stops attending steering because every meeting is a milestone review. Loses the gate discipline that milestones exist to enforce.

No named approver per milestone.

"Project team approves" means nobody is accountable. The first time a milestone is contested, the project has no resolution path.

Vague gate criteria.

"Design phase complete" with no criteria means the approver decides on the day, often based on calendar pressure rather than evidence. Charter approval becomes performative.

Milestones tied to deliverables not outcomes.

"Pricing engine code complete" is a deliverable. "Pricing engine processing 50% of production traffic with error rate under 0.1%" is an outcome milestone. Outcome milestones survive contact with reality.

Frequently Asked Questions

How many milestones should a charter have?
5 to 7 for most projects. Above 7, the milestones become a task list and lose their gate function. Below 5, the project lacks phase discipline. PMI's Pulse of the Profession data consistently shows projects with 5 to 7 well-defined milestones have higher on-time delivery rates than projects with 12+ (over-engineered) or fewer than 4 (under-managed) milestones.
What is the difference between a milestone and a deliverable?
A deliverable is a tangible artefact produced; a milestone is the moment when an outcome is achieved. 'Design specification document v1' is a deliverable. 'Design phase complete and signed off' is a milestone. Milestones are often gated by deliverables (the milestone is reached when the deliverable exists and is approved), but the milestone itself is the gate, not the artefact.
Should milestones include dates or just sequence?
Dates, with clear notation that they are target dates not guaranteed dates. Pure-sequence milestones (M1 -> M2 -> M3) provide no schedule discipline; pure-date milestones imply unrealistic precision. The convention used in mature PMOs is 'target date plus tolerance' (e.g. 'target 30 September 2026, plus or minus 3 weeks per project tolerance'). PRINCE2 formalises this as tolerance bands; PMBOK leaves it to organisational practice.
What is Stage-Gate methodology?
Stage-Gate is a phased decision-making framework developed by Robert G. Cooper, widely used in product development. It defines stages (idea, concept, build, test, launch, post-launch review) separated by formal gates with go / no-go decisions. Many project charters borrow stage-gate language; the milestone section of a charter is often a stage-gate map adapted for the specific project.
How do agile projects handle milestones?
Agile projects use release milestones and Sprint Goals rather than phase-gate milestones. A release milestone is the moment when a shippable increment goes live; a Sprint Goal is the single outcome the team commits to for the Sprint. The charter's milestone section in an agile project typically lists the release milestones (4-8 over a project) with the Sprint cadence noted but Sprint-level goals deferred to the team. Hybrid projects mix both: phase gates for governance, release milestones for delivery.
Can milestones be added mid-project?
Rarely without re-approving the charter. Adding a milestone changes the gate structure and shifts what the project is committed to. If a new milestone is genuinely needed (e.g. a regulatory submission deadline that emerged after charter approval), it should be added through formal change control with the sponsor's approval. Quiet milestone additions undermine the gate discipline.
What happens when a milestone is missed?
Per PRINCE2 tolerance language, a missed milestone within tolerance is a status item; a missed milestone beyond tolerance triggers an Exception Report that pauses delivery until the sponsor decides on continuation or replan. PMBOK frames this less formally but the principle is the same: missed milestones beyond tolerance should not be quietly absorbed; they should trigger a steering decision on whether to extend, descope, or stop the project.

Related on this site

Updated 2 May 2026