Wie man Projektmisserfolg in 3 Schritten vermeidet + 4 Fallstudien
Es gibt viele Gründe, warum Projekte scheitern, aber letztlich läuft es fast immer auf einen (oder beide) der folgenden Gründe hinaus:
- Es gab ein Risiko, das niemand erkannt hat, und/oder
- Wir haben nicht gut darauf reagiert, als ein Problem aufgetreten ist
In diesem Artikel möchte ich mich auf das große Ganze konzentrieren, um die Hauptursache für das Scheitern von Projekten – und oft auch des Projektmanagements – anzugehen.
So vermeiden Sie das Scheitern von Projekten und was zu tun ist, wenn das katastrophale Problem, das Sie nicht vorhergesehen haben, eintritt (Sie können es trotzdem noch schaffen, wenn Sie schnell und überlegt handeln!).
Unlock for Free
Create a free account to finish this piece and join a community of forward-thinking leaders unlocking tools, playbooks, and insights for thriving in the age of AI.
Have an account? Log In
Was ist das Scheitern eines Projekts?
Genau das, wonach es klingt – immer dann, wenn ein Projekt die zu Beginn vom Team gesetzten Ziele nicht erreicht, die Erwartungen des Kunden oder der wichtigsten Stakeholder nicht erfüllt oder nicht im Zeit-, Budget- oder Umfangsrahmen bleibt.
Warum scheitern Projekte?
Wie bereits im Intro angedeutet, gibt es eine Vielzahl von häufigen Gründen, warum Projekte scheitern können. Meistens liegt dies daran, dass ein Risiko nicht richtig eingeschätzt wurde und/oder dass das Team (einschließlich des Projektmanagers) nicht angemessen auf das Risiko reagiert hat.
Weitere häufige Ursachen für das Scheitern von Projekten können schlechte Kommunikation zu Status, Problemen oder Risiken sein; Teammitglieder halten sich nicht an den Projektumfang (oder verstehen ihn nicht richtig), Projektleistungen (zum Beispiel Scope Creep) oder den Zeitrahmen; ein Mangel an Ressourcen oder das Nichteinhalten der festgelegten Prozesse oder Methoden.
Wie man das Scheitern von Projekten vermeidet: 3 Schritte
Risikomanagement ist eine zentrale Aktivität im Projektmanagement. Es ist so wichtig, dass ein Versagen im Risikomanagement oft auch ein Scheitern im Projektmanagement bedeutet. Risikomanagement besteht aus drei wesentlichen Komponenten:
- Risiken identifizieren.
- Bewerten Sie, was Sie identifiziert haben: Wie wahrscheinlich ist es, dass es eintritt, und wie schlimm wird es, wenn es passiert? Was sind die Wahrscheinlichkeit und die Auswirkungen?
- Erarbeiten Sie Maßnahmen zur Abschwächung und Notfallpläne für diejenigen Risiken, die Ihr ansonsten erfolgreiches Projekt gefährden könnten. Risiko-Register sind nützlich, um das, was Sie getan haben, nachzuhalten.
1. Risiken identifizieren
Zuerst müssen die Risiken identifiziert werden. Wenn Sie das gut machen, erhöhen sich die Erfolgschancen Ihres Projekts erheblich. Auch wenn es schwierig ist, wirklich alle zu erfassen, können Sie durch einen systematischen Blick auf das Projekt meistens die größten Risiken herausfinden. Das ist normalerweise Teil der Erstellung eines Projektplans.
Ich komme aus dem Bereich der Softwareentwicklung, sowohl Produkt- als auch IT-seitig, und den dazugehörigen Prozessen. Softwareprojekte sind komplex, fragil und verfügen – außer in wenigen Ausnahmen – nicht über die Art von eingebauten Sicherheitsmechanismen und Prüfungen, wie es beispielsweise in der Bau- oder Medizintechnikproduktion der Fall ist.
Sie sollten Projektziele für alle vier Stellschrauben haben:
- Zeitplan
- Inhalt
- Kosten
- Qualität
Wenn Sie nicht wissen, was das jeweils ist, dann wäre das Ihr Ausgangspunkt. Erfahrungsgemäß verschieben sich meistens zwei der vier Punkte ein wenig, aber je mehr Sie über die Zielrichtung wissen, desto leichter lassen sich Hindernisse identifizieren.
Zu wissen, welche der vier Stellschrauben die höchste Priorität hat, hilft Ihnen, Risiken zu minimieren, indem Sie gezielt an kleinen Stellen angemessene Kompromisse eingehen.
Man kann sich leicht von der Zeitplanung ablenken lassen und übersieht dabei Risiken, die die anderen Punkte betreffen könnten, aber sie sind alle miteinander verbunden und gleich wichtig zu betrachten.
Die Einhaltung des Zeitplans zu Lasten der Produktqualität – zum Beispiel mit einem fehlerhaften Produkt – ist meist keine gute Option: Auch wenn Sie das Produkt ausliefern, werden Sie „Fix-it“-Releases machen müssen, die den Zeitplan für ein angemessenes Produkt weiter hinauszögern, als es die frühzeitige Behebung des Problems getan hätte.
Über die 4 Stellschrauben hinaus
Neben den vier Stellschrauben gibt es drei weitere Projektdimensionen, die Sie ausbalancieren müssen:
- Produkt, was üblicherweise durch die Stellschrauben abgedeckt wird
- Prozess
- Menschen
Prozessrisiken gibt es in zwei Formen: Eine bestehende Prozessschwäche, die nicht zu den Anforderungen Ihres Projekts passt, sowie das Fehlen eines Prozesses für etwas, das für das Team kritisch ist. Prozessrisiken lassen sich meist recht einfach durch die Einführung oder Anpassung eines Prozesses mindern.
Der Faktor Mensch wird oft unterschätzt, aber Ihr eigenes Team und die Teams, mit denen sie zusammenarbeiten, entscheiden maßgeblich über den Projekterfolg. Schwierige oder desinteressierte Stakeholder machen es schwer, an notwendige Informationen und Entscheidungen zu kommen.
Überarbeitete, gestresste oder unzufriedene Teammitglieder werden die Arbeit nicht erledigen. Einige der möglichen zwischenmenschlichen Probleme können Sie öffentlich erkennen, andere sollten Sie lieber privat ansprechen – aber machen Sie nicht den Fehler, sie zu ignorieren.
2. Einschätzen der identifizierten Risiken
Nachdem Sie die Risiken identifiziert haben, bestimmen Sie, wie wahrscheinlich das Eintreten des Risikos ist. Ich verwende dafür normalerweise einen Prozentsatz—100% bedeutet, dass ich sicher bin, dass es eintreten wird. Ebenso wichtig ist es zu bestimmen, wie schlimm es wäre, wenn das Risiko wirklich eintritt. Am einfachsten ist es, Risiken als hoch, mittel oder niedrig einzustufen.
Nachdem Sie diese Analyse durchgeführt haben, ist es Zeit, Ihr Team mit einzubeziehen. Fragen Sie jedes Projektteammitglied oder jeden Mitwirkenden, worüber sie sich Sorgen machen, ergänzen Sie diese Punkte zur Risikoliste und stellen Sie die Liste zur Überprüfung vor:
- Fallen dem Team noch weitere Risiken ein, die Sie nicht abgedeckt haben?
- Wie schätzt das Team die Wahrscheinlichkeits- und Impaktanalyse ein?
Basierend auf diesem Meeting können Sie Anpassungen an Ihrem Risikoplan vornehmen. Teil eins und zwei sind damit—vorerst—abgeschlossen. Sie müssen die Risiken jedoch mindestens wöchentlich überprüfen, um festzustellen, ob neue hinzugekommen sind, einige nicht mehr relevant sind oder sich Wahrscheinlichkeiten oder Auswirkungen verändert haben.
3. Vorbereitung von Minderungs- und Notfallplänen
Wenn die Kombination aus Wahrscheinlichkeit und Auswirkung bestimmter Risiken Ihr Projekt entgleisen lassen könnte, erarbeiten Sie gemeinsam mit Ihrem Team dokumentierte Pläne für die Risikominderung und das weitere Vorgehen im Notfall.
Minderung bedeutet, das Risiko entweder weniger wahrscheinlich zu machen oder im Fall seines Eintritts die Auswirkungen zu verringern. Notfallmaßnahmen konzentrieren sich darauf, welche Schritte Sie unternehmen, wenn das Risiko unvermeidbar ist und tatsächlich eintritt.
Stellen Sie sicher, dass die Pläne dokumentiert werden und allen bekannt sind. Es ist auch sinnvoll, potenzielle zwischenmenschliche Themen zusätzlich zu den 4 Stellschrauben und Prozessen zu berücksichtigen – aber diese Analyse sollten Sie vermutlich selbst vornehmen und vertraulich behandeln.
Wie Sie ein Scheitern des Projekts überstehen
Der zweite Grund für das Scheitern von Projekten ist eine schlechte Reaktion auf eingetretene Projektrisiken, ob vorhersehbar oder nicht. Das liegt ganz bei Ihnen als Projektleiter. Bevor Sie eine der untenstehenden Maßnahmen ergreifen, beginnen Sie mit diesen zwei Tipps:
- Nicht in Panik geraten. Vergessen Sie nicht zu atmen.
- Keine Schuldzuweisungen – und lassen Sie auch sonst niemanden auf Schuldzuweisungspfaden wandeln.
1. Auf den Notfallplan zurückgreifen
Wenn Sie einen Notfallplan haben, berufen Sie sofort ein Meeting ein, oder schicken Sie wenigstens eine E-Mail, die den Notfallplan auslöst. Erinnern Sie alle an den Plan und informieren Sie, wann und wie der Status zu melden ist.
Wenn Sie dies überspringen oder verzögern, werden hilfsbereite Mitarbeitende auf eigene Faust loslegen; im Panikmodus verlieren Sie dann schnell den Überblick, was schon getan wurde, und das Problem wird oft schlimmer.
Falls kein Notfallplan vorhanden ist, versammeln Sie Ihr Team umgehend zu einer Besprechung mit der strikten Anweisung, bis dahin NICHTS ANDERES zu tun.
Andernfalls werden alle versuchen zu helfen, und Sie wissen nicht, wer was getan hat. Sprechen Sie im Meeting das Problem klar und deutlich an – es ist immer wieder erstaunlich, wie unterschiedlich die Ansichten im Team dazu sind.
Führen Sie eine konsolidierte Ursachenanalyse durch, um dem Problem auf den Grund zu gehen und einen Plan auszuarbeiten: Wer macht was, und wie sieht die Rückkehr zum Sollzustand aus? Bei der Ursachenanalyse müssen Sie nachvollziehen, wer was im Vorfeld getan hat, aber halten Sie die Diskussion auf dieser Sachebene.
Mit anderen Worten: nüchtern die Fakten. Keine Schuldzuweisungen, denn das lenkt nur ab. Kommt das Team zu keiner Lösung, haben Sie verschiedene Optionen.
Die erste ist, jemanden einzubeziehen, der das Thema kennt, aber nicht im Projektteam ist – beispielsweise einen Datenbankadministrator, falls die Datenbank die Ursache scheint, der bisher nicht am Projekt beteiligt ist und eine frische Sicht beisteuern kann.
Eine andere Technik ist, jemanden völlig Außenstehendes hinzuzuziehen. Das detaillierte Erläutern jedes einzelnen Schrittes entlarvt manchmal falsche Annahmen oder Sachverhalte, die übersehen wurden.
2. Das Problem beheben
Bringen Sie alle hinter Ihren Lösungsweg und teilen Sie Aufgaben zu. Lassen Sie die Fortschritte an Sie melden und sagen Sie genau, wie oft – stündlich, nach Abschluss eines Arbeitsschrittes, am Tagesende oder was je nach Situation Sinn ergibt.
Das Melden des Status scheint Ihnen vielleicht selbstverständlich, ist es für alle anderen jedoch nicht. Regelmäßige Updates helfen, das Team auf Kurs zu halten. Berichten Sie häufig zusammengefasste Fortschritte an das gesamte Team.
Die Teammitglieder ohne unmittelbare Aufgaben werden unruhig und versuchen wahrscheinlich irgendwann zu helfen, wenn Sie sie nicht mit Status-Updates und Informationen versorgen.
Es ist auch sehr wichtig, das Management stets auf dem Laufenden zu halten. Nutzen Sie Ihr Urteilsvermögen, um zu entscheiden, wer wann informiert werden muss, aber berichten Sie regelmäßig zusammengefasste Fortschritte an das gesamte Team.
3. Abschluss kommunizieren
Aber wirklich erst dann, wenn es erledigt ist. Erstellen Sie einen Abschlussbericht und gehen Sie zum nächsten Schritt über. Geben Sie dem Team eine kurze Erholungspause.
4. Führen Sie eine Nachbesprechung oder Retrospektive durch
Es ist wichtig, eine Projektauswertung durchzuführen, um gewonnene Erkenntnisse zu sammeln. So können Sie das strukturieren:
- Benennen Sie das Problem, damit alle auf dem gleichen Stand sind
- Beginnen Sie mit dem, was gut gelaufen ist. Selbst in der aussichtslosesten Situation ist etwas gut gelaufen. So startet das Meeting mit einer ganz anderen Stimmung.
- Sprechen Sie darüber, was verbessert werden muss. Wenn Zeit bleibt, brainstormen Sie gemeinsam Verbesserungsmöglichkeiten; andernfalls weisen Sie Aufgaben und Fälligkeitstermine zu und verfolgen Sie diese nach.
Wenn tatsächlich jemand schuld war, sprechen Sie es mit dieser Person – im Privaten – an. Tun Sie dies öffentlich, wird sich Ihr gesamtes Team fragen, wer als Nächstes vor allen bloßgestellt wird.
Wenn Sie die Nachbesprechung komplett auslassen, fühlt sich Ihr Team so, als hätte jemand etwas ungestraft durchgehen lassen und das Problem sei nicht behoben worden. Bleiben Sie sachlich und verfolgen Sie notwendige persönliche Prozessänderungen nach. Es geht um Verantwortung und Verbesserung, nicht darum, einen Schuldigen zu suchen.
3 Praxisbeispiele für Projektmisserfolge
Ich habe meinen Anteil an gescheiterten IT-Projekten erlebt, obwohl sie zum Glück – wenn auch schmerzvoll – aufgefangen werden konnten.
Hier sind einige meiner eigenen gescheiterten IT- und Entwicklungsprojekte sowie ein Beispiel für ein berüchtigtes gescheitertes Projekt.
Diese Beispiele und Fallstudien gescheiterter Projekte sollen Ihnen auch ein anschauliches Bild davon geben, wie Projekte scheitern können und wie damit umgegangen werden kann.
1. Das Buchhaltungssystem
Früh in meiner Karriere arbeitete ich bei IBM. Mein erster richtiger Job war es, ein recht kleines System, das in die Konzernbuchhaltung einspeiste, zu übernehmen. Jemand innerhalb von IBM hatte es in einer obskuren Programmiersprache namens RPG auf einem kleinen System geschrieben.
Ich habe nicht nur das Projekt gesteuert – ich war für das gesamte System verantwortlich (obwohl es einen Administrator gab), einschließlich Anforderungsanalyse, Fehlerbehebung und Programmierung.
Eines schönen Tages spielte ich ein neues Programm ein, startete es und bemerkte einen Fehler. Ich korrigierte den Fehler und startete das Programm erneut. Am nächsten Morgen erhielt ich einen Anruf von der Buchhaltung: Es gab Doppelbuchungen (was in der Buchhaltungswelt sehr schlechte Nachrichten sind).
Erstens hat niemand meine Arbeit überprüft. Zweitens habe ich nicht die Kollegen der nachgelagerten Systeme eingebunden, um die Buchungen vor der Weiterleitung zu kontrollieren. Drittens habe ich mir keine Zeit genommen, einige der alten Programme zu analysieren, die noch liefen und ebenfalls Doppelbuchungen verursachten. Es gab auch keinen Prozess, außer dem, den ich spontan entwickelte.
Und dann meine Reaktion – Panik. Herrgott, frisch von der Uni und ich ruiniere IBMs Buchhaltungssystem! Ich habe nicht die richtigen Leute einbezogen – der Administrator wusste von nichts – und er erzeugte ohne es zu wissen eine weitere Buchungsserie. Am Ende arbeitete ich 48 Stunden am Stück, um die Ursache zu finden, das Problem zu beheben und Programme zu schreiben und auszuführen, um die Buchhaltungsfehler zu korrigieren.
Daraus habe ich meine Lektion gezogen – genau hinschauen, Reviews einholen, überlegen, was schiefgehen kann und erst nachdenken, bevor man kopfüber versucht, etwas zu reparieren (all das kann Buchhaltungsprojektmanagement-Software unterstützen). Stellen Sie sich jetzt vor, ich hätte ein 10-köpfiges Team geleitet und jeder hätte eigenständig versucht, das Problem zu lösen. Es wäre unmöglich gewesen, das Ganze zu retten, ohne das gesamte IBM-Buchhaltungssystem außer Betrieb zu nehmen.
2. Das neue interne Produkt
Als Berater leitete ich ein neues, großes Projekt mit vielen Beteiligten, was zu ständig wechselnden Prioritäten führte. Wir arbeiteten nach einem agilen Projektmanagementprozess, den das Unternehmen bisher nicht kannte. Die Qualitätssicherung war sehr gut in Tests, verstand jedoch noch nicht die Denkweise und den Arbeitsablauf der Endanwender.
Mir waren all diese Dinge bewusst und ich habe sie auch gelegentlich angesprochen, aber ich hatte kein Risikoregister, keine Einschätzung von Auswirkung/Wahrscheinlichkeit, keine Notfall- oder Maßnahmenpläne. Ich war zudem nicht die Hauptinformationsquelle für die Projekt-Sponsorin, auch wenn ich sie gelegentlich traf.
Wir fügten einen Sprint hinzu. Dann noch einen. Als klar wurde, dass wir noch nicht bereit waren für einen Betatest, kam ein dritter Sprint hinzu.
Da ich aber nicht diejenige war, die die Kommunikation mit der Projekt-Sponsorin übernahm, wusste ich nicht, dass sie von all dem nichts wusste. Die verantwortliche Person machte den entscheidenden Fehler, der Sponsorin nichts mitzuteilen, in der Hoffnung, dass wir das Problem lösen könnten.
Und ehrlich gesagt: Auch wenn ich über Risiken sprach, gab ich ihm keine konkrete Risikoliste an die Hand, die der Sponsorin präsentiert werden konnte, um sie auf eine mögliche Terminverschiebung vorzubereiten.
Mitten in all dem hatte ich ein Meeting mit der Sponsorin und erwähnte beiläufig den finalen Sprint, den wir noch hinzufügen würden. Sie stoppte mich sofort. Sie wusste nichts davon und war nicht erfreut.
Wie sich herausstellte, war sie mehr über die Überraschung als über die Terminverschiebung verärgert. Es gab öffentliche Konsequenzen, und letztlich wechselte die verantwortliche Person das Projekt beziehungsweise den Aufgabenbereich im Unternehmen, weil das Vertrauensverhältnis zerstört war.
Wieder einmal habe ich aus dem Scheitern wichtige Lektionen gelernt. Die Risiken zu kennen reicht nicht aus, man muss sie zusammenführen, bewerten, Gegenmaßnahmen und Notfallpläne haben sowie diese öffentlich machen und stets sichtbar halten.
Ich war nie jemand, der Risiken und Probleme versteckt hat, aber die Bedeutung von Projektransparenz wurde mir auf unverkennbare Weise klar.
3. Erinnern Sie sich an OS2?
Nein, niemand erinnert sich daran. Es ist eines von vielen gescheiterten Systementwicklungsprojekten. Ich arbeitete bei IBM, als das originale OS2 herauskam – ein Konkurrent zu Windows. Ich habe diese erste Version nicht einmal ausprobiert, denn bei IBM wussten wir alle, dass sie wirklich fehlerhaft war. Der Rest der Welt merkte schnell, dass sie zu viele Mängel hatte, um sich damit zu beschäftigen.
Sie war so fehlerhaft, dass das Projektteam unmöglich gedacht haben kann, sie sei ausgereift, aber irgendwie wurde nicht die richtige Entscheidung getroffen, den Release zu verschieben. Wenn man den menschlichen Faktor vernachlässigt – sowohl das eigene Team als auch die Kunden – wird ein wunderschöner Plan schnell zunichte gemacht.
In der Softwareentwicklung gibt es zahlreiche Alternativen zu dieser Situation: Man kann eine eingeschränkte Freigabe an Personen machen, die bereit sind, die Fehler in Kauf zu nehmen, nur um neueste Software zu erhalten, oder öffentlich kommunizieren, dass man mit der Veröffentlichung wartet, bis die Zuverlässigkeit den eigenen hohen Standards entspricht, usw.
Das war noch früh genug in meiner Karriere, um aus der Tatsache, dass ein Produkt, das ich liebte, bereits beim zweiten Release keine Zukunft mehr hatte, wertvolle Lehren zu ziehen.
Seien Sie eindeutig bei Ihren Prioritäten – es gibt nur wenige Fälle, in denen ein Veröffentlichungstermin wichtiger ist als die Produktqualität, aber sie sind selten.
Nutzen Sie Ihre vier Stellschrauben, gestehen Sie Fehler ein und machen Sie Korrekturen sichtbar, damit die Leute darauf vertrauen, dass Sie das Problem verstanden haben und den Fehler nicht wiederholen.
Beachten Sie den menschlichen Faktor – er ist genauso entscheidend wie die Technik. Diese Erkenntnisse habe ich von da an in alle Software- und IT-Projekte eingebracht, und sie waren von unschätzbarem Wert.
Das Fazit
Denken Sie immer daran, dass Sie zwar letztlich die Verantwortung tragen, aber nicht die ganze Arbeit selbst machen müssen. Im Gegenteil, Sie sollten auf keinen Fall versuchen, alles allein zu machen. Sie können vom reichen Erfahrungsschatz und Wissen Ihres Teams profitieren. Sie sind die Führungskraft, aber Sie müssen nicht das ganze Team sein.
Projektmanagement-Software und andere Projektmanagement-Tools können Ihnen helfen, Risiken, Meilensteine, Ressourcenzuweisung und andere entscheidende Indikatoren zu verfolgen, ob Sie auf dem Weg zu einem erfolgreichen Projekt sind.
