Studies have shown that in over 80% of the investigated and failed software projects, the usage of the Waterfall methodology was one of the key factors of failure. But why?

Phases in the Classical Waterfall Software Development Model

As shown in the image, when deploying the waterfall methodology there is a strict sequential chain of the different project phases. A previous phase has to be completed before starting the next phase. Going back is in most cases difficult, costly, frustrating to the team and time consuming.

The project timeline is planned at the start. A releasable product is delivered only at the end of the project timeline. If one phase is delayed all other phases are also delayed.

To avoid this users of the waterfall methodology normally try to anticipate all possibilities beforehand. This means that in one of the earliest phases of the project they try to define all requirements as fine grained and complete as possible. However, requirement definition in such an early phase of the project is often very difficult and therefore many requirements change (or should change) throughout the project. Studies have shown that in larger and complex projects about 60% of the initial requirements are changed throughout the project. Other requirements are implemented as defined but are not really needed by the customer and consume valuable time that could have been better used to implement functionality with a higher added value for the customer.

The separation into different project phases force users to estimate each phase separately. The problem is that most of these phases are normally not separate. They are working together and in parallel.

The waterfall approach for developing software can be used for implementing small and simple projects. But for bigger and more complex projects it can be said that this approach is highly risky, often more costly and generally less efficient than Scrum Project Management Framework.

Source: Scrum Institute

Original Article