While agile has been stealing the project management methodology spotlight in recent years, let’s not forget another approach that has truly stood the test of time – the waterfall methodology.
With its structured and sequential nature, the waterfall process brings a level of clarity to project management, offering a multitude of benefits for all stakeholders.
It can make your projects flow smoothly, avoid bottlenecks, help you hit deadlines, ensure deliverables are met before the next phase begins, and allow the team overall to shine with perfection.
This in-depth guide analyses the advantages of the waterfall methodology. Learn the benefits and understand the edge over agile in this PMO expert assessment.
The waterfall method of project delivery seems to have had a bad rap, with many commentators and organizations stating that they have ‘gone agile’.
There is a reasoning amongst some professionals that agile means nimble, flexible, adaptive etc.
All of which are great attributes for any methodology.
Conversely, if you are not ‘agile’ you must therefore be rigid, slow or fixed.
Not good.
On the face of these attributes, who wouldn’t pick an agile compared to a waterfall approach?
But this is far too simplistic.
Both approaches have their merits, but in some organizations the proponents of waterfall and those of agile seem to think that only one approach is good and the other is bad.
We hope to show you that such zealotry is misplaced and, as we shall see, both approaches can be relevant.
The waterfall model or methodology is so described because the stages of a project tend to be sequential rather than iterative, i.e. each phase needs to be completed before the next phase starts.
In the initiation phase you are getting to understand the objectives of a project, the scope, costs, benefits and mobilizing the team.
You then progress to the requirements phase where you document and secure sign off of 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 lack of user involvement until user acceptance testing.
In this intervening gap, requirements may change or the outcome could have been misunderstood by the project team.
The logic then follows 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 through to the project management team.
This leads to projects being delivered that may meet the original business requirements but no longer reflect what is actually needed.
However, the reality 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 during 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 to defining requirements and specifying these to a high 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 needs to be delivered and it is more efficient to manage a set of sequential phases.
Winston W. Royce was an American computer scientist and software engineer who made significant contributions to the field of software development and project management.
He is best known for his paper titled “Managing the Development of Large Software Systems,” published in 1970, which introduced the concept of the waterfall model.
Different projects require different approaches, and there are a number of situations when the waterfall approach is ideal.
These include:
The agile methodology has a very different approach to waterfall. There is more emphasis on flexibility and speed of delivery.
With a real focus on delivering modules or part of a project quickly, there are numerous approaches when it comes to agile project management.
A common method 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 are 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.
Source: Agile manifesto
These are a great set of principles, but they also rely on certain organizational factors being in place.
For example, there is more emphasis on self-organizing teams than in waterfall, and a level of trust is needed to get the job done.
There is also a requirement for team members to be collaborative and the users to be part of the team.
Ideally, the team is located in the same place as this makes collaboration and self-organizing 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.
There are several situations when an agile approach is suitable.
These include:
There are many benefits of agile, including:
“A number of years ago I was called in to review a large software redevelopment.
A retailer wanted to upgrade the technology platform of their Point-of-Sale system.
The were happy with the requirements and, to reduce training costs, wanted the new system to look and operate in exactly the same way as the current system.
The requirements of the new system were 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 heading 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-organize.
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 had been used.
This project met all the criterial listed above that would suggest a waterfall approach.”
IT teams are always searching for the silver bullet that will deliver projects faster and more successfully.
Unfortunately, the statistics on project success rates have not improved.
In our 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.
Not all projects are suited to an agile approach.
However, too many organizations have simply ‘gone agile’ for every project.
Not every project is suitable for agile so before you throw out the ‘old-fashioned’ waterfall method, make sure that the proposed project and team are suited to an agile approach.
Waterfall has suffered from bad press over the years, with some people who still run waterfall approaches even being considered dinosaurs.
Yet 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.
So in the spirit of these ‘agile’ times, stay flexible!
Waterfall software refers to the application of the waterfall methodology in software development projects.
The waterfall methodology is a linear and sequential approach to project management that was initially introduced in the manufacturing and construction industries but has since been adapted for software development.
In the context of development methodology, the waterfall model follows a sequence of different phases, with each new phase depending on the completion of the previous one.
The typical workflow includes requirements gathering, system design, implementation, testing, deployment and maintenance.
Once a phase is completed, the project moves forward, and it becomes a challenge to revisit and make changes to the previous phase without disrupting the entire process.
The waterfall approach is often characterized by its well-defined documentation, comprehensive planning and clear milestones.
It emphasizes thorough upfront planning and a detailed understanding of project requirements before proceeding to the development stage.
This methodology assumes that the project requirements can be clearly defined at the beginning and remain relatively stable throughout the project’s lifecycle.
As a project management approach it has many benefits, such as providing a structured framework and facilitating documentation.
However, some project managers will always argue that it lacks the flexibility and adaptability to changes that can arise during the software development process.
Agile methodologies, which prioritize iterative and collaborative approaches, have certainly gained popularity as alternatives, particularly in dynamic and complex software engineering projects.
It’s important to note that the waterfall methodology assumes a linear progression through these stages, with each stage being completed before moving on to the next. This sequential nature distinguishes the waterfall model from more iterative and flexible methodologies like agile.
The waterfall methodology and agile methodology differ significantly in their approach to project management and software development. Here are some key differences between the two:
Both methodologies have their strengths and weaknesses, and their suitability depends on the specific project’s nature, requirements and constraints. Waterfall is typically used in projects with well-defined and stable requirements, while agile is favored in projects that require flexibility, adaptability and frequent customer involvement.
The waterfall model is a traditional and sequential approach used in the Software Development Life Cycle (SDLC). It follows a linear progression of phases, where each phase is completed before moving on to the next. The waterfall model typically consists of the following phases:
The waterfall model assumes that project requirements can be clearly defined upfront and remain relatively stable throughout the project. It is characterized by its emphasis on comprehensive planning, documentation and a well-defined sequence of phases. However, the waterfall model can be less adaptable to changes and may not accommodate feedback and adjustments as effectively as more iterative approaches like agile methodologies.
No, the waterfall method does not use scrum. Scrum is a specific agile framework, whereas the waterfall method is a traditional and sequential approach to project management.
Scrum focuses on iterative and incremental development, emphasizing flexibility, collaboration and adaptability to changing requirements. It utilizes short development cycles called sprints, daily stand-up meetings and various scrum artifacts (such as the product backlog and sprint backlog) to manage projects.
On the other hand, the waterfall method follows a linear and sequential approach, where each phase is completed before moving on to the next. It emphasizes comprehensive upfront planning and assumes that project requirements can be defined and remain stable throughout the project.
While scrum and the waterfall method are both project management approaches, they have different principles, methodologies and practices. Scrum is designed to accommodate changing requirements and encourage collaboration, while the waterfall method is more suitable for projects with well-defined and stable requirements.
I am always wary of the organizations 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: pm3sales.us@elecosoft.com
Our products help you deliver successful change programs and projects by always focusing on the overall business outcomes. Find out how our products can help you.