Most RAID logs die in a spreadsheet nobody opens after kickoff. By the time a risk becomes an issue, the log was already weeks out of date.
You build the RAID log on day one — all four tabs, color-coded, owner column filled in. Then the project starts. By week six the file lives in a folder nobody opens, the last edit is dated before the work began, and the risk that just blew up your timeline has been sitting in row 14 the whole time, status “Open,” owner blank.
That is the real failure of RAID in project management. The framework is sound; the discipline is what breaks. And the cost is measurable: on-time delivery across professional services fell to 73.4% in 2024, down from 80.2% in 2021, according to the 2025 SPI Professional Services Maturity Benchmark. Only 10% of organizations deliver more than 90% of projects on time. Risks surfaced too late are a large part of that gap.
What does RAID stand for in project management?
RAID in project management stands for Risks, Assumptions, Issues, and Dependencies — the four categories a project manager tracks to stay ahead of what could derail a project. A RAID log is the single running record that holds all four, reviewed on a cadence so threats surface as early warning instead of post-mortem. The four are easy to confuse, and confusing them is how things slip through: a risk is potential, an issue is already happening, an assumption is unverified, and a dependency is an external blocker outside your direct control.
| Term | What it is | The test | Example |
|---|---|---|---|
| R Risk | A potential future event that could affect the project, good or bad. It has not happened yet. | It might happen. | A key developer may be pulled onto another account next month. |
| A Assumption | Something you are treating as true to plan the work, but have not verified. | We believe it, unconfirmed. | The client will provide test data by the date in the plan. |
| I Issue | A problem that is already happening and needs action now. | It is happening. | The test data never arrived; the build is blocked today. |
| D Dependency | An external item the project relies on, owned by another party or team. | We wait on someone else. | Go-live depends on the client’s security team signing off. |
Notice how the rows connect. An unverified assumption (“test data arrives on time”) is really a dependency on the client. Leave it unconfirmed and it becomes a risk; leave the risk unmitigated and it becomes an issue that stops work. A good RAID log catches the chain at the assumption, not at the issue.
What is the difference between a risk and an issue?
A risk is a potential problem that has not happened yet, so you plan a response and monitor it; an issue is a problem already happening that needs action today. The rule on a RAID log: if it might happen, log it as a risk; if it is happening, log it as an issue. Most issues are simply risks nobody mitigated in time.
What goes in a RAID log template?
A RAID log template has four sections — Risks, Assumptions, Issues, Dependencies — and a consistent set of fields per entry. At minimum, every row needs an ID, a description, an owner, the date raised, a status, and a next step. The four categories then add their own fields:
- Risks — probability, impact, and a mitigation plan (what you will do to lower the odds or the damage).
- Assumptions — who needs to confirm it, by when, and what breaks if it turns out false.
- Issues — severity, the action being taken now, and the target resolution date.
- Dependencies — the responsible party, the date you need the item by, and the impact if it is late.
The template is the easy part. A RAID log you can download in ninety seconds does nothing if the entries are written once and never touched again. The fields are scaffolding for a habit, not a substitute for one.
How do you run a RAID log through a project?
You run a RAID log by reviewing it on a fixed cadence and updating status before every status meeting — not by filling it in at kickoff and hoping. The log is a living document or a dead one; there is no middle state. A workable rhythm:
- Kickoff: seed the log. Capture every assumption the plan rests on and every external dependency before a single task starts.
- Weekly: walk the open risks and issues in the team status meeting. Convert risks that have materialized into issues. Close what is resolved. Reassign anything with a blank owner.
- At each milestone or stage gate: re-test the assumptions. The ones that were true at kickoff are often false by phase two.
- Always: tie each entry to the work it threatens. A risk floating free of a task is a risk nobody acts on.
That last point is where most spreadsheet RAID logs fail. The risk lives in one file, the schedule in another, and the person who could act on the risk never sees it next to the task it endangers.
A RAID log that lives apart from the plan is a record of what went wrong. A RAID log inside the plan is a warning before it does.
How does Klient PSA keep RAID current inside Salesforce?
Klient PSA tracks risks, issues, and dependencies against real tasks and milestones inside Salesforce, so a RAID entry is attached to the work it threatens instead of stranded in a separate file. Because Klient PSA is 100% Salesforce-native, the RAID log shares the same database and records as the project plan — no export, no second tool, no stale copy. When a dependency slips, the milestone it blocks is right there on the same record.
That solves the storage problem. Keeping the log current is where the AI agents come in. Klient PSA includes nine AI agents and one MCP, powered by Salesforce Agentforce, and two of them work directly on RAID. Humans decide; the agents surface and draft.
PLANNY1 surfaces the risk before it bites. A read-only project monitor, PLANNY1 reads live Salesforce tasks, milestones, and status, then sends a brief flagging what is slipping — the overdue dependency, the milestone at risk — so the risk reaches the project manager before it converts into an issue. It writes nothing; you decide what goes on the RAID log.
SCOPEY1 captures assumptions and constraints at the source. SCOPEY1 takes a plain-language request and writes a structured scope — including Edge Cases and Constraints — then creates a Klient PSA task held for human approval. Those sections are where assumptions and dependencies get named up front, before they quietly become risks.
The pattern is the one that defines Klient PSA: humans lead, agents deliver, and each agent stops at a human approval gate. They close the gap between “the risk was in the data” and “someone saw it in time” — they do not make the call.
Down from 80.2% in 2021, with only 10% of organizations delivering more than 90% of projects on time. Source: 2025 SPI Professional Services Maturity Benchmark. Late-surfaced risk is a core driver of the decline.
Why does a RAID log matter more for services firms?
For a services firm, every slipped project is margin and a client relationship at the same time, which is why a current RAID log matters more here than almost anywhere else. The firms at the bottom of that on-time range are not lacking a framework — they are lacking the discipline to keep it live. Klient PSA puts the RAID log where the work already lives, in Salesforce, and uses PLANNY1 and SCOPEY1 to keep it current. It goes live in about three weeks at $39/user/month, so the habit starts within the quarter.
RAID is not a new idea. Projects still slip not because teams have never heard of risks and dependencies, but because the log goes stale the moment the work gets busy. Fix where it lives and who keeps it current, and the framework finally does its job. For the bigger picture, see our guide to professional services automation, or how Klient PSA tracks the whole project on Salesforce.
RAID in project management — frequently asked questions
What does RAID stand for in project management?
RAID in project management stands for Risks, Assumptions, Issues, and Dependencies — the four categories a project manager tracks to stay ahead of what could derail a project. A risk is potential, an issue is already happening, an assumption is unverified, and a dependency is an external blocker outside your direct control.
What is a RAID log?
A RAID log is the single running record that holds all four RAID categories — Risks, Assumptions, Issues, Dependencies — with an ID, description, owner, date raised, status, and next step per entry. Reviewed on a fixed cadence, it surfaces threats as early warning instead of a post-mortem record. A log opened only at kickoff stops reflecting reality within weeks.
What is the difference between a risk and an issue?
A risk is a potential problem that has not happened yet, so you plan a response and monitor it; an issue is a problem already happening that needs action today. The rule on a RAID log: if it might happen, log it as a risk; if it is happening, log it as an issue. Most issues are simply risks nobody mitigated in time.
See your RAID log live inside Salesforce
Watch how Klient PSA ties risks, issues, and dependencies to real tasks — and how PLANNY1 surfaces them before they bite.