When you face a problem in your project, don’t get frustrated. Take another perspective: It’s an opportunity to learn, an opportunity to improve yourself or your team. Failure, however painful and stressful, is a resource, so embrace it.

Of course, in order for problems to benefit you, you should take time to review and learn from the experience. To simplify the learning process, start collecting postmortem data from the very beginning. Along with the project plan, set up everything to make gathering feedback as easy as possible.

Below is the minimum set of data I usually collect and review on my projects. I do it during the project execution while my and my team’s memories are still fresh.

Issue List

This list is designed to store all the issues discovered during the project execution. Every issue belongs to a defined category. When you start the analysis, you can easily identify some common patterns (for instance, which types of issues cause you the most trouble). Having this data handy not only helps prevent the same issues from happening in the future but also helps make positive process changes at the organizational level. It’s pure gold!

Risk List

Similar to the issues, the risks grouped by categories will give you insights. The next step is to collect data on the risks that became issues later on and try to understand why they turned into issues even though they were discovered early on.

Schedule Variance

Projects don’t always follow their schedules exactly, and it’s always interesting to see the variance between the baseline and the actual dates. For that, you need to define the baseline start and end dates. When the project is done, compare those dates to the actual start and end dates.

One step further is to match delays to the issues from the list above. A report like this will give you an understanding of which issues caused the timeline slippage.

Lessons Learned and Action Items

When you’re looking back at the issues, you typically form an idea of what you could have done better. For each issue, write down a lesson worth reflecting on. Sometimes it might require an action item for your team or a change request at the organizational level. Take action to really benefit from the lessons learned.

When the project is done, schedule a meeting with the internal stakeholders to review the collected data, have a good discussion, and think of ways of how to improve.

…

To conclude, I’ve written this note from a project manager’s perspective, but I do not believe retrospectives are something that only PMs need to do. All team members who are keen to learn from their experiences should do them to some extent. Simply journaling your thoughts and issues throughout your workdays will provide lots of benefits. Happy learning!