The prompt
Score 10 of 10, Excellent
Use it when You need to imagine the project has failed and list the likely causes while there is still time to act.
- {{project_context}}
- {{key_dates}}
- {{known_concerns}}
- {{plan}}
Full prompt and why it works
Prompt
Project and goal: {{project_context}} Deadline and key dates: {{key_dates}} Concerns already raised: {{known_concerns}} The plan: """ {{plan}} """ Task: Run a pre-mortem on the plan above. Imagine it is three months after the deadline and the project has clearly failed, then work backward to the most likely reasons, while there is still time to act on them. The result is for the project team to discuss and turn into changes to the plan. Format: 1. The failure story: a short account, under 120 words and in the past tense, of how the project failed, built from the weakest points in this plan. 2. Causes of failure: 10 to 15, grouped under people and skills, dependencies and suppliers, scope and requirements, technology, stakeholders and adoption, schedule and budget, and outside events. For each: what went wrong, the early warning sign we would have seen, likelihood and impact (high, medium or low), and one preventive action. 3. Act now: the five causes most worth acting on, each with the change to make to the plan and a suggested owner by role. 4. Running it with the team: a 45-minute session outline (silent writing, one idea per person in turn, grouping, voting, actions) so the team can add the causes only they know. Requirements: - Be specific to this plan. "Poor communication" is not a cause; for example, "the warehouse team hears about the new process a week before go-live" is. - Include the uncomfortable causes where they plausibly apply: the sponsor loses interest, a key person leaves, the goal turns out to be the wrong one, or users do not adopt the result. - Do not invent facts about the organization, suppliers or people. If a cause depends on something the plan does not say, flag it as "(assumption)". - Do not blame named individuals; describe roles and conditions. - Keep it under 900 words. The list should feel a little uncomfortable to the team: if every cause on it is one they have already discussed, look harder at the weak points. Anything the plan leaves out, such as an owner, a budget or a test phase, is itself a likely cause of failure. List it as one rather than assuming it is handled elsewhere.
Variables
- {{project_context}}
- What the project is and what success looks like.
- {{key_dates}}
- The deadline and any milestones that matter.
- {{known_concerns}}
- Worries the team has already mentioned. Write "none" if there are none.
- {{plan}}
- The plan: phases, tasks, owners, dates, budget, whatever you have.
Why it works
- What to make. Imagining the project has already failed makes it easier to name risks that people hesitate to raise about a plan they are committed to.
- What good looks like. Each cause must be specific to this plan, with an early warning sign and a preventive action, so the exercise ends in changes rather than general worry.
- If unsure. Gaps in the plan, such as a missing owner or test phase, are treated as causes of failure instead of being assumed to be handled.