Planung

Die Planungsphase klärt, warum ein Vorhaben überhaupt gestartet wird. Bevor irgendjemand über Architektur, Technologien oder Code nachdenkt, wird deutlich, welches Problem adressiert wird, welches Zielbild angestrebt wird und in welchem groben Umfang sich das Projekt bewegt.

Das ist keine rein technische Aufgabe. Management und fachliche Verantwortungsträger einigen sich hier auf Budget, Zeitschiene und zentrale Annahmen. Wer in dieser Phase mitreden sollte, sind also nicht nur technische Rollen, sondern alle, die später von der Lösung betroffen sind oder über sie entscheiden. Der eigentliche Wert der Planungsphase liegt dabei weniger in ihren Dokumenten als in dem gemeinsamen Verständnis, das sie herstellt.

Was in der Planungsphase geklärt wird

Fünf Fragen ziehen sich durch jede gute Planung, unabhängig davon, wie groß das Vorhaben ist:

• Scope: Was ist Teil des Projekts und was explizit nicht?
• Ziele: Welches Problem wird gelöst und woran erkennen alle Beteiligten Erfolg?
• Ressourcen: Wer arbeitet mit, mit welchem Zeitbudget und welchen Kompetenzen?
• Risiken: Welche Unsicherheiten existieren und wie wird mit ihnen umgegangen?
• Stakeholder: Wer hat Erwartungen, wer hat Einfluss, wer muss informiert werden?

Jede dieser Fragen, die hier nicht bewusst beantwortet wird, beantwortet sich später von selbst, meistens unter deutlich schlechteren Bedingungen: als Streit über Zuständigkeiten, als Scope-Erweiterung mitten in der Entwicklung oder als überraschter Stakeholder kurz vor dem Go-Live.

Wer typischerweise beteiligt ist

Der Product Owner oder Business Sponsor verantwortet die fachliche Richtung und das Geschäftsziel. Die Projektleitung koordiniert Ressourcen, Zeitplan und Kommunikation. Die technische Leitung bewertet Machbarkeit und identifiziert frühzeitig technische Risiken. Der Fachbereich bringt das konkrete Nutzungswissen ein, ohne das Ziele und Anforderungen abstrakt bleiben.

Diese Rollen ersetzen sich nicht gegenseitig. Eine Planung, die nur von Management oder nur von Technik getragen wird, übersieht fast zwangsläufig eine Seite des Problems.

Typische Risiken

Wird die Planungsphase unterschätzt, starten Projekte mit unscharfen Zielen und impliziten Erwartungen. Spätere Diskussionen drehen sich dann weniger um Fakten als um Deutungen und nachträgliche Zielverschiebungen. Genau das macht diese Phase, obwohl sie selten viel Code produziert, zu einer der folgenreichsten im gesamten Lebenszyklus.

Was am Ende vorliegen sollte: Übergabe an die Analyse

Übergabeartefakt	Warum es zählt
Projektziel und Problemdefinition	Ohne klares Problem kein klares Ergebnis
Scope-Dokument inklusive Nicht-Ziele	Verhindert stille Erweiterungen in der Analyse
Stakeholder-Übersicht	Zeigt, wer in der Analyse einbezogen werden muss
Risiko- und Annahmenregister	Gibt der Analyse einen Rahmen für offene Fragen
Erfolgskriterien	Macht eine spätere Qualitätsbewertung möglich
Ressourcen- und Zeitrahmen	Setzt realistische Grenzen für den Detaillierungsgrad

Wer diese Übergabe sauber gestaltet, schenkt der Analyse eine solide Basis. Wer sie überspringt, gibt das Problem nur weiter, mit mehr Druck und weniger Spielraum.

Fragen, die sich alle Beteiligten stellen sollten

Ist klar beschrieben, welches Problem gelöst und wie Erfolg gemessen werden soll?
Welche Annahmen und Risiken werden bewusst in Kauf genommen, statt sie stillschweigend zu übergehen?
Diese Fragen sind für Product Owner und Projektleitung genauso relevant wie für Entwicklung und Architektur. Wer sie früh beantwortet, spart sich spätere Grundsatzdiskussionen.

Im Beispiel: Ablösung des Ticketsystems

In unserem Beispiel zur Ablösung eines internen Ticketsystems wird in der Planungsphase grob festgelegt, warum das alte System ersetzt wird, wer betroffen ist und welche Ziele erreicht werden sollen, etwa kürzere Reaktionszeiten im Support oder bessere Transparenz für Führungskräfte. Noch nicht geklärt ist an dieser Stelle, wie genau die Lösung aussieht, das ist Aufgabe der nächsten Phase.

Wie stark die Qualität dieser Phase von den Menschen abhängt, die sie gestalten und was das mit zunehmendem Einsatz von KI in der Softwareentwicklung zu tun hat, vertieft der Artikel „Der Faktor Mensch im SDLC“.