Fast jeder, der schon einmal Software in Auftrag gegeben hat, kann eine Geschichte über ein misslungenes Projekt erzählen. Das Projekt verzögerte sich um Monate. Die Endkosten waren doppelt so hoch wie der Kostenvoranschlag. Die gelieferte Software funktionierte zwar technisch, löste aber das Problem nicht. Oder sie wurde nach dem Launch stillschweigend aufgegeben, weil sie niemand nutzte. Solche Fehlschläge sind so häufig, dass sie oft als unvermeidlich gelten, als Teil des Geschäftsrisikos im Umgang mit Technologie.
Sie sind jedoch nicht unvermeidlich. Betrachtet man viele Projekte, so sind die Ursachen für das Scheitern bemerkenswert einheitlich, und die meisten liegen eher in den Mitarbeitern und Prozessen als im Code. Das ist ermutigend, denn Mitarbeiter und Prozesse können von jedem, unabhängig von der Unternehmensgröße, verbessert werden, bevor auch nur eine Zeile Code geschrieben wird. Dieser Artikel beschreibt zwölf häufige Ursachen für das Scheitern von Softwareprojekten, erklärt, wie sich jede einzelne äußert, und bietet praktische Möglichkeiten, sie zu vermeiden. Dieser Text richtet sich sowohl an Unternehmer und Produktverantwortliche als auch an Entwickler.
Wie sieht Scheitern konkret aus?
Es ist wichtig, präzise zu sein, denn „Scheitern“ kann viele Formen annehmen.
- Budgetüberschreitung. Das Projekt kostet deutlich mehr als geplant.
- Terminüberschreitung. Die Lieferung erfolgt monatelang verspätet.
- Falsches Produkt. Die Software funktioniert, erfüllt aber nicht die tatsächlichen Bedürfnisse.
- Mangelhafte Qualität. Sie ist fehlerhaft, langsam oder unsicher.
- Geringe Akzeptanz. Die Software wird nicht genutzt.
- Projektabbruch. Das Projekt wird vor Fertigstellung gestoppt.
- Nicht wartbares Ergebnis. Es funktioniert zwar aktuell, aber niemand kann es ändern.
Ein Projekt kann auf die eine Weise scheitern und auf die andere erfolgreich sein. Die folgenden Ursachen führen häufig zu mehreren gleichzeitig.
1. Unklare oder sich ändernde Anforderungen
Dies ist die am häufigsten genannte Ursache. Wenn niemand genau sagen kann, was die Software leisten muss, entwickelt das Team eine möglichst genaue Schätzung. Diese Schätzung erweist sich meist als fehlerhaft, was sich erst später zeigt. Anforderungen verändern sich zudem ständig: Neue Ideen kommen immer wieder hinzu, und ohne einen festgelegten Prozess fließt jede Idee in das Projekt ein.
So lässt sich das verhindern:
- Erstellen Sie vor Projektbeginn ein leicht verständliches Briefing mit Nutzern, Zielen, Muss-Kriterien und Ausschlusskriterien. Eine einfache Struktur beschreiben wir in How to Write a Software Requirements Document.
- Führen Sie eine Liste mit Ideen für später, damit gute Ideen festgehalten werden und nicht verloren gehen oder erzwungen werden.
- Vereinbaren Sie, wie Änderungen vorgeschlagen, geschätzt und genehmigt werden.
2. Der Versuch, alles auf einmal zu entwickeln
Große erste Releases dauern lange, kosten viel und bringen erst nach ihrer Fertigstellung Erkenntnisse. Bis die Nutzer das Produkt sehen, können Annahmen, die vor einem Jahr getroffen wurden, falsch sein, und es fehlt an Geld und Energie, um sie zu korrigieren.
So beugen Sie dem vor:
- Entwickeln Sie die kleinste Version, die echten Mehrwert bietet und Ihre riskanteste Annahme testet.
- Veröffentlichen Sie in Etappen, die jeweils eigenständig nutzbar sind.
- Lesen Sie Was ist ein MVP? und MVP vs. Vollprodukt, um zu erfahren, wie Sie die richtige Grenze ziehen.
3. Unrealistische Schätzungen und Erwartungen
Der Druck, einen niedrigen Preis oder einen kurzen Zeitplan einzuhalten, verleitet Teams – manchmal bewusst – dazu, optimistische Zahlen anzugeben. Das Projekt gerät dann von Anfang an in Schwierigkeiten und bleibt es auch. Ein damit zusammenhängendes Problem ist die Behandlung einer frühen, groben Schätzung als verbindliche Zusage.
So vermeiden Sie das:
- Fragen Sie nach Kostenbereichen mit konkreten Annahmen, nicht nach einer einzelnen Zahl.
- Vergleichen Sie den Umfang, bevor Sie den Preis vergleichen.
- Planen Sie einen realistischen Puffer ein.
- Überarbeiten Sie die Schätzung, sobald das Projekt konkreter wird. Unser Leitfaden zur Schätzung eines Softwareprojekts erklärt, wie Schätzungen erstellt und interpretiert werden.
4. Fehlendes Verständnis der tatsächlichen Nutzer
Software wird oft von der Person spezifiziert, die dafür bezahlt, aber nicht unbedingt die Person ist, die sie nutzt. Funktionen, die in Meetings sinnvoll erscheinen, erweisen sich im Arbeitsalltag als unpraktisch, und die Nutzer suchen nach Umgehungslösungen, anstatt das System zu verwenden.
So beugen Sie dem vor:
- Sprechen Sie vor, während und nach der Entwicklung mit echten Nutzern.
- Beobachten Sie, wie die Arbeit heute tatsächlich erledigt wird, nicht nur, wie sie beschrieben wird.
- Testen Sie frühe Prototypen mit den zukünftigen Nutzern.
- Beziehen Sie regelmäßig einige Nutzer in Demos ein.
5. Schlechte Kommunikation
Distanz, Fachjargon, Annahmen und Schweigen führen zu Missverständnissen. Teams stimmen möglicherweise Dingen zu, die sie nicht verstehen, und Kunden schweigen, während die Unzufriedenheit wächst. Kleine Verständnislücken summieren sich zu großen Lücken im Produkt.
So beugen Sie dem vor:
- Vereinbaren Sie einen Kommunikationsrhythmus: Wer spricht mit wem, wie oft und über welche Kanäle.
- Bestehen Sie auf regelmäßigen Demos funktionierender Software, nicht nur auf Statusberichten.
- Dokumentieren Sie Entscheidungen und kommunizieren Sie diese.
- Fragen Sie: „Was verstehen Sie darunter?“ Statt von einer Einigung auszugehen.
- Ermutigen Sie dazu, schlechte Nachrichten frühzeitig anzusprechen. Eine Kultur, in der Probleme verschwiegen werden, führt zum Scheitern. Informationen zur Remote-Arbeit finden Sie unter Outsourcing von Softwareentwicklung: Wie es funktioniert.
6. Die Wahl des falschen Partners
Ein Team mit der falschen Erfahrung, unzureichender Seniorität, schwachen Prozessen oder der Angewohnheit, zu viel zu versprechen, kann selbst ein gut definiertes Projekt zum Scheitern bringen. Die Warnsignale sind bei der Auswahl erkennbar, wenn man weiß, worauf man achten muss.
So beugen Sie vor:
- Prüfen Sie die Erfahrung in ähnlichen Projekten und sprechen Sie mit ehemaligen Kunden.
- Lernen Sie die Personen kennen, die die Arbeit tatsächlich ausführen werden.
- Beginnen Sie mit einem kleinen bezahlten Projekt, um die Zusammenarbeit zu testen.
- Achten Sie auf Warnsignale: Angebote ohne Rückfragen, Druck zur schnellen Vertragsunterzeichnung, keine Erwähnung von Tests oder Verantwortlichkeiten.
- Nutzen Sie die Checkliste in Wie man ein Softwareentwicklungsunternehmen auswählt.
7. Schwache Führung und Entscheidungsfindung auf Kundenseite
Projekte geraten ins Stocken, wenn auf Kundenseite niemand die Verantwortung für Entscheidungen übernimmt. Fragen bleiben tagelang unbeantwortet, Prioritäten ändern sich mit jedem Meeting und verschiedene Beteiligte geben widersprüchliche Anweisungen. Das Entwicklungsteam kann das nicht beheben, egal wie gut es ist.
So lässt es sich verhindern:
- Eine Person mit Entscheidungsbefugnis für Produktfragen benennen.
- Festlegen, wie Stakeholder Feedback geben und wer Konflikte löst.
- Fragen schnell beantworten. Verzögerungen kosten genauso viel wie Entwicklerstunden.
- Das Team vor ständiger Neupriorisierung schützen.
8. Überspringen von Recherche und Planung
Direkt mit der Entwicklung zu beginnen, mag produktiv erscheinen, aber zu entwickeln, bevor man verstanden hat, ist ein teurer Weg zu lernen. Unbekannte Faktoren wie Integrationen, Datenqualität und technische Einschränkungen treffen das Projekt mitten in der Entwicklung, wenn Kursänderungen kostspielig sind.
So beugen Sie dem vor:
- Investieren Sie in eine kurze Analysephase: Klären Sie Ziele, Nutzer, Umfang und Risiken.
- Erstellen Sie Wireframes oder einen Prototyp vor der eigentlichen Entwicklung.
- Untersuchen Sie Unbekanntes frühzeitig, z. B. ob ein Drittanbietersystem tatsächlich die benötigten Daten liefert.
- Betrachten Sie die Analysephase als Teil des Projekts, nicht als zusätzlichen Aufwand.
9. Unzureichende Test- und Qualitätssicherungspraktiken
Wenn Zeitpläne enger werden, wird als Erstes an den Tests gespart. Das Ergebnis ist Software, die in Demos funktioniert, aber im realen Einsatz versagt, wobei die Fehler von den Kunden entdeckt werden. Mangelnde Qualität macht jede spätere Änderung riskanter und langsamer.
So lässt sich das verhindern:
- Automatisierte Tests für die wichtigsten Teile wie Zahlungen, Berechtigungen und Kernregeln fordern.
- Code-Reviews und Tests in die Aufwandsschätzung einbeziehen und nicht stillschweigend vernachlässigen.
- Mit realistischen Daten und auf echten Geräten und Browsern testen.
- Benutzer vor dem Launch in die Akzeptanztests einbeziehen.
10. Nicht-funktionale Anforderungen ignorieren
Teams konzentrieren sich auf Funktionen und vernachlässigen Sicherheit, Leistung, Zuverlässigkeit und Barrierefreiheit, bis diese zu Problemen führen. Ein System, das für zehn Benutzer funktioniert, kann bei tausend Benutzern zusammenbrechen, und nachträglich hinzugefügte Sicherheit ist schwächer und teurer.
So lässt sich das verhindern:
- Erwartungen an Geschwindigkeit, Verfügbarkeit, Sicherheit und Skalierbarkeit in den Anforderungen festlegen.
- Diese Aspekte im Design berücksichtigen, nicht erst in den letzten Wochen.
- Überwachung und Backups einplanen.
- Die Sicherheit gezielt überprüfen; Für Apps siehe unsere Checkliste für die Sicherheit mobiler Apps.
11. Vernachlässigung von Eigentum, Dokumentation und Übergabe
Manche Projekte sind am Tag der Auslieferung erfolgreich, scheitern aber danach, weil niemand das Ergebnis weiterverfolgen kann. Der Code befindet sich im Account des Anbieters, nichts ist dokumentiert, und die einzige Person, die ihn verstanden hat, ist nicht mehr dabei.
So lässt sich das verhindern:
- Bestehen Sie darauf, dass der Code vom ersten Tag an in Ihrem eigenen Repository liegt.
- Fordern Sie eine Dokumentation von Einrichtung, Architektur und wichtigen Entscheidungen an.
- Sorgen Sie für eine ordnungsgemäße Übergabe, inklusive Schulungen, falls erforderlich.
- Planen Sie die Kontinuität: Was passiert, wenn jemand das Unternehmen verlässt? Siehe Dediziertes Team vs. Freelancer vs. Inhouse-Entwickler.
12. Vergessen der Zeit nach dem Launch
Der Launch wird oft als Abschluss betrachtet. Tatsächlich ist es der Beginn von echtem Feedback und der laufenden Kosten für Hosting, Updates und Verbesserungen. Produkte ohne einen Plan für die Zeit nach dem Launch verlieren an Wert, und die Nutzer merken es.
So beugen Sie dem vor:
- Planen Sie von Anfang an ein Budget für die Wartung ein; eine gängige Richtlinie sind 15 bis 20 Prozent der Entwicklungskosten pro Jahr. Siehe Softwarewartungskosten.
- Definieren Sie Erfolgskriterien und überprüfen Sie diese nach dem Launch.
- Planen Sie die nächste Phase basierend auf dem tatsächlichen Nutzerverhalten.
- Legen Sie fest, wer die tägliche Verantwortung für das Produkt übernimmt.
Muster hinter den Ursachen
Betrachtet man die zwölf Punkte, wiederholen sich mehrere Themen.
- Unsicherheit wird nicht gemanagt. Projekte, die davon ausgehen, alles zu wissen, werden ständig überrascht.
- Feedback kommt zu spät. Frühzeitige Sichtung der realen Software ist der beste Schutz.
- Niemand ist für das Ergebnis verantwortlich. Die Verantwortung ist diffus.
- Der Umfang wächst stillschweigend. Ohne sichtbare Kompromisse wächst er immer.
- Kurzfristiger Druck siegt über langfristiges Wachstum. Abkürzungen, die zur Einhaltung eines Termins genommen werden, rächen sich später in Form von Kosten.
Ein gesundes Projekt macht das Gegenteil: Es erkennt Unsicherheit an, zeigt regelmäßig den Arbeitsfortschritt, hat klare Verantwortlichkeiten, macht Kompromisse sichtbar und schützt Qualität.
Frühe Warnzeichen
Probleme frühzeitig erkennen. Achten Sie auf Folgendes:
- Demos werden ständig verschoben oder sind „fast fertig“.
- Dieselben Aufgaben bleiben wochenlang „in Bearbeitung“.
- Anforderungen ändern sich ohne Absprache über Kosten oder Zeitaufwand.
- Fragen an das Team werden vage beantwortet.
- Es gibt keine funktionierende Software, nur Berichte.
- Probleme werden nicht mehr gemeldet.
- Die Kostenschätzung wurde nie erläutert und ändert sich ständig.
- Tests sollen „am Ende durchgeführt werden“.
Wenn Sie mehrere dieser Punkte bemerken, halten Sie inne und starten Sie neu: Überprüfen Sie den Projektumfang, überarbeiten Sie den Plan und führen Sie wieder regelmäßige Demos durch.
Was erfolgreiche Projekte gemeinsam haben
- Ein klares, schriftliches Ziel und eine vereinbarte erste Version.
- Ein verantwortlicher Ansprechpartner auf Kundenseite.
- Kurze Lieferzyklen mit sichtbarer, funktionierender Software.
- Ehrliche Kommunikation, auch bei Problemen.
- Qualität integriert durch: Tests, Reviews und Dokumentation.
- Faire, transparente Geschäftsbedingungen und klare Verantwortlichkeiten.
- Ein Plan für die Zeit nach dem Launch.
- **Die Bereitschaft Kursänderungen vorzunehmen, wenn die Beweislage es nahelegt.
Nichts davon erfordert besonderes Genie. Es erfordert Disziplin und einen Partner, der diese teilt. Unser Vorgehen ist auf der Seite Vorgehensweise beschrieben. Die gleichen Vorgehensweisen gelten unabhängig davon, ob Sie mit uns oder einem anderen Unternehmen zusammenarbeiten.
Checkliste vor Projektbeginn
Bevor Sie beginnen, stellen Sie sicher, dass Sie jede der folgenden Fragen mit „Ja“ beantworten können.
- Wir können das Problem und das Ziel in wenigen Sätzen beschreiben.
- Wir kennen die Nutzer und haben bereits mit einigen von ihnen gesprochen.
- Die erste Version ist definiert, alle weiteren Versionen werden später veröffentlicht.
- Wir haben ein schriftliches Briefing und eine Kostenschätzung mit Annahmen.
- Eine Person in unserem Unternehmen ist für die Entscheidungen verantwortlich.
- Wir haben unseren Partner sorgfältig ausgewählt und die Zusammenarbeit anhand eines kleinen Projekts getestet.
- Wir werden regelmäßig funktionierende Software erhalten.
- Tests, Dokumentation und Codeverantwortung sind im Vertrag festgelegt.
- Das Budget beinhaltet einen Puffer und die Kosten nach dem Launch.
- Wir wissen, wie wir den Erfolg messen werden.
Abschließende Gedanken
Softwareprojekte scheitern selten an einem einzigen schwerwiegenden Fehler. Sie scheitern an einer schleichenden Anhäufung kleiner, vermeidbarer Fehler: eine unklare Anforderung hier, eine ausgelassene Demo dort, eine Entscheidung, für die niemand die Verantwortung übernahm. Die gute Nachricht: Dasselbe gilt für Erfolg. Ein Projekt, das klar definiert, in Etappen umgesetzt, ehrlich kommuniziert und sorgfältig entwickelt wird, hat sehr gute Erfolgschancen.
Wenn Sie ein Projekt planen und einen Partner suchen, der so arbeitet, sprechen Sie mit uns. Wir helfen Ihnen, eine realistische erste Version zu definieren, einen Rhythmus zu etablieren, der alle Beteiligten auf Kurs hält, und informieren Sie frühzeitig, wenn wir ein Problem erkennen.