The Four Deadly A’s of Change Initiatives
Why transformation projects fail to meet expectationsRead More
Author: Scott Lutz
Since the 1970’s, Waterfall Project Management has been the leading methodology for project managers to drive projects forward, track progress, and hold team members accountable to due dates and deliverables.
In the past 15 years, new frameworks and methodologies such as Agile and Kanban, have taken over as the popular and cutting-edge project management styles, leaving Waterfall to seem dated and “old school.” This has many wondering if Waterfall is a dead methodology that makes a company seem stuck in the past. In the technology industry, being perceived as lagging behind is a bad place to be.
For software development projects using Waterfall, there is typically a structured plan or timeline that is split into distinct phases over specified timeframes. Standard phases typically include some version of: Analysis, Planning, Requirements, Design, Build, Test, and Maintain. A subsequent phase does not begin until the previous phase has fully completed. This approach assumes most everything is known and accurately completed before going to the next phase, leaving little, if any, room for changes.
Conversely, Agile frameworks operate using iterative cycles with the waterfall phases happening in two-to-four-week increments called Sprints. These increments allow teams to adjust to new information and changing requirements, repeating the process until a product owner agrees that the deliverable meets end-user needs.
So why has Waterfall project management fallen out of favor compared to Agile? The first, and arguably largest, reason is Waterfall’s lack of flexibility when it comes to changes in design, requirements, or timeline. Today’s world of tech is constantly evolving, and customer demands are always changing.
With Waterfall, the original design of a product is based on perceived or researched customer needs. Because of its rigid process, these needs can be outdated by the time the product is deployed.
Another popular reason is that Agile highlights issues sooner. With Agile, some portion of product is deployed to stakeholders for immediate feedback, allowing the team to adjust along the way. Waterfall forces stakeholders to wait months or even years before seeing a working product.
Despite these arguments, Waterfall still holds value and, in some cases, can be the better project management approach. Some common examples of when Waterfall might be preferred are:
Waterfall project management still “holds water” as a tested and successful methodology for certain companies, teams, and projects. Agile project management has its place, however, in some scenarios, it can be too vague, messy, and difficult to manage.
Many organizations see the use of Agile as a shortcut to success, but a project’s outcome is directly correlated to the team supporting that project, regardless of methodology. There will be times when the nature of the project, team composition, team experience, or even corporate work is better with “old school” Waterfall than the “new-fangled” Agile approach.
Worried about your project’s exploding budget or slipping timelines? Contact RevGen to speak to one of our project management experts today.
Scott Lutz is a manager in RevGen’s Digital Enablement practice. He specializes in program and project management and overseeing software implementations for his clients.