The Risk Nobody Wrote Down

RAID has four letters and most risk registers run on two. A 15-minute assumption audit.

We had signed contracts with every partner. Two hundred of them at launch, and every single one had a countersigned agreement on file — company policy, no exceptions. The delivery plan recorded that as secured revenue, and nobody argued with it, because what is there to argue with? The contracts existed. I'd read them.

Written by me, drafted with AI assistance. The project, the numbers and the mistake are mine.

What the plan didn't record was the sentence underneath the number: that a signed contract means the fee gets paid. Nobody wrote that down, because at the time it wasn't an assumption. It was just how contracts work.

Most of them honored the customer-facing side of the agreement and declined the fee. Revenue came in around sixty percent under plan. It took me four months to build a mechanism that recovered any of it, and the launch-year number never came back.

The risk register had thirty-odd entries. Vendor delivery, integration timelines, seasonal demand, the usual. Not one of them was about partners refusing to pay, because refusal wasn't a risk anyone had identified. It was an assumption nobody had questioned, sitting one layer beneath a risk register that looked complete.

Assumptions are just risks you haven't noticed yet

RAID stands for Risks, Assumptions, Issues, Dependencies. In practice most logs run on two of those. Risks get columns, owners, probability scores and a review cadence. Issues get escalated because they're already hurting. Dependencies sit half-empty, which I've written about before. Assumptions get nothing at all — no owner, no trigger, no review date, frequently no row.

That's backwards, and the reason is structural rather than lazy. A risk is a statement about something that might go wrong, so it arrives already framed as a threat and the register knows what to do with it. An assumption is a statement about the world that everyone in the room believes is true. It doesn't feel like a threat. It feels like context. So it goes into the narrative section of the plan, into a slide, into a conversation, and never into a row with an owner's name against it.

Then one of them turns out to be false, and it doesn't announce itself. There's no trigger event, because nobody defined a trigger. There's no owner watching it, because nobody was assigned. You find out weeks later, through a number that came in wrong, and by then the assumption has already been load-bearing for a month.

Every unlogged assumption is a risk with no probability, no impact score, no mitigation and no owner. You just don't get to call it one until after it breaks.

The audit

This takes about fifteen minutes and you run it against documents you already have — the delivery plan, the BRD, the business case, the runbook. It works the same way in requirements as it does in delivery, because the failure mode is identical: a statement about the future that nobody in the room controls, recorded as though it were a fact.

The point isn't to produce a longer list. It's to find the two or three statements that are actually holding up the plan, and get them into the register before they become issues.

Tool: Claude or ChatGPT

Takes: ~5 minutes, plus 10 for the human pass

Output: A table of unstated assumptions, each with what happens if it's false

Prompt:

>

>

>

>

>

>

You are a senior risk analyst reviewing a project document before approval. Your job is not to summarize it.

Read the document below and extract every assumption — any statement about the future, or about the behavior of a person, team, vendor or system outside the project's direct control, that is written as though it were established fact.

Include assumptions that are implied rather than stated. If the document says "onboarding begins in March," the implied assumption is that the prerequisite work finishes in February. Surface both.

Present as a table: | Assumption (as implied by the document) | Where it appears | Who or what it depends on | What breaks first if it's false | How we would find out |

The last column is the most important one. For each assumption, state the specific signal that would tell us it's false, and roughly when that signal would be visible.

Then list the three assumptions that, if wrong, would do the most damage to the plan. Explain the reasoning for each in two sentences.

Document: [PASTE]

Watch for: The model will pad the list with harmless assumptions to look thorough — "assumes the team has access to the required tools," that sort of thing. Ignore the volume and go straight to the last two columns. An assumption with no detection signal and no clear failure mode isn't worth a row. An assumption where the honest answer to "how would we find out" is "when the quarter closes" is the one to worry about, and it's usually the one nobody wanted to raise.

What to do with the output

Three things, and the third is the one people skip.

Promote the top two or three into the risk register as actual risks, with a probability and an impact score. "Partners will pay the monthly fee" becomes "Partners honour the customer-facing terms but decline the fee — H/H." It reads uncomfortably in a document you're about to circulate. That discomfort is the whole value.

Give each one a named owner. Not a team, a person. The owner's job isn't to prevent the assumption from being false. It's to be the person who notices first.

Then set the review date against the detection signal, not against your reporting cycle. If the signal is visible in week three, the review is in week three. Reviewing it at the monthly checkpoint means finding out about a week-three problem in week five, which is roughly how I ended up with four months of recovery work.

If you'd rather not build it from scratch

Risk Register + RAID Log Pack — $14.99. The register this workflow feeds into. Assumptions column with detection signals, owner and review-date fields, and the scoring formulas already wired. Excel and Google Sheets, works in both. → Get the pack

Done-For-You Risk Register — $150. Four diagnostic questions, and I build it against your actual project. Delivered as a working file inside three business days. For when the fifteen minutes isn't the problem — not having anyone to spend them is. → See the service

The uncomfortable part

Running this audit properly means writing down, in a document other people will read, that you're not certain about something you've been presenting as settled. That's the actual barrier. It isn't the fifteen minutes.

I've never once run this and found nothing. The lowest count was four. The highest was somewhere past a dozen, on a plan I'd have described that morning as watertight.

The contracts were real. I'd read them. What I hadn't done was write down the part I was taking on faith.

This piece went out first to newsletter subscribers. Subscribe on Substack to get them as they publish.