Project Retrospective Prompts: Review and Improve
A retrospective is useful when it changes the next project. Start with a short record of what happened, distinguish observations from interpretations and choose one improvement you can actually test. These prompts are for reflecting on completed work, rather than planning a new project or assigning blame.
A small workflow
- Gather the original goal, actual outcome and a few dated observations.
- Separate what you know happened from your explanation of why it happened.
- Choose one small change with an owner and a way to check it next time.
Worked example
A team delivered a workshop on the agreed date. The slides needed two late revisions because the final attendee list arrived after the first draft. A useful improvement is to agree an attendee-information cutoff before the next workshop; claiming that the team is disorganised goes beyond the evidence.
Build an evidence timeline
You get: A timeline with facts and interpretations separated.
Bring: goal, events, target, result
Review this completed project: goal [goal], dates and events [events], intended result [target], actual result [result]. Build a brief chronological table with event, observed effect and evidence supplied. Put interpretations and unverified causes in a separate list. Do not infer motives, agreement or a missed deadline unless the notes establish it.
Follow-up
Which two missing facts would most change the conclusions?
Find a process lesson
You get: Process questions that avoid unsupported blame.
Bring: timeline
Use this project timeline [timeline]. Identify three possible process lessons. For each, distinguish an observed problem from a proposed explanation and ask what evidence would support that explanation. Focus on handoffs, information and approval steps. Do not attribute a problem to an individual’s character or invent a cause.
Follow-up
Which lesson is best supported by the timeline, and which is still only a hypothesis?
Design one improvement experiment
You get: A small change with a measurable check.
Bring: lesson, project, resources
Our supported lesson is [lesson]. The next similar project is [project] and the resources available are [resources]. Propose one reversible process change. Define when we apply it, who must agree, what record we keep and how we compare the outcome with the previous process. Label any suggested target as a proposal, not a proven benchmark.
Follow-up
Reduce the experiment so it can be tested during one project.
Write the follow-up note
You get: A short recap of agreed actions and open questions.
Bring: decisions, questions
Draft a retrospective follow-up from these confirmed decisions [decisions] and unresolved questions [questions]. Include what we learned, the one change agreed, its confirmed owner and the next review point if supplied. Mark absent ownership or dates as ‘to confirm’. Keep the note under 160 words and do not convert suggestions into decisions.
Follow-up
Remove any action that the notes do not explicitly show as agreed.
Check the result
- Use records rather than reconstructing events from memory alone.
- Ask the people involved to confirm interpretations and ownership.
- Keep one improvement small enough to observe in the next project.
