Warum Softwareprojekte scheitern

1. Niemand hat zugesehen, wie tatsächlich gearbeitet wird

Das häufigste Muster, mit Abstand. Anforderungen werden in einer Besprechung gesammelt, in der die Leute sitzen, die entscheiden – nicht die, die arbeiten. Was dabei entsteht, ist eine Beschreibung des Sollzustands aus dem Qualitätshandbuch.

Die Wirklichkeit sieht anders aus. Es gibt die Excel-Datei daneben, den Zettel an der Pinnwand, die Kollegin, die weiß, welche Kunden man nicht anmahnen darf. Diese Dinge stehen in keinem Lastenheft, und ohne sie funktioniert die neue Software nicht.

Gegenmittel: einen Tag danebensitzen. Das kostet acht Stunden und rettet regelmäßig Projekte.

2. Es wurde nie festgelegt, was nicht dazugehört

Jedes Konzept sagt, was gebaut wird. Wenige sagen, was bewusst nicht gebaut wird. Diese Lücke füllt sich im Projektverlauf von selbst – mit Erwartungen, die niemand ausgesprochen hat und alle für selbstverständlich halten.

Ein Konzept ohne Ausschlussliste ist kein Konzept, sondern eine Wunschsammlung.

3. Der Auftraggeber hat keine Zeit eingeplant

Eine Entwicklung braucht Entscheidungen: Wie soll dieser Sonderfall laufen? Welcher Preis gilt hier? Wer darf das freigeben? Wenn diese Fragen zwei Wochen auf Antwort warten, steht das Projekt zwei Wochen.

Realistisch sind zwei bis vier Stunden pro Woche auf Ihrer Seite, über die gesamte Laufzeit. Wer das nicht einplanen kann, sollte den Start verschieben statt das Budget kürzen.

4. Alles auf einmal

Das große System, das in neun Monaten fertig wird und dann alles ersetzt. Diese Projekte scheitern nicht am Ende – sie scheitern in Monat sechs, wenn sich die Anforderungen geändert haben und niemand mehr weiß, was eigentlich schon fertig ist.

Gegenmittel: Ausbaustufen, von denen jede für sich nutzbar ist. Nach der ersten Stufe wissen beide Seiten, ob die Zusammenarbeit trägt – bei überschaubarem Einsatz.

5. Die Datenübernahme wurde unterschätzt

„Die Daten spielen wir am Schluss ein.“ Dieser Satz hat schon viele Termine gekippt. Gewachsene Bestände enthalten doppelte Kunden, uneinheitliche Schreibweisen, leere Pflichtfelder und Artikelnummern, die zweimal vergeben wurden.

Das ist keine technische Aufgabe, sondern eine fachliche – und sie kann nur bei Ihnen entschieden werden. Deshalb gehört die Datenübernahme an den Anfang, nicht ans Ende.

6. Kein Verantwortlicher auf Kundenseite

Wenn drei Abteilungen widersprüchliche Anforderungen stellen und niemand entscheidet, entscheidet am Ende der Entwickler. Das geht selten gut aus.

Ein Projekt braucht auf Auftraggeberseite eine Person mit Entscheidungsbefugnis, die auch Nein sagen darf. Nicht ein Gremium, nicht einen Verteiler.

Was auffällt

Fünf dieser sechs Muster entstehen, bevor die erste Zeile Code geschrieben wird. Softwareprojekte scheitern fast nie an der Programmierung. Sie scheitern daran, dass zu früh mit dem Programmieren angefangen wurde.