How many times have you been in a postmortem meeting where the “bad” items were no surprise to you? Where people sheepishly admitted, “Yeah, I guess we should’ve expected that would happen.”

To borrow some wisdom from a CTO friend of mine, “The problem is that you’re basing a plan around assuming that the code works.”

You have to assume that things will fail, and plan for how you’ll deal with it when it does happen.

Unfortunately, the temptation is to make project kickoffs focus on the positive. This is a great opportunity, we’re going to build great technology, our consumers will have a great experience, we’ll drive revenues. You need a little of that to rally the troops (after all, this projects usually mean lots of long hours and hard work).

But the “buzz” of a great kickoff is dwarfed by the huge morale hit that happens when projects go bad. Even if the company or customer’s success isn’t permanently harmed, teams can only take so many hits.

So get in front of the whiteboard with your cross-functional teams and assume the worst has already happened. It’s not being pessimistic, and it’s not demoralizing the troops. Quite the opposite - it’s empowering people to think about how to work smart and work collaboratively. Just like A Christmas Carol, these are the “shadows of things that may be” and there’s still time to make sure they don’t happen.

Some tips for holding a premortem meeting:

• Using notes from a past postmortem meeting, identify some likely risk areas to start discussion. Cluster them into functional areas (”operations”, “QA”, “customer management”, etc.)
• Insist upon at least one representative from each functional area. Be respectful of their time - scheduling the first half-hour for Operations, the next half-hour for QA, etc. It’s much easier for them to accept a half-hour meeting invitation than a two-hour one.
• For each risk area, talk briefly about what “happened” and the fallout (i.e. “We weren’t able to adequately test X functionality. As a result, there was a customer escalation and QA and sustaining had to spend their weekend rushing to create and certify a patch.”) This makes it real - this is what they are avoiding by taking the extra time to plan.
• Have a dedicated note-taker to ensure that you document actionable steps to prevent each premortem item. Send out meeting notes as soon as possible.
• Build your actionable steps into your project plan. You must allocate time for fire prevention in order to avoid fire-fighting later!

Tags: meetings, premortem

Category: Best practices   Comment: Add A Comment
Trackback URL: http://www.cindyalvarez.com/best-practices/more-premortem-less-postmortem/trackback/