Project Closure & Retrospective Report
Builds on Topic 9.
What you'll produce
A project closure and retrospective report for the Unified Checkout program — the formal document that confirms the deliverable was met against the charter's success criteria, then mines the project for everything it can teach. It pairs a hard outcome scorecard (did we hit the goal, on time, on scope, with the conversion lift we promised?) with an honest structured retrospective (what went well / what didn't / what we'll change), 3–5 concrete lessons learned with named owners, and a metrics summary that quantifies schedule variance, scope variance, and which of your scored risks actually materialized. This is the one artifact that turns a finished project into reusable knowledge — and it's the source material for the "tell me about a project you ran" interview round (the project-deep-dive). For a project/program manager, closing well is a skill in its own right: it's the difference between a team that repeats its mistakes and one that compounds its lessons, and a report this clean is exactly what a hiring manager wants to see you walk through.
Instructions
- Pull your charter's success criteria forward, verbatim. Open Deliverable 1 and copy each success criterion exactly as you wrote it (the SMART goal, the conversion target, the Q3 date, the in-scope list). You will grade against these, not against a softened version — a closure report that quietly moves the goalposts is worthless. Put them in a table with a Met / Partially met / Not met column and one line of evidence each.
- Compute schedule variance. State the planned finish (your charter's Q3 milestone date and your Deliverable 2 critical-path date) versus the actual finish. Express the slip or lead in calendar days and as a percentage of planned duration. If you slipped, name which critical-path milestone slipped and why — tie it back to the one or two you flagged as most at risk in Deliverable 2.
- Compute scope variance. List what you committed in the charter, then what actually shipped: features delivered, features descoped (and to where — a fast-follow, a later quarter, or cut entirely), and anything added mid-flight. A descope is not a failure if it was a deliberate, communicated triple-constraint trade-off — say so, and say who approved it.
- Run the structured retrospective. Three columns: What went well · What didn't · What we'll change. Write 3–5 items per column, each a specific sentence about this program (the shared engineer, the PCI review, the two-team dependency), not a generic platitude. The "what we'll change" column must be actionable — a different behavior, not a wish.
- Write 3–5 lessons learned, each with a named owner and a forcing function. A lesson without an owner and a mechanism is a diary entry. Format each as: Lesson → so next time we will [concrete change] → owned by [role/name] → enforced by [where it lives]. At least one lesson must come from a risk that materialized (it was in your RAID log) and at least one from a risk you missed (it wasn't).
- Build the metrics summary. A compact table: schedule variance, scope variance, the conversion result vs. target, sprint throughput/predictability if you tracked it, and a "top risks that materialized" row that cross-references your Deliverable 4 RAID log (which fired, which didn't, which surprised you). For conversion, report it at both altitudes and label each: the segment number that satisfies your charter's SC-2 acceptance bar (mobile vs. its baseline) and the blended, program-level lift across all flows — and decide, explicitly, which one is your headline. The blended program-level figure is the number that belongs on your resume, LinkedIn, and interview answer; a big segment lift that you quote as if it were program-wide is the single most common way a closure report overstates impact (and the fastest way an interviewer catches it). Make D6's headline and your career artifacts cite the same number.
- Confirm formal closure. State that the deliverable was accepted (by whom), that the program is handed over to the owning team (named), that access/temporary resources are released, and the date you closed it. This is the "Closure" phase of the lifecycle made real.
- Write the 60-second interview story. End with a tight STAR-shaped paragraph: the situation, your specific role, the biggest obstacle, the trade-off you made, the outcome with a number, and the one lesson — the answer you'd give to "walk me through a project you ran." The outcome number you lead with here must be the same one your resume and LinkedIn carry — the blended, program-level conversion lift — not a different (e.g. segment-only) figure. A learner whose resume says "+2.1 pp blended" and whose interview story says "73%" sounds like two different projects; the whole point of closing well is that one defensible number flows straight from this report into every career artifact.
Worked example
(Program: Unified Checkout at NovaPay. PM/PgM: Priya Shah. Closed 6 Oct 2026. Audience: Sponsor/VP Product Marcus Lin, the two eng leads (Devon Okoro / Ana Ruiz), Legal/Compliance (Nadia Haddad), and the portfolio review.)
1. Outcome vs. charter success criteria
Source: Deliverable 1 charter, "Success criteria" section. Copied verbatim, in the same order, graded exactly as written — including the two inconvenient ones (support tickets, the Oct 5 partner certification). I am grading against the 61%→≥72% bar I set on day one, not a softened "any lift" version.
| # | Charter success criterion (verbatim from D1) | Result | Evidence |
|---|---|---|---|
| SC-1 | Unified flow live for 100% of merchants by Sep 30 — legacy flows off | Met | Single flow GA'd; legacy web/mobile/hosted-link flows behind a kill-switch and decommissioned; 100% of the 4,100 merchants migrated by 2 Oct |
| SC-2 | Mobile-context conversion ≥ 72% in the A/B test (vs. 61% baseline) | Met | A/B test mobile arm reads 73.0% at the day-14 mark (+12.0 pp over the 61% mobile baseline, clearing the ≥72% / +11-point bar). Mobile is ~17% of checkout volume, so this segment lift rolls up to a blended all-flows conversion lift of +2.1 pp (74.8% → 76.9% across web + mobile + hosted-link) — the program-level number; full 30-day read due 2 Nov to confirm durability |
| SC-3 | Zero PCI-DSS findings introduced by the merged flow (Legal sign-off on file) | Met | Compliance (Nadia) signed off 26 Sep; SAQ level unchanged — card entry kept inside the existing tokenization iframe, so the merge did not expand the cardholder-data environment. Zero findings |
| SC-4 | Partner (BigCommerce) integration certified and live for the Oct 5 co-marketing launch | Met | BigCommerce checkout handoff certified 30 Sep; partner co-marketing launched on schedule Oct 5. The 3-day GA slip (below) did not touch this date |
| SC-5 | Checkout-related support tickets down ≥ 20% within 30 days of full rollout | Partially met | Day-14 read: checkout tickets down 14% vs. baseline — short of the ≥20% bar. A late-arriving Support-readiness gap (see retro) spiked tickets in week 1; trend is now improving and the 30-day read is open, owned by Maya Cohen |
Verdict: 4 of 5 criteria fully met; 1 (SC-5, ticket reduction) partially met and still open at the 14-day mark — graded honestly against the ≥20% bar rather than rounded up. SC-2 cleared the hard 61%→≥72% conversion target; PCI held at zero; the BigCommerce/Oct 5 partner commitment landed on time. The one genuine miss-so-far (SC-5) traces to an angle our RAID log under-weighted — Support-readiness lead-time, the gap behind D4 R6 — which becomes Lesson 4 below.
Two true numbers, one headline — pick the right altitude. This program produced two honest conversion figures, and a PM has to know which is which: the mobile-segment lift (61% → 73.0%, +12.0 pp) is the charter's SC-2 acceptance bar — graded here verbatim against D1 — but it describes only the ~17% of traffic that flows through mobile. The blended, all-flows lift (74.8% → 76.9%, +2.1 pp, target ≥2.0 pp) is the program-level business outcome the sponsor cares about and the number that belongs on your resume, LinkedIn, and in the interview. They don't conflict — a +12 pp jump on a 17% slice rolls up to a ~+2 pp blended move — but they answer different questions. Lead with the blended +2.1 pp (it's the program's impact and it matches the SMART goal's business case), and cite the mobile +12 pp as the driver behind it. Quoting "+12.4 pp" as the headline overstates program-wide impact (a sharp interviewer will catch that it's a segment number) and quoting only "+2.1 pp" buries how decisively the mobile flow moved. The metrics table below reports both, clearly labelled, so the one number you carry into every career artifact is the defensible one.
2. Schedule variance
- Planned finish (charter SMART goal + D2 critical path): 30 Sep 2026, from charter sign-off (M1, 20 Jun). Planned duration: ~14.5 weeks (20 Jun → 30 Sep = 102 calendar days).
- Actual finish (GA / 100% rollout): 3 Oct 2026. Actual duration: 105 calendar days.
- Schedule variance: +3 calendar days late (+2.9% of planned duration).
- What slipped: the PCI scope sign-off chain — D1's milestone M2 (technical design + Legal PCI sign-off, target Jul 11) ran late, exactly the item we'd scored as the #1 risk (D4 R1, PCI-DSS scope expands, L4×I5 = 20). Legal needed a second review pass to confirm the tokenization iframe kept us out of an expanded CDE; that pushed M2 sign-off and cost the build window its buffer, surfacing again as a 3-day slip at the M5 rollout gate. Critically, R1 did not fully fire — the scope didn't expand (so SC-3 held at zero findings) — but the assessment cost more calendar time than budgeted. The two-team checkout-merge dependency landed on time because we front-loaded it, so the variance came from our top-scored risk, not a surprise.
3. Scope variance
| Committed in charter (D1 in-scope) | Outcome |
|---|---|
| One checkout flow serving web, mobile, and hosted-link contexts | Delivered |
| Migrating all 4,100 merchants to the new flow | Delivered (100% by 2 Oct) |
| BigCommerce partner API integration (checkout handoff) | Delivered (certified 30 Sep, live Oct 5) |
| Re-validating PCI-DSS scope for the merged flow | Delivered (Legal sign-off, SAQ unchanged) |
| A/B-tested rollout + rollback plan | Delivered (kill-switch + canary) |
| Saved-card "express" path (a mid-flight ask, never in the charter — surfaced as D4 R4 scope creep) | Descoped to a Q4 fast-follow — routed to the R4 parking-lot and traded with a triple-constraint memo; approved by Marcus Lin (sponsor) at the 11 Sep status review to protect the Sep 30 date |
| BNPL (charter out-of-scope, Q4 fast-follow), re-requested by Sales (Aug) | Held out of scope, deferred to Q4 — the written out-of-scope line in D1 held; logged as a decision, never absorbed |
| — | Added mid-flight: a one-screen legacy-flow kill-switch (not in charter) — needed for a safe 100% cutover and the rollback plan; +3 story points, absorbed without moving the date |
- Scope variance: every committed charter item shipped; the only descope (saved-card express path) was an added ask we declined to absorb, traded openly through the R4 process, not a cut to anything we'd promised. BNPL stayed out per the charter. Net: 100% of committed charter scope delivered on the committed date, with the express path consciously parked to Q4 — a held line, not a miss.
4. Structured retrospective
| What went well | What didn't | What we'll change |
|---|---|---|
| Front-loading the two-team checkout-merge dependency into Sprint 1 took the cross-team integration off the critical path — it landed in week 6 with zero slip. | We under-budgeted the PCI scope assessment (D4 R1). We treated Legal sign-off (M2) as a 2-day rubber stamp, but it needed a second review pass and cost us the buffer — the only thing that slipped the date. | Bring Legal into Sprint 1, not at M2. Make compliance a Definition-of-Done gate on every card-data story and book the scope-assessment slot at kickoff, not the week before. |
| Weekly RAG reports (Deliverable 5) meant the express-path descope was a calm, pre-agreed decision with Marcus — no end-of-quarter surprise. | The shared senior engineer (Diego, 50% on the Ledger program — D4 R2) became a real bottleneck in weeks 4–5 when Ledger took a bigger slice of him than the 60% we'd agreed. | Fund the contingency, don't just log it. Pre-agree a named backfill for any <100% critical-path engineer at charter time and front-load their work — the R2 pairing with Aïsha helped, but it was set up too late. |
| The kill-switch + canary (the charter's rollout/rollback commitment) let us cut over 100% of traffic safely and de-risked the single riskiest moment of the program. | Standups drifted long (25–30 min) in the middle sprints because we debugged in the meeting instead of taking it offline. | Hard 15-min time-box; "park and pair" rule — any debugging moves to a breakout, not the standup. |
| The data analyst (Sam) instrumented the funnel per segment and blended before GA (per D4 R5), so we had a clean 61% mobile baseline and a 74.8% blended baseline — letting us report both the 73.0% / +12.0 pp mobile lift (SC-2) and the +2.1 pp blended program-level result credibly, instead of a single number that hides which traffic moved. | We scored Support too low. D4 R6 ("Support overwhelmed at launch") fired, but we'd rated it 9 (monitor) and logged launch ticket volume without ever logging runbook/training lead-time — so Maya Cohen got the runbook days before GA, the week-1 spike hit, and SC-5 (tickets ≥20% down) is only partially met at day 14. | Loop Support in two sprints early with a draft runbook and a demo — and add a distinct "Support-readiness lead-time" risk, the angle R6 missed (see Lesson 4). |
5. Lessons learned (owned + enforced)
- PCI/compliance is critical-path work, not a checkpoint (from a risk that materialized — D4 R1, "PCI-DSS scope expands," our top-scored risk at 20). → Next time we schedule the Legal scope assessment at kickoff and gate every card-data story's Definition of Done on compliance review. → Owned by: PM (Priya) + Legal/Compliance (Nadia Haddad). → Enforced by: a DoD line in the team's Jira workflow + a kickoff calendar hold on the M2 review.
- A part-time critical-path person needs a funded backfill, not just a logged risk (from a risk that materialized — D4 R2, "shared engineer Diego pulled to Ledger," scored 16). → We pre-agree a named backup with the eng leads and front-load the shared person's critical-path work into Sprint 1, instead of standing up the Aïsha pairing only once R2 was already firing. → Owned by: PM (Priya) + eng leads (Devon Okoro / Ana Ruiz). → Enforced by: a staffing line in the charter's assumptions/constraints section, re-confirmed at every sprint planning (it ties to D4 assumption A4).
- Instrument the success metric before you ship — at both altitudes (what went well — make it the default; ties to D4 R5). → The conversion baseline and dashboard are a Sprint-1 deliverable, not a post-launch scramble, and we capture the metric per segment and blended so we can both grade the SC-2 mobile bar (61% baseline) and report the blended +2.1 pp program-level lift the sponsor and the resume need — never just one number that hides which traffic moved. → Owned by: Data analyst (Sam). → Enforced by: a backlog item created automatically at charter approval, specifying segment + blended baselines.
- Bring the downstream team (Support) in two sprints early (from an angle we MISSED — D4 R6 logged launch ticket volume but never the runbook/training lead-time, the gap that actually fired and dropped SC-5 below its ≥20% bar). → Support gets a draft runbook and a demo at the mid-point, not days before GA, and "Support-readiness lead-time" gets logged as its own scored risk on day one. → Owned by: PM (Priya) + Support lead (Maya Cohen). → Enforced by: a standing "downstream readiness" item in the comms plan + a new RAID row at charter time.
- A communicated trade-off beats a silent one (what went well — protect it). → When the triple constraint binds, we trade scope visibly and early with the sponsor — exactly how the express-path descope went to Marcus through the R4 parking-lot — not silently and late. → Owned by: PM (Priya). → Enforced by: the weekly RAG report's "decisions needed" section (Deliverable 5).
6. Metrics summary
| Metric | Plan / Target (from D1) | Actual | Variance |
|---|---|---|---|
| Finish date (100% rollout) | 30 Sep 2026 | 3 Oct 2026 | +3 days (+2.9%) |
| Committed charter scope delivered | 100% | 100% (express-path ask parked to Q4, nothing committed cut) | 0 — held |
| Mobile-context conversion (A/B, day-14) — the SC-2 charter bar | ≥ 72% (vs. 61% mobile baseline) | 73.0% | +1.0 pp over the ≥72% target, +12.0 pp over baseline — SC-2 met |
| Blended all-flows conversion (web + mobile + hosted-link) — the program-level / resume number | ≥ +2.0 pp lift | 76.9% (from 74.8% baseline) | +2.1 pp blended — clears ≥2.0 pp; the mobile segment is the driver |
| PCI-DSS findings introduced | Zero (SAQ unchanged) | Zero (CDE not expanded; SAQ unchanged) | 0 — held (SC-3) |
| Partner (BigCommerce) certified for Oct 5 | Live Oct 5 | Certified 30 Sep, live Oct 5 | On time (SC-4) |
| Checkout support tickets (vs. baseline) | ≥ 20% down in 30 days | 14% down at day 14, 30-day read open | −6 pp short so far — SC-5 partially met |
| Sprint predictability (committed vs. done, 6 sprints) | — | 88% avg (range 75–100%) | dip in S4–S5 (Diego pulled to Ledger — R2) |
| Top risks that materialized | — | R1 PCI scope assessment (fired on timing — cost the buffer, +3 days — but scope did not expand, so SC-3 held); R2 shared engineer Diego (fired in wks 4–5, blunted by the Aïsha pairing). R3 partner-API slip did not fire. R6 Support-at-launch fired but was under-scored (9), and its runbook-lead-time angle was unlogged — that miss dropped SC-5. | 2 top risks (R1, R2) fired; R6 fired under-weighted; R3 held |
7. Formal closure
- Deliverable accepted by: Marcus Lin (Sponsor / VP Product) and the BigCommerce partner-integration lead (Greg Tan), 3 Oct 2026.
- Handover: Unified Checkout is now owned by the Checkout squad (eng leads Devon Okoro / Ana Ruiz) for steady-state operation; the saved-card express-path fast-follow and the Q4 BNPL item move to their backlog with full context.
- Resources released: Diego returns to his Ledger-program split; the temporary cross-team Slack channel and shared board are archived (read-only) for the record.
- Program formally closed: 6 Oct 2026 — with two open threads handed off, each with a named owner and a date: (1) the 30-day conversion read (confirming SC-2 holds) scheduled 2 Nov 2026, owned by Sam (Data); and (2) the 30-day support-ticket read (the still-open SC-5 ≥20% bar) owned by Maya Cohen (Support), who reports both to Marcus at the next portfolio review.
8. The 60-second interview story
"I ran the Unified Checkout program at NovaPay — merging three legacy checkout flows into one against a hard Q3 deadline locked to a BigCommerce partner launch on October 5, with a vague spec, two teams with competing priorities, and a senior engineer only half-allocated to me. As the program manager I owned the plan, the risks, and the comms. My biggest obstacle was that shared engineer, Diego — I'd scored 'Diego pulled to Ledger' as my second-highest risk, and in weeks 4–5 Ledger reclaimed him right on the critical path. Because I'd flagged it, I'd already paired him with a mid-level on the orchestration work and front-loaded it, which absorbed most of the hit. The harder call came in September: to protect the date I traded scope, parking a saved-card express-path ask to a Q4 fast-follow — but I did it visibly, with the sponsor's sign-off at a status review, not silently. We shipped three days late but hit the promise that mattered: one unified flow live to all 4,100 merchants, zero PCI findings, the partner certified for October 5, and a +2.1-point blended conversion lift across all flows against my ≥2.0-point target — driven by the mobile flow jumping from 61% to 73%, which cleared the 11-point mobile bar I'd committed in the charter. The lesson I took: treat PCI/compliance as critical-path work from day one — the only thing that slipped the date was the scope sign-off, because I'd budgeted it as a checkpoint instead of real work. And I left two reads owned and dated — the 30-day conversion and ticket numbers — because closing a project means handing off the open threads, not hiding them."
Rubric
The app's AI scores the learner's submission against these criteria and gives feedback. Levels: Needs work (1) / Solid (2) / Excellent (3). Passing = every criterion at Solid or above.
- Graded against the real charter — 1: success criteria vague, softened, or invented at closure · 2: each charter criterion restated and marked met/partially/not-met with evidence · 3: graded verbatim against Deliverable 1, including the inconvenient ones, with honest "partially met" calls and one-line proof each.
- Quantified schedule & scope variance — 1: "mostly on time/on scope" with no numbers · 2: schedule variance in days/% and scope variance as delivered/descoped/added · 3: both quantified and tied to the specific critical-path milestone and the deliberate, signed-off trade-off that caused them.
- Honest structured retrospective — 1: generic or all-positive ("good teamwork") · 2: specific went-well / didn't / will-change items about this program · 3: every "what we'll change" is a concrete behavior change, and the column names real failures (PCI under-budgeted, standups drifting) without spin.
- Lessons with owners and forcing functions — 1: lessons are diary entries with no owner · 2: 3–5 lessons each with a named owner and a concrete change · 3: each lesson is enforced by a real mechanism (DoD gate, charter line, automated backlog item), and includes at least one from a materialized risk and one from a risk that was missed.
- Metrics summary cross-referenced to the RAID log — 1: no metrics table or disconnected from earlier work · 2: compact table with schedule, scope, outcome, and which risks fired · 3: explicitly maps to Deliverable 4 (which scored risks materialized, which didn't, what surprised you) and reports the success metric against target.
- One canonical conversion number, at the right altitude — 1: a single conversion figure quoted ambiguously, or a segment lift (e.g. mobile +12 pp) passed off as the program-wide result · 2: both the SC-2 segment number and a blended program-level number are reported and labelled · 3: the segment lift is graded verbatim against the charter's SC-2 bar and the blended program-level lift is named as the headline — and that same headline number flows unchanged into the interview story (and is the one the resume/LinkedIn artifacts will cite), so the project tells one consistent story end to end.
- Formal closure + interview-ready story — 1: no acceptance/handover, or no narrative · 2: states acceptance, handover, and a STAR-shaped story · 3: closure is real (named acceptor, named owning team, resources released, open thread owned with a date) and the 60-second story lands a number and a single sharp lesson.