Der passende Blickwinkel
Das richtige Krisenmanagement im Projekt
- 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
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.
- Zoff in Projekten
Stress in Projekten wollen GPM (Deutsche Gesellschaft für Projektmanagement) und DGQ (Deutsche Gesellschaft für Qualität) mit einem Leitfaden vermeiden. Ein gelungenes Projekt ist für sie wie ein Boxenstopp in der Formel 1. Auf den folgenden Seiten finden Sie Indikatoren, die Ihnen anzeigen, ob Ihr Projekt die Qualität eines Boxenstopps hat. - Zusammenspiel
Beim Boxenstopp hängt die Qualität des Ergebnisses vom perfekten Zusammenspiel von Spezialisten unterschiedlicher Abteilungen ab - in unserem Unternehmen ist die Zusammenarbeit von Projekt, Linie und QM reibungsfrei. - Zeitvorgaben
Die Zeit, die für den Boxenstopp zur Verfügung steht, ist begrenzt - in unserem Unternehmen gibt es für alle Projekte klare Zeitvorgaben, die eine möglichst schnelle Abwicklung verfolgen. - Geschwindigkeit
Die Geschwindigkeit, mit der der Boxenstopp erfolgt, kann den Ausgang des Rennens massiv beeinflussen - in unserem Unternehmen ist allen Beteiligten klar, welche Bedeutung für den Erfolg der ganzen Organisation eine möglichst konsequente Projektbearbeitung hat. - Hierarchie
Es gibt eine klare Hierarchie, die nicht angezweifelt wird - in unserem Unternehmen sind die Verantwortungen in Projekten auch gegenüber QM und Linie eindeutig geklärt. - Aufgaben
Jeder Beteiligte kennt genau seine Aufgabe - in unserem Unternehmen gibt es in Projekten klare Rollendefinitionen. - Ziel
Das gemeinsame Ziel ist (normalerweise) auch klar und unbestritten: Gemeinsame bestmögliche Erledigung der Aufgabe - in unserem Unternehmen ziehen Projekt, Linie und QM an einem Strang.
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.
- Erfolgsfaktoren im Projektmanagement
Gibt es Muster und Faktoren, die verschiedenste erfolgreiche Projekte gemein haben – diese Frage zieht sich durch die Studie "Erfolgsfaktoren im Projektmanagement". Die Studie ist eine Gemeinschaftsarbeit des BPM-Labors (Business Process Management) an der Hochschule Koblenz mit der Deutschen Gesellschaft für Projektmanagement (GPM) und Heupel Consultants. - Unterscheidungskriterien
Die Studienautoren wollten wissen, nach welchen Kriterien die rund 200 befragten Manager den Erfolg eines Vorhabens beurteilen. Das hängt vor allem davon ab, ob die gewünschte Qualität erreicht wurde. - Erfolgsfaktoren
Faktor Nummer Eins ist das Teamwork. Das bestätigen 83 Prozent. Gute Teamarbeit heißt: Rollen und Kompetenzen sind klar definiert. Das Projekt basiert auf einem fachlichen Konzept, das jeder Beteiligte verstanden hat. Kundenanforderungen werden "kritisch und konstruktiv" behandelt. - Misserfolgsfaktoren
Scheitert ein Projekt, liegt das vor allem an schlechter Steuerung und Entscheidungsschwäche. Am wenigsten liegt es an der Projektinfrastruktur. - Die Top Ten der Erfolgskriterien
Die Teilnehmer haben einzelne Aussagen zum Projekterfolg in ein Ranking gebracht. Hier sind die Top Ten von insgesamt 30 Aussagen. Weitere Statements folgen auf den kommenden zwei Seiten. - Plätze 11 bis 20
Teil Zwei des Rankings der wichtigsten Erfolgskriterien - Plätze 21 bis 30
Plätze 21 bis 30 der wichtigsten Aussagen über den Erfolg eines Projektes
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.