Lexicon · Methodology

Waterfall

Definitie

Waterfall is een aanpak voor softwareontwikkeling en projecten waarbij fases sequentieel worden doorlopen: eerst alle eisen vastleggen, dan ontwerpen, dan bouwen, dan testen, dan uitrollen. Elke fase wordt afgerond en goedgekeurd voordat de volgende start. De naam verwijst naar de visuele weergave: de fases vloeien als een waterval naar beneden, zonder terug te stromen.

Het verschil met agile-methoden: bij waterfall ligt de scope vooraf vast en wordt het eindresultaat pas zichtbaar tegen het einde. Bij agile wordt in korte cycli iets opgeleverd, geleerd en bijgestuurd. Waterfall is niet “ouderwets en fout”, het is een geschikte aanpak voor projecten met heldere, stabiele eisen en weinig onzekerheid.

Waarom het ertoe doet voor MKB

Voor MKB-bedrijven is waterfall vaak nog de standaard bij vaste-prijsofferten van leveranciers: “zoveel uur voor exact deze functionaliteit, opgeleverd op die datum”. Dat geeft schijnzekerheid. De keerzijde is dat veranderingen tijdens het project duur worden en dat het eindresultaat soms niet meer past bij wat het bedrijf intussen nodig heeft.

Begrijpen wanneer waterfall wel en niet werkt voorkomt teleurstelling. Voor een softwareproject met onduidelijke eisen levert waterfall vaak een product op dat technisch klopt maar zakelijk tegenvalt. Voor de uitrol van een standaardpakket of een infrastructuurmigratie kan het juist prima werken, omdat de eindsituatie duidelijk is en weinig ontdekking nodig is onderweg.

Concreet voorbeeld

Een productiebedrijf met 80 medewerkers laat een nieuw klantenportaal bouwen door een externe partij. Vaste prijs €85.000, doorlooptijd 6 maanden, waterfall-aanpak. Eisen worden in twee maanden vastgelegd in een document van 70 pagina’s, daarna bouwt de leverancier zonder tussentijdse opleveringen.

Bij de oplevering blijkt dat de logistieke flow tijdens het project is veranderd en de helft van het portaal niet meer aansluit. Meerwerk-aanvraag: €40.000 en drie maanden vertraging. Een agile-aanpak met maandelijkse opleveringen had de mismatch in maand drie zichtbaar gemaakt, niet in maand zes. Dezelfde leverancier doet hetzelfde type project nu standaard in tweewekelijkse iteraties.

Misverstanden en valkuilen

  • “Waterfall is achterhaald.” Voor projecten met stabiele eisen (een ERP-migratie, certificering, vervanging van een bekend systeem door een vergelijkbaar) werkt waterfall prima. Het probleem ontstaat vooral bij projecten met veel onzekerheid en veranderend inzicht.
  • “Vaste prijs is veiliger.” Een vaste prijs vooraf voelt veilig, maar verschuift het risico naar meerwerkdiscussies, scope-conflicten en kwaliteitscompromissen. Wie de prijs vasthoudt, betaalt vaak op een andere manier.
  • “Wij doen agile, dus geen waterfall.” Veel bedrijven roepen agile maar werken in de praktijk waterfall (eerst alles uitdenken, dan bouwen). De keuze maakt niet uit als het past, het wordt onzin als de termen alleen voor de buhne worden gebruikt.
  • “Eisen vooraf vastleggen voorkomt verrassingen.” Het verschuift verrassingen naar het einde. Wat je niet weet bij het opstellen van eisen, kom je tijdens het bouwen tegen, en dat is op een minder gunstig moment dan ergens vooraan in het project.

Wanneer moet je hiervan wakker liggen, wanneer niet

Wakker liggen: als een leverancier voorstelt om jouw onzekere softwareproject in een waterfall-vorm te gieten met een vaste prijs en een lange doorlooptijd. De kans is groot dat het resultaat technisch wordt opgeleverd maar zakelijk teleurstelt. Onderhandel over iteratieve opleveringen of overweeg een andere leverancier.

Niet wakker liggen: als het project een duidelijk einddoel heeft, weinig functionele onzekerheid kent en het werk vooral uitvoerend is. Een migratie, certificeringstraject of vaste-vorm uitrol leent zich prima voor een waterfall-planning, mits met heldere tussentijdse milestones.

Gerelateerde termen

  • Agile: het bredere alternatief voor waterfall.
  • Scrum: een agile-methode die vaak tegenover waterfall wordt gezet.
  • MVP: agile-concept dat in waterfall-projecten zelden voorkomt.
  • Sprint: korte werkperiode die waterfall niet kent.
  • Build vs buy: keuze die mee bepaalt welke aanpak geschikt is.
  • TCO: bij waterfall-projecten vaak onderschat door meerwerk en latere aanpassingen.
Filed under Methodology
Leestijd 3 min
Gepubliceerd 26 mei 2026

Zie ook

A/B testing
A/B-testing is een methode om twee varianten van een digitaal element naast elkaar te tonen aan vergelijkbare bezoekers en met...
Agile
Agile is een werkwijze waarbij projecten in korte stukken worden opgeleverd en bijgestuurd op basis van wat geleerd wordt. Tegenhanger...
Build vs buy
Build vs buy is de strategische afweging tussen software zelf laten ontwikkelen of een bestaand product kopen. Geen vaste regel;...
CI/CD
CI/CD staat voor Continuous Integration en Continuous Delivery: software wordt automatisch gebouwd, getest en uitgerold zodra een ontwikkelaar wijzigingen indient....
DevOps
DevOps is een werkwijze waarin software bouwen en software draaiend houden door één team gedaan worden. Resultaat: sneller nieuwe versies...
Kanban
Kanban is een methode om werk visueel te beheren via een bord met kolommen, zoals te doen, in uitvoering en...

Verder lezen

Freelancer, bureau of fractional partner: wie moet je software bouwen?
Voor MKB-projecten is er een derde optie: vergelijk freelancer, bureau en fractional partner op kosten, risico en werkwijze.
Het one-person tech team: waarom je geen team van 5 nodig hebt
Je zoekt een developer voor je nieuwe platform. Het bureau komt met een offerte: projectmanager, UX-designer, twee developers, een tester. Vijf mensen, zes maanden,...
Technische schuld: wat het je echt kost en hoe je het oplost
Je herkent het waarschijnlijk. Elke aanpassing aan je software duurt langer dan verwacht. Je IT-kosten stijgen jaar na jaar, maar je systemen voelen niet...