We are all are drivers, collaborators and leaders In our respective roles in the organizations. We all have a stake in a project. We all work in teams using different project management tools to keep us accountable and transparent with progress in line with organizational KPIs. In spite of having the best tools to capture the progress and process are being put in place, still we fail as individuals or teams on certain assignments. In the space of product development, things going right or wrong can affect the overall product, the brand and above all create friction among team members.
When everything is going as planned, we necessarily do not zoom into details to capture the elements which went right. Invariably, we come collectively with a critical lens when a project takes a wrong turn or a plunge. This is where companies most likely to hold a post mortem. The word post mortem is more aligned with medical practice that to an organizational culture. However, the same meaning can be embedded into an organizational culture to understand the the causes for the death of a particular project. In medicine, a post mortem would not revive pulse but in an organization it could revive pulse and give life to the company.
If used correctly, it can be a great learning tool while a post mortem is badly managed it could lead to dispirit the whole team leading to name calling and finger pointing. Hence, postmortem needs to be approached in a way that it is impartial with the sole purpose of “fact finding” than punitive. The rule of the thumb is to clock a postmortem to a maximum of an one hour. Depending on the size of the project even it can go on for hours. I personally would prefer without sticking to a hard stop, letting the session flow as it may be deem to the occasion. However, the golden rule of a post mortem is to have it no sooner than later, ideally no sooner the project is over. This will help to recall information steadfast than having to make up for loss information.
The best way to have the post mortem is to set aside a date and time. Most importantly, let everyone know beforehand about the purpose of the post mortem. There should be a structured agenda whilst everyone is given an opportunity to to submit information either anonymously or directly beforehand. Ideally, a Google survey form would be a suitable tool for this exercise. Once the information is compiled, the final document needs to be shared with the moderator who will lead the session. It is a good practice to share the agenda with the participants before the meeting.
On the day, yet again the team members should be reminded about the purpose of the post mortem, highlighting the prime motive is to objectively analyse the details and reasons which led to the predicaments. The moderator is expected to create a safe space for everyone allowing free flow of views and information. To make the post mortem more successful and to add value, it is highly recommended to leave behind laptops, phones and anything that could distract the flow of the proceedings. Below are some of the key points that will be touched during this session;
A.Key Accomplishments
1.What went right?
2.What worked well?
3.What was found to be particularly useful?
4.Project highlights
B.Key Problem Areas
1.What went wrong?
2.What project processes didn’t work well?
3.What specific processes caused problems?
4.What were the effects of key problems areas?
5.Technical challenges
C.Risk Management
D.Lessons Learned
Finally, at the end of the session, a recap should be shared with the participants covering the things discussed and the next steps. The points of the next steps should be actionable while assigning members to each action clearly highlighting the drivers and contributors .