Imagine a failed outcome to surface plausible causes, weak signals, tests, and preventive actions
7 min setupTested with:ChatGPTReviewed: 2026-08-28
1
Add your context
Your text stays in this browser. AILesson Prompts does not send it to a model or server.
2
Your prompt
Unfilled fields remain visible as placeholders, so you can still copy and edit the prompt
Run a project pre-mortem using the supplied context.
Project, users, plan, target, and concrete failure definition:
[project]
Constraints, dependencies, incidents, estimates, dissent, and unknowns:
[assumptions]
Participant perspectives, authority, mitigation capacity, and review timing:
[participants]
Assume the project has failed at the stated future point, then generate distinct and plausible explanations across user value, scope, delivery, quality, operations, people, vendor, governance, security, accessibility, data, and external context only where relevant. Separate evidence-backed concerns from hypotheses. Avoid generic catastrophes, blame, and hindsight certainty. Cluster causes into causal chains, identify earliest observable indicators, and rank by plausibility and damage with stated rationale—not invented precision. For the top scenarios provide a cheap test, prevention, contingency trigger, response, explicit owner or Unassigned, and decision deadline. Include contrarian scenarios and strengths that reduce risk.
Private by defaultPrompt assembly happens locally in your browser. Avoid placing confidential information into any AI service unless your organization allows it.
From input to outcome
A worked example
See how concrete context turns this recipe into a usable result
Actual input
Project and failure date
In March, a regional charity launches an online volunteer scheduling portal for 600 volunteers and 40 coordinators. Failure at 30 June means coordinators still maintain parallel spreadsheets, more than 10% of scheduled shifts are disputed, or fewer than 50% of active volunteers use the portal monthly. Pilot begins with two teams in February.
Evidence and assumptions
Many volunteers use phones; 18% of current records lack a unique email. Coordinators use different shift naming. The vendor says CSV import is supported but has not tested our file. Training budget covers two live sessions. One coordinator worries volunteers will not see cancellation notices. Authentication uses email links. No accessibility test, support rota, or spreadsheet retirement rule exists yet.
Participants and action authority
Workshop includes volunteer coordinator, volunteer representative, operations manager with launch authority, data officer, communications lead, and vendor specialist. Two staff-weeks remain for mitigation. Decisions reviewed next Tuesday.
Example output
Failure story A—fragmented identity and import: 18% without unique email plus untested CSV import causes duplicate/missing accounts; volunteers cannot authenticate; coordinators retain spreadsheets; disputes rise. Evidence-backed. Earliest indicators: import exception rate, duplicate accounts, failed sign-ins. Cheap test: import a de-identified representative file and attempt phone sign-in with records missing/duplicating email. Prevention: define identity remediation and reconcile counts before pilot. Owner: Data officer for test; identity-policy owner Unassigned. Decision by next Tuesday.
B—inconsistent shift definitions: different names map incorrectly, creating disputed schedules and parallel records. Evidence-backed. Test a shared taxonomy against two pilot teams and reconcile every imported shift. C—cancellations fail operationally: email-link users may miss notices; no support rota or acknowledged-notice rule. Concern is explicit, outcome mechanism partly hypothetical. Test delivery/opening plus five volunteer task walkthroughs; define urgent fallback and owner. D—adoption appears acceptable while coordinators maintain shadow sheets; contrarian governance failure. Indicator: edits continue after cutover. Define retirement gate and exception log before launch.
Other hypotheses: mobile accessibility prevents task completion; two sessions miss shift workers; vendor defects outlast two staff-weeks. Strengths: staged two-team pilot, named launch authority, volunteer perspective, and measurable failure thresholds. Prioritize A/B before pilot because they share a data foundation but require separate acceptance checks.
Why this works
1
Prospective hindsight makes teams name failure causes that optimistic planning often suppresses.
2
Indicators and cheap tests convert imagined failure into evidence that can change the plan.
Check the result
Are scenarios specific to this project and linked to supplied evidence or labeled hypotheses?
Do top scenarios have early indicators, cheap tests, triggers, and actionable responses?
Does the output avoid blame, false probability, and duplicate wording of the same causal chain?
ChatGPT