Why You're the Wrong Person to Write Your Own Risk Register

It isn't a skill problem. It's that you're in the document.

It isn't a skill problem. It's that you're in the document.

Ask any project manager, privately, what's most likely to go wrong on their project. They'll tell you in one sentence, immediately, with total confidence.

Then look at the register. That sentence isn't in it.

That gap is the whole subject of this piece. It gets diagnosed as a technique problem — run a pre-mortem, use a risk breakdown structure, interview more SMEs — and the techniques are fine. I use them. But they don't explain the pattern, because the pattern isn't ignorance. The PM already knows. The information exists. It just doesn't survive the trip onto the page.

What stops it is cost.

Every honest entry has a bill attached

Look at what the useful version of a risk actually sounds like.

The client has changed the priority order twice and there's no reason to think they've finished.

The vendor's integration team has missed both dates they've given us and we have no leverage.

Nobody on this team has built this kind of system before, including me.

The business lead who understands the current process leaves in March and has not been replaced.

Every one of those is a legitimate entry. Every one of them names a person, or names a decision somebody made, or admits something about the author.

Writing it down means someone reads it. Reading it means a conversation. The conversation lands on whoever wrote it.

So the entry gets softened. "Client keeps reversing decisions" becomes stakeholder alignment risk. "Nobody here has done this before" becomes technical complexity. The information survives in abstract form, which is the same as not surviving, because nobody has ever taken a mitigating action against stakeholder alignment risk.

That's not laziness and it isn't a competence gap. It's the predictable output of asking the most exposed person on the project to author the most exposing document.

The register is a political document before it's an analytical one

This is the part the templates never say.

A risk register has an audience. It goes to a steering committee. It gets read by the client, sometimes by the client's boss, occasionally by an auditor. Everyone writing one knows this, and writes accordingly.

Which means the document is doing two jobs at once. It's supposed to be an honest inventory of what could go wrong, and it's simultaneously a statement about how well the project is being run, authored by the person being assessed.

Those two jobs conflict. When they conflict, the second one wins, because the second one has consequences attached and the first one is a spreadsheet.

Notice what this predicts. It predicts registers will be most generic exactly where the project is most political — high visibility, senior client stakeholders, contested budget. Which matches what I've seen. The riskiest projects have the blandest registers.

Two things that reduce the problem

Neither of these solves it. They lower the cost of honesty a little, which is enough to get more onto the page.

Ask about the last project, not this one.

People tell the truth about finished work because nobody is accountable anymore. "What went wrong on the last build like this?" produces specifics that "what could go wrong here?" never will. Then test each one against your project. Most still apply, because most project failures are organizational, and the organization hasn't changed since.

Separate naming from owning.

A lot of the pressure comes from writing the risk and the owner in the same pass. The moment an entry has a name in the owner column it reads as an accusation, and you feel that while you're typing it. So don't. Get every risk named first — ugly, unscored, unassigned, in a document nobody else will see. Assign afterward. You'll write things in the first pass you would never write in a combined one.

The risk that belonged to nobody

A custom software build, a few years back. The client was a startup, first product in their field, VC-funded and on a comfortable budget. They'd run their own viability research in-house, and their product team wrote the PRD from it.

Before development started we ran our own pass over the competing products. It took days to see the PRD was thin. Some features in it had no equivalent anywhere and no obvious reason to exist. Things every serious competitor shipped were missing. We flagged both.

I should say where my read came from, because it wasn't clever analysis. Before that project I'd been product ops head and BA lead at two startups, and I'd watched this exact failure happen from the inside. A roadmap built on what the founders found exciting rather than on what buyers were asking for. I wasn't reasoning it out. I was recognizing it.

They were confident in the meetings. Founders in a new category usually are, and it isn't unreasonable — they'd done the research and we hadn't.

Here's what stayed with me. That risk never went into a register on either side.

Not ours. We were contracted to deliver software. Market penetration wasn't in scope, and a vendor logging we think the client's product strategy is wrong is writing a risk it has no standing to own and every commercial reason not to raise twice.

Not theirs either, because the honest version read our viability research may not support this product. Their own product team did that research. Whoever wrote that entry would be sitting next to the people it indicted.

So a real risk sat in the gap between two organizations, visible to both, owned by neither.

The part worth knowing is what happened next. Their own customers started asking for the features we'd said were missing — and asking for them ahead of the ambitious ones the PRD led with. The team surfaced other gaps of their own around the same time. They fixed it. By their own reckoning it cost somewhere in the range of six to eight months of projected onboarding and revenue. They were well funded, so it was expensive rather than fatal.

Nobody had to answer for it, though. There was no entry anywhere that had asked the question.

That's what an unwritten risk actually costs. Not the surprise — the surprise was survivable. What's missing is the moment where somebody has to say, on the record, whether they believe it or not. An entry in a register is a question with a name attached. No entry, no question, and nothing to be wrong about in public.

Where the ceiling is

I'd rather name the limit than pretend these techniques clear it.

Some risks you can't write. Not won't — can't.

If the honest entry is the client keeps reversing decisions, and the client approves your register, that entry doesn't survive contact with your own career. If it's the PM has never delivered this type of project, you're not going to write it about yourself, and nobody reasonable expects you to. If the risk implicates the person who decides your next assignment, no identification technique gets it onto the page, because identification was never the bottleneck.

The register that ships is the register you can afford to ship.

That's not a failure of process. It's a structural property of being inside the project — and it's the entire argument for having someone outside it write the first pass.

An outsider has no assignment to protect, no relationship with the client to manage, and no reason to soften the vendor has missed two dates into dependency risk. They can put the uncomfortable version on the page.

And there's a second thing, less about neutrality than about pattern. Someone who has sat in your seat on other projects has usually watched the failure you're heading toward already. That's most of what made the PRD obvious to me and invisible to them — not sharper thinking, just having been there before. Judgment is largely recognition, and recognition needs a sample size you can't get from one project. You then decide what stays, what gets softened, and what quietly comes out before the steering committee sees it.

But you're editing a real document instead of trying to author one against your own interests. That's a different starting position, and it's most of the value.

What an outsider can't do is make you act. The startup heard us and shipped the PRD as written, and they were entitled to — it was their product and their call. Naming a risk and owning it are separate jobs, and only one of them can be delegated.

What an outsider actually needs from you

The obvious objection: someone outside the project doesn't know your sponsor, your vendor, or who's leaving in March. Fair. The outsider isn't supplying knowledge. They're supplying permission to write it down.

Which means the handover is the whole job, and it's four questions:

Who has reversed a decision on this project, and how many times? Not "are there stakeholder alignment concerns." The count, and the person.

Which commitment from another team or vendor do you not actually believe? Everyone has one. It's rarely in a document.

What is this team building that it hasn't built before? Including you. Especially including you.

Who leaves, moves, or gets reassigned in the next six months? Departure dates are public facts that almost never reach the register.

You can answer all four in twenty minutes. None of the answers are hard to know. They're just hard to publish under your own name — which is the point.

The test worth running before your next review

Write the private version first. No owner column, no scoring, no audience. Just the sentences you'd say out loud if the project were finished and nothing could be held against you.

Then set it beside the register.

The difference between those two documents is your actual risk exposure. Everything else is process.

I put together a free pack of 16 AI prompts for PMs — including the elicitation and register prompts I use on live projects. No course, no upsell: mmohammad.gumroad.com/l/promptpack

And if the register you need is one you can't write from inside the project, I build them as a fixed-scope service — a full risk register and RAID log, written by someone with nothing to protect: mmohammad.gumroad.com/l/dfy-risk-register

Follow new pieces on Substack.