Skip to main content

Warum scheitern so viele Projekte? Eine häufig zitierte Statistik besagt, dass 70 % der Projekte scheitern. Auch wenn es keine eindeutige Ursprungsquelle für diese Zahl zu geben scheint, lohnt es sich dennoch, die Ursachen für das Scheitern von Projekten zu hinterfragen. Wenn wir aus vergangenen Projektmisserfolgen lernen, können wir vermeiden, die gleichen Fehler erneut zu machen.

Als ich zum ersten Mal als Projektmanager arbeitete, lernte ich alles über Projektmanagement-Pannen auf die harte Tour: Fehleinschätzungen, das Vergessen wichtiger Fragen und die Zurückhaltung, auch mal Nein zu sagen.

Obwohl ich mittlerweile seit vielen Jahren als Projektmanager tätig bin, habe ich trotzdem Projekte auf spektakuläre Weise an allerlei Gründen scheitern sehen. In diesem Artikel erkläre ich, was Projekte zu Misserfolgen macht, warum sie letztlich scheitern und gebe Tipps, wie sich Scheitern vermeiden lässt.

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.

Step 1 of 2

This field is for validation purposes and should be left unchanged.
Name*
This field is hidden when viewing the form

Wann gelten Projekte als gescheitert?

Projekte gelten als gescheitert, wenn sie das Budget überschreiten, verspätet geliefert werden oder nicht wie geplant im vollen Umfang abgeschlossen werden. Oft gibt es hierbei jedoch einen gewissen Spielraum. Projekte werden häufig aus Gründen verzögert, die außerhalb des Einflussbereichs des Projektmanagers liegen (z. B. wenn der Kunde die Website-Inhalte nicht rechtzeitig liefert).

Auch der Umfang eines Projekts kann sich im Verlauf verändern, zum Beispiel durch neue Anforderungen der Kunden oder Stakeholder. Obwohl Scope Creep (stetige Ausweitung des Projektumfangs) ein häufiger Grund für das Scheitern von Projekten sein kann, muss dies bei richtigem Umgang (mit Change Requests und Absegnung durch wichtige Stakeholder) nicht zwangsläufig zu Misserfolg führen.

6 häufige Gründe, warum Projekte scheitern & Beispiele

Doch warum scheitern Projekte? Hier sind fünf meiner größten Projektmanagement-Pannen, die typische Ursachen für das Scheitern von Projekten verdeutlichen, sowie die wichtigen Erkenntnisse aus vergangenen Projekten, die ich daraus gezogen habe, um zukünftige Projekte erfolgreicher zu machen.

1. Nicht kommunizieren, wenn es schwierig wird

Es ist ein menschlicher Instinkt, nicht auf sich aufmerksam machen zu wollen, wenn etwas schief gelaufen ist und es noch niemand bemerkt hat. Das ist genau das Gegenteil dessen, was im Projektmanagement erforderlich ist – aber mangelhafte Kommunikation ist einer der Hauptgründe, warum Projekte scheitern.

Ich muss zugeben, die Kombination aus einem sehr anspruchsvollen Kunden und einem Budget oder Zeitplan, der kurz davor steht, überschritten zu werden, hat mich manchmal zu lange zögern lassen, dem Kunden den Status seines Projekts mitzuteilen.

Gerade wenn es in den letzten Tagen oder Wochen in einem Projekt ruhig und reibungslos lief, ist es die verletzlichste Phase – es ist immens wichtig, das in den Projektmanager gesetzte Vertrauen des Kunden zu bewahren und weiter auszubauen.

Join the DPM community for access to exclusive content, practical templates, member-only events, and weekly leadership insights - it’s free to join. <br><br>

Join the DPM community for access to exclusive content, practical templates, member-only events, and weekly leadership insights - it’s free to join.

This field is for validation purposes and should be left unchanged.
Name*
This field is hidden when viewing the form

Gelerntes daraus:

Jedes Mal, wenn ich innehalte, bevor ich einem Kunden eine schlechte Nachricht überbringe, frage ich mich: Ist es besser, jetzt die Erwartungen zu steuern, oder möchte ich das Problem lieber erst angehen, wenn es zu spät ist? Die Antwort ist IMMER: Sofort handeln und proaktiv sein.

Damit legst du außerdem den Grundstein dafür, zukünftig unrealistischen Erwartungen eines bestimmten Kunden besser begegnen zu können.

2. Nicht beim vereinbarten Umfang bleiben

Bei einem besonders detailreichen Projekt schlug ein Teammitglied, das eng mit mir zusammenarbeitete, vor, für einen Portfolio-Bereich auf der Kundenseite ein neues Slider-Plugin zu testen.

Es basierte auf einem Framework, mit dem wir sonst nicht arbeiteten, aber der Slider sah anspruchsvoller aus und funktionierte eleganter als der, den wir sonst nutzten. Ich war zunächst zögerlich, wegen des engen Zeitplans und der genauen Designvorgaben des Projekts, ließ mich aber von den angeblichen Vorteilen für den Kunden UND unser Entwicklerteam überzeugen.

Die Aktualisierung dieser Komponente hatten wir zuvor nie diskutiert, aber es schien eine gute Gelegenheit, das neue Plugin im Einsatz zu sehen.

Am Ende war das eine der kostspieligsten Entscheidungen des Projekts – hinsichtlich Arbeitsstunden und Budget. Der Slider unterstützte ein zentrales Feature nicht und ließ sich nicht einfach für responsive Größen oder bestimmte Browser konfigurieren.

Die Auswahl wurde nicht wie sonst üblich durch das technische Führungsteam und weitere Entwickler als geplante Weiterentwicklung bewertet und beschlossen. Es war ein unglaublich einfacher Fehler, der uns beiden viel Stress, Ärger und Ressourcen gekostet hat.

Den Projektumfang unnötig durch zusätzliche Liefergegenstände oder überkomplizierte Aufgaben zu erweitern – auch als „Gold Plating“ bekannt – ist ein weiterer typischer Grund, warum Projekte scheitern.

Gelerntes daraus:

Bleib deinen Prozessen treu und ändere Dinge nicht aus dem Bauch heraus. Sollten Teammitglieder tatsächlich von Änderungen an Prozessen oder Tools profitieren (einschließlich Projektmanagement-Software oder anderen Projektmanagement-Tools und Technologien) während eines Projekts, gehe alle nötigen Prüfungen und Freigaben durch.

3. Zu freundschaftlich mit Team und Kunden werden

Es gibt eine deutliche Trennung zwischen beruflichen Beziehungen und privaten Freundschaften, und ich habe gelernt, diese durch sorgfältige Übung zu wahren.

Das heißt nicht, dass man nicht mit seinen Teamkollegen oder Kunden befreundet sein kann—man sollte sich jedoch bewusst sein, wann man im Umgang die Professionalität ein- oder ausschaltet.

Vor Jahren arbeitete ich in einer Firma voller Menschen, die gerade frisch von der Uni kamen, alle mit ähnlichen Interessen und die auch noch in derselben Stadt in der Nähe lebten. Es war ganz natürlich, dass wir nach der Arbeit und am Wochenende zusammen Zeit verbrachten und enge Freundschaften entstanden.

Eines Tages musste ich um eine schnelle Umsetzung bei einem Projekt bitten, das niemand besonders mochte—es war weder schön noch spannend, und wurde von den meisten Leuten weder wahrgenommen noch geschätzt.

Der Designer im Projekt überschritt den Abgabetermin und arbeitete stattdessen an einem größeren, moderneren Webdesign, das erst in Wochen fertig sein musste. Ich sprach ihn darauf an und er fragte mich, warum ich so streng zu ihm sei, wo wir doch eigentlich Freunde sind.

Wenn die Grenzen zwischen Persönlichem und Beruflichem verschwimmen, ist das manchmal ein Grund dafür, warum Projekte scheitern, da dies die Verantwortlichkeit beeinträchtigen kann.

Lektion gelernt:

Sei freundlich, aber bewahre Professionalität, um weiterhin Menschen für ihre Handlungen in einem Projekt verantwortlich machen zu können. Es ist viel leichter, dass wir bei Freunden ein "Augenzudrücken" erwarten, und das kann eine gefährliche (und peinliche) Situation sein, wenn sich das mit beruflichen Verpflichtungen vermischt.

4. In Panik geraten, bevor man Zeit hat, alles zu verarbeiten

Vielleicht geht es nur mir so, aber ich reagiere leicht auf bestimmte Warnzeichen oder Schlüsselbegriffe in Projekten.

Dinge wie E-Mails in Großbuchstaben, die Wörter „neue Deadline“ oder „Seite offline“, oder auch unscheinbarere Warnsignale wie fehlende Kommunikation an einem entscheidenden Punkt eines Projekts, ein neuer Stakeholder, der kurz vor dem Launch ins Projekt geholt wird oder seltsame Fehler auf einer Seite kurz vor einer Kundendemonstration.

Nichts bringt mich mehr aus der Fassung, als sofort einen Manager, Entwickler oder Kunden um Klarstellung zu bitten, obwohl mir etwas klar gewesen wäre (oder ich es selbst hätte lösen können), wenn ich mir einen Moment Zeit zum Durchatmen und Nachdenken genommen hätte.

Es gab schon so viele Situationen, in denen ich dachte, es läge ein schwerwiegender Bug auf einer Seite vor (obwohl es eigentlich nur ein Problem mit meinem eigenen oder dem Cache des Kunden war), ich einen Feature-Wunsch viel größer verstanden habe als tatsächlich gemeint, oder ein Kunde dachte, seine Website/sein Server wäre offline, als er in Wahrheit nur keine Internetverbindung hatte (ja, das passiert häufig).

Auch wenn dies kein großer Projektfehler für sich ist, trägt es zu schlechter Kommunikation bei und kann Panik auslösen, wenn diese gar nicht nötig ist.

Lektion gelernt:

Hab keine Angst davor, eine reaktive E-Mail oder Nachricht wegzulegen, kurz innezuhalten und erst einmal selbst nachzuforschen, bevor du um weitere Hilfe bittest.

5. Prozesse nicht einhalten

Ach ja: der Trugschluss, dass „dieser Punkt ausnahmsweise nicht durch unseren üblichen Entwicklungs-/Design-/Review-/QA-Prozess muss, weil es ja nur eine kleine Änderung ist“. Genau das ist so oft der Grund, warum Projekte scheitern.

Ich habe das sehr oft bei Projekten erlebt. Ich selbst habe diesen Fehler bei scheinbar „einfachen“ Wartungs-Updates, kleinen Feature-Anfragen in größeren Projekten und bei Scope-Änderungen jeder Art gemacht.

Etwas wie das Aktualisieren einer Formularfeld-Option scheint oberflächlich einfach, kann jedoch zu Spaghetti-Code und einem System-Update werden, sobald ein Entwickler tiefer einsteigt.

Ebenso kann eine kleine optische Änderung, die sich ein Kunde wünscht, den Designprozess durcheinanderbringen und dazu führen, dass man einen Teil des gesamten Websiteflows überdenken muss.

Lektion gelernt:

Vertraue immer auf den Prozess und gehe entsprechend durch Discovery-, Schätzungs- und QA-Prozesse: Ich habe gelernt, dass es keine Änderung gibt, die klein genug ist, um nicht irgendwo etwas anderes zu beeinflussen.

Schütze deinen Prozess und setze dich dafür ein, Dinge richtig zu machen—auch wenn das ein wenig mehr Aufwand bedeutet. Das heißt auch, die passende Projektmanagement-Methode oder den richtigen Workflow zu wählen, ob agil, Wasserfall, Kanban oder eine hybride Variante.

6. Keine klaren Ziele festlegen

Projekte sollten von Beginn an klare, messbare Projektziele haben (auch als SMART-Ziele bekannt). Wie sollen wir wissen, ob wir an einem erfolgreichen Projekt arbeiten, wenn wir den Fortschritt nicht an etwas messen können?

Als Teil des Planungsprozesses werden Meilensteine, Ziele und Erfolgskriterien festgelegt. Überlege dir deinen Projektzeitplan, die Anforderungen und das Budget. Wähle die KPIs, die für dein Projekt oder Vorhaben am sinnvollsten sind.

Dies ist eine der häufigsten Ursachen für das Scheitern von Projekten. Ohne diese wissen die Teammitglieder (und Sie selbst!) nicht, ob Sie im Hinblick auf Zeitplan, Umfang und Budget auf dem richtigen Weg sind. Sie häufen verpasste Fristen und Budgetüberschreitungen an, bevor Sie überhaupt bemerken, dass etwas nicht stimmt.

Lektion gelernt:

Legen Sie immer KPIs und Kennzahlen für Ihre Projekte fest, auch für kleinere Projekte, bei denen dies möglicherweise unnötig erscheint oder wie ein zusätzlicher Schritt wirkt, um etwas zu bestimmen, das Sie bereits zu wissen glauben. Möglicherweise stellen Sie fest, dass Ihre Projektziele und KPIs nicht übereinstimmen – was Ihnen später eine Menge Kopfschmerzen ersparen kann.

3 Schritte, um Projektversagen zu vermeiden

Ein Ansatz, um Projektscheitern zu verhindern, besteht darin, Projektbewertungen an mehreren Punkten im Verlauf des Projekts durchzuführen. Hier sind drei Schritte, die es zu beachten gilt:

  1. Risiken identifizieren: Normalerweise machen Sie dies im Rahmen der Erstellung des Projektplans. Halten Sie Risiken in einem Risikoregister oder RAID-Log fest.
  2. Risiken bewerten: Bewerten Sie die Wahrscheinlichkeit und den Einfluss jedes Risikos. Risiken, die sehr wahrscheinlich eintreten und die größte negative Auswirkung hätten, sollten höchste Priorität erhalten.
  3. Erstellen Sie Pläne zum Risikomanagement und Notfallpläne: Was werden Sie tun, wenn ein bestimmtes Risiko eintritt? Wie können Sie die Wahrscheinlichkeit für das Auftreten dieses Risikos verringern?

Lesen Sie mehr darüber, wie Sie Projektscheitern vermeiden können.

Was denken Sie?

Dies sind einige der häufigsten Gründe für das Scheitern von Projekten, aber nicht die einzigen. Möglicherweise stoßen Sie auch auf fehlende Ressourcen, mangelnde Teamarbeit und verschiedene andere Probleme. Das Wichtigste ist, wachsam zu bleiben, die Kommunikationskanäle offen zu halten und sicherzustellen, dass Sie Risiken adressiert haben, die Ihr Projekt gefährden könnten.

Bringen Sie Ihre Fähigkeiten im Projektmanagement mit einem dieser fundierten Kurse zum Risikomanagement auf das nächste Level.

Natalie Semczuk

Natalie ist eine konsultative digitale Projektmanagerin, die remote arbeitet und im Südwesten der USA lebt. Ihre Arbeit konzentriert sich auf die Beratung kleiner bis mittlerer Agenturen und interner Webabteilungen bei der Verwaltung digitaler Projekte, Kundenservices und der Implementierung von Prozessen, die es Design- und Entwicklungsteams ermöglichen, besser zusammenzuarbeiten. Sie ist außerdem spezialisiert auf die Implementierung von Projektsystemen in Remote-Teams. Natalie leitet den PM Reactions Blog und genießt dystopische Literatur, Yoga und Kaffeetrinken. Du findest sie anderweitig auf Twitter @talkanatalka oder auf ihrer Website, talkanatalka.com.