Wenn sie viel im Software Projektgeschäft unterwegs sind, dann hören Sie immer wieder Zweifel an der Scrum Methode. Dies liegt in verschiedenen Ursachen begründet. Ein Hauptkritikpunkt von den Scrum Gegnern ist, dass früher doch alles besser war.  Man hat ausführlich auf zig Seiten ein Lastenheft dokumentiert, saß in zahlreichen Abstimmungsmeetings, erstellte eine auf Millimeter-genaue Meilensteinplanung und der König des Projektes war der Projektleiter, welcher nicht nur fachlich, sondern auch disziplinarisch seine Projektmannschaft geführt hat. Die Welt war so lange in Ordnung so lange das Lastenheft 1 zu 1 umgesetzt werden konnte, sei es aus fachlicher wie auch aus technischer Sicht. War dies nicht der Fall so brach die Katastrophe aus und die Stunde des Projektleiters hatte geschlagen.

Die Entschuldigung des Projektleiters für das Projektversagen lag sehr oft darin begründet, dass die Anforderungen im Lastenheft so nicht umsetzbar waren. Dies hat man festgestellt als das Projekt abgeschlossen war und das komplette Entwicklungsbudget verbraucht war. Um das Risiko eines Projektversagens zu minimieren, wurde oft versucht sogenannte Steering Committee (Lenkungsausschuss) zu installieren. Dort sitzen dann Geschäftsführer des Kunden und des Dienstleisters zusammen und lassen sich vom Projektleiter berichten, wie der Projektfortschritt ist. Gibt es Abweichungen vom Projektplan muss der Projektleiter entsprechende Argumente liefern wie:

• Hat länger gedauert wie geplant hinsichtlich Zeit oder Budget
• Unvorhersehbare Ereignisse wie Krankheit, Urlaub, etc.
• Änderung des Leistungsumfangs (Scope)

Der Sinn des Lenkungsausschuss ist in der Praxis überschaubar. Definitiv stärkt es aber die königliche Position des Projektleiters. Gemäß Theorie ist der Lenkungsausschuss zuerst ein Berichtsgremium und bei Abweichungen ein Eskalationsgremium bzw. Entscheidungsgremium.

Da es so gut wie immer Abweichungen zum ursprünglichen Projektplan gibt, stellt sich der Lenkungsausschuss vor allem als Eskalationsgremium dar wegen Abweichung von Time, Budget oder Scope.

Wer braucht noch Wasserfallmethode? Keiner!

Keiner braucht mehr die Wasserfallmethode, vor allem dann, wenn der Projektausgang sehr unsicher ist und das Risiko eines Scheiterns/ Ausfallrisiko („Risk of Failure“) sehr hoch ist.

In der modernen Softwareentwicklung und im Produktmanagement hat die Wasserfallmethode stark an Bedeutung verloren – zugunsten agiler Methoden wie Scrum, Kanban oder SAFe. Aber auch für andere Branchen und Anwendungsfälle ist eine agile Methode die deutlich bessere Wahl.

Sehr wohl gibt es aber sehr spezifische Bereiche, bei denen die Wasserfallmethode die bessere Alternative ist. Diese sind:

Projekte mit starren Anforderungen nach dem Motto „Haben wir immer schon so gemacht“ oder „Müssen wir so machen“

In der Literatur findet man die Beispiele Baubranche, Medizintechnik, Luft und Raumfahrt, bei denen die Wasserfallmethode die bevorzugte Methode ist. Ich halte diese Eingliederung für gefährlich, da sie suggeriert, dass die genannten Branchen sehr engstirnig sind. Dies ist in der Realität aber nicht der Fall.

So setzen manche Bauunternehmer sowohl Wasserfallmethode wie auch agile Methoden ein. Die Wasserfallmethode setzen Bauunternehmen klassischerweise im Bereich Hausbau ein, bei den unterstützenden Prozessen für den Hausbau- Stichwort „Digitalisierung“ wird dabei sehr oft auf eine agile Methode wie z.B. Scrum gesetzt.

Wo wird Wasserfall dennoch genutzt?

Beifolgenden Sachverhalten macht eine Wasserfallmethode für das Projektmanagement evtl. Sinn:

• Regulierte Branchen in denenstrenge Vorschriften eingehalten werden müssen, die eine lineare und dokumentationsgetriebene Vorgehensweise erfordern. Dies ist z.B. im Bereich Medizintechnik, Luft- und Raumfahrt oder Bankenwesen.
• Großprojekte mit stabilen, starren und nicht wechselnden Anforderungen. Vor allem bei Infrastrukturprojekte wie Brückenbau oder große Maschinenbauprojekte verwendet man oft das Wasserfallprinzip, da sich hier Anforderungen wenig ändern.
• Verträge/Projekte mit Festpreisen: Unternehmen, die mit externen Dienstleistern arbeiten und einen klaren Budgetrahmen benötigen, setzen manchmal noch auf Wasserfallmethoden. Vor allem bei ERP-Einführungsprojekten bei denen eine bestehende ERP-Software wie abas ERP, Asseco oder SAP nur noch auf die Bedürfnisse angepasst wird („Customizing“), wird weiterhin auf diese Methode gesetzt mit entsprechenden Nachteilen.

Nachteile der Wasserfallmethode

Die Wasserfallmethode ist nicht mehr zeitgemäß. Das Ausfallrisiko ist zu groß, Budget und Zeitplanungen werden so gut wie immer gesprengt. Weitere Nachteile sind:

• Fehlende Flexibilität: Änderungen im Projektverlauf sind schwer einzuarbeiten, da der Plan von Anfang an feststeht.
• Langsame Reaktion auf neue Anforderungen: Markt- oder Kundenanforderungen können sich ändern, doch das Wasserfallmodell erlaubt keine bzw. nur späte Anpassungen.
• Hohe Risiken: Da Tests erst am Ende erfolgen, kann es passieren, dass Fehler erst spät erkannt werden – mit enormen Kosten für Nachbesserungen. Das Ausfallrisiko ist bei der Wasserfallmethode einfach enorm.

• Kundeneinbindung nur am Anfang und Ende: Das Nutzerfeedback fehlt während der Entwicklung, was oft zu Produkten führt, die am Markt vorbei entwickelt wurden.

• Nicht geeignet für komplexe Softwareprojekte: Besonders in der Softwareentwicklung ändern sich Anforderungen und Technologien schnell – hier sind iterative Methoden klar überlegen.

Fazit zur Wasserfallmethode – Finger weg!

Die Wasserfallmodell ist nicht mehr zeitgemäß. Agile Methoden wie z.B. Scrum sind flexibler, kundenorientierter und risikoärmer. Wer heute noch Wasserfall nutzt, tut dies meist aus regulatorischen oder organisatorischen Zwängen – nicht, weil es die bessere Methode wäre. Am besten lassen Sie die Finger weg von der Wasserfallmethode und nutzen Sie eine agile Methode wie z.B. Scrum. Und denken Sie daran, das „Risk of Failure“ ist in jedem Projekt oder Unternehmen vorhanden, aber durch gute Planung, agile Methoden und eine flexible Strategie können Sie es minimieren. Oder schauen Sie sich doch mal Kanban an, vielleicht ist es die richtige Projektmanagementlösung für ihren Fall.