What goes in a RAID log, and who owns it?

• Risks. Things that might happen and would affect the project if they did. Example: a key supplier may not deliver on time.
• Assumptions. Things you're treating as true without having proved them. Example: the existing system can handle the extra volume.
• Issues. Things that have already happened and need action now. Example: the test environment isn't available.
• Dependencies. Things the project relies on from elsewhere, or that others rely on from the project. Example: go-live depends on another team's data migration.

Some organisations use the D for decisions instead of dependencies, or track both. What matters is that the team agrees which it is.

Keep the columns to the minimum people will actually keep up to date:

• For every entry: a reference number, a short description, the owner, the next action, the due date and the status.
• Risks: likelihood, impact, and the response (what you'll do to reduce it).
• Assumptions: how and by when it will be checked, and what happens if it turns out to be wrong.
• Issues: severity, and whether it needs escalating beyond the project.
• Dependencies: who it depends on, and the date it's needed by.

The usual reasons:

• Entries are owned by a team or "TBC" rather than a named person.
• The log is reviewed only when something has already gone wrong.
• Assumptions are never checked, so they quietly turn into issues.
• Closed items are deleted, so nobody can see what was learned.
• The plan and the log are kept in separate places, so they drift apart.

• The project manager owns the log and makes sure it's reviewed.
• Each entry has one named owner responsible for the next action.
• Anyone on the project can raise a new entry.
• The project board sees the top risks and issues and decides on anything outside the project manager's authority.
• The PMO sets the template and combines logs to show risks and issues across all projects.

• Review it at a fixed point every week or fortnight, as a standing item in the project meeting.
• Ask the same three questions of each open entry: is it still valid, has the owner acted, and has anything changed?
• Turn assumptions into risks or issues as soon as they prove doubtful.
• Close entries rather than deleting them, so there's a record.
• Keep the log in the same place as the plan, so a slipped date and its cause are seen together.