Product development: The Waterfall methodology (model) in software development
Most software product development uses either the Agile or Waterfall methodology. A development methodology is the process by which an engineering team will build a given product.
The Waterfall methodology—also known as the Waterfall Model—is a sequential software development process, where progress flows steadily toward the conclusion (like a waterfall) through the phases of a project (that is, analysis, design, development, testing). This involves fully documenting a project in advance, including the user interface, user stories, and all the features’ variations and outcomes.
The goal of the Waterfall methodology follows the old adage to “measure twice, cut once.” A detailed investigation and full research into a product feature is conducted up front, eliminating (most) project risks. With the bulk of the research done in advance, estimates of the time required for each requirement are more accurate, thus providing a more predictable release date.
Project phases for software development using the Waterfall Model
The product development team analyzes the requirements, and fully understands the problems. This is a research phase that includes no building. The team attempts to ask all the questions and secure all the answers they need to build the product requirement.
The software developers design a technical solution to the problems set out by the product requirements, including scenarios, layouts and data models. This phase is usually accompanied by documentation for each requirement, which enables other members of the team to review it for validation.
Once the design is approved, technical implementation begins. This is often the shortest phase because research and design have been done in advance.
Upon completion of full implementation, testing needs to occur before the product can be released to customers. The software testing team will use the design documents, personas and user case scenarios delivered by the product manager in order to create their test cases.
Adaptation during product development
If nothing changes over the course of the product development, then estimates generated from the Waterfall methodology will result in a predictable release date.
However, change is inevitable, and will come in many different forms. For example, you might learn more information about a feature and will need to adjust the requirements, or your team might realize once they begin the build that it is more complicated than initially imagined. These factors will change the delivery dates, and add risk to the project.
In the Waterfall Model, change is expensive because most of the time and effort has been spent early on in the design and analysis phases. Also, because the team will be so invested in the requirements before the project begins, there may be considerable resistance to change.
Product manager’s role in Waterfall methodology
In the Waterfall methodology, the role of the product manager is to create the requirements and ask all pertinent questions up front. Because the team does all of the research and design in the initial phases, the requirements given must be as complete as possible. As well, the requirements drive the detailed estimates on which the project plan will be based.
The Waterfall methodology is a documentation-heavy approach because it relies on the “measure twice, cut once” theory. The product manager’s workload is much heavier at the beginning of the project than it is during the actual release. The aim is to ask all pertinent questions in advance to minimize change during the development process, especially since change is relatively expensive.
Customer input in the Waterfall methodology
The nature of the Waterfall methodology insists that each phase be complete and perfected before the start of the next phase. This prevents customers from reviewing and providing feedback on a project before its release. Even if suggestions were solicited, since change is expensive, the team will be less flexible about accepting feedback.
Building solutions that have features that are not dependent on each other can help mitigate these issues, although challenges will remain. For example, a wind-powered energy solution may have different components, and by ensuring that each part can work independently, your team can mitigate overall project risk.
Example: Product development—Waterfall methodology
If a team were to develop a customer address book using the Waterfall methodology, the order of work would be as follows (timeframes are for demonstration purposes only):
Product manager creates requirements documents that include the following requirements (in order of priority):
- User should be able to create new contacts.
- User should be able to view their contacts.
- User should be able to import contacts from other programs.
- User should be able to email their contacts from the address book.
- User should be able to add pictures to represent their contacts.
These requirement documents will include detailed requirements, user scenarios and potential layouts for the functionality.
Timeframe: 2 weeks
Engineering team takes these requirements and analyzes them, asking questions as needed. Product manager updates documents as questions are resolved.
Timeframe: 1 week
Engineering team creates a design for functionality, including database design, mock-ups and workflows.
Timeframe: 3 weeks
Engineering team develops functionality and prepares it for testing.
Timeframe: 1 week
Software product testing
Product team tests entire functionality.
Timeframe: 2 weeks
The product functionality is released.
TOTAL elapsed time: 9 weeks
Note: if any changes to the design occur during this workflow, the project would have to return to the second or third phase and restart the process.
Waterfall vs. Agile methodologies
There is much debate about the merits of the Waterfall and Agile software development methodologies. In the end, it is up to your organization to choose the most appropriate system.
Review the article, Product development: Agile methodology to form your own opinion of how you would like to manage your development process.
McConnell, S. (2006). Software Estimation: Demystifying the Black Art.Microsoft Press.
“Waterfall vs. Agile Methodology.” 2008. Agile Introduction for Dummies. Retrieved August 13, 2010, from http://agileintro.wordpress.com/2008/01/04/waterfall-vs-agile-methodology/