The best way to conduct an IT postmortem
Project postmortems not only achieve continuous process improvement; they also enable continuous knowledge improvement
Follow @ITCatalystsDear 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:
- Start with a detailed model of how things work.
- Build a methodology based on that model.
- During a project, keep track of what doesn't happen the way the model predicts things should happen.
- During the debrief, discuss how the model needs to be changed to account for the occurrences it failed to predict.
- 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 InfoWorld.com.
