Thursday, March 5, 2009


By now, at least, in the circles I run in, doing a postmortem after a release is a fairly common thing. We all get together in a room and discuss what went well and what didn't. We talk about what things we want to do in the same way, and what things we want to try doing differently.

We've started doing the same thing for major customer issues. While the issue is going on, just get through it - you're wabbit hunting! But once the issue is resolved and the customer is back up and running, consider having a postmortem.

Just like you can build software better, faster, more reliably, you can solve your customers problems better, faster, more smoothly. So get the team together - support, development, the account rep, and maybe even the customer - and see what you can learn. Questions to consider:
  • What could have prevented this from happening in the first place?
  • What is the customer's perception of how this issue was handled? Were they pleased? What would have made them more pleased with your handling?
  • What changes should be made in the product or in procedures that would have enabled earlier detection of the problem? More precise detection?
  • Could this problem have been caught internally? If so, what can we change to catch these types of problems before they get to a customer?
  • How disruptive was this issue internally?  Is there anything we can do to reduce that?
  • What is the "signature" of this problem? How will we recognize it if we see it again?
Not every issue needs a postmortem, but for the large customer problems, pausing after it's over to think about how to make it better next time can certainly prevent future headaches.

1 comment:

  1. Right on. Very useful. Thank you for posting.

    We do post-mortems along these lines for major issues, but it's always useful to get someone else's perspective.