8.2 Lehren aus gescheiterten Projekten
Wie sorgfältig ein Projekt auch geplant ist — Misserfolg kann trotzdem eintreten. Aber Misserfolg ist nicht nur ein Endergebnis — er trägt Lehren in sich, die für das nächste Mal wertvoll sind.
Dieser Abschnitt arbeitet die häufigen Ursachen und Warnsignale durch, die in gescheiterten Projekten auftauchen, aus mehreren Blickwinkeln, damit Sie sie früher erkennen und ihre Ausbreitung stoppen.
1. Ziele waren vage oder verschoben sich
- Verschiedene Stakeholder hielten konkurrierende Erwartungen, die nie abgeglichen wurden
- Geschäftsziele waren nie klar aufgeschrieben, jede Seite interpretierte sie anders
- Unternehmensprioritäten änderten sich mitten im Projekt, und der ursprüngliche Zweck driftete ab
Ohne stabile Richtung kann selbst ein Projekt, das pünktlich liefert, als Enttäuschung in Erinnerung bleiben.
2. Risiken und Probleme wurden schlecht kommuniziert
- Der Issue-Tracker wurde zur Formalität — ausgefüllt, aber nicht bearbeitet
- Stimmen vom Feld erreichten nie die Entscheider
- Risikominderung und Notfallpläne fehlten oder waren dünn
Eine Kultur des Schweigens — oder des Aufschiebens harter Gespräche — macht es fast unmöglich, frühe Risiken anzugehen.
3. Menschliche Faktoren wurden übersehen
- Der PM oder andere Schlüsselpersonen wurden zu spät oder gar nicht ernannt
- Reviews und Freigaben wurden zu Stempelaktionen
- Mitgliederwechsel hinterließ unvollständige Übergaben
Stabile Personen und klare Verantwortlichkeit zählen genauso wie der Zeitplan. Verlieren Sie eines davon, beginnt der Rest zu wackeln.
4. Projektmanagement funktionierte nicht
- Die Lage war verstanden, aber Entscheidungen wurden verzögert oder vermieden
- Vereinbarte Regeln — Reviews, Fortschritts-Updates — wurden nicht tatsächlich befolgt
- Berichte wurden eingereicht, aber führten nicht zu Aktion
„Wir wussten es, haben aber nicht gehandelt" ist eines der häufigsten Muster in gescheiterten Projekten.
Fallstudie: E-Commerce-Website-Erneuerung (Einzelhandelsunternehmen)
Überblick: Eine 8-monatige komplette Erneuerung einer B2C-E-Commerce-Site, die kurz vor dem Launch abgebrochen wurde.
- KPIs waren von Anfang an unklar und Anforderungen änderten sich ständig
- Abstimmung mit dem User-Team war dünn, sodass Spec-Bestätigungen immer wieder rutschten
- Schlüsselmitglieder kündigten und brachen Kontinuität und Übergaben
- Qualitätsprobleme stapelten sich kurz vor Release und das Projekt wurde abgebrochen
Dieser Fall verband mehrdeutige Ziele, Führungslücken und schwache Kommunikation — jede für sich überlebbar, zusammen aber bringen sie das Projekt über den Punkt der Erholung hinaus.
Fazit: Misserfolg ist ein Muster übersehener Signale
Projektscheitern wird nicht durch einen einzelnen Fehler verursacht. Es ist das Ergebnis angesammelter Signale, aufgeschobener Entscheidungen und Gespräche, die nie stattfanden.
Deshalb ist es die echte Vorbeugung, Unbehagen früh zu bemerken — und sowohl den Mut als auch das System zu haben, anzuhalten, zu reden und zu reparieren.
So sieht das in AB aus
Jedes Fehlermuster oben hat ein Gegenstück in AB Project Management: vager Umfang → die Projektbeschreibung plus eine Wiki-Seite „Out of Scope" geben dem Umfang ein einziges Zuhause, das nicht abdriftet; versteckte Risiken → Risiko-getypte Aufgaben mit Check-in-Rhythmus halten Risiken lebendig statt in einer Tabelle vergraben; späte Eskalationen → der Verlaufstab zeigt Status- und Zuständigen-Wechsel automatisch, sodass Eskalation kein separater Bericht ist; Wissensinseln → Wiki-Seiten, Kommentare und Anhänge bleiben am Projekt statt verstreut über Drives und Posteingänge; unklare Verantwortlichkeit → das Zuständigen-Feld erzwingt einen Namen für jede Aufgabe. AB verhindert keine Misserfolge — aber es macht sie früher sichtbar, solange sie noch günstig zu reparieren sind.
→ Als Nächstes weiter zu 9.0 Häufig gestellte Fragen (FAQ), um häufige Herausforderungen und praktische Anliegen aus der echten Projektarbeit zu bearbeiten.