RAID Log & Communication Plan

What you'll produce

A living RAID log (Risks, Assumptions, Issues, Dependencies) for the Unified Checkout program, paired with a communication plan. This is a program-altitude artifact — you write it looking across all three projects (Checkout-Core, Partner-Integration, Migration & Cutover), not zoomed into one. The RAID log scores each risk by likelihood × impact, assigns a named response (avoid / reduce / accept-with-contingency / transfer) and a single accountable owner, and tracks the assumptions, live issues, and cross-project dependencies that could sink your Q3 date — including the two that will bite this program hardest: the shared senior engineer (Diego) and the PCI scope unknown, plus the spine that chains the three projects (Partner-Integration can't test until Checkout-Core ships a stable interface; Migration can't cut over until both are done and PCI signs off). The communication plan then says exactly who hears what, in what format, how often, and from whom — so the VP, the three project leads, Compliance, the partner team, the Ledger PM you share Diego with, and Support are never surprised. This is the core of Topic 7 and the heart of the job: a project/program manager has no authority, so your leverage is seeing trouble before it hits and keeping every stakeholder aligned. A real RAID log is the artifact leadership trusts you to run; a real comms plan is how you turn "manage stakeholders" from a platitude into a schedule.

Instructions

1. Pull your raw material from Deliverables 1–2. Your charter (D1) already lists assumptions, constraints, and named stakeholders; your schedule (D2) already exposes the critical path and dependencies. RAID is where those become managed, not just noted. Open both and harvest: every assumption that, if false, breaks the plan; every cross-team handoff on the critical path; every constraint the business handed you.
2. Build the RAID log as four labelled tables, not one blob. Risks (might happen), Assumptions (believed true, unverified), Issues (already happening, needs action now), Dependencies (you're blocked on someone/something). The single most common beginner error is logging an issue as a risk — if it has already happened, it is an issue and needs an owner and a due date today, not a likelihood score.
3. Score every risk on a 1–5 likelihood × 1–5 impact grid, then multiply for a 1–25 score. Sort the log by score descending. Anything ≥ 12 is a "top risk" you actively manage and report weekly; 6–11 you monitor; ≤ 5 you accept and revisit. Write the L and I numbers explicitly — "High/Medium" is too fuzzy to prioritise or to defend to a VP.
4. Give every risk a named response using one of four strategies. Avoid (change the plan so the risk can't occur), Reduce/Mitigate (lower its likelihood or impact), Transfer (move the exposure to someone better placed — a vendor, Legal, a contract), or Accept (live with it, but write the contingency / trigger — what you'll do if it fires, and the early signal that tells you it's firing). A response with no trigger is a wish, not a plan.
5. Put exactly one human name on every row — never a team. "Engineering will handle it" is how risks die unowned. The owner is the one person accountable for the response, even if others do the work.
6. Force in the two scenario-critical risks. (a) Your shared senior engineer from the charter — the one the capstone names (Diego) as split across two programs — is a single point of failure on the critical path; score it, and your response must address the capacity collision (a written allocation, a pairing/bus-factor fix, and an escalation owner — you arbitrate his time with the Ledger-program PM, Tom), not just hope. (b) PCI-DSS scope is unconfirmed — merging three flows may pull new systems into the cardholder-data environment, which can add weeks of audit and remediation work; score it and transfer the assessment to Legal/Compliance with a hard date and a written contingency for the "scope expands" answer. Use the canonical cast you locked in D1 — the same sponsor, leads, and shared engineer — not a fresh set of names; the worked example below uses that cast so you can copy the pattern, not the strings.
7. Date every row and mark status. Each row gets a Logged date, an Owner, a Status (Open / Mitigating / Closed), and a Last reviewed date. A RAID log is "living" — it is worthless if it is a one-time document. State your review cadence (e.g., revisited in weekly squad sync, re-scored before each status report).
8. Build the communication plan as a table, one row per stakeholder group. Columns: Audience · What they need · Format / channel · Frequency · Owner. Derive the content from your D1 stakeholder map — high-influence/high-interest (the VP) gets tailored, frequent, decision-oriented comms; low-interest/low-influence gets "keep informed" on a slow cadence.
9. Tailor depth to the audience, and name the escalation path. Executives want RAG status + the top 3 risks + the decisions they must make — not a task list. The squads want detail. End the plan with a one-line escalation rule: what triggers an immediate, out-of-cadence message to the VP (e.g., any red status, any critical-path slip, any new risk scoring ≥ 16).
10. Sanity-check coherence. Every critical-path milestone from D2 should appear as a dependency or a risk. Every named stakeholder from D1 should appear in the comms plan. If a stakeholder isn't in the plan, you've already started to surprise them.

Rubric

Levels: Needs work (1) / Solid (2) / Excellent (3). Passing = every criterion at Solid or above.

• RAID is correctly separated — 1: one undifferentiated list, or issues logged as risks · 2: four categories present and mostly correct · 3: clean R/A/I/D split, issues (already happened) clearly distinguished from risks (might happen), each with the right fields.
• Risks scored by likelihood × impact — 1: no scoring or vague "high/low" · 2: explicit L and I with a score and a sort order · 3: defensible scores, a stated threshold for "manage actively," and the log prioritised by it.
• Named responses with triggers — 1: no strategy or "we'll deal with it" · 2: a clear avoid/reduce/transfer/accept per risk · 3: the right strategy per risk plus a concrete trigger/early-signal and contingency, not a wish.
• Single accountable owner per row — 1: unowned or "the team" · 2: a named person on every row · 3: owners are the genuinely accountable individual and match the response (e.g., PCI transferred to Compliance).
• Scenario-critical risks present — 1: shared-engineer and PCI risks missing · 2: both present and scored · 3: both present, scored realistically, with responses that address the real mechanism (capacity collision; CDE scope), not generic mitigations.
• Communication plan fit-for-audience — 1: one-size-fits-all or missing stakeholders · 2: per-group rows with format + frequency · 3: depth tailored to influence/interest, every named stakeholder covered, with a clear escalation rule.
• Living + coherent with prior deliverables — 1: static document, disconnected from charter/schedule · 2: a review cadence stated and traceable to D1–D2 · 3: explicit cadence, every critical-path item appears as a dependency/risk, every charter stakeholder appears in the comms plan, and it visibly feeds the status report (D5).