Waterfall methodology: What you need to know
It can be incredibly jarring starting a project, especially if you’re relatively new to your position, team, function, or all of the above. Someone can ask you to cook them an egg, but without proper planning and execution, something as simple as this can go very much awry.
There are ways to go about managing your tasks alongside the rest of your team without going towards more complicated and advanced project management techniques. Projects come in all shapes and sizes, and at times the simplest ways to go about things might actually be the best way too.
A great management framework for your next project that we will introduce in this article is the Waterfall methodology. This method provides a great step-by-step process for your next project without adding too many layers to consider.
Overview of the Waterfall Methodology
The Waterfall Method is a popular method utilized by project managers from different industries. Originally developed as a way for software engineers to properly organize their development process, the Waterfall method essentially focuses on a linear progression of steps throughout the lifetime of a project. With a proper setup and planning, you can leverage this direct approach to moving through your project with better ease.
Though as with any sequential approach to project management, it can be tricky to utilize in ambiguous scenarios. Frameworks like the Waterfall method are better suited for objectives that have a clear line of sight and procedure set in best practices.
History of the Waterfall Method
This Waterfall method was initially (mistakenly) attributed to American computer scientist Winston W. Royce back in 1979. Regardless of who exactly developed the first iteration of the Waterfall method, it was developed for software engineers to manage their workload as they were able to utilize and establish a 5-step development plan to reach a predictable outcome.
Despite this being developed with software development in mind, it has since been used in other industries that share similar characteristics to the former’s development process. For example, if you have a task like preparing the financial statements for a particular quarterly earnings call, you can utilize the Waterfall method to better organize your process around manageable steps.
Pros and Cons of the Waterfall Method
Each framework used in a project management space usually comes with its own fair share of strengths and weaknesses depending on the nature of the project. For the Waterfall method, its simplicity and chronological flow give it the edge for new managers looking for a straightforward guide to their projects. It’s also relatively easy to introduce to your teams as the process steps themselves are pretty intuitive.
Aiden Gallagher, Jack Dunleavy, and Peter Reeves, contributors to IBM’s DevOps page, also noted that the Waterfall method’s full focus on early design specifics can help reduce the overall cost of the project by avoiding inefficiencies down the line of the development.
Moreover, key members may enter and exit the project teams without too much hassle as each project development step clearly outlines the needed tasks to be done. These same members will also access information on already completed steps for better context moving forward.
Naturally, there are also limitations to the effectiveness of the process itself. In today’s incredibly “agile-focused” world, establishing the early stages can be difficult as the majority of the requirements might not be as clear-cut as it seems. Additionally, different processes (especially the ones in newer technologies) can face rapid changes in what needs to be developed in response to market movements and faster release cycles. The time aspect can also be limiting as setting a strict start and end point can limit the flexibility of your project team to tackle the task at hand. You can, however, mitigate this risk by including contingencies as part of the overall time required for the project.
How the Waterfall Method Works
With the Waterfall method being a fairly straightforward process, it’s important to properly execute each step well and understand the implications it has for each process it will need to go through. As we mentioned earlier, the Waterfall method works off of a 5-step process, namely the Requirements, Design, Implementation, Verification, and Maintenance stages in a project’s expected timeline. Each stage in this process is fairly intuitive and self-explanatory, but getting a more holistic deep dive into the process can still be helpful.
For a better illustration of the tool, let’s revisit the earlier example in what might be an appropriate project to use the Waterfall method on: preparing financial statements for a quarterly earnings report. With this fairly standard but integral business process found in all public companies and some private ones, we can see how the Waterfall method can help alleviate some of the heavier aspects of the work by essentially front-loading the tasks to be done at the start of the process.
Part 1: The Requirements
The first part of the Waterfall method is the Requirements phase. It’s in this phase that you work with your team and any relevant stakeholders/point persons on the overall requirements you will need for the project at hand.
Due to the fact that the requirements section is still very early on in the entire process, it’s likely that this plan will remain fairly high-level instead of a granular breakdown of the project itself. Dr. Chriss Mattmann, Chief Technology and Innovation Officer (commonly known as CTIO) at NASA’s Jet Propulsion Laboratory, notes that these “high-level statements” are likely to be “implemented in many different ways”.
For our example of the financial statement preparation, this can come in several high-level plans, including but not limited to:
- Outline the relevant financial managers to properly review the quantitative data across the company.
- Discuss with the leadership team the preliminary findings and Pro-forma statements that will have a material impact on stakeholders.
- Reviewing the regulatory requirements of any financial data filings in either the private or the public space.
- For most companies, this might also mean reaching out to third-party accountancy and audit firms to better verify your statements as being accurate and authoritative.
Again, the exact specifics will likely be dependent on the specific business environment and situational context you find yourself in. What’s important is you take the time to outline all the key steps needed to move the plan forward at this stage in the Waterfall.
Part 2: The Design
As you get a better understanding of the inputs needed for the project to be a success, you’ll then want to dive into your team’s capabilities to better understand and craft design solutions that can achieve this.
For managers, this means understanding each of your team member’s workload and current responsibilities to better assign tasks towards those better fit for them. Dr. Mattmann continues with this from the perspective of computer engineering, stating that in a specific project case that their “designs should have redundancy with multiple backend servers” as a resiliency requirement for the task. Here, Dr. Mattmann understands that while there are many ways to achieve his initial high-level statements outlined in the requirements stage, it’s important to contextualize them in the reality of their current resources and capabilities.
Going back now to our example of the financial report for the incoming quarterly earnings deadline, managers and project leads need to understand the workload burden that’s currently with their teams and the organization as a whole. This includes understanding the different political dimensions of the company as this can affect how well resources are allocated throughout. You can also leverage existing resources, such as proprietary tools and licensed software, to help you complete the task that much faster.
For the design stage, it’s best to come up with several different alternative iterations to get a better sense of possible contingency plans in case an initially approved plan falls through.
Part 3: The Implementation
Now that you’ve essentially covered more than 50% of the work so far, it’s time to begin implementing one of the proposed designs for the project to move forward. This includes all the technical and non-technical aspects of the project itself. For software developers, this means running the code that was planned out based on the requirements and design while including some iterative testing as well.
This is likely one of the most variable stages in the Waterfall process as it has to do with collecting the data from a smaller run or essentially starting the project and managing it as it goes. For our example case, this means beginning the process based on the specific project design chosen. If, for example, your company chooses to outsource the development of the financial statements to a third-party based on the best possible design, then this implementation step is to begin the discussion with those third-party teams and have them start the process on their end.
If you were looking for the stage in which the action occurs, this is likely the one you’ll be focused on. It can be nerve-wracking to begin the actual project here but rest assured that you spent a good amount of time laying the route for this in the earlier stages so this part is just putting that plan into action.
Part 4: The Verification
The verification stage focuses on taking that implementation run and ensuring that it is meeting the requirements you initially set out in the earlier stages, including the requirement stage and the design stage.
This is essentially the management stage in the early phase of the Waterfall method as it has to do with making sure you're still on the right track. Many things can go wrong in a project’s execution that doesn’t have to do with the plan per se, so keeping an eye on the moving pieces is key here.
In our case, you’ll want to ensure then that the third-party partners that you’ve chosen to take the reins in developing these integral financial statements are keeping on time with the deadlines required and adhering to the different regulatory requirements that were either defined by you or another regulatory body.
This verification aspect is likely to run in tandem with your overall implementation phase as it is essentially the integrated monitoring system for your actual execution. Catching errors as early as the first few weeks of running can save you and your company a lot of headaches in management towards the end part of the project.
Part 5: The Maintenance
Lastly, you’ll want to ensure that despite verification being achieved, you keep up the maintenance of the project all throughout its lifespan. The project isn’t over once it has gone through validation and verification. The system still needs to be maintained. During maintenance, you are “designing strategies for updating and upgrading”, Mattmann said. This involves patching systems, upgrading the systems, implementing a software upgrade or testing for errors and fixing them if they do occur.
For our example, you want to keep in mind that financial audits can dig up items that might not make sense to stakeholders or regulatory boards, so coming back to the project during these maintenance areas is key to ensuring that your project has proper follow-through even beyond its completion.
Through this 5-step process, you can manage financial reports, marketing plans, production schedules, and more, just by ensuring that you have the roadmap set early on.