Die meisten Entscheidungen im Softwareprojekt fallen entweder zu früh oder zu spät. Wer zu früh entscheidet, hat zu wenig Informationen. Wer zu spät entscheidet, verpasst den Moment. Und dann gibt es eine dritte Variante, die besonders teuer ist: Es wird gar nicht entschieden, weil die perfekte Lösung noch nicht gefunden ist. Für alle drei Fälle gilt bei uns seit Jahren dasselbe Motto: so früh wie notwendig und so spät wie möglich.

Zu früh entschieden: Festlegung ohne Grundlage

Das Schwierigste an einer Entscheidung ist oft nicht die Entscheidung selbst, sondern der Zeitpunkt. Je später entschieden wird, desto mehr Kontext und Klarheit liegen vor. Eine früh getroffene Entscheidung wird dagegen schnell zur Vorgabe, an der sich andere Arbeit ausrichtet. Je mehr darauf aufbaut, desto teurer wird jede Korrektur.

In der Praxis begegnen uns Menschen, die sofort entscheiden wollen, auch wenn es noch gar nicht nötig ist. Die Gegenfrage lautet: Warum heute festlegen, was erst in drei Monaten relevant wird? Gerade in der IT ändern sich Technologien, und Anforderungen verschieben sich.

Zu spät entschieden: Warten auf die letzte Information

Das andere Extrem sind Menschen, die warten, bis jede Unbekannte aufgelöst ist. Diesen Zeitpunkt gibt es oft nicht, oder er kommt viel zu spät. Unbekannte bleiben immer. Eine Entscheidung mit 80 Prozent der Informationen ist besser als gar keine. Lieber heute mit Unbekannten entscheiden als morgen zu spät.

Wer auf perfekte Information wartet, wartet oft zu lange. Dasselbe Muster gibt es auf der Ebene des ganzen Projekts, und dort heißt es Perfektionismus.

Perfektionismus: die getarnte Blockade

Die größte Gefahr für ein Softwareprojekt ist selten schlechte Qualität. Häufiger ist es Perfektionismus. CIOs, CTOs und IT-Leiter sagen uns regelmäßig: „Wir wollen es gleich richtig machen.“ Ein guter Vorsatz. Das Problem: Die perfekte Lösung gibt es nicht, und wer sie sucht, sucht für immer.

Es geht immer noch besser, egal, wo ein Projekt gerade steht. Jeder Stakeholder hat neue Ideen, jeder Fachbereich bringt Sonderwünsche mit, und alles ist berechtigt. Das Ergebnis sind endlose Diskussionen, keine Entscheidung und kein Go-Live. Kommt am Ende doch etwas heraus, ist es oft ein Kompromiss aus zu vielen Meinungen und zu vielen Funktionen, mit dem niemand glücklich ist. Perfektionismus fühlt sich an wie Qualität, ist aber häufig eine getarnte Blockade.

Das prominenteste Beispiel ist Cariad, die Softwaretochter von VW. Das Ziel war eine Software für alle Marken und Modelle, Audi, VW und Porsche in einem System. Visionär war das, lieferbar nicht. Cariad ist ein extremer Fall, der Mechanismus findet sich aber auch in kleinen Projekten: ein Werkzeug, das alles können soll, und ein Projekt, das deshalb nicht fertig wird.

Entscheidungen im Softwareprojekt: priorisieren statt alle glücklich machen

Die Lösung ist nicht, weniger zuzuhören. Alle Stakeholder anhören und alle Anforderungen aufnehmen gehört dazu. Alle glücklich zu machen, ist dagegen kein Ziel. Stattdessen werden Grenzen gesetzt und Anforderungen bewusst priorisiert:

• Welche Funktionen schaffen echten Mehrwert für das Geschäft?
• Was bringt direkten Nutzen im Verhältnis zum Aufwand?
• Was kann bis Version 2.0 warten?

Die Kunst liegt nicht darin, alles zu bauen, sondern das Richtige. Eine erste Version, die einen klar umrissenen Teil gut löst, ist früher im Einsatz und liefert Rückmeldungen aus dem echten Betrieb. Die sind verlässlicher als jede weitere Diskussionsrunde. Wie das bei Ablöseprojekten aussieht, beschreibt der Beitrag So wie die alte Software.

Den richtigen Zeitpunkt bestimmen

Damit das Motto im Alltag funktioniert, braucht es konkrete Fragen. Diese fünf haben sich bei uns bewährt:

1. Bis wann muss die Entscheidung fallen? Gemeint ist der Punkt, ab dem andere Arbeit blockiert wäre oder eine Option wegfällt.
2. Was könnte sich bis dahin noch ändern? Kommt nichts mehr hinzu, ist Warten reine Verzögerung.
3. Welche Information würde die Entscheidung tatsächlich verändern? Nur nach ihr lohnt die Suche.
4. Wie schwer lässt sich die Entscheidung später korrigieren? Je schwerer, desto länger lohnt das Sammeln von Informationen, aber nicht über den Stichtag hinaus.
5. Welche Annahmen stecken darin? Wer sie aufschreibt, erkennt später, wann eine Korrektur fällig ist.

In Projekten hilft zusätzlich ein fester Takt. Wenn der Projektstatus nur an wenigen Terminen sichtbar wird, fallen Entscheidungen über Zeit, Team oder Umfang spät und unter Druck. Ein regelmäßiger Rhythmus erzwingt sie, solange noch Spielraum besteht. Wie das aussieht, steht im Beitrag Meilensteine oder Sprints.

Woran Entscheider die Blockade früh erkennen

Perfektionismus und vertagte Entscheidungen kündigen sich an, lange bevor ein Termin reißt:

• Die Anforderungsliste wächst, aber nichts wird gestrichen.
• Es gibt kein Datum für den Go-Live, oder es wird immer wieder verschoben.
• Entscheidungen werden vertagt, bis alle Beteiligten zustimmen.
• Niemand hat festgelegt, wann ein Feature fertig ist.

Gegenmittel sind ein benannter Verantwortlicher, der priorisiert und im Streitfall entscheidet, eine schriftliche Liste für Version 2.0, auf der zurückgestellte Wünsche ehrlich landen, und ein fester Termin für die erste Auslieferung. Ein Wunsch lässt sich leichter zurückstellen, wenn er für später konkret eingeplant statt abgelehnt wird.

Fazit

Entscheidungen im Softwareprojekt scheitern selten an fehlender Analyse, sondern am Zeitpunkt und am Anspruch, alles perfekt zu machen. Wer zu früh entscheidet, legt sich ohne Grundlage fest. Wer auf die letzte Information oder die perfekte Lösung wartet, entscheidet gar nicht. Ein Stichtag je Entscheidung, die Bereitschaft, mit 80 Prozent der Information zu leben, und eine klare Priorisierung bringen ein Projekt zum Go-Live.