RAID Log Template (With a Worked Example From a Real Programme)

RAID Log Template (With a Worked Example From a Real Programme)

The contractor gives notice. Your Product Owner is unavailable. The PMO wants an escalation note before Friday’s governance meeting.

A RAID log that says “staffing risk: monitor” will not help you handle any of that. A useful log shows what might happen, what has happened, who is acting, and when someone needs to make a decision.

Below is a copyable RAID log template, guidance for each column, and a worked example. One clarification: Meridian PLC, the programme used in the example, is a fictional corporate simulation. The scenario is realistic, but it is not a claim about a real client programme.

Copy this RAID log template

Use one row per item. Keep the type-specific details in the response and trigger columns, rather than forcing every type of item to have the same fields.

ID	Type	Description / cause and effect	Owner	Date raised	Impact	Priority	Trigger / validation test	Next action	Required by	Status	Last reviewed	Escalation / linked item

Use R for risk, A for assumption, I for issue and D for dependency. RAID is not used identically everywhere, so state what your letters mean at the top of the log. Some teams use a different expansion.

If you are building this in a spreadsheet, turn on filters and freeze the header row. Keep the description brief; put supporting detail in a linked note or decision record.

What each column is for

• ID: A unique reference, such as R-01. Keep it even when an item closes.
• Type: Risk, assumption, issue or dependency. These are different things and need different responses.
• Description: State the situation clearly. For risks, use cause → possible event → effect. For other types, say what is unproven, happening or needed.
• Owner: One named person accountable for moving the item forward. “The team” is not an owner.
• Date raised: When the item was added, not the date someone last discussed it.
• Impact: Say what could be affected: scope, schedule, cost, quality, compliance or benefits. Be specific where you can.
• Priority: A practical rating such as high, medium or low. Agree the criteria with your team; do not treat an unexplained red/amber/green label as analysis.
• Trigger / validation test: For a risk, the sign that it is becoming more likely. For an assumption, how you will prove or disprove it. For an issue, what will count as resolved. For a dependency, what must be received or done.
• Next action: The next concrete step, not a vague instruction to “monitor”.
• Required by: The date the action, decision or dependency is needed. Add a separate review date if the item needs checking sooner.
• Status: Use a small, agreed set of values, such as Open, Monitoring, Escalated, Resolved or Closed.
• Last reviewed: Helps you spot stale items. Update it when you have checked the evidence, not just because the meeting took place.
• Escalation / linked item: Record who needs to act or decide, when you escalated, and any related item IDs.

That is the core. Risks need a mitigation and a trigger. Assumptions need a check date and evidence. Issues need a resolution action. Dependencies need a provider and a required-by date. Add fields if your governance needs them, but do not let the sheet become too cumbersome to maintain.

A worked example: Patrick’s notice arrives late

The programme team has been relying on Patrick, a contractor, for key API integration knowledge. The delivery manager has noticed that only Patrick can complete parts of the handover, but has not yet confirmed whether his contract is ending. When notice is finally confirmed, the risk is no longer just a risk: the team has an active issue to manage.

ID	Type	Description	Owner	Priority	Trigger / test	Next action	Required by	Status / escalation
R-01	Risk	If API knowledge remains concentrated with Patrick, his departure may delay integration and testing.	Grace, Delivery Manager	High	Handover sessions missed; no second person can complete a key integration task.	Pair a second developer with Patrick; list critical tasks and record walkthroughs.	Before his final working day	Open. Escalate if handover time is not agreed by Wednesday.
I-01	Issue	Patrick’s resignation is confirmed. His final day is in eleven working days, leaving integration knowledge at risk.	Jamie, Engineering Lead	High	Resolved when a named colleague completes the agreed handover tasks and can run the integration.	Agree a handover plan; protect time; identify any work that needs re-planning.	Before final working day	Open. Linked to R-01; raise resource or scope decision with sponsor if needed.
A-01	Assumption	Priya, the Product Owner, will confirm acceptance criteria for the next sprint before planning.	Grace, Delivery Manager	Medium	Written acceptance criteria received and reviewed before planning.	Ask Priya to confirm a delegate and decision deadline.	Before sprint planning	At risk. If not confirmed, escalate the delivery impact and agree a route to decision.
D-01	Dependency	The PMO needs an updated milestone forecast and an escalation note for its governance review.	Grace, Delivery Manager	Medium	PMO confirms the forecast and escalation note are accepted for the review pack.	Map sprint impact to the Gantt baseline; state any forecast change and decision required.	Friday review	Waiting. Escalate to the PMO Director if the baseline or decision route is unclear.

This example keeps the categories distinct. Patrick’s possible departure begins as a risk. Once his resignation is confirmed, the impact is an issue. The assumption about Product Owner availability is not a commitment. The PMO request is a dependency because the delivery team needs a governance input by a specific date.

Do not quietly change R-01 into I-01 and erase the history. Link the records. That shows whether the early warning was useful and what happened next.

An early-warning log watches signals, not just outcomes

A lag indicator tells you what has already happened: a milestone has slipped, a dependency was missed, or testing has been delayed. It matters, but it tells you late.

A lead indicator gives you a chance to act earlier. In this example, missed handover sessions and the lack of a second person able to complete an integration task are warning signs. They do not prove the programme will slip. They do show that the risk deserves attention.

Use both kinds of indicator in your review:

• Leading: handover not booked, decisions waiting on one person, dependency dates approaching, items with no named owner or next action.
• Lagging: missed milestone, work blocked, defect found, accepted scope reduced or actual rework.

A log full of lag indicators is a record of damage. A log that also tracks leading indicators can help you prevent some of it.

Escalation needs a decision, not a longer description

A senior stakeholder should be able to understand the issue quickly and see what you need from them. Try a three-sentence escalation:

1. What changed: “Patrick has confirmed his final day is in eleven working days.”
2. Delivery impact: “The API integration has knowledge concentrated with him, and the handover is not yet complete.”
3. Decision or action needed: “Please confirm protected handover time this week, or agree which scope or date we should re-plan.”

Keep the supporting evidence in the log or linked note. Do not bury the request in a page of background.

For a Gantt-first PMO, connect the Agile delivery detail to the milestone they govern. Show the forecast, the reason it has changed, and the decision needed. Do not promise a fixed date just to make the report look tidy.

Review the log or it will become paperwork

A RAID log is useful only if someone maintains it. At each review:

1. Check for new evidence and changes to existing items.
2. Challenge assumptions whose validation date is due.
3. Confirm each open item has an owner, next action and date.
4. Look for leading indicators, not just missed outcomes.
5. Record decisions and escalation routes.
6. Close items only when the agreed evidence or acceptance test is met.

The University of Waterloo’s RAID log guidance also treats the log as something to review and update as the work changes. For a public-sector example of separate risk, assumption, issue and dependency entries, see Ofgem’s RAID log.

The practical test: can someone act from your log?

Before you send your RAID log to a sponsor or PMO, check three things:

• Can they tell what might happen or what has happened?
• Is one person accountable for the next action?
• Is it clear what decision or intervention you need, and by when?

If not, tighten the entry. “Resource risk, monitor” is not a plan. “Second developer cannot complete the integration handover; confirm protected pairing time by Wednesday” is something a stakeholder can act on.

At AgileLite, the live RAID log with escalation notes is one of the eight portfolio artefacts practitioners build in the Meridian PLC simulation. The programme runs across eight live three-hour sessions, with a maximum of 10 seats; artefacts are reviewed against FTSE 250 standards. The fee is £1,800 per seat. You can see how AgileLite teaches practical delivery or visit AgileLite’s website.

If you are also working out how to turn a certification into credible delivery evidence, look for our related guide, How to become a Scrum Master with no experience, on the AgileLite site.