Warum Softwareprojekte scheitern – und fünf Prüfungen dagegen

Wenn ein Softwareprojekt scheitert, wird die Geschichte meist als technische erzählt: das falsche Framework, ein Entwickler, der nicht geliefert hat, eine Integration, die schwieriger war als erwartet.

Das ist fast nie das, was tatsächlich passiert ist. Die technische Schwierigkeit war real, aber sie war ein Symptom. Das Scheitern wurde in den ersten zwei Wochen durch eine von fünf Entscheidungen besiegelt und fünf Monate später entdeckt.

1. Niemand konnte den Prozess beschreiben

Die häufigste Ursache, und die am wenigsten technische.

Software bildet einen Prozess ab. Wenn der Prozess nicht abgestimmt ist — wenn zwei Abteilungen ihn unterschiedlich beschreiben oder er nur im Kopf einer einzigen Person existiert —, dann kann die Software nicht gebaut werden, weil es nichts zu bauen gibt.

Entwicklung löst das nicht. Sie verwandelt eine ungeklärte Meinungsverschiedenheit in eine teure, die erst bei der Abnahme auffällt, wenn jede Seite etwas sieht, das sie nicht freigegeben hat.

Die Prüfung: Können zwei Personen aus verschiedenen Bereichen des Unternehmens den Prozess gleich beschreiben, schriftlich, bevor irgendjemand ein Angebot abgibt? Wenn nicht, ist genau das das Projekt, und zwar ein Organisationsprojekt, kein Softwareprojekt.

2. Der Entscheider war nicht im Raum

Anforderungen werden bei den Menschen erhoben, die das System nutzen werden. Vernünftig. Die Freigabe kommt dann aber von jemandem, der nie an diesen Gesprächen teilgenommen hat, das Ergebnis am Ende zum ersten Mal sieht und Änderungen verlangt, die bis an die Fundamente reichen.

Die Prüfung: Wer unterschreibt die Schlussrechnung, und hat diese Person den Leistungsumfang persönlich geprüft? Wenn nicht, holen Sie das nach, bevor die Arbeit beginnt. Keinen Statusbericht — den tatsächlichen Leistungsumfang.

3. Die Integration wurde für einfach gehalten

Ein neues System muss fast immer mit einem alten sprechen. Das neue System wird im Detail beschrieben; das alte ist eine einzige Zeile: "Anbindung an das bestehende Kassensystem".

Die Schwierigkeit hängt allein vom alten System ab, und niemand prüft sie, bevor er sich festlegt. Eine dokumentierte API bedeutet Tage. Ein geschlossenes System mit einem nächtlichen CSV-Export bedeutet Wochen und Kompromisse. Ein System, dessen Anbieter verschwunden ist, kann unmöglich sein.

Die Prüfung: Lassen Sie sich vor der Unterschrift die API-Dokumentation jedes Systems zeigen, das angebunden werden muss. Kein Versprechen, dass es sie gibt — das tatsächliche Dokument. Diese eine Prüfung verhindert mehr Budget- und Terminüberschreitungen als jede andere auf dieser Liste.

4. Es gab keine erste Version

Ein Projekt, das als eine einzige Lieferung nach zwölf Monaten angelegt ist, bekommt bis zum zwölften Monat keine Rückmeldung. Bis dahin hat sich das Geschäft verändert, die Menschen haben gewechselt, und die Anforderungen aus dem ersten Monat sind veraltet.

Die Prüfung: Lässt sich das Vorhaben in Teile schneiden, die jeweils für sich funktionieren? Wenn nicht, ist der Umfang zu verflochten, und diese Verflechtung ist selbst das Risiko. Das Restaurantprojekt in Warenverlust um ein Drittel senken ging genau aus diesem Grund in vier Stufen live.

5. Niemand war intern verantwortlich

Jedes erfolgreiche Projekt hat eine Person im Unternehmen, die will, dass es entsteht, die entscheiden darf und die Zeit hat. Fehlt diese Person, stauen sich die Entscheidungen, der Dienstleister rät, um voranzukommen, und die Vermutungen bauen aufeinander auf.

Die Prüfung: Benennen Sie diese Person und stellen Sie sicher, dass sie mehrere Stunden pro Woche dafür hat. "Alle sind verantwortlich" heißt: niemand.

Die fünf Prüfungen im Überblick

Keine davon erfordert technisches Wissen. Alle fünf lassen sich in einer Woche überprüfen, und diese Woche ist die ertragreichste des gesamten Projekts.

Die teuren Fehler werden gemacht, bevor jemand Code schreibt. Sie werden nur erst danach entdeckt.

Wie Scheitern tatsächlich aussieht

Selten dramatisch. Meist so: Die Lieferung verschiebt sich um einen Monat, dann um noch einen. Der Umfang wird gekürzt, um einen Termin zu halten. Was ausgeliefert wird, funktioniert, wird aber nicht genutzt, weil es nicht zum Prozess passt. Sechs Monate später kehrt jemand stillschweigend zur alten Tabelle zurück.

Niemand nennt es Scheitern. Es heißt dann "das System, das wir gekauft haben und eigentlich nicht nutzen", und die meisten Unternehmen haben eines davon.

Häufige Fragen

Wessen Schuld ist es meistens?

Sie ist geteilt, und die Aufteilung hilft nicht weiter. Dienstleister sollten Projekte ablehnen, bei denen diese fünf Punkte nicht erfüllt sind, und die meisten tun es nicht. Kunden sollten sie sicherstellen, und die meisten gehen davon aus, dass der Dienstleister das übernimmt.

Lässt sich ein Projekt retten, wenn es schiefläuft?

Oft ja, wenn Sie anhalten und die fünf Prüfungen erneut durchgehen. Was nicht funktioniert, ist, mehr Leute hinzuzunehmen oder die Frist zu verlängern, während die zugrunde liegende Entscheidung weiter aussteht.

Wie vermeiden wir das mit einem Dienstleister, mit dem wir noch nicht gearbeitet haben?

Beginnen Sie mit einem kleinen bezahlten Projekt — dem Test aus wie Sie ein Softwareunternehmen auswählen. Zwei bis vier Wochen bringen alle fünf Punkte ans Licht, zu einem Bruchteil der Kosten, die es hätte, sie erst im sechsten Monat zu entdecken.