Super-Quick Project Post-mortems

The project post-mortem you do when you don't have time for a project post-mortem.

Good judgment comes from experience, and experience comes from bad judgment. - Mulla Nasrudin

"Don't you already have a blog article on project post-mortems?" Yes, I do. You may be wondering why I'm writing another article on the same topic. It's not because I have an improved version to share, and it's not because I don't believe in the structure I previously devised, in fact, I don't even like this structure I'm about to describe. But just because I don't like something doesn't mean it doesn't have value. The bottom line is that some form of project post-mortem is better than no post-mortem at all.

This leads me to the question; in what situations is this style of report useful? The answer is when you don't have time to run a thorough debriefing at the end of a project. Using this style of report, you can prepare a post mortem document in under 3 hours. So what's my problem with this format than? It's very subjective, it makes no numeric analysis of the bug log, and it doesn't gather input from the developers who worked on the project. That said, it is super fast to produce, so I begrudgingly bow my head to it.

The report format is loosely based on the PRINCE2 lessons learned report protocol. I recall when the structure was first proposed by the lead project manager, I was quite against it, I said my piece, and then waited for a rubbish report to be produced. To my surprise, the report wasn't rubbish, it was quite insightful. It was a good lesson for me too, in flexibility and 'giving things a chance'. The other area of merit this format possesses is that it has room for describing what went well on a project. All too often people want to focus on the negative, but I think its important to speak about the successful aspects of a project too.

The real beauty of the report is that it was written in about 2 hours. This was done in coordination with the lead project manager. I had tried to get approval from the managing director to get the hours needed to do the more in-depth style of project post-mortem I like, but there wasn't enough time.

Now onto the structure of the report. The original report I produced was a PowerPoint presentation, but a Word document is fine too. Each page is made up of a main title signifying the area under analysis (e.g. Management, or Technical). Most pages have a sub-heading along the lines of 'what went well' or 'what went badly' (I like the straight-forwardness of these titles, there's no sugar-coating). Each page contains bullet points rather than paragraphs of text.

Title page - a title like 'ACME Project Post Mortem' in large font, than the date of the report and the start and finish date of the project.

Management - what went well - on this page you describe good management practices employed during the course of the project. Describe strategies and protocols which were seen to pay dividends. For example: "low number of post-launch bug reports. This indicates effective QA protocols", "team commitment was good - everyone contributed time after hours to finish the project."

Management - what went badly - a description of management practices used through-out the project which caused hardship or didn't come out as expected. For example: "the wrong prototyping tool was chosen for creating wireframes", "formal approvals not taken from client, resulting in lost revenue and rework."

Management - what was lacking - this section gives you a chance to discuss what practices would of helped the project along (i.e. "things would of gone better if we..."). For example: "we should of done technical briefing sessions with programmers before they started to code", "we should of spent more time analyzing the spec to produce better time estimates for the project schedule."

Events - a summary of abnormal events which caused deviations on the project (this could be deviations in budget or delivery date). Examples would be: "delays and disruptions caused by staff turn-over", "delays in project progress caused when entire team was moved to a new office location."

Technical - what went well - describe what technical decisions turned out to be a good choice. Examples would be: "the bug tracking system helped manage and control bug reports", "the CMS we chose for the project was simple to install and configure, and easy to teach the client how to use."

Technical - what went badly - a few bullet points about what technology choices hampered the progress of the project. For example: "a lot of the bugs logged were UI related, indicating a lack of attention to detail", "a XML data-store was chosen for the product catalogue when a database implementation would have been better."

Recommendations - arguably the most important section of the document, you can't get to this until you've laid out the proceeding pages of the report. Here is where you bring it all together, look for overall patterns and pose suggestions for how things can be done better on the next project. Some examples would be: "ensure developers get a technical briefing before they code", "development tools should not be changed mid-project if a functioning tool is already in place."



How long will the report be? Perhaps 10-15 PowerPoint slides for a medium to large-sized project (e.g. 160-300 hours).

As an interesting side-note, you'll probably find that on projects which didn't meet their set objectives, went over budget, or were delivered late, the Management - what went badly section will probably be the biggest. The good thing about this is it somewhat objectively shows management practices are what derailed the project (rather than technical decisions).

The witch-hunt factor. I don't believe the purpose of the post-mortem report is to lay blame and point fingers at individuals. That kind of activity serves no one. At its root, the post-mortem should lead to 'kaizen', a Japanese principle which is all about continuous improvement. Will a post-mortem radically change the processes used on the next project? Maybe, but it doesn't have to. It should at least lead to some improvements, some kind of change for the better, otherwise it's a useless exercise.

Subscribe to RSS Feed.