Why RAID logs fail in real IT projects

RAID logs are supposed to be the backbone of delivery control

In theory, a RAID log — tracking Risks, Assumptions, Issues, and Dependencies — is the structured mechanism that keeps a project's problems visible, owned, and managed. In practice, most RAID logs in complex IT projects are out of date, inconsistently maintained, and actively avoided by the people who should be using them most.

This is not a personal failing. RAID logs fail for structural reasons that repeat across organisations, sectors, and project types. Understanding those reasons is the first step to fixing them.

Reason 1: Ownership is unclear

The most common reason a RAID log stops being useful is that individual entries have no clear owner. A risk is identified in a meeting, added to the log by the PM, and then never updated because nobody accepted responsibility for it.

Effective RAID management requires that every entry has a named individual — not a team, not a workstream, not a supplier — who is accountable for monitoring, updating, and escalating that item. When ownership is diffuse, nothing happens.

Reason 2: Updates happen too infrequently

RAID logs that are reviewed monthly in fast-moving delivery environments become historical documents, not control tools. By the time a risk is updated, it may already have materialised as an issue. By the time an issue is updated, it may already be causing slippage.

The update cadence needs to match the pace of the delivery environment. In high-tempo delivery, weekly RAID review is the minimum. In complex multi-workstream programmes, some categories of risk may need more frequent attention.

Reason 3: The log is too long and too generic

RAID logs grow. Every risk that was ever identified gets added. Closed issues stay in the log. Assumptions that were validated months ago remain listed as open. The result is a log with hundreds of entries, most of which are irrelevant to current delivery.

A useful RAID log is actively curated. Closed items are archived, not left open. The active log should reflect current delivery risk — concise enough that stakeholders will read it, structured enough that escalations are obvious.

Reason 4: The log is disconnected from governance

A RAID log that exists in isolation from governance meetings is a filing exercise, not a control mechanism. RAID outputs need to feed directly into governance meetings — status reviews, risk forums, steering groups — and the log needs to be updated based on decisions made in those meetings.

When RAID and governance are disconnected, risks are discussed in meetings but not captured, actions are agreed but not tracked, and decisions are made but not logged. The governance cadence and the RAID discipline need to be designed together.

Reason 5: Escalation paths are not defined

Even when a RAID log is well-maintained and owned, it fails if there is no clear escalation path. A risk identified at workstream level needs a route to programme-level visibility if it crosses a defined threshold. An issue that the delivery team cannot resolve needs a route to the sponsor or steering group.

Without defined escalation paths, risks and issues sit in the log until they become crises. Effective RAID management defines — in advance — what triggers escalation, who receives it, and what the expected response is.

What functional delivery control looks like

A RAID log that actually works is short, owned, current, and connected to governance. It is not a comprehensive record of every problem ever discussed — it is a live view of the risks and issues that currently require attention. Owners update their entries before governance meetings, not after. Escalations happen through defined channels, not through informal corridor conversations.

The measure of a healthy RAID log is not its length or its age. It is whether it would still be the first document a senior stakeholder would trust to show them where the delivery really stands.