Wat is de watervalmethode?

Definitie: De watervalmethode is een lineaire manier van projectmanagement waarbij een project in vaste fasen wordt uitgevoerd, zoals eisen, ontwerp, bouw, testen en oplevering. Elke fase wordt afgerond en goedgekeurd voordat de volgende begint, zoals water dat van trede naar trede naar beneden valt.

In het kort

• De watervalmethode werkt met een vaste volgorde van fasen en een uitgebreide planning vooraf.
• Winston W. Royce beschreef de aanpak in 1970; de naam waterval werd volgens Toolshero in 1976 voor het eerst gebruikt door Bell en Thayer.
• Sterk in voorspelbaarheid, mijlpalen en documentatie; zwak in flexibiliteit en late feedback van gebruikers.
• Agile werkt juist in korte cycli met tussentijdse oplevering; veel organisaties combineren beide in een hybride aanpak.

Wat is de watervalmethode?

De watervalmethode is een van de oudste en bekendste manieren om een project aan te pakken. Je bepaalt aan het begin zo volledig mogelijk wat er gemaakt moet worden, maakt daar een plan voor en voert dat plan stap voor stap uit. Een volgende fase begint pas als de vorige is afgerond. Terug naar een eerdere fase gaan is in principe niet de bedoeling, en als het toch moet, kost het tijd en geld.

De methode komt oorspronkelijk uit de bouw en de industrie, waar je een fundering niet meer verandert als de muren eenmaal staan. Toolshero beschrijft hoe Winston W. Royce de aanpak in 1970 voor softwareontwikkeling beschreef, en hoe het Amerikaanse ministerie van Defensie de methode vanaf 1985 voor softwareleveranciers gebruikte. PMcursus noemt waterval jarenlang de standaard in bouw, engineering en IT.

Welke fasen kent de watervalmethode?

Het aantal fasen verschilt per bron, maar de kern is steeds gelijk. Een veelgebruikte indeling:

1. Eisen verzamelen. Wat moet het systeem kunnen, voor wie en onder welke voorwaarden? Dit wordt vastgelegd, vaak in een programma van eisen.
2. Analyse en ontwerp. De eisen worden uitgewerkt in een functioneel en technisch ontwerp: schermen, processen, datamodel en architectuur.
3. Bouw. Ontwikkelaars bouwen het systeem volgens het ontwerp.
4. Testen. Het complete systeem wordt getest op fouten en op de afgesproken eisen.
5. Implementatie. Het systeem wordt opgeleverd, in gebruik genomen en gebruikers worden opgeleid.
6. Onderhoud. Fouten worden opgelost en kleine aanpassingen doorgevoerd.

Elke overgang is een moment van goedkeuring. De opdrachtgever tekent bijvoorbeeld voor het ontwerp, waarna de bouw begint op basis van precies dat ontwerp.

Wat zijn de voordelen van de watervalmethode?

• Duidelijke structuur. Iedereen weet in welke fase het project zit en wat er daarna komt.
• Voorspelbare planning en begroting. Lucidchart noemt een duidelijke tijdlijn en kostenraming vooraf als belangrijk voordeel.
• Vaste mijlpalen. Goedkeuringsmomenten maken voortgang meetbaar.
• Goede documentatie. Eisen en ontwerp worden vooraf vastgelegd, wat helpt bij overdracht en latere uitbreidingen.
• Minder tijd van de opdrachtgever tijdens de bouw. Na de ontwerpfase is de klant minder vaak nodig.
• Geschikt voor vaste afspraken. Bij aanbestedingen of contracten met een vaste prijs sluit een vooraf vastgelegde scope goed aan.

Wat zijn de nadelen?

• Weinig ruimte voor verandering. Inzichten die tijdens de bouw ontstaan, passen slecht in het plan.
• Late feedback. Gebruikers zien het systeem vaak pas aan het eind. Blijkt dan dat iets niet werkt zoals verwacht, dan is aanpassen duur.
• Testen aan het eind. Fouten in het ontwerp komen pas laat aan het licht. Toolshero wijst erop dat een fout in een late fase soms betekent dat je deels opnieuw moet beginnen.
• Pas laat iets werkends. Tot de oplevering is er geen bruikbaar product.
• Eisen moeten vooraf bekend zijn. Bij nieuwe ideeën weet je aan het begin vaak nog niet precies wat nodig is.

Hoe ziet waterval eruit in een softwareproject?

Stel dat een organisatie een nieuw planningssysteem laat bouwen volgens de watervalmethode. Het verloop ziet er dan ongeveer zo uit:

1. Eisen. In een reeks gesprekken met planners, teamleiders en directie worden alle wensen opgehaald en vastgelegd in een document.
2. Ontwerp. Een functioneel ontwerp beschrijft schermen, rollen en processen. Een technisch ontwerp legt het datamodel en de koppelingen vast. De opdrachtgever keurt beide goed.
3. Bouw. Het ontwikkelteam bouwt maandenlang op basis van de goedgekeurde ontwerpen, zonder dat gebruikers tussentijds iets zien.
4. Test. Testers controleren het systeem tegen de eisen. Gevonden fouten worden opgelost.
5. Acceptatie en livegang. Gebruikers testen het systeem zelf en het gaat live.

Het risico zit in stap 5. Pas dan merken planners bijvoorbeeld dat een veelgebruikte uitzondering ontbreekt, omdat niemand die in stap 1 had genoemd. Aanpassen betekent terug naar het ontwerp, met extra kosten en vertraging.

Documentatie en goedkeuring

Documentatie is bij waterval geen bijzaak maar het fundament. Elke fase levert een document op dat de basis vormt voor de volgende: een programma van eisen, een functioneel ontwerp, een technisch ontwerp, een testplan en een opleverdocument. Dat maakt het project controleerbaar en overdraagbaar. Het nadeel is dat documenten verouderen zodra de werkelijkheid verandert, en dat een handtekening onder een ontwerp nog niet betekent dat iedereen het ook op dezelfde manier heeft begrepen.

Waterval vs agile: wat is het verschil?

Agile is gebaseerd op het Agile Manifesto uit 2001, met vier kernwaarden en twaalf principes. Scrum is het bekendste agile framework; PMcursus noemt sprints van één tot vier weken. Lucidchart wijst erop dat agile veel communicatie vraagt en door extra sprints duurder kan uitvallen dan gepland. Projectmanagementspot noemt het risico op scope creep en een minder voorspelbare planning.

Wanneer kies je voor waterval?

PMcursus geeft een bruikbare keuzehulp met vier vragen:

1. Hoe zeker is de scope?
2. Hoe stabiel zijn de eisen?
3. Is tussentijdse betrokkenheid van de klant nodig?
4. Kan de organisatie omgaan met onzekerheid?

Waterval past vooral bij projecten met een vaste, goed bekende scope, strenge regelgeving, meerdere externe partijen die één masterplan nodig hebben, of een fysiek resultaat zoals een gebouw. Tailor iT noemt de bouw van een kantoorpand als voorbeeld voor waterval en softwareontwikkeling als voorbeeld voor agile.

Bij software is de scope zelden volledig bekend. Gebruikers ontdekken pas wat ze nodig hebben als ze met iets werken. Daarom kiezen de meeste softwareteams voor een iteratieve aanpak, of in ieder geval voor kleinere stappen.

Hybride: het beste van beide

Veel organisaties combineren de twee. Budget, governance en de globale faseplanning volgen een traditionele opzet, terwijl de dagelijkse uitvoering in korte cycli verloopt. PMcursus noemt AgilePM als methode die daarvoor is ontworpen. Ook het Rational Unified Process combineert mijlpalen met iteraties.

In de praktijk ziet een hybride softwareproject er vaak zo uit:

1. Vooraf afbakenen. Doel, gebruikers en de inhoud van de eerste versie worden vastgelegd.
2. Ontwerp op hoofdlijnen. Schermschetsen en processen, zonder elk detail vast te leggen.
3. Bouwen in stappen. De eerste versie wordt in korte rondes gebouwd en tussentijds getoond.
4. Ingebruikname. De eerste versie gaat live bij een beperkte groep gebruikers.
5. Verbeteren. Op basis van gebruik volgen nieuwe rondes.

Veelgemaakte fouten

• Een te groot eerste plan. Hoe meer je vooraf vastlegt, hoe meer er later kan blijken niet te kloppen.
• Geen tussentijdse controle. Ook bij waterval helpt het om ontwerpen en tussenresultaten aan echte gebruikers te laten zien.
• Agile als excuus voor geen plan. Zonder duidelijk doel en afbakening wordt een iteratief project een eindeloze reeks aanpassingen.
• Contract en methode die niet passen. Een vaste prijs met een vaste scope combineert slecht met een aanpak waarin alles kan veranderen.

Wat betekent dit voor jouw project?

Mijn traject heeft van beide methoden iets. Het begint met een procesgesprek van ongeveer twintig minuten en een betaalde blauwdruk: een afgebakend proces, schermschetsen, afhankelijkheden en een voorstel voor de eerste versie. Dat is vooraf vastleggen, zoals bij waterval. Daarna volgt de eerste versie, en vervolgens beheer en verbetering op basis van gebruik.

Ik wil vooraf duidelijk hebben wat we met een eerste versie bedoelen. Een kleine, afgebakende eerste versie geeft voorspelbaarheid, en laat tegelijk ruimte om te leren van hoe het in de praktijk wordt gebruikt.

Vraag? Stuur me voor wie het is, wat er nu gebeurt en wat de eerste versie moet oplossen. Dan bepalen we samen de logische eerste stap. Lees ook hoe een webapplicatie laten maken verloopt.

Veelgestelde vragen over de watervalmethode

Wat is de watervalmethode?

De watervalmethode is een lineaire projectaanpak waarbij fasen zoals eisen, ontwerp, bouw, testen en oplevering na elkaar worden uitgevoerd. Een volgende fase begint pas als de vorige is afgerond en goedgekeurd.

Wat is het verschil tussen waterval en agile?

Waterval plant vooraf gedetailleerd en levert één keer op aan het einde. Agile werkt in korte cycli waarin steeds een werkend deel wordt opgeleverd en de planning op basis van feedback wordt bijgesteld.

Wanneer is de watervalmethode geschikt?

De watervalmethode past bij projecten met een vaste, goed bekende scope en stabiele eisen, zoals bouwprojecten of projecten met strenge regelgeving. Bij software met onzekere eisen kiest men vaker voor agile of een hybride aanpak.

Verwante termen

Scope creep · Discovery-fase · Programma van eisen · Functioneel ontwerp · Fixed price vs nacalculatie · Proof of concept