If you’ve seen a cop drama in the last twenty years, odds are high you’ve watched a scene where the detectives and the coroner stand over a body on a stainless steel table. Give us the straight scoop, doc, how’d he catch it?, they say (at least if the show is in black and white, anyway). You think I’m a miracle worker? retorts the coroner. Come back tomorrow and I might – might be able to fill you in.
The TV never shows what the coroner actually *does* – rarely anyway – because A) it’s really gross, and B) more entertaining to watch the detectives chase someone down. But in the real world, the job the coroner does is critical to any crime investigation. How was the person killed? How tall was the killer? What hand did they use? What was the weapon? Etc, etc.
Now, failure in the IT world can be pretty ugly. Email went down. Phones went down. Files went missing. Revisiting those wounds isn’t always an easy thing to do. But if your IT group is healthy, and clicking on all cylinders, project and incident postmortems should be a regular part of your routine. There are, however, a few rules to follow.
Number One: let some time pass. This is tricky, because you have to walk a fine line between allowing enough time to pass to allow emotions to settle down, to let all parties (IT and non-IT) to return to normalcy, but also close enough to the event where everyone’s memory is clear about what happened. If you’re going to err, err on the side of waiting longer for cooler heads to prevail. By nature, a postmortem of a negative event has the potential to become emotional. Keep the personalities involved calm. This isn’t an opportunity to beat up on the guy who accidentally pulled the plug out of the wall. Use the postmortem as a learning event.
Number Two: have a set procedure, and follow it. What exactly happened? What could we have done to prevent it? What process needs adjustment, if any? Do the costs of implementing preventative steps outweigh the costs of the event happening again? Maintaining a format allows people to know what to expect, and maintains a sense of impartiality.
Number Three: maintain accountability. Not always possible, but don’t use a group setting of a postmortem to hide the fact that there’s a specific problem, or error, that occurred. This is especially critical when a postmortem includes another business unit. If it is the IT Group’s fault, take responsibility. Sugarcoating, or passing the buck, won’t help you get to that Trusted Partner status. This must be managed; postmortems are not a place for people to beat up on someone.
Number Four: follow up. If the postmortem conclusion has a specific action item (i.e., move patching from weekly to monthly), do it. If the p-m process becomes a show-and-tell display rather than a meaningful process, people will quickly learn to not approach it seriously.
Number Five – and perhaps the most important: do postmortems after every project, even successful ones. For successful p-ms, the tone and approach are different; more of a “what could we have done better” attitude. These are also a chance to give credit where credit is due.
If you think about it, the postmortem is really just an exercise that increases communication levels, be they internal to IT or with a business partner. Of course, it is difficult to conduct these when you’re running around putting out fires or running from one project into the other. As with all processes that are higher up Donahue’s Hierarchical Pyramid of IT needs, they rely on the fact that the lower levels are being adequately met. But postmortems are a key indicator that an IT group is in a good place.