# Run a lessons-learned review: checklist

Turn your notes on a finished project or event into a blame-free review, with what happened, what went well, what got in the way and why, one change to try for each problem, and the questions the notes cannot answer.

## Before you start

- [ ] Have ready: What the project set out to do
  One line on what you were trying to achieve, with any target.
- [ ] Have ready: What happened
  Paste your notes, a timeline or the messages, in any order. Include what went well and what did not.

## Step 1: Lay out what happened

- [ ] List the events in the order they happened, each quoted from the notes, with no judgment yet.
- [ ] You have: A table of the events in order, each quoted from the notes.
- [ ] Check: Every quote in the Quote column appears word for word in the what happened.
  A plain rule you can check by eye. If not: Run the step once more, and add what was wrong to the end of the prompt. If it still does not pass, fix it by hand and make a note of it.

## Step 2: Sort what went well from what got in the way

- [ ] Pick out the events that mattered, mark each one, and say what in the situation made it happen.
- [ ] You have: A table that marks each event that mattered as went well or got in the way, with the cause from the notes.
- [ ] Check: Every row of the table has one of "went well" or "got in the way" in the Effect column.
  A plain rule you can check by eye. If not: Run the step once more, and add what was wrong to the end of the prompt. If it still does not pass, fix it by hand and make a note of it.

## Step 3: Turn each problem into a change

- [ ] For every event that got in the way, write one change to try, a role to own it and a way to tell it worked.
- [ ] You have: A table with one change, one owner role and one way to know for each problem.
- [ ] Check: Every row of the table has something written in "Change to try", "Owner (a role)" and "How we will know" (a blank or a dash does not count).
  A plain rule you can check by eye. If not: Run the step once more, and add what was wrong to the end of the prompt. If it still does not pass, fix it by hand and make a note of it.

## Step 4: Write the review

- [ ] Put the summary, what went well, the changes and the open questions in one short review a team can read together.
- [ ] You have: A short review with a summary, what went well, a table of problems and changes, and the open questions.
- [ ] Check: The answer includes the words "Check this draft with the people who were there before you share it.".
  A plain rule you can check by eye. If not: Run the step once more, and add what was wrong to the end of the prompt. If it still does not pass, fix it by hand and make a note of it.

## Final checks

- [ ] Check: Every number in the answer also appears in the what happened.
  A plain rule you can check by eye. If not: Run the step once more, and add what was wrong to the end of the prompt. If it still does not pass, fix it by hand and make a note of it.
- [ ] Check: Read the review in the answer. Does any line name a person as the cause, say someone failed, forgot or should have done something, or guess at a person's reasons? Roles are fine when they only say who owns a change. Answer FAIL and quote each line that does.
  Checked by a second AI prompt. If not: Run the step once more, and add what was wrong to the end of the prompt. If it still does not pass, fix it by hand and make a note of it.
- [ ] Check: Compare each change in the answer with its cause in the sorted events below. Does each change answer the cause in its own row, and does it say what a person would do, rather than advice such as "be more careful" or "plan better"? Answer FAIL and quote each change that does not.
  Checked by a second AI prompt. If not: Run the step once more, and add what was wrong to the end of the prompt. If it still does not pass, fix it by hand and make a note of it.
- [ ] Check: Read the review with the people who were there. Ask each whether it matches what they remember and whether any line reads as blame, and change any line they dispute before you share it. Only they know what the notes left out.
  Checked by you. If not: Carry on, but write down the problem so whoever uses the result knows about it.

## You end up with

- [ ] A summary of how the project went in two sentences.
- [ ] A list of what went well.
- [ ] A table of what got in the way, why, one change to try, an owner role and a way to know.
- [ ] The questions the notes cannot answer.

---

From Logic Lab (logiclabhq.com). Free to use and adapt, with credit.