To insights

blog

On the merits of waterfall

The misunderstood scapegoat

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.

Waterfall is still a very popular project model. It is, however, often misunderstood and thus often applied improperly. This can lead to disappointing results. The model becomes the designated scapegoat responsible for all wrongdoings. In fact, the same can be observed with newer agile/scrum models. It need not be so, states Eric Boulet, Project Manager at TriFinance Financial Institutions and member of the Transformation and Project Management Practice. His article presents an alternative way of how waterfall can be implemented and touches upon when it is appropriate to use this model, even in times of remote working due to the COVID-19 pandemic.

What the theory says and what experience has shown

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

How waterfall can also be applied

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.

  • Firstly, the planning was adapted by splitting the project in two parts. The idea was to have more achievable/manageable milestones reducing risk budget- and timewise.
  • Secondly, the bank and other stakeholders were heavily involved throughout the project, not just during the requirement and verification phases. For instance, long before the development started and even before the design phase, hand-generated output was delivered for verification by other stakeholders. Such verifications, whether through automatic or hand-generated output, happened with each change or progress in development. In short: there was continuous corroboration with other stakeholders.
  • And thirdly, during the analysis and design phases of the first part of the project, functional and non-functional testing of core components took place. While this Proof Of Concept (POC) necessitated some additional work, it validated the feasibility of the project and gave the project team experience on the subject reducing once more overall risks.

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.

When to go down the waterfall

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:

  • The problem and solution are well-understood; it’s not about discovering the answer through trial & error as can be the case when designing a user interface. It also helps if there are no changing requirements.
  • Project experience of those involved is either nonexistent or almost exclusively with waterfall-like environments.
  • Time to market is not critical. The project deadline is to be respected, however, there’s no customer value in bringing (part of) the solution early to market.

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.

How it compares to the agile mindset

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 Law of the Customer - an obsession with delivering value to customers as the be-all and end-all of the organization.
  • The Law of the Small Team  - a presumption that all work be carried out by small self -organizing teams, working in short cycles and focused on delivering value to customers—and
  • The Law of the Network - a continuing effort to obliterate bureaucracy and top-down hierarchy so that the firm operates as an interacting network of teams, all focused on working together to deliver increasing value to customers.

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.

In conclusion

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.

About the Trifinance 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.

Grow your career

Come join us

Expand your business

Let's work together

Sign up for the latest industry insights
Set preferences