I was facilitating a one-day workshop last week in the Hudson Valley area on how to run and manage a post-mortem meeting at the end of a project. The first thing we discussed was the name ‘post-mortem’. We all agreed that the name needed some work.
If you look it up, you will see that the term post-mortem is latin for “after death “, and originally referred to a medical examination of a corpse to determine the cause of death.
The group decided that we would embrace the term ‘Post Implementation Review’ or PIR. So today we’re going to talk about your PIR’s.
Let’s start with admitting that none of us do this very well or even, unfortunately, at all. Once our projects are done we’re often flying onto the next project. Our team is dispersed and taking time to discuss the past does not seem to be a good use of anyone’s time.
We all know this is a big mistake. There are so many good things that can come out of a PIR:
- Process improvement that will benefit all projects
- the use of tools
- how we manage projects generally
and surprising to some:
- our own professional growth as we learn about ways of being better project managers.
So here than are this week’s four tips for running better PIR’s.
- Sell the idea first. People may not want to attend so we should spend time selling the benefits of the meeting – convince people that this is a great thing to contribute to and it will benefit them and many others around.
- Be prepared. Go in prepared so that your gathering is constructive, productive and a great use of everyone’s time. Be ready with all the required information, start and end on time as scheduled, structure the meeting well and be organized from start to finish.
- Guide the process. This goes to the ‘structure’ comment above. Attendees should be guided through all the segments of the project and your project management process in a well-organized fashion. Thinking about what you did well and what needs fixing is a lot easier if you guide the conversation through each one of your project areas: scheduling in control, risk, tools, communication, issue resolution and more.
- Communicate the results. This is a reminder that the information can be very valuable to many people but that it has to be communicated properly. Too often we take these reports and file them away so that no one will ever read them again. Communicating the results means creating a plan as to where it goes, who will read it and a follow-up plan so that it doesn’t get lost in the future. Our PM 101-level Communication Plan would be a great tool at this time: who gets what, why, when, how and where? This will ensure that the vital information we’ve created will not be filed away forever.
Call it a PIR or post-mortem or lessons learned meeting – it really doesn’t matter. What does matter is that people understand its importance, enjoy contributing to its creation and that the information gets communicated to the right people.
When is your next PIR? Are you ready?
Images Courtesy of www.freedigitalphotos.net
9 thoughts on “4 Tips for Conducting Your Next Post-Mortem Review?”
David: First and foremost thank you for all of your energy and output – super valuable! On this post you are stepping on a pet peeve of mine – One key reason PIRs are so hard to sell is that so often they are done and forgotten – the perception is there is little value to take away. The reason: the process for compiling and using any information gathered in PIRs has so often been ineffective or non-existent. The best most organizations can do is point to a data dump where thousands of PIR results from past projects lie moldering. Insights from the data heap, accessible organization, and an effective and useful way of retrieving _relevant_ pieces of it when needed by practitioners all seem to escape us. There are ways to solve these problems and achieve an interactive, query-response kind of interface that could provide project planners with relevant and focused insights tailored to a prospective project. However I have found the stink from ineffective past efforts with data dumps makes it hard for folks to consider trying again.
David
PIR are great way to learn from a project management perspective but has to be done efficiently. I have wrote an article a while ago about how to conduct lessons learned (not the place here to promote it) and I found that basic rules of engagement is the key. You have to make sure everyone is safe of discussing and that we do not attack people but processes. As Walt mentioned, the key is after, where the data is stored, how do we file it to make sure it is easy to access… That could be another topic for your great blog!
On another topic, you should add a login feature to your website so we can just login and no needs to enter our info all the time…
Walt: I share your pet peeve and your points are valid. However, organization don’t necessarily have to point to data dump where PIR results from past projects are smoldering. Instead a simple log of PIR’s/Lessons Learned for projects may be the solution. Have PM or BA leads summarize the top 3 lessons learned from the PIRs and input them to an excel log. Whether they be about project, planning, future initiatives or how to manage a specific stakeholder. The log (single source of information) can then be shared with new project teams (possibly in a SharePoint platform) to use and access to determine if any previous project learnings can be applied to the new project. Thus managing projects with less risk, increased efficiency and leading to continuous project improvement.
Sure, David. I was inspired by the Taxonomy suggested by Carnegie Mellon for Software Development Risk Evaluation (https://www.sei.cmu.edu/reports/93tr006.pdf). I built a similar Taxonomy for Project-oriented risks (I’m happy to share). Now imagine using a template for Lessons Learned (to assure complete info and consistent fields and use) and then imagine being able to tag issues raised by taxonomy elements. The submitter, or the PMO can review and apply tags. The researcher at project concept time, can query by risk tag to quickly find not only the relevant records, but the specific elements of those records that apply. I’ve also put some thought into the data schema to make it all work – and I’m happy to share that too, if there is interest. The key here is to make data creation and data retrieval low-friction, while delivering relevant responses to queries. So now I think in terms of the kind of functionality social apps deliver: Why not also let my users apply their own set of tags at will – making the data repository, over time, more and more tailored to individual PMs and their needs? This could develop into a powerful knowledge management accelerator.
Walt: Yes the Taxonomy suggested by Carnegie Mellon for Software Development Risk Evaluation is interesting. I’m interested in the Taxonomy for Project-oriented risks you’ve built as well as the data schema to make it all work. Can you share?
The following was submitted at the request of anonymity…
PIR’s are very frustrating. Huge amount of time at XOrganization dedicated to this, but no one ever does anything with the data.
XBank was no different. I remember running a PIR (L’s L’ed) and came up with a long list of terrific ‘recommendations’… Kinda like an audit.
The Director (Sponsor) went harrumph, and let me know he was running his Dept., not my list of Lessons Learned.
That was my personal LL.
They always seem to be part of ‘governance’, but to what end?
You need two or three PIR’s. One internal to start, then one that includes vendors and/or clients. Don’t want vendors and clients exposed to our internal laundry.
You are never allowed to assess blame. So everything is on a Happy Path anyway. Don’t know what difference it really makes.
Sure, you can blame a process, but try to determine who owns it, and if there’s any chance of having it fixed. Yet another change.
One thing I found was that lessons learned need to create some sort of action wherever possible – a change in process, a maintenance change to improve something delivered, or maybe a new project to address a deficiency. And the action needs to have an owner who is accountable for delivering.
Where it is simply a lesson learned, as a PMO leader this is where I saw an opportunity to add value by presenting the lessons learned back to the other PMs. Sometimes I would aggregate and do this anonymously, other times PMs would present it themselves – especially when it was something positive to be recognized for amongst their peers, because we sometimes forget that it’s not just what went wrong, but what we did well. It’s not necessarily a post-mortem, but can also be a post-birth analysis!
buy piroxicam safe piroxicam order discount https://www.theknot.com/wedding/ordering-piroxicam