Modul 2 - Das Wasserfallmodell

Worum es geht

Kein Modell wird im Projektmanagement so oft genannt — und so oft missverstanden — wie der Wasserfall. Für die einen ist er das Sinnbild für schwerfälliges, gestriges Arbeiten; für die anderen die einzige Art, ein großes Vorhaben verlässlich ans Ziel zu bringen. Beide haben ein Stück recht, und beide übersehen etwas.

Mausrad: Zoom · Ziehen: Verschieben · Doppelklick: Reset

Diese Einheit entwirrt drei Dinge: die eigentliche Idee hinter dem Phasenmodell, den hartnäckigen Mythos um seinen Ursprung — und, weil das in der Praxis am meisten zählt, wo der Wasserfall heute noch arbeitet, meist in abgewandelter Form.

Die Idee: Phasen in Reihe

Das Wasserfallmodell zerlegt ein Projekt in eine feste Folge von Phasen. Jede Phase wird vollständig abgeschlossen und ihr Ergebnis abgenommen, bevor die nächste beginnt — wie Wasser, das nur nach unten fließt, nie zurück. Zwischen den Phasen stehen Meilensteine, an denen entschieden wird, ob es weitergeht.

In seiner klassischen, aus der Softwareentwicklung stammenden Form sieht die Kette so aus:

Der Reiz dieses Vorgehens ist kein Zufall. Wer am Anfang weiß, was am Ende stehen soll, gewinnt mit dieser Struktur viel: kalkulierbare Budgets, klare Verträge, eindeutige Verantwortlichkeiten und eine lückenlose Dokumentation, die jede Entscheidung nachvollziehbar macht. Genau deshalb hat sich das Modell so lange gehalten.

Der Royce-Mythos

Der Wasserfall wird fast immer einem einzigen Mann zugeschrieben: Winston W. Royce, der 1970 das Papier Managing the Development of Large Software Systems veröffentlichte. Das stimmt — und führt zugleich in die Irre.

Royce zeichnete darin tatsächlich das streng sequenzielle Modell. Im selben Atemzug schrieb er aber, dieses Vorgehen sei „riskant und lade zum Scheitern ein”. Das Problem, das er benannte: Der Test kommt erst ganz am Ende — also genau dann, wenn Probleme am teuersten zu beheben sind und Rückwege kaum noch offenstehen. Seine Empfehlung war deshalb gerade nicht die reine Linie, sondern Rückkopplungsschleifen zwischen benachbarten Phasen und der Rat, das Vorhaben „zweimal zu machen” — einen frühen Prototypen-Durchlauf, bevor man im Ernst baut. Das Wort „Wasserfall” benutzte Royce übrigens nie; den Namen prägten erst andere.

Hier lohnt eine ehrliche Einordnung, damit aus dem einen Mythos nicht der nächste wird: Royce war kein heimlicher Agilist. Seine Iteration war korrigierend, nicht explorativ — er ging weiterhin davon aus, dass sich die Anforderungen vorab weitgehend festlegen lassen, und schrieb für die Welt großer Rüstungs- und Raumfahrtprojekte. Die Wahrheit liegt also dazwischen: Der „reine Wasserfall”, der später zum Lehrbuch-Dogma wurde, war von Anfang an ein Strohmann — aber Royces Gegenentwurf war diszipliniertes, plangetriebenes Vorgehen mit Schleifen, nicht das Lernen-im-Tun späterer agiler Methoden.

Wo der Wasserfall heute noch lebt — meist abgewandelt

In Reinform begegnet einem der Wasserfall heute selten. Seine Grundlogik — erst festlegen, dann in Sequenz bauen — ist dagegen quicklebendig, nur trägt sie meist andere Namen. Es lohnt sich, die typischen Felder zu kennen:

• Regulierte und abnahmepflichtige Vorhaben. Wo jeder Schritt dokumentiert und formal freigegeben werden muss, passt das phasenweise Vorgehen mit klaren Nachweisen fast von selbst. Die geforderte Nachvollziehbarkeit ist praktisch eine Wasserfall-Struktur.
• Hardware-, Bau- und Anlagenprojekte. Ein gegossenes Fundament, eine bestellte Maschine oder eine verlegte Produktionsstraße lassen sich nicht in der nächsten Iteration eben umbauen. Wo das Ergebnis physisch ist, ist „erst fertig denken, dann bauen” oft die einzig vernünftige Reihenfolge.
• Festpreis- und Vertragsprojekte. Sind Umfang, Preis und Termin vertraglich fixiert, spiegelt die plangetriebene Sequenz schlicht die Vertragslogik wider — der Plan ist Teil der Vereinbarung.
• Öffentliche Ausschreibungen. Ausschreibung, Spezifikation, Vergabe, Bau, Abnahme — dieser Ablauf ist von Natur aus sequenziell und gatebehaftet.
• Migrationen und Rollouts mit hartem Cutover. Wenn an einem festen Stichtag umgeschaltet wird, läuft fast alles davor auf diesen einen Moment zu — klassische Choreografie.

Und dann lebt die Wasserfall-DNA in abgewandelten Formen weiter. In der Produktentwicklung etwa als Stage-Gate-Prozess: feste Phasen, an deren Toren bewusst über Weiterführen oder Abbrechen entschieden wird. Oder in Hybriden, bei denen eine klassische Steuerungsebene — Budget, Meilensteine, Berichtswesen — über einer agilen Umsetzung liegt. Diese Mischung ist verbreitet und kann gut funktionieren; sie kippt aber in das bekannte „Water-Scrum-Fall”-Muster, sobald ein agiles Team vorne von einer starren Anforderungsphase und hinten von einer starren Abnahmephase eingequetscht wird und von beidem nur den Druck, nicht die Vorteile bekommt. Wer Hybride baut, sollte diesen Fallstrick kennen — wir vertiefen ihn in Modul 08 und in Teil D.

Wo er an seine Grenzen stößt

Die Schwäche des Wasserfalls ist die Kehrseite seiner Stärke. Er setzt voraus, dass die Anforderungen früh richtig und stabil sind. Wo das nicht gilt — bei unklaren, neuartigen oder sich wandelnden Zielen — plant er mit hoher Präzision an der Realität vorbei.

Dazu kommt ein struktureller Haken, den schon Royce benannte: Integration und Test stehen am Ende. Fehler im Fundament zeigen sich also spät — und je später eine Änderung kommt, desto teurer wird sie. Eine alte Faustregel der Softwaretechnik besagt, dass die Kosten einer Korrektur mit jeder Phase, die sie überdauert, steil ansteigen. Genau dieses Risiko adressiert das V-Modell im nächsten Modul, indem es jeder Entwicklungsstufe von Anfang an eine passende Teststufe gegenüberstellt.

Quellen

• Winston W. Royce — Managing the Development of Large Software Systems (IEEE WESCON, 1970; Originalpaper)
• Winston W. Royce (Einordnung des Papiers und seiner Wirkung)