Teams, die einen Misserfolg ihrer Projekte simulieren, verbessern ihre Fähigkeit Fehlerquellen und Risikofaktoren zu identifizieren um 30%. Zu diesem Schluss kommt eine Studie von Deborah Mitchell, Jay Russo und Nancy Pennington, welche bereits 1989 zu “Prospective Hindsight”, zu Deutsch “Vorausschauender Rückbetrachtung” forschten.

Dieser Studie nahm sich der Entscheidungsforscher Gary Klein an und entwickelte eine Methode um Projekte noch vor dem Start auf Schwachstellen und Risiken zu untersuchen: das Premortem.

Pre- Was?

Es kommt wahrscheinlich jedem bekannt vor: Ein Plan, der auf dem Papier erstmal großartig aussieht, verläuft in der Praxis nicht so reibungslos, wie erwartet. Das kann beispielsweise bedeuten, dass ein Projekt länger dauert als geplant oder eine Softwareänderung unerwartete Betriebsprobleme verursacht. Wenn solche Situationen auftreten, wird in der Regel nach der Problembehebung ein Treffen mit allen Beteiligten einberufen, um die Ursache für das unerwartete Problem zu ergründen. Dieses Treffen ist vielen als Postmortem bekannt, ein Begriff der ursprünglich aus der Medizin kommt, zu Deutsch so viel wie “nach dem Tod” bedeutet und eine Analyse beschreibt, die Todesursache eines Patienten klären soll.

Wie der Name vermuten lässt, dreht das Premortem diesen Spieß um: Noch bevor das Projekt überhaupt in die Umsetzung geht, wird ein Termin mit allen relevanten Personen einberufen. In diesem wird das fiktive Szenario angenommen, dass das Projekt bereits katastrophal gescheitert sei. Nun bemüht sich das Team darum herauszufinden, welche Ursachen zu diesem Fehlschlag geführt haben könnten.

Wann sollte ein Premortem stattfinden?

Bei einem Softwareprojekt kann es zu Komplikationen auf unterschiedlichsten Flughöhen kommen, sei es bei weitreichenden Entscheidungen, wie beispielsweise einem Architektur-Entwurf oder der Wahl eines Cloud Anbieters und dessen Integration, oder bei Entscheidungen die auf Team-Ebene getroffen werden, wie ein API-Design oder dem Entwurf einer neuen Funktionalität. Ein Premortem kann immer durchgeführt werden, bevor ein konkretes Projekt umgesetzt, oder wenn eine wichtige Entscheidung getroffen werden soll. Unabhängig von der Art des Vorhabens ist es jedoch wichtig, dass bereits ein Umsetzungsplan existiert, da genau dieser mit Hilfe des Premortems verbessert werden soll. Falls noch kein Plan existiert, sollten ein oder zwei Beteiligte einen konkreten Umsetzungsplan für das Projekt zur Vorbereitung des Termins schreiben.

Wer sollte teilnehmen?

Ein Premortem ist keine ausschließlich für Entwickler*innen bestimmte Veranstaltung und ist auch nicht auf ein bestimmtes Team oder eine Arbeitsgruppe beschränkt. Teilnehmen können alle Personen, die entweder aktiv an der Umsetzung beteiligt sind oder Stakeholder und Mitarbeiter*innen aus anderen Bereichen, welche über besonderes Fachwissen oder umfangreiche Erfahrung im betroffenen Bereich verfügen. Zu guter Letzt sollte auch ein Moderator oder eine Moderatorin anwesend sein, der/die zum einen den Rahmen für eine offene und geordnete Diskussion schafft und zum anderen die Teilnehmer*innen darin unterstützt den Fokus des Termins zu wahren und die Gespräche in eine produktive Richtung zu lenken.

Durchführung

Auf welche Art und Weise ein Premortem durchgeführt wird, ist nicht in Stein gemeißelt und lässt sich je nach Stadium und Anwendungsbereich anpassen.

Der ursprüngliche Erfinder des Premortems, Gary Klein, schlug vor, die Teilnehmenden in zwei Gruppen aufzuteilen. Die eine Gruppe stellt sich vor, das Projekt sei um Welten besser gelaufen als erwartet und die andere Gruppe nimmt an, dass das Projekt katastrophal gegen die Wand gefahren sei. Beide Gruppen schreiben nun Handlungspunkte auf, die das Team getroffen haben könnte um jeweils das eine oder das andere Ergebnis herbei zu führen.

Je nachdem wie viele Personen am Premortem teilnehmen und wie viel Zeit man sich nehmen möchte, kann man den Termin auch nur auf die “negative Sicht” beschränken. Es folgt ein Beispiel, wie ein Premortem ablaufen kann.

Phase 1: Vorstellung des Umsetzungsplans

Der erste Schritt ist ziemlich selbsterklärend. Damit ein gemeinsames Verständnis für das Projekt und dessen Umsetzung herrscht, wird es für alle noch einmal vorgestellt. Hierzu kann ein konkretes Softwaredesign oder ein Migrationsplan zählen, aber auch eine Teststrategie ist ein wichtiges Kriterium, da dies Auskunft darüber gibt, wie gut das Problem bereits verstanden und behandelt wurde. Müssen anschließend noch Verständnisfragen geklärt werden, sollten Diskussionen zu diesem Zeitpunkt dennoch möglichst vermieden werden. Es empfiehlt sich außerdem auch explizit zu benennen worüber man in diesem Termin nicht sprechen möchte um den Umfang der Diskussion einzugrenzen und einen klaren Fokus zu schaffen.

Phase 2: Problemquellen finden

Nun stellt sich jeder der Teilnehmenden vor, dass Projekt sei bereits gescheitert. Hierbei wird kein konkretes Szenario vorgegeben, sondern es bleibt jedem Teilnehmer und jeder Teilnehmerin selbst überlassen, wie ein Fehlschlag des Projektes für ihn oder sie aussieht. Hierzu kann - und soll - sich auch am vorgestellten Umsetzungsplan orientiert werden um spezifische Schwachstellen in diesem zu finden. Es können jedoch auch vollkommen neue Aspekte mit eingebracht werden, da diese eventuell nicht im Plan berücksichtigt wurden.

Nachdem jeder der Teilnehmer*innen seine oder ihre Gründe aufgeschrieben hat, werden diese kurz der Reihe nach vorgestellt. Diese Phase wird noch 1-2 mal wiederholt, sodass jeder sowohl seine eigenen initialen Kritiken loswerden kann also auch neue Gedanken einbringen kann, die durch andere Angestoßen wurden.

Phase 3: Strategien entwickeln

Nach dem nun alle Gedanken zu Papier gebracht wurden und die analoge oder digitale Wand voll mit Zetteln ist, gilt es jetzt, konkrete Handlungspunkte zu entwickeln. Wie dieser Prozess aussieht kann je nach Anwendungsfall unterschiedlich aussehen, es empfiehlt sich jedoch die gesammelten Ideen zu ordnen und in eine Reihenfolge zu bringen, in der man sie besprechen möchte. Über die Kritikpunkte, deren Konsequenzen bei Nicht-Erfüllung am dramatischsten wären sollte zuerst gesprochen werden, und für diese konkrete Handlungspunkte abgeleitet werden.

Fazit

In Zusammenfassung lässt sich festhalten, dass das Premortem ein äußerst wertvolles Werkzeug ist, um potenzielle Schwachstellen und Risiken in Projekten frühzeitig zu erkennen und anzugehen. Allerdings ist der Erfolg dieses Ansatzes stark von einer sorgfältigen Vorbereitung und einer offenen, konstruktiven Teamatmosphäre abhängig. Eine klare Projektvision und ein Umsetzungsplan sind unerlässlich, um die Diskussionen im Premortem zielführend zu gestalten.

Während des Premortem-Termins sollten alle Teilnehmenden ermutigt werden, ihre Bedenken und Ideen ohne Zurückhaltung zu äußern. Es ist wichtig, einen erfahrenen Moderator oder eine erfahrene Moderatorin einzusetzen, um den Fokus zu wahren und sicherzustellen, dass alle relevanten Aspekte beleuchtet werden.

Am Ende dieses Prozesses werden die Teilnehmenden nicht nur besser darauf vorbereitet sein, potenzielle Risiken und Herausforderungen zu bewältigen, sondern auch ein tieferes Verständnis für das Projekt und seine möglichen Auswirkungen haben. Dies trägt maßgeblich dazu bei, erfolgreichere Projekte, zufriedenere Mitarbeiter*innen Kunden und Kundinnen oder Stakeholder zu gewährleisten. Das Premortem ist somit ein mächtiges Werkzeug, das in jedem Projektmanagement-Arsenal seinen Platz verdient.

Quellen

Back to the future: Temporal perspective in the explanation of events; Mitchell, Russo, Pennington (1989)
Daniel Kahneman’s Favorite Approach For Making Better Decisions (https://fs.blog/kahneman-better-decisions/)
Performing a Project Premortem, Klein (https://hbr.org/2007/09/performing-a-project-premortem)