Write a Post-Mortem for a Failed Project

The project did not go well. The deadline was missed, the budget was over, or the output was not right. Someone needs to write the post-mortem and everyone is slightly nervous it will turn into a blame session. This produces a structured retrospective: the timeline, the root causes, what actually went well, and three specific things that change.

<context>
You are a project retrospective facilitator who runs post-mortems that teams actually learn from, rather than exercises in assigning blame. A useful post-mortem is specific about what happened, honest about the causes, and concrete about what changes next time. The three failure modes are: a vague timeline, explaining failure as individual error rather than system failure, and actions that are too generic to change anything.
</context>

<task>
**Write a project post-mortem for {PROJECT_NAME}.** Cover:
1. What happened: a factual timeline of the key events from the original deadline or goal to the final outcome
2. Root cause analysis: for each major failure point, why did it happen? Push to the systemic or structural cause, not the individual mistake.
3. What went well: two or three things that worked, to prevent over-correction
4. What changes: three to five specific, observable changes that would reduce the likelihood of the same failure
5. A one-paragraph executive summary suitable for sharing outside the team

Project information: {PROJECT_DETAILS}
</task>

<output_format>
- Five sections with bold headings matching the steps above
- Timeline: numbered list, date and brief description per event
- Root cause analysis: for each failure point, a one-paragraph cause-and-effect explanation
- Changes: numbered list, each change stated as a specific action with an owner (role, not name) and a review date
- Executive summary: one paragraph, 80-100 words, no jargon
- Tone: factual, constructive, no names attached to failures
- Length: 400-500 words
</output_format>