Post Mortems are often referred to as the phase in a project where overall lessons are learned. What worked, what didn't work and what can be improved. But is it effective for failed projects (definition of failed is left up to you)?
In thinking over a quote from a Mr. Albert Einstein We can't solve problems by using the same kind of thinking we used when we created them. I started to think that the process of the post mortem and the people who would manage it are most likely the ones who had (and/or caused) the issues in the project....so would the combination of process/people be effective in performing a post mortem? Most likely not. If you've read Richard Farson's Management of the Absurd - there's a sentence (I can't exactly quote it from memory) - that basically says that only people that realize they can improve will improve and those are the people that are considered in most cases successful.
So, my thinking is, you can't stop people from doing what they think is right (or what they think will cover their butts during reviews), but, to continue with any effort with the same processes and same people during an obvious failed project is a waste and a real 'sit down and think it over' period is required. Spend your time/effort where it counts the most...don't follow process for process sake.
My answer for the question from the title is "yes." When I look at outcome from any post mortem I always see first things which went wrong, then those which are to be improved and finally I check what was good. That's because post mortem which is done well brings you a lot of knowledge how to improve future projects, processes, team etc.
ReplyDeleteWhen something went well everyone knows it. It's a bigger challenge to point what exactly on the low level went wrong and invited general failure. Ask developer and he'll come with different things than project manager and they both will point other issues than support engineer.
That's why I believe post mortems should be done after failed projects. Especially after them.