The best way to conduct an IT postmortem

Project postmortems not only achieve continuous process improvement; they also enable continuous knowledge improvement

Dear Bob ...

You published a couple of pieces in which you promoted postmortems on projects and other activities, and seemed to endorse analysis paralysis (see "The paths you didn't take" and "Lack-of-analysis paralysis").

[ Get sage advice on IT careers and management from Bob Lewis in InfoWorld's Advice Line newsletter. ]

Seems to me we should be shooting for the following:

  • During a project, let's make sure we understand the root cause of all issues.
  • As we close a project, let's list what we have learned.
  • As we open a new project, let's ensure that we do not repeat the mistakes of last time.

I think you need to distinguish between analysis paralysis -- that is, continuous analysis with no intention on moving forward -- versus understanding root cause and applying lessons learned.

- Unparalyzed

Dear Unparalyzed ...

There's a subtle distinction to be made here, which starts with the recognition that the root-cause/don't-repeat-mistakes approach often isn't based on an underlying detailed model of the overall system. Without that systems model, there's no good way to predict the impact of any proposed change; what appears to be a mistake might easily turn out to have been the least of the available evils instead.

The approach I've been discussing differs from yours as follows:

  1. Start with a detailed model of how things work.
  2. Build a methodology based on that model.
  3. During a project, keep track of what doesn't happen the way the model predicts things should happen.
  4. During the debrief, discuss how the model needs to be changed to account for the occurrences it failed to predict.
  5. During the debrief, determine how the methodology needs to change based on the improved model.

It's steps 1 and 4 that generally don't occur in the standard approach to continuous improvement.

- Bob

This story, "The best way to conduct an IT postmortem," was originally published at