Weekly Status Report (RAG Dashboard)
Builds on Topic 8.
What you'll produce
A one-page weekly portfolio status report for the Unified Checkout program — the recurring artifact a program manager actually sends to leadership every Friday. Because this is a program of three projects (Checkout-Core, Partner-Integration, Migration & Cutover), the report rolls all three up into one picture: a per-project RAG row and a single program RAG that is never greener than the worst project on the cross-project critical chain. It opens with that program RAG and a one-line headline a busy exec reads in ten seconds, then drills down: progress vs. plan per project, the cross-project milestones hit and at risk, the top 3 risks/blockers with owners and a specific ask, decisions you need from leadership this week, and a tight "what changed since last week" so a reader who skipped last week can catch up in one glance. This proves the core Topic 8 skills — keeping an accurate status picture, communicating it with RAG so health is obvious at a glance, rolling a portfolio of projects up to one honest signal, surfacing problems early (the recurring trust-building habit), and writing with the brevity that earns an exec's attention. It is the single most-read thing you produce as a program manager: a steady, honest weekly signal is what makes leadership trust you to run three projects to one date without watching over your shoulder.
Instructions
- Pull your inputs before you write. Open the board (sprint burndown, story status), the schedule/critical path (Deliverable 2), and the RAID log (Deliverable 4). The report summarizes these — never invent a number you can't point to in a tool.
- Set the date, reporting period, and "next milestone" header. State the week as a real program week tied to your D2 schedule (e.g., the worked example sits at "Week of Aug 3–7, program week W8, Sprint 4 of 6") and the next hard date on the critical path — the next milestone ID from D2, with its planned week — so the deadline pressure is always visible at the top. If a week, sprint number, or milestone date doesn't map to a row in your schedule, you've invented it (Instruction 1).
- Roll the three projects up to one program RAG, and justify it in one rule. First give each project its own RAG (Checkout-Core, Partner-Integration, Migration & Cutover) in a one-line rollup row. Then set the program RAG by an explicit rule you apply every week, not a gut feel: per project, Green = on track for its scope/date, no exec action; Amber = a milestone or scope at risk but you have a plan / need a decision; Red = its committed date or scope will miss without intervention now. The program RAG is never greener than the worst project on the cross-project critical chain (the same rule you set in the Deliverable 7 roadmap) — a Green project off the chain can't paper over an Amber one on it. Trust dies when "Green" hides a slip; when in doubt, go Amber and say why.
- Write the one-line headline. One sentence, plain English, that a VP could forward untouched: the status, the single most important fact, and the one thing you need. If it needs a second sentence to make sense, it's not tight enough yet.
- Show progress vs. plan with numbers, not adjectives. "On track" means nothing; "12 of 18 stories done, sprint burndown tracking to finish 1 day early" means something. Tie progress back to the plan's milestones, not just activity.
- Run a milestone table: Hit / On track / At risk / Slipped with the planned date and a one-line status each. Mark each milestone's own RAG. The overall RAG should never look healthier than your worst near-term critical-path milestone.
- List the top 3 risks/blockers — no more. For each: a plain-English description, the owner (a named person, not a team), the impact if unaddressed, and the specific ask of leadership ("approve X," "decide between A/B by Wed," "free up person Y") — or "no ask, FYI" if you've got it handled. Pull these straight from your RAID log so the report and the log agree.
- Add a "Decisions needed this week" line. Separate decisions from risks: a decision is a fork you can't resolve yourself and need an answer on by a date. Name the decision, the options, your recommendation, and the deadline. An exec who reads only this line should know exactly what you need from them.
- Write "What changed since last week." 3–5 bullets max: status moves (Green→Amber and why), milestones that shifted, risks that opened or closed, decisions made. This is what lets a skimming reader trust the trend, not just the snapshot.
- Cut it to one page and read it as the exec. If a sentence doesn't change a decision or an action, delete it. No raw Jira IDs, no "we had a productive sprint" filler. The test: a VP gets the true health in ten seconds and knows what (if anything) you need from them.
Worked example
(Unified Checkout program, NovaPay. Week of Aug 3–7, 2026 — program week W8, Sprint 4 of 6. Every name, date, and number below is carried forward from the charter (D1), schedule/critical path (D2), and RAID log (D4) — nothing is invented here; if it isn't in one of those artifacts, it isn't in this report. Hard deadline: GA by Sep 30, tied to the BigCommerce partner launch (Oct 5) and the Q3 marketing push. Cast and dates are the D1 canonical set: sponsor Marcus Lin (VP Product); PgM Priya Shah (you); Checkout-Core / Team A lead Devon Okoro; Partner-Integration / Team B lead Ana Ruiz; PCI/Compliance gate owner Nadia Haddad; shared payments engineer Diego (50% on the Ledger program, whose PM is Tom); partner liaison Greg Tan (BigCommerce); data Sam.)
Why W8 is the week to model. A status report is only honest at a real moment on the real schedule. D2's critical path runs
… 3.1b orchestration (ends W8) → 3.2 web flow (W10) → 5.3 partner joint test (W11) → BUF buffer (W12–13) → 6.2 rollout (W15) → Sep 30. W8 is the week M3 (orchestration, 3.1b) lands — a critical-path node — and the next hard date is M4 (PCI/QSA sign-off + all three flows built, ends W10, wk of Aug 17–21). That is exactly when the shared-engineer risk (D4 R2) and the PCI-scope risk (D4 R1) are both live, so the worked example sits where the report has something real to say.
UNIFIED CHECKOUT — Weekly Status To: Marcus Lin (VP Product, sponsor), Unified Checkout steering group · From: Priya Shah, Program Manager Period: Aug 3–7, 2026 · Program week W8 · Sprint 4 of 6 · Next hard milestone: M4 — PCI/QSA sign-off + all three flows built — ends W10 (wk of Aug 17–21) [D2]
🟡 Program status: AMBER
Headline: On scope and still on the Sep 30 GA date, but the M4 PCI/QSA sign-off (Aug 17–21) is one Diego-reclaim away from eating our only buffer — I need you to lock Diego at 80% through M4 by Fri Aug 7; I have a recommendation and need a yes/no.
Portfolio rollup (three projects → one program RAG)
| Project | Lead | RAG | One-line status |
|---|---|---|---|
| Checkout-Core (Team A) | Devon Okoro | 🟢 Green | Orchestration (3.1b, M3) landed this week on plan; web/mobile/hosted-link flows (3.2–3.4) now building |
| Partner-Integration (Team B) | Ana Ruiz | 🟢 Green | Integration (5.2) building on the frozen interface; BigCommerce joint test (5.3) set for W11 (Aug 24–28) |
| Migration & Cutover (PCI gate) | Nadia Haddad | 🟡 Amber | QSA review (4.3) opens W9; M4 sign-off rides the assessor's Aug 17–21 window — and Diego (the only vault engineer) is half-pulled to Ledger (see Risk 1) |
| PROGRAM | (Priya Shah, PgM) | 🟡 Amber | Rule: program RAG = worst project on the cross-project critical chain. The PCI/QSA gate (M4) is on the chain and Amber → program Amber, even though Checkout-Core and Partner-Integration are Green. |
Progress vs. plan (per project)
- Checkout-Core — Sprint 4 (W7–W8, Jul 27–Aug 7): orchestration & routing (3.1b, M3) merged Wed — on plan, the critical-path node for the week. Burndown tracking to close the sprint clean; web flow (3.2) and the mobile/hosted-link variants (3.3, 3.4) started against the now-frozen payment interface. First time all three legacy flows share one codepath end-to-end in staging.
- Partner-Integration: unblocked once the interface froze at M3; partner integration (5.2) is building to the BigCommerce contract Greg Tan froze at the W3 milestone. End-to-end joint test (5.3) holds at W11 (wk of Aug 24–28) — sandbox availability confirmed, no schedule change.
- Migration & Cutover / PCI: remediation (4.2) closing; the external QSA review (4.3) opens W9 and runs to M4 (ends W10, Aug 17–21) — 10 days, mostly external wait time we don't control. This is the binding near-term gate.
- Cross-project critical chain (verbatim from D2):
3.1b orchestration (W8) → 3.2 web flow (W10) → 5.3 partner joint test (W11) → BUF buffer (W12–W13) → 6.2 rollout (W15) → Sep 30. The program's real float is the 2-week buffer (BUF, W12–W13) D2 placed between the converging M4/M5 milestones and the irreversible cutover, plus the Sep 26–30 go/no-go margin after M6. That buffer is the whole cushion — and it was sized to absorb exactly one round of QSA findings, no more.
Milestones
| Milestone | Planned (D2) | Status | Note |
|---|---|---|---|
| M2 — Design approved (2.2) | W5 (Jul 13–17) | 🟢 Hit | Approved on schedule; unblocked the core build |
| M3 — Core orchestration done (3.1b) | W8 (Aug 3–7) | 🟢 Hit | Merged Wed Aug 5 — the critical-path node for this sprint |
| Three flows built (3.2–3.4) | W10 (Aug 17–21) | 🟢 On track | Web/mobile started this week; hosted-link follows in W11 |
| M4 — PCI/QSA sign-off (4.3) | W10 (Aug 17–21) | 🟡 At risk | External QSA wait + Diego is the sole vault engineer (D4 R1/R2); see Risk 1 |
| M5 — Partner joint test (5.3) | W11 (Aug 24–28) | 🟢 On track | BigCommerce sandbox confirmed; contract frozen at W3 |
| M6 — 100% rollout live (6.2) | W15 (Sep 21–25) → Sep 30 | 🟢 On track | Immovable; protected by the BUF (W12–13) + the Sep 26–30 margin |
Top risks / blockers
- Shared-engineer capacity collision (D4 R2, scored 16): Diego is the only engineer who knows the tokenization vault, and the M4 QSA sign-off (W9–W10) needs him to turn QSA findings around — but he's 50% on the Ledger program. Owner: Priya Shah, PgM — this is a program-level arbitration neither lead can settle. Impact: if Diego stays at 50% and the QSA returns findings, the remediate-and-re-review cycle can't finish inside the M4 window, M4 slips past W10, and it eats straight into the 2-week BUF (W12–13) — the program's only cushion before the Sep 30 cutover. Ask: approve Diego at 80% on Unified Checkout through M4 sign-off (W10 / Aug 21); Tom (Ledger PM) has agreed in principle to backfill his lower-priority refactor — need your call by Fri Aug 7.
- PCI/QSA scope or timing (D4 R1, scored 20 — our top risk): the external assessor has a hard Aug 17–21 booking window; any slip upstream, or any findings needing a second pass, pushes sign-off toward mid-September and zeroes the buffer. Owner: Nadia Haddad (Legal/Compliance, PCI gate). Impact: a late or twice-cycled assessment compresses the GA buffer to nothing. No ask this week — mitigated by holding tokenization inside the existing iframe so the merge doesn't expand the cardholder-data environment (per R1's contingency); flagging so the steering group sees why Risk 1's Diego decision matters downstream.
- Hosted-link flow (3.4) is the thinnest-staffed build and trails web/mobile by a sprint — if it slips it converges late on the W12 migration tooling. Owner: Devon Okoro (Checkout-Core lead). Impact: a late hosted-link flow would push 6.1 migration tooling and erode BUF from the other side. Ask: none yet — Devon is re-sequencing Team A to start 3.4 a week early; I'll report whether that holds next week. Escalating only if it slips again.
Decisions needed this week
- Diego's allocation (Ledger vs. Unified Checkout) through M4. Options: (a) keep 50/50 and accept that any QSA findings can't be cleared inside the Aug 17–21 window — M4 slips and consumes the BUF; (b) move Diego to 80% on Unified Checkout through M4 sign-off (W10 / Aug 21) and backfill Ledger's lower-priority refactor (Tom has agreed in principle). My recommendation: (b) — it protects the binding gate on the cross-project critical chain in exchange for two weeks of lower-priority Ledger work, and keeps the BUF intact as real cushion rather than slip-absorption. Decision needed by Fri Aug 7. (Full arbitration logic is in the Deliverable 7 roadmap; this is the weekly surfacing of it, and it ties straight to D4 R2.)
What changed since last week
- Program RAG moved 🟢 Green → 🟡 Amber — solely because Migration & Cutover crossed into Amber as the QSA window (Aug 17–21) came into range with Diego still half-allocated; Checkout-Core and Partner-Integration stay Green. Scope and the Sep 30 GA date are unchanged.
- M3 hit on schedule (Aug 5): orchestration & routing (3.1b) merged — the critical-path node for the sprint — which froze the payment interface and unblocked Partner-Integration's build.
- QSA review (4.3) entered the next-milestone window: booked into the assessor's Aug 17–21 slot, which is what surfaced the Diego/PCI collision (D4 R1 × R2) as this week's live risk.
- New risk opened: hosted-link flow (3.4) under-staffing (Risk 3); Devon re-sequencing Team A to start it early.
- Closed: design approval (M2) confirmed last week; dropped from the active-risk list.
Note on craft: the program RAG is Amber even though two of the three projects are Green — because the one Amber project (Migration & Cutover / the PCI gate) sits on the cross-project critical chain, and the rollup rule says the program is never greener than its worst project on that chain. Everything here is checkable against an upstream tool: the milestone dates and the critical chain are read straight off D2's Gantt (W8 → W10 → W11 → BUF → W15 → Sep 30), the two top risks are D4 R2 (score 16) and R1 (score 20) with their D1 owners, the buffer is D2's named BUF block (W12–13) — not an invented "9-day float" — and the sponsor is the same Marcus Lin who signed the charter and will accept the closure. A single project board would have shown two greens and missed the program risk; the program manager's rollup surfaces it early, with a specific, time-boxed ask, while it's still cheap to fix. An exec finishes this in ten seconds knowing the program is fundamentally healthy across three projects and that they owe you one decision by Friday.
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.
- Portfolio rollup (three projects → one program RAG) — 1: a single project's status with no per-project rollup, or a program RAG greener than its worst critical-chain project · 2: each project gets its own RAG plus a program RAG with a stated rule · 3: per-project RAGs roll up to a program RAG that strictly follows "never greener than the worst project on the cross-project critical chain," the rule is stated in one sentence and is consistent with the Deliverable 7 roadmap — a single Green project off the chain visibly cannot mask an Amber one on it.
- Program RAG + ten-second headline — 1: no clear status, or a headline that needs the whole report to decode · 2: a defensible RAG and a one-line headline an exec can read fast · 3: RAG justified by a consistent rule, headline forwardable untouched, status honestly Amber/Red when the critical chain warrants — never green-washed.
- Progress vs. plan with real numbers — 1: vague adjectives ("good progress," "on track") with no figures · 2: concrete progress tied to plan (points done, burndown, epics complete) · 3: progress traces to specific milestones and the critical path, distinguishing activity from outcomes.
- Milestone health (hit / on-track / at-risk / slipped) — 1: missing, or every milestone marked green · 2: a dated milestone list with per-item status · 3: per-milestone RAG that is consistent with the overall RAG (overall never healthier than the worst near-term critical-path milestone), with a crisp note each.
- Top risks/blockers with owners and a specific ask — 1: generic risks, no owners, or no ask · 2: top ~3 risks each with a named owner and a clear ask · 3: risks pulled straight from the RAID log, each with a named person (not a team), impact stated, and a precise, time-boxed ask — including the shared-engineer and PCI risks.
- Decisions needed — 1: decisions buried in prose or absent · 2: decisions called out separately with a deadline · 3: each decision states options, a recommendation, and a hard date — an exec reading only this section knows exactly what you need.
- "What changed since last week" — 1: missing or a restatement of the snapshot · 2: a short list of real changes since last report · 3: explains status moves and why (e.g., Green→Amber), tracks risks/decisions opened and closed — lets a skimmer trust the trend, not just the snapshot.
- Brevity and exec readability — 1: multi-page, raw ticket IDs, filler · 2: roughly one page, scannable, jargon-light · 3: ruthlessly cut — every line changes a decision or action; a busy VP gets true health and their ask in ten seconds.