Vendors and consultants still breathing life into an old canard.

There's no such thing as the Waterfall Approach!
(and there never was)
© Conrad Weisert, Information Disciplines, Inc., Chicago
8 February, 2003

NOTE: This document may be circulated or quoted from freely, as long as the copyright credit is included.

Background -- Origin of the term

I attended yet another presentation this week in which the speaker drew a sharp contrast between a modern, enlightened development life-cycle and the discredited "traditional waterfall" methodology. He didn't explain what the waterfall methodology is or how it got its name, but the audience of about 80 didn't complain. Indeed, their questions suggested that they had heard of the waterfall approach and accepted the claim that it's outmoded.

I don't recall when I first saw that term¹, but I'm sure it was in a pejorative sense. I'm unaware of any article or paper that ever put forth the "waterfall methodology" as a positive or recommended approach to system development.

In fact, "waterfall" is a straw-man term, coined and used by those trying to promote some new methodology by contrasting it with a silly alleged traditional approach that no competent methodology expert ever favored.

May, 2003, Update

This February article attracted more comments on both sides than any other recent "Issue of the Month".

Three readers expressed vigorous disagreement, claiming that the "waterfall model" has been well known for decades and citing various sources. One of them wondered how I could possibly be so ignorant. Upon checking those sources, however, I found none of them to be the originator of either the concept or the term. In particular, Winston Royce's 1970 paper neither used the term "waterfall" nor proposed such an inflexible life-cycle. Barry Boehm also denies having originated the term. The other citations were all secondary references.
Several other readers concurred and expressed friendly encouragement.

For now, then, I'll stand by the original article.

What does "waterfall" mean?

Although we can't find a rigorous definition, the key attribute of the so-called "waterfall approach" seems to be extreme inflexibility. In particular:

Once you've completed a phase, its results are frozen. You can't go back and revise anything based on changing needs or fresh insights.
Until the results of the current phase are complete and approved, you may not start on any work that properly belongs to the next phase or any later phase.

Presumably the waterfall metaphor was suggested by the inability of water to flow uphill. Once you've passed a given point, there's no going back.

But after more than a quarter-century working with formal system development life-cycle methodologies, I'm aware of no serious textbook, course, or expert that favors such slavish rigidity². Nor have I worked with any client project team that interpreted the system development life cycle in such a strange manner. I have to conclude, therefore, that the waterfall approach exists only in the minds of those who condemn it.

Phase disciplines

The point of any formal life-cycle is the phase-limited commitment. The sponsors fund and approve one phase at a time, in order:

to limit their risk to an affordable sum,
to minimize effort spent on unproductive or undesired directions, and
to avoid the possibility of losing control of a project.

We never "freeze" the users' requirements or a system specification or any other phase deliverables. Of course, there's a cost associated with modifying work that's already been completed and approved. A well-conceived life-cycle methodology gives the sponsoring organization a rational choice based on the costs and expected benefits of making or not making any non-trivial change to previously accepted results.

Furthermore, there's nothing to stop the project manager from initiating advance work on aspects of phase n+1 before phase n is completed, except for the obvious risk that such work may turn out to be invalid. Again, the sponsoring organization should be given a rational choice whether to take that risk in the interest of schedule compression.

Finally, most life-cycle methodologies encourage or at least permit partitioning a large project into multiple smaller projects, which can then proceed independently through the remaining phases.

Life-cycle benefits

Phase disciplines, when practiced with sensible judgment and flexibility, are a good thing with no offsetting downside. They are essential to the success of large projects. Bogus attacks on the non-existent "waterfall approach" can obscure a new methodology's failure to support long-established sensible practice.

We shall return to this topic in a later article. Meanwhile, please

Refrain from using that meaningless and misleading term, unless you're prepared to explain exactly how it applies, and
Question vague claims from tools vendors and methodologists that tie the virtues of their product or methodology mainly to a rejection of the waterfall approach.

¹ -- The earliest use of the term "waterfall" to describe a life-cycle methodology is often attributed either to Barry Boehm or to critics of his COCOMO estimating technique.
² -- If you know of one, please let me know about it.

Return to IDI Home Page
Return to Managerial articles

Last modified February 8, 2003