The Waterfall project model is still very popular, but often misunderstood
With some pragmatism waterfall can give excellent results
Let's put the focus to what matters most: getting the job done.
In the waterfall model, a project is split into sequential phases where each phase is dependent on the results of the previous one. Broadly speaking, the phases are in order: listing the requirements, analysing, designing, implementing, verifying and finally maintaining the solution. Note that the theory says a next phase can only start when the previous one is finished. In reality, it’s extremely common to have some overlap between the phases. For example, development already starts while the design, having taken longer than envisaged, is yet to fully conclude.
This sequential way of working feels intuitive and is, in fact, applied by all of us in everyday’s life for such mundane tasks as doing the groceries or assembling a closet. We are faced with a situation, think on how to approach it and then act. Furthermore, thanks to its extensive analysis and design phase(s), it’s not an absolute necessity to have much experience across the team. Indeed, with (very) detailed analyses the development team does not need to have much experience.
The downsides are important: poor adaptability to change, important time to market while risk reduction is heavily dependent on the thoroughness of the analysis and design. As a consequence projects often go over budget and over time; the sunk cost fallacy is the ever-present pitfall that prevents project cancellation for bad projects.
This way of applying waterfall is very rigid and stringent. As such it’s typically not the best way of doing things and is also not how waterfall is usually utilised in successful projects.
With some pragmatism, i.e. interpreting the theory as only a guideline, waterfall can give excellent results and can even be the most appropriate way of working.Eric Boulet, Project Manager at TriFinance Financial Institutions
Through a real-life example, a more pragmatic or realistic way of applying waterfall is showcased. The changes to the theoretical model are borrowed from other models and helped reduce risks. It was known from experience that these work well in practice.
The year is 2015 and I’m the project manager responsible for the development and delivery of software that manages current accounts at a major French bank. Project duration, excluding maintenance, was around nine months and I had seven developers in my team. Functional requirements consisted of a list of operations: creating and deleting accounts, transferring money, blocking and unblocking clients, changing the account limits etc. No user interaction with the new software was possible, all operations were automated. It is important to note that this solution would replace an older one and needed to be integrated into a greater whole. Furthermore the rest of the bank’s software needed to remain as untouched as possible. Also important, the format of the input and the output was mostly known from the start.
Three changes were made to the theoretical waterfall model to better fit the project. I’d like to stress that this way of applying waterfall is far from being uncommon.
One might wonder if this can still be considered waterfall? Taking into account that the project consisted of well-defined sequential phases with the analysis and design mostly finishing before development, it certainly followed its basic principle.
Here, you will find the simplified project timeline.
The example above illustrates how waterfall can also be implemented. This brings us to the question: when is it suitable to use waterfall?
The following points are excellent indicators:
If any of these holds true, it’s probably a good idea to pick waterfall. Incidentally, in the above example, all three indicators were true.
It is worthwhile to compare the above-described way of applying waterfall to what has currently become the go-to way of working: agile or more precisely the agile mindset. In a previous article on fake agile, I wrote about the three laws of agile as defined by Steve Denning. These are:
The importance of these laws was stated in the conclusion: “It’s hard to see how an organisation that follows the three laws could not efficiently deliver value to its customers. And in the end, that’s what truly matters … regardless of how one calls it or which methodology is used”.
The project mentioned above arguably follows two of those three laws. Only the law of the customer is violated, with the customer being the clients of the bank. After all, the project seemingly doesn’t do anything for the customer: the new software emulates the old one, in other words, the customer shouldn’t see any difference. It’s true that there was no quantifiable benefit for the customer but there were qualitative arguments for the bank. However, it would only distract us from the topic at hand to discuss this further. Delivering value to the customer is more about the reason why a project is undertaken and is critical to keep in mind, less about how a project should be conducted.
Waterfall is far from being this rigid project model that is so often scorned. In fact it’s only as rigid as one wants it to be. Looking at the theory as a guideline instead of an unbreakable law certainly helps. Applying strict waterfall can produce and has produced great results in the past but is probably difficult to put in practice. By borrowing good concepts from other models and when it’s appropriate to use, a more pragmatic approach to waterfall can be very good.
When defining the way of working, the focus shouldn’t have to be on implementing the currently popular project model. Neither should it be to blindly trust one model over the other. Instead, it pays to spend time studying what exists and adapt it to the particular needs and context of a project. This puts the focus to what matters most: getting the job done.
Written by Eric Boulet, Project Manager at TriFinance Financial Institutions and member of the Transformation and Project Management Practice.
For those interested in project models, FI’s Transformation and Project Management practice is, among other things, involved in better understanding these topics and applying its knowledge at the client side. Its members use their experience in project management, business expertise and business transformation to successfully complete projects and to give support to other TriFinance consultants in their work.