The Column Nobody Fills

Every RAID log has four letters. Most only use three.

Risks get filled in. Issues get filled in, usually in a hurry, usually after something has already gone wrong. Dependencies get filled in because somebody else is chasing you for them.

Assumptions sit empty.

I've reviewed enough of these to notice the pattern holds almost everywhere, across teams and industries and delivery methods. The A is the column people skip, and it's the one that quietly decides whether the rest of the log was worth writing.

Here's why that happens, and what to do about it this week.

An assumption doesn't feel like work

A risk feels like analysis. You thought about the future, you identified something that might happen, you wrote it down. That's visible effort and it looks like the job.

An assumption feels like stating the obvious. We're assuming the client's data is in the format they described. Well — yes. Obviously. It seems too basic to record, and writing it down feels faintly insulting to everyone involved.

That's exactly why it doesn't get written. And it's why, four months later, when the data arrives in a format nobody planned for, there's no record of anyone having thought about it. The team didn't miss the risk. They never surfaced the belief underneath it.

Risks are things you know you don't know. Assumptions are things you don't know you've decided.

The three that cost the most

From what I've seen, assumptions cluster in three places, and the expensive ones are almost always here:

Availability. You've assumed a person will be there. The SME who explains the legacy process. The approver who signs off. The one developer who's touched that system. Nobody wrote down that the plan depends on them, so nobody noticed when their calendar changed.

Condition. You've assumed something exists in the state you were told. The data is clean. The API is documented. The existing process works the way the process document says it does. This one hurts most in migration and integration work, and it almost never surfaces in review. It surfaces the first time the thing gets used on the real project, about two weeks in.

Stability. You've assumed something won't change. The scope. The regulation. The priority order. The team. This is the one that reads as pessimistic when you write it, which is precisely why it stays unwritten.

The move: run the sentence backwards

Here's the practical part, and it takes about twenty minutes.

Take your plan — the schedule, the estimate, whatever you're committing to. Pick any three commitments in it. For each one, finish this sentence:

"This date only holds if ____."

Whatever fills that blank is an assumption. Write it in the A column. Then add one more thing next to it: who would know if it stopped being true, and how you'd find out.

That last part is what separates a useful assumptions log from a list of platitudes. An assumption with no detection method is just an opinion you've recorded. An assumption with a name and a check attached becomes an early warning.

Most teams find three or four per plan. Two of them will be things everybody knew and nobody had said out loud.

A prompt for the first pass

If you want AI to do the surfacing pass before you refine it by hand:

Tool: Claude, ChatGPT, or Gemini

Takes: Your project plan, schedule, or scope document

Output: A list of unstated assumptions the plan depends on, grouped by type

Prompt:

Below is a project plan. Do not summarize it or comment on its quality.

Instead, identify the unstated assumptions this plan depends on — the things that must be true for these dates and commitments to hold, but which are not written down anywhere in the document.

Group them under three headings: Availability (people the plan depends on), Condition (things assumed to exist in a particular state), and Stability (things assumed not to change).

For each assumption, write one sentence on how someone would find out it had stopped being true.

Be specific and concrete. Do not list generic project risks.

[paste plan]

Watch-for: It will generate plausible-sounding assumptions that aren't actually in your plan. Treat the output as a prompt for your own thinking, not a finished list. Delete anything you can't tie to a specific line in the document — and add the two or three it missed, which are usually the ones about people.

The one worth writing first

If you only add a single line to the A column this week, make it the one you'd feel slightly uncomfortable writing down.

That discomfort is a reliable signal. The assumptions that are safe to record are usually the ones that were never in danger.

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