Das richtige Krisenmanagement im Projekt

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.

• Ist der Projektmanager ehrlich zu sich selbst, kann sein Bauchgefühl ein sehr wertvoller Trigger sein, um ein drohendes Scheitern zu erkennen
• Wenn der Zeitpunkt der letzten Gelegenheit (Window of Opportunity) nahe ist oder sogar überschritten wurde, empfehlen sich drei Verhaltensweisen für Projektmanager
• Erstens: die Situation nicht leugnen oder herunterspielen
• Zweitens: Schuldzuweisungen und destruktive Kommunikation vermeiden
• Drittens: Beim Entwickeln von Handlungsalternativen und Lösungsansätzen unbedingt das Team einbeziehen

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.

Krisenmanagement-Werkzeug “Window of Threat and Opportunity”

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.

Wie man drohende Risiken erkennt

Mit dem Start des Projektes ist das Risiko des Scheiterns präsent. Daher sollte der Projektmanager zu Beginn seines Projektes relevante Risiken identifizieren, deren Auswirkungen bewerten und während des Projektverlaufes kontinuierlich beobachten.

Die einfachste Form des Risikocontrollings ist eine Tabelle mit der Auflistung relevanter Risiken. Weniger relevante Risiken können gruppiert werden. Jedes Risiko ist mit Indikatoren (Trigger) verknüpft, die kontinuierlich unter Beobachtung stehen. Wichtig ist, dass der Projektmanager zusammen mit seinem Team im Vorfeld Gegenmaßnahmen und Verantwortliche für die bedeutendsten Risiken benennt.

Ein typisches Risiko für ein IT-Projekt ist die Unterschätzung der Komplexität. Tritt dieses Risiko ein, wirkt es sich je nach Prioritätensetzung des Sponsors auf den Umfang (Scope), die Kosten (Budget) und oder den Zeitplan aus. Folgende Trigger können den Eintritt eines entsprechenden Risikos signalisieren:

• Steigende Anzahl von Problemen im Entwicklungsteam.
• Die Anzahl der nicht behobenen Fehler steigt kontinuierlich.
• Die Anzahl der Workarounds steigt.

Verhalten des Projektmanagers

Die Trigger schlagen an, das Team berichtet wiederholt von Problemen. Das Projekt befindet sich im Zeitfenster der Gelegenheiten. Leider ist die eindeutige Definition der Anzahl der Probleme, die den Zeitpunkt der letzten Gelegenheit markieren, wenig sinnvoll. Der Projektmanager muss sich selbst sein Urteil bilden, ob das Team eher pessimistisch, realistisch oder zu optimistisch kommuniziert. Dabei ist das Bauchgefühl nicht zu unterschätzen. Ist der Projektmanager ehrlich zu sich selbst, kann das Bauchgefühl ein sehr wertvoller Trigger sein.

Für den Fall, dass der Zeitpunkt der letzten Gelegenheit nahe ist oder sogar überschritten wurde, empfehle ich dem Projektmanager folgende drei Verhaltensweisen zu berücksichtigen:

• Auch wenn es schwer fällt: Cool bleiben und die Kontrolle behalten! Mit dem Cool bleiben ist nicht gemeint, dass der Projektmanager die Situation leugnet oder herunterspielt. Er muss die Situation korrekt bewerten.
• Schuldzuweisungen (Finger-pointing) und destruktive Kommunikation sind zu vermeiden. Sätze wie zum Beispiel “Es läuft wie immer, die bekommen gar nichts hin. Die sind einfach zu doof zu allem” signalisieren eindeutig, dass der Projektmanager die Kontrolle verloren hat. Verliert der Projektmanager seinen Kopf, bricht die Moral des Teams zusammen. Der Sponsor verliert das Vertrauen und das Scheitern ist nicht mehr zu verhindern.
• Bei der Entwicklung von Handlungsalternativen und Lösungsansätzen ist das Team ein wertvoller Inputgeber. Ein kluger Projektmanager bezieht das Team in die Lösungsfindung mit ein.

Bevor der Zeitpunkt der letzten Gelegenheit überschritten wird, sollte der Projektmanager das Rückgrat haben mit dem Sponsor offen und transparent zu kommunizieren. Auch wenn diese Situation wenig angenehm ist, mittelfristig kann ein verantwortungsvoller Projektmanager nur gewinnen.

Fazit

Projekte leben im Zeitfenster der Gelegenheiten. Das obligatorische Bewerten und der aktive Umgang mit bekannten und unbekannten Risiken hält das Projekt auch weiterhin in dem Fenster. Der Punkt der letzten Chance kommt leise. Ist dieser überschritten und das Überschreiten realisiert, gilt es sich auf den Crash möglichst effektiv vorzubereiten.

Ausblick

Der kommende zweite Teil dieses Artikels wird sich auf das Krisenmanagementwerkzeug PSOBAK beziehen. Zeitlich gesehen fällt PSOBAK in das Zeitfenster der Gelegenheiten beziehungsweise in den Zeitraum zur Schadensbegrenzung. PSOBAK ist eine standardisierte Methode für Entscheider zur Herbeiführung guter Entscheidungen um das Projekt im Zeitfenster der Gelegenheit zu halten.

Referenzen

Schweizerische Sicherheitsuntersuchungsstelle (SUST): Schlussbericht Nr. 2050 des Büros für Flugunfalluntersuchungen über den Unfall des Eigenbau-Flugzeuges Express 2000 ER, HB-YMN

Hans Peter Hartmann: Parallelwelten, oder wie man in der Fliegerei über den Umgang mit Risiken denkt und ob die Welt der Alpinisten davon profitieren kann