The Cascading Costs of Waterfall
The Waterfall model has traditionally been a popular one in software development. So-called because of its sequentially flowing process — conception to initiation to analysis to design to construction to testing to implementation — it has been the most prevalent product development methodology in the software product space for a while.
Waterfall is an easy model to follow. A linear system of getting things done in a way that makes logical and intuitive sense, it’s easy to get teams on board even if they have diverse backgrounds, because everyone knows exactly what’s expected of them far in advance. Waterfall requires little flexibility, which works well for rigid teams who don’t like being flexible.
The Big “But” of Waterfall
“‘Prevention is better than cure’ applies to defects in the software development life cycle as well as illnesses in medical science.” — Mukesh Soni
But (and there’s a BIG BUT), with Waterfall, most of the energy is put into understanding and eliminating risk through trying to anticipate the end state of the product far in advance. This model relies on extensive planning up front. If you do that planning, and follow the methodology precisely, you will create a very clear picture of the end state of your product before development even begins. In many larger organizations, in fact, the pre-planning is likely taking place years in advance, and roadmaps are developed without much understanding of how the marketing, product, or landscape might change before the product is even ready for market.
If you use the Waterfall methodology on small projects, it’s like you’re swimming in calm waters with gentle shifts from pool to pool. If you make a mistake, it’s not that hard to get back up to where you were, even with the water pushing against you. But with a bigger project, you find yourself in a much wilder and more aggressive environment. It’s like a Class V rapid where any misstep might send you hurdling over a dangerous waterfall that you can’t recover from. It’s nearly impossible to navigate back to where you were without incurring significant effort, time, cost, and diversions. And one tiny mistake on a Class-V rapid can be fatal; the same goes for large projects relying on the Waterfall model.
The True Cost: Loss of User-Focused Experience
We once worked with a client whose web-service project was being built using the Waterfall methodology. Several of the published features had been planned out well over a year in advance, and as we became involved in the project, we quickly realized that these features were not solving problems for actual users. We tried to insert some user testing into the project and conduct a post-mortem on the current release, to no avail. The project management team was afraid of what the results would show, and wouldn’t get on board. The general corporate mentality was that it’s better (for both careers and departments) not to know bad news. This mindset, unfortunately, is common.
The client pushed forward with their product plan, using Waterfall, and delivering on time with all of their sprints. They were doing a perfect job of sticking to the initial plan, and constantly congratulated each other. To this day, they still see this project as a success, because they hit all their deadlines, managed the process to a T, and stayed on budget (albeit a budget of millions).
But even as deadlines were met, budgets honored, features launched, and fanfare gathered, not one single person on the 20+-person team bothered to notice whether the new features were being used by actual people. Our own analysis showed that for one main feature, which had consumed at least a quarter of the budget, the usage numbers were dismal. Less than 10 percent of users were even using it — although those numbers were being artificially driven up by members of the product team showing it off.
As user-centric product developers, this made us sick to our stomachs. We believe in creating products people want to use.
Don’t Be a Victim of the Waterfall Mentality
IBM’s Systems Sciences Institute reports that the cost to fix an error in the maintenance stage after product release is up to 100 times more than the cost to fix it if found in the design phase.
Given the current pace of the mobile, social, digital space, prioritizing speed and adapting quickly in everything you do is essential for the survival and success of your product and company. Not only does your application itself need to perform quickly, but you need speed in your decision-making and your ability to change course when necessary.
Waterfall prioritizes a slow, careful, meticulously planned approach — not aligned with solving user problems. Waterfall lends itself well to fancy PowerPoint presentations in front of core stakeholders gathered in a boardroom. But it doesn’t have much to do with actual users.
If usability is the goal of iteration — which it absolutely is — then the hidden cost of Waterfall is clear.
It’s a fact that it’s less expensive to fix a fundamental software problem early on in the development cycle. Think about a house that you are building: it’s much easier to move the placement of a room or the shape of the house during the design stage. Once the foundation is poured and the structure starts to go up, this type of change gets more and more expensive.
Using a development model that allows for iteration early on, and all along, is important. Unfortunately, Waterfall is not that model for a lot of people, which is why this model is far out of favor for innovative developers.
Still, the Waterfall model has its place, especially on simple projects that can be completed in less than six weeks. This model can work well if you’re developing a second-generation iteration or a refactor of a product that is already in production. In these instances, Waterfall can feel like rapid prototyping, but the key difference is the product should be shipped after the six-week interval, assuming it can stand on its own and serve a purpose for a period of time before future enhancements are required.
It’s an effective model — but in our opinion, it’s not usually the most efficient or adaptive one. In fact, we’ve heard it said that Waterfall means “death by meeting.”
Nevertheless, if you are committed to bringing your initial plan to fruition without a lot of feedback or any risk of a pivot, this is possibly the product development model for you.
Want to keep going? Read our book Got Ideas? How to Turn Your Ideas into Products People Want to Use, which takes novice product-makers through the journey of creating great, user-friendly digital products from the thin air of their imaginations. Available in hardcover, paperback, ebook, and audiobook, it’s a hands-on, practical manual for aspiring entrepreneurs and intrapreneurs.
