RAID Log Example: A Filled-In Log from an ERP Migration

The example

The programme below is invented, but the shape of it is ordinary: a manufacturer with three sites replacing a fourteen-year-old on-premise ERP with a cloud product, go-live in May, workstreams for finance, supply chain, HR and payroll, data and integration. The log is shown as it stood in week 8, before dry run 2. Seventeen live entries is about right for a programme this size at that point; it grows to forty or so during cutover and shrinks again afterwards.

Reading the example

The columns are the same eleven described in the RAID log guide. What separates a log people use from a log people update is almost entirely in how these columns are filled.

• ID - a stable reference with a letter for the type. It exists so that a status report, a meeting minute and an escalation email can all point at the same thing. IDs are never reused when an entry closes.
• Type - risk, assumption, issue or dependency. The test is tense: a risk has not happened, an issue has, an assumption is something being treated as true without evidence, and a dependency is something someone outside the team owes you. Entries that sit uneasily between two types are usually written badly rather than genuinely ambiguous.
• Description - one or two sentences with a cause and an effect, as in R-01. A description that reads "resource risk" or "data quality" is a category, not an entry; nobody can act on it and nobody can tell later whether it closed.
• Owner - a named person, not a team. For dependencies the owner is the person outside the project who has to deliver, with the internal chaser named alongside if that helps. "The PMO" as an owner means the entry is unowned.
• Raised - the date it entered the log. Its real use is age: an entry raised in week 2 and still untouched in week 8 is telling you something about the entry or about the owner.
• Probability and impact - a coarse scale, three or five points. Impact is left blank for issues, because an issue has already occurred, and for dependencies, where the useful question is what happens if the date is missed. Precision here is false comfort; the value is in forcing a conversation, not in the number.
• Rating - the derived red, amber or green. In a workbook this is calculated, not typed, so nobody can quietly downgrade a risk without changing probability or impact and leaving a trace.
• Response and next action - the response type (mitigate, accept, transfer, avoid; validate for assumptions) followed by what is actually being done, by whom, and by when. Compare I-01, which names the fix and the retest, with an entry that says "monitoring the situation". Monitoring is not an action.
• Due - the date the next action is expected, not the date the risk disappears. A due date in the past with an open status is the single most useful sort in the log.
• Status - open or closed, with closed entries kept in place. A log that deletes closed items loses the record of what the project chose to do, which is exactly what anyone reviewing the programme later wants to see.

What the good entries have in common

Read R-01 and I-02 next to each other. Both name a specific thing, a specific consequence and a specific action with a date. Neither says "may impact delivery", which is true of everything in the log and therefore says nothing.

The dependency entries carry a needed date and a committed date as separate facts. D-01 has both and they agree, so it is amber rather than red only because the confirmation is three weeks old. D-02 has a needed date and no commitment at all, which is what makes it the entry the programme board should be looking at. Merging those two dates into one column loses the gap, and the gap is the whole point. The dependency tracking guide goes further into what to record for items you do not control.

Assumptions are the entries most often written vaguely, because an assumption that is stated precisely can be proved wrong. A-01 names the party, the thing being assumed and the test that settles it. When the test comes back, the assumption closes and either nothing happens or an issue is raised. A-02 shows the second outcome: the usage logs found nine reports still in use, which became a change request rather than a surprise in UAT.

How the log moves between weeks

In practice the log is worked once a week in a half-hour session with the workstream leads, and touched ad hoc in between. Three things happen in that session: entries with a due date in the past get a new action or a new date with a reason, entries whose rating has changed get re-scored in front of everyone, and anything closed is closed properly with a note rather than deleted.

The reporting layer follows from that. Red entries and anything escalated go into the weekly report; the rest stay in the log. That is why a RAID log and a weekly status report should read from the same source rather than being maintained separately - two versions of the same risk with different wording is how a steering committee ends up with the wrong impression of a programme.

What this example leaves out

A real log carries more than fits on a page. The obvious omissions here:

• History. There is no record of what R-02 looked like three weeks ago, when it was scored medium/medium. Real logs either keep a change note per entry or accept that the audit trail lives in the weekly reports.
• Closed entries. Only four appear. By go-live this log would hold sixty or seventy closed entries, and they would still be visible - the closed set is what a lessons learned session actually reads.
• Links to other artefacts. I-01 in a real programme points at a defect number; D-02 points at a decision on the decision log; A-02 points at change request CR-014. Without those references the same fact ends up recorded in three places with three different dates.
• Workstream, cost and secondary owner. Larger programmes filter by workstream, record an estimated cost of the response, and name a deputy so the log does not stall when one person is on leave.
• The conversation. Nothing in the table shows that D-02 had been raised verbally for a fortnight before anyone wrote it down. The log records positions, not the effort of getting them.

If you want the same structure as a working file rather than a page, the RAID log template is one sheet with the scoring and dashboard already built, and the governance pack adds the dependency, stakeholder and action tabs that this example refers to but does not show.

Examples · All 36 templates