A History of the Waterfall Method
Waterfall is a logical pattern to follow - plan, build, test, and release in sequence. The history of Waterfall stems from Winston W. Royce’s 1970 article from the Proceedings of IEEE WESCON, Managing the Development of Large Software Systems. Royce’s article was probably the first discussion of Waterfall in software development, though the word “waterfall” does not appear anywhere in the article. The formal term was introduced in Thomas E. Bell’s and T.A. Thayer’s 1976 paper from the Proceedings of the 2nd International Conference on Software Engineering, Software requirements: Are they really a problem?. As has been noted in many places, however, Royce’s paper did not praise the method. In fact, he described it in unflattering terms, calling it flawed and inviting failure in many ways. He went on to discuss a more iterative approach, perhaps the foundation of what would become an Agile approach.
Bell and Thayer’s paper discusses a change in approach from a bottom-up to a top-down in the development of software requirements, referencing the adoption of this approach in MIL STD 490/483 (MIL STD 490 discusses specifications practices and MIL STD 483 discusses Configuration Management Practices for Systems). The paper is mainly concerned with examining the approaches empirically to determine which works best. Ultimately, the paper declares that “over the last ten years more structure and discipline has been adopted, and practitioners have concluded that a top-down approach is superior to the bottom-up approach of the past.” The term “waterfall” is used in direct reference to Winston Royce’s paper.
Despite the flaws described by Royce, Waterfall became a preferred method in 1985 when the Department of Defence issued DOD-STD-2167A, Defense Systems Software Development. It described the software development cycle as follows:
- Software Requirements Analysis
- Preliminary Design
- Detailed Design
- Coding and Unit Testing
- Computer Software Component (CSC) Integration and Testing
- CSCI Testing
The forward states that “this standard is intended to be dynamic and responsive to the rapidly evolving software technology field. As such, this standard should be selectively applied and tailored to fit the unique characteristics of each software acquisition program.” However, the requirement was laid out in black and white and followed religiously.
The Waterfall method began to fade from popular use when industry leaders became frustrated with its inflexibility and developed the Agile Manifesto. Since then, more and more companies have adopted Agile, but many businesses still cling to Waterfall, and for good reason. Waterfall has its faults, but it also has its benefits and in the right environment, can be the best practice.
Project Management Guide
Your one-stop shop for everything project management
Ready to get more out of your project management efforts? Visit our comprehensive project management guide for tips, best practices, and free resources to manage your work more effectively.
Benefits of Waterfall Project Management
For all the criticism of Waterfall, there are some real benefits to its implementation:
- It is a simple, straight-forward approach.
- It is easy to develop a plan for managing a Waterfall project since every phase has a start and end, and you know prior to coding what is to be developed, when it is due, when testing is to begin, etc.
- The early planning provides a good basis for designing components that integrate with external systems.
- It is easy to plan resources for Waterfall because, again, you know when everything is to start and end.
- Clients who want definitive beginning and ending dates can find Waterfall reassuring. Customers can be told the date when they will have a product in their hands and, if the project is right for a Waterfall approach, it is delivered on that date.
- The cost of development can be determined in advance.
- Detailed procedures can be used to regulate every part of the process.
- The design-heavy approach of Waterfall forces a disciplined approach to development and makes expectations clear.
- Team members can participate in other projects before their phase begins or after their phase ends, returning to the project as needed.
- The reliance on design documentation reduces stress from developer turnover.
- The design-heavy approach means errors can be spotted in the design phase. There are obvious pitfalls to this and anyone who has worked with the Waterfall method knows that design errors occur, but take an experienced team and put together a plan and you will often get a solid design that can be executed according to plan.
Drawbacks of Waterfall Project Management
Here are some of the top concerns and criticisms of Waterfall:
- Time to release is exceptionally lengthy for large projects. Royce’s paper was kind to Waterfall when it came to small, internal projects, but regarded it as quite flawed for larger, more complex projects. In fact, this is probably the primary reason Agile has become so popular. Projects that were too large were cancelled before they could reach completion via the Waterfall method.
- The second leading criticism of Waterfall is that change is unwelcome. Once testing begins, it is extremely expensive to return to development or to redesign the project. The design must be carefully and correctly written before going too far.
- Working software doesn’t appear until late in the project.
- Bugs written early in the project can create big headaches for later code, but none of that becomes apparent until testing begins, which makes fixing the code expensive and time consuming.
- It is not an object-oriented approach. Waterfall projects are highly integrated. This is another aspect of Waterfall that reduces flexibility.
- It is not a good method for maintenance and other types of long-term projects.
- Hand-in-hand with the preceding criticisms is the fact that customers often don’t know what they want before the project begins.
- If the team is inexperienced or entering uncharted waters, obstacles appear that create jeopardies for the project.
- Testing may be short-changed in order to stay on schedule, which leaves bugs to be discovered by the customer after the product is delivered.
- Events may force the entire project to be scrapped. For example, changes in the industry that occur during the development phase could render the entire project obsolete. Another event may be the discovery of a design flaw so severe that the whole project has to go back for redesign, which can be so costly the customer rejects the project.
Comparing Waterfall to Agile
Waterfall focuses on the design phase of a project, while Agile involves minimal time in design. Both project management options aim to deliver working software, but Waterfall projects typically deliver a release once or twice a year (or even less often) while Agile can deliver working software as frequently as once a week. The deliveries in Waterfall can be large and require a lengthy period of testing, with many companies also using customers to provide Beta testing. Agile tests software as it is built, with the developer often performing the tests.
A significant difference between Waterfall and Agile is that Waterfall is a methodology, but Agile is a “movement” with a variety of derivative methods that apply the principles and values of Agile. Scrum, eXtreme Programming (XP), Kanban, Scrumban, and a number of other methods allow the development team options, so there may be a best choice among them.
An Agile methodology is a superior choice when the client is uncertain about requirements or wants to be closely involved in the development process, and if timelines are short and they want rapid delivery. Waterfall is superior if there are complex dependencies, but Agile is preferable when dependencies are minimal. Agile is also best if speed is more important than quality.
Some drawbacks of Agile are:
- Requires customer involvement
- Costs and timelines are uncertain
- Planning is difficult
- Lack of clarity about final result
- Minimal documentation
- Team members must be cross functional – some who are inexperienced in unfamiliar roles
- Developers are dedicated to a single project
- Scope creep is a risk – as a project welcomes change it can grow out of control and run past its due date
The idea that Agile is a dramatic departure from Waterfall is not entirely true. The Agile approach is actually more of an adjusted Waterfall approach, an attempt to address some of the drawbacks of Waterfall in terms of resistance to change and long delivery dates. The lack of flexibility and high rate of cancelled projects has caused many teams to switch from Waterfall to Agile. However, it is important to understand that Agile still takes a sequential approach - it just uses a shorter sequence. Agile still includes some requirements analysis and design at the beginning, but coding does not start until the requirements and design are completed, and you cannot test code that has not been written or deliver code that has not been tested and integrated. Therefore, Agile can be thought of as a more flexible, rapid form of Waterfall project management.
Tips and best practices for your next project using the Agile methodology.
Learn all there is to know about Agile project management and tips to help you start implementing Agile PM best practices.
When to Use Waterfall Method for Project Management
Deciding between Waterfall and Agile comes down to examining the characteristics of the project and the needs of the customer. In particular, pay close attention to the requirements, the goal, and the objective of the project. Waterfall is often a better choice when:
- The requirements are well understood and not likely to change.
- The customer is not prone to demanding changes.
- The customer prefers not to be involved in the development, but wants to be consulted at the beginning and receive a working package at the end of the project. Agile works best when the customer is involved in all phases (reviewing the product at each iteration), but Waterfall customers need only receive a release and install it. (Note: this is a simplification. Customers also must be educated in using the system and that can be a lengthy and important step. This is the same regardless of the method used, and it may be that educating users once or twice a year on new features for a larger release is less intrusive than educating a customer monthly or even weekly on a smaller set of features. Also, bear in mind that customers who want to be involved can be in a Waterfall-based project. Having the customer in for frequent reviews can be distracting and may lead to unwanted change requests, but it can also keep the project focused on meeting customer needs.)
- The project is small.
- Speed of delivery is not important.
- The delivery is to be applied to a legacy system that is not prone to change.
- You will have similar projects in the future, allowing reuse of the project plan and can glean lessons from the heavy documentation of the previous project.
A Brief Look at the Top Project Management Methodologies
Waterfall is just one of many competing methodologies. When making the decision to implement one or the other, it helps to have an idea what they are. The following is a brief look at the top project management methodologies currently in use.
Waterfall
The Waterfall methodology is generally regarded as a traditional approach to project management. Waterfall was based on the notion of everything happening in sequence, with one phase of a project ending before another beginning. This created many dependencies and also resulted in some fairly disastrous situations for software development. Projects were often behind schedule and over budget, and in some cases completely cancelled when the technology changed too rapidly.
Critical Path Method (CPM)
The CPM method is another sequential method that assumes each step is dependent on the previous step’s completion. The planning phase of a CPM project is more about identifying the most resource intensive portions of the project in order to allocate resources and avoid bottlenecks. Application of the method is done by:
- Identifying required tasks and defining the sequence for completing them.
- Defining the dependencies for required tasks.
- Determining the relationships that are and are not critical between tasks.
- Schedule the expected timeline for each task.
- Develop a Plan B for critical paths.
Critical Chain Project Management (CCPM)
Waterfall focuses on design and CPM focuses on tasks, but CCPM focuses on resources and resource allocation. CCPM concentrates on the factors that may affect timelines, costs, performance, and the risk of under-delivery. CCPM’s approach is to define the critical chain, apply resources that can do the most good, and finally introduce time buffers to the critical tasks in order to ensure timely delivery if problems do arise.
PMI PMBOK® Guide
The PMI PMBOK® Guide method of project management applies the PMI’s five process groups from the text, A Guide to Project Management Body of Knowledge. Here is a high-level overview of these groups:
- Initiating—Set the vision. This is also the process group in which the project manager is selected.
- Planning—Set the scope. The PMBOK describes 24 processes in the Planning stage.
- Executing—Put the plan into action.
- Monitoring and Controlling—This occurs during the entire project and is not a sequential phase that waits on another phase to end.
- Closing—Occurs when the customer agrees to accept the project.
Agile Methodologies
Agile is defined as a movement, not a methodology, but a family of Agile methodologies have been developed in accord with the Agile values and principles.
Scrum
The Scrum method has a small Agile team headed by a Scrum Master. The Scrum Master’s role is to facilitate the work of the team. Planning is minimal and a list is created of the tasks to be worked. Tasks are worked in “Sprints,” which are typically two to four weeks long. Brief daily meetings (called Daily Scrums) are held to go over the day’s tasks and identify obstacles. Team members perform all of the traditional tasks of a project, designing as they go and testing as they complete a task. The goal of the Scrum is to hand over working software. When one Sprint ends, the next begins, with the team drawing a set of tasks from the project backlog. When the overall project objectives have been met and there are no more tasks, the project is complete.
Kanban
The Kanban method is most suited for maintenance projects. The core of the Kanban method is the Kanban board, a list of all tasks (also called Kanban cards) to be performed that is continuously updated and is easily visible to all team members. When a resource (team member) becomes available, that team member takes a task from the board and works on it. Tasks are added to the board and worked on continuously. There is no defined beginning or ending to the project.
Extreme Programming (XP)
Sprints are usually one week in length with many iterations. In XP, change is the key, and XP programmers work closely with stakeholders. XP is ideal for environments where the requirements are constantly changing. Tasks can be replaced in mid-Sprint.
Adaptive Project Framework (APF)
APF assumes that IT projects vary so widely, no one approach ever makes sense. IT projects differ in risk, cost, length, and complexity and often involve uncertainty in market, business value, customer involvement, and objectives. An APF project therefore starts with analysis of the requirements to define strategic goals. The project is executed iteratively and post-mortems are performed after iterations in order to improve the process. Analysis is usually ongoing, so that the entire project can be redefined or adapted as it proceeds in response to the uncertainty issues in order to maintain or increase business value.
Lean
Lean is intended to reduce waste and maximize value. The core values of Lean are continuous incremental improvement and respect for people. Lean focuses on delivering the most value to the customer, maintaining the flow, allocating the work evenly, and most of all, eliminating waste.
Six Sigma
Six Sigma is all about eliminating defects in development through efficient processes and continuous improvement of processes. A rating of Six Sigma means the product is 99.99966% free of defects. When you have a process with a Six Sigma rating, it means that every product delivered via this process can be expected to achieve the same result.
Lean Six Sigma
Lean Six Sigma attempts to combine the Lean and Six Sigma approaches, eliminating waste to make processes more efficient and delivering high value and low defects to the customer.
Process-Based Project Management
In Process-Based Project Management, the focus is on aligning each project with the corporate mission and values. Projects are subsumed in the corporate strategy. Consequently, such traditional aspects of project analysis, such as metrics, are used to determine how closely that objective is met.
PRINCE2
The PRINCE2 method is based on the less successful PRINCE method. The PRINCE Method was not widely adopted because it was too cumbersome, and was revised in 1996 into PRINCE2 by a committee comprised of 150 European organizations. While PRINCE was intended to reduce IT cost and time overruns, it was also developed as a project management methodology for any type of project. PRINCE2 issued a major revision in 2009 which made the method simpler and introduced seven basic principles of project success.
Project Integrating Sustainable Methods (PRiSM)
PRiSM focuses on socially responsible project management. Its intent is to manage projects while reducing negative impacts on the environment and promoting socially beneficial projects.
Benefits Realization
The Benefits Realization method is all about the customer. From beginning to end, the method seeks to ensure that the customer derives maximum benefit from the deliverable above and beyond cost and timeline.
Many Project Management Methods Equal Many Opportunities
There are many methods in the world of project management. Most have grown around new approaches and varying needs that only became apparent as the software industry became both more complex (variety of methods and languages) and also easier (increased ease of writing code). The old methods of project management, however, still retain their value in the right environments, as is evidenced by the companies that still develop projects under the Waterfall method. Many customers still want to know what it will cost and when it will be done before they agree to development, and they also still want to know what will be in it. Without that vital information, how would they know if the deliverable has any business value?
Why Smartsheet is Powerful Tool for Waterfall Project Management
From simple task management and project planning to complex resource and portfolio management, Smartsheet helps you improve collaboration and increase work velocity -- empowering you to get more done.
The Smartsheet platform makes it easy to plan, capture, manage, and report on work from anywhere, helping your team be more effective and get more done. Report on key metrics and get real-time visibility into work as it happens with roll-up reports, dashboards, and automated workflows built to keep your team connected and informed.
When teams have clarity into the work getting done, there’s no telling how much more they can accomplish in the same amount of time. Try Smartsheet for free, today.