Softwareprojekt planen: die 7 Schritte vor dem Kick-off

Die meisten Softwareprojekte scheitern nicht am Programmieren. Sie scheitern an einer Frage, die niemand rechtzeitig gestellt hat: Was genau soll am Ende fertig sein, und woran merkt man das? Eine Studie von McKinsey und der Universität Oxford über mehr als 5.400 IT-Projekte kam 2012 zu einem ernüchternden Ergebnis. Große Projekte mit Budgets über 15 Millionen Dollar lagen im Schnitt 45 Prozent über dem Budget und lieferten 56 Prozent weniger Nutzen als geplant.

Bei kleinen Projekten sind die Summen kleiner. Die Muster sind dieselben.

Die gute Nachricht: Ein großer Teil dieser Probleme ist vor dem ersten Commit lösbar. Dafür braucht es keinen 80-seitigen Projekthandbuch-Ordner, sondern sieben Entscheidungen, die schriftlich festgehalten werden.

Was muss vor dem Kick-off feststehen?

Steve McConnell hat den sogenannten Kegel der Unsicherheit populär gemacht. Seine Aussage: Zu Beginn eines Projekts liegen selbst gute Schätzungen um den Faktor vier daneben, nach oben wie nach unten. Erst wenn Produktdefinition und Anforderungen stehen, schrumpft die Spanne auf etwa das 1,5-Fache. Und der Kegel verengt sich nicht von selbst. Er wird nur schmaler, wenn jemand die offenen Fragen aktiv klärt.

Daraus folgt eine einfache Regel. Bevor ein Team Termine oder Festpreise zusagt, müssen mindestens diese Punkte beantwortet sein:

• Welches Problem lösen wir, und für wen?
• Woran messen wir Erfolg (Zahl, Datum, Nutzerverhalten)?
• Was gehört ausdrücklich nicht zur ersten Version?
• Wer entscheidet fachlich, wer gibt Budget frei, wer nimmt ab?
• Welche Systeme müssen angebunden werden?
• Was passiert, wenn das Budget zur Hälfte verbraucht ist und erst ein Drittel fertig?

Die letzte Frage stellt fast niemand. Sie ist die wichtigste.

Die sieben Schritte im Überblick

1. Ziel festlegenEin Satz zum Problem, ein messbares Erfolgskriterium mit Datum.
2. Anforderungen sammelnNutzergruppen, ihre Aufgaben, Schnittstellen. Als User Stories oder Lastenheft.
3. Umfang priorisierenMuss, Soll, Kann, Nicht jetzt. Die erste Version enthält nur Muss.
4. Aufwand schätzenZwei Methoden, Ergebnis als Spanne. Puffer sichtbar ausweisen.
5. Vorgehen wählenAgil, klassisch oder hybrid. Rollen und Entscheidungswege klären.
6. Risiken benennenTop-5-Liste mit Gegenmaßnahme und Verantwortlichem.
7. Meilensteine setzenJeder Meilenstein endet mit einer Go/Stop-Entscheidung.

Schritt 1 und 2: Ziel und Anforderungen

Ein brauchbares Ziel passt in einen Satz und enthält eine Zahl. „Wir digitalisieren den Bestellprozess“ ist kein Ziel. „Bis Ende März laufen 70 Prozent der Bestellungen unserer Stammkunden ohne Telefonat über das Portal“ ist eines. Daran lassen sich später Funktionen messen: Hilft dieses Feature, die 70 Prozent zu erreichen, oder ist es nett, aber verzichtbar?

Für die Anforderungen gibt es zwei Wege. Klassisch schreibt der Auftraggeber ein Lastenheft mit Gliederung und Pflichtteilen. Agile Teams arbeiten lieber mit gut geschriebenen User Stories. Beides funktioniert. Entscheidend ist, dass jemand aus der Fachabteilung mitschreibt, der die Arbeit kennt, die die Software erleichtern soll.

Schritt 3: Umfang schneiden

Hier wird es unbequem. Fast jede Anforderungsliste ist zu lang für das Budget. Das Agile Business Consortium, das das DSDM-Framework pflegt, empfiehlt, dass Muss-Anforderungen höchstens 60 Prozent des geschätzten Aufwands ausmachen. Der Rest ist Manövriermasse, falls etwas länger dauert. Wie das konkret geht, steht im Beitrag zur MoSCoW-Priorisierung.

Schritt 4: Schätzen, aber ehrlich

Eine Schätzung ist eine Wahrscheinlichkeitsaussage, kein Versprechen. Wer „vier Monate“ sagt, meint meistens „vier Monate, wenn nichts schiefgeht“. Besser: „drei bis sechs Monate, mit 80 Prozent Wahrscheinlichkeit unter fünf“. Methoden dafür und ein Rechenbeispiel findest du unter Aufwandsschätzung in Softwareprojekten.

Schritt 5 bis 7: Vorgehen, Risiken, Meilensteine

Ob Scrum, Wasserfall oder eine Mischung passt, hängt vor allem davon ab, wie stabil die Anforderungen sind. Wichtiger als das Etikett sind die Rollen. Es muss eine Person geben, die fachliche Fragen innerhalb von ein bis zwei Tagen verbindlich beantwortet. Fehlt sie, wartet das Entwicklungsteam, und Wartezeit kostet genauso viel wie Arbeitszeit.

Die Risikoliste darf kurz sein. Fünf Einträge, jeder mit Gegenmaßnahme. Typische Kandidaten: eine Schnittstelle zu einem Altsystem, deren Dokumentation niemand gesehen hat. Eine Schlüsselperson, die im Sommer drei Wochen weg ist. Datenschutzfragen, die erst kurz vor dem Livegang auffallen.

Vorlage: Projektsteckbrief auf einer Seite

Statt eines langen Projektplans hat sich ein einseitiger Steckbrief bewährt, den alle Beteiligten unterschreiben. So kann er aussehen:

Das Abbruchkriterium wirkt auf den ersten Blick pessimistisch. In der Praxis verhindert es den häufigsten teuren Fehler: weiterzumachen, weil schon so viel investiert wurde.

Wo Planungen typischerweise kippen

Bent Flyvbjerg und Alexander Budzier haben 2011 in der Harvard Business Review 1.471 IT-Projekte ausgewertet. Der durchschnittliche Kostenüberzug lag bei 27 Prozent. Das klingt beherrschbar. Das Problem steckt im Ausreißer: Jedes sechste Projekt überzog die Kosten im Schnitt um 200 Prozent und den Zeitplan um fast 70 Prozent. Ein Plan, der nur den Durchschnitt abdeckt, deckt also die gefährlichen Fälle nicht ab.

Was diese Ausreißer gemeinsam haben, lässt sich aus der Praxis grob eingrenzen:

1. Der Umfang wächst still. Jede Erweiterung ist klein, zusammen sind sie riesig. Dagegen hilft ein sauberer Prozess für Änderungswünsche.
2. Die Schätzung war eine Zusage. Jemand hat unter Druck eine Zahl genannt, die dann zum Termin wurde.
3. Fachliche Entscheidungen bleiben liegen. Das Team baut auf Annahmen, die später kassiert werden.
4. Die Abnahme wurde nie definiert. Am Ende diskutiert man, was „fertig“ bedeutet.

Ausführlicher geht es um diese Muster im Beitrag Warum IT-Projekte scheitern.

Ein Plan ist ein Arbeitsdokument

Ein häufiger Irrtum: Der Projektplan wird einmal geschrieben, abgenommen und dann gegen die Realität verteidigt. Sinnvoller ist ein fester Rhythmus. Nach jedem Meilenstein, spätestens alle vier Wochen, schaut die Runde aus Budgetverantwortlichem, Fachseite und Technik auf drei Zahlen: Wie viel Budget ist verbraucht? Wie viel vom priorisierten Umfang ist fertig und abgenommen? Hat sich die Schätzung für den Rest verändert?

Wenn Budgetverbrauch und Fortschritt mehr als 15 Prozentpunkte auseinanderliegen, ist das ein Signal. Dann wird nicht härter gearbeitet, sondern Umfang gestrichen oder der Rahmen neu verhandelt.

Wer ein Projekt nicht selbst planen und umsetzen will, kann sich ansehen, wie ein Technologie-Studio wie OnlineBuilders seine Projekte vom Konzept bis zum Betrieb strukturiert, und die eigene Planung daran spiegeln.

Dein nächster Schritt: Schreib heute den einseitigen Steckbrief für dein Projekt. Wenn du das Feld „Nicht im Umfang“ nicht füllen kannst, ist die Planung noch nicht so weit, wie du denkst.

Schritt für Schritt

1. Ziel und Erfolgskriterium festlegen In einem Satz aufschreiben, welches Problem die Software löst und woran du in sechs Monaten merkst, dass es funktioniert hat.
2. Nutzer und Anforderungen sammeln Nutzergruppen benennen und ihre Aufgaben als User Stories oder im Lastenheft festhalten.
3. Umfang priorisieren Anforderungen nach MoSCoW einteilen und die erste Version auf die Muss-Kriterien begrenzen.
4. Aufwand als Spanne schätzen Mit mindestens zwei Methoden schätzen und das Ergebnis als Bandbreite statt als Punktwert kommunizieren.
5. Vorgehen und Rollen bestimmen Agil, klassisch oder hybrid wählen und festlegen, wer fachlich entscheidet und wer abnimmt.
6. Risiken benennen Die fünf größten Risiken mit Eintrittswahrscheinlichkeit, Auswirkung und Gegenmaßnahme notieren.
7. Meilensteine mit Prüfpunkten setzen Pro Meilenstein ein prüfbares Ergebnis und eine Entscheidung festlegen: weiter, umsteuern oder stoppen.

Häufige Fragen

Wie lange dauert die Planung eines Softwareprojekts?

Bei einem kleinen Projekt mit drei bis sechs Monaten Laufzeit reichen oft zwei bis vier Wochen Vorarbeit. Die Faustregel aus dem Kegel der Unsicherheit: Die größte Klärung passiert in den ersten 20 bis 30 Prozent der Projektlaufzeit. Wer diese Phase überspringt, plant sie später teurer nach.

Brauche ich einen Projektplan, wenn ich agil arbeite?

Ja, nur sieht er anders aus. Statt eines Gantt-Diagramms mit allen Aufgaben brauchst du ein Produktziel, ein priorisiertes Backlog, eine grobe Release-Planung und ein Budget mit Abbruchkriterium. Agil heißt nicht planlos, sondern häufiger nachplanen.

Welches Tool eignet sich für die Projektplanung?

Für die Planung selbst reichen ein geteiltes Dokument und eine Tabelle. Jira, Linear oder GitHub Projects lohnen sich, sobald das Team Aufgaben abarbeitet. Das Tool ersetzt keine Entscheidung über Ziel und Umfang.

Wer sollte an der Planung beteiligt sein?

Mindestens eine Person, die das Budget verantwortet, jemand aus der Fachabteilung mit echtem Nutzerwissen und eine Person, die den technischen Aufwand einschätzen kann. Fehlt die Technik am Tisch, werden Termine zugesagt, die niemand prüfen konnte.