Waterfall model

What it means

The waterfall model is a project approach in which phases follow one another like water falling down steps: requirements analysis, design, development, testing and deployment. Each phase starts only when the previous one is finished, and its outputs are the inputs for the next step.

The model originated in traditional engineering and construction, where late changes are difficult and expensive. It requires thorough planning at the outset, detailed documentation and a clearly defined scope, schedule and budget before execution begins.

The opposite is agile management, such as Scrum, where the project is split into short cycles and requirements are refined along the way. Waterfall suits clear and stable requirements, while agile suits uncertainty and frequent change.

How it works in practice

The waterfall model works well for projects with a fixed scope, such as implementing standard accounting software, moving offices or construction. The plan is often shown in a Gantt chart with clear milestones marking the completion of each phase.

With an external supplier, waterfall is often combined with a fixed-price contract for work and a precisely defined deliverable. The client knows in advance what it will get and pay, but changes during the project mean contract amendments and often a higher price.

In practice the two approaches are often combined. The overall project framework, budget and key milestones are planned waterfall-style, while specific parts, such as a website or app, are developed in short agile cycles with regular user feedback.

What to watch out for

The biggest risk of waterfall is that errors in requirements only surface during testing or deployment, when fixing them is most expensive. If requirements change during the project, the model becomes rigid and the result may not match what the client actually needs at completion.

The waterfall approach is not outdated, but it must be applied to the right kind of project. When choosing a methodology, consider the stability of requirements, the degree of uncertainty, regulatory documentation requirements and how much feedback the client can give during the project.