Wie Eskalation in Projektteams klappt

Projektorganisationen sind hierarchisch aufgebaut, um schnell Entscheidungen treffen zu können. Dadurch wird zwar das Projekt effizient vorangetrieben, aber hierarchische Strukturen verhindern, dass die Beobachtungen aller Teammitglieder in Entscheidungsprozessen optimal berücksichtigt werden. Dr. Georg Angermeier analysiert diese Hemmnisse und zeigt Lösungswege für eine wirksame Eskalation von Problemen auf. Hierzu vergleicht er Projektteams mit anderen hierarchischen Teams wie z.B. Flugzeugbesatzungen und überträgt die dort verwendeten Methoden des sog. Crew Resource Managements auf die Projektarbeit.

 

Wie Eskalation in Projektteams klappt

Projektorganisationen sind hierarchisch aufgebaut, um schnell Entscheidungen treffen zu können. Dadurch wird zwar das Projekt effizient vorangetrieben, aber hierarchische Strukturen verhindern, dass die Beobachtungen aller Teammitglieder in Entscheidungsprozessen optimal berücksichtigt werden. Dr. Georg Angermeier analysiert diese Hemmnisse und zeigt Lösungswege für eine wirksame Eskalation von Problemen auf. Hierzu vergleicht er Projektteams mit anderen hierarchischen Teams wie z.B. Flugzeugbesatzungen und überträgt die dort verwendeten Methoden des sog. Crew Resource Managements auf die Projektarbeit.

 

Der Flug United Airlines 173 von New York über Denver nach Portland am 28. Dezember 1978 verlief bis zum Landeanflug um 17:05 völlig problemlos. Um 17:09 gab der Kapitän den Befehl, das Fahrwerk auszufahren. Aber die Signalleuchte für das ordnungsgemäße Einrasten des rechten Hauptfahrwerks leuchtete nicht auf. Um 17:12 meldete der Kapitän diesen Vorfall an den Tower und ließ sich in eine Warteschleife lotsen, um das Problem lösen zu können.

Während der folgenden dreiviertel Stunde kreisten alle Bemühungen der Crew darum, das Fahrwerk vollständig auszufahren und eine eventuelle Notlandung vorzubereiten. Erst um 17:46 erkundigte sich der Kapitän nach dem Treibstoffstand. Der Bordingenieur schätzte, dass noch für etwa 15 Minuten Treibstoff zur Verfügung stünde. Eigentlich hätte der Kapitän jetzt den ursprünglichen Plan über den Haufen werfen und zur sofortigen Landung ansetzen müssen. Aber er war vollständig darauf konzentriert, die Passagiere optimal für die Notlandung und die Evakuierung vorzubereiten. Deshalb informierte er weder den Tower über die Zuspitzung der Situation, noch beschleunigte er die Vorbereitungen für die Notlandung, sondern setzte die Vorbereitungen fort, so wie sie in den Anleitungen beschrieben waren. Das war ein klarer Fehler, zudem hätte er bereits von Anfang an den Treibstoffstand in seine Pläne einbeziehen müssen. Spätestens die Meldung des Bordingenieurs hätte ihn auf diesen Fehler aufmerksam machen müssen. Aber auch der Bordingenieur hätte das Problem des Treibstoffmangels dem Kapitän mit deutlich höherer Dringlichkeit melden müssen.

Erst elf Minuten später um 17:57, als der vom Bordingenieur durchgeführte Check bestätigte, dass nur noch für kurze Zeit Treibstoff vorhanden war, wurde dies zum Hauptthema im Cockpit. Zu spät. Um 18:13 fielen alle vier Triebwerke aus und die DC-8 stürzte um 18:15 nur sechs Meilen vor der rettenden Landebahn in ein bewaldetes Wohngebiet. Dem glücklichen Umstand, dass die betroffenen Häuser gerade leer standen, die Bäume die Maschine abbremsten und kein Feuer ausbrach, war zu verdanken, dass es unter den insgesamt 189 Menschen "nur" zehn Todesopfer zu beklagen gab.

In der Untersuchung des Unglücks (NTSB 1979) wurde als Unglücksursache identifiziert:

"Der Fehler des Kapitäns, den Treibstoffstand richtig zu überwachen und richtig auf den niedrigen Treibstoffstand und die Hinweise der Besatzung auf den Treibstoffstand zu reagieren. … Zum Unfall beigetragen hat das Scheitern der anderen beiden Crewmitglieder … ihre Bedenken erfolgreich dem Kapitän mitzuteilen."

Mit anderen Worten: Die Eskalation des Problems "Kapitän, wir haben nicht mehr genügend Treibstoff!" hatte nicht richtig funktioniert. Tragischerweise ergab die nachträgliche Untersuchung zudem, dass das Fahrwerk korrekt ausgefahren war und lediglich der Schalter für die Signallampe des rechten Hauptfahrwerks defekt war, so dass diese nicht aufleuchtete (NTSB 1979).

Warum wir in hierarchischen Teams nicht eskalieren

Um zu verstehen, warum der Bordingenieur den Kapitän nicht eindringlicher auf den bedrohlichen Treibstoffmangel aufmerksam gemacht hatte, müssen wir uns die besondere Stellung eines Flugkapitäns bewusst machen: Er trifft letztverantwortlich alle für den Flug relevanten Entscheidungen. Diese überaus starke hierarchische Position hat einen triftigen Grund: Wenn es kritisch wird, sind an Bord eines Flugzeugs schnelle Entscheidungen notwendig. Wenn es z.B. gilt, einem entgegenkommenden Flugzeug auszuweichen, würde eine Diskussion mit anschließender Abstimmung der Crew darüber, ob man steigen oder sinken solle, ganz einfach zu viel Zeit in Anspruch nehmen.

Deswegen sind Kapitäne in Flugzeugen und auf Schiffen, Einsatzleiter von Feuerwehrteams und Chefärzte am Operationstisch darauf getrimmt, Verantwortung zu tragen und zu entscheiden. Und umgekehrt orientieren sich die Teammitglieder vollständig an ihrem Leiter – sie vertrauen darauf, dass dieser die richtigen Entscheidungen trifft.

Diese Delegation der Verantwortung an den Teamchef hat den Vorteil, dass das Team reibungsfrei und schnell agieren kann. Der schwerwiegende Nachteil besteht darin, dass es nicht geeignet ist, Fehler des Chefs zu korrigieren, sondern diese sogar eher verstärkt, da die Teammitglieder ihre persönliche Verantwortung auf ihren unmittelbaren Zuständigkeitsbereich beschränken. Zudem erkennt das Team Fehler zu spät, da es bis zuletzt von einer richtigen Entscheidung des Vorgesetzten ausgeht.

Das Dilemma der Eskalation

Wenn in einer hierarchischen Struktur ein Mitarbeiter ein Problem erkennt, so gibt es grundsätzlich zwei Möglichkeiten:

  1. Die Ursache liegt im eigenen Verantwortungsbereich.
  2. Die Ursache liegt im Verantwortungsbereich des Vorgesetzten.

Bewertungen und Kommentare

Diese Funktion steht nur eingeloggten Nutzern zur Verfügung. Jetzt einloggen
7 Kommentare anzeigen & selbst mitreden!
Gesamt
Bewertungen 16
Kommentare 7

Alle Kommentare (7)

Anke
Röber

Sehr gut und veranlaßt mich gleich meine gerade noch nicht abgesendete e-Mail anzupassen.

 

Steffen
Heinze

Sehr hilfreicher Artikel über ein ganz wichtiges Thema in jedem Projekt.

 

Gertrud
Thoma

Sehr gute "Gebrauchsanweisung" zur Versachlichung eines absolut heiklen Themas.

 

Sedat
Celik

Ich persönlich lerne Eskalationen oftmals mit bitterem Beigeschmack kennen. Frei nach dem Motto: "Do not hesitate...escalate!" wird inflationär eskaliert, ohne wirlich Rücksicht auf die wahren Probleme oder Ursachen zu nehmen. Den Hinweis auf den PM Reifegrad halte ich auch für enorm wichtig, somit trifft der Artikel meiner Meinung nach genau den richtigen Nerv.

 

Nadine
Röhrig

Sehr interessanter und hilfreicher Artikel. Es wurden zur Veranschaulichung sehr gute und absolut nachvollziehbare Beispiele ausgewählt.

 

Gerhard
Schoch

Klare und deutliche Hinweise und anschauliche Vergleiche!!!

 

Wolfgang
Merten
Dipl.-Ing.

Der Artikel ist sehr anschaulich aufbereitet. Ich frage mich jedoch, ob immer mehr neue Managementmethoden erforderlich sind, um die Grundlage der Kommunikation, d.h. die Verantwortung des Senders und des Empfängers in der Kommunikation, wirksam anzuwenden. Ein klarer, auch die Eskalation berücksichtigender, Kommunikationsplan und die bewußte Teamlenkung zur Einhaltung dieser Regeln schaffen meist schon eine sehr gute Basis für gemeinsame Verantwortungswahrnehmug und Lösungsfindung. Ich bin auch der Auffassung, dass manche Projektmanager wie Herr Huber reagieren und mancher Lenkungsausschuss gar keine Probleme hören möchte(Schönefeld lässt grüßen)- aber ist es dann nicht auch ein richtiger Weg, dies offen in Fachkreisen zu diskutieren, anstatt Lösungsansätze zur Umgehung dieser Verweigerungshaltung zu ergründen?