How do you share lessons learned from a post-mortem?

Question

Running a project post-mortem (or post-implementation review) is a valuable way to identify and document lessons learned from the project.

After doing so, how to best share (and act upon) those lessons learned with an organization as a whole? It is not just the project team that would benefit from the lessons learned, and too often I see the review outcomes relegated to a document library for an archived project where it is never read.

I understand some companies such as Boeing have a black book of lessons from past failures that are shared with employees... any other approaches that work well?

Answer 1

Retrospectives are incredibly powerful tools if they are used wisely. (Not unlike the Jedi's Force, it can be for good or darkness.)

One of my first suggestions on making them more effective, is to hold them more often. Holding them only at the end of the project means you can't apply any of the lessons to the project. Holding Retrospectives after major milestones, phase gates, etc. can be quick and quickly applied. I highly recommend the Manager Tools Hotwash podcast for an excellent and quick Retrospective for during a project. I marry this with the Scrum guideline of focus on fixing just one thing at a time.

Now instead of saving up a years worth of lessons, you can put learning into practice.

Retrospectives can still be very valuable after a project has ended. Reach into the PMBoK and it lists Lessons Learned as an Organizational Process Asset. During the chartering or forming of a project you would specifically look back on past projects for what can be learned from them. PM consultant Ainsley Nies used to specialize in Retrospectives. This was until she discovered that something like 80% of all Retrospective found issues could be traced back to the Chartering stage of the project. Now she is helping companies kick of their projects right, by looking back.

Answer 2

I find documents which are results of retrospectives/post mortems/lessons learned very often useless as no matter how good they are people rarely go back to them.

For me retros serve a couple of purposes:

1. Learning what's wrong. From this perspective the discussion is the most valuable part as no one in the team is kind of oracle who knows everything about all the issues in the project. Here, focus should be set on facilitating a good discussion during retrospective, get everyone involved and create atmosphere where openness and honesty are encouraged.

2. Applying those lessons. Actually this is the biggest problem with retrospectives - people don't learn from than. So what I'd do here is building short and simple plans which can be verified. A few ideas here.

   • Try to focus on a single most painful problem only. Move to another once the first one is fixed.

   • Set goals, measurable if possible. Check regularly whether you're doing well. If you have no other idea just discuss it with the team.

   • Do retros frequently, e.g. in Scrum you're advised to do them after each sprint which means once every 2-4 weeks. This way you often have checkpoints when you can verify how you're doing and adjust the course or move to another thing on the list.

   • If you work in a co-located team you may try informal ad-hoc retrospectives which are very light-weight but then they virtually are call for action which makes it likely to see results very fast.

If you want to spread the knowledge among the whole company, first make your retros successful and then invite some people who care to improve their teams as guests to your meetings so they can see what you're doing and share that in their teams.

Answer 3

Apart from the project team, the first audience should be other PM's. If you hold a monthly "PM community" meeting or something, you could add the sharing of lessons learned as a fixed item on the agenda.

Make it compulsory for PM's to present their Lessons Learned at least at the end of a project, or every 6 months if the project takes longer than a year.

Additionally, you could put this in their yearly evaluation.

Answer 4

I would recommend having a company intranet site with current events, current projects, etc. and a section for templates and lessons learned. The best way I know of seeing something used/implemented is to reward for it so, after publishing and having available lessons learned, allow for other teams to reference the lesson and how they utilized it on their project. If the PMO feels it was well utilized, buy the team lunch (pizza greases the wheels of success all the time). Constant and consistent recognition of improvements -- planned or otherwise -- sends a strong signal to all teams of what is expected.

Answer 5

Apart from the above, make it a "MUST HAVE" for a new PM to read the book before his new project starts. You can add a "Read Lessons Learned" step to you internal procedures or just encourage him to do so.