Challenger-Unfall zeigt, wie man‘s nicht macht

In fünf Schritten aus der Projektkrise

23.10.2013 von Hans Stromeyer
Zeit- und Kostendruck sowie unterschiedliche Interessen machen Projekt-Managern den Alltag schwer. Und wenn dann etwas Unerwartetes passiert, brennt der Baum. Was dann zu tun ist, lässt sich am Beispiel des „Challenger“-Unglücks zeigen.

Am 28. Januar 1986 explodierte im Kennedy Space Center der NASA das Space Shuttle Challenger etwa eine Minute nach dem Abheben von der Startrampe. Sieben Astronauten verloren bei dem Unfall ihr Leben. Die nachfolgende Überprüfung durch eine Regierungskommission ergab: Ein Dichtungsring einer der Feststoffraketen war undicht geworden - ein Konstruktionsfehler, der den beteiligten Ingenieuren seit langem bekannt war.

Foto: Mike Brown, Fotolia.com

Das ist ein prominentes Beispiel dafür, wie Krisen entstehen und was geschehen kann, wenn die folgenden fünf Schritte für erfolgreiches Krisen-Management nicht eingeleitet werden:

1. Einen kühlen Kopf bewahren

Gerade in ernsthaften Situationen besinnt sich der Mensch von einem Moment zum anderen automatisch wieder auf seine Urinstinkte: Weglaufen oder Kämpfen. Egal, wie oft man für den Ernstfall trainiert hat: Psychisch reagiert jeder anders auf kritische Ereignisse. Die physische Reaktion ist bei allen dieselbe: Der Körper schüttet eine hohe Menge an Adrenalin aus. Die Folgen sind Schockstarre, Angriffsverhalten oder Flucht; der Betroffene verhält sich in der Regel impulsiv.

So auch bei der NASA: Als das Space Shuttle in einem Feuerball verschwand, legte sich zunächst eine große Lähmung über alle Beteiligten. Und diese Starre hielt an: sämtliche Verantwortliche, ja die gesamte Organisation der NASA tauchte zunächst unter und versuchte, keine Informationen nach außen dringen zu lassen.

Im Anschluss an diese Phase begann dann das "Finger Pointing" : Die verschiedenen Verantwortlichen versuchten, die Schuld jeweils auf den anderen zu schieben. Eine Pressekonferenz fand niemals statt. In der Folge brodelte die Gerüchteküche. Statt gemeinsam das Projekt in ruhigeres Fahrwasser zu ziehen, verschärften die Projektbeteiligten durch ihr Verhalten die Krise in beträchtlichem Ausmaß.

Die 14 Fehler beim Projekt-Management
Sie tun es immer wieder: IT-Abteilungen begehen regelmäßig dieselben Fehler beim Projekt-Management. Risiken werden nicht analysiert oder nicht das richtige Personal eingesetzt. Kein Wunder, dass nur ein Drittel aller Vorhaben erfolgreich ist.
Falsches Personal
Der Fehler: Nicht die richtigen Leute für ein Projekt zu haben, kann das ganze Vorhaben sterben lassen. Alle Planungen sind nichts wert, wenn die notwendigen Talente fehlen.<br><br> Die Lösung: IT und Projekt Management müssen einen kompletten Überblick über die Fähigkeiten und Belastungsgrenzen des Personals haben. Das bezieht sich auch auf Berater, Anbieter und Outsourcing-Partner. Entscheidend ist, die Ressourcen bei den unzähligen Projekten und der täglichen Arbeit richtig einzusetzen.
Keine erfahrenen Projekt-Manager
Der Fehler: Projekte können schnell außer Kontrolle geraten, wenn ein erfahrener Projekt-Manager am Steuer fehlt.<br><br> Die Lösung: Es muss ein Projekt-Manager her, der über die richtigen Zertifizierungen und die Finesse verfügt, die einzelnen Akteure zu steuern. Gute Projekt-Manager verstehen es, Meetings in die gewünschte Richtung zu lenken, Risiken zu managen und mit einer Vielzahl von unterschiedlichsten Mitarbeitern umzugehen.
Keine Methode
Der Fehler: Keine Methode mit Standards zu haben erhöht das Risiko, dass das Projekt durch das Raster fällt. Es kann vorkommen, dass es dann komplett überarbeitet werden muss. Im schlimmsten Fall wird es nicht rechtzeitig fertig oder sprengt das Budget.<br><br> Die Lösung: Eine Methodik hilft, Projekte effizienter zu gestalten und informiert über alle Aktivitäten, die bei der Ausführung dazu gehören.
Zu viele Prozesse
Der Fehler: Zu viele Prozesse auf einmal macht das Projekt-Team unflexibel. Was dabei herauskommt ist Frust bei den Beteiligten. <br><br>Die Lösung: Flexibel sein und mit Auftraggebern und Projektbeteiligten kommunizieren.
Änderungen beim Projektumfang werden nicht berücksichtigt
Die Folge: Das Budget für das Projekt explodiert. Zeitpläne sind nur Makulatur. <br><br> Die Lösung: Strazza von CA empfiehlt einen Änderungsantrag ganz formal anzugehen. Ein Dokument sollte die spezifischen Änderungen auflisten. Der Projektleiter muss dann ermitteln, wie sie sich auf das Budget und den Zeitplan auswirken.
Keine Ahnung über den Status quo
Der Fehler: Bei vielen IT-Projekten fehlen aktuelle Daten über den momentanen Status. Aber wie soll man etwas managen, wenn man es nicht messen kann? Vor allem ist es schier unmöglich, Ressourcen zu koordinieren oder auf Veränderungen zu reagieren.<br><br>Die Lösung: Software einsetzen und sich stets über den aktuellen Stand der Dinge informieren.
Probleme ignorieren
Der Fehler: Probleme lösen sich leider nicht von selbst. Sie nehmen immer mehr zu, je länger man wartet. Die Folge sind steigende Kosten. <br><br> Die Lösung: Wenn mal etwas schief läuft, kommt es anschließend darauf an, wie schnell man es wieder in Ordnung bringt.
Umfang nicht klar definieren
Der Fehler: Wenn der Umfang eines Projekts nicht klar umrissen ist, kann es so aufgeblasen enden wie Elvis in seinen letzten Jahren. Irgendwann verliert die IT die Richtung, um das Vorhaben im Rahmen des Zeitplans und des Budgets so über die Bühne zu bekommen, wie sich das Business das vorstellt. <br><br> Die Lösung: IT und Business sollten sich zunächst einmal Zeit nehmen und die Grenzen des Projekt strikt feststecken.
Zusammenhänge zwischen Projekt nicht sehen
Der Fehler: Projekte laufen niemals isoliert für sich allein. Sie hängen oft mit anderen zusammen. Projektleiter vergessen schon mal, das zu berücksichtigen. Die Folge ist, dass nicht nur das einzelne Projekt den Bach runtergeht, sondern auch noch weitere mit nach unten zieht. <br><br> Die Lösung: Zusammenhänge zwischen einzelnen Projekten sollten schon bei der Planung berücksichtigt werden. Dabei hilft es, sich mit den Beteiligten zu besprechen und Projekte als Diagramme darzustellen, um zu erkennen, wie sie sich gegenseitig beeinflussen.
Murphy´s Law vergessen
Der Fehler: Probleme kann es immer geben - und meistens folgt eins dem anderen. Das Schlimme ist nur, wenn die IT davon auf dem falschen Fuß erwischt wird. Das Projekt hat dann erst mal Zwangspause, während die IT versucht, den Laden wieder auf Vordermann zu bringen. <br><br> Die Lösung: Zu einer guten Projektplanung gehört ein Risiko-Assessment. Dafür muss das ganze Team überlegen, was passieren könnte. Danach geht es darum, diese Szenarien zu verhindern.
Kein Change Management
Der Fehler: All die Zeit, Geld und harte Arbeit, die man in neue Technologien steckt, bringen nichts, wenn die Anwender diese nicht annehmen. <br><br> Die Lösung: Bevor zum Beispiel neue Applikationen implementiert werden, sollte geschaut werden, wo es im Unternehmen Widerstand gibt, um die entsprechenden Leute ansprechen zu können. Aufklärungsarbeit ist gefragt.
Unvollständige Ablaufpläne
Der Fehler: Die Beteiligten wissen oft nicht, was wann zu erledigen ist. <br><br> Die Lösung: Zunächst sollten alle Schritte festgelegt werden, die für das Projekt notwendig sind. Als zweiter Schritt muss jedem Punkt eine Deadline gesetzt werden. Hilfreich dabei ist eine entsprechende Software.
Unrealistische Deadlines
Der Fehler: Die IT weist zu selten nicht einhaltbare Deadlines zurück, die vom CEO vorgegeben werden. Dass das Projekt dann nicht just in time läuft, ist kein Wunder. <br><br> Die Lösung: Die IT muss dem CEO erklären, was es kostet, bestimmte Termine einzuhalten. Der hat dann die Wahl zwischen mehr Kosten oder mehr Zeit, die er dem Projekt zur Verfügung stellt.
Fachchinesisch
Der Fehler: Die IT kommuniziert oft mit den Auftraggebern und anderen Beteiligten in einer Weise, die keiner außer ihr selbst versteht. <br><br> Die Lösung: Von Vorteil ist es, wenn man sich bei der Kommunikation auf die Gegenseite einstellt. Das gilt vor allem für die IT. Das Business hat keine Lust, seitenweise Technikbegriffe lesen zu müssen, die ein paar Funktionalitäten erklären sollen.

2. Einen geeigneten Krisen-Manager berufen

Folgerichtig ist die Auswahl des passenden Krisen-Managers das A und O bei der Krisenbewältigung. Im Idealfall ist das eine Person, die in der Lage ist, trotz der angespannten Situation eine durchdachte Strategie zu entwickeln, zu ihrer Umsetzung alle Stakeholder wieder an einen Tisch zu bringen und das Projektteam neu zu motivieren. Das kann, muss aber nicht der derzeitige Projektleiter sein.

Wichtig ist - gleich zu Beginn des Krisen-Managements - die Frage, wie mit dem derzeitigen Projektleiter verfahren wird. Ablösen oder nicht? Die Antwort darauf ist ein wichtiges Teilergebnis der Untersuchung. Soll der Projektleiter abgelöst werden, muss möglichst schnell ein Nachfolger in das Aufgabenfeld eingeführt werden. Die Verantwortung dafür liegt entweder direkt bei der Unternehmensführung oder beim zuständigen Lenkungsausschuss.

Der Krisen-Manager kann aus dem eigenen Unternehmen rekrutiert werden oder ein externer Berater sein. Dem Internen ist das Unternehmen mit seinen Prozessen und Kommunikationswegen vertraut, und er ist im Idealfall stark vernetzt; gleichzeitig unterliegt er der Unternehmensraison und scheut sich häufig, Probleme offen anzusprechen. Der Berater dagegen darf das; dafür sind ihm Mitarbeiter und Unternehmensspezifika fremd.

Im Challenger-Fall wurde nach kurzer Zeit deutlich, dass die Probleme nicht innerhalb der Organisation zu lösen waren. Folgerichtig wurde eine Kommission berufen, die den Unfall und seine Ursachen analysieren sowie Empfehlungen aussprechen sollten, wie solche Katastrophen künftig zu vermeiden wären. Die "Rogers-Kommission" bestand aus einer Reihe anerkannter Fachleute. Den Vorsitz hatte Sally Ride, die erste amerikanische Astronautin im All.

Ob interner oder externer Krisen-Manager - es muss sich unbedingt um eine Persönlichkeit mit umfangreicher Erfahrung im Projekt-Management handeln, die ihre Kompetenz in Sachen PM-Grundregelnnachweisen kann. Systematik und Vorgehen sind immer gleich - weshalb Branchenerfahrung zweitranging ist.

3. Ursachen analysieren, Schwachstellen identifizieren

Wie im Challenger-Fall sind Krisen in vielen Fällen selbst verschuldet und bereits bei Projektbeginn absehbar. Die häufigsten Gründe, aus denen Projekte in Schieflage geraten können, sind die folgenden:

Einer der Gründe für eine Krise ist häufig fehlende oder mangelhafte Kommunikation innerhalb des Projekts. Vorausgehen sollte die Analyse der Stakeholder. So können alle Beteiligten eines Projekts - direkt oder indirekt - in die Abläufe einbezogen werden und haben notfalls Zugang zur Projektleitung. Das erlaubt ein frühzeitiges Erkennen möglicher Risiken und Krisen.

Bei der NASA kamen Schwachstellen in Organisationskultur und Entscheidungsprozessen zusammen. So war auf der unteren Management-Ebene bereits seit langem bekannt, dass das Design der Feststoffraketen bei den Dichtungsringen einen massiven Konstruktionsfehler aufwies - ein Problem, das nie behoben wurde. Auch die Störanfälligkeit des Space Shuttle bei niedrigen Temperaturen war bereits mehrfach bemängelt und nie angegangen worden. Politischer Druck hatte dafür gesorgt, dass keiner der Projektbeteiligten es gewagt hatte, die Schwachstellen beim Namen zu nennen. Ein externer Krisen-Manager darf dies tun - wenn auch nur rückwirkend mit Blick auf künftige Fehlervermeidung.

1. Producteev
“Producteev” ist ein Aufgaben-orientiertes Projekt-Management-Tool, das Team-Collaboration und -Kommunikation in den Vordergrund stellt.
2. Asana
Mit “Asana” bietet sich ein weiteres modernes PM-Tool an, das mit einer besonders intuitiven Bedienung und schnellen Echtzeit-Daten punktet.
3. Do
Der SaaS-Pionier Salesforce stellt mit “Do” einen modernen Service für effektives Projekt-Management zur Verfügung, der Social-Charakter hat und in direkter Konkurrenz mit Producteev und Asana steht.
4. Basecamp
“Basecamp” gehört mittlerweile zu einer der erfolgreichsten PM-Lösungen weltweit und hat den Weg für ein neues Management-Stil basierend auf Kommunikation klar gemacht.
5. Copper Project
“Copper Project” gilt als eine ernsthafte Alternative zu Basecamp und bietet all die Planungs-Funktionen, die viele Anwender eigentlich beim Platzhirsch missen – etwa Gantt-Diagramme und Reporting-Tools.
6. Smartsheet
“Smartsheet” verfolgt einen ganz besonderen Lösungsansatz, bei der flexible, “intelligente” Tabellen als zentrales Organisations- und Kommunikationsinstrument dienen.
7. Jira
“Jira” ist eine umfangreiche PM-Plattform mit zahlreichen Features und Integrationsmöglichkeiten, die speziell für Software-Entwickler konzipiert ist.
8. Redmine
Eine weitere PM-Lösung, die Entwickler adressiert, ist “Redmine”. Dabei handelt es sich um eine quelloffene und extrem flexible Lösung, die man kostenlos einsetzen kann.

4. Mit den Stakeholdern reden und zusammenarbeiten

Die zentrale Aufgabe des Krisen-Managers besteht im Stakeholder-Management. Denn hier herrschen in der Regel Verunsicherung, Ungeduld und Angst. Deshalb setzt der Krisen-Manager zunächst alles daran, eine möglichst persönliche Beziehung zu den Haupt-Stakeholdern aufzubauen. Erst im zweiten Schritt gründet er ein Kernteam, in das er ausgewählte Beteiligte einbindet.

Am Anfang des Krisen-Managements stehen die Neumotivierung aller Projektbeteiligten und Stakeholder sowie eine umfassende Projektanalyse. Diese muss von allen unterstützt werden. Sie kann sich durchaus am "Deming-Zyklus" für Qualität orientieren (Planen - Ausführen - Überprüfen - Anpassen). Dabei sollten folgende unter anderen diese drei Fragen beantwortet werden:

5. Lösungen erarbeiten sowie umsetzen und dokumentieren

Eine wichtige Aufgabe des Krisen-Managers besteht darin, eine Empfehlung für das weitere Vorgehen oder Wege aus der Krise abzugeben. Grundsätzlich bieten sich folgende Handlungsalternativen an:

Das ist vor allem dann sinnvoll, wenn sich das Projekt auch mittelfristig nicht mehr rechnet oder die Ziele innerhalb eines realistischen Zeitrahmens nicht erreichbar sind. Hat der Krisen-Manager seine Handlungsempfehlung abgegeben, ist seine Aufgabe meist beendet. Die Verantwortung für das weitere Vorgehen liegt beim Auftraggeber.

Die NASA entschied sich übrigens fürs Weitermachen. Dazu gab die "Rogers-Kommission" einen umfangreichen Katalog mit Empfehlungen ab. Diese wurden jedoch nicht vollumfänglich umgesetzt. Von der NASA verworfen wurde auch die wichtigste Empfehlung der Kommission - die Einrichtung eines externen und unabhängigen Sicherheitsbüros mit weitreichenden Entscheidungsbefugnissen.

2004 verunglückte wieder ein Space Shuttle. Beim Landeanflug riss eine der Haupttragflächen der Raumfähre Columbia ab. Wieder waren massive Konstruktionsfehler das Problem, wieder waren diese seit langem bekannt, und wieder waren sie nicht adäquat angegangen worden.

Spielregeln für das Projekt-Team
Diese Spielregeln sorgen für eine offene Kommunikation und bieten auch im Konfliktfall eine Orientierung.
Tipp 2
Eine offene Kommunikation einhalten.
Tipp 3
Eine konstruktive Zusammenarbeit umsetzen.
Tipp 4
Zu Problemen grundsätzlich Lösungsvorschläge anbieten.
Tipp 6
Keine Arbeitspakete ohne Termin und Verantwortlichen definieren.
Tipp 7
Delegieren von Arbeitspaketen vermeiden.
Tipp 8
Lieber miteinander reden anstatt E-Mail-Ping-Pong zu spielen.
Tipp 9
Keine politischen Spielchen treiben.
Tipp 11
Dynamik entwickeln und auf das gesamte Projektteam sowie alle Anwender übertragen.

Fazit: Lessons learned erarbeiten - und Fehler nicht wiederholen

Am Ende eines Projekts sollte immer eine Abschlussveranstaltung stehen, bei der man sich das Projekt in seiner Gesamtheit noch einmal vor Augen führt - und sich fragt:

  1. Was ist in den einzelnen Phasen passiert, wo lagen die Probleme und Fehler, was kann und sollte verbessert werden?

  2. Was war gut und sollte beibehalten oder sogar ausgebaut werden?

  3. Welche Hilfen sollte man künftigen Projekten mitgeben?

  4. Wie kann man die "Lessons learned" künftigen Projekten zugänglich machen?

Eine Krise ist immer auch eine Chance: Die Alarmstimmung unterbricht den Alltagsrhythmus und motiviert dazu, gründlich zu prüfen, wo Fehler und Schwachstellen liegen. Allerdings muss die Bereitschaft dazu vorhanden sein, die ursächlichen Fehler zu benennen und anzugehen. (qua)

Checkliste für das Krisen-Management

1. Projekt-Management im Allgemeinen:

2. Projektergebnisse in der Krise: