Projekte eskalieren selten an einem einzigen Tag. Meist beginnt es viel früher. Ein Termin wird trotzdem bestätigt. Ein Risiko wird vertagt. Qualität wird zugunsten von Geschwindigkeit reduziert. Das Team arbeitet länger. Der Status bleibt gelb, obwohl intern längst niemand mehr an den Plan glaubt. Wie ein Projekt komplett eskaliert ist – und was man daraus lernen kann, zeigt ein real dokumentierter Fall besonders deutlich. Aus einem anspruchsvollen IT-Projekt wurde Schritt für Schritt ein Recovery-Fall. Entscheidend sind dabei nicht die Fehler eines einzelnen Projektleiters. Interessant ist die Kette aus falschen Annahmen, schwacher Steuerung und zu spätem Eingreifen – und was Unternehmen daraus konkret ableiten können.

Ein Projektproblem ist noch keine Projekteskalation.

Ein Projekt ist ernsthaft gefährdet, wenn wesentliche Abweichungen nicht mehr innerhalb der normalen Projektsteuerung beherrscht werden können.

Typische Anzeichen sind:

PMI beschreibt ein „troubled project“ als ein Projekt, bei dem Abweichungen in Qualität, Zeit, Budget oder Scope akzeptable Toleranzen überschreiten und eine besondere Intervention notwendig wird. Dabei gehört auch die Beendigung eines Projekts zu den legitimen Handlungsoptionen.

Der entscheidende Punkt:

Eine Eskalation beginnt nicht erst mit der roten Ampel. Sie beginnt dort, wo normale Steuerungsmechanismen nicht mehr ausreichen.

Der folgende Fall stammt aus einer dokumentierten Projekt-Recovery-Analyse.

Unternehmens- und Kundennamen bleiben bewusst außen vor.

Ein Technologieunternehmen sollte für einen deutschen Kunden ein sehr großes individuelles Software- und Datenbanksystem entwickeln.

Das Projekt war anspruchsvoll:

Das Projektteam verfügte grundsätzlich über gute Fachkräfte.

Viele Führungskräfte im Projekt hatten jedoch noch wenig Erfahrung mit Vorhaben dieser Größenordnung.

Dann begann die Eskalation.

Die Terminplanung war nicht detailliert genug, um Fortschritt und Abhängigkeiten zuverlässig zu steuern.

Gleichzeitig wurden Kosten- und Terminrisiken direkt in die normalen Planwerte eingerechnet.

Das klingt zunächst pragmatisch.

Es hatte aber eine fatale Folge:

Reserve und eigentliche Baseline waren später nicht mehr unterscheidbar.

Das Projekt verbrauchte Risikopuffer, ohne klar erkennen zu können, wann dieser Puffer aufgebraucht war.

Auch die Work Breakdown Structure war für ein Vorhaben dieser Größe zu grob. Eine belastbare Prognose wurde dadurch immer schwieriger.

Risiko darf nicht unsichtbar in einer Baseline verschwinden.

Ein Projekt braucht Transparenz über:

Sonst wirkt der Plan länger stabil, als er tatsächlich ist.

Ein großer Teil des Projekts bestand aus der Übernahme vorhandener Daten.

Diese stammten aus vielen Quellen.

Die Qualität war sehr unterschiedlich.

Datenkonvertierung und Bereinigung dauerten wesentlich länger als erwartet.

Das Projekt verlor dadurch mehrere Monate.

Das Problem war nicht nur technisch.

Unklare Verantwortlichkeiten für schlechte Ausgangsdaten verschärften die Situation.

Wer ist verantwortlich, wenn der Kunde Daten liefert, die nicht verarbeitet werden können?

Wer bereinigt sie?

Wer trägt die Terminfolgen?

Solche Fragen waren nicht früh genug eindeutig geregelt.

Bei Datenprojekten ist Datenqualität kein Arbeitspaket kurz vor Migration.

Sie ist eine Projektvoraussetzung.

Früh prüfen:

Ein Data-Readiness-Check kann hier mehr Wert erzeugen als Wochen zusätzlicher Detailplanung.

Der Zeitdruck stieg.

Ein wichtiger politischer Meilenstein musste gehalten werden.

Das Projekt wurde deshalb in mehrere Phasen aufgeteilt.

Gleichzeitig wurden Qualitätsprüfungen reduziert und Tests gelockert, damit eine erste Lieferung rechtzeitig erfolgen konnte.

Kurzfristig half das.

Langfristig entstand ein neues Problem:

Qualitätsschulden.

Fehler und Dokumentationslücken verschwanden nicht.

Sie wurden lediglich in die Zukunft verschoben.

Dieses Muster sieht man auch heute häufig:

Damit wird ein Termin formal gerettet.

Das Gesamtrisiko steigt jedoch.

Nicht jede Terminrettung ist eine Projektrettung.

Frage bei jeder Beschleunigungsmaßnahme:

Was verschieben wir dadurch in die Zukunft?

Zum Beispiel:

Ein Meilenstein ist nur dann erfolgreich, wenn die erreichte Qualität ausreichend ist.

Der größte Unterauftragnehmer reduzierte seine Personalkapazität.

Trotzdem behauptete er, sein Plan sei weiterhin erreichbar.

Dann wurden weitere Meilensteine verfehlt.

Parallel gab es Streit über Changes und Vertragsfragen.

Ein weiterer Anbieter musste eine wichtige Softwarekomponente anpassen. Während des laufenden Projekts wurde bekannt, dass dieses Unternehmen übernommen werden sollte.

Dazu kamen Probleme mit Produkten anderer Anbieter, bei denen keine verlässlichen Termine für Fehlerbehebungen genannt wurden.

Das Projekt war jetzt nicht mehr nur ein Entwicklungsprojekt.

Es war ein Netzwerk aus gegenseitig abhängigen Unternehmen mit unterschiedlichen Interessen.

Lieferantensteuerung darf nicht auf Vertragsmanagement reduziert werden.

Bei kritischen Partnern sollten regelmäßig geprüft werden:

Eine besonders gefährliche Aussage lautet:

„Der Lieferant sagt, er schafft es.“

Ein Forecast braucht Evidenz.

Im Projekt wurde viel kommuniziert.

Genau das war Teil des Problems.

Projektteam, Kunde und externe Partner kommunizierten auf mehreren Ebenen direkt miteinander.

Es gab jedoch keine ausreichende Koordination.

Dadurch entstanden Probleme bei:

Mehr Kommunikation bedeutete also nicht automatisch bessere Kommunikation.

Die Recovery-Analyse stellte fest, dass ein konsolidierter Kommunikationsansatz fehlte.

Große Projekte brauchen nicht möglichst viele Kommunikationswege.

Sie brauchen klare Kommunikationsarchitektur.

Zum Beispiel:

Ein Kunde sollte nicht von drei Projektmitgliedern drei unterschiedliche Aussagen erhalten.

Termine wurden verfehlt.

Arbeitszeiten stiegen.

Die Qualität litt.

Mitarbeiter verließen das Projekt.

Neue Kräfte waren schwer zu finden.

Die Moral sank immer weiter.

Schließlich verloren Mitglieder des Teams selbst das Vertrauen, dass das Projekt noch erfolgreich abgeschlossen werden konnte.

Das ist ein kritischer Wendepunkt.

Denn ein Projektplan funktioniert nur, wenn die Menschen, die ihn umsetzen sollen, ihn noch für realistisch halten.

Dann existiert nicht nur ein Terminproblem.

Es besteht eine Vertrauenskrise.

Die Organisation reagierte schließlich mit einer strukturierten Intervention.

Das Projekt wurde nicht einfach aufgefordert:

„Jetzt bitte schneller arbeiten.“

Stattdessen wurde die Steuerung grundlegend verändert.

Zu den Maßnahmen gehörten:

Bemerkenswert ist:

Die Recovery bestand nicht aus einer spektakulären Maßnahme.

Sie bestand aus der Reparatur mehrerer grundlegender Steuerungselemente.

Genau das ist typisch.

Projekte eskalieren selten wegen eines einzelnen Problems.

Sie eskalieren, wenn mehrere Schwächen gleichzeitig wirken.

Rückblickend lässt sich die Eskalation vereinfacht so darstellen:

Hohe technische Komplexität

↓

zu wenig Erfahrung mit dieser Projektgröße

↓

unzureichend detaillierte Planung

↓

schwache Transparenz über Risiken und Abhängigkeiten

↓

Datenmigration unterschätzt

↓

Terminverzug

↓

Qualitätsprüfungen reduziert

↓

zusätzliche technische Risiken

↓

Lieferantenprobleme

↓

mehr Zeitdruck

↓

Überlastung

↓

Fluktuation und Vertrauensverlust

↓

Managementeskalation

Diese Darstellung zeigt ein wichtiges Prinzip:

Projektkrisen sind häufig systemisch.

Deshalb hilft es wenig, nur das sichtbarste Symptom zu bearbeiten.

Aktuelle PMI-Forschung bestätigt die zunehmende Bedeutung dieser systemischen Perspektive. Laut Pulse of the Profession 2026 erreicht fast ein Drittel komplexer Projekte nicht den vollständigen erwarteten Nutzen. Teams, die Komplexität wirksam steuern, erzielen dagegen eine deutlich höhere Erfolgsquote.

Der Fall liefert mehrere Frühindikatoren.

Termine werden verfehlt, aber die Gesamtplanung bleibt weitgehend unverändert.

Niemand kann mehr erklären, wie viel Reserve tatsächlich verbleibt.

Hier war es die Datenmigration.

Das erzeugt häufig spätere Nacharbeit.

Dann ist die Lieferantenaussage allein kein belastbarer Forecast mehr.

Kurzfristige Spitzen sind normal.

Dauerhafte Überlastung ist ein Warnsignal.

Insbesondere bei Schlüsselrollen.

Wenn niemand mehr an „Grün“ glaubt, ist die Ampel wertlos.

„Wir müssen jetzt alle eine Schippe drauflegen.“

Das funktioniert nur, wenn fehlender Einsatz tatsächlich die Ursache ist.

Bei strukturellen Problemen erhöht mehr Druck häufig:

Manchmal ist ein Führungswechsel notwendig.

Aber ein neuer Projektleiter repariert keine unrealistische Baseline, fehlende Ressourcen oder schlechte Verträge automatisch.

Ein Termin kann nach einer Eskalation nur dann bestehen bleiben, wenn Scope, Ressourcen und Risiken dies realistisch zulassen.

Ein neuer Gantt-Plan behebt keine Root Cause.

Mehr Statusberichte schaffen keine besseren Entscheidungen.

Menschen, die Monate in einem Projekt gearbeitet haben, besitzen wertvolles Wissen.

Sie haben aber auch blinde Flecken.

Deshalb ist bei einer echten Eskalation ein unabhängiger Blick häufig sinnvoll.

Nicht sofort alles umplanen.

Zuerst die Realität herstellen.

Keine weich formulierte gelbe Ampel.

Das Management muss akzeptieren, dass normale Projektsteuerung aktuell nicht ausreicht.

Keine weiteren hektischen Änderungen.

Kritische Tätigkeiten schützen.

Prüfen:

Interviewt werden sollten je nach Projekt:

PMI empfiehlt bei Recovery-Assessments genau diese Kombination aus Dokumentenprüfung, Interviews, Faktenanalyse und abgestimmten Empfehlungen.

„Wir sind drei Monate zu spät“ ist ein Symptom.

Die Ursachen können sein:

Die wichtigste Frage lautet nicht automatisch:

Wie retten wir das Projekt?

Sondern:

Lohnt es sich noch, dieses Projekt zu retten?

PMI weist ausdrücklich darauf hin, dass Recovery den Business Case erneut prüfen muss. Ein Projekt wieder auf seinen ursprünglichen Plan zu bringen, ergibt wenig Sinn, wenn die erwarteten Business Benefits inzwischen nicht mehr erreichbar oder relevant sind.

Nicht jedes eskalierte Projekt sollte gerettet werden.

Ein Recovery-Versuch ist kritisch, wenn:

PMI nennt genau solche Kriterien als Gründe, eine Recovery nicht fortzuführen.

Ein Projekt zu beenden ist deshalb nicht automatisch eine Niederlage.

Manchmal ist der Abbruch die wirtschaftlich beste Entscheidung.

Die gefährlichere Variante lautet:

Ein Projekt weiterzuführen, nur weil bereits viel investiert wurde.

Unternehmen sollten nicht darauf warten, dass ein Projektleiter irgendwann selbst erklärt:

„Wir haben ein Problem.“

Ein PMO kann klare Eskalationskriterien definieren.

Zum Beispiel:

Werden mehrere Schwellen gleichzeitig überschritten, startet ein unabhängiger Health Check.

Nicht erst ein weiterer normaler Statusbericht.

Für ein stark gefährdetes Projekt kann ein kompaktes Vorgehen helfen.

Die drei bis fünf wichtigsten Ursachen identifizieren.

Zum Beispiel:

Szenario A: Termin halten, Scope reduzieren.

Szenario B: Scope halten, Termin verschieben.

Szenario C: Teilprojekt stoppen und neu aufsetzen.

Sponsor und Management wählen eine Variante.

Festlegen:

PMI empfiehlt bei größeren Krisen, die Recovery selbst wie ein eigenes Projekt zu behandeln: mit Mandat, Assessment, Definition, Intervention und späterer Übergabe in eine wieder normale Projektsteuerung.

Die wertvollste Erkenntnis einer Projekteskalation entsteht nicht im betroffenen Projekt.

Sie entsteht im nächsten Projekt.

Aus dem beschriebenen Fall lassen sich beispielsweise Standards ableiten:

Große und komplexe Vorhaben erhalten erfahrenere Projektleitungen.

Datenmigrationen werden vor der Baseline untersucht.

Risiko bleibt getrennt von normalen Planwerten sichtbar.

Kritische Partner werden nicht nur vertraglich, sondern operativ bewertet.

Qualität kann nicht beliebig für Termine geopfert werden.

Strategische Projekte erhalten unabhängige Reviews.

Rot wird anhand definierter Schwellen ausgelöst.

Für Krisen existiert ein vorbereitetes Entscheidungsmodell.

Genau hier wird aus einem schlechten Projekt Unternehmenswissen.

APM-Forschung nennt unter anderem wirksame Governance, klare Ziele, kompetente Teams, Planung und Review sowie Commitment als besonders konsistent mit Projekterfolg verbundene Bedingungen.

Der dokumentierte Fall begann nicht mit einem großen Knall.

Es gab keinen einzelnen Moment, an dem plötzlich alles schiefging.

Stattdessen:

Jeder einzelne Punkt erschien zunächst beherrschbar.

Ihre Wechselwirkung machte das Projekt kritisch.

Genau das ist bei komplexen Projekten heute noch relevanter. PMI berichtet 2026, dass 81 Prozent der Projektprofessionals eine zunehmende Projektkomplexität wahrnehmen. Schwach gemanagte Komplexität äußert sich unter anderem durch Rework, Entscheidungsprobleme, strategisches Abdriften und Belastung der Teams.

Die beste Eskalationsstrategie beginnt deshalb nicht bei Rot.

Sie beginnt bei den ersten Veränderungen im System.

Wenn ein Projekt komplett eskaliert, lautet die falsche Frage:

„Wer hat versagt?“

Die bessere Frage lautet:

„Welche Kombination von Bedingungen hat dazu geführt, dass normale Projektsteuerung nicht mehr funktioniert?“

Der beschriebene Praxisfall zeigt eine typische Kette:

Die Recovery funktionierte nicht durch eine einzelne Hero-Maßnahme.

Sie funktionierte durch die Rückkehr zu grundlegenden Prinzipien:

Vor allem aber braucht ein eskaliertes Projekt eine ehrliche Entscheidung:

Ist das Vorhaben noch wirtschaftlich sinnvoll und realistisch rettbar?

Nur wenn diese Antwort Ja lautet, sollte die Organisation in Recovery investieren.

PURE Consultant unterstützt Unternehmen dabei, gefährdete Projekte unabhängig zu bewerten, Ursachen hinter Abweichungen sichtbar zu machen und eine belastbare Entscheidung zwischen Stabilisierung, Neuausrichtung und Projektabbruch vorzubereiten.