Waterfall is a classical sequential (non-iterative) approach, historically popular in large-scale packaged solution implementations globally. This has been used for initiatives/programs that are big, span multiple businesses, have a large number of requirements, involve complex single-site deployments, are developed by global/multi-site organizations, and so on.

Waterfall is simple to understand and has checkpoints/phases that must be completed before the next phase can start.

The following diagram shows the Microsoft Sure Step methodology with discrete phases and their deliverables to give an end-to-end glimpse of the waterfall methodology:

As shown in the preceding diagram, there are predefined stages and their associated deliverables. In a typical waterfall implementation, the following phases are expected:

• Diagnostic: This is primarily the presales phase or requirement-gathering phase.
• Analysis: This is the phase where an advisor/partner understands requirements and maps them with the solution. During this phase, the extent of solution fitment becomes known and the decisions to customize, buy, or build the solution verticals are made.
• Design: In this phase, a solution blueprint needs to be prepared, which in turn needs to be supported with other designs, such as functional, technical, data migration, and security. This is done for both fitment and solution gap areas.
• Development: In this phase, all gaps for which design documents are prepared in the earlier phase are undertaken for development and unit testing. Some implementations perform functional testing as part of this phase or in the subsequent phase.
• Deployment: This is the solution validation phase, where the solution is tested to fit the business requirements of the initiative. Preparation for go-live also happens in this phase and so do activities and deliverables related to data migration, security, training, and so on. 
• Operation: This is the phase after go-live, often known as support/sustenance.

Let's now explore some key attributes of this methodology:

• This methodology is highly efficient when requirements are very clear, fixed, and well articulated.
• Requirements do not change much over a period of time.
• The scope for ambiguity must be minimum, as it would reduce the chances of success.
• Sometimes, implementations allow phases to run in parallel.
• There are some shortcomings of this methodology and they must be checked all of the time:
  • Ensure that the concept stage is finalized and signed off as, once the system goes into the testing phase, it is very difficult to go back and change anything.
  • The entire solution remains a black box and is seen only toward the later phase in the methodology life cycle.
• Reconsider your methodology when the requirements are to be elaborated out or when the program is an on going initiative:
  • There can be huge risks, assumptions, and uncertainties involved due to the inherent nature of the methodology.

Let's learn about common deliverables and phases across these methodologies in the following section and subsequent chapters.