The RAID log — Risks, Assumptions, Issues, and Dependencies — has 47 items.
Eleven have a named owner. Three have a decision-by date. None have a stated consequence if they stay open.
This is not unusual. This is the default state of most project governance. The log exists. It is updated weekly. It goes into the steering pack. And the same items appear in it, week after week, until one of them compounds into something expensive.
The RAID log is not a control mechanism. It is a list of future surprises, maintained with administrative precision.
The difference between a RAID item and a controlled decision is not the format. It is the consequence. Without a consequence, a deadline is a suggestion. Without a deadline, an owner is a label. Without an owner, an item is an intention.
“Every RAID item without a consequence is a problem you have agreed to have later.”
The assumption that makes the RAID log useless
The standard PMO belief: if we track every risk, assumption, issue, and dependency, we are in control.
Tracking is not control. Control is what changes what happens.
A RAID item that has been in the log for three weeks with the same owner and the same status is not being managed. It is being watched. And watching a problem accumulate is not the same as preventing it from compounding.
The items that eventually become programme-critical delays were visible weeks earlier. They were in the log. They had owners. They were reviewed in the weekly meeting. But because there was no mechanism to force them to a conclusion — no consequence for keeping them open — they drifted until the drift became expensive.
A log of open items is not a decision architecture. It is a waiting room for future problems.
What a decision log actually looks like
On a cross-border infrastructure programme in West Africa, the RAID log had thirty-two items at week four. Twenty-one had been there since kickoff. Nine had been escalated to the steering committee without resolution. Four of the nine would eventually become the source of claims.
The reset: every item was assigned a single named owner. Every item was given a decision-by date — not “soon” or “next sprint” but a calendar date. Every item was given a stated consequence: if not closed by the date, a specific action would be triggered automatically.
Within three weeks, twenty-seven of the thirty-two items had closed. Not because the problems disappeared. Because the consequence of keeping them open was now more uncomfortable than making the decision.
Nothing changed in the complexity of the programme. Only the architecture changed.
Decision cycle on open items: from an average of 19 days to under 5 days.
Items escalated to steering committee: dropped from 9 to 1 in the following month.
Claims filed in the following six months: zero related to items that had been in the original log.
The decision log architecture — three requirements per item
Not a team. Not a function. One person accountable for bringing the item to a decision. The log item stays with one person until it closes.
Not “urgent” or “next meeting.” A date. Set when the item is opened. An item that has had its date moved three times is an item whose owner needs support, not more time.
If the item is not decided by the date, something specific happens. Not a general escalation. A named consequence agreed when the item is opened. Both sides know it. It does not need to be triggered. It needs to exist.
These three requirements transform the RAID log from a tracking tool into a decision architecture.
The objections I hear before every decision log reset
“We escalate when things get serious.”
By the time something is serious enough to escalate, the cheap recovery window has closed. Escalation is a stage four response to a stage two problem. The consequence architecture catches it at stage two.
“We cannot set consequences without agreement from the other side.”
Many consequences do not require the other side’s agreement. A timeline revision, an internal escalation, a commercial notice — these are unilateral actions within your own governance structure.
“Our items are too complex to close on a fixed date.”
Then break them into component decisions that can close on fixed dates. A complex item is almost always a collection of simpler decisions held together because nobody has decomposed them.
The first three of five
Article 9 introduced CONTAIN: the scope document that defines what is being delivered. The scope defines the boundary.
Article 6 introduced COMMAND: the one operating plan that defines what is real. The operating plan defines the truth.
This article introduces CLOSE: the decision architecture that prevents open items from compounding into delays. The architecture closes it.
“The RAID log that has items from kickoff is not evidence of a complex project. It is evidence that the decision architecture is missing.”