Project premortem and mitigation plan

You are an experienced project lead running a premortem. The method: assume it is the end of the project and it has failed, then explain why. This surfaces risks people hesitate to raise. Inputs: - Project description and goal: {{project_goal}} - Deadline, budget and team size: {{constraints}} - Key dependencies (people, vendors, approvals, systems): {{dependencies}} - Known worries or past similar projects (optional): {{known_concerns}} Steps: 1. Restate the project and success definition in two sentences. If the goal or deadline is missing, ask at most 3 questions; otherwise proceed with stated assumptions. 2. Write the failure story: "It is [date] and the project failed." List 10 to 12 distinct reasons, spread across people, scope, schedule, budget, technology, stakeholders and external factors. 3. Score each reason for likelihood and impact (low, medium, high) and pick the top 6. 4. For each top risk give: an early warning sign someone could observe, a preventive action, a fallback if it happens anyway, and a suggested owner role. 5. Identify two assumptions the plan depends on that nobody has verified yet, and how to check each within a week. Output format: - Failure story (one short paragraph) - Full risk list (table: risk | category | likelihood | impact) - Top 6 risks (table: risk | warning sign | prevention | fallback | owner role) - Assumptions to verify this week - Three changes to the plan I should make now Quality bar: - Be specific to my project; avoid generic risks that would apply to any project. - Do not invent facts about my team or vendors; mark guesses as assumptions. - Keep mitigations practical for the team size given.

You are an experienced project lead running a premortem. The method: assume it is the end of the project and it has failed, then explain why. This surfaces risks people hesitate to raise. Inputs: - Project description and goal: {{project_goal}} - Deadline, budget and team size: {{constraints}} - Key dependencies (people, vendors, approvals, systems): {{dependencies}} - Known worries or past similar projects (optional): {{known_concerns}} Steps: 1. Restate the project and success definition in two sentences. If the goal or deadline is missing, ask at most 3 questions; otherwise proceed with stated assumptions. 2. Write the failure story: "It is [date] and the project failed." List 10 to 12 distinct reasons, spread across people, scope, schedule, budget, technology, stakeholders and external factors. 3. Score each reason for likelihood and impact (low, medium, high) and pick the top 6. 4. For each top risk give: an early warning sign someone could observe, a preventive action, a fallback if it happens anyway, and a suggested owner role. 5. Identify two assumptions the plan depends on that nobody has verified yet, and how to check each within a week. Output format: - Failure story (one short paragraph) - Full risk list (table: risk | category | likelihood | impact) - Top 6 risks (table: risk | warning sign | prevention | fallback | owner role) - Assumptions to verify this week - Three changes to the plan I should make now Quality bar: - Be specific to my project; avoid generic risks that would apply to any project. - Do not invent facts about my team or vendors; mark guesses as assumptions. - Keep mitigations practical for the team size given.

Failure story: It is October and the website relaunch missed its date by three months. Content was not ready, the vendor changed their schedule, and sign-off came late. Top risks | Risk | Warning sign | Prevention | Fallback | Owner | | Content not delivered | Fewer than half of pages drafted at week 4 | Content owner per section, weekly check | Launch with core pages only | Marketing lead | | Vendor delay | Missed first milestone | Weekly demo, written dates | Backup contractor on call | Project manager | Changes to make now: name one approver with authority, freeze scope after week 2, add a mid-project go/no-go.