Wie du den Zeitplan deines Softwareprojekts realistisch planst

Der Launch soll zur Messe fertig sein, zum Jahreswechsel oder bevor die alte Software ausläuft. Solche Termine können feststehen, bevor jemand die Arbeit geschätzt hat. Dann liefert der Anbieter ein Angebot, das zum Wunschtermin passt, und beide Seiten behandeln das Datum als gegeben. Ein belastbarer Zeitplan entsteht anders: aus Meilensteinen, Abhängigkeiten und einem Puffer, den du bewusst einplanst. Dieser Artikel zeigt, wie.

Warum Zeitpläne reißen

Die Ursachen lassen sich in drei Gruppen sortieren:

Unklare Anforderungen. Wenn bei Projektbeginn Funktionen offen sind, entstehen Klärungsschleifen, die im Plan nicht vorkommen. Ein vollständiges Pflichtenheft ist deshalb auch ein Zeitplan-Werkzeug. Der Artikel Der Pflichtenheft-Fehler, der dein Projekt 30% teurer macht beschreibt, was hier schiefläuft.
Zu knappe Schätzung. Eine Schätzung enthält nur die Arbeit, die man vorhersieht. Unvorhergesehenes wie Krankheit, technische Probleme und Rückfragen fehlt, wenn kein Puffer vorgesehen ist.
Verzögerungen auf Auftraggeberseite. Dieser Punkt wird leicht übersehen: Der Plan des Dienstleisters setzt voraus, dass du Entscheidungen, Zugänge, Inhalte und Testergebnisse rechtzeitig lieferst.

Mitwirkung des Auftraggebers einplanen

Bei Werkverträgen, zu denen Festpreis-Softwareprojekte zählen, trifft den Besteller eine Mitwirkungsobliegenheit. Das Gesetz sieht in § 642 BGB vor, dass der Unternehmer eine angemessene Entschädigung verlangen kann, wenn der Besteller durch das Unterlassen einer erforderlichen Handlung in Verzug der Annahme kommt. Das ist rechtlich eine Frage des Einzelfalls, praktisch bedeutet es: Wenn dein Beitrag fehlt und das Projekt dadurch steht, kann das Folgen für Termin und Kosten haben.

Welche Beiträge das sind, solltest du in den Zeitplan aufnehmen:

Entscheidungen wie Freigabe von Designentwürfen oder Klärung von Fachfragen, mit einer vereinbarten Antwortfrist.
Zugänge und Material, etwa Zugangsdaten zu Fremdsystemen, Logos, Texte, Beispieldaten.
Personen, die für Fragen und Tests zur Verfügung stehen, auch während Urlaubszeiten.
Prüfungen, zum Beispiel die Zeit, die dein Team für den Abnahmetest braucht.

Lege pro Beitrag fest, wer verantwortlich ist und bis wann er vorliegt. Schon eine einzelne Schnittstelle zu einem Bestandssystem kann Zugangsdaten, ein Testsystem und einen Ansprechpartner beim Hersteller erfordern.

Meilensteine statt Enddatum

Ein einzelnes Enddatum verrät erst am Ende, ob das Projekt im Plan lag. Meilensteine geben dir unterwegs Anhaltspunkte. Gute Meilensteine haben diese Eigenschaften:

Sie sind prüfbar: "Registrierung und Login auf der Staging-Umgebung nutzbar" statt "Fortschritt bei den Nutzerfunktionen". Zur Staging-Umgebung siehe Entwicklung, Staging, Produktion.
Sie liefern sichtbare Ergebnisse, die du selbst ausprobieren kannst.
Sie sind mit Zahlungsabschnitten verknüpft, sodass Fortschritt und Vergütung zusammenpassen.
Sie haben Termine, die aus der Schätzung folgen und nicht aus dem Wunschtermin.

Wenn ein Meilenstein verfehlt wird, ist das ein Frühwarnsignal. Wie du Anzeichen für ein Projekt außer Kontrolle erkennst, steht im Artikel 5 Warnsignale, dass dein Softwareprojekt aus dem Ruder läuft.

Puffer bewusst einplanen

Ein Puffer ist keine Verschwendung, sondern Abbildung der Unsicherheit. Plane ihn an zwei Stellen ein:

Beim Anbieter: Frag, ob die Schätzung einen Puffer für Unvorhergesehenes enthält und wie groß er ist. Eine Schätzung ohne Reserve ist nur der günstigste Verlauf.
Bei dir: Lege dein Wunschdatum hinter den Tag der geplanten Fertigstellung. Lass zwischen Abnahme und dem Termin, an dem du die Software brauchst, Zeit für Nachbesserungen, Datenübernahme und Schulung.

Berücksichtige außerdem Ferienzeiten, Feiertage und eigene Stoßzeiten, in denen dein Team keine Kapazität für Rückfragen hat.

Festtermin oder Festpreis: Du kannst nicht alles festlegen

Umfang, Termin und Kosten hängen zusammen. Wenn du den Umfang und den Preis festschreibst, bleibt der Termin das Ergebnis der Schätzung. Wenn du den Termin festlegst und den Preis fixierst, muss der Umfang flexibel sein. Eine Entscheidung zwischen diesen Größen kommt nicht ohne Kompromiss aus. Ein Weg, mit festem Termin umzugehen, ist die Priorisierung: Trenne Funktionen, die zum Termin da sein müssen, von denen, die in einem zweiten Release folgen können. Wie du Umfang und Preis vertraglich festhältst, steht im Artikel Wie du einen Festpreis-Vertrag mit deiner Softwareagentur verhandelst.

Fazit

Ein belastbarer Zeitplan beruht auf klaren Anforderungen, prüfbaren Meilensteinen, einem ausgewiesenen Puffer und festgehaltenen Mitwirkungen deiner Seite. Lege dein Wunschdatum hinter die geplante Fertigstellung, um Platz für Nachbesserung und Einführung zu haben, und entscheide bewusst, ob Umfang, Termin oder Kosten flexibel sein dürfen.

Häufig gestellte Fragen

Wie lange dauert ein Softwareprojekt?

Das hängt vom Umfang ab. Eine seriöse Aussage ist erst nach einer Anforderungsanalyse möglich. Misstraue Zeitangaben, die ohne Kenntnis deiner Anforderungen genannt werden.

Was passiert, wenn ich meine Zulieferungen verspätet liefere?

Der Plan verschiebt sich, und je nach Vertrag können zusätzliche Kosten entstehen. Vereinbare deshalb vorab, welche Beiträge du bis wann leistest, und melde dich früh, wenn sich etwas verzögert.

Wie viel Puffer ist angemessen?

Eine feste Zahl lässt sich nicht pauschal nennen. Richte den Puffer nach dem Risiko aus: Je mehr Unbekanntes im Projekt steckt, etwa neue Technik oder Schnittstellen zu Altsystemen, desto größer sollte er sein.