Improve Program Management

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

Common mistakes

• Measuring against rescheduled milestones rather than original commitments — a programme that reschedules 80% of its milestones and then hits all the rescheduled dates has a 100% completion rate on rescheduled dates and a 20% completion rate on original commitments; the latter is the honest baseline
• Diagnosing programme failures as team failures rather than programme management failures — 'the backend team was slow' is a team attribution; 'the programme had no mechanism for escalating when a workstream's capacity was at risk' is a programme management diagnosis
• Proposing a status report as the structural change — a status report that summarises programme state is not a structural change to how programmes are managed; the change must alter how dependencies are tracked, how scope changes are communicated, or how the critical path is identified

Resources

What a verifier looks for

• Original vs. rescheduled dates: ask the submitter to show one milestone from the baseline with its original target date and actual completion date — confirm that the baseline uses original commitments, not rescheduled ones
• Programme management vs. team attribution: ask whether the failure incidents were caused by teams underperforming or by programme management gaps — if the answer is primarily team performance, the structural intervention will not address the dominant failure type
• Pre-committed change specificity: ask what specifically will change in how the programme is tracked or managed — a general 'better communication' answer is not specific enough

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

Proof required

Submit: (1) an implementation log with at least 3 dated entries documenting how the structural change was put in place, what workstream leads were briefed, and any adoption friction; (2) post-change delivery data: for at least one programme managed under the new structure (or 10–15 milestones over 3–4 months), the milestone completion rate on original dates, compared to the M1 baseline; (3) dependency or scope tracking evidence: at least 3 specific instances where the new structure surfaced a dependency, a scope change, or a critical path risk before it became a programme failure — name the risk, when it was surfaced, how it was handled, and what would have happened under the old programme management approach.

What gets checked

• Post-change delivery data uses the same measurement methodology as M1 — original target dates, same calculation formula
• Risk surfacing evidence is specific — 'we caught risks earlier now' is not evidence; '2026-07-10: the dependency tracking sheet showed that workstream 3 was expecting an API spec from workstream 1 on 2026-07-15 — a cross-workstream review flagged this 3 weeks early and the spec was delivered 2026-07-13' is evidence
• Adoption is confirmed across workstream leads — programme management structural changes only work if all workstream leads participate; the implementation log must name which leads were briefed and show that more than one workstream is providing data to the new structure

Common mistakes

• Measuring activity (number of programme reviews held, number of risks logged) rather than outcomes (milestone completion rate, programme delivery time) — activity is not delivery
• The pre-committed improvement target was not set in M1 — if no improvement target was pre-committed, any improvement looks like success and any failure looks like an acceptable outcome; the M2 comparison must be against the M1 pre-committed target, not a retrospectively chosen benchmark
• Workstream adoption is incomplete — if only the submitter's workstream is using the new structure and others are not, the cross-functional programme management change has not been adopted; programme management improvements require adoption across all workstreams

Resources

What a verifier looks for

• Measurement consistency: confirm that the M2 post-change completion rate uses the same original-date methodology as M1 — ask to see one example milestone with its original target and actual completion date
• Risk surfacing quality: ask the submitter to describe the best risk-surfacing example in detail — what was the risk, when was it surfaced, how was it handled, and what is the confidence that the old structure would have missed it
• Multi-workstream adoption: ask the submitter to name 2 workstream leads who are actively contributing to the new tracking structure — if only the submitter's team is participating, the programme management change is incomplete

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

Proof required

Submit: (1) a before/after summary: M1 baseline completion rate, post-change completion rate, the structural change implemented, and 3 specific risk-surfacing examples showing the new structure in action; (2) a lessons-learned document (300 words minimum): what the structural change improved (which failure type), which failure type it did not address, and what you would design differently; (3) documentation of a real-time Q&A session with a named reviewer who has ≥3 years of programme or project management experience and a verifiable professional profile — the documentation must include specific challenge questions and your responses; the reviewer must not be a direct report or a workstream lead who participated in the programme.

What gets checked

• Before/after comparison uses the same original-date methodology across both periods — the completion rate improvement must be calculable from the evidence submitted
• Lessons-learned names the failure type the structural change did not address — no single programme management change fixes all failure types; an honest lessons-learned names what remains
• Reviewer is external to the programme — a reviewer who led a workstream in the programme and witnessed the changes cannot give an adversarial view; the reviewer should be evaluating the evidence for the first time

Common mistakes

• Before/after comparison that mixes programme types — a comparison that uses large complex programmes for M1 and small fast programmes for M2 is not apples-to-apples; the post-change programmes should be comparable in scope and cross-functional complexity to the baseline
• Lessons-learned that only credits the structural change — programme delivery variability is also driven by team experience, project type, and external factors; the lessons-learned must acknowledge these
• Reviewer who is familiar with the programme — a reviewer who participated in or heard about the programme during M2 may have formed a prior view; the reviewer should encounter the evidence as a fresh evaluator

Resources

What a verifier looks for

• Comparability: ask the submitter to describe the programmes or milestones used in both M1 and M3 — confirm that they are comparable in scope and cross-functional complexity
• Attribution: ask what else changed between M1 and M3 that might affect programme delivery rates — team experience, project type, team size
• Failure type coverage: ask which programme failure type from the M1 failure log the structural change did NOT address — and why

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