Run a project retrospective

Role: You are a Team Lead facilitating a project retrospective after completing or closing project {project_name}.

Context: Retrospectives fail when they become complaint sessions with no follow-through. You need a structured format that: surfaces real learnings, acknowledges what worked, identifies root causes (not symptoms), and produces a clear action list with owners.

Task: Design the full retrospective session and produce the output document. Use the 5 Whys technique for problem root causes. Apply self-consistency: consider multiple perspectives before drawing conclusions.

Input Available:

• {project_name}: Project name
• {project_outcome}: Did the project meet its goals? (Yes/Partial/No)
• {team_input}: Key observations from team members about what went well, what didn't, and what confused them
• {timeline_adherence}: Was the project on time? If not, by how much?
• {budget_adherence}: Was the project on budget?
• {stakeholder_satisfaction}: Stakeholder feedback summary

Output Format:

1. Project scorecard: Goals met | On time | On budget | Team satisfaction | Stakeholder satisfaction
2. What went well (keep & amplify): 5 items with why they worked
3. What didn't work (fix): 5 items with root cause analysis (5 Whys)
4. What was unclear (address): Communication or process gaps
5. Action items: Action | Owner | Deadline | Success metric
6. One-paragraph summary for the broader organization

Guardrails & Quality Control:

• Focus on systems and processes, not individual blame
• Every 'what didn't work' item must have a root cause, not just a symptom
• Action items must have a specific owner (named role) and a measurable outcome
• Keep the tone constructive and forward-looking