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 term1, 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".
For now, then, I'll stand by the original article.
Although we can't find a rigorous definition, the key attribute of the so-called "waterfall approach" seems to be extreme inflexibility. In particular:
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 rigidity2. 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.
The point of any formal life-cycle is the phase-limited commitment. The sponsors fund and approve one phase at a time, in order:
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.
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|
1 -- 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.
2 -- 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