A sequential methodology is successful when the complexity of the system is low and requirements are static. A sequential methodology simply states that first one should think about what is being built, then establish the plan for how it should be built, and then build it with quality. It allows for a software engineering methodology which is in alignment with hardware engineering methods and practices. It forces a discipline process to avoid the pressures of writing code long before it is known what is going to be built.
Many times, an implementation team is under pressure to build some code before the analysis is completed, only to later discover that the code is not needed or will contribute little to the end product. Unfortunately, this early code becomes a costly legacy: difficult to abandon and difficult to change. A sequential methodology forces analysis and planning before implementation. This is good advice in many software engineering situations.
The process forces the analysis team to precisely define their requirements. It is much easier to build something if it is known what that something is.
Significant numbers of historical software systems have been built using a sequential methodology. Many past corporations owe their success to one of the many sequential methodologies. These successes were in part due to the usage of a formal sequential methodology at the time when pressures of change coming from external sources were limited.