Projektmanagement Autopsie am lebenden Projekt
Projekte scheitern erschreckend oft. Der Grund dafür ist, dass viele Mitarbeiter sich scheuen, ihre Bedenken zu äußern - und zwar zu einem Zeitpunkt, zu dem dies am wichtigsten wäre: in der Planungsphase. Würden Führungskräfte es Projektgegnern ermöglichen, ihre Einwände auszusprechen, ohne negative Folgen befürchten zu müssen, könnten sie die Chancen für einen Projekterfolg deutlich erhöhen.
1989 führten Deborah J. Mitchell von der Wharton School, Jay Russo von der Cornell University und Nancy Pennington von der University of Colorado Studien durch, bei denen sich zeigte: Die Fähigkeit, die korrekten Ursachen für ein bestimmtes zukünftiges Ereignis zu nennen, erhöht sich um 30 Prozent, wenn man Menschen dazu bringt, sich vorzustellen, das Ereignis sei tatsächlich bereits eingetreten. Wir haben diese Erkenntnis dazu benutzt, eine Methode zu entwickeln, die wir "Pre-mortem"-Analyse nennen. Diese Analyse soll Projektteams dabei helfen, mögliche Risiken für ein Projekt gleich zu Beginn zu identifizieren.
Eine Pre-mortem-Analyse ist quasi das Gegenteil der post mortem durchgeführten Autopsie. Durch die Leichenöffnung erfahren Ärzte und die Familie, woran eine Person gestorben ist. Jeder profitiert davon - abgesehen natürlich vom Patienten. Wir haben unsere Methode Pre-mortem-Projekt- analyse genannt, um den Gegensatz zu einer Post-mortem-Analyse zu betonen, also einer, die erst nach dem unrühmlichen Ende eines Projekts stattfindet und bei der es meistens vor allem darum geht, Schuldige zu finden.
Eine Pre-mortem-Analyse bedeutet, dass die Projektteams vor dem Beginn des Projekts eine fiktive Autopsie durchführen, um anschließend jene Verbesserungen einleiten zu können, die nötig sind, um das Scheitern des Projekts zu verhindern.
Anders als bei einer typischen Kritiksitzung, bei der die Teammit-glieder danach gefragt werden, was alles schiefgehen könnte, wird bei einer Pre-mortem-Analyse davon ausgegangen, dass der Patient schon tot ist, und die Frage lautet: Was ist tatsächlich schiefgegangen? Die Teammitglieder sollen plausible Gründe für das Scheitern des Projekts finden.
Zunächst muss das Team über das Vorgehen bei dieser Übung genau instruiert werden. Die Führungskraft beginnt, indem sie jeden Einzelnen davon in Kenntnis setzt, dass das Projekt grandios gescheitert ist. Im Anschluss schreiben alle im Raum unabhängig voneinander die Gründe auf, die ihrer Ansicht nach zu dem Misserfolg geführt haben. Dabei sollen die Teilnehmer besonders solche Dinge erwähnen, die sie normalerweise nicht als potenzielle Probleme genannt hätten - aus Angst vor Konsequenzen.
In einem Workshop, den ein "Fortune"-50-Unternehmen durchführte, ging es darum, so zu tun, als sei ein geplantes Milliarden-Umweltprojekt gescheitert. Woran hatte es gelegen? Eine Führungskraft gab als Grund an, das Interesse sei erlahmt, nachdem der CEO in Rente gegangen war. Ein anderer Manager sah die Ursache darin, dass die Vorbildwirkung des Projekts verblasst sei, nachdem sich die gesetzlichen Richtlinien geändert hatten.
In einem nächsten Schritt bitten die Führungskräfte jedes Teammitglied darum, einen der Gründe, die sie notiert haben, vorzulesen. Der Projektleiter macht den Anfang, anschließend fügt jedes Teammitglied einen weiteren
Grund hinzu, bis schließlich alle denkbaren Gründe aufgelistet sind. Nach der Sitzung geht der Projektleiter die Liste noch einmal durch, um zu sehen, wo der Projektplan Schwächen aufweist, die beseitigt werden müssen.
In einem Workshop wurde ein Projekt analysiert, bei dem es darum ging, einer militärischen Einheit neue Computeralgorithmen für die Planung von Manövern zur Verfügung zu stellen. Ein Teammitglied, das während des vorangegangenen Kickoff-Meetings auffallend still gewesen war, gab schließlich als möglichen Grund für das Scheitern an, dass die im Feld verwendeten Laptops für einen der Algorithmen nicht leistungsfähig genug waren. Entsprechend hatte die Software Stunden gebraucht, um die Daten zu verarbeiten, obwohl die Nutzer schnelle Ergebnisse gebraucht hatten. Dem Team wurde klar, dass das Projekt praktisch undurchführbar sein würde, wenn für dieses Problem keine Lösung gefunden wurde.
Es stellte sich heraus, dass die Entwickler der Algorithmen bereits eine neue Version programmiert hatten, die weniger Rechenkapazität benötigte. Sie hatten aber noch gezögert, diese zu erwähnen. Die neue Version wurde eingesetzt, und das Projekt wurde sehr erfolgreich.
In einem anderen Workshop ging es um die Bewertung eines Forschungsprojekts. Eine Führungskraft nannte als potenziellen Grund für dessen Scheitern, es habe zu wenig Zeit gegeben, einen Geschäftsplan zu entwickeln, bevor eine unternehmensweite interne Bewertung neuer Produkte stattgefunden hatte. Während des 90-minütigen Kick-off-Meetings zuvor hatte niemand diese Zeit-beschränkung auch nur erwähnt. Der Projektmanager revidierte schnell den Projektplan, um die Entscheidungsprozesse im Unternehmen zu berücksichtigen.
Viele Projektteams führen vorab durchaus detaillierte Risikoanalysen durch - doch die Pre-mortem-Analyse liefert wertvolle Hinweise, die andere Methoden nicht liefern können. Sie hilft Teams nicht nur, poten-zielle Probleme möglichst früh zu entdecken. Sie ist auch ein gutes Mittel, um jener Ignoranz gegenüber Gefahren zu begegnen, die Leute häufig an den Tag legen, wenn sie schon zu viel in ein Projekt investiert haben. Indem die Projektmitglieder Schwächen benennen, die sonst noch niemandem aus dem Team aufgefallen sind, können sie sich profilieren, und andere können von ihnen lernen.
Die Übung sensibilisiert Projektteams auch dafür, früh auftauchende Warnsignale sofort zu beachten und gegenzusteuern. Letztlich dürfte eine "Autopsie am lebenden Projekt" weniger schmerzhaft sein als die an einem gestorbenen. n
