The RAID review playbook: pressure-testing a plan before an assumption breaks it

"Assume breach" is a cybersecurity mindset, and it is one of the most useful project risk mindsets a PM can carry into a RAID review. Most project plans are quietly built as if the key assumptions will hold: the vendor will deliver, the integration will work, the data will be clean, the sponsor will stay available, the team will remain staffed, the user group will adopt.

A RAID log usually records those assumptions. It rarely tests what happens the moment one of them breaks, which is the entire point of the review. Strategic PMs ask what happens the instant a critical assumption fails, and whether the plan can still reach the outcome from there.

On an operational platform delivery, as pressure rose near MVP, the real question was never whether the plan looked coherent in the deck. It was whether the team could absorb disruption without losing control of the outcome. That is the difference between a RAID log kept for governance appearances and a RAID review that actually changes what you do next.

Good risk work treats failure modes as design inputs, not pessimistic side notes tacked onto the end of a status pack. A RAID review that only lists assumptions is a filing exercise. A RAID review that pressure-tests them is a planning tool.

For each entry in your RAID log, especially in the Assumptions column, run it through four questions instead of leaving it as a static line item.

Breach trigger. What specific event or signal would tell you this assumption has actually failed, rather than just started to look shaky?

Early warning. Is there a signal you could see before the full breach, or will you only find out once the damage has already happened?

Recovery move. If this assumption breaks today, what is the next move, and can the plan reach the outcome from there, or does the outcome itself have to change?

Owner. Who is watching for the breach trigger, and do they know that watching for it is their job?

Run this across the assumptions most likely to be quietly load-bearing on your programme right now.

Vendor delivery. What happens to the plan the week a key vendor deliverable slips or arrives broken?

Integration risk. If the integration does not behave as specified, what is the fallback, and who decides to use it?

Data quality. If the data feeding the programme is dirtier than assumed, what does that do to your timeline and your confidence in the outcome?

Sponsor availability. If your sponsor becomes unavailable or is replaced mid-programme, who else can make the decisions only they were making?

Team staffing. If a key person leaves or is pulled onto another priority, what breaks first, and how long before someone notices?

User adoption. If the target user group resists or under-adopts, does the business case for this programme still hold?

Take your current RAID log and pick the three assumptions most load-bearing to your plan right now. Run each one through the four questions above this week, in writing. If you cannot name a breach trigger, an early warning signal, a recovery move, and an owner for an assumption, you do not have a risk entry. You have a hope. Turning that into a defensible position before you are in the room is exactly what PM Strategy Advisor helps you prepare, so you can stress-test the plan and walk in with the recovery move already decided.