What is meant by a waterfall project? The waterfall model entered the corporate lexicon in the 1970s to describe a design approach in software engineering by the TRW Defense and Space Systems Group. It was used to signify the cascading of customer requirements towards implementation (see diagram below).

Bell and Thayer (1976) concluded that ‘problems with requirements are frequent and important. Differences between types of requirement problems is quite small between projects. Improved techniques for developing and stating requirements are needed to deal with these problems’.

Amazingly, these issues still exist today, more than 40 years on.

Essentially, the waterfall approach requires that you gather everything up before you start the project: the needs and priorities of the customer; the design of how it will be built and put together; how it will be tested to make sure (a) it works and (b) the stakeholders are happy; and how it will be maintained once the project is completed.

The best way to think of it is like a big Lego set. You have everything in the box — all the pieces, the instructions, the tools (if required). Then all you have to do is review the design and estimate who you’ll need to be involved, how long you think you’ll need, the quality expectations and how much it will cost. Led by my son, the people required for this project would be him, with my support for larger, more complex sections. The time taken would depend on the size of the set — anywhere between 30 minutes and four hours. The quality expectations are that it will look exactly like it does on the front of the box while all the moving parts should work perfectly. The cost for his time would of course be $0 because he’s 10 and has nothing better to do, although he’d be looking at $2000 per hour (or part thereof) for my help. What? I’m self-employed, time is money.

Well, you get the idea.

For a waterfall project to work you need to know a lot up front and should start with an idea, not a solution. If you start with a solution in mind, then the components of the approach are weighted towards what you’ve seen, not what’s most important for the organisation.

The more you know up front, the less a project should cost (in theory), as there’ll be little rework required towards the back end of the project, when everything gets more expensive.

It requires more work in the planning stage to collect information and will likely have to go through a series of ‘stage gates’ to ensure it will still deliver what was promised in the business case. It needs a dedicated sponsor and a steering committee who can help guide decision making, a definition of the culture required and, of course, a project leader to ensure that change is well controlled throughout.

Current thinking around the world is that waterfall projects don’t work and organisations are falling over themselves to implement more ‘agile’ ways of working. Yet some of the best projects I ever worked on were waterfall projects. For an organisation to achieve its strategic objectives, and for its projects to be continually successful, it will need to consider and be great at delivering both kinds of approaches.

Pros and cons of the waterfall project