RAID Logs, Registers, and Rituals​

​​

At some point, every project creates a RAID log.

Risks.
Assumptions.
Issues.
Dependencies.

 

Everything is captured.
Everything is tracked.
Everything has an owner.

 

And somehow, the same problems still resurface — unchanged.

This field guide is about RAID logs as they actually function — not as control systems, but as organizational rituals that absorb uncertainty without resolving it.

​

What RAID Logs Are Supposed to Do

 

In theory, RAID logs exist to:

• Centralize uncertainty

• Clarify ownership

• Surface interdependencies

• Enable proactive action

 

They promise visibility, coordination, and discipline.

When used well, they can help teams see patterns early and respond deliberately.

But that’s not how they’re usually used.

​

How RAID Logs Actually Emerge

 

RAID logs rarely appear at the start of projects.

They emerge when:

• Complexity increases

• Issues multiply

• Leadership asks for “more control”

 

The log becomes a container — a place to put everything that feels unresolved.

It feels responsible.
It looks comprehensive.
It reassures stakeholders.

​

The Expansion Problem

 

RAID logs grow relentlessly.

Risks become issues.
Issues become assumptions.
Dependencies spawn more dependencies.

 

The log expands because:

• Nothing is ever truly closed

• Resolution depends on people not present

• Escalation feels riskier than tracking

 

The log survives.
The problems persist.

​

Ownership Without Consequence

 

Every RAID item has an owner.

Few owners experience:

• Consequences for inaction

• Authority to resolve dependencies

• Incentives aligned with closure

 

Ownership becomes nominal.

The item remains “open” —
but tolerated.

Closure becomes symbolic rather than real.

​

RAID Reviews as Performance

 

RAID reviews often become performative.

They:

• Demonstrate diligence

• Signal awareness

• Avoid disruption

 

Updates sound familiar:

• “No change”

• “Monitoring closely”

• “Working through dependencies”

 

The ritual is completed.
The risk remains.

​

When Documentation Replaces Decision

 

RAID logs often substitute for decision-making.

Instead of:

• Choosing a direction

• Accepting tradeoffs

• Escalating conflict

 

Projects:

• Log uncertainty

• Track discomfort

• Defer commitment

 

The log becomes a holding area for decisions no one wants to make.

​

Why RAID Feels Necessary (Even When It Fails)

 

RAID logs persist because they solve a different problem.

They:

• Create the appearance of control

• Protect individuals from blame

• Prove that issues were “known”

 

In environments where accountability is diffuse, documentation becomes armor.

The project doesn’t get safer —
but people do.

​

What RAID Logs Actually Reveal

 

RAID logs are diagnostic tools — just not in the way intended.

They reveal:

• Where authority is missing

• Which dependencies never resolve

• Which risks are politically untouchable

 

The pattern matters more than the entries.

​

How Experienced PMs Use RAID Logs Differently

 

Experienced PMs don’t try to perfect RAID logs.

They use them to:

• Identify stalled ownership

• Trigger escalation conversations

• Make decision gaps visible

 

They know the log won’t fix the project —
but it can expose why it’s stuck.

​

Ritual Without Resolution Is Just Record-Keeping

 

RAID logs don’t fail because they’re poorly maintained.

They fail because:

• Decisions are deferred

• Authority is unclear

• Escalation is unsafe

 

Documentation records reality.
It does not change it.

Only decisions do.

​

“RAID logs struggle most when decision-making is delayed or avoided.”

Link “decision-making is delayed or avoided” to:
➡ Decision-Making Failures in Projects

➡ Risk Registers and the Illusion of Control
 

​