I recently read an article by a man who felt that project post-mortems (‘lessons learned’) were a waste of time.

I was surprised, since I’ve always found these reviews to be very useful (not to mention cathartic).

The article went on to say that ‘management’ was never receptive to changes and wouldn’t commit resources necessary for change, that the meetings themselves were boring, and that most people were busy doing their email during the meetings. All in all an interesting point of view, but one very different from my own experience. Maybe it’s a combination of approach and expectations. So I gave some thought to what has made my own experience so positive and figured out the methodology that has worked so consistently well for me:

1. I rarely invite anyone not directly associated with the project. Outside viewpoints are interesting and may be included in the report, but they tend to stifle the willingness of the project team members to speak their minds.

    

2. I always, always start with ‘what went right’. It’s quite as important to keep doing what works as it is to stop doing what doesn’t. It’s also easy to implement the actions – just make sure the success is recognized and keep going. This starts on the right note, keeps everyone engaged, and seems to divert any tendency to point fingers in the ‘what can be improved’ section.

    

3. The team makes a list of what areas could be improved. The list itself needs to come first – we don’t try to solve the issues while we’re brainstorming here or we’d get stuck on the first item.

    

4. Once we have the list, we go through and mark anything we think we can handle quickly during the meeting with respect to possible improvements.

    

5. The items that are too complex for this meeting are assigned to people for follow-up. Typically people particularly interested in an improvement area express that interest here so the point person knows who to work with (I’m on the list for every item). There’s a date associated with the follow-up – usually no more than a week away – so it doesn’t get lost.

    

6. We start through the list of things we think we can handle during this meeting. I try very hard to work with the team to come up with at least one action we as a team can take to improve every item – that way it’s not entirely out of our control and we can make some progress.

    

7. I leave enough time at the end of the meeting to assign out anything on the ‘easy’ list that we didn’t get to and to summarize what we said.

    

8. After the meeting I send out minutes, then track the follow-on efforts and send a final management report once we get all of the data/suggestions in.

    

9. When I start a new project, one of the first meetings I have is to review the post-mortem of the previous project in the area to see what we want to try to implement and what we want to keep.

This has worked for me for many, many projects. Sure, there are sometimes some big things that will require resource commitments from whomever is holding the purse strings (and sure, these often don’t get funded), but there are usually so many things within control of the team that we make progress with every project.

For agile, we review proposed changes and at every wrap-up and kick-off meeting, so it's this process in microcosm. It's so easy to make small incremental changes in an Agile environment that it flows with the rest of the Agile process.