Home About Experience Projects Case studies Resources Articles Briefs Playbook Tools FAQ How we start Security Get in touch

All tools › RAID log

Saved in this browser only

The tool · project delivery

RAID log

Project
Project manager
Last reviewed
1

Risks

might happen, would hurt
IDRisk and its impact if it landsLikelihoodPriorityOwnerStatus
2

Assumptions

things treated as true that nobody verified
IDAssumption and what breaks if it is wrongOwner to verifyStatus
3

Issues

already happening, needs action now
IDIssue and its impactPriorityOwnerStatus
4

Dependencies

what we wait on, and who waits on us
IDDependencyDirectionOwnerNeeded by

How to keep a RAID log alive

Write risks as cause and effect. "Timeline risk" is a mood; "client approval could slip two weeks, delaying launch" is a risk.

Review it weekly, in the open. A RAID log updated the night before a steering meeting is a prop, not a control.

Issues are not risks that grew up. When a risk lands, close it and open an issue with an action.

IDs matter. R-003 in a status report is unambiguous; "the vendor thing" is not.

This is the working document of a running project. If someone asks how the project is going and the honest answer lives in your head, it belongs on this page instead.

Everything saves in this browser only. Some teams use the D for Decisions; this sheet uses Dependencies and pairs with the separate decision log tool.

Prefer paper? Download the blank sheet as a PDF. The thinking behind it, and the nine tools it works with, is in The Project.

General guidance from practice, not legal, HR, or financial advice. Everything you type stays in this browser and is never sent to a server.