Früher oder später gerät jedes Projekt auf den Pfad ins Desaster, sagt unser Autor. Die Kunst der Projektleitung besteht für ihn darin, diesen so schnell es geht wieder zu verlassen. Anhand eines bekannten Beispiels stellt er den Pfad vor.
An Amazon-Kindle übertragen
Melden Sie sich bei Ihrem Amazon Konto an und folgen Sie den Anweisungen, um Ihre Datei hochzuladen und auf Ihr Kindle-Gerät zu übertragen. Unter diesem Link können Sie Ihre Amazon-Geräte und Dateien verwalten. Feedback oder Fragen?
Früher oder später gerät jedes Projekt auf den Pfad ins Desaster, sagt unser Autor. Die Kunst der Projektleitung besteht für ihn darin, diesen so schnell es geht wieder zu verlassen. Anhand eines bekannten Beispiels stellt er den Pfad vor.
Früher oder später betritt jedes Projekt den Pfad ins Desaster. Natürlich gibt es viele Gründe und mögliche Aneinanderreihungen von Problemen, die zu Desastern führen können, doch ich möchte den Blick hiermit auf die Meta-Ebene lenken. Sämtliche Szenarien des Scheiterns wandeln auf demselben dunklen und sumpfigen Pfad, der immer gegenwärtig ist und an dessen Ende ein Sumpf liegt, der das Projekt verschlingt.
Diesen Pfad zu betreten ist unvermeidlich. Doch es ist überlebenswichtig für das Projekt, dass es ihn so früh wie möglich wieder verlässt. Durch Untätigkeit oder falsche Entscheidungen nähert sich das Projekt dem Sumpf immer weiter, bis jede Hilfe zu spät kommt.
Projekte werden angestoßen, um wichtige Ziele zu erreichen. Folglich sind die Beteiligten zu Projektbeginn voller Hoffnung und Zuversicht: Schnell verbreiten sich Aufbruchsstimmung und Euphorie, die das Team bis zum Ende des Projekts und dem Erreichen der gesetzten Ziele tragen sollen. Auch im Projektumfeld setzen alle auf den Erfolg. Es ist ein Gefühl, wie man es vor einer schönen Urlaubsreise kennt: Man tritt die Reise an, um schöne Dinge zu erleben. Nur kurz denkt man darüber nach, was alles schief gehen könnte: auf einer Kreuzfahrt könnte man Schiffbruch erleiden oder sich auf einer Wanderung ein Bein brechen – aber wie häufig geschieht so etwas schon?
Die anfängliche Positivität ist gut und hilfreich. Allerdings ist bekannt, dass ein Großteil der Projekte ihre Ziele verfehlt. Laut der Studie "The Future of Project Management: Global Outlook 2019" sind nur 19% der Unternehmen in der Lage, ihre Projekte zumindest meistens erfolgreich abzuliefern. Laut dem aktuellen Chaos-Report der Standish Group "Chaos 2020: Beyond Infinity" wurden zwischen 2015 und 2020 lediglich 35% der Projekte erfolgreich abgeschlossen (siehe in diesem Video bei Minute 03:30). Der Trend scheint sogar rückläufig zu sein, so dass immer weniger Projekte Erfolg zu haben scheinen.
Die Gründe für das Scheitern sind ganz unterschiedlich. Je nach Flughöhe der Betrachtung sind sie mehr oder weniger spezifisch. In einzelnen Projekten sind es Herausforderungen wie: "Vom CEO gab es keine ausreichende Unterstützung", "Der Entwickler Max Mustermann verfügte nicht über ausreichende Kenntnisse und Erfahrung" oder "Der CMO hat seine Erwartungen nicht ausreichend beschreiben und kommunizieren können".
Aus einer höheren Flughöhe gesehen (und hierbei handelt es sich typischerweise um die oben anhand von zwei Beispielen vorgestellten Statistiken, die verschiedene Institute regelmäßig erheben), sind es zusammengefasste und etwas verallgemeinerte Erkenntnisse wie "eine mangelhafte Unterstützung durch das Management", "unklare Anforderungen", "fehlende Kenntnisse und Erfahrung der Teammitglieder" oder "eine optimierungswürdige Kommunikation im Team".
Alle diese Betrachtungen eint, dass der Pfad des Projekt-Desasters bei ihnen unsichtbar bleibt. Man erkennt ihn nur, wenn man die Gründe und die Kausalitätsketten noch weiter abstrahiert, und zwar bis lediglich die Kernmerkmale und Kausalitäten übrigbleiben. Erst dann wird der Pfad des Projekt-Desasters sichtbar – und zwar so deutlich, als "fielen einem Schuppen von den Augen"!
Wie man Bild 1 entnehmen kann, besteht der Pfad des Projekt-Desasters aus vier Etappen "Annahme (Assumption)", "Risiko (Risk)", "Problem (Issue)" und "Desaster (Disaster)".
Nehmen wir nun die einzelnen Etappen unter die Lupe und betrachten unter welchen Umständen wir sie in Projekten üblicherweise betreten.Der Pfad wird nicht immer in der ersten Etappe "Annahme" betreten, sondern kann in jedem Abschnitt sowohl betreten als auch verlassen werden! Ist man untätig oder trifft falsche Entscheidungen in einer Etappe, folgt man unweigerlich dem Pfad, verschlechtert gleichzeitig die Chancen auf Erfolg und betritt die jeweils nachfolgende Etappe, bis schließlich das Desaster eintritt.
Viele Annahmen werden getroffen, während ein Projekt vorbereitet und aufgesetzt wird. Denn zu diesem Zeitpunkt ist vieles noch unbekannt. Zudem möchten die wenigsten sich über einen längeren Zeitraum ausschließlich mit der Projektvorbereitung beschäftigen. Um das Projekt voranzutreiben, ist es daher eine gute Idee, bestimmte Annahmen zu treffen. Aus diesem Grund findet man bereits viele Annahmen in Scope-Dokumenten, Anforderungsdokumentationen, Lastenheften und Ticketingsystemen wie Jira. Dabei handelt es sich um Annahmen wie z.B. "Es wird angenommen, dass die zu entwickelnde mobile Applikation auf Android-Betriebssystemen mit der Version 10+ uneingeschränkt funktioniert".
Beim Thema Annahmen ist allerdings Achtsamkeit angebracht, denn diese können in jeder Phase eines Projekts anfallen. Lediglich zu Beginn eines Projekts den Fokus auf Annahmen zu legen, führt dazu, dass später getroffene Annahmen nicht oder nur unzureichend behandelt werden. Und somit würde man zu jenem Zeitpunkt unweigerlich wieder den Pfad des Projekt-Desasters betreten. Annahmen können in Projekten zu jedem Zeitpunkt getroffen werden.
Beispiele für diese Zeitpunkte sind:
Der Übergang zur nächsten Etappe "Risiko" ist fließend; denn für jede Annahme gilt, dass ihre Nichterfüllung ein Risiko ist.
Um in dieser Etappe den Pfad des Projekt-Desasters zu verlassen, muss man Annahmen überprüfen – je früher, desto besser. Je länger man Annahmen in einem nicht validierten Status belässt, umso weiter wird man sich im Pfad des Projekt-Desasters fortbewegt haben.
Hat man z.B. eine Applikation komplett auf Basis der erstgenannten Annahme erstellt (siehe oben: "Daten stehen im JSON-Format zur Verfügung"), ohne diese validiert zu haben, kann es zu gravierenden Auswirkungen kommen, wenn zu spät festgestellt wird (bei der Integration mit den betroffenen Systemen), dass die Daten in einem ganz anderen Format bereitgestellt würden. Die sich hieraus ergebenden Probleme zu diesem Zeitpunkt zu beheben, dürfte logischerweise einen enorm hohen Aufwand nach sich ziehen. Der Aufwand wäre sicherlich deutlich geringer gewesen, wenn man gleich zu Beginn der Zusammenarbeit die getroffene Annahme überprüft hätte.
Auch sollte man sich die Schnelllebigkeit der Zielstellungen in der heutigen Zeit vor Augen halten: Annahmen oder Erwartungen, die zu Beginn des Projekts getroffen werden, sind einige Zeit später möglicherweise bereits nicht mehr oder nicht mehr vollständig vorhanden bzw. werden von den Stakeholdern abgelehnt.
Entwickelt man beispielsweise eine Web-Applikation unter der Annahme, dass Cookies zum Einsatz kommen, kann es nach einer Ankündigung durch bedeutende Player im Markt, künftig auf das Tracking zu verzichten (siehe Meldung auf tagesschau.de), zu einem Wandel der Absichten der Projektsponsoren kommen. Daher ist es wichtig, gewisse Annahmen auch zu einem späteren Zeitpunkt erneut zu validieren und an ggf. angepassten Zielstellungen auszurichten.
Verlässt man die erste Etappe des Pfads des Projekt-Desasters nicht rechtzeitig, gelangt man automatisch auf die nächste Etappe "Risiko". Mit anderen Worten: Es entsteht ein Risiko bei dem Thema, zu welchem man eine Annahme getroffen hatte.
Annahmen sind also die Quelle für Risiken. Per Definition enthält jede Annahme das Risiko, dass diese nicht eintritt. Allerdings können Risiken – ebenso wie Annahmen – in jeder Phase des Projekts auftreten. Man kann z.B. gleich zu Beginn eines Projekts dem Risiko ausgesetzt sein, dass ein:e Auftraggeber:in nicht die Zeit findet, um seine:ihre Ziele, Erwartungen und Anforderungen in einem ausreichenden Maß zu kommunizieren. Ebenso kann man am Ende eines Projekts, bei der Veröffentlichung eines Produkts, dem Risiko ausgesetzt sein, dass das entwickelte Produkt von der relevanten Zielgruppe nicht angenommen würde.
Befinden Sie sich auf der Etappe Risiko, sollten Sie das Risiko richtig behandeln und managen, um den Pfad so früh wie möglich wieder zu verlassen. Zum richtigen Management eines Risikos gehören seine adäquate Qualifizierung, das Ableiten von geeigneten Vermeidungsstrategien und/oder Korrekturmaßnahmen sowie das sorgfältige Abarbeiten aller notwendigen Aufgaben, bis das Risiko in einem ausreichenden Maße unwirksam wird (siehe weiterführend zum Thema Risikomanagement das E-Book "Schwierige Projektsituationen meistern", Anmerkung der Redaktion).
Hat man es versäumt oder ist daran gescheitert, Risiken in einem ausreichenden Maße zu vermeiden oder unwirksam zu machen, betritt man die Etappe "Problem". Das bedeutet, dass mindestens ein Risiko eingetreten ist. In anderen Worten: Aus einem Risiko wird ein Problem, wenn die Eintrittswahrscheinlichkeit, die zu den Bewertungsmetriken von Risiken gehört, auf 100% gestiegen ist.
Das Risiko ist also eingetreten und hat sich in ein Problem verwandelt. Auch über diese Etappe kann der Pfad zum Desaster direkt betreten werden. Ein Beispiel hierfür wäre, dass derjenige Mitarbeiter, der am Veröffentlichungstermin eines Produkts eine tragende Rolle spielen soll, nicht am Ort der Veranstaltung erscheint.
Ein Beispiel für einen Übergang aus der Etappe "Risiko" wäre, – angelehnt an das vorherige Beispiel unter "Etappe 2: Risiko" – wenn man nach der Veröffentlichung eines Produkts feststellt, dass es von der anvisierten Zielgruppe nicht angenommen wird, weil man in der vorherigen Etappe das erkannte Risiko nicht ausreichend behandelt hatte. Diesen Pfad hätte man verlassen können, indem man die Anforderungen durch den Markt und die Nutzer:innen zu einem früheren Zeitpunkt überprüft hätte. Dadurch wäre der notwendige Handlungsbedarf erkannt und Maßnahmen eingeleitet worden.
Egal auf welcher Etappe man sich befindet, es gilt immer die Devise: Die Etappe muss so schnell wie möglich wieder verlassen werden. Sollte das unmöglich sein, muss zumindest der Übergang zur nächsten Etappe vermieden werden: also den Übergang von der Annahme zum Risiko, vom Risiko zum Problem und vom Problem ins Desaster.
Sobald man die letzte Etappe betritt, kann es für das Projekt kaum schlimmer werden; es ist dazu verurteilt, im Sumpf des Projekt-Desasters zu versinken. Doch noch ist nicht alles verloren: Sorgen Sie dafür, dass das Projekt seinen Wanderrucksack mit der wertvollen Ausrüstung abwirft und diese sicher außerhalb des Sumpfes landet – die Nachkommenden werden es Ihnen danken!
Denn auch wenn es jetzt nur noch um Schadensbegrenzung geht: Die Aussichtslosigkeit der Situation ist kein Freifahrtschein, um aufzugeben. Meiner Meinung nach trennt sich in dieser Etappe die Spreu vom Weizen; und die wahren Führungspersönlichkeiten beweisen sich.
Wie in jeder anderen Etappe zuvor müssen Sie auch jetzt einen kühlen Kopf bewahren, tapfer bleiben, Verantwortung übernehmen und die richtigen Entscheidungen treffen – allerdings in einer deutlich höheren und kritischeren Intensität, denn die Zeit drängt mehr denn je: der Sumpf kennt kein Erbarmen.
Meine Beobachtung ist, dass viele aus Angst vor Konsequenzen die Situation sogar verschlimmern, indem sie versuchen, Dinge zu vertuschen, die Fehler bei anderen suchen oder sogar ihre Probleme zu Problemen anderer machen wollen. Tun Sie so etwas nicht! Es hilft weder dem Projekt noch Ihnen. Die Wahrheit kommt ohnehin irgendwann ans Licht.
Zeigen Sie stattdessen lieber wahre Größe, indem Sie Ihre eigenen Fehler anerkennen, diese ehrlich eingestehen und daraus Lehren ziehen – für sich selbst, aber auch für andere (z.B. in Form von Lessons Learned und Best Practices). Andere sollen erkennen, dass es sich um Ihren Rucksack handelt, der ihnen später in einer ähnlichen Situation hilft.
Wer im Desaster-Fall alles vertuschen möchte, macht dies oft, um den eigenen Ruf oder den Job zu retten, um in der Zukunft wieder die Verantwortung für Projekte übertragen zu bekommen. Jedoch verhindert Unehrlichkeit eben dies: Niemand würde einer Person nochmal eine verantwortungsvolle Rolle übergeben, wenn es diese in der Krise an Vertrauenswürdigkeit hat vermissen lassen, denn Ehrlichkeit und Vertrauen sind der Grundstein jeder Zusammenarbeit.
Die Desaster-Situation sollte vielschichtig betrachtet und behandelt werden, denn selbst in dieser Situation gibt es noch etwas zu gewinnen: die Minimierung des Schadens; ganz egal, ob es sich hierbei um finanzielle, personelle, oder um Image-Schäden handelt. Das macht die richtige Behandlung der Desaster-Situation so wichtig.
Wer sich hier bewusst falsch verhält und die ihm:ihr übertragene Verantwortung mit Füßen tritt, um sich persönlich zu schützen, erweist sich dieser Verantwortung als unwürdig. Es gibt in dieser Situation nichts zu beschönigen oder zu verheimlichen. Ehrlichkeit, Offenheit, klare Kommunikation und richtige Entscheidungen zwecks Schadenminimierung sind hier die einzig angebrachten Verhaltensweisen.
Viele Projekte enden in einem Desaster. Von den wenigsten bekommt man etwas mit, weil sie entweder zu klein sind und/oder die Unternehmen es – im Sinne nachvollziehbarer Minimierung des Schadens am eigenen Image – vermeiden, aktiv darüber zu sprechen. Es gibt aber bekannte Beispiele von Projekt-Desastern, auch im deutschen Raum.
Um den Pfad des Projekt-Desasters an einem realen Beispiel zu zeigen, wähle ich bewusst eines, das sich außerhalb eines typischen Projektgeschehens abgespielt hat. Dieses Beispiel eignet sich besonders gut zur Erläuterung des Pfads des Desasters, da es allen recht gut bekannt sein dürfte, sodass der Bezug zum Pfad des Desasters leicht hergestellt werden kann. Sämtliche Etappen des Pfades wurden – teilweise sogar mehrmals – beschritten und die Verantwortlichen handelten in jeder Etappe möglichst ungünstig.
Am Abend des 13. Januar 2012 verließ das Kreuzfahrtschiff Costa Concordia den Hafen von Civitavecchia aus. Für 3.200 Reisende sollte es der Beginn einer Rundfahrt durch das westliche Mittelmeer werden. Der Kapitän der Costa Concordia entschloss sich zu einem außerplanmäßigen Manöver: Er wollte dicht an der kleinen Insel Giglio vorbeifahren, um die Bewohner:innen dieser Insel "zu grüßen" (siehe Spiegel Online). Doch dabei kollidierte das Schiff mit einem vorgelagerten Felsen und zog sich einen 70 Meter langen Riss zu, durch den mehrere Abteilungen überflutet wurden, u.a. auch die Maschinenräume. Gut eine Stunde später lief das Schiff auf Grund.
Der Kapitän navigierte sein Schiff auf den Pfad des Desasters, als er sich zu diesem Manöver entschloss. Er hatte wohl angenommen, dass es gut gehen würde, so wie in der Vergangenheit auch. Spezialist:innen halten dieses für anspruchsvoll, aber machbar (mittlerweile wurde es verboten, siehe Meldung auf SZ.de).
Der Kapitän schaltete den Autopiloten aus und übernahm selbst die Kontrolle. Seine zweite falsche Annahme war also, dass er ohne die Technologie besser klarkommen würde. Doch direkt kam es zu einem Missverständnis in der Kommunikation mit dem Rudergänger (so wird das Besatzungsmitglied bezeichnet, das nach den Weisungen der Schiffsführung mit dem Ruder steuert). Daraufhin fuhr das Schiff in die falsche Richtung.
Wie zuvor erörtert, ist die Grenze zwischen Annahmen und Risiken fließend. Zwei falsche Annahmen des Kapitäns genügten, um die Costa Concordia großen Risiken auszusetzen. Die Gründe für die Fehleinschätzungen waren hauptsächlich die Überheblichkeit und Selbstüberschätzung des Kapitäns sowie seine falsche Priorisierung, und die starren Machtstrukturen innerhalb der Crew (siehe dazu "Wie Eskalation in Projektteams klappt", Anmerkung der Redaktion), sowie eine Unternehmenskultur, die Regelverstöße duldete.
Das Risiko, das Schiff könnte komplett außer Kontrolle geraten, wurde nicht sorgfältig behandelt. Auch die gestörte Kommunikation mit dem Rudergänger wurde nicht als Risiko ernst genommen und in ihrer Dysfunktionalität belassen. Auch wurde das Risiko der Havarie untätig hingenommen, indem die elektronischen Navigier-Werkzeuge, die hätten helfen können, teilweise deaktiviert wurden.
Dann brach das Heck der Costa Concordia aus. Die weiteren Versuche zum Gegensteuern fielen wieder den Kommunikationsproblemen mit dem Rudergänger zum Opfer. Eine einfache Rechts-Links-Verwechslung trieb das Schiff immer tiefer auf den Pfad des Desasters. Die ungenügende Berücksichtigung der Risiken führte umgehend zum großen Problem: Der Kollision mit einem Felsen.
Nach der Kollision ging die Crew davon aus, dass seine Konstruktionsweise das Schiff vor dem Schlimmsten bewahren würde, da nur einige Abteilungen überflutet waren. Mit dieser Annahme betrat die Crew einen weiteren Pfad des Desasters, während sie sich bereits auf dem ursprünglichen Desaster-Pad befand. Auch das daraus resultierende Risiko unterschätzte sie und behandelte es nicht in einem ausreichenden Maße.
Da auch der Maschinenraum geflutet wurde, war das Schiff manövrierunfähig und es kam zu einem Stromausfall. Daraufhin gaben die Pumpen ihren Dienst auf, sodass das Schiff voll Wasser lief und vollkommen manövrierunfähig wurde. Das Schicksal der Costa Concordia war besiegelt, sie würde sinken. Doch noch war Zeit, das Desaster abzuwenden.
Denn das Schicksal der Menschen an Bord war weiterhin offen. Die Besatzung hatte die Chance, das Schiff zu evakuieren und einen Notruf abzusetzen, um das schlimmste – den Verlust von Menschenleben – zu vermeiden. Sie tat es nicht. Stattdessen folgte ein beispielloses Missmanagement des Problems:
Durch Wind und Strömung trieb das Schiff ab und näherte sich immer weiter der Insel Giglio. 25 Minuten nach der Kollision meldete sich die Küstenwache beim Kapitän und erkundigte sich nach der Lage, weil sie von der Polizei – infolge von Passagieranrufen – alarmiert worden war. Eigentlich hätte sich der Kapitän bei der Küstenwache melden und um Hilfe bitten müssen.
Als wäre dieses Versäumnis nicht schlimm genug, fuhr der Kapitän sich selbst, seine Crew und Tausende Reisende immer tiefer in den Sumpf des Desasters, indem er Unwahrheiten verbreitete und weiterhin falsche Entscheidungen traf. Er teilte der Küstenwache mit: "Das stimmt nicht. Es ist nur ein Stromausfall. Wir machen uns ein Bild von der Lage."
Der Kapitän blieb weiterhin untätig, verschwieg der Küstenwache das wahre Ausmaß des Problems und verhinderte dadurch, dass die Menschen an Bord gerettet werden konnten. Zur Ehrenrettung des Kapitäns ist anzumerken, dass er schnell das firmeneigene Krisenmanagement über den Unfall informierte, dieses die Informationen allerdings nicht weitergab (siehe Culjak 2015).
Nach der Kollision lief die Costa Concordia auf Grund. Es vergingen weitere 20 Minuten; und erst eine Stunde nach der Kollision forderte die Besatzung die Reisenden dazu auf, das Schiff zu verlassen. In diesem Moment brachen Panik und Chaos aus, da alle das Schiff so schnell wie möglich verlassen wollten. Wegen der Lügen des Kapitäns kamen die Rettungshubschrauber viel zu spät beim Schiff an. Erst als sie das Schiff sehen konnten, erkannten die Piloten das Ausmaß der Katastrophe.
Zu diesem Zeitpunkt hatte der Kapitän das Schiff bereits verlassen. Statt vor Ort die richtigen Entscheidungen zu treffen, Menschen zu retten und zur Schadensminimierung beizutragen, entfernte er sich alleine auf einem Rettungsboot. Dort erreichte ihn ein weiterer Anruf der Küstenwache. Seine Kommunikation und sein Verhalten gehören als Anti-Pattern in jedes Lehrbuch für Führungskräfte:
Küstenwache: "Kommandant: Sie müssen zum Schiff zurückkehren!"
Kapitän: "Ich gehe nirgendwo hin"
Küstenwache: "Kehren Sie um, es gibt Tote!"
Kapitän: "Wie viele?"
Küstenwache: "Das weiß ich nicht. Das sollten Sie mir sagen! Oh Gott!"
Auch wenn ich diese Sätze glücklicherweise in einem derart kritischen und lebensbedrohlichen Kontext noch nie hören musste, erinnert mich diese Kommunikation sehr wohl an unzählige Lenkungskreis-Sitzungen und Projektaudits. Häufig wird dort festgestellt, dass Projektleiter:innen untätig den Pfad des Projekt-Desasters eingeschlagen haben und über den wahren Zustand ihres Projekts nicht Bescheid wissen. Der Ausdruck "Das sollten Sie mir sagen!" fällt leider auch im Projektkontext zu oft.
Das Desaster um die Costa Concordia ging weiter. Der Kapitän setzte seine Flucht fort und nahm sich ein Zimmer im einzigen Hotel der Insel, auf der gerade mehrere Tausend Menschen strandeten. Wenige Stunden später wurde er wegen fahrlässiger Tötung festgenommen.
Die Bilanz ist verheerend:
Jedes Projekt wird sich auf den Pfad des Projekt-Desasters begeben, dies ist unvermeidlich. Mit Untätigkeit, grundloser Hoffnung, Ignoranz und falschen Entscheidungen beschleunigt man auf diesem Pfad. Das primäre Ziel muss also sein, den Pfad so früh wie möglich zu verlassen, ganz egal, in welcher Etappe man ihn betritt. Entscheidend ist zu vermeiden, dass man die nachfolgende Etappe betritt, z.B. indem sich ein Risiko in ein Problem verwandelt.
Verantwortlich dafür, das Projekt aus der Krise heraus zu navigieren ist – im Sinne des RASCI-Modells: Accountable (siehe Verantwortlichkeitsmatrix, Anmerkung der Redaktion) – die Projektleitung. Die Werkzeuge des Projektmanagements können Projektleiter:innen dabei helfen. Neben Projektmanagement-Methoden und Toolkits ist auch die richtige Kommunikation ein kritischer Erfolgsfaktor. Lenkungskreis-Treffen und Status-Reports können sehr hilfreich sein, um Unterstützung zu bekommen und ein Desaster zu vermeiden.
Wer als Projektleitung bis zum Knie im Sumpf des Desasters steckt, aber vorsorglich ein Seil gespannt hat (Stichwort Risikomanagement), um sich selbst heraus zu helfen, sollte das Seil nutzen. Gleichzeitig sollten die Stakeholder via Walkie-Talkie (z.B. Status-Report) adäquat über den aktuellen Status informiert werden; z.B. mit der Ampelfarbe Gelb und dem Hinweis, dass sie zwar bis zum Knie im Sumpf steckt, aber aus eigener Kraft in der Lage ist, sich bzw. das Projekt zu retten.
Steckt das Projekt aber bereits bis zum Hals im Sumpf, muss die Projektleitung dies umgehend kommunizieren, gepaart mit einer klaren Handlungsempfehlung. Sie muss offenlegen, wie tief das Projekt drinsteckt und, dass sie es aus eigener Kraft (im übertragenen Sinne repräsentiert dies die vorhandenen Projektmittel wie Budget/Ressourcen, Zeit, Qualität) nicht mehr befreien kann. Um heraus zu kommen, benötigt das Projekt z.B. innerhalb der nächsten 10 Minuten einen Rettungshubschrauber. Die zu kommunizierende Ampelfarbe des Status wäre Rot.
Wer seinen Status allerdings – wie ich es oft beobachte – nach dem Wassermelonen-Prinzip (nach außen grün, von innen tiefrot) kommuniziert, nimmt anderen Menschen die Möglichkeit, helfend einzugreifen und ein Desaster zu verhindern.
Zum Glück gibt es auch Führungskräfte, die ziemlich alles richtig machen. Ein Gegenbeispiel zum Verhalten des Kapitäns der Costa Concordia ist jenes von "Sully" (Chesley B. Sullenberger), der mit einer erfolgreichen Notwasserung auf dem Hudson River und seinem beispiellosen Verhalten Anerkennung und Ruhm erlangte. Er musste den Pfad des Desasters in der Etappe "Problem" direkt betreten, weil kurz nach dem Abheben ein Vogelschwarm in seine Triebwerke geflogen war.
Mit Erfahrung, Umsicht, richtigen Entscheidungen und Handlungen sowie adäquater Kommunikation gelang es ihm nicht nur, das Flugzeug im Hudson River zu landen, sondern auch alle 155 Menschen an Bord zu retten. Seine Besatzung evakuierte alle Reisenden binnen weniger Minuten. Sullenberger selbst ging zweimal durch das sinkende Flugzeug, um zu 100% sicherzustellen, dass sich kein Mensch mehr an Bord befand und er das Flugzeug als Letzter verlassen konnte (siehe auch Wikipedia).
