In diesem Artikel möchte ich die Post-Mortem-Methode vortellen. Mithilfe eines Post Mortems beschreibt man Ereignisse aus der Vergangenheit, um daraus für die Zukunft zu lernen.

Es handelt sich um eine Methode aus dem Projekt- und dem Wissensmanagement. Die Methode wird unter anderem in der IT verwendet und dient der Dokumentation von Ereignissen von Relevanz.

Inhaltsverzeichnis

Der Post-Mortem-Report

Inhalt

In diesem Abschnitt soll der Inhalt eine Post Mortems beschrieben werden. Es enthält folgende Punkte und dazugehörige Fragen1:

  1. Ereignisbeschreibung:
    • Was ist passiert?
    • Welche Personen waren betroffen?
    • Welche Dienste waren betroffen?
    • Gibt es sonst noch Wissenswertes?
  2. Ursachenanalyse:
    Was war die Hauptursache des Ereignisses?
  3. Handlungen:
    Welche Maßnahmen wurden zur Diagnose, Analyse und Abarbeitung getroffen?
  4. Ablauf:
    Was ist in welcher Reihenfolge passiert?
  5. Zusammenfassung und nächste Schritte:
    • Was lief gut?
    • Was lief schlecht?
    • Was kann man besser machen?
    • Wie kann man zukünftig mit diesem Ereignis umgehen, falls es wieder auftritt?

Randbedingungen

In diesem Abschnitt sollen weiterführende Prinzipien beleuchtet werden. Eine Übersetzung erfolgt an dieser Stelle nicht. Folgendes sollte auch mit beachtet werden2:

  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.

Mike Gunderloy2

Das war es auch schon mit der kurzen EInführung in Post Mortems.

  1. frei übersetzt nach “5 Steps to Conduct an Incident Post-Mortem” https://alertops.com/five-steps-conduct-incident-post-mortem/ ↩︎

  2. nicht übersetzt nach “Nine steps to IT post-mortem excellence” https://www.zdnet.com/article/nine-steps-to-it-post-mortem-excellence/ ↩︎