Nine steps to IT post-mortem excellence

Nine steps to IT post-mortem excellence

Summary: Most IT project post-mortems are exercises in finger-pointing and assigning blame. Here are nine steps to make them useful.

SHARE:
TOPICS: IT Employment, CXO
7

Why IT failure post-mortems donÂ’t matter

Conventional IT wisdom holds that post-mortems are essential to ensuring future project success. Sadly, many corporate post-mortems are a waste of time, accomplishing little besides finger-pointing and assigning blame.

Here's what StickyMinds.com says about the post-mortem issue:

Most teams don't use postmortems. The teams that do don't always get value from them. Frequently, postmortems have a habit of either turning into "the blame game" or whitewashing mistakes. A bad postmortem can create dissension and institutionalize mistakes.

On the other hand, well-run post-mortems help a project team create a culture of continuous improvement. Embedding a culture of ongoing, positive change inside a project delivery organization is the best way to ensure long-term success.

Post-mortems are an important link in this chain of positive improvement.

Running a successful post-mortem isn't magic, although it does require thoughtful planning. Consultant Mike Gunderloy offers a list of nine steps to post-mortem excellence:

  1. Plan for post-mortems. To get the most value out of this activity, you need to take it seriously. The postmortem should be a scheduled activity, with time for a meeting of the team to discuss the lessons learned and time for someone (or some group) to write the postmortem report.
  2. Keep it close in time. Don't let memories fade by scheduling the postmortem too long after the end of the project. Ship the software, have the celebration, and then roll right into the post-mortem.
  3. Record the project details. Part of the post-mortem report needs to be a recital of the details of the project: how big it was, how long it took, what software was used, what the objectives were, and so on.
  4. Involve everyone. There are two facets to this. First, different people will have different insights about the project, and you need to collect them all to really understand what worked and didn't. Second, getting everyone involved helps prevent the post-mortem from degenerating into scapegoating.
  5. Get it in writing. The project manager needs to own the process of reducing the post-mortem lessons to a written report, delegating this if necessary.
  6. Record successes as well as failures. It's easy for a post-mortem to degenerate into a blame session, especially if the project went over budget or the team didn't manage to deliver all the promised features.
  7. It's not for punishment. If you want honest post-mortems, management has to develop a reputation for listening openly to input and not punishing people for being honest.
  8. Create an action plan. The written post-mortem should make recommendations of how to continue things that worked, and how to fix things that didn't work. Remember, the idea is to learn from your successes and failures, not just to document them.
  9. Make it available. A software post-mortem locked in a filing cabinet in the sub-basement does no one any good. Good organizations store the supply of post-mortems somewhere that they're easily found.

To summarize, make your post-mortem successful by carefully preparing in advance, analyzing the project systematically, producing actionable findings, and actively sharing the results.

Follow these steps and your next post-mortem will be one of the few that actually are useful.

[Image via Coding Horror.]

Topics: IT Employment, CXO

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

7 comments
Log in or register to join the discussion
  • Good Article, Bad Title

    I agree with your position and your content and suggestions. The title, however, is not reflective of the subject-matter. The article is about improving the post-mortems process, yet I was expecting to see an opinion piece about how they are irrelevant. Just my two cents...
    Gazanga
    • A fair point

      Thanks for commenting. I've changed the title to "Nine steps to IT post-mortem excellence."
      mkrigsman@...
  • The full quote

    Quoting:

    9. Make it available. A software postmortem locked in a filing cabinet in the sub-basement does no one any good. Good organizations store the supply of postmortems somewhere that they?re easily found.

    [End quote]

    The quote implicitly referenced:

    ... in the basement inside a locked filing cabinet in a disused lavatory with a sign saying Beware of the leopard.

    [End quote]

    Also appreciated is the reference to the "supply of postmortems". Somewhere there's a long shelf of reports with similar bindings, headed Great Books of Western Culture, starting with Aristotle and Plato.
    (I titled one stored report: Critique of Pure Reason.)

    Hide in plain sight where they'll never be investigated.
    Anton Philidor
  • We have forgotten how to learn..

    Surely the main reason for a post mortem is to review learning? If you have reviewed learning throughout the project then the post mortem should simply be a bringing together of all the points throughout the project. It should of course recognise what has been achieved whatever the result of the project.

    I see too many project managers and teams make the same mistakes over and over again; and they are all busy...maybe, just maybe if learning reviews were built into the project and then reviewed at the end some of these mistakes (and let???s not forget the positive stuff!) would be used again and again!!

    Just my thoughts on an important subject Michael

    Ron Rosenhead
    Project Agency
    ronrosenhead
    • Incentives to learn

      Good point, but why should they learn? Look at the economics: complete one project then move on the next, getting paid for both. Is there any financial incentive to improve? If not, then the cycle is bound to repeat, endlessly and fruitlessly.

      Thanks for commenting.
      mkrigsman@...
    • Yes, "postmortems" should be embedded in the project process

      Great point!

      If a project is very short--- a few months--- then you can wait till the bitter end and do one project postmortem. But if the project duration is of any significant length then:

      * There is too much to remember, so people only remember what happened in the last 1 or 2 quarters of the project or the most painful events.

      * You may be able to implement lessons learned in the next project, but the current project can?t benefit.

      * Chances are that your project really is composed of several projects. In addition, some projects morph into completely different projects when a project runs a long time. In any event, it becomes difficult to get a sense of which issues are relevant to certain types of projects or certain phases.
      elizab
  • In the end, is your company?s culture one of punishment ?.

    or one of "how can we do better?"?

    A lot of companies have a culture of punishment, so people are reluctant to tell you they screwed up when they screwed up; in fact, they hide it. Also, no one tells you, when "you" (the project manager) screws up. In either case, this means that the project manager learns about the problem too late, when only miserable options are available at a time when there is no running room in the project.

    The other thing is that when the culture is one of punishment, so much energy is devoted to defending oneself, that no one can get to the important issues such as:

    * Finding out what went wrong so history won't repeat itself during the remainder of the project or the next one

    * How might we be able to avoid a similar problem in the future

    * Getting every one focused on finding out a solution to the problem

    * Getting people to understand issues and ramifications of their actions

    * Getting people to take responsibility as opposed to avoidance

    This issue grows in degrees when you talk about THE postmortem. Everybody is focused on hiding, so you really have no lessons learned that you can employ on the next project.

    Even in the best of circumstances. it takes a lot of self-control to not meet out punishment, especially for projects of high visibility, in highly political cultures, when the company has a lot at stake.
    elizab