Projektmanagement: Aus Fehlern lernen dank Post-Mortem-Kultur

Inhaltsverzeichnis

Fehler passieren – das ist eine Tatsache, die man akzeptieren muss. Bei Projekten, die eine Null-Fehler-Kultur angeben, kann man davon ausgehen, dass über Fehler geschwiegen wird. Das erzeugt auf lange Sicht ein Klima der Angst und hemmt das Unternehmen in allen Bereichen. Es wird selbst bei simplen Entscheidungen viel Zeit mit Change-Prozessen verbracht, die durchaus sechs Monate benötigen können.

Als Tool zur systematischen Analyse von Fehlern tauchen Post Mortems regelmäßig auf. Darin werden die Abläufe analysiert, die zu einem Fehler geführt haben. Ziel eines Post Mortems ist es, alle Aspekte eines Fehlers zu verstehen und Maßnahmen umzusetzen, ihn künftig zu vermeiden.

Zu den bekannten Vertretern der Post-Mortem-Analyse gehört die Veröffentlichung von GitLab aus dem Jahr 2017. Inzwischen gibt es weitere Firmen, die ihre Post Mortems veröffentlichen und damit die offene Kommunikation mit ihren Nutzern und Kundinnen suchen.

In der Praxis zeigt sich, dass ein sinnvoller Umgang mit Fehlern ein weitaus besserer Weg als das Verschweigen ist. Die erste wichtige Erkenntnis ist, dass Fehler weder schlecht noch gut sind. Der Umgang mit ihnen entscheidet darüber, ob sie sich positiv oder negativ auf Projekte auswirken.

Wichtig ist, zu verstehen, wie Fehler entstanden sind und auf welchen Entscheidungen sie gründen. Kompliziert wird es jedoch spätestens in der Zusammenarbeit. Wie schaffen es Teams, dass alle Kolleginnen und Kollegen mit gleichem Erfolg lernen, und wie lassen sich Prozesse, die für einzelne Personen funktionieren, auf das ganze Team übertragen?

Was wir von Toyota lernen können

Mit dem Ende der New Economy, als die tayloristische Massenproduktion abgelöst wurde und Wachstum nicht mehr grenzenlos zu sein schien, begann Toyota in den 1950er Jahren aus der Not heraus Lean Production zu entwickeln – die schlanke Produktion, die bis heute weltweit als Benchmark für produzierende Unternehmen gilt. Ursprünglich in Krisenzeiten entwickelt, folgen Toyota-Prozesse dem Prinzip der inszenierten Dauerkrise und setzen auf schlanke Produktionsprozesse und Fertigung nach dem Pull-Prinzip: Das Unternehmen produziert ausschließlich, was bestellt wurde. Somit stellt es alles nach dem Just-in-Time-Prinzip her und gewährleistet dabei einen reibungslosen Produktionsfluss.

Mitarbeiter oder Mitarbeiterinnen von Toyota, die in der Produktion einen Fehler feststellen, können die gesamte Produktionsstraße anhalten, um die Ursachen zu ermitteln. Ziel ist, das Problem dauerhaft auszumerzen. Die Qualitätsstatistiken geben dem Autobauer recht: Toyota ist die ungeschlagene Nummer eins bei der Kundenzufriedenheit.

Viele nehmen das Konzept der Lean Production als mechanischen Prozess wahr, den sie nur kopieren müssen, um erfolgreich zu sein. Den entscheidenden Punkt übersehen sie dabei häufig: Der einfache Bandarbeiter, der in der Lage ist, die gesamte Produktion anzuhalten, hat weitreichende Handlungsbefugnisse und ihm wird ein hohes Maß an Vertrauen entgegengebracht. Dafür muss der Arbeiter sicher sein, dass sein Handeln keine negativen Konsequenzen für ihn hat – weder von den Vorgesetzen noch von den Kolleginnen und Kollegen. Damit hat Toyota mehr erreicht als einen rein mechanischen Prozess zu entwickeln: Das Unternehmen bietet allen Mitarbeitenden ein hohes Maß an psychologischer Sicherheit.

Der Rückhalt und das Vertrauen im Kollegium und in Bezug auf die Vorgesetzten ist auch in der Softwareentwicklung der mit Abstand wichtigste Teil einer guten Fehlerkultur.

Psychologische Sicherheit als Grundpfeiler funktionierender Teams

Google hat vor einigen Jahren mit dem Project Aristotle den Sachverhalt untersucht. Die Ergebnisse sind erstaunlich ähnlich zu den Erkenntnissen der Lean Production. Sie unterstreichen die Annahme, dass psychologische Sicherheit der Grundpfeiler gut funktionierender Teams ist. Es geht darum, dass Teams offen miteinander umgehen können und alle nach Hilfe fragen können, ohne negative Reaktionen zu ernten. Fehler werden verziehen und zum Lernen genutzt. Kommunikation findet auf Augenhöhe statt.

Das zeigt, dass vor allem das Mindset entscheidend ist und einfache technische Prozesse allein nicht helfen. Damit bleibt die Frage, wie es in dem Kontext hilfreich ist, den Fokus auf eine positive Fehlerkultur und Blameless Post Mortems zu legen.

Ein Sündenbock hilft nicht

Teams müssen vorbereitet sein und einen Plan haben, um angemessen auf Fehler reagieren zu können. Neben der technischen Ebene ist ein Verständnis des soziotechnischen Systems wichtig, also der Interaktion zwischen Menschen und Maschine: Was haben die Projektbeteiligten dazu beigetragen? Wie wirkt das Ganze auf sie?

Für die Umsetzung im Team ist eine vertrauensvolle Zusammenarbeit nötig: Nur wer darauf vertrauen kann, nicht zum Sündenbock zu werden, ist bereit, Fehler zu berichten und im Team zu teilen. Außerdem ist der richtige Fokus bei Fehlern entscheidend. Die Fehler der Menschen sind in der Regel nicht die Ursache eines Problems. Fehlerquellen können vielmehr Architekturen, Prozesse, Tools, Dokumentationen oder Verhaltensweisen sein, die in der Unternehmenskultur gründen.

Eine Post-Mortem-Analyse ohne Schuldzuweisungen sucht keine Sündenböcke. Stattdessen sollte man davon ausgehen, dass jedes Team und jeder Mitarbeitende mit den besten Absichten gehandelt hat – basierend auf den Informationen, die zu dem Zeitpunkt zur Verfügung standen. Das fördert eine Kultur des Lernens und verbessert die Leistung im Laufe der Zeit.

Sprich über deine Fehler – ohne Schuldzuweisungen

Systeme werden nur sicherer, wenn alle Beteiligten offen über Fehler und deren Entstehung sprechen können. Dieses Prinzip einer Blameless Culture ist in Bereichen wie der Luftfahrt oder der Medizin schon länger bekannt. Dort gilt ein Fehler als Möglichkeit, das System zu stärken. Auch IT-Unternehmen wie Google oder Etsy haben deshalb für die systematische Analyse von Fehlern sogenannte Blameless Post Mortems etabliert. Sie helfen dabei, systematisch die Ursachen eines Fehlers zu finden und Maßnahmen zu beschließen, um ihn in der Zukunft zu vermeiden.

Im Rahmen des Post Mortem wird bei jedem größeren Fehler ein Blameless-Post-Mortem-Protokoll (BPM) angefertigt und im Wiki für alle Mitarbeitenden bereitgestellt. Wichtig ist, nicht nur über das zu berichten, was zur Lösung geführt hat, sondern vor allem darüber, welche Maßnahmen nicht hilfreich waren und warum. Damit lässt sich das Wissen festigen und auf andere Projekte übertragen. Es handelt es sich also um eine ganzheitliche Retrospektive, die je nach Unternehmen variieren kann, generell aber in vier Phasen aufgegliedert wird:

1. Entdecken der Störung und Erstellen des BPM

An der ersten Phase sind alle Kolleginnen und Kollegen beteiligt, die direkt an der Störung arbeiten. Ziel ist es, während der Störungsbearbeitung alle Informationen und Abläufe möglichst genau festzuhalten. Dementsprechend ist es sinnvoll, das BPM zeitnah zu starten. In das Protokoll können Chatprotokolle, Screenshots, genutzte Admin-Tools, Logmeldungen und Fehlermeldungen einfließen. Je detaillierter man im ersten Schritt Informationen sammelt, umso besser kann man in den späteren Phasen arbeiten.

2. Probleme identifizieren

Nach dem Zusammentragen der Informationen zieht das Projektteam bei Bedarf weitere Expertinnen oder Experten hinzu. Die Gruppe analysiert Dokumentationen und Codes und stellt Konzepte auf die Probe. Dabei schaut sie nicht nur auf die technischen Details, sondern studiert daneben die organisatorischen Abläufe. Ziel ist es, alle Sachverhalte zu finden, die zur Störung beigetragen haben können.

3. Diskussion

In der dritten Phase setzt sich die gesamte Abteilung wöchentlich zusammen, um ein ausgewähltes BPM zu diskutieren. Das verantwortliche Team stellt seine Dokumentation des BPM vor, erklärt die Abläufe, die gefundenen Probleme und die angestrebten Lösungen. Dabei entsteht gemeinsam die Auswahl der umzusetzenden Korrekturmaßnahmen. Gelegentlich kann man auf Lösungsansätze anderer Teams zurückgreifen.

4. Abschluss

In der letzten Phase geht es darum, die Lösungsansätze in ein Ticketsystem zu überführen, die Planung vorzunehmen und letztlich die Verbesserungen umzusetzen.