Milestone map
Milestone map
3 milestones
Post-Mortem 3 Real Projects
2–3 weeks (3–4 hrs)
Choose 3 projects you have managed or significantly contributed to in the last 2 years — at least one that finished late or over budget, and at least one that finished on time. For each, reconstruct the original plan and what actually happened: original timeline vs actual timeline, original scope vs delivered scope, and original resource assumptions vs what was needed. For each gap, identify the specific planning failure that caused it (scope underestimation, dependency omission, resource overcommitment, risk not identified, buffer not built in, or other).
Proof required
Submit your 3 project post-mortems: for each project, a table with original plan vs actual outcome for timeline / scope / resources, and a paragraph naming the specific planning failure(s) that caused each significant gap. Append a 150-word cross-project pattern analysis naming your most consistent planning weakness.
What gets checked
- 3 real projects with concrete original plan data — a post-mortem based on 'I think we planned for 6 weeks' is not sufficient; there should be a real original estimate to compare against
- Planning failure named for each significant gap with a specific cause (not 'things changed' — what specifically was not planned for?)
- Cross-project pattern analysis names one recurring weakness across at least 2 of the 3 projects
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Ask the submitter for the original project estimate for the late project — if they cannot name it, the post-mortem is based on memory, not records
- Check that planning failures are specific rather than generic — 'poor communication' is not a planning failure; 'did not map dependencies between teams before committing to the launch date' is
- Confirm at least one of the 3 projects finished late or over budget — post-mortems of successful projects only reveal less about planning skill gaps
- Ask the submitter what they wish they had planned for in the project that went over budget — the answer reveals whether genuine insight was gained
- Choosing only projects that went well to minimise uncomfortable self-assessment — the outcome requires at least one project that finished late or over budget
- Attributing all gaps to external factors ('stakeholders changed the scope') rather than identifying the planning practice that would have anticipated or managed the change
- Pattern analysis that lists multiple equal weaknesses instead of identifying one primary recurring pattern
Plan and Run a Real Project to Completion
6–10 weeks (depending on project scope)
Plan and deliver a real project of at least 6 weeks' duration, incorporating specific practices that address the M1 weakness you identified: reference class forecasting for the initial timeline estimate, explicit dependency mapping before committing, built-in buffers at identified risk points, and a weekly check-in log comparing planned vs actual progress. The project must be real — a deliverable that matters to someone other than yourself — and must have a visible completion point.
Proof required
Submit your initial project plan (created before the project started): scope statement, timeline with reference class forecast and buffer points labelled, dependency map, and top 3 risks. Also submit your weekly log (minimum 6 entries: planned vs actual, one risk that appeared, one adjustment made). Submit your completion artifact or evidence of delivery.
What gets checked
- Initial plan created before the project started — a plan written after the fact to fit what happened is not planning practice
- Timeline includes a reference class forecast (what have similar projects taken historically?) with a named reference class
- Completion artifact or evidence of delivery confirms the project was real and delivered to someone
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Confirm the initial plan was created before the project started — ask the submitter to show the date on the original plan document
- Check that the reference class used in the timeline estimate is plausible — 'similar projects have taken 6 weeks' needs to be grounded in actual historical examples
- Ask the submitter what the biggest variance between planned and actual was and what they would have planned differently — this tests whether the log produced genuine learning
- Confirm the project deliverable is real — ask who received it and what they used it for
- Choosing a solo project with no external accountability — the planning skill is most tested when others depend on the plan
- Dependency map that only lists internal dependencies — cross-team or cross-organisation dependencies are the ones most commonly missed in planning
- Weekly log that records only planned activities, not the variance between planned and actual — the log is only useful if it shows where the plan was wrong
Defend Your Plan to a Senior Project Reviewer
1–2 weeks (1 hr session + brief prep)
Present your M2 project — its original plan, weekly log, and final delivery — to a qualified reviewer: a senior project manager, programme director, or experienced delivery lead with 5+ years of delivering complex projects. The reviewer's role is to identify the weakest assumptions in your original plan, challenge your risk management decisions with reference to what actually happened, and present a hypothetical scenario ('what would you have done if X had happened at week 3?') to test your planning robustness under novel conditions.
Proof required
Submit your M2 project documentation plus the reviewer's written assessment: the plan assumptions they identified as weakest and why, their observations on how you managed the risks that appeared in the weekly log, the hypothetical scenario they introduced and your response, and their sign-off confirming their role and a live session.
What gets checked
- Reviewer identifies at least one planning assumption that was weaker than the submitter's own M1 or M2 analysis recognised
- Hypothetical scenario response is procedural (how specifically you would have handled it using the plan and the practices you applied) not conceptual
- Reviewer sign-off confirms 5+ years of delivering complex projects (project manager, programme director, or delivery lead)
Resources
Foundationstart here
What a verifier looks for
- Read the weekly log before the session and identify 2 moments where the plan was significantly wrong — use these as the basis for the challenge questions
- Ask the submitter to identify the single decision in the plan they are least confident was right in retrospect — this tests honest self-assessment
- Reviewer minimum qualification: 5+ years delivering complex projects (multi-team or multi-stakeholder) — a person who has managed only small self-contained projects may not have encountered the planning failures that matter most
- The hypothetical scenario should be a plausible extension of what actually happened — not an extreme edge case but something the plan should have been robust enough to handle
- Presenting the polished final delivery without the weekly log that shows the variance — the log is the most revealing evidence of how the planning held up under real conditions
- A reviewer who focuses on project management frameworks rather than the specific weaknesses in this submitter's specific plan
- Hypothetical scenario response that is vague ('I would have adjusted the plan') rather than specific ('I would have used the buffer I built into week 4 and deprioritised the non-essential scope defined in the plan')