Lesson 4 of 5
Managing RAID
9 min
A RAID log tracks risks, assumptions, issues and dependencies. It is the PMO's early-warning system. A good RAID log is short enough to read, specific enough to act on, and reviewed often enough that nothing in it surprises anyone. A bad one is a spreadsheet of three hundred lines that nobody opens.
| Type | Definition | Contoso example | Key fields |
|---|---|---|---|
| Risk | Something that might happen and would affect objectives | Second data load cycle may slip, delaying SIT | Probability, impact, owner, response, trigger |
| Assumption | Something believed true but not yet confirmed | Dealer portal test environment available from June | Owner, date to validate, consequence if false |
| Issue | Something that has happened and needs action | QAS client 100 refresh failed; testing blocked | Severity, owner, action, due date |
| Dependency | Something the program needs from someone else | SAP service request for a system copy before dress rehearsal 1 | Provider, need-by date, status |
Assessing risks
Score each risk on probability and impact, using scales defined in the risk approach so everyone scores the same way. Impact should be expressed in program terms: schedule, cost, scope and quality, including the quality of the evidence the business will sign. Then choose a response: avoid, reduce, transfer or accept, with an owner and a trigger that tells you when the risk is turning into an issue.
Lifecycle
- IdentifyAnyone raises a risk, assumption, issue or dependency
- AssessOwner scores it and proposes a response
- ActMitigations and actions tracked with dates
- ReviewWeekly at program management; top items monthly at steering
- Convert or closeRisks that occur become issues; validated assumptions close; met dependencies close
Testing risks belong in RAID
Testing is where many upstream risks become visible, so Priya feeds RAID directly. Typical test-related entries at Contoso include data load cycles that would leave SIT without realistic data, interfaces not ready for integration testing, business roles not designed in time for role-based tests, key users not released from daily work for UAT, and service requests for system copies under RISE. Each one has a need-by date tied to a test entry criterion.
Dependencies deserve particular attention in a RISE program, because some of them sit outside the project entirely. System copies, additional systems and technical updates are requested from SAP with lead times; interface partners such as the dealer portal provider have their own release calendars. Grace records each external dependency with the provider, the need-by date and the date by which the request must be raised, so the program chases them before they become issues.
Where to keep RAID
Many programs still keep RAID in a spreadsheet. SAP Cloud ALM's recent implementation best practice material lists risk tasks among its entities, linked to projects; earlier releases relied on project tasks with tags for risks and issues. Check what your tenant offers. Either way, keep RAID where it can link to the plan, requirements and tests, and give every item one owner.
- MondayOwners updateOwners update status and scores for their items
- TuesdayPMO reviewGrace reviews new and changed items; checks triggers and dates
- WednesdayProgram meetingTop ten items discussed; dependencies chased across workstreams
- MonthlySteeringTop risks with trend and decisions needed
What would you do?
Contoso's RAID log has 240 open items, most with the owner "Partner" or "Team", and many have not changed in two months. The steering committee no longer reads it. What should Grace do?
- RAID tracks risks, assumptions, issues and dependencies, each with fields that make it actionable.
- Score risks on agreed probability and impact scales; choose avoid, reduce, transfer or accept with an owner and trigger.
- Feed testing risks into RAID with need-by dates tied to test entry criteria.
- Give every item one named owner, review weekly, and give assumptions validation dates.
Check your understanding · not graded
Lesson check
1. Which belongs in a RAID log as a dependency?
2. What is the difference between a risk and an issue?
3. What should every assumption have?
4. Which response accepts a risk deliberately?