The Register That Described a Project That No Longer Existed

Building it was never the hard part.

There's a particular kind of quiet that happens when you open a document you own and don't recognize what's in it.

Mine was a risk register, six weeks into a payments migration, twenty minutes before steering. The top-rated item was a dependency the team had closed out back in week three — still sitting there at High, still marked Open. Further down, nothing at all about the client's compliance lead, who had resigned the previous Thursday and taken every approval relationship in the account with her.

The document wasn't wrong, exactly. It was accurate to a project that had stopped existing about five weeks earlier.

The part nobody budgets for

Nobody had touched it since. Not because we were lazy. Updating a risk register is the kind of task that never wins a fight for calendar space — important, never urgent, and it loses to whatever is on fire that morning. Every morning.

Here's the uncomfortable arithmetic: a register you built carefully and then froze isn't neutral. It's worse than nothing, because it looks authoritative. A steering committee reads twenty-two color-coded rows and concludes risk is handled. An empty template at least admits it doesn't know.

Registers die from three specific kinds of drift:

Stale risks. Resolved, mitigated, or overtaken — still sitting at High/High, hogging attention and quietly training everyone to trust the document less.

Missing risks. The project changed and the register didn't hear about it. This is the dangerous one. The risk that actually lands is almost never one you rated wrong. It's one you never wrote down.

Risks that already happened. A risk that has occurred isn't a risk anymore — it's an issue, and it needs a response plan, not a likelihood score.

Notice what those have in common: none of them require judgment to detect. They require comparing what the register says against what the project is actually doing this week. Detection is a diff. Judgment comes after.

The 15-minute version

Once a week, before the status meeting, I hand the model two things: the current register, and whatever honestly describes this week — the status report, standup notes, or five candid sentences typed from memory.

Then I ask for changes only. This is where most people go wrong. They paste the register and ask "is this still accurate?" The model, eager to help, rewrites everything, re-rates every row, and hands back a register you no longer recognize. Now you have to review all of it — the exact task you were avoiding.

The prompt that works asks for four lists and nothing else:

Compare the register against the status notes. Report ONLY the deltas:

1. STALE — register risks that appear resolved or overtaken.
   Cite the line in the notes that suggests it.
2. ESCALATED — risks that appear MORE likely or higher impact
   than currently rated. Cite your evidence.
3. OCCURRED — risks that have already happened and should be
   reclassified as issues with a response owner.
4. NEW — risks implied by the notes but absent from the register.
   Description, category, proposed likelihood and impact,
   one-line rationale.

Do not rewrite the register. Do not re-rate risks you have no
evidence about. If the notes don't mention something, say
"no signal" — do not infer.

Watch-for: the model will sometimes flag a risk as stale because the notes don't mention it. Silence is not resolution. That's what the "no signal" instruction is for, and you should still check it yourself. The risk nobody has mentioned in three weeks is occasionally the one quietly getting worse.

Then you rule on each delta. Accept, reject, or investigate. Five minutes, and it can't be delegated — accepting a register change is a decision, and decisions need someone whose name is on them. Anything you file under "investigate" becomes a question in that week's status meeting, which is why I run this right before it. The diff hands me my agenda.

Once a month, ask the harder question

The weekly diff catches drift. It doesn't catch blind spots — things missing from both the register and the notes because nobody writes them down anywhere. So once a month I add one question:

Based on everything you've seen about this project, what's one risk that appears in neither document — the kind of sponsor, political, or people risk nobody puts in writing but that could quietly sink the project?

The model has no career riding on staying quiet, which makes it strangely good at this.

The compliance-lead resignation I opened with? A pass like this one flagged "key-person dependency on client-side approvers" two projects later. That time I had a succession conversation before the departure instead of after. Same category of risk, very different Tuesday.

What actually changes

The register stops being a document you open before steering meetings and becomes the document the meeting runs from. Stale risks come off, so live ones get real attention. Escalations get caught early enough to act on.

None of that comes from better risk analysis. It comes from the register being current — a maintenance property, not an intelligence property. The AI didn't make me smarter about risk. It made the boring weekly comparison cheap enough that it actually happened.

If you'd rather not build the first one yourself: I've started taking a small number of these directly. You send me your project — a description or your charter, names and figures redacted — and in three business days you get back a populated register (15–25 risks scored and owner-assigned), a full RAID log, and a one-page "Top 5 to Watch." Details here.

Either way, run the weekly diff. The register only earns its place if it's true.

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