The project has a RAID log.
The rows exist.
The owners exist.
The colours exist.
The weekly update even says the log was reviewed.
And yet, the same risks show up every week.
Issues stay open longer than they should. Dependencies drift. Assumptions age quietly in the background.
Everyone can see the log, but nothing really moves.
That is the dangerous part.
A RAID log can make a project look controlled while the actual execution is getting softer.
The problem is not that the RAID log does not exist.
The problem is that it is not driving movement.
For project managers and delivery leads, sending updates to sponsors, steering committees, executives, or cross-functional stakeholders.
The Shift
The RAID log is not the control. The review cadence is.
This is where a lot of project teams get lazy without meaning to.
They treat captured items as managed items.
But a risk can have an owner and still be unmanaged.
An issue can have a status and still be stuck.
A dependency can be listed and still have no checkpoint.
An assumption can be documented and still drive the project off course.
A RAID log is only useful when it changes what happens next.
That means the value is not in the table.
The value is in the rhythm around the table:
Who reviews it?
What changed?
What needs a decision?
What should escalate?
What can close?
What needs a new owner, date, or next action?
Without that rhythm, the RAID log becomes delivery theater.
It looks responsible. It feels structured. It creates a record.
But it does not create control. Control comes from movement.
The System
Use this before your next project checkpoint, steering update, or stakeholder meeting.
The Active RAID Review Loop
1) Refresh
Update the log before the review, not during the meeting.
Remove stale items. Update statuses. Flag what changed since the last review.
If the first ten minutes of the meeting are spent asking, “Is this still relevant?” the review is already too late.
2) Filter
Do not review every row with the same energy.
Some items are just being watched. Others need action this week.
Pull out the items that need movement now:
active risks with rising probability
issues blocking delivery
dependencies with unclear timing
assumptions that are getting weaker
items sitting too long without a real next step
The goal is not to admire the whole log. The goal is to find what needs attention.
3) Assign
Every active item needs one clear owner.
Not “the team.”
Not “business and IT.”
Not “vendor / PMO / delivery.”
One owner.
If ownership is shared, accountability usually gets blurry.
You can have contributors. But the item still needs one person responsible for moving it forward.
4) Decide
Some RAID items are not really “monitoring” items.
They are hidden decisions. A risk may need a tradeoff.
An issue may need escalation. A dependency may need a stakeholder intervention.
An assumption may need validation before the team keeps building around it.
Do not let decision items hide behind polite status language.
Name the decision.
5) Close or move
Every reviewed item should do one of four things:
close
move forward
escalate
get a next checkpoint
If nothing changes after review, the review is probably theater.
A good RAID review should create a visible next move.
Not just a cleaner spreadsheet.
The Asset
The asset for this issue is the Active RAID Review Checklist.
It helps you check whether active RAID items have actual movement before a checkpoint, steering update, or stakeholder meeting.
Use it to ask:
Is this item still active?
Does it have one owner?
Is the next action clear?
Is the due date real?
Does this need escalation?
Is a decision needed?
Has this been sitting too long?
Should this be closed, moved, escalated, converted into a decision, or reframed?
The checklist is not meant to make your RAID log prettier.
It is meant to make the review harder to fake.
Because if an item has no owner, no next action, no timing, and no escalation logic, it is not being managed.
It is being stored.
You’ll find the checklist button in The Move below.
The AI Assist
One practical AI workflow here is:
Raw notes -> RAID review draft
A RAID review usually starts with messy inputs.
Meeting notes.
Vendor updates.
Stakeholder comments.
Side conversations.
A few “quick flags” that were never turned into real items.
AI can help create a first-pass RAID review draft from that mess.
Not to manage the project for you.
Not to decide what is risky.
But to surface weak signals faster:
unclear ownership
vague timing
missing next actions
hidden dependencies
items that may need escalation or a decision
Use this prompt after a project meeting, vendor update, or stakeholder check-in:
Act as a delivery PM.
Review the notes below and identify possible risks, issues, assumptions, and dependencies.
Return a table with:
- Type: Risk / Issue / Assumption / Dependency
- Item
- Weak signal found
- Why it matters
- Suggested owner
- Next action
- Escalation or decision needed
- Review timing
Do not invent facts.
If ownership, timing, impact, or escalation path is unclear, mark it as “needs clarification.”
Notes:
[paste notes]
Then review the output like a PM, not like a passenger.
Before adding anything to your RAID log, ask:
Is this item real?
Is the owner real?
Is the next action clear?
Is the timing credible?
Does this need a decision, escalation, checkpoint, or closure?
AI can draft the review. You own the judgment.
Quick caution: Do not paste confidential, client-sensitive, personal, or restricted information into AI tools unless your organization and client rules allow it.
The Move
Use the Active RAID Review Checklist to turn your RAID review into ownership, decisions, escalation, and next action.
What usually makes your RAID log go stale: no owner, no cadence, no escalation, or no decision?