Warum Softwareprojekte scheitern und was man dagegen tun kann

Ich habe in den letzten fünfzehn Jahren an über vierzig Softwareprojekten mitgearbeitet, mal als Entwickler, mal als Berater, oft als jemand, der die Scherben zusammenkehren durfte. Das Muster wiederholt sich mit erschreckender Regelmäßigkeit. Nicht die Technik ist das Problem. Es sind die Leute, die Prozesse und die stillen Annahmen, die niemand ausspricht. Ein Projekt scheitert selten an einem einzelnen Fehler. Es scheitert an der Summe vieler kleiner Entscheidungen, die alle richtig aussahen, als man sie traf.

Die erste und häufigste Ursache ist ein Missverständnis über den Umfang. Jemand in der Geschäftsleitung sagt: «Wir brauchen eine Software, die unsere Lagerhaltung optimiert.» Was er meint, ist: «Wir brauchen ein System, das uns sagt, wann wir Nachschub bestellen müssen, ohne dass wir jeden Monat drei Überstunden machen.» Diese Lücke zwischen Wunsch und Bedarf wächst, je länger das Projekt läuft. Wenn ich mit neuen Teams arbeite, empfehle ich ihnen oft, sich konkrete Beispiele aus dem eigenen Betrieb anzusehen. Ein guter Ausgangspunkt ist eine Übersicht über die gängigen Anforderungen an Lager- und Bestandssoftware, wie sie etwa auf www.grumpi.com.de zu finden ist, einfach um ein Gefühl dafür zu bekommen, was andere Betriebe als Standard betrachten. Aber Vorsicht, solche Listen sind keine Spezifikation, sie sind nur ein Gesprächsstarter.

Der falsche Glaube an das Pflichtenheft

Viele Unternehmen bestehen auf einem detaillierten Pflichtenheft, bevor sie einen Entwickler auch nur ansehen. Das klingt professionell, ist aber oft kontraproduktiv. Ein Pflichtenheft friert den Wissensstand vom Tag eins ein. Drei Monate später hat sich der Markt geändert, der Chef hat eine neue Idee, und ein Wettbewerber hat ein Feature veröffentlicht, das niemand erwartet hat. Das Heft bleibt starr. Ich habe einmal ein Projekt begleitet, bei dem das Lastenheft achthundert Seiten umfasste. Die Software wurde zwölf Monate später fertig, und niemand wollte sie haben, weil die Anforderungen längst veraltet waren.

Besser ist ein iterativer Ansatz. Man baut ein kleines Stück, zeigt es dem Anwender, lernt daraus und baut das nächste Stück. Das setzt voraus, dass der Auftraggeber bereit ist, seine eigenen Wünsche zu hinterfragen. Das fällt vielen schwer. Sie zahlen schließlich für eine Lösung, nicht für einen Prozess. Aber genau dieser Prozess ist die eigentliche Arbeit. Die Software ist nur das Protokoll der Erkenntnisse.

Das Schweigen der Fachexperten

Ein weiteres Problem ist die Abwesenheit der richtigen Leute im Raum. Wer kennt den Arbeitsalltag? Nicht der Abteilungsleiter, sondern die Frau, die seit zwanzig Jahren die Bestellungen bearbeitet. Sie hat das Wissen über alle Ausnahmen, über die Sonderfälle, die niemand im Prozesshandbuch dokumentiert hat. In Projekten, die schiefgehen, fehlt genau diese Person. Der Abteilungsleiter gibt sein Bestes, aber er hat seit fünf Jahren selbst keine Bestellung mehr erfasst. Er beschreibt das System, wie es sein soll, nicht wie es ist.

Ich erinnere mich an ein Projekt im Großhandel, wo das Team drei Wochen lang Datenmodelle entwarf. Die Bestandsführung klappte nie. Erst als wir eine Lageristin in den Besprechungsraum holten, fiel auf, dass sie Barcodes auf eine bestimmte Art klebte, die der Scanner nicht lesen konnte. Zwei Minuten mit ihr, und das Problem war erklärt. Vorher hatte das Team wochenlang über die Software rätselnd diskutiert. Es ging nicht um Intelligenz, sondern um Zugang zum echten Arbeitsplatz.

Technische Schulden werden unsichtbar

Jede Software hat technische Schulden. Das ist normal und kein Beinbruch. Man nimmt eine Abkürzung, um einen Termin zu halten, und verspricht sich, es später zu bereinigen. Das Später kommt selten, weil immer etwas Dringenderes auftaucht. Nach zwei Jahren hat man einen Code, der aussieht wie ein Einkaufszentrum, das über Jahre wild erweitert wurde: ein Ladengeschäft hier, ein Parkhaus dort, kein roter Faden mehr.

Ein Kollege von mir nannte das die «Räumungsverkaufs-Architektur». Alles ist reduziert, nichts passt zusammen. Die Lösung ist nicht, teure Refactoring-Projekte zu starten, die die halbe Firma lahmlegen. Es genügt, beim Schreiben jedes neuen Codes eine halbe Stunde einzuplanen, um eine unsaubere Stelle auszubessern, die man gerade sieht. Kleine Schritte, keine Großprojekte. Die meisten Teams unterschätzen, wie viel fünfzehn Minuten sauberer Arbeit pro Tag über ein Jahr ausmachen.

Die Kommunikation zwischen Fachabteilung und Entwicklern

Ich höre oft den Satz: «Die Entwickler verstehen nicht, was ich meine.» Das stimmt meistens. Aber es liegt nicht an der Dummheit der Entwickler. Es liegt daran, dass die Fachabteilung in Bildern spricht und die Entwickler in Logik. Die Fachabteilung sagt: «Das System soll flexibel sein.» Der Entwickler fragt: «Flexibel in welcher Dimension? Anzahl der Lagerplätze? Wechsel der Einheiten? Saisonale Schwankungen?» Ohne diese Konkretisierung wird der Entwickler eine von tausend möglichen Interpretationen wählen, und fast sicher die falsche.

Was funktioniert, ist die Übersetzungsarbeit. Ich rate Teams, jeden Fachbegriff auf einen Zettel zu schreiben und nachzufragen, was er im konkreten Arbeitsablauf bedeutet. Das ist langweilig und klingt banal, aber es verhindert die meisten Missverständnisse. Ein weiterer Tipp: Lassen Sie den Entwickler einen Tag lang der Fachabteilung über die Schulter schauen. Nicht um zu programmieren, sondern um zuzuhören. Die Erkenntnisse daraus sind mehr wert als jede Anforderungsanalyse.

Der Termin als Feind der Qualität

Termine sind notwendig, keine Frage. Aber ein Termin, der von vornherein ohne fachliche Grundlage festgelegt wurde, richtet Schaden an. Ich habe Projekte gesehen, die am Ende schneller fertig waren als geplant und trotzdem gut. Deren Teams haben nicht gespart, sondern sie haben geschickt priorisiert. Sie haben gefragt: Was ist das Minimum, das wir brauchen, damit die Arbeit erleichtert wird? Alles andere kam später.

Der übliche Fehler ist andersherum. Das Team versucht, alle Funktionen gleichzeitig zu liefern, und am Ende ist alles mittelmäßig. Die Nutzer bekommen eine Software, die alle Klickwege kennt, aber keine einzige Abkürzung hat. Dann wird monatelang nachgebessert, was man beim ersten Mal hätte richtig machen können. Meine Erfahrung nach all diesen Jahren: Besser ein einfaches System, das hundert Prozent der Kernaufgaben zuverlässig löst, als ein komplexes, das bei neunzig Prozent liefert und die restlichen zehn Prozent mit Abstürzen quittiert. Die Anwender verzeihen fehlende Funktionen. Sie verzeihen keine instabilen Basisfunktionen.

Am Ende bleibt eine einfache Wahrheit. Softwareprojekte scheitern nicht an der Technik, sondern an der fehlenden Bereitschaft, Annahmen zu hinterfragen, echte Nutzer einzubeziehen und den Umfang konsequent klein zu halten. Wer diese drei Dinge ernst nimmt, hat gute Chancen, mit einem Produkt zu enden, das tatsächlich benutzt wird. Und das ist am Ende das einzige Kriterium, das zählt.