Run a pre-mortem on the plan before you start

Most risk registers get written at the start of a project, when everyone's hopeful and nobody wants to say the plan might not work. A pre-mortem asks the awkward question differently: it's six months from now, the project has failed, so what happened?

People are bad at this in a meeting, because nobody wants to be the one who says it. A chat window doesn't mind.

Here's a project plan. Assume it's six months after the planned finish
and the project has failed badly.
Write the post-mortem as if it already happened. Give me the ten most
likely reasons it failed, ordered by how likely you think they are.
For each one:
- what went wrong, in a sentence
- the early warning sign we'd have seen in the first month
- one cheap thing we could do now to stop it
Include at least three that are about people, communication or timing,
not technology. Be specific to this plan, not generic project advice.

Plan: [PASTE: GOAL, TEAM, DATES, DEPENDENCIES, BUDGET]

Ask for the early warning sign, because a risk with no sign you can watch for is only a worry. The ones about people are where this earns its keep. "The two teams who need to agree never met" doesn't show up on a Gantt chart.

The more real detail you give it about who's involved and what's already shaky, the sharper the answer. If the plan's vague, so will the failures be.

Take the list to the team and ask which ones they'd add. Then pick three to act on and give each an owner. A list of ten that nobody owns doesn't change anything. For the smaller version of this whole process, there's a lightweight project guide.