Warum diese Phase unterschätzt wird

Wer Softwareentwicklung von außen beobachtet, sieht Code, Commits und funktionierende Features. Die Planungsphase dagegen produziert nichts davon, kein lauffähiges System, keine sichtbare Leistung, nichts Anfassbares. Genau das ist das Problem. Was nicht sichtbar ist, wird selten wertgeschätzt. Und was nicht wertgeschätzt wird, bekommt zu wenig Zeit, zu wenig Aufmerksamkeit und zu wenig Budget.

Das häufigste Missverständnis lautet: Planung ist das, was man macht, bevor die eigentliche Arbeit beginnt. Ein notwendiges Übel. Eine Formalie. Eine Pflicht, bevor man endlich „loslegen" kann. Dieses Denken sitzt tief und es ist teuer. Es führt dazu, dass Teams die Planungsphase unter Zeitdruck abkürzen, durch generische Templates ersetzen oder gleich ganz überspringen. Der Schaden ist zunächst unsichtbar: Alle nachgelagerten Phasen arbeiten auf einem wackligen Fundament, ohne es zu merken, bis es zu spät ist.

Die Realität sieht so aus: In der Planungsphase werden keine Entscheidungen vorbereitet, sie werden getroffen. Was gebaut wird, für wen, warum, mit welchen Ressourcen und in welchem Zeitrahmen, das alles entscheidet sich hier. Wer diese Phase als Vorstufe begreift, hat den SDLC noch nicht wirklich verstanden. Denn der eigentliche Wert der Planungsphase liegt nicht in ihren Dokumenten, sondern in dem gemeinsamen Verständnis, das sie herstellt:

• 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.

Ein Beispiel, das so oder so ähnlich in vielen Projekten vorkommt: Ein Entwicklungsteam erhält den Auftrag, ein internes Reporting-Tool zu bauen. Der Zeitdruck ist hoch, die Erwartungen wirken klar. Zumindest glaubt das jeder. Man beginnt direkt mit Analyse und Design, weil „der Scope ja offensichtlich ist". Drei Monate später steht ein funktionierendes System. Nur: Die Controller/eigentlichen Nutzer hatten sich etwas völlig anderes vorgestellt. Die IT-Sicherheit war nie einbezogen worden und blockiert die Inbetriebnahme. Das Budget ist aufgebraucht aber zwei der ursprünglich zugesagten Features fehlen noch.

Was war das eigentliche Problem? Nicht mangelnde technische Kompetenz. Nicht ein schlechtes Team. Sondern: Niemand hatte zu Beginn explizit gefragt, wer welche Erwartungen hat, was „fertig" bedeutet und welche Rahmenbedingungen gelten. Eine Stunde ehrliche Planungsarbeit am Anfang hätte Monate an Nacharbeit erspart. Dieses Muster wiederholt sich in der Softwareentwicklung mit erschreckender Regelmäßigkeit. Nicht weil Teams es nicht besser wissen, sondern weil der Druck, schnell anzufangen, stärker ist als die Disziplin, zuerst innezuhalten.

Was diese Phase wirklich ist

Das Lehrbuch sagt: Planung ist der erste Schritt im SDLC, in dem Ziele definiert, Ressourcen zugewiesen und ein grober Projektplan erstellt wird. Das stimmt aber es greift zu kurz. Denn diese Definition beschreibt das Was, nicht das Warum und schon gar nicht das Wozu. Planung ist nicht einfach ein Schritt, der abgehakt werden muss, bevor die nächste Phase beginnt. Planung ist der Moment, in dem aus einer vagen Idee ein gemeinsames Vorhaben wird. Mit Richtung, Grenzen und einem geteilten Verständnis dessen, was eigentlich erreicht werden soll.

Planung bedeutet im Kern: Komplexität reduzieren, bevor sie zum Problem wird. Jedes Softwareprojekt beginnt mit einer Fülle offener Fragen, konkurrierender Erwartungen und unausgesprochener Annahmen. Die Planungsphase hat die Aufgabe, diese Unschärfe strukturiert zu durchleuchten, nicht um Perfektion herzustellen, sondern um einen belastbaren Rahmen zu schaffen, auf den sich alle Beteiligten beziehen können. Der Unterschied zwischen einem Plan und einem Planungsdokument ist dabei entscheidend. Ein Dokument archiviert Entscheidungen - ein echter Plan entsteht durch das Gespräch, die Auseinandersetzung und das Ringen um Klarheit dahinter.

Im Gesamtsystem des SDLC nimmt die Planungsphase eine Sonderstellung ein. Sie ist die einzige Phase, in der noch keine technischen Weichen gestellt wurden und gleichzeitig alle nachfolgenden Phasen beeinflusst werden. Was hier unklar bleibt, wird von Analyse, Design und Entwicklung implizit interpretiert. Jede Phase füllt die Lücken mit eigenen Annahmen. Je mehr Spielraum die Planung lässt, desto größer wird die Divergenz zwischen dem, was das Business erwartet und dem, was das Team baut. Die Planungsphase ist damit kein Starter-Schritt, sondern ein Qualitätsmultiplikator für alles, was folgt.

Das Verhältnis zu den angrenzenden Phasen lässt sich so beschreiben:

Menschen, nicht nur Prozesse

Kein Planungsprozess ist besser als die Menschen, die ihn durchführen. Das klingt offensichtlich und wird trotzdem regelmäßig ignoriert. In der Praxis wird Planung häufig als technisch-organisatorische Aufgabe behandelt: Scope definieren, Ressourcen zuweisen, Risiken dokumentieren. Die entscheidende Frage (Wer sitzt eigentlich am Tisch, wer fehlt und wer hat welche Erwartungen?) wird dabei oft erst dann gestellt, wenn es zu spät ist. Denn Planung ist kein Dokument sondern ein sozialer Prozess.

Formell gibt es in der Planungsphase klare Zuständigkeiten. 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. Diese Rollen sind wichtig aber sie erklären nicht, wie Entscheidungen wirklich zustande kommen. Denn neben der formellen Struktur existiert immer eine informelle. Erfahrene Entwickler, die Risiken still einpreisen; Stakeholder, die außerhalb von Meetings Erwartungen setzen; Führungskräfte, deren Meinung mehr Gewicht hat als ihre offizielle Rolle vermuten lässt.

Entscheidungen in der Planungsphase werden selten in dem Moment getroffen, in dem sie protokolliert werden. Die eigentliche Entscheidung fällt oft vorher. In einem kurzen Gespräch auf dem Flur, einer E-Mail-Kette oder einem bilateralen Abstimmungsgespräch, das nie dokumentiert wurde. Das ist keine Pathologie, es ist menschlich. Problematisch wird es, wenn diese informellen Vorentscheidungen nicht in den offiziellen Planungsprozess zurückfließen, weil dann ein Teil des Teams mit einem anderen Verständnis weiterarbeitet als der Rest. Der Plan sieht abgestimmt aus, ist es aber nicht!

Typische Reibungspunkte entstehen deshalb nicht aus bösem Willen, sondern aus strukturellen Lücken:

• Unterschiedliche Definitionen von „fertig": Was der Fachbereich unter einem abgeschlossenen Feature versteht, weicht oft deutlich von der technischen Interpretation ab.

• Konkurrierende Prioritäten: Business will maximalen Scope, Entwicklung will realistische Planung, Management will niedrige Kosten. Alle haben recht aber niemand spricht es offen aus.

• Schweigen als Zustimmung: In Planungsmeetings werden kritische Einwände oft zurückgehalten, weil der soziale Druck zur Einigkeit stärker ist als der Wunsch, unangenehme Wahrheiten auszusprechen.

• Fehlende Entscheidungskultur: Wer trifft welche Entscheidung final? Wenn das unklar ist, werden Entscheidungen vertagt, delegiert oder implizit getroffen, ohne dass es jemand merkt.

Die wirksamste Gegenmaßnahme ist keine neue Methodik, sondern eine einfache Praxis. Erwartungen explizit machen, bevor sie zu Annahmen werden. Konkret bedeutet das, in Planungsgesprächen aktiv nachzufragen. Nicht „Sind alle einverstanden?", sondern „Was genau verstehst du darunter?" und „Welche Bedingungen müssen erfüllt sein, damit du das als Erfolg betrachtest?". Diese Fragen fühlen sich manchmal unbequem an. Aber sie sind der Unterschied zwischen einem Plan, dem alle nicken und einem Plan, dem alle folgen.

Woran du erkennst, ob es läuft

„Gut gemacht" ist in der Planungsphase schwerer zu erkennen als in jeder anderen SDLC-Phase. Es gibt keinen grünen Test, kein lauffähiges Feature, keine Deployment-Pipeline, die Erfolg signalisiert. Stattdessen zeigt sich Qualität hier in etwas Ungreifbarem: im Grad der gemeinsamen Klarheit. Wenn alle Beteiligten das Projektziel in ähnlichen Worten beschreiben können, wenn Risiken offen auf dem Tisch liegen und wenn niemand nach dem Kick-off mit einem Fragezeichen im Gesicht den Raum verlässt, dann läuft es.

Das klingt weich, lässt sich aber durchaus konkretisieren. Eine Planungsphase ist dann messbar erfolgreich, wenn sie folgende Ergebnisse produziert:

• Klarer Scope: Was gebaut wird, ist beschreibbar und was nicht gebaut wird, ist es ebenso. Bewusste Nicht-Ziele sind mindestens genauso wertvoll wie Ziele.

• Abgestimmte Erfolgskriterien: Alle relevanten Stakeholder können benennen, woran sie erkennen, dass das Projekt erfolgreich war und diese Antworten ähneln sich.

• Dokumentierte Risiken: Keine Risikodatei, die niemand liest, sondern eine ehrliche Einschätzung der größten Unsicherheiten mit einem Umgang, der dazu beschlossen wurde.

• Realistische Ressourcenbasis: Zeit- und Budgetannahmen sind nachvollziehbar hergeleitet, nicht rückwärts aus einem Wunschtermin errechnet.

• Bekannte Stakeholder-Landschaft: Wer welche Erwartungen hat, wer entscheidet, wer informiert werden muss. Das ist nicht im Kopf einer einzelnen Person, sondern geteilt und dokumentiert.

Neben diesen messbaren Kriterien gibt es weiche Signale, die erfahrene Teams früh wahrnehmen. Lange bevor Zahlen oder Statusberichte Alarm schlagen. Ein verlässliches Warnsignal: Wenn nach dem Planungsabschluss niemand im Team die wichtigsten Entscheidungen aus dem Stegreif benennen kann, wurde nicht geplant, sondern dokumentiert. Ein weiteres: Wenn Rückfragen aus der Analysephase beginnen, die eigentlich schon in der Planung hätten beantwortet sein müssen, hat die Planung ihre wichtigste Aufgabe verfehlt. Und wenn im Team häufig Sätze fallen wie „Das haben wir so nicht besprochen" oder „Ich dachte, das sei selbstverständlich", dann ist das kein Kommunikationsproblem, sondern ein Planungsproblem.

Die Übergabe in die Analysephase ist der erste echte Belastungstest. Was diese Phase konkret liefern sollte, damit die nächste sauber starten kann:

Wer diese Übergabe sauber gestaltet, schenkt dem gesamten Folgeprozess eine solide Basis. Und wer sie überspringt, gibt das Problem nur weiter. Mit mehr Druck und weniger Spielraum.

Entscheidungen, die morgen noch gelten

Der Gestaltungsspielraum, den die Planungsphase bietet, schrumpft mit jeder Phase, die folgt. Mit jeder technischen Entscheidung, die in Design oder Entwicklung getroffen wird, entstehen Bindungen, die sich schwer rückgängig machen lassen. Wer in der Planung sorgfältig entscheidet, arbeitet daher nicht nur ordentlich, sondern wirtschaftlich: weniger Korrekturen, weniger Eskalationen, weniger Nachtschichten kurz vor dem Go-live.

Nachhaltig arbeiten in der Planungsphase bedeutet nicht, alles zu dokumentieren oder jeden Eventualfall durchzudenken. Es bedeutet, die Entscheidungen zu treffen, die morgen noch Bestand haben. Unter realem Projektdruck, mit wechselnden Anforderungen und in einer Organisation, die sich weiterentwickelt. Konkret heißt das:

• Ziele statt Lösungen festhalten: Wer in der Planung bereits Lösungen vorschreibt, verengt den Spielraum der Analyse und des Designs unnötig. Ein klar formuliertes Ziel hält länger als eine früh festgelegte Umsetzungsidee.

• Annahmen mit Kontext festhalten: Jede Planungsentscheidung basiert auf Annahmen. Wer nicht nur die Entscheidung, sondern auch ihre Begründung dokumentiert, schützt das Team vor Interpretationsstreit. Auch dann noch, wenn die ursprünglichen Beteiligten nicht mehr im Projekt sind.

• Bewusste Kompromisse benennen: Ein Beschluss ohne dokumentierte Konsequenz ist kein Kompromiss, sondern ein aufgeschobenes Problem.

Die typischen Fallmuster in der Planungsphase sind gut bekannt und werden trotzdem immer wieder reproduziert. Der häufigste: Der Termin steht fest, also wird der Scope rückwärts berechnet. Was realistisch nicht passt, wird weggelassen aber nicht offen kommuniziert, sondern still vorausgesetzt. Ein anderer Klassiker: Die Ressourcenplanung basiert auf Verfügbarkeit im Idealzustand, nicht auf der Realität mit Urlaub, parallelen Projekten und ungeplanten Störungen. Und schließlich: Risiken werden identifiziert aber mit einem „werden wir schon lösen" abgetan, ohne dass eine konkrete Maßnahme beschlossen wird.

Am Ende jeder Planungsphase lohnt sich deshalb eine einzige ehrliche Frage:

Wenn dieses Projekt in sechs Monaten nicht das hält, was wir uns erhofft haben, welche Entscheidung aus der Planung würde ich im Nachhinein anders treffen?

Diese Frage ist unbequem. Aber sie ist präzise. Sie zwingt dazu, die eigenen Annahmen zu hinterfragen, bevor die nächste Phase beginnt. Sie schafft das Bewusstsein, das den Unterschied macht zwischen Teams, die Probleme früh erkennen und Teams, die sie erst lösen, wenn es teuer wird.

Weiterdenken

Planung wird oft als sachlicher Akt beschrieben. Ein Schritt, der erledigt wird, bevor das Eigentliche beginnt. Aber wer die vorherigen Abschnitte aufmerksam gelesen hat, ahnt, so einfach ist es nicht. Planung ist gleichzeitig strategische Arbeit, sozialer Prozess und kultureller Spiegel. Sie zeigt, wie ein Team mit Unsicherheit umgeht, ob Risiken offen ausgesprochen oder wegmoderiert werden und ob Verantwortung klar übernommen oder still abgeschoben wird. Diese Dimension ist keine Nebensache, sie ist oft der entscheidende Unterschied zwischen Projekten, die funktionieren und solchen, die scheitern, obwohl alle Beteiligten ihr Bestes gegeben haben.

Die interessanteste Frage ist nicht, ob du die richtige Planungsmethode verwendest, sondern wie Planung bei dir wirklich gelebt wird. Einige Fragen, die mehr verraten als jede Retrospektive:

• Wird in deiner Planungsphase wirklich entschieden, oder nur dokumentiert, was ohnehin schon feststeht?

• Wie viel Raum gibt es für echten Widerspruch, bevor der Plan verabschiedet wird?

• Welche Annahme aus eurer letzten Planung hat sich im Projektverlauf als falsch herausgestellt und wann habt ihr es gemerkt?

• Was müsste sich in eurem Team ändern, damit Planung als Führungsarbeit verstanden wird und nicht als Formalität?

Die nächste Phase, die Analyse, baut direkt auf dem auf, was die Planung geliefert hat. Dort werden aus Zielen konkrete Anforderungen, aus groben Scope-Grenzen detaillierte Spezifikationen, aus ersten Stakeholder-Annahmen belastbare Nutzerbedürfnisse. Wie gut das gelingt, hängt mehr von der Qualität der Planung ab als von der Qualität der Analysemethoden. Der Übergang zwischen beiden Phasen ist kein administrativer Akt, er ist der erste echte Test, ob das Fundament trägt.