There are many ways to complete any given project. Most teams develop a method, set that method in stone, and work toward minimal deviations. Over the years, in many organizations, this method has worked relatively well at delivering a finished project. This structure is called Waterfall. Where this workflow method falls short is when the team is required to adapt to sudden changes in the middle of their rock-solid process. Fortunately, this isn’t the only method. But first, let’s take a closer look at Waterfall.
Waterfall is a workflow process comprised of specific phases. Each phase starts only after the agreed deliverables from the previous phase are done. As you can see illustrated in the diagram below, the work flows in one very specific direction.
Once the idea is born, planning begins on the project. Analysis of the project cannot begin until Planning is finished, Design cannot begin until the Analysis is complete, and so on.
The Waterfall process is considered finished when you deliver a complete project. Development is considered ‘done’ when the code has been built and has been sent for testing. The entire project is considered ‘done’ when all of the requirements for the project have been built, tested, delivered and proven to work. Let’s take a more in-depth look at how Waterfall traditionally plays out for teams.
The Disadvantages of Waterfall
In Waterfall, decisions (regarding both design and development) are made strictly within each phase of the process. As an example, changing the designs once the development phase has begun takes considerable time and money. Waterfall is supposed to control the process so that all but the most critical changes are managed or altogether prevented.
When the life-cycle of a project is born, the initial idea is written into a document. This document is then handed off to different people, and those documents take on a life of their own.
- Draft Idea Document
- Send to reviewer. Wait for response.
- Update doc with reviewer’s comments. Send updated doc back to reviewer. Wait for response.
- Produce final draft. Send back to reviewer. Wait for response.
- Wait for supporting docs from all other doc owners. Submit all docs as a pack.
- Send pack to stakeholders for sign-off. Wait for sign-off.
- Submit signed-off package to a shared workspace.
- Wait for document pack to be picked up by the development team.
Using this sequential process, documentation is moved back and forth between different people or teams. Delays are common as each team waits for reviews and sign-offs from other teams. Let’s take a closer look at what these Waterfall steps look like.
Weakness #1 – Time
This traditional method is certainly not unreasonable, and has been proven to work in many scenarios over many years. What this method does outline, however, is how time-consuming and resource-intensive the Waterfall process is.
The business ends up waiting a considerable amount of time for a complete product.
Every requirement is analyzed, designed, developed, and thoroughly tested before being released. Because this needs to be done for every set of requirements – the business ends up waiting a considerable amount of time for a complete product. As a result, the overall return on investment on the project takes even longer as the wait times can be substantial.
Weakness #2 – Cost
The biggest setback during a Waterfall project is change. The intention of exclusive project phases are that the phase itself is finite, so that once that phase is complete no changes can possibly occur. Unfortunately, most projects inevitably have changes. And when changes do occur, there are repercussions throughout the project.
The cost for implementing changes is compounded over the life-cycle of the project.
So why does this up being so costly? The cost for implementing changes is compounded over the life-cycle of the project: minimal during the concept and design phases, ten times higher during development, and hundreds of times more costly once it’s launched.
Next: The Benefits of Agile