A sequential methodology might fail for many reasons. A sequential methodology requires the analysis team to be nearly clairvoyant. They must define ALL details up front. There is no room for mistakes and no process for correcting errors after the final requirements are released. There is no feedback about the complexity of delivering code corresponding to each one of the requirements. An easily stated requirement may significantly increase the complexity of the implementation, and it may not even be possible to be implemented with today's technology. Had the requirement team known that a particular requirement could not be implemented, they could have substituted a slightly different requirement that met most of their needs and could have been easier to achieve.
Communication between teams becomes a gating item. Traditionally, the four teams may be different and cross-team communication may be limited. The main mode of communication are the documents that are completed by one team and then passed to another team with little feedback. The requirement team has completed the analysis and is disbanded when the implementation team starts. The requirement documents can only capture a small fraction of the knowledge and typically do not capture any information dealing with quality, performance, behavior, or motivation.
In a fast-moving technology, a sequential methodology builds products that, by the time they are delivered, may be obsolete. A sequential methodology puts so much emphasis on planning, that in a fast-moving target arena, it can not respond fast enough to change. There is no early feedback from the customer and customers may change their requirements. Frequently, once the customers see a prototype of the system, the customers change their requirements.