Improve Program Management
12 weeks · 4 milestones
Milestone map
Milestone map
3 milestones
Programme management at scale involves coordinating multiple workstreams across multiple teams toward a shared outcome. Programme failures are specific: missed milestones, untracked cross-workstream dependencies that cause surprises, scope changes not communicated to all affected workstreams, or a lack of visibility into which workstream is the critical path at any moment. The baseline must capture current programme completion rate (percentage of milestones completed on time over the past 6–12 months) and identify the dominant failure pattern with evidence.
Proof required
Submit: (1) a baseline programme completion rate: for at least 2–3 programmes managed in the past 6–12 months, the percentage of milestones completed on their original target dates (not rescheduled dates); if exact data is not available, a sample of 10–15 milestones with their original target and actual completion dates; (2) a failure log: 5 specific programme failures over the past 6–12 months — for each, name the failure type (missed milestone, untracked dependency, scope change communication failure, critical path surprise), the downstream cost, and the cause; (3) a root cause diagnosis (200 words minimum): the dominant programme management structural gap, and a pre-committed structural change — a new dependency tracking process, a programme status ritual, a scope change workflow, or a critical path review cadence — written before implementation.
What gets checked
- Baseline completion rate uses original dates, not rescheduled dates — a milestone that was due 2026-05-01 and rescheduled to 2026-06-01 and completed 2026-06-01 is a missed milestone, not an on-time delivery; the completion rate must reflect the original plan
- Failure log entries are specific and costed — 'a programme was late' is not a failure log entry; 'the API integration milestone was 3 weeks late because the dependency on the auth team's certificate rotation was never tracked, blocking the backend team for 2 weeks when the rotation happened unexpectedly' is a failure log entry
- Pre-committed structural change addresses the dominant failure type — if 4 of 5 failures are untracked dependencies, the change must address dependency tracking, not milestone reporting
Resources
Enroll free to unlock learning resources →Mastery
First Round Review — Programme Management at Scale
Go further: specific programme failure patterns and how to diagnose them structurally.
Unlocks after completing Foundation + Depth