In project management, the purpose of a Post-Mortem is to evaluate a recently finished project. This is a valuable post-project activity whether the project was successful, unsuccessful, cancelled, etc.
Goal and Objectives
The goal of a post-mortem meeting is to learn from the project experience. The key objectives are:
- What did we do well? What did we get right?
- What did we struggle with? What did we do wrong?
- What can we improve on next time?
The whole focus of the post-mortem is "next time". The just finished project is over, it is "dead". There is no opportunity to change the outcome. But any lessons that can be learned from the experience can be applied in future engagements.
Focus and Attitude
It is important for participants in a post-mortem to keep in mind that the focus of th exercise is the future. The attitude should be positive ("What can we learn?"), and Not who should be blamed for problems and failures. This is not an easy thing to do if a project was a huge failure.
Areas of Focus
Anything related to a project can be included in a post-mortem. But areas that are part of most projects are of special concern. For example:
- Communications; customer relations; team meetings
- Budgets; timelines; task management; time management
- Gathering Requirements; preparing designs; documenting changes
- Building and Coding activities; managing changes
- Testing; problem resolution; validating accurate operations
- Deployments; responses to customer issues; issue tracking
- Customer satisfaction; management satisfaction
What Went Right?
Identifying what went well about a project is very important. Hopefully, those items are things that have been done well in the past, where the organization and team have developed a consistent approach that continued to work for this project. Better, there may be areas that have improved; maybe areas that were identified as problems in previous projects.
For example, perhaps the development team adopted a task management system that has worked well in prior projects. Did it work well this time?
What Went Wrong?
For many projects, this seems easy. Requirements were wrong, coding took too long, testing was not accurate, the project ran over time and budget, the customer was not happy, etc. But those are all results of problems - not the actual problems or the reasons for those problems.
Just as in any quality control process, the key to finding, discussing and resolving problems is to find the "root cause". WHY were the requirements wrong?
- Did the customer not provide accurate information?
- Did we fail to ask necessary questions?
- Was there a disconnect between gathering requirements and documenting them to designers and developers?
- Did the designers and developers misunderstand?
- Were there problems with standards?
- Were code reviews skipped or not effective?
Problems can be truly resolved until the root causes are defined and addressed. The sample list above illustrates that there are a very large number of possible reasons why things were not right. Failing to find the root cause means the organization may waste time running in multiple directions and not addressing the actual issues.
The post-mortem is also not the time or place to resolve the problems. Defining the root causes can be a difficult task all by itself. Finding fixes for the identified problems should be addressed after the post-mortem.
What Can be Done Better?
Regardless of the outcome of the project (successful, unsuccessful, cancelled, etc.), there are always opportunities for improvements. Perhaps meetings can be made shorter and more productive. Perhaps requirements can be cleared and less open to interpretation. Perhaps customers can be better involved, or testing can be better automated.
Obviously, the organization want to avoid all the things that went wrong. But that should not overshadow efforts to also tweak and improve things that went well. It is also important for organizations to realize that some processes are relatively standard and executed in nearly the same manner for most projects. Improving those efforts mean every future project should be improved in those areas.
Other parts of a project may be something that happens one-time or rarely. The challenge is those cases is less with "why did we fail executing X", that "How do we better approach and execute processes that we are not familiar with?".
Team View vs. Personal View
Post-mortems are almost always focused on the organization, the team, and the overall project. But individuals should always take the opportunity to perform the same analysis on their own participation.
- What did I do well? What did I get right?
- What did I struggle with? What did I do wrong?
- What can I improve on next time?
This is very similar to the overall analysis that the team is conducting. But for the individual developer, for example, this is the perfect time to consider how to improve personal skills and training in areas such as communications, collaboration, coding, documentation, testing, etc. Perhaps some tasks were overly difficult because the person lacked experience with certain coding concepts or languages. Are those things likely to come up in the future? They may be skills to study and practice, and consider adding to the personal tool belt.
One area to always consider: communications. Did I do the best job possible in communicating with my team, management, customers, etc.? It is almost always possible to improve on how we communicate with others, whether it being clearer, more timely, more to the point, responding quicker, managing our time to communicate, managing expectations, etc.
Individuals should always be able to note one or more items of communication that they can work on improving.