Plan and Ship Projects on Time

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

Common mistakes

• 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

Resources

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

You'll sign in first, then come straight back here.

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

Common mistakes

• 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

Resources

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

You'll sign in first, then come straight back here.

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)

Common mistakes

• 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')

Resources

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

You'll sign in first, then come straight back here.