Monday, June 9, 2014

Postmortem or postvitam?

I think there needs to be a meeting to set an agenda for more meetings about meetings. ~ Jonah Goldberg

I came across an article recently about how much time is wasted in meetings. I didn't have this problem much in my last job before retiring because I was known to have such a lousy attitude in meetings I generally got notified of a meeting but attendance on my part was voluntary. Now I could get away with this for two reasons. First, I was good at my job, so, while no one is indispensable, it was generally thought that firing me because of my attitude toward meetings would be more of a pain than it was worth. Secondly, when I was dragged into attending a useless meeting, I'd let the meeting organizer know before, during (especially during), and after the event how useless it was.

What this meant was that I generally only went to useful meetings like project status, problem resolution, or potential system change/addition/improvement discussions. It also meant I got a lot of regular work done.

It should be noted I was not alone in this attitude. My fellow system administrator felt the same way. While he was nicer about it, he made it clear he could either sit in meetings or keep the network up. We system administrators get away with a lot of stuff that way.

All that being said, there was one kind of meeting that was necessary but often not real useful, the postmortem. You know the situation. A project has flopped, or something bad happened that wasn't supposed to happen, so there's a meeting to try to figure out what went wrong and how not to do it again. These meetings all tend to be the same. If you try to fix responsibility for the problem, someone, usually the person who called the meeting, says we're not here to blame anyone, just to figure out what went wrong and prevent it from happening. Well, if Joe screwed up because he didn't follow procedures, what needs to happen is to agree that the procedures would work if followed. However, since we can't “blame” Joe, we end up changing perfectly good procedures into bloated messes – which Joe won't follow next time, either.

Seriously, this business of not affixing responsibility (rather than “blame”) frequently gets in the way of getting anything done. I've even tried to take responsibility for a failure myself and been told that we're not here to blame anyone. Fine, don't blame me, but realize I made a mistake and I know it and will try to avoid doing so in the future. We're done here, so let's go back to work.

Postmortems have a history of not really fixing anything. Would you care to estimate how many postmortem meetings have occurred at the various auto makers after recalls? I would bet whole bunches, but the recalls still happen because someone decided to go ahead and use a bad design or questionable parts, usually to save money.

NASA showed how successful postmortems can be by following the Challenger disaster with the Columbia disaster. One of the findings of the Columbia investigation is that NASA was still making the same mistakes they made that led to the Challenger debacle.

History shows that organizations simply don't learn from their mistakes. There are exceptions, but they are few and far between. So, since we aren't getting any benefit from postmortems maybe it's time to consider an alternative.

NASA has had many notable successes. The ones that come quickly to mind are the moon landings (which was not without it's stumbles along the way), the Voyager 1 and 2 missions, and the Mars rovers Spirit and Opportunity. Spirit finally gave up the ghost some time ago, but Opportunity continues chugging along several years past it's 90-day expiration date. So, the question is, does NASA have meetings to discuss what they did right on those missions?

I've had the good fortune to be part of few very successful major projects. None of them had a “success postmortem” to figure out why they did so well. Oh, there's often a wrapup meeting with goodies to eat and much patting on the back, but no one asks, “How come you guys got this done on time and on budget when so many IT projects fall on their face?”

Now you might say the answers to the question are obvious. The project has sufficient resources, well-defined requirements which didn't constantly change, and it was given the appropriate priority by the managers. In addition, the schedule was well-defined, any variations from the schedule were addressed quickly, and any problems that came up were also addressed quickly. Obvious stuff.

Well, if it's that obvious, why is it that the same organizations where the successes happened had projects that were dismal failures? Because one or more of the elements of success were ignored. And why was that? Because managers didn't pay attention to what those elements were.

Now, I can guarantee that some or all of the success factors came up during the postmortem, but they were brought up as failure factors and given alibis. Someone brought up the constant changes to requirements, but someone else excused these as needed. The real problem, of course, is that the project wasn't defined correctly to begin with. Someone brought up a lack of resources, but no one mentioned the real problem of a lack of commitment by managers to provide those resources or that the needs were underestimated at the start. Because of those problems the project went over budget, but the reasoning is that the budget wasn't big enough.

Now, if instead of focusing on the disasters, we would focus on successes, we would learn the factors for succeeding and make them the basis for future decisions in projects. So, we should have post-success meetings to drive these things home. Maybe if the factors that made things go right would be pounded into everyone's heads, there would be more successful projects. And, since going over success factors is quicker than slogging through all the reasons things flopped, those meetings would be shorter. Which would mean less time wasted in meetings.

A win-win situation if ever there was one.

No comments:

Post a Comment