Project Pre-Mortem

When to use it

A project is about to start, or has just started, and the user wants to find the ways it fails before they happen. They describe the project (goal, team, timeline, budget, dependencies, who wants it and who does not) and get a one-page pre-mortem: ten causes of failure written as if they already happened, ranked, each with the signal that would show it coming and the one action that makes it less likely.

Also for a project that is already in trouble: the same method, with "six months on" replaced by "at the deadline", finds what is most likely to finish it off.

Not for: a risk register in the formal sense (a pre-mortem feeds one), status reporting (the Project Status Reporter pack does that), or a plan the user has not written yet. The pre-mortem needs a plan to attack.

What it asks you

Ask in one message, numbered. Work from what comes back.

1. What is the project, in three lines: what will exist at the end that does not exist now, and for whom?
2. What does success look like on the final day, in terms someone could check: a number, a date, a thing shipped, a decision made?
3. Who is on it, how much of their time, and who is the sponsor who can remove a blocker?
4. Timeline and budget, and which of the two is fixed.
5. What does the project depend on that the team does not control: another team, a supplier, a sign-off, a system, a hire, a regulator?
6. Who wants this to happen, and who would quietly prefer it did not? What happens to each of them if it succeeds?
7. What has gone wrong on similar projects here before, if you know?
8. What is the one thing you are most worried about, and what are you not worried about at all?

A vague answer to 2 gets one follow-up: "On the last day, what would make the sponsor say it worked?" If success is still not checkable, the first cause on the list is "nobody could agree whether it had succeeded", and the skill says so.

Never invent a team member, a dependency, a past failure or a date. Causes are built from what the user gave and from well-established ways projects fail, and the skill says which is which.

What comes back

Plain text.

PRE-MORTEM: project name, date It is six months on. (The failure sentence.) The three causes that carry most of the score: ...

THE TEN Rank. Headline (past tense). Likelihood L x Damage D = score. Source. Signal to watch by date. Action (who; lowers likelihood or damage). Marked "seen here before" or "general pattern" where it applies. (ten rows)

Your worry: where it landed and why. Your non-worry: whether it appears, and which rank. Check the signals on: date. Next: one line naming the single most useful next step.

For a project already in trouble: the same, with "at the deadline" in place of "six months on" and the signals set two weeks out.

• 00_START_HERE.pdf: the two-minute set-up for each AI.
• 1 - Skill: project-pre-mortem.zip, one upload to Claude, ChatGPT, Gemini, Grok or Microsoft 365 Copilot. It switches on by itself when this job comes up.
• 2 - Text file for any AI: the same Move as one .txt. Attach it to any chat, on any plan, and type "Follow this file".

It drafts, you read and send. It never contacts anyone for you and never invents a fact, a number or proof.

A Move is a single play. The whole function in a box is Project Status Reporter, an agent pack with up to 8 skills.