You are here

Problems with the waterfall life cycle

7 September, 2015 - 12:26

When the waterfall life cycle was first published, development project planners used it as a generic systems development plan, translating each activity as a separate bar on a GANTT chart which couldn’t be started until the previous activity was completed. This approach caused a number of difficulties and has largely been abandoned. The waterfall life cycle is now used almost exclusively as a training framework, because it distinguishes between the different kinds of activities that take place during systems design – although it does not represent an actual chronological sequence of events.

The main reasons for the inadequacy of the waterfall concept are related to the need to manage changes to the system. We have already mentioned that as soon as a system has been launched, requests for changes start accumulating. In fact, these requests start almost as soon as the first systems requirements have been agreed to, whether it is because the business and technological environments keep changing or because verification, validation and testing (including prototyping) uncover defects that need to be corrected.

Specifically, the problems that arise are the following:

  1. Projects take too long. By placing each activity on the critical path rather than doing some of them simultaneously, the elapsed time of a project cannot be shortened beyond a minimum of a year or more in the typical case. During the long development phase, costs are incurred; benefits do not start accruing for several years. This interferes with the realization of the economic benefits supposed to be brought by the system.
  2. Requirements have to be finalized – “frozen” is the term most used – too early in the project. During a year or more of development, the world does not stand still, and what may have been useful at the start of a project may be irrelevant a year or two later. This became especially true when information technology started to be used as a competitive weapon in the early 1980s.
  3. Users frequently do not get a full understanding of the system until it is almost done. Accepting a requirement or a design on paper is not at all the same as seeing and using a real system, and users who see a system in operation for the first time may quickly discover major problems. As a result, either the system has to be delayed by major corrections or it will be released on time, but with known defects.
  4. Once the developers have handed the system over to operations, they quickly find, contrary to their (somewhat unrealistic) hopes and expectations, that they can’t just forget about it. As people start using the system, they find undesirable system behaviors such as bugs, poor performance, etc. They also develop ideas for additional functions to add to the system, whether these ideas for modifications come from their own experience in using the new technology or are due to changes in the environment – imposed by the competition, regulators, and society at large. In other words, maintenance hits.
  5. In fact, maintenance is already needed during development. As programmers test, they find bugs that have to be fixed. Some bugs are just errors they have made themselves, but sometimes errors are due to poor design or to a misunderstanding of the real requirements. Errors may in fact be found at any point during the development process. To correct these errors, you may have to go back one or several phases in the life cycle to scrap some work previously done and rework it. (Royce knew this: he provided the back arrows on his diagram to address this need. But project planners didn’t truly understand the problem. As a result, the maintenance activity – or bug fixing – that goes on in a waterfall project is usually conflated with the testing activity.)
  6. On innovative projects, another difficulty arises. The team members may not know how to perform their designated activities in the best way, because they have never done it before. When this happens, designers experiment by quickly implementing and testing a possible solution, thus anticipating the later stages of the waterfall life cycle.