Advantages of the Waterfall Methodology

Blog Amrit Sandhu 09-09-2022

Waterfall or Agile Approaches

In this blog, we will look at the merits of using waterfall or alternatively agile.

Both approaches have their merits but in some organisations the proponents of waterfall and those of agile seem to think that one approach is good and the other is bad.

This zealotry is misplaced and as we will see both approaches are relevant.

What is Waterfall methodology?

Has the waterfall method of delivery projects had a bad rap?!

Many LinkedIn commentators and indeed organisations are going ‘agile’.

There is a reasoning amongst some professionals that agile means nimble, flexible, adaptive etc.

All of which are good attributes for any methodology.

Conversely, if you are not ‘agile’ you must be: rigid, slow, fixed, etc.

On the face of these attributes who wouldn’t pick an agile approach compared to a waterfall approach.

This is, of course, far too simplistic.

Let’s look first at what a waterfall approach to delivering projects really means and also the misconceptions around it.

Waterfall methodology definition/ What is the waterfall methodology

The waterfall methodology is so described because the stages of a project tend to be sequential rather than iterative.

Each phase needs to be completed before the next stage starts.

A depiction of a waterfall project approach is shown below.

waterfall methodology advantages
Waterfall Methodology   

In the initiation phase you are understanding the objectives of a project, the scope, costs, benefits and mobilising the team.

You then progress to the requirements phase where you document and get the users to sign off the user or business requirements.

Next, you specify these requirements in more detail, undertake technical design, build, test and then transition into a live service.

The criticism that is often levelled at waterfall is that users get involved in requirements gathering and specification, but then there is a gap of user involvement until user acceptance testing.

In this intervening gap, requirements may change and / or the requirements are misunderstood by the project team.

The logic then continues that as the business environment is changing at a rapid rate, the requirements are likely to change and, if the users are not involved in the mid-part of the life cycle, changes to requirements are not fed into the project team.

This leads to projects being delivered that may meet the original business requirements but no longer reflect what is actually needed.

The reality, in my experience, is that this does not happen in a well-run project.

A ‘good’ project manager wants to deliver the outcomes that the users want and need.

It makes sense for the project team to liaise and communicate with the user community during all aspects of the project and not just the requirements gathering and specification.

There are many situations where the requirements do not change a great deal over time and there is an advantage of defining requirements and specifying these to a low level of detail.

Some project teams are more comfortable with the waterfall approach because – if the requirements are not likely to change – there is more certainty in what is needed to be delivered and it is easier to manage a set of sequential phases.

When should you use the waterfall methodology?

There are a number of situations when a waterfall approach is ideally suited.

These include:

  • When requirements are unlikely to change in any significant way
  • Teams are disparate
  • Outcomes and end goal are clear
  • Requirements are fully documented and easy to test against especially when using third parties
  • Users do not have the time to actively participate in every stage of the development process

Agile Methodology

The agile methodology has a very different approach to waterfall. There is more emphasis on flexibility and speed of delivery.

There is a real focus on delivering modules or part of a project quickly. There are numerous agile approaches.

A common one involves developing user stories which are a set of mini requirements or features of a system.

These user stories are developed in close conjunction with the key users.

As we will see later the agile philosophy is to work very closely with the users and the product owner.

These user stories will have broad estimates and then placed in what is called a sprint.

These sprints are typically time bound and during the sprint some stories may be demoted from the sprint and not delivered as there is typically a fixed sprint delivery date.

There are a lot of feedback loops in agile and it delivers software in a set of iterations unlike waterfall which tends to be more sequential and often results in a ‘big delivery’.

The original team of professionals who developed agile as a method developed a number of agile principles which I have detailed below:

Agile Principles

  • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  • Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  • Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  • Business people and developers must work together daily throughout the project.
  • Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.
  • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  • Working software is the primary measure of progress.
  • Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  • Continuous attention to technical excellence and good design enhances agility.
  • Simplicity–the art of maximizing the amount of work not done–is essential.
  • The best architectures, requirements, and designs emerge from self-organizing teams.
  • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Source: Agile manifesto

These are a great set of principles but they also rely on certain organisational factors to be in place.

For example, there is more emphasis, than in waterfall, on self-organising teams and a level of trust is needed to get the job done.

There is also a requirement for teams to be collaborative and the users / sponsors to be part of the team.

Ideally, the team is located in the same place as this makes collaboration and self-organising easier.

Yes, a lot of teams are now working from home and using Teams or Zoom, but this is not as efficient as collaborating in the same place.

When to use Agile

There are a number of situations when an agile approach is ideally suited. These include:

  • End goal is vague or uncertain
  • Requirements are likely to change
  • Incremental delivery is more important than delivering a big bang solution
  • Project team is motivated and embrace change
  • Product Owners area actively involved in the team

Benefits of Agile

There are many benefits of agile and these include:

  • Embraces change more readily
  • Less time spent modifying detailed project plans
  • Development is incremental
  • Team feels empowered
  • Close user involvement improves likelihood that delivery meets user expectations
  • Timeboxed sprints increase predictability of delivery

Case Study / War Story

A number of years ago I was called in to review a large software redevelopment.

This retailer wanted to upgrade the technology platform of their Point-of-Sale system.

The were happy with the requirements and, to reduce training costs, they wanted the new system to look and operate in exactly the same way as the current system.

The requirements of the new system were very clear and understood.

The scope was also very clear and it was not acceptable to drop anything out of scope.

The development manager had adopted an agile approach to this project using an off-shore partner in India.

This project was not going well and headed for the rocks.

There was no benefit in going agile for this project; in fact quite the reverse as the team was not used to the fluidity of the agile approach or able to self-organise.

Requirements were documented and were unlikely to change.

The scope and end goal were also clear.

Agile was chosen because the development manager wanted to try this new approach.

In this case the project would have been more successful if a more traditional waterfall approach was used.

This project met all the criterial listed above that would suggest a waterfall approach.

Agile – Its latest Silver Bullet?

For as long as I have been involved in project management IT has been searching for the silver bullet that would deliver projects more quickly and more successfully.

Unfortunately, the statistics on project success rates have not improved despite the various ‘silver bullets’ that have been tried.

In my opinion, agile is a great approach for certain types of projects but it can be a more complex set of processes to manage.

The agile teams have to be adaptive and absorb frequent change.

Not every team is capable of delivering in an agile way nor are all projects suited for an agile approach.

Unfortunately, too many organisations have ‘gone agile’ for every project.

As I have stated, not every project is suitable for agile and before you throw out the ‘old-fashioned’ waterfall method, ensure that the proposed project and team are suited to an agile approach.

Waterfall has had a bad rap over the years and people who still run waterfall approaches are considered dinosaurs and behind the times.

The reality is that some projects are ideally suited to waterfall, and you will improve your project delivery success rate by choosing the right approach for each project.
PM3’s Support for Agile and Waterfall

PM3, Bestoutcome’s award-winning Project, Portfolio Management (PPM) tool supports both traditional waterfall projects and also agile projects.

PM3 supports: user stories, sprints, Kanban and also burndown charts.

Click here for more information on PM3

PM3 Scrumboard screengrab


I am always wary of the organisations that have gone agile for every project.

Some projects and teams are suited for agile, but others are more suited for a traditional waterfall approach.

For more information on how PM3 supports both approaches, please contact us at:

Outcome-driven success

Outcome-driven success

Our products help you deliver successful change programmes and projects by always focusing on the overall business outcomes. Find out how our products can help you.

Get in Touch Schedule a Demo

Related Resources


Latest PM3 release includes Agile Support and PM3 Team mobile

The latest release of PM3 includes a number of important functional improvements including:...

Read more >

7 Simple Steps to Realise Your Project Benefits


Read more >

Project Management Myths. PRINCE2 makes a good project manager

We at Bestoutcome were working recently at an oil company where there was a desire to improve the su...

Read more >