Vier Liefertermine wurden versprochen. Keiner hielt. Der Kunde verlor das Vertrauen. Zwischen Teams entstand eine Schuldzuweisungskultur. Es gab keinen belastbaren Gesamtplan, Anforderungen waren nicht freigegeben und selbst eine klare Teststrategie fehlte. Das Projekt stand kurz davor, einen strategisch wichtigen Kunden zu verlieren. Trotzdem gelang der Turnaround. Vom Chaos-Projekt zum Erfolg: Eine echte Case Study zeigt anhand eines dokumentierten IT-Projekts, wie aus einem kaum noch steuerbaren Vorhaben wieder ein lieferfähiges Projekt wurde. Entscheidend waren weder zusätzliche Überstunden noch ein neues Reporting. Der Wendepunkt kam durch Transparenz, klare Verantwortung, einen realistischen Plan und ein Team, das wieder gemeinsam statt gegeneinander arbeitete.

Ein Chaos-Projekt ist kein fachlicher Projektmanagementbegriff. Gemeint ist ein Projekt, bei dem mehrere Steuerungsmechanismen gleichzeitig versagen.

Typische Merkmale sind:

Ein einzelner verpasster Meilenstein macht noch kein Chaos-Projekt.

Kritisch wird es, wenn Probleme miteinander wechselwirken und sich gegenseitig verstärken.

Genau das passierte in der folgenden echten Case Study.

Ein großer deutscher IT-Lösungsanbieter entwickelte gemeinsam mit seinen britischen Einheiten automatisierte Self-Checkout-Systeme für einen internationalen Einzelhändler.

Der Pilot umfasste zunächst vier Geräte.

Für den Anbieter stand viel auf dem Spiel. Eine erfolgreiche Umsetzung konnte laut dokumentierter Fallstudie Folgegeschäft im potenziellen Wert von rund 20 Millionen britischen Pfund eröffnen. Das Projekt hatte damit nicht nur technische, sondern erhebliche strategische Bedeutung.

Das Vorhaben begann im Februar 2003.

Der erste zugesagte Liefertermin:

Januar 2004.

Er wurde verfehlt.

Neuer Termin:

März 2004.

Auch dieser Termin hielt nicht.

Danach:

Mai 2004.

Wieder keine Lieferung.

Schließlich versprach das Projekt:

Mitte August 2004.

Auch dieser Termin erschien zunehmend unrealistisch. Gleichzeitig näherte sich ein vom Kunden vorgegebenes Implementierungsfenster, nach dem für mehrere Monate keine Einführung mehr möglich gewesen wäre.

Spätestens jetzt war klar:

Das Projekt hatte nicht einfach Terminprobleme.

Es hatte seine Steuerungsfähigkeit verloren.

Das Produkt selbst war anspruchsvoll.

Aber die spätere Analyse zeigte, dass viele Schwierigkeiten aus Projektorganisation, Planung und Zusammenarbeit entstanden.

Unter anderem fehlten:

Besonders kritisch war die Unternehmenskultur im Projekt.

Teams beschuldigten sich gegenseitig.

Managementbereiche machten jeweils andere Bereiche verantwortlich.

Software und Hardware sahen die Fehler beim jeweils anderen Team. Teile der Organisation machten wiederum die bisherige Projektleitung verantwortlich.

Damit entstand ein bekanntes Muster.

Je größer die Probleme wurden, desto stärker konzentrierte sich die Organisation darauf, wer schuld war.

Die eigentlichen Ursachen blieben bestehen.

Im Juli griff das Project Board ein.

Dort saßen unter anderem Führungskräfte aus Deutschland und Großbritannien.

Eine neue Projektleitung wurde eingesetzt.

Das klingt zunächst nach der klassischen Lösung:

Projekt läuft schlecht – Projektleiter austauschen.

Aber genau das allein hätte wenig verändert.

Der wichtige Schritt war ein anderer:

Das Management gab der neuen Projektleitung die Möglichkeit, zunächst die tatsächliche Situation zu untersuchen und anschließend eine neue Strategie vorzulegen.

Dafür wurden drei Schritte vereinbart:

Für Analyse und Neuausrichtung waren lediglich rund zwei Wochen vorgesehen.

Das Projekt wurde also nicht für Monate gestoppt.

Es wurde kurzfristig aus dem normalen Modus genommen, um wieder steuerbar zu werden.

Die neue Projektleitung prüfte vorhandene Unterlagen und sprach direkt mit den Teams.

Dabei wurde schnell sichtbar, wie weit offizieller Projektstatus und tatsächliche Lieferfähigkeit auseinanderlagen.

Einige der Erkenntnisse waren fundamental.

Statt eines integrierten Projektplans existierte im Wesentlichen ein Bericht.

Das bedeutete:

Abhängigkeiten, Aktivitäten, Ressourcen und Liefertermine waren nicht ausreichend miteinander verknüpft.

Die funktionalen Anforderungen waren mit dem Kunden noch nicht abschließend freigegeben.

Gleichzeitig wurden intern Änderungen vorgenommen.

Das Projekt entwickelte also ein Produkt, dessen endgültiger Leistungsumfang nicht ausreichend abgesichert war.

Auch das Hardwaredesign war nicht abgeschlossen.

Damit fehlte selbst bei einem wesentlichen Bestandteil des Produkts eine stabile Grundlage.

Es gab:

Die Fallstudie beschreibt sogar eine Situation, in der das Softwareteam einen Test durchführen wollte, während das Hardwareteam dasselbe Gerät gerade auseinandergebaut hatte.

Das wirkt im Rückblick absurd.

Es zeigt aber sehr gut, was ein Chaos-Projekt ausmacht:

Jeder arbeitet. Aber das Gesamtsystem funktioniert nicht.

Der nächste Schritt war bemerkenswert.

Die Projektleitung organisierte einen gemeinsamen Recovery-Workshop.

Die Führungskräfte nahmen bewusst nicht teil.

Warum?

Im Projekt hatte sich bereits eine starke Hierarchie- und Schuldzuweisungskultur entwickelt.

Die Menschen, die tatsächlich an Hardware, Software und Implementierung arbeiteten, sollten offen sagen können:

Das Project Board unterstützte dafür ausdrücklich einen schuldzuweisungsfreien Rahmen. Vergangene Fehler sollten nicht gegen einzelne Beteiligte verwendet werden. Im Gegenzug wurde vollständige Transparenz erwartet.

Diese Entscheidung ist für Projekt-Recovery zentral.

Ein Projekt kann nur dann stabilisiert werden, wenn das Management den tatsächlichen Zustand kennt.

Wenn Mitarbeiter negative Informationen aus Angst zurückhalten, entsteht eine gefährliche Scheingenauigkeit.

Im Workshop wurden nicht einfach Probleme gesammelt.

Das Team rekonstruierte gemeinsam das gesamte Projekt.

Untersucht wurden unter anderem:

Damit sah ein Softwareentwickler nicht länger nur sein Softwarepaket.

Das Hardwareteam sah nicht nur seine Komponente.

Und die Implementierung sah nicht nur den Rollout.

Alle konnten erkennen:

Wie hängt unsere Arbeit miteinander zusammen?

Genau diese Perspektive ist heute noch wichtiger. PMI berichtet 2026, dass 81 Prozent der Projektprofessionals eine zunehmende Komplexität ihrer Projekte wahrnehmen. Rund 31 Prozent komplexer Projekte erreichen nicht den vollständigen ursprünglich erwarteten Nutzen. Teams, die Komplexität wirksam steuern, erreichen dagegen wesentlich bessere Ergebnisse.

Die wichtigste Fähigkeit besteht also nicht darin, jedes Arbeitspaket isoliert zu optimieren.

Es geht darum, das gesamte System zu verstehen.

Der Workshop förderte auch konkrete Planungsfehler zutage.

Ursprünglich war beispielsweise die falsche Anzahl von Geräten kalkuliert worden.

Benötigt wurden zusätzliche Systeme für:

Diese waren in der ursprünglichen Planung nicht ausreichend berücksichtigt worden.

Anschließend erstellte das Team eine neue Struktur der benötigten Aktivitäten und Liefergegenstände.

Daraus entstand:

Der Plan war nicht einfach optimistischer.

Er war erstmals wirklich integriert.

Das ist ein wesentlicher Unterschied.

Recovery bedeutet nicht, ein neues Datum in den alten Plan zu schreiben.

Recovery bedeutet, die Planung auf Basis der tatsächlichen Situation neu aufzubauen.

Auch die Projektorganisation wurde verändert.

Das Team definierte eine klarere Organisationsstruktur.

Zusätzlich wurde eine eigene Testmanagement-Rolle vorgesehen, um Tests zwischen den verschiedenen Teams, dem Anbieter und dem Kunden zu koordinieren.

Damit wurde ein vorher strukturelles Problem nicht mehr nur mit zusätzlichem Engagement bekämpft.

Es bekam:

einen Verantwortlichen.

Dieser Grundsatz lässt sich auf fast jedes gefährdete Projekt übertragen.

Wenn etwas dauerhaft wichtig ist, braucht es:

Sonst bleibt es eine Erwartung.

Gerade dieser Teil macht die Case Study glaubwürdig.

Der Workshop rettete das Projekt nicht innerhalb eines Tages.

Nach der Neuausrichtung dauerte es weitere zehn Wochen, bis das Projekt wieder ausreichend unter Kontrolle war.

Es blieben Schwierigkeiten.

Unter anderem:

Der Unterschied war jetzt:

Das Team verfügte über einen gemeinsamen Plan und eine funktionierende Struktur, um diese Probleme zu bearbeiten.

Das ist ein wichtiger Punkt für jede Projekt-Recovery.

Stabilisierung bedeutet nicht Problemfreiheit.

Sie bedeutet, dass das Projekt wieder in der Lage ist, seine Probleme systematisch zu steuern.

Dann passierte etwas Entscheidendes.

Die ersten neu vereinbarten Meilensteine wurden erreicht.

Das Team sah:

Der Plan funktioniert.

Die Projektleitung sah:

Das Team liefert.

Das Project Board sah:

Die Prognosen werden wieder belastbarer.

Nach und nach entstand Vertrauen.

Laut Fallstudie entwickelte sich aus der schwachen Projektkultur Schritt für Schritt eine stärkere Zusammenarbeit. Isolierte Entscheidungen nahmen ab. Das Team begann wieder als Einheit zu agieren.

Das zeigt:

Vertrauen entsteht bei einer Recovery nicht durch Motivationsreden.

Es entsteht durch glaubwürdige Zusagen und sichtbare Ergebnisse.

Im Januar 2005 wurden schließlich vier hochwertige Self-Checkout-Systeme an den Kunden geliefert.

War das Projekt damit im klassischen Sinn perfekt?

Nein.

Der ursprünglich zugesagte Termin Januar 2004 war um etwa ein Jahr verfehlt worden.

Das sollte man nicht schönreden.

Der Erfolg bestand in etwas anderem.

Ein Projekt, das:

wurde neu aufgesetzt und schließlich mit einem funktionierenden Ergebnis ausgeliefert.

Das ist ein Projekt-Turnaround.

Und genau deshalb ist die Case Study auch heute noch relevant.

Aktuelle PMI-Forschung zeigt, dass rund 45 Prozent der Projekte, die letztlich erfolgreich wurden, während ihrer Laufzeit zeitweise als gefährdet wahrgenommen wurden. Besonders wichtig für ihre Erholung waren frühe Kommunikation von Problemen, Anpassungen an neue Bedingungen, realistischere Zeitplanung und die Sicherung notwendiger Ressourcen.

Aus dem Fall lassen sich sieben entscheidende Faktoren ableiten.

Es wurde nicht weiter versucht, den bestehenden Zustand schönzureden.

Ohne diese Anerkennung gibt es keine echte Recovery.

Die Projektleitung änderte nicht sofort alles.

Sie untersuchte zunächst die Situation.

Probleme durften offen angesprochen werden.

Dadurch konnte Planung wieder auf Fakten basieren.

Abhängigkeiten wurden sichtbar.

Das Projekt wurde wieder als System betrachtet.

Besonders wichtig war die klare Organisation des Testmanagements.

Der Recovery-Plan wurde nicht nur von oben diktiert.

Die Menschen, die die Arbeit ausführten, entwickelten ihn mit.

Erst erreichte Meilensteine machten den neuen Plan glaubwürdig.

Das kann notwendig sein.

Es ersetzt aber keine Ursachenanalyse.

Überlastete Teams werden dadurch selten leistungsfähiger.

Ein Termin ohne neue Planung ist nur eine neue Hoffnung.

Recovery braucht die Bereitschaft, auch frühere Annahmen infrage zu stellen.

Mehr Berichte schaffen keine integrierte Planung.

Dadurch werden wichtige Informationen zurückgehalten.

Ein Krisenprojekt braucht Prioritäten.

Nicht 50 Verbesserungsmaßnahmen.

Nicht jedes Chaos-Projekt sollte gerettet werden.

Das ist eine wichtige Managemententscheidung.

Eine Recovery lohnt sich besonders dann nicht, wenn:

PMI empfiehlt deshalb, eine Projekt-Rettung nicht automatisch mit der Wiederherstellung des alten Projektplans gleichzusetzen. Vor einer Recovery sollte auch der Business Case erneut geprüft werden.

Die Frage lautet nicht:

Wie bringen wir dieses Projekt um jeden Preis wieder auf Kurs?

Sondern:

Ist dieses Projekt in einer veränderten Form weiterhin eine sinnvolle Investition?

Unternehmen sollten nicht erst im Krisenfall überlegen, wie eine Projektrettung funktioniert.

Ein standardisiertes Vorgehen kann fünf Phasen enthalten.

Offiziell feststellen:

Das Projekt befindet sich außerhalb der normalen Toleranzen.

Recovery-Verantwortung und Entscheidungsrechte festlegen.

Innerhalb weniger Tage prüfen:

Entscheiden:

Recovery-Maßnahmen umsetzen.

Kurze Steuerungszyklen etablieren.

Kritische Entscheidungen aktiv verfolgen.

Erst wenn das Projekt wieder innerhalb belastbarer Toleranzen arbeitet, endet der Recovery-Modus.

PMI beschreibt für große gefährdete Projekte ein ähnliches Modell aus Mandate, Assessment, Definition, Intervention und Transfer.

Ein Krisenprojekt braucht weniger kosmetische Ampeln und mehr belastbare Signale.

Wie stabil sind neue Termin- und Kostenprognosen?

Wie schnell werden kritische Entscheidungen getroffen?

Wie lange bleiben wesentliche Hindernisse ungelöst?

Wie viel Aufwand entsteht durch Fehler und Nacharbeit?

Wie viele neu zugesagte Meilensteine werden tatsächlich erreicht?

Gerade die letzte Kennzahl ist für den Wiederaufbau von Vertrauen wichtig.

Eine Recovery ist teuer.

Deshalb ist ein früher Health Check besser.

Achte besonders auf:

Wer diese Signale früh ernst nimmt, braucht möglicherweise nie einen vollständigen Turnaround.

Was hat dieses Projekt gerettet?

Nicht ein neues Tool.

Nicht zusätzliche Kontrolle.

Nicht ein besonders detaillierter Statusbericht.

Der Turnaround begann, als vier Dinge gleichzeitig passierten:

Die Realität wurde akzeptiert.

Das Team durfte sie offen aussprechen.

Aus Einzelaktivitäten entstand wieder ein gemeinsamer Plan.

Verantwortung wurde konsequent geklärt.

Das klingt einfach.

In einer laufenden Projektkrise ist es das nicht.

Denn genau dann steigen politischer Druck, Schuldzuweisungen und der Wunsch, unangenehme Fakten zu relativieren.

Die Fallstudie zeigt deshalb besonders deutlich:

Projekt-Recovery beginnt mit Wahrheit, nicht mit Optimismus.

Vom Chaos-Projekt zum Erfolg ist keine Geschichte über einen Projektleiter, der im Alleingang ein Projekt rettet.

Solche Geschichten sind meistens zu einfach.

Die echte Case Study zeigt etwas anderes.

Das Projekt war tief in Schwierigkeiten, weil mehrere Faktoren zusammenwirkten:

Der Turnaround gelang, weil diese Probleme gemeinsam sichtbar und systematisch bearbeitet wurden.

Die Organisation:

Auch die aktuelle Forschung unterstützt diese Logik. Komplexe Projekte werden nicht erfolgreich, weil sie weniger Schwierigkeiten haben. Erfolgreiche Teams gehen besser mit diesen Schwierigkeiten um. PMI zufolge sind Teams mit hoher Fähigkeit zum Umgang mit Komplexität rund fünfmal häufiger erfolgreich als Teams, die diese nur schwach beherrschen.

Die entscheidende Frage lautet deshalb nicht:

„Ist unser Projekt schon rot?“

Sondern:

„Funktioniert unser Projektmanagement-System noch gut genug, um auf Probleme wirksam zu reagieren?“

Wenn die Antwort Nein lautet, hilft weiteres normales Reporting selten.

Dann braucht das Projekt einen echten Reset.

PURE Consultant unterstützt Unternehmen dabei, gefährdete Projekte unabhängig zu analysieren, Ursachen hinter Termin-, Kosten- und Qualitätsproblemen sichtbar zu machen und aus einem unübersichtlichen Krisenprojekt wieder ein steuerbares Vorhaben mit klaren Entscheidungen und belastbarer Planung zu entwickeln.