There has been discussion on the Agile PM forum and other places about the inappropriate use of "waterfall" in software development projects. While waterfall is likely not the best approach for the types of software development encountered in many organizations - "discovery design" type projects - the topic of "waterfall" itself is confusing.
- Waterfall is many times a code word for "command and control"
- Waterfall is the anti-agile red herring, used by agile proponents to "tilt against" for their own methodology
- Waterfall is usually poorly understood, badly applied, and generally misrepresented
The paper Launch Vehicle Design Process: Characterization, Technical Integration, and Lessons Learns, NASA/TP-2001-210992, is a nice overview of how a "staged" incremental development process - aka "waterfall" can be used for large complex systems development programs. See Figures 4., pp 8 for the "notional" view of a waterfall schedule on a large program. Similar complexities can be found in ERP or enterprise services projects.
Is this approach appropriate for some software development projects? Probably not. Does waterfall have a place in the large complex software development domain? Probably so. Should anyone advocating for or against the use of a specific development methodology have some experience in that method (both for and against) - absolutely.
Terms like successive refinement, systems of systems, vertical and horizontal integration, design structure matrices can be found in the same document as waterfall. These concepts and more set the stage for a structured, staged, and linear deployment process the contains small incremental and iterative delivery processes.
