Run a pre-mortem on an initiative.

What the AI will do

• Learn how your initiative is meant to work, then imagine a future in which it has failed.
• Trace plausible paths to failure and write a hypothetical retrospective grounded in your actual project.
• Use your corrections to recommend practical changes, tests, and early warning signs.

What you can provide

• Start with a plan, documents, links, rough notes, or a spoken account. The AI can interview you if little is written down.

Where you'll take part

• Confirm the project brief and what failure would mean.
• Add your own reasons for failure before seeing the AI’s explanations, or ask it to continue. Participating colleagues contribute separately.
• Review the failure report, then decide which changes or tests, if any, to pursue.

What you'll get

A shareable hypothetical failure report, alternative failure scenarios, and a record of agreed changes, unresolved questions, and when to revisit them.

Activity context

A pre-mortem is a useful technique for identifying risks before a project begins: you imagine its failure to uncover ways to improve its chances of success.

Imagine it’s the end of your project—and it has failed. What happened? Have AI write the report explaining how it fell apart, then work backward to the choices you can make now to give it a better chance.

For the user

Give your AI a project plan, proposal, downloaded file, link, or rough description, and paste the prompt below. A spoken download or an interview works too; you don’t need a polished plan. The AI will establish what you’re trying to achieve, imagine a plausible failure, and investigate how it could unfold.

You’ll check its understanding of the project, review the imagined failure report, and choose which preventive changes are worth making.

Guidance for the AI

These are general instructions, not a description of this user's particular AI system, tools, access, or circumstances. Adapt the method to the user's goal and the capabilities you can actually use, while preserving the activity's essential sequence, review points, and intended result.

Start with the activity and the user's context

Read the complete activity and guide the user through it. Use the activity prompt yourself; the user does not need to paste it again. Keep the responsibilities of the user, the AI, and any colleague clear.

Begin with what the user has already supplied. Establish the intended result and resolve missing context through focused questions when needed. Work within the activity's stated scope, permissions, required confirmations, and stopping points, including any deliberate order for introducing information. Make progress with the available information and reasonable, clearly identified assumptions where the activity allows them.

Check the capabilities needed for this work

Inspect relevant available tools, connectors, and data. Use small, relevant, non-destructive checks to establish whether necessary access or a capability actually works. Naming a product does not establish access to it. Let this activity determine what needs checking; do not impose a universal preliminary questionnaire or a full system audit.

When useful access is missing:

• Explain what you cannot reach and how that material would help.
• Investigate practical setup, connection, export, or other access alternatives before asking the user to gather material or troubleshoot.
• If progress depends on access, request only the specific user action or permission needed to enable it or provide the material another way. Continue useful independent work while awaiting the response.
• Offer to walk the user through an export or upload. Welcome files, links, copied text, rough notes, or an interview as supported by your system and the activity, and use the best available route. If the missing access is optional, continue with what is available.

Ask focused questions and respect the answers

Ask questions only when necessary to complete the work well or satisfy the activity's required review points. Build on answers already supplied. Ask one question at a time, or a small group of closely related questions. Wait on work that depends on the answer, and continue useful work that does not. Explain unfamiliar language with examples where helpful.

Confirm answers or decisions you supply on the user's behalf before treating them as the user's final answers or decisions. This does not require separate approval of every sourced finding; follow the activity's specific review requirements.

Keep evidence and independent contributions distinct

Distinguish evidence, inference, and missing information. Check your work against the source material.

Use independent agents when your system actually supports delegation and independent investigation or review would improve the work:

• Give each agent a bounded brief and the context appropriate to its role.
• Keep discovery independent until synthesis where the activity requires it. Preserve any requirement for the user or colleagues to contribute before seeing other explanations.
• Follow the activity's stated fallback and any required confirmation when independent agents or fresh contexts are unavailable. Preserve reviewer isolation where required; describe shared-context or sequential passes accurately.

Produce, check, and revise the result

Do the substantive investigation and production. Carry the activity through to the most complete, usable result within its scope, rather than ending with a plan or handing the main work back to the user. When missing information does not prevent useful work, proceed with clearly identified assumptions where the activity permits them.

Check the result against the activity's completion criteria. At each substantive delivery, state what is complete and any material unfinished work, assumptions, helpful missing information, and remaining uncertainty. Explain how these affect what the user can use, and help the user revise the result.

Preserve the activity's stopping point. Do not turn a rehearsal, investigation, or test-design activity into execution that the user has not authorized.

Your AI prompt

Run a pre-mortem on my project. Imagine that we have reached a relevant future date and the project has failed. Write a substantive report explaining what happened and why, then identify choices we can make now to reduce the chance of that failure. Do the investigation and drafting yourself. Ask one focused question at a time when you need my input.

1. Understand the project and what failure would mean.

Start with whatever I have supplied: a written plan, proposal, downloaded document, link, rough notes, or a spoken account. Read the material carefully. Check and try available access to relevant project files and connected documents, email, or meeting notes to fill gaps. If a source is inaccessible, investigate available access options and offer to walk me through exporting or sharing it. If little is written down, interview me and assemble the project description from my answers.

Establish:

• The intended result and who it is for.
• The plan for achieving it, timing, and resources.
• Key people and dependencies.
• The assumptions that must hold.

Find out which decisions are still open. Pay particular attention to dependencies outside the project team’s control and concerns already raised. Use the project’s actual circumstances; these topics are starting points, not a questionnaire I must complete.

Summarize your understanding, distinguish documented facts from assumptions and unknowns, and propose a future date or milestone at which we could judge the outcome. Define failure concretely: what promised result did not materialize, for whom, and with what consequence? A project can be delivered on time and still fail to achieve its purpose. Ask me to confirm or correct this brief and failure definition. Wait before proceeding.

2. Imagine the failure and generate explanations before judging them.

Take the confirmed future viewpoint: the project has failed. Ask what happened to bring us here. Treat failure as a certainty within this exercise, while keeping clear that we are constructing a hypothetical account.

Generate a broad set of project-specific explanations before selecting a story or proposing fixes. Examine what happens if important assumptions turn out badly, a critical dependency breaks, or a weak point compounds another. Include uncomfortable organizational possibilities such as conflicting incentives, an overloaded team, loss of sponsorship, or people declining to adopt the result when those fit this project. Explain the mechanism; “poor communication” alone is not an explanation.

Independent explanations

If separate agents are available, give a small number the same confirmed project brief and source material, without sharing your draft explanations or their answers with each other. Ask each to independently explain how the project failed, citing the facts it starts from and labeling the adverse developments it imagines. Invite different emphases, such as delivery, adoption, and organizational dependencies, while allowing each to look beyond its assigned emphasis. Collect their accounts before synthesizing them. Otherwise explore these perspectives yourself in separate passes.

Invite separate human contributions

Before showing me the explanations, invite me to add my own reasons for the failure or tell you to continue. Wait for my response. If colleagues are already participating, have each contribute separately before seeing the others’ ideas. Continue with the available information if we choose not to contribute. AI-generated perspectives remain hypotheses to examine, not evidence of what actual stakeholders believe.

3. Work out the most consequential paths to failure.

Bring the explanations together, combine duplicates, and trace the causal chains. For each serious candidate, identify:

• The assumption or dependency that failed.
• What happened next.
• The consequence for the project’s intended result.
• An early sign that might have revealed the problem.

Connect it to the actual plan or an explicit unknown. Separate causes from symptoms and show where several failures share one underlying weakness.

Assess and select the causal paths

Assess which paths deserve attention using their plausibility, impact, and how much we can prevent or limit them. Explain the basis for your judgment. Don’t assign numerical probabilities without a defensible basis or treat agreement between agents as proof. Keep a consequential possibility visible even when evidence is too thin to judge its likelihood; identify what we would need to learn.

Choose the strongest causal chain for the main report. Preserve materially different ways the project could fail as short alternative scenarios. Keep the main account coherent: don’t force incompatible events or every imaginable disaster into one story.

4. Write the report from the failed future.

Write a clearly labeled hypothetical failure report, dated at the agreed future milestone and told in the past tense. Open with what we set out to achieve and what happened instead. Reconstruct how early decisions, unmet assumptions, weak dependencies, and missed signals led to the result. Show where a different choice could have interrupted the chain. Make the account specific enough that I can recognize this project, rather than a generic project-management warning.

Keep the narrative readable. Follow it with a short explanation of its factual foundations, the negative outcomes you introduced for the exercise, and the most important unknowns. Use source references for actual project facts where available. Any hypothetical figures must be labeled; don’t invent actual quotes, meetings, or evidence to make the story convincing. Include the alternative failure scenarios and the distinct weaknesses they reveal.

Check the report, then pause for my review

If a fresh reviewer is available, have it check the report against the project material for unsupported factual claims, missing causal links, and existing protections you overlooked. Reconcile its findings before presenting the report. Otherwise perform that check yourself.

Show me the report and ask what important context, existing protections, or failure paths it missed. Wait for my response and revise your interpretation before recommending changes.

5. Return to the present and identify choices worth changing.

Use the revised analysis to recommend a short, prioritized set of actions we could take now. For each, identify the failure path it addresses, the specific decision or change, and how that change would interrupt the chain. Check whether the current plan already addresses it. Explain meaningful effort or tradeoffs and what vulnerability would remain.

Tests and early warnings

Where an uncertain assumption drives the failure, propose a concrete way to test it before we depend on it. State what we would learn and how different results would change the decision. Where prevention is limited, propose an early warning sign and a specific response if it appears. Suggest a responsible role and a useful deadline or project milestone, marking these as proposals for us to confirm.

Record my decisions

Focus first on the few changes with the strongest combination of consequence and practical benefit. Ask which I want to adopt or explore, and wait. Incorporate my decisions into the final pre-mortem report, with a concise list of agreed changes, unresolved questions, and a point at which we should revisit the analysis. Keep recommendations distinct from accepted decisions. Deliver the report in a form I can keep and share. Completion means we have both a plausible explanation of failure and useful choices to make before it happens.

Done when

You have an imagined failure report grounded in your actual project, the weak assumptions and dependencies it exposes, and a clear decision about which changes or tests, if any, to pursue now.

These instructions were written in September 2026 using the frontier models available at the time. You may now have better tools or models, or restrictions that make some tasks harder. Your AI should adapt to the tools and access you actually have and find the best available way to help. Everything here is a starting suggestion for you and your AI, not a proven best practice for every setup. Feel free to rewrite any of it to better meet your needs.