Ein gescheitertes Projekt kostet Geld, Zeit und oft Vertrauen. Diese Verluste lassen sich nicht schönreden. Trotzdem muss der Wert des Projekts nicht bei null liegen. Wie du aus gescheiterten Projekten echten Nutzen ziehst, entscheidet sich daran, was danach passiert. Werden Ursachen ehrlich analysiert? Bleiben entwickelte Lösungen nutzbar? Ändert das Unternehmen seine Entscheidungen, Standards oder Portfoliologik? Oder verschwindet das Projekt möglichst schnell aus der Erinnerung? Gerade der letzte Fall ist teuer. Dann bezahlt die Organisation denselben Fehler möglicherweise mehrfach. Professionelles Lernen aus Projektscheitern bedeutet deshalb nicht, Fehler zu feiern. Es bedeutet, bereits entstandene Verluste konsequent in Wissen, bessere Entscheidungen und zukünftigen Projekterfolg zu übersetzen.

Ein Projekt gilt nicht allein deshalb als gescheitert, weil es seinen ursprünglichen Termin oder sein Budget überschritten hat.

Die entscheidendere Frage lautet:

Hat das Projekt einen Wert erzeugt, der Aufwand, Kosten und Risiken rechtfertigt?

PMI verwendet inzwischen genau diese wertorientierte Perspektive. In einer globalen Untersuchung mit mehr als 5.800 Projektbeteiligten wurden 13 Prozent der Projekte als klare Fehlschläge bewertet. Weitere 37 Prozent erzielten gemischte Ergebnisse. Gleichzeitig waren 45 Prozent der Projekte, die am Ende erfolgreich waren, während ihrer Laufzeit zeitweise ernsthaft gefährdet.

Das zeigt zwei Dinge.

Erstens:

Ein Projekt kann gravierende Probleme haben und trotzdem noch erfolgreich werden.

Zweitens:

Nicht jeder Abbruch ist automatisch ein Misserfolg.

Ein Projekt früh zu stoppen, dessen Business Case nicht mehr funktioniert, kann eine sehr gute Managemententscheidung sein.

Bevor ein Unternehmen aus einem gescheiterten Projekt lernen kann, muss es klären, was genau gescheitert ist.

Das Projekt konnte seine zugesagte Leistung nicht ausreichend liefern.

Zum Beispiel:

Das Projekt wurde geliefert, erzeugt aber nicht den erwarteten Nutzen.

Beispiel:

Eine neue Plattform funktioniert technisch.

Die Kunden nutzen sie kaum.

Das Ergebnis funktioniert, passt aber nicht mehr zur Unternehmensstrategie oder zum Markt.

Das Projekt wird bewusst beendet, weil neue Erkenntnisse zeigen, dass eine Fortsetzung wirtschaftlich nicht sinnvoll ist.

Gerade die vierte Variante sollte nicht mit schlechtem Projektmanagement verwechselt werden.

Ein gutes Portfolio stoppt schlechte Investitionen.

Ein schlechtes Portfolio hält an ihnen fest, damit niemand ein Scheitern eingestehen muss.

Nach einem Projektscheitern reagieren Organisationen häufig emotional.

Eine Seite argumentiert:

„Wir haben bereits so viel investiert. Jetzt müssen wir weitermachen.“

Die andere:

„Das Projekt ist gescheitert. Alles weg.“

Beides kann falsch sein.

Bereits entstandene Kosten sind wirtschaftlich zunächst versunken.

Sie sollten nicht allein darüber entscheiden, ob weitere Investitionen sinnvoll sind.

Trotzdem kann ein abgebrochenes Projekt erhebliche verwertbare Ergebnisse hinterlassen.

Zum Beispiel:

Die richtige Frage lautet deshalb:

Welchen Restwert können wir aus dem Projekt sichern?

In einer Projektorganisation wurde ein großer Teil der Forschungs- und Entwicklungsprojekte vom Senior Management als Fehlschlag bewertet.

Das PMO betrachtete die Ergebnisse anders.

Einige dieser Vorhaben hatten zwar ihr ursprüngliches Geschäftsziel nicht erreicht, aber Technologie und geistiges Eigentum erzeugt, die später in anderen Projekten genutzt und in kommerziell erfolgreichen Produkten eingesetzt wurden. APM nutzt diesen Fall als Beispiel dafür, warum die Beurteilung eines Projekts nicht ausschließlich beim unmittelbaren ursprünglichen Ergebnis enden sollte.

Ein Projekt kann also in seiner ursprünglichen Form scheitern und trotzdem:

Wissen, Technologie oder Optionen für zukünftigen Wert schaffen.

Das rechtfertigt nicht die ursprünglichen Verluste.

Es verhindert aber, dass zusätzlich der Restwert verloren geht.

Der schlechteste Zeitpunkt für eine Analyse ist sechs Monate später.

Dann:

Deshalb sollte unmittelbar nach Abbruch oder gravierendem Misserfolg ein strukturierter Review erfolgen.

Sichere:

Ziel ist keine Beweisführung gegen einzelne Personen.

Ziel ist:

den tatsächlichen Projektverlauf rekonstruieren.

„Das Projektmanagement war schlecht“ ist keine Analyse.

Auch:

„Die Kommunikation hat nicht funktioniert“

reicht nicht.

Frage stattdessen:

Beispiel:

Nicht:

„Der Kunde war unzufrieden.“

Sondern:

„Das gelieferte Ergebnis entsprach nicht den Anforderungen des Sponsors, weil zwischen der initialen Anforderungsaufnahme und der finalen Lieferung über einen langen Zeitraum keine ausreichende Validierung stattfand.“

Jetzt kann daraus etwas gelernt werden.

Ein dokumentiertes Projekt sollte ein Informationsprodukt für eine öffentliche Organisation entwickeln.

Das Team ging davon aus, die Anforderungen des Sponsors verstanden zu haben.

Zwischen der initialen Abstimmung und der späteren Lieferung lag jedoch eine sehr lange Kommunikationslücke.

Am Ende stellte der Sponsor fest, dass das Ergebnis nicht seinen Anforderungen entsprach.

Das Projekt wurde als Fehlschlag bewertet.

Die zentrale Erkenntnis des verantwortlichen Projektmanagers war nicht:

„Wir müssen besser kommunizieren.“

Sie war konkreter:

Kritische Stakeholder müssen während der Entwicklung regelmäßig eingebunden werden, damit Anforderungen validiert werden können, bevor ein Team über Monate in die falsche Richtung arbeitet.

Genau diese Konkretisierung macht aus einer negativen Erfahrung einen nutzbaren Standard.

Projekte scheitern selten aus genau einem Grund.

Beispiel:

Problem: Projekt wurde zwölf Monate verspätet.

Erste Erklärung:

Die Entwicklung war zu langsam.

Aber warum?

Warum veränderten sich Anforderungen?

Der eigentliche Nutzer war beim Projektstart kaum eingebunden.

Warum waren Schlüsselpersonen überlastet?

Das Portfolio hatte deutlich mehr Initiativen genehmigt als mit den vorhandenen Kapazitäten umgesetzt werden konnten.

Plötzlich liegt die Ursache nicht mehr allein beim Projektteam.

Sondern auch bei:

Eine Fallstudie zu einem gescheiterten Versicherungsprojekt zeigt genau die Bedeutung solcher Ursachenketten. Die Autoren weisen darauf hin, dass klassische Lessons-Learned-Sitzungen tiefere Zusammenhänge häufig nicht erfassen und systemische Methoden wie Cognitive Mapping helfen können, Ursache-Wirkungs-Beziehungen besser sichtbar zu machen.

Symptom

Was wurde sichtbar?

Unmittelbare Ursache

Warum geschah es?

Systemische Ursache

Welche organisatorische Bedingung ermöglichte das Problem?

Erst die dritte Ebene erzeugt häufig den größten Unternehmensnutzen.

Das ist besonders wichtig.

Eine gute Entscheidung kann zu einem schlechten Ergebnis führen.

Und eine schlechte Entscheidung kann durch Glück gut ausgehen.

Beispiel:

Ein Unternehmen testet eine neue Technologie.

Vor Projektstart wurden:

Trotzdem funktioniert die Technologie nicht.

Das Ergebnis ist negativ.

War die Entscheidung deshalb schlecht?

Nicht zwingend.

Wenn Unternehmen jedes negative Ergebnis automatisch bestrafen, entsteht ein gefährlicher Effekt:

Menschen vermeiden Unsicherheit.

Aktuelle Forschung zu projektbasierten Unternehmen zeigt, dass Misserfolge die Bereitschaft zu weiterer Exploration reduzieren können. Projektdiskontinuität und die psychologische Wirkung versunkener Kosten erschweren dabei das Lernen. Gleichzeitig können vorhandene operative Erfahrung und neue Projekte helfen, diese Risikoscheu abzumildern.

Deshalb sollte ein Post-Mortem immer fragen:

War die Entscheidung mit den damals verfügbaren Informationen vernünftig?

Nicht nur:

Wie ist sie ausgegangen?

Auch Harvard Business Review warnt davor, aus Misserfolgen automatisch die vermeintlich offensichtliche Lehre abzuleiten. Rückschau kann selbst falsche Schlussfolgerungen produzieren, wenn der Kontext und die damalige Informationslage nicht berücksichtigt werden.

Nach der Ursachenanalyse folgt eine häufig vergessene Aufgabe.

Inventarisiere, was weiterhin nutzbar ist.

Danach erhält jedes Element eine Entscheidung:

weiterverwenden

überführen

archivieren

bewusst verwerfen

So verhindert das Unternehmen, dass verwertbare Ergebnisse gemeinsam mit dem Projekt verschwinden.

Eine Lesson Learned bringt wenig, wenn sie lautet:

„Stakeholder stärker einbinden.“

Besser:

„Bei Projekten mit mehr als drei betroffenen Fachbereichen muss vor Baseline-Freigabe ein gemeinsames Scope-Review mit den jeweiligen Business Ownern stattfinden.“

Jetzt entsteht eine veränderte Praxis.

Mögliche Konsequenzen eines gescheiterten Projekts sind:

APM weist auf ein bekanntes Problem hin: Organisationen dokumentieren Lessons häufig, passen ihre Arbeitsweise anschließend aber nicht zuverlässig an. Lernen entsteht erst durch die tatsächliche Nutzung des gewonnenen Wissens.

Die zentrale Frage lautet deshalb:

Welcher Unternehmensprozess sieht nach diesem Projekt anders aus als vorher?

Wenn die Antwort „keiner“ lautet, hat die Organisation vermutlich noch nicht ausreichend gelernt.

Hier entsteht der schnellste wirtschaftliche Nutzen.

Angenommen, ein Projekt scheitert unter anderem daran, dass ein externer Lieferant eine kritische Leistung nicht liefern kann.

Im Unternehmen laufen fünf weitere Projekte mit demselben Anbieter.

Dann sollte die Lesson nicht erst in drei Monaten in einer Datenbank veröffentlicht werden.

Das PMO muss sofort prüfen:

Lessons Learned können dadurch zu einem Portfolio-Frühwarnsystem werden.

Das verändert auch die Rolle des PMO.

Nicht:

Erfahrungen archivieren.

Sondern:

Erfahrungen aktiv auf andere Investitionen übertragen.

Nicht jedes gescheiterte Projekt hatte ein falsches Ziel.

Manchmal war:

Das ursprüngliche Problem kann trotzdem weiter bestehen.

Ein dokumentiertes Beispiel betrifft ein bereits eingestelltes Enterprise-Architecture-Programm einer öffentlichen Organisation.

Ein neuer Verantwortlicher analysierte die ursprünglichen Probleme und kam zu dem Schluss, dass der Zweck des Programms weiterhin relevant war. Statt die alte Umsetzung einfach fortzusetzen, wurde das Programm neu gedacht, neu strukturiert und mit anderen Prioritäten wieder gestartet.

Die relevante Frage nach einem Scheitern lautet deshalb:

Ist die Idee falsch – oder war die Umsetzung falsch?

Das ist ein erheblicher Unterschied.

Ein besonders wertvoller Lerneffekt betrifft nicht die Durchführung.

Sondern den Zeitpunkt des Abbruchs.

Frage rückblickend:

Wann hätten wir erstmals wissen können, dass eine Fortsetzung wirtschaftlich nicht sinnvoll ist?

Zum Beispiel:

Monat 3:

Technische Machbarkeit wird deutlich schlechter.

Monat 5:

Kostenprognose steigt um 40 Prozent.

Monat 7:

Business-Nutzen sinkt aufgrund einer Marktveränderung.

Monat 11:

Projekt wird beendet.

Dann lautet eine entscheidende Lesson möglicherweise:

Wir haben nicht zu spät umgesetzt. Wir haben zu spät gestoppt.

Daraus lassen sich Portfolio-Regeln entwickeln.

Zum Beispiel:

Damit verhindert der Fehlschlag möglicherweise zukünftige Fehlinvestitionen.

Das kann wirtschaftlich wertvoller sein als jede einzelne operative Lesson.

Sobald die Analyse zur persönlichen Verteidigungsschlacht wird, sinkt die Qualität der Informationen.

Viele Ursachen liegen außerhalb des Projekts.

Zum Beispiel:

„Kommunikation“ ist selten eine ausreichende Root Cause.

Vielleicht wurden trotz Scheitern gute Technologien oder Arbeitsweisen entwickelt.

Manchmal war perfekte Umsetzung gar nicht mehr sinnvoll.

Nicht jede Beobachtung ist strategisch relevant.

Konzentriere dich auf wenige übertragbare Erkenntnisse.

Dann entsteht Wissen ohne Veränderung.

Damit verschwindet genau das Wissen, das jetzt gebraucht wird.

Dann steigt die Wahrscheinlichkeit, dass dieselben Fehler erneut auftreten.

Der wichtigste Faktor ist Unternehmenskultur.

Lernen funktioniert kaum, wenn Menschen befürchten müssen, dass offene Aussagen:

Dann wird ein Post-Mortem politisch.

Die Präsentation lautet:

„Ungünstige externe Umstände und komplexe Rahmenbedingungen führten zu Herausforderungen.“

Niemand lernt etwas.

Eine offene Analyse könnte stattdessen lauten:

„Das Management genehmigte einen Termin, obwohl die Ressourcenplanung bereits zeigte, dass er mit vorhandener Kapazität nicht erreichbar war.“

Aktuelle Forschung zu gescheiterten Prozessverbesserungsprojekten zeigt ebenfalls, dass Ursachen auf mehreren Ebenen liegen können: vom Top-Management über die Projektorganisation bis zum individuellen Verhalten. In einer qualitativen Studie mit 21 erfahrenen Praktikern wurden 14 kritische Failure Factors identifiziert und mit möglichen Gegenmaßnahmen verknüpft.

Scheitern ist also selten nur ein Teamproblem.

Auch das ist gefährlich.

Nach einem gescheiterten Digitalprojekt lautet die neue Regel:

„Keine experimentellen Technologien mehr.“

Nach einem schwierigen agilen Projekt:

„Scrum funktioniert bei uns nicht.“

Nach einem gescheiterten Lieferantenprojekt:

„Externe Partner sind zu riskant.“

Das sind möglicherweise die falschen Lessons.

Ein einzelnes Ereignis liefert nicht automatisch eine allgemeingültige Regel.

Prüfe deshalb:

Lernen darf nicht in organisatorische Angst umschlagen.

Ein dokumentiertes Technologieprojekt wollte ein neues System mit einer besseren Nutzererfahrung einführen.

Die Lösung wurde nach Einführung von den Nutzern abgelehnt. Die Organisation kehrte kurzfristig zum vorherigen System zurück.

Die spätere Analyse identifizierte unter anderem zwei zentrale Probleme:

Die Konsequenz war nicht:

„Agile Methoden funktionieren nicht.“

Sondern:

Neue Arbeitsweisen benötigen Kompetenzen und Managementverständnis, bevor sie in einem kritischen Projekt angewendet werden.

Das ist der Unterschied zwischen einer reflexartigen und einer belastbaren Lesson.

Unternehmen können gescheiterte Projekte mit einem standardisierten Prozess auswerten.

Innerhalb weniger Tage:

Innerhalb von zwei bis vier Wochen:

Prüfen:

Maximal fünf zentrale Lessons auswählen.

Für jede:

Das PMO identifiziert:

Nach drei bis zwölf Monaten:

Erst hier schließt sich der Lernkreislauf.

Nicht jeder Nutzen lässt sich in Euro ausdrücken.

Trotzdem kann das Unternehmen verschiedene Kategorien messen.

Welche Fehler wurden in Folgeprojekten verhindert?

Welche Technologie oder IP wurde weiterverwendet?

Welche Investitionen wurden später aufgrund besserer Kriterien früher beendet?

Wie viele Projekte nutzen entstandenes Wissen oder Komponenten?

Welche Kompetenzen entstanden?

Welche neuen Frühindikatoren oder Kontrollen verhindern Wiederholungen?

Eine empirische Untersuchung zu Lessons-Learned-Praktiken fand einen statistisch signifikanten Zusammenhang zwischen dem Sammeln und tatsächlichen Anwenden von Projekterfahrungen und der Realisierung von Projektzielen hinsichtlich Scope, Zeit und Budget.

Der entscheidende Teil ist dabei:

Anwenden.

Nicht sammeln.

Ein guter Failure Review sollte diese Fragen beantworten können:

Kann das Unternehmen Frage sieben nicht beantworten, ist die Analyse noch nicht abgeschlossen.

Ja. Es kann beispielsweise Technologie, Daten, geistiges Eigentum, Kompetenzen oder Erkenntnisse erzeugen, die später genutzt werden. Das macht das ursprüngliche Scheitern nicht ungeschehen, kann aber einen Restwert schaffen.

Bei wesentlichen Projekten ja. Tiefe und Aufwand sollten jedoch zur Größe und Bedeutung des Projekts passen. Ein kleines Projekt braucht keinen mehrwöchigen Review.

Neben Projektteam und Projektleitung sollten je nach Ursache auch Sponsor, PMO, Fachbereiche, Betrieb oder andere Beteiligte einbezogen werden. Bei besonders kritischen Projekten kann eine unabhängige Moderation sinnvoll sein.

Nur wenn das zugrunde liegende Problem beziehungsweise die Chance weiterhin relevant ist und die Ursachen des früheren Scheiterns ausreichend verstanden wurden. Die alte Umsetzung unverändert neu zu starten ist keine Recovery-Strategie.

Es gibt keine universelle. Die wertvollste Erkenntnis ist diejenige, die eine konkrete zukünftige Entscheidung oder Arbeitsweise verbessert.

Indem Entscheidungen im damaligen Informationskontext analysiert, Ursachenketten untersucht und systemische Faktoren berücksichtigt werden. Ziel des Reviews ist Verbesserung, nicht die nachträgliche Suche nach einem Schuldigen.

Ein gescheitertes Projekt ist zunächst genau das:

ein Verlust.

Zeit wurde investiert.

Geld wurde ausgegeben.

Erwartungen wurden enttäuscht.

Diesen Schaden sollte niemand mit Begriffen wie „Lernchance“ kleinreden.

Aber Unternehmen haben danach eine Wahl.

Sie können zusätzlich auch noch:

Oder sie sichern den verbliebenen Wert.

Wie du aus gescheiterten Projekten echten Nutzen ziehst, hängt deshalb von einem konsequenten Prozess ab:

Aktuelle PMI-Forschung liefert dabei eine wichtige Perspektive: Fast die Hälfte der Projekte, die am Ende erfolgreich waren, war zwischenzeitlich selbst vom Scheitern bedroht. Anpassungsfähigkeit und Kommunikation halfen ihnen, den Kurs zu verändern. Gleichzeitig zeigt die Forschung zu komplexen Projekten 2026, dass etwa ein Drittel dieser besonders anspruchsvollen Vorhaben scheitert und systemisches Verständnis deutlich an Bedeutung gewinnt.

Projektscheitern lässt sich also nicht vollständig verhindern.

Aber vermeidbare Wiederholungen lassen sich verhindern.

Der eigentliche Verlust entsteht deshalb nicht nur, wenn ein Projekt scheitert.

Er entsteht ein zweites Mal, wenn das nächste Projekt aus diesem Scheitern nichts gelernt hat.

PURE Consultant unterstützt Unternehmen dabei, kritische und gescheiterte Projekte strukturiert auszuwerten, Ursachen sichtbar zu machen und die Erkenntnisse in Projektstandards, PMO, Governance und zukünftige Portfolioentscheidungen zu übertragen.