• Increase font size
  • Default font size
  • Decrease font size
Home Blog: Back From Red General Blog Kill the Postmortem
E-mail Print PDF

Kill the Postmortem

In a recent blog on stupid decisions, a reader asked about lessons learned processes. I had to defer the question since my reply would have been as long as the blog he was commenting on. So here we go: the entire class of retrospectives, postmortems, and lessons learned are a waste of time. Well, to be fair, I have never seen them work. They may have worked for others. Maybe the reason I never see them work is that I am involved only on disasters, you know, those projects everyone talks about for years to come, the ones people cannot get way from fast enough. Surely, the type of work I perform taints my experience.

Why They are Ineffective?

The primary reason the postmortem's fail is lack of executive commitment. Without the organization's management being behind the spirit of the retrospective and implementing the suggested changes, they are a waste of time. The event becomes drudgery. Attendees thoughtlessly answer questions while texting their friends or thinking about other tasks they have to perform.

In one retrospective, management told me not to use the project's audit report as a source of data and the facilitator restricted my comments to one item. The team quickly realized there was a gag order on the person that had fixed the project and concluded the meeting was to check off the box that the task was complete rather than to identify problems to resolve.

The next most common reason is lack of funding. Either there was no funding at the beginning of the project or to complete it budgets were trimmed to exclude anything that would not directly generate the deliverable. The concept of a retrospective was lost long ago.

Of course, there is the apathy component. No wants to prolong the pain by reviewing everything that went wrong. It puts salt in the wound. If this is a problem, try holding the postmortem at a bar. For some reason everyone becomes talkative.

Finally, apprehension will kill any objective involvement. No one wants to go into a meeting where they may be identified as part of the problem. Even though a properly run meeting does not assign blame, in companies that insist on finding fault, people will protect themselves and peers and the postmortem becomes a finger-pointing, interdepartmental blame game.

Are my observations isolated? I am afraid not. Last year, while writing my book, I read The Mythical Man-Month by Fredrick Brookes. The number of colloquialisms originating in the book surprised me—"there are no silver bullets," "How do projects become a year late? One day at a time," and "The Second System Effect." As I read through the development of the IBM 360 architecture, I was bewildered at the number of problems that he describes on a project in the mid-sixties—when I was a pre-teen—that are 100% applicable today. As the saying goes, the first kick by a mule is educational.  If we have not learned from these lessons, how are we going to learn from our own problems?

A Different Approach That Works

Looking at these reasons above for why retrospectives fail, all of them have a common thread of management's attitude toward the retrospective. However, rather than try to change the attitude on the lessons learned process, focus your efforts on changing the culture of management as a whole. Management must proactively accept promoting change throughout the organization.

The solution is to make problem identification and resolution part of the recovery. Reflecting back on the article Recovering Projects in Four Easy Steps, you will see that the application of corrective actions is the first part of the Execute phase. This is critical since trying to run the project without fixing the problems that effect it is... well... silly. Anytime you find a problem, fix it; do not wait until the end of the project. Waiting prolongs the pain and probably will result in the problem never being addressed.

For example, in the article How Many Problems, there were three root causes generating nine major failure symptoms. Only one had to be fixed for the project to continue—defining the system's end user. The other two—improving executive management involvement and creating a maintenance group—were solved in parallel with the project. As might be expected, all three of these were intertwined in the failure. The fact that the end user was undefined was a failure of the project; however it also indicated that the PMO was not reading project charters. If they had, they would have seen two diametrically opposed end users.

During the audit, the head of the PMO was asked if the charter conformed to their standards. He indicated it did. When asked if the end user was correct, he reply was that the PMO did not have the expertise to understand whether document content was correct. I concluded they simply checked off the box that the charter had the correct sections. The recommendation to the CIO was that the people in the PMO either add value by reviewing the content or the PMO be disbanded. He implemented the former. Without doing this, the problem would happen on subsequent projects. Another half-dozen changes were also implemented in the CIO's executive committee.

What Are Your Experiences?

Now it is your turn. Have you had a great experience with a retrospective? Tell us about it.

  • What was it that made it work?
  • What kind of problems were identified and solved?
  • What techniques were used to make sure no one felt blamed?
Delicious Delicious
Add to Technorati Favorites


Tags: , , ,

Previous Blog Next Blog


+1 # Guest 2010-06-06 22:58
Fortnightly retrospectives throughout the project are working well, although often painful while in progress.
+1 # Guest 2010-06-07 04:26
As much as I would like to construct a counter-point, my experience indicates that this is often true, as described in the article.

Quick observations -

"Task saturation is the enemy" is true and is often part of the reason that post-mortems do not always lead to meaningful outcomes. It is a challenge to create a group of technologists whose role permits them to see trends and think through how to effect major change on issues that show themselves time and again.

Secondly, a group I was in researched how the military does post-mortems within the Air Force, which are required after each flight. One interesting aspect of what they do is, prior to entering a room for a post-mortem, to remove their insignia which designates rank. The result is that each person establishes a level of equality with one another so that the discussion can proceed without concern to the chain of command.

It leads to frankness that might not be there otherwise.

In summary, I agree with the article, but also believe few things hold as much promise as a strong culture of learning from one's lessons.
+1 # Guest 2010-06-07 05:30
My experience seems to match yours, Todd. I cannot recall an effective project Post Mortem that I led or have sat through. However I think there are plenty of events that should have a post mortem. The thing is, the post mortem has to happen as soon as the problem occurs so the project team can adapt for the rest of the project, it should be focused on the specific item that went wrong. The typical lessons learned, occurring weeks or maybe months after an event is just not effective.
0 # Guest 2010-06-07 22:54
Agree with all of the comments above. One thing that has worked (along with the periodic reviews that Craig mentions) is we do a "what worked, what didn't work" at the closure of each workstream. That way we can apply lessons to remaining parts of the project/programme. If nothing else, it serves a teaching aid for all project participants for future projects.
0 # Guest 2010-06-08 03:53
I disagree wholeheartedly. Post-project reviews can and do work.

What you have seen are post-project reviews gone wrong. Some people turn the post-project reviews into a game of "blame and shame". They focus on everything that has gone wrong in the project, and try to assign guilt.

These types of post-project reviews do not work well, but there is an alternative.

If you focus your post-project reviews on:

1. What went WELL and what you can REPEAT
2. What could be IMPROVED and what you hope to do DIFFERENTLY NEXT TIME

then you can get tons of useful lessons from every project.

I also believe that these types of conversations should not wait until the project end. I try to collect these ideas continuously. I just do a special meeting at the end of the project to review all my observations and ideas with the team, and to gather any that they might have seen and which I might have missed.

In a lot of ways we do agree. I agree with you that the problem is an attitude problem. I disagree with your solution, however.

I do tackle the issue of "attitude" during my post-project reviews. I tell people what their attitude should be, I design the meetings so that we are focused on positive, constructive ideas, and I stop the meetings if they turn into "blame and shame" sessions. This has worked very well for me.
0 # Guest 2010-06-09 12:45
I think this is largely a self-fulfilling phenomenon. That is, when the management culture is one that promotes change and improvement the projects usually go at least "OK", whereas those cases where the project is a complete disaster are usually those where management is more concerned with appearances than with improvement.

My experiences range across the spectrum - I have frequently commissioned PMs and found them very valuable, but only when I had the power to implement change. I've also sat through a number of PMs where no change was wanted, and the whole purpose was just to check a box.
0 # Guest 2010-06-10 06:20
I agree that one of the reasons postmortems don't work is a lack of support from leadership level, however that doesn't mean we shouldn't do them. Postmortems are critical if we want to learn and improve processes. In fact, they are even more important after a failed project or one that has struggled.

Of course, depending on the leadership in your organization, an effective postmortem could be problematic, but I have found them to be a great tool to learn more about what's working and what isn't working in our project management methodology.

Thanks for the thought-provoking post.
0 # Todd C. Williams 2010-06-10 06:32
Thank you for all the great input.

It would seem to me that the general consensus is that waiting to the end to solve the problem is too late. In that, we seem to all agree.

I need to point out Paul’s, comment about “self-fulfillment.” Management that is open to change will not get into the big issues that cause projects to crash and burn. That has been the subject of a couple of other articles. I just hope the managers closed to change are reading articles like this and… oops, I think that is also self-evident.

The high-level concept of waiting for something to "die" seems a little late to fix it.

Cheers, Todd
0 # Guest 2010-06-18 13:05
To a certain degree, I find myself nodding in agreement with your assessment, Todd. However, my experience has also shown that if you add one crucial ingredient to the mix it suddenly holds value and becomes more effective.

That missing ingredient, as you alluded to, is buy-in from Management. If one is lucky enough to work in an environment where such a thing exists, then you immediately find that participants are more able to submit useful feedback and, gods forbid, receive some sort of follow-up from the project's management.

From my perspective (QA and Quality Management), there is hardly a more useful tool to come out of a completed project than a thorough Lessons Learned write-up. This assumes, of course, that there is some sort of continuity between projects as well as with personnel resources. A lot may be lost in translation where turnover (or excessive contracting) is involved.

I will give you that this sounds like a semi-utopian environment in this day and age, but the willingness of the players as well as sponsorship (or at least buy-in) from Management can make this a very worthwhile exercise.
0 # Guest 2010-07-08 07:34
If future projects don't learn from the lessons, there's no point in recording them. I can recall very few projects that analyzed retrospectives from previous projects. Sure, the disasters are avoided and the very best practices are adopted, but that is mainly because those had become legend and the organizations adapted asynchronously to any particular project.

It's the old tree falling in the woods, and if there's nobody to hear the lessons learned, then no wonder nobody supports recording them with any rigor, especially executive management.
0 # Guest 2010-07-22 19:29
I respectfully disagree with the article, Todd. That said, my first point would be that you only get value if you are analyzing something you'll be doing again. There is less reason to review a one-off project than something you'll be doing again and again. Second, a review shouldn't be a Blame Game. It should look at the Good, the Bad, and the Ugly.

What did we do right? Remember that so we can do it again. What went wrong? Was it beyond our control or something that can be planned for next time? What could've been done differently? If the focus isn't on what went wrong, but on how to do better next time a "post mortem" has a lot of value.
0 # Guest 2010-08-16 19:00
We used a great AAR system in the Army.

Every staff section was to list three items that were effective to reinforce and three than were ineffective.

Then during the next exercise they were posted on the wall and anyone could say, "Wait, someone deemed that ineffective, why are we doing it again?"

Currently comment rights have been restricted to registered users only. Please try registering and logging on.

Who's Listening To Us...

Fortune/CNN Money logo
Forefront's logo
Logo Oregonian/OregonLive
Enterprising CIO's logo
Slashdot's logo
The CEO Magazine's logo

Read and Hear More...

Visualize Your Future

Change how you do business.

Project Failure Insight:

The following blogs regularly have articles on project failure, recovery and good management practices.
Chris Curran
CIO Dashboard
Michiko Diby
Preventing Project Failure
John Estrella
Dr. John A. Estrella's Blog
Mike Krigsman
IT Project Failures on ZDNet
John F. Moore
Random Thoughts of a Boston-based CTO
Roger Sessions
Simple Architectures for Complex Enterprises

Looking to buy the internationally acclaimed Rescue the Problem Project?

Image of RPP

For a signed and personalized copy in the US visit the book's website.

Not in the US? Try one of these book stores worldwide

Amazon logo
Book or Kindle
Flag of the United States
United States

Flag of Canada

Flag of the United Kingdom Flag of Ireland
United Kingdom

Flag of Germany

Flag of France

Flag of Italy

Flag of the PRC
Flag of Japan
Barnes and Noble Logo
Book or Nook
Sony Reader Store logo
Sony Reader
Worldwide: Many other
book sellers worldwide.

Recent and Upcoming Events

Suggested Books

Many of these books have reviews in the "Books to Read" section of this site.

The Toyota Way
by Jeffery Liker

Related Items