A Lesson Is Not Learned Because We Wrote It Down

Picture this handover. The package is complete, except for a drawing that the next team needs. The drawing has been issued. Look in the register and you will find the issue date, the revision, everything you would expect. Ask the colleague at the other end to open the drawing and you get a different answer: it is not there.

Work stops while someone chases the missing file. Afterwards, the handover gets its review. An action appears in the minutes: improve communication. It has an owner. At the next meeting, the action is closed because the drawing was sent again.

What has the next project gained from any of this?

This is an imagined job, not a case from the book. I use it here to approach Chapter 9 of What Are We Missing? from a project desk rather than through one of the chapter's cases. Sending the missing drawing fixes this handover. I would still want someone to take me through the closing of the package. Where, between issuing a file and marking the job complete, did anyone ask the receiver? That part could be left unexamined once the replacement drawing arrives.

I would stay with that gap. The date gives me one part of the account. To accept the handover I would need the other end of it, too.

The action was closed. Was the problem?

Let me take one action from the review and follow it through the next package. Take that instruction to improve communication. Who is meant to do something different? At which point in the handover? How are they going to find out whether the receiving engineer has the drawing?

I would ask those questions before passing the action on. Otherwise we have left the next team to work out what we meant by it.

This is why I hesitate over the phrase lessons learned. It sounds finished. I can read a perfectly clear account of the delay and still have no idea what to do on the next job. I know where the drawing ended up. I still need to know where to put the check, and whose call it is to hold the package when something is missing.

Suppose the proposed fix is a check by the receiving team before the package is marked complete. That is something we can examine on the next handover. Did it happen? Was the right person available to make it? Did the check catch a missing revision, or did it become another signature nobody had time to question?

A closed action cannot answer those questions by itself.

Before the explanation

There is a useful discipline in the US Army's guide to after-action reviews. It asks the people involved to work through the event and find improvements for themselves. That is a different job from sitting through somebody else's verdict. The guide calls that distinction out: an after-action review is not a critique.

The NASA guidance I read calls its version Pause and Learn, and puts it through the project's life. It begins with the plan beside the event: what was meant to happen, and what did? From that comparison come the reasons for the differences and the changes to make. There is a question about repeating successes as well. I appreciate that last question: a review that discards a good practice has lost something too.

For our drawing, I would start with the dispatch and the receipt, and resist the early explanation. In our imagined handover, the sender might say the package was complete because every item had been issued. The receiver might say it was incomplete because one item was unavailable for use. Both accounts matter. Chasing a quicker dispatch would be a poor answer to that disagreement.

Before writing a fresh procedure, I would open the current one. Is the receiving check already there? Can the person named in it see the register? What happens when they are away? Those are questions to investigate on this imagined job; I am not assuming their answers. The last thing I want is a second instruction sitting beside a first instruction that nobody could follow.

None of this excuses a skipped check. If someone had the information and the means to act, that belongs in the account. Then ask what the next person will face. If the same obstacle is still there, naming this person's mistake has left part of the job undone.

The colleague who was not in the room

Now put the review in the hands of another team. They have their own programme to protect. They were not there for the argument about the register. They open the minutes and find improve communication. What are they to make of that? They sent their last package on time and, as far as they know, nobody complained.

Send them the disagreement over complete instead. Now they have a question worth taking to their own drawing register: whose definition are we using? They may need a different fix. I would want them to know why the change was proposed, so they can judge it against their own job.

This is where Chapter 9 takes the review out of the meeting. Who gets the account? Can they speak to someone who was there? I would send a short note with the disputed definition, the proposed receiving check and the reason for choosing it. If the next team cannot tell whether it fits their package, the note needs another conversation, not another circulation list.

Then go back. Ask what they used. Put an actual handover beside the new check and see what the team did. Or hear their reasons for refusing the proposal. Their objection may be the detail our review missed.

This is a recommendation, not evidence that one template will prevent failure. The effort has to suit the decision. I would not assemble a committee over every late drawing. I would spend more time on a handover whose assumptions another team is about to build on.

What reaches the work

Chapter 9 follows knowledge beyond the people who first held it. For me, the recipient is the test. A review can make sense to everyone at the table and remain useless to the colleague who opens the file a month later. I would follow it as far as the next decision the lesson was meant to improve.

What Are We Missing? is about the questions we leave unasked before we commit. Here is one for the next project review: what did we do differently because of the last one?

If nobody can point to anything, keep that question open.

Explore the book and read the free sample: https://zafaralam.co.uk

Available to pre-order now: https://amzn.eu/d/0au4rUW3