Over the years, the way that IT teams work has adapted and evolved. The Waterfall Methodology has been widely used in the past in order to get projects completed against a deadline, at a given cost, and to a predefined quality. In this article, we will define the Waterfall Method and talk about some of its benefits and constraints.
What is the Waterfall Method?
The Waterfall Model is a linear or sequential approach to project management and works based on fixed dates, requirements, and outcomes. Teams do not require consistent communication and, unless specific integrations are required, can be self-contained. Team members can also work independently and are often required to provide status reports somewhat less frequently (when compared to an agile approach).
A typical Waterfall project is chronological and is made up of the following phases:
Let’s break this down.
Throughout these five stages, written requirements, usually put into a single document and used for verification of each stage, are composed alongside constraints and functional and non-functional needs of the project. Cost is described, as are assumptions, risks, dependencies, success metrics, and timelines for completion.
A high-level design (HLD) is created to describe the purpose, the scope of the project, the general traffic flow of each component, and the integration points (the topology), followed by a detailed design, which allows subject matter experts (SMEs) to implement the HLD design to precise details.
Implementation teams work to the design to create, code, implement, and test the solution. It is crucial that the single written document be as clear as possible, as the team who designs the system may or may not be the same. If changes are required during the implementation phase (due to unforeseen issues with the design, integrations, or even changes to the intended function of the system), this necessitates that a new design be created and signed off on before the implementation is completed.
Acceptance tests are then deployed and executed in the verification phase, with the built solution further tested against the requirements to confirm that the project meets initial expectations. If it does not, then an examination is performed to identify the shortfalls and a review is completed to determine any ratification actions.
Finally, as defects are raised or new versions of products are needed (maybe because they are no longer supported), planned changes are made by a dedicated ownership team. With the Waterfall Model, each stage can only continue when each of the previous stages are completed and signed off.
Benefits vs. constraints
As with most methodologies, the Waterfall Model comes with just as many benefits as constraints that can impact a project. Let’s look at some of the benefits and constraints you will need to balance with getting your project out of the door.
- The project scope stays relatively static, meaning cost and timelines can be determined early on in the project.
- By completing a full design early in the project, changes to systems stay minimal, meaning the cost to fix and alter designs is kept low.
- A structured approach to a project means that everyone understands what needs to be done and when. SMEs can effectively plan their time over the fixed period.
- By having detailed documentation and designs, a project can lose key members without too much hassle since the documentation describes in reasonable detail how any SME of the product or skill are needed to complete the work.
- It is hard to allow for new requirements in an ever-changing world. For example, an organization or industry-wide change of specifications would take a long time to adopt, with the project needing to return back to the requirements and design stage.
- A project that has dependencies on relatively unstable products which are constantly in flux may also cause constraint. For example, if the project makes use of software or technologies with very rapid release-cycles and paces-of-change, then the project needs to have fixes being implemented on a monthly basis. This makes design and documentation very difficult and means risk and assumptions must be embedded into the estimations with widely varying degrees of accuracy.
- It is difficult to estimate the total time a project will take to complete. Each organization has different processes and each project has different issues, including SME shortages, long delays in provisioning software, and a lengthy approval process.
- A large amount of contingency is, more often than not, added into timescales. From the start of project, lots of subjects and outcomes will be undetermined and only put into production in the final stages of the project. This creates risk, which gradually diminishes as the project progresses. Whilst this risk can be decreased with good practices, it still creates a good deal of uncertainty.
Hopefully this article has given you a better understanding of when to use the Waterfall Method. To see how we used it in practice, see our article, “How to use Waterfall and Agile practices on your next project“.