Projektmanagement


Der passende Blickwinkel

Das richtige Krisenmanagement im Projekt

28. Januar 2016
Friedrich Behnk arbeitete als Softwareentwickler und Consultant in einer Unternehmensberatung, legte einen Zwischenstopp im Risikocontrolling in einer Privatbank ein und gründete ein Startup. Heute arbeitet er als freiberuflicher Projekt- und Testmanager.
Ein Pilot strebte mit seinem selbst gebauten Flugzeug nach einem Rekord und scheiterte tragisch. Der Unfall in der Schweiz weist viele Parallelen zu IT-Projekten auf. Das für die Luftfahrt entwickelte Krisenmanagementwerkzeug "Window of Opportunity" kann auch am Boden "Unfälle" im Projektgeschäft vermeiden.
Mit den richtigen Methoden Krisen erkennen und erfolgreich meistern.
Mit den richtigen Methoden Krisen erkennen und erfolgreich meistern.
Foto: Roll cloud - Friedrich Behnk

Was sollte auf keiner Agenda eines Teammeetings im Projekt fehlen? So lautet eine Frage für die Prüfungsvorbereitung zu einem international anerkannten Zertifikat für Projektmanager. Die korrekte Antwort ist die Diskussion von Projektrisiken. Wenn ich ehrlich bin, habe ich es bisher noch nicht erlebt, dass jede Agenda eines Teammeetings diesen Punkt explizit ausweist. Ich bin mir jedoch sicher, dass der erfahrene Projektmanager im Teammeeting sehr genau die Themen und Aussagen scannt und mindestens implizit potenzielle negative Risiken im Blick hat.

Im Bereich der See- und Luftfahrt gilt die Regel "Safety first". Zugegeben, in den meisten IT Projekten stehen nicht ganz so viele Menschenleben wie in der Luftfahrt auf dem Spiel und die Geschwindigkeit wird auch etwas langsamer sein. Ein effektives Risiko- und Krisenmanagement sollte jedoch in allen drei Bereichen ernsthaft betrieben werden.

Tragischer Flugzeugunfall

Für die Bereiche See- und Luftfahrt existieren staatliche Institutionen, die Unfälle mit dem Ziel untersuchen, wie diese in Zukunft vermieden werden können. Anhand des nachfolgenden Berichtes lässt sich sehr gut das Zeitfenster der Gelegenheit (Window of Threat and Opportunity) von Tony Kern erläutern. An dieser Stelle sei gesagt, dass ich keine Forderung nach einer Behörde für Projektunfälle stelle.

Am 23. Juli 2007 ereignete sich mit einem Flugzeug auf dem Stadtgebiet von Basel ein schwerer Unfall. Der Pilot, ein sehr erfahrener und risikobewusster Flugkapitän, widmete sich nach seiner Pensionierung der Aufstellung von Rekorden in der privaten Fliegerei. Sein letzter Rekordversuch sollte die zweimalige Umrundung der Erde über beide Pole mit seinem selbst gebauten Flugzeug sein.

Der Bau des Flugzeuges begann 2002. Der Start wurde für den Winter 2007/08 geplant. Im Winter 2006/07 wurde der Start auf den Juli 2007 vorverlegt. Zu diesem Zeitpunkt ergab sich eine Gelegenheit zusätzliche Sponsoren zu gewinnen.

Verzögerungen in der Bauphase und die Vorverlegung des Starttermins verkürzten die Erprobungsphase. Wegen technischer Mängel wurde der erste Starttermin um einige Tage verschoben. Am Tag des neuen Starttermins fand sich eine größere Anzahl von Menschen auf dem Flughafen ein. Medienvertreter waren anwesend. Erneut traten technische Mängel auf. Diese wurden teilweise mit Workarounds behoben. Die Freigabe zum Start wurde erteilt. Während des Starts kam es zu Komplikationen. Der Pilot hätte zu diesem Zeitpunkt den Start noch abbrechen können. Er brach nicht ab und überschritt damit den Zeitpunkt der letzten Gelegenheit.

Wenige Kilometer hinter der Piste kollidierte das Flugzeug mit einem Wohnhaus. Der Treibstoff entzündete sich und setzte das Wohnhaus in Brand. Der Pilot und Teile des Flugzeuges wurden auf den benachbarten Spielplatz geschleudert.

Analogien zum IT-Projekt

Zum Glück habe ich noch kein Projekt mit einer entsprechenden Dramaturgie erlebt. Die Zuspitzung der Ereignisse kommt mir in der einen oder anderen Form bekannt vor. Das Projekt startet. Die Erwartungen sind hoch. Im Verlaufe des Projektes nimmt der Erfolgsdruck kontinuierlich zu. Neue Erkenntnisse, marktbedingte Notwendigkeiten und so weiter sind ausschlaggebend für notwendige Anpassungen des Umfangs, des Zeitplans und/oder der Kosten. Häufig werden die Anpassungen nicht konsequent in das Projekt übernommen, sodass die Testphase darunter leidet. Das Produkt des Projektes ist nicht ausreichend getestet. "Der letzte Schliff kann auch im Betrieb erfolgen".

Kurz vor der Inbetriebnahme werden mit der "heißen Nadel" noch die letzten Löcher gestopft. Der Erfolgsdruck ist kontinuierlich hoch, der Projektmanager steht unter Beobachtung und der GoLive steht kurz bevor. Die Inbetriebnahme erfolgt hakelig und verspätet. Der Point of no return wurde überschritten. Im Betrieb stellt sich heraus, dass an diversen Stellen nachgebessert werden muss. Im besten Fall werden nur unnötig Ressourcen gebunden.

Window of Threat and Opportunity

Window of Threat and Opportunity
Window of Threat and Opportunity
Foto: Friedrich Behnk

Fast jeder Unfall beginnt schleichend und häufig als "Havariekette", ein Zusammenwirken einzelner kleiner Unglücke und Fehlentscheidungen. Ab einem gewissen Zeitpunkt, Zeitpunkt der Erkenntnis, realisieren die Akteure einen Missstand. Im Bereich der See- und Luftfahrt wird versucht diese Situation so schnell wie möglich zu verlassen. Ich denke, dass diese Situation für IT-Projekte der Normalzustand ist. Vom Zeitpunkt der letzten Gelegenheit sollte sich jeder Verantwortliche tunlichst fernhalten. Das Heimtückische an diesem Zeitpunkt ist, dass das Überschreiten dieses Punktes häufig zu spät wahrgenommen wird.

Schadensbegrenzung vor dem Projekt-Crash

Zwischen dem Zeitpunkt der letzten Gelegenheit und dem Crash befindet sich oft noch eine weitere Phase, die Zeitspanne zur Schadensbegrenzung. Der Crash ist noch nicht eingetreten, kann aber auch nicht mehr verhindert werden. In dieser Phase ist derjenige gut beraten, der der Realität in das Auge sieht und Vorbereitungen triff, um den Crash abzumildern.

Zur Startseite