RAID Log

Origin & evolution

The RAID log has no single inventor. It grew out of standard project and programme management practice, where experienced managers had long kept separate registers for risks and issues and found them easier to maintain as one combined document. The acronym RAID became common in the programme management community through the 1990s and 2000s, appearing in training materials, PMO templates, and large-scale delivery frameworks without being associated with any single methodology or originator.

Variants🆎VariantGrowthA variant in an A/B testView reference → exist. Some organisations use RAAIDD (Risks, Actions, Assumptions, Issues, Decisions⚖️DecisionStrategyA recorded decision with context, rationale, and consequencesView reference →, Dependencies) or RAIDO (adding Opportunities🚪OpportunityDiscoveryA validated gap worth solvingView reference →). Some invert the D to stand for Decisions, not Dependencies, which is more common in agile contexts. The base RAID formulation nonetheless remains the most widely recognised, and most organisations begin with it before extending the register to fit their own delivery context.

How it works in practice

Each letter corresponds to a register tab or section:

• Risks are potential future events that could negatively affect the project. Each risk gets an owner, a likelihood rating, an impact rating, and a mitigation action. A risk that has not yet materialised lives here.
• Assumptions are things the team is treating as true without formal confirmation. They represent hidden dependencies on information not yet verified. Common assumptions include budget availability, third-party system readiness, and regulatory timelines.
• Issues are problems that have already occurred and require active management. A risk that materialised becomes an issue. Issues get an owner, a priority, and a resolution path.
• Dependencies are deliverables, decisions, or actions that the project relies on from outside its own boundary: another team, a vendor, a regulatory body, or another workstream.

A concrete example. A programme delivering a data-platform migration to a cloud provider logs the following. Under Risks: the lead data engineer has flagged a possible six-week delay in the vendor's managed-service availability; the project manager assigns it a high likelihood and high impact, and records a mitigation to identify a fallback provider. Under Assumptions: the team has assumed that the existing data-governance policy covers the new environment; the assumption owner will confirm this with legal by the end of the month. Under Issues: a schema inconsistency discovered in the legacy database is blocking the first migration wave; the engineering lead owns resolution by a named date. Under Dependencies: the security team must approve the network-peering configuration before build-out can proceed; the project manager is tracking this as a dependency with a due date and a named contact.

The log is most useful when it is reviewed in a standing meeting, not left in a shared folder. Stale entries undermine confidence in the whole register.

When to use it (and when not)

A RAID log is most valuable on projects with multiple workstreams, external dependencies, or a delivery timeline long enough for circumstances to change. Large programmes, product launches, platform migrations, and regulated-industry releases🚢ReleaseProduct SpecificationA shipped version of the productView reference → all benefit from the discipline of a maintained register.

It earns its keep less well on short-cycle product work where the team is small enough to hold risks in a daily standup without needing a formal log. The common failure mode is creating a RAID log at kick-off and then treating it as a static artefact and never updating it. When entries are never closed, never escalated, and never actioned, the log becomes a record of anxiety with no feedback loop to delivery. The other recurring problem is category confusion: teams often log an assumption as a risk and a dependency as an issue. Spending ten minutes in the first session agreeing definitions by example prevents most of this drift.

In the Unified Product Graph

The RAID log is a table framework in the programme management category. Its four sections map onto distinct entity types in the Unified Product Graph:

• The Risk register🧯Risk RegisterProgram ManagementA register of project risksView reference → corresponds to a risk_register🧯Risk RegisterProgram ManagementA register of project risksView reference → entity, the structured record of identified risks, owners, ratings, and mitigations.
• Dependencies become dependency⛓️DependencyTeam & OrganisationA cross-team or system dependencyView reference → entities, each representing a specific reliance on an external deliverable, decision, or action.
• Issues in active resolution map to a status_report📄Status ReportProgram ManagementA project status reportView reference → entity, surfacing current blockers and their resolution state.
• Deliverables that the project must produce or consume in order to resolve a dependency become deliverable🎀DeliverableProgram ManagementA deliverable from a projectView reference → entities, trackable artefacts with owners and due dates.

Modelling the RAID log this way means a dependency⛓️DependencyTeam & OrganisationA cross-team or system dependencyView reference → node can be linked directly to the feature⭐FeatureProduct SpecificationA product capability or featureView reference → or epic📜EpicProduct SpecificationA large body of work that can be broken into storiesView reference → it is blocking, and a risk_register🧯Risk RegisterProgram ManagementA register of project risksView reference → node can connect to the team or workstream that owns it, making the register a live part of the product graph with every entry owned and traceable to the work it affects.