Introduction to Waterfall Project Management

Today, most IT teams are looking at adopting Agile Project Management systems. But they end up adopting Agile Project Management systems to their projects. This means combining traditional project management systems (Waterfall Project Management Systems) connected with the Principles of Agile Management, as detailed in the original Agile Manifesto.

As more projects worldwide incorporate Agile Project Management practices, does that mean the end of waterfall project management? Will all IT projects end up being Agile Project Management?

To understand the different models, including Agile, and to use the one best suited to your situation, it is important first to understand what the traditional project management system, the Waterfall Project Management Model, is all about.

The Waterfall project management model, so named because of the nature of the workflow process, is characterized by the following:

1. The end product is first visualized in great detail.

2. Then, the stages of the workflow are implemented in sequence:

Requirements and analysis
Design
Implementation
Testing
Installation
Maintenance

The project plan should be foolproof because once a stage in the sequence is completed, developers can only revisit the same by starting the planning over again. There is little scope for changes or errors, and the project plan must be diligently followed.

Origin of Waterfall Project Management Model

In the early stages of the IT industry, there was no specific model for software development.

So, the industry adopted the sequential workflow model used in the manufacturing and construction industries. These industries had well-defined work stages and developed a model that satisfied their need for tight cost control. So the hardware industry model was applied to the software industry.

Winston W Royce presented this model in 1970 but did not use the term “Waterfall Project Management”. He explained the model as a flawed one. The pictorial representation of the model looked like a cascading waterfall. Thomas E. Bell and T.A. Thayer later used “waterfall” in their 1976 paper, “Software Requirements: Are They a Problem?” The word came to stay.

There are several variants of this model. Below are the six phases commonly used in the Waterfall project management model. However, depending on the project, two stages may be combined.

Let’s consider the example of building a school as an example to understand the waterfall project management model better.

1. Requirements and analysis phase

First, we have to know exactly what we are designing.

For this, we might want to:

Conduct detailed discussions with the customer.
Try to visualize the product with its minutest details clearly.
Analyze which hardware and software components are required.
List out the details which include: the problem that the product should solve, the customer constraints, the level of performance, and the compatibility with already existing systems.
Conduct case studies of a similar product.
Consider the requirements of each stakeholder.
List out the specifications in the Product Requirements Document, which forms the input for the next step.

In our example of building a school, in this step, we list the number of classrooms, the material to be used for the building, the people required, and the existing infrastructure. Also, we would note down what the school management requires (office room, staff room) and what the students need (better toilets, playgrounds).

2. Design

In the design stage, all that has been visualized in the first stage is made into a blueprint.

In IT projects, this consists of defining:

The hardware that will be used.
The software platform to be used, including local or cloud deployment.
The software architecture, including the different components and modules to be created.
Inputs required for the project to work successfully.
Outputs that can be expected (ideally, this will sync with the requirements detailed in the earlier stage).

There are two types of design that come into play in a software project.

Logical design: This includes the basic data and processes that will be included in the project. It details the Design of forms and reports, the Design of the interface, and the database. For example, for a train ticketing website, this Design will determine how the entire process will work: the screen on which the traveler inputs his details, how that data will flow into the database, and what type of database will store these details.
Physical design: This is concerned with the physical database design, the programs and processes, and the distributed systems. This is done after the Logical Design and will include “how” the project will be done: the hardware, the platform on which it will be developed, the various databases, screens, and forms that will be used, etc.

3. Implementation

This is where the actual development of the software/system takes place.
The input for this stage is the design specifications provided by the previous step.
The team builds one or more product components to specifications, debugs them, tests them, and integrates them to satisfy the system architecture, resulting in an output.
The development team of programmers, interface designers, and other specialists usually handles this stage. The tools used are compilers, debuggers, interpreters, and media editors.
This stage usually takes the maximum time, and it is important to keep track of the processes and design diligently. Changes to the Design at this stage are difficult in Waterfall Project Management.
For a large project involving several teams, version control is recommended to track changes to the code tree and revert to previous snapshots for error handling.
The team constructs the building using labor and materials at this stage in our example.

4. Testing

Testing can be done for the product as a whole or individual component. “Test cases” can be verified to see if the product can deliver as promised. There can be testing of modules, system testing of the integrated product, and acceptance testing. Acceptance testing involves testing the product for loopholes by the end-user or customer. The team notes down defects for the implementation team to correct. Once the corrections are made, they prepare formal product documentation.

In the example of the school, an audit team likely tests the infrastructure, and sometimes teachers are invited to use the premises and provide feedback.

5. Installation

Once the product testing is complete in all aspects, the team can release the product into the market or install it at the customer’s premises. At this stage, the team also hands over the complete product documentation. In the case of our school, a formal inauguration (preferably by a notable person) takes place, and the school begins its operations!

6. Maintenance

In this stage, the IT team fixes any issues that may arise once the customer starts using the product or when there is a product enhancement. Good documentation is the backbone of maintenance. Problems are rectified by modifying codes, called “patches”.

If the project requires significant changes, the development team may receive it as a new project.

In our example, the school needs regular maintenance, mostly infrastructural, for example, faulty electrical wiring or leaking bathrooms. It is necessary to address these problems from time to time.

As you can see, the Waterfall Development Project Management stages are distinct. While there is usually constant interaction with the client, it is primarily to discuss the progress of the project, not the Design or requirements. However, the waterfall project management model has adequately served the IT industry for many years, and for most projects, the stages still hold good while not as rigid.

The Waterfall project management model highly suits several projects.

What Kind of Project is it Suited to?

Product definition: The team must clearly define the result (product) at the beginning. Projects in which the product owner needs to be more sure about the desired product’s exact specifications may do well to follow Agile Management practices.
Documentation: The project should be one that can be documented. Documentation is an important requirement of the Waterfall project management Model. The product requirements, Design, and source code should be established in all stages. If the original team members quit, this forms the guide for project continuity.
Time and resources: There must be no immediate urgency to release the product. At the beginning of the project, the team sets the timelines, which they must adhere to. Also, ample resources must be available regarding workforce and technology.
Risk and uncertainty: Waterfall Project Management Tools must work better in an environment of risk and uncertainty. For example, The Mobile app is a product that needs more certainty regarding customer acceptance and competition with similar apps.
Clearly defined stages: The system stages should be well defined as they have to be completed in sequence, and there can be no overlap. When a new version of existing software is being created outside of the IT domain, the Waterfall project management Model has been successfully used in huge projects such as:

- - Airplane building
  - Infrastructure projects such as bridges
  - Defense equipment manufacturing
  - Health care systems in hospitals

Waterfall Project Management particularly suits tasks that involve external hardware in IT projects, where changing the specifications midway can lead to losses of millions of dollars. When inadequacies in Waterfall Project Management became apparent in the software industry, there was much thought about how IT teams could deliver maximum value to clients while ensuring flexibility in the workflow process. And thus, the Agile Project Management System, which most software companies are now adopting, was born.

Waterfall Project Management vs Agile Systems

The Agile Project Management system is a flexible model that became popular in the 1990s. It involves breaking up the project into “mini-projects” called sprints and working independently. This model enables the developers to incorporate required changes faster, and it is very effective where the customer environment is variable.

Positives of waterfall project management steps are:

Knowing the end product makes the planning and design unambiguous.
Potential issues in the project can be ironed out during the design phase itself before any code has been written.
Since the stages are well-defined, measuring the progress of work is easy.
The team’s stability is there since the team remains until the end of the project. In the case of Agile, the team changes constantly, and this requires a certain amount of adjustment.
Documentation is extensive, making it easier for teams to manage if a member leaves.
Developers find this model easier to work with as it is easy to understand.
After the requirements phase, the end customer only needs to actively participate in the testing phase because all requirements have been discussed in detail, leaving no ambiguity.
The product can develop the whole product instead of creating it in parts.
The Waterfall project management model is superior at handling contract and client management concerns.

Positives of agile project management are:

The customer can interact with the project team throughout the cycle and occasionally make changes to the product to suit the changing environment.
If the product has to be released very soon due to market circumstances, the Agile Project Management team can remove a basic version that can have advanced versions later.
The system is quite transparent from the customer’s point of view, and he has a fair idea of the stage in which his product is.
Since the client prioritizes features, the team knows it focuses on the features offering the most business value.
The process has its momentum.
Teams are fluid and flexible, enabling ideation from every member.
Documentation is minimal, so time is freed up from those tasks.

After many years of both models existing side-by-side, it is apparent that:

The Waterfall project management Model is effective for Project management, where there are minimal changes once the project is done.

Agile Project Management is more suited to Product Management, where it is important to adapt to changes.

Regardless, the Waterfall project management system remains an important component of most IT projects. One cannot say that a particular project strictly follows Agile Management Practices. It is usually that Agile principles are “incorporated” into IT projects. Some Agile Project Management has Project Managers, whereas precisely an Agile model has only Scrum Masters. Some call this hybrid combination of Agile and Waterfall Project Management models “Agifall” or “Agency Agile” projects.

The popularity of the Waterfall project management system is also because Waterfall Project Management methods better handle contract and client management issues. While more and more projects come under the Agile Project Management fold and more companies are seeing the benefits of a flexible management model, the popularity of the Waterfall project management Model is no doubt waning.

However, it is challenging to envision a future for IT projects that are completely Agile shortly. And Waterfall Project Management, which helped the software industry through its infancy, will live on in a few project management components, at least for a few more years.

Quiz Result
Total Questions	Correct Answers	Wrong Answers	Percentage