Milestone map
Milestone map
3 milestones
Define Scope and Build the Delivery Plan
3 weeks
Produce a full project delivery plan for a major project (three or more months duration, three or more team members, significant organisational impact). The plan must include: a scope definition with explicit in-scope and out-of-scope boundaries, a work breakdown structure (WBS) or equivalent, dependency map identifying cross-team or cross-function dependencies, risk register with likelihood/impact assessment and mitigation plans for the top five risks, and a milestone schedule. Present the plan to the project sponsor and key stakeholders for sign-off.
Proof required
Submit the delivery plan (min 1000 words or equivalent structured document) including all five elements, plus a record of the sponsor sign-off meeting showing that the scope and schedule were confirmed and any changes requested.
What gets checked
- Out-of-scope items are explicitly named — not just implied by what's listed as in-scope
- Risk register covers at least five risks with specific mitigations — not just 'monitor closely'
- Sponsor sign-off is documented with any requested scope or schedule changes
Common mistakes
- Scope is defined but only as in-scope — out-of-scope items are left to interpretation and cause scope creep
- Risk register is created but mitigations are vague — 'escalate to management' is not a mitigation
- Plan is created but not signed off — project starts without confirmed sponsor alignment
Resources
Foundationstart here
Depthgo deeper
Masteryfor the dedicated
What a verifier looks for
- Ask the submitter what is explicitly out-of-scope and why — this tests whether the scope definition is real
- Ask them to walk through one risk and its mitigation — is the mitigation specific and actionable?
- Confirm the sponsor sign-off is documented — not just assumed from a meeting
Run Weekly Steering and Manage a Significant Change
6 weeks
Run the project through at least six weeks of active delivery: conduct weekly steering meetings with documented agendas, decisions, and action owners; maintain an updated risk register (risks added, escalated, or resolved); and manage at least one significant scope, schedule, or resource change through a documented change-control process (proposed change → impact analysis → sponsor decision → updated plan). Collect feedback from the project team on the steering quality at the six-week mark.
Proof required
Submit six weekly steering meeting records (agendas + decisions + action owners), an updated risk register, documentation of one significant change through the change-control process, and brief feedback from at least three team members on steering quality.
What gets checked
- All six steering records are present and contain decisions and action owners — not just status updates
- Change control documentation shows impact analysis, sponsor decision, and updated plan
- Team feedback on steering quality is from at least three named team members
Common mistakes
- Steering meetings become status updates — no decisions are made or tracked
- Change is absorbed informally — no documentation, no sponsor decision, no plan update
- Risk register becomes static — risks are added at start but never updated during delivery
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Ask the submitter to walk through the significant change — what was proposed, what was the impact analysis, what did the sponsor decide?
- Confirm the risk register was actively updated — can they identify a risk that was resolved or escalated during delivery?
- Check that steering decisions have documented action owners and that those actions were tracked
Close the Project and Capture Lessons Learned
2 weeks
Complete the project delivery and run a formal project close including: a deliverables acceptance sign-off from the sponsor, a stakeholder satisfaction survey (at least five respondents), a lessons-learned workshop with the core project team (at least 60 minutes, documented findings), and a post-project report covering outcomes versus plan (scope, schedule, budget), key decisions that most influenced outcome, and three specific process improvements for future projects. Archive the project documentation.
Proof required
Submit the sponsor deliverables acceptance record, stakeholder satisfaction survey results (anonymised), lessons-learned workshop notes, and the post-project report (min 700 words covering all four required sections).
What gets checked
- Sponsor acceptance is documented — not just assumed from project end
- Lessons-learned workshop involves the core team — not just the project manager reflecting alone
- Post-project report is honest about schedule or scope variances — not a success narrative
Common mistakes
- Project ends without a formal close — deliverables are handed over but acceptance is not documented
- Lessons learned are noted privately — they are never shared with the team or captured for future projects
- Post-project report only covers successes — variances and near-misses are omitted
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Confirm sponsor acceptance is documented with a specific sign-off record
- Ask the submitter what the most important lesson learned was and how they would apply it next time
- Check the post-project report covers actual vs planned on all three dimensions — scope, schedule, budget