The Resilience of the Waterfall method
Imagine you are standing in front of Niagara Falls. You can see the water flowing in one direction, accelerating towards a cliff and as it goes over the rock, it builds momentum, splashing some water in different directions while much of the water gets pulled by gravity, falling downward creating a new body of water.
What is the first thing you think of when comparing this visual to your workplace? Project management? Business silos? One-piece flow? Each one of us has been introduced to the waterfall concept at some point in our careers and we recall it based on how we used it. For example, I was first introduced to waterfall over twenty years ago when demonstrating cost erosion in a project. It is fantastic how one word can be defined in many ways.
Waterfall was first introduced to us in 1970, by Dr. Wilson Royce who authored a paper titled “Managing the development of large software systems” which described his experience managing large software projects on spacecraft’s post-flight analysis. Dr. Royce never intended to promote the waterfall method when managing projects, yet he is known as the person who identified it.
In Dr. Royce’s original submission, the method was seen as a waterfall flowing into five phases where each phase was required to move from one branch component step to the next in a sequential stream.
This idea was quickly adopted by several groups, here are the ones I have witnessed:
- Business process management adopted this methodology, mapping out the flow of a company or business. It was then incorporated in their QMS (quality management system) framework.
- Project management groups mimicking the business flows in their project execution, mapping a chronological order of events that take place in the execution of the project.
- Quality in manufacturing speaks to the one-piece flow (widely used in Lean methodology.) In 1913, Henry Ford created the “Flow Production”, moving his factory equipment in a consecutive sequence that started from raw materials to the finished automobile. In fact, he only had one part number.
- Finance and Quality groups used this approach to describe cost erosion or spending, moving forward in a linear path to show the decrease in the funds with explanations. It was used as a visual support to explain the root cause analysis.
In fact, if the inputs and outputs of each group were predictable and limited uncertainty, this concept worked. Therefore, to make Waterfall work, the following constraints need to be met:
- Scope is well-known: it is clear what needs to be done and how it will be executed.
- Requirements are clear: the customer’s expectations align with what the company produces.
- Scheduling / time is fixed: knowing the tasks to be completed and the work being done will give an accurate estimation for the waterfall to be completed.
- Cost-effective: knowing exactly how much it will cost avoids any cost overruns.
- Risk adverse: little to no risks during the execution phase because there are no unknowns to what needs to be done.
- Infrequent Customer involvement or collaboration: no need to clarify with customer during production, simple communications of where you are at suffice.
The biggest constraint was that it fostered a Silo setup of business process flow when executing projects. Similarly, to what Dr. Royce showed as his five steps, an example of a typical project’s waterfall is shown below in the figure:
It is understood that the main person interacting with all these steps or groups is the project manager. If the project they are planning falls in the constraints stated earlier, then they can manage the project successfully for the company and the customers. But if there are any changes to those constraints, then the plan goes out the window. Getting the cross-functional team with all the SMEs can be challenging, and if accomplished, each group will defend their turf only enhancing the silo effect.
There is a caveat to this waterfall. Though project managers know that some steps do start before the other is completed, depending on the details within each step, the project managers impose the waterfall remains the same. An example being long-lead item drawings are sent to the procurement group so they can be sourced before all drawings are completed. Thus, the SME (subject matter experts) within each step or group will complete their portion based on the information provided to them and move their piece to the next step. It is assumed that it flows one way and not that the recipient of the SME’s work sends it back due to shoddy workmanship.
The reasons waterfall does not work for any type of project is all related to the flexibility to change during execution:
- Customization limitations: customers are getting what is a standard staple of the company and nothing changed to the offering. A customer asking for something different than the contract scope would mean amending the contract, updating the schedule with possible delays, updating the budget with possible overtures (incl. additional resources) and incorporating new potential risks into the log.
- Poor in handling crisis management: if something out of the ordinary occurs, like power outage, or the tsunami that hit my company’s manufacturing plant, there is no flexibility in the plan to cover for this devastation. The plan needs to be updated with new dates, costs, risks, and scope to oversee this catastrophe.
- Internal change limitation: if there is a constraint abiding to the contract and thus, a change needs to be made. Depending on the change, the plan needs to be recrafted because it no longer works as-is. Examples are a supplier delivers defective products creating delays, the raw materials are in shortage (we saw this with COVID), the costs of the raw materials (i.e., steel, copper) fluctuate, and employee turnover.
- Risks turn to issues: if a risk is in a log and you are mitigating it, it remains a risk. But as soon as it materializes, it becomes an issue which is a change to plan. You enter crisis management trying to contain it so that it will not cost as much, and it will not delay the schedule. If the contingencies you have in place work, then you are good but if not, then it will alter your plans.
So why use waterfall methodology? It is a cost-effective way of doing business if your company uses a repeatable process with no surprises. It also is easy to understand when used as a visual aid.
Yet Dr. Royce ended his white paper with his view that the waterfall method could only be used for simpler software projects. For any project dealing with complexity, he had mapped the spark for Agile thinking with his figure resembling more of a system map with interactions than a one-way flow. I encourage you to see Dr. Royce’s white paper so you too can see the irony in the birth of the waterfall method.
Dr. Royce may have created the waterfall method to disprove it for the projects he was managing and get additional funding to improve upon it, we are still using it today for traditional project management. In fact, as stated earlier, we are using this way of thinking in other disciplines as well. The waterfall’s resilience is still going strong. In fact, it may not help with a complex project, but it can help you tell a story on how the project failed.
Share your experiences and comments. If you want to learn other ways of using waterfall creatively, reach out.