Charlotte Bennett

Run a Pre-Mortem on a Project Before It Starts

Imagine the project has already failed and work backwards: specific causes scored by risk, early-warning signs and cheap prevention steps.

At a glance

Best for: Project leads and small-business owners about to start a migration, launch or rollout who want to find the likely failure points first.
Tested on: Claude · Opus 5.5
You fill in: review_dateprojectteamsuccess
You get: Failure story (28 February 2027) The Xero migration started in late October, not September, because the contractor's three days were used up on… (full result below)

Prompt

Run a pre-mortem on this project. Imagine it is {{review_date}} and the project has clearly failed. Work backwards from that failure.

Project: {{project}}
Team and resources: {{team}}
What success was supposed to look like: {{success}}

1. Write the failure story in 5-6 sentences, as if from the post-mortem: what went wrong and in what order.

1. List 8 distinct causes of failure across people, scope, technical, suppliers, customers and assumptions. Be specific to this project; "poor communication" is not allowed.

1. Score each cause for likelihood (1-5) and impact (1-5), and sort by the product.

1. For the top 4: an early-warning signal we'd see in the first 3 weeks, and a prevention step that costs less than a day's work.

1. One thing we should drop or de-scope now to make the rest more likely to succeed.

Tone: frank, like a colleague who has seen this go wrong before. Mark anything you're speculating about with (?).

Fill in

{{review_date}}: A date after the project should have finishede.g. 28 February 2027
{{project}}: What the project is and its deadlinee.g. Move a 9-person accounting firm from Sage and network drives to Xero and SharePoint
{{team}}: Who is working on it, how much time they have, and the budgete.g. Office manager 1 day/week, IT contractor 3 days, £6,000
{{success}}: What success was meant to look likee.g. All 140 clients on Xero, files in SharePoint, no missed filing deadlines

Example input

review_date: 28 February 2027
project: Move our 9-person accounting firm from on-premise Sage and shared network drives to Xero and SharePoint, and start using an AI assistant for drafting client emails, all before the January self-assessment peak.
team: Office manager (project lead, 1 day a week), 2 partners, 6 staff; external IT contractor for 3 days in total; budget £6,000.
success: All client files in SharePoint with the right permissions, all 140 bookkeeping clients on Xero, staff using the AI assistant for first drafts, no missed filing deadlines.

1.5k0

Generated Outputs (1)

3 hours ago

Claude

Opus 5.5

3 hours ago

Generated Output

Failure story (28 February 2027)
The Xero migration started in late October, not September, because the contractor's three days were used up on SharePoint permissions. By December only 60 of 140 clients had moved, so the firm ran Sage and Xero side by side through January. Staff didn't know which system held the latest figures, and two clients' VAT figures were entered in both. With self-assessment work at its peak, nobody had time to learn the AI assistant, and a partner banned it after it drafted an email quoting the wrong tax year. One return was filed late. The migration finished in April, over budget.

Causes, sorted by likelihood x impact

| # | Cause | L | I | Score |
|---|---|---|---|---|
| 1 | The migration runs into the January peak and two systems run in parallel | 4 | 5 | 20 |
| 2 | One day a week isn't enough for a 140-client migration | 5 | 4 | 20 |
| 3 | Opening balances and historical data don't reconcile after moving | 3 | 5 | 15 |
| 4 | Three contractor days don't cover SharePoint, Xero support and fixes | 4 | 3 | 12 |
| 5 | Folder permissions copied wrongly, so staff see files they shouldn't (?) | 3 | 4 | 12 |
| 6 | Partners carry on with old habits, so staff follow them | 3 | 3 | 9 |
| 7 | AI drafts contain errors that nobody catches in busy season | 3 | 3 | 9 |
| 8 | Clients using Sage-linked bank feeds need re-authorising and don't respond (?) | 3 | 2 | 6 |

Top four: warning signs and prevention

1. January collision. Warning: fewer than 30 clients moved by mid-October. Prevention: set a hard cut-off of 30 November; any client not moved by then stays on Sage until February.

1. Lead capacity. Warning: the office manager misses migration days in the first three weeks. Prevention: partners agree in writing which of her normal tasks stop until December.

1. Data not reconciling. Warning: the first 5 pilot clients' trial balances don't match. Prevention: reconcile a 5-client pilot before moving anyone else.

1. Contractor days. Warning: SharePoint takes more than 1.5 days. Prevention: get a written day-by-day scope from the contractor now.

Drop this now
Move the AI assistant rollout to March. It's the least urgent part of the project and the one most likely to cause an embarrassing mistake during busy season.

Why it works

Framing the project as already failed gets past the optimism that makes normal risk reviews useless; it's easier to explain a failure than to predict one. Banning "poor communication" forces causes specific enough to act on. Likelihood x impact sorts a long list into the few that matter. The "costs less than a day" limit on prevention steps keeps the advice proportionate for a small team. The final de-scope question often produces the most valuable change of all.

When not to use it

Less useful for small, reversible tasks where trying and adjusting is cheaper than planning. The model doesn't know your people, suppliers or systems, so its causes are informed guesses. Run it as input to a team discussion rather than a replacement for one, since the people doing the work spot the real risks.

Comments (0)

No comments yet. Be the first to share your thoughts!