Introduction | The PMI's Guide to the PMBoK | The "Waterfall" Process
The Systems Engineering Approach | The Spiral Model Approach | PART 2

The "Waterfall" Process

The waterfall process is essentially a linear process as shown in Figure 1.

Figure 1: The Waterfall Life Span (Royce 1998)

To explain this phenomenon we can hardly do better than to quote Murray Cantor extensively.[6]

Quote

Software development may seem to have a lot in common with construction or engineering projects, such as building a bridge. A set of activities must be carried out in what seems to be a natural order: requirements gathering, design, building, testing, and finally putting the bridge into general service. From then on, the bridge goes into operation and maintenance. For software, the usual activities are recast as requirements analysis, architecture, design, code and unit test, integration, and system test.

Tasks are serialized in construction projects. For example, you cannot lay the foundation for a building until the excavation is completed and approved. The flooring task must not begin until the joists are inspected and signed off. Early approaches to software development tried to follow the same discipline.

1. The analysis team captured and documented the requirements.
2. When the requirements were approved, the design started.
3. When the design was approved, coding began.
4. Each line of code was inspected. If it was approved, it was allowed to be integrated into the product.

This is the dreaded waterfall process. It was once touted as a way to make software development cost-effective. The thought was that if coding began before the design was approved, some coding effort would probably be wasted. In practice, ... the construction mentality inherent in the waterfall process has led to some spectacular software development failures.

...

The first problem with this approach is that the software development tasks are not as easily planned and assessed as those of a construction project. It is simple to know what it means to be half done with painting a bridge. It is difficult to know when you are half done with writing code. The amount of time it takes to paint each part of a bridge is easy to estimate, but no one really knows how large the final code will be, and no one knows exactly how long it will take to write and debug any particular piece of code.

A second problem is caused by the serialization of the activities: completing one activity before starting the next. To complete an activity implies that the outcome is perfect and that the staff assigned to the activity can move on to the next project [but] you cannot be sure whether, say, the requirements document is finished. In fact, experience has shown that you can be sure it is not finished. Over the life of the project, shortfalls in the requirements document will be discovered [or in the requirements or design specifications.] ... Each time the documents are reviewed, new problems arise, doubts are raised, gaps discovered, and questions are asked that cannot be answered. Management is disciplined, insisting on quality and holding to standards. They want flawless documents that describe inhumanly complex systems. Their expectations cannot be met and, in the end, a lot of money is spent with no useful results. There is plenty of blame to go around.

End quote

Good features

• The waterfall approach has been around for a long time, and many people are familiar and comfortable with it.
• It is simple and easily understood.
• It does recognize the need to move one stage at a time and recycle back to the previous stage to validate the stage outcome

Not so good features

• The waterfall approach does not satisfy the requirement for executive control that we described in our introduction.
• It is very difficult to manage under conditions of complexity.
• In the waterfall approach, integration and testing is generally left until the end. That's when "all the chickens come home to roost", with disastrous effect on project schedule and cost.

As Shelley Doll puts it:[7]

• "Another potential danger is that you won't know if the solution is successful until very close to launch, leaving little time and room for correction. Oversights and flawed design work can seriously affect your launch date.
• "Other criticisms of this model include the fact that there's no room for feedback anywhere in the process, except at the end of a phase.
• "Also, there's no room for changes once development has begun.
• "Finally, if system testing shows that capacity or performance isn't up to snuff, it may be impossible to correct."

In short, the waterfall approach may be fine for smaller projects but not for projects of any size requiring effective executive control.

The PMI's Guide to the PMBoK

The Systems Engineering Approach

Home | Issacons | PM Glossary | Papers & Books | Max's Musings
Guest Articles | Contact Info | Search My Site | Site Map | Top of Page