Waterfall Project Management

Waterfall Project Management – Today, most IT teams are looking at adopting Agile Project Management systems. But what they end up doing is adopting  Agile Project Management systems to their projects. This means combining traditional project management systems (called Waterfall Project Management Systems), combined 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 to first understand the traditional project management system, called 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:

• The end product is first visualized in great detail.
• Then the stages of the workflow are implemented in sequence:

1. Requirements and analysis
2. Design
3. Implementation
4. Testing
5. Installation
6. Maintenance

• The project plan should be foolproof because once a stage in the sequence is completed, developers cannot revisit the same without 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 first presented this model in 1970 but he did not use the term “Waterfall Project Management”. In fact, he presented 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 the term “waterfall” in their 1976 paper, “Software Requirements: Are They Really a Problem?” and the term came to stay.

There are several variants of this model. The commonly used six distinct phases in the Waterfall project management Model are explained below. 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
• Analyse 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 out the number of classrooms, the material to be used for building, people required, the already existing infrastructure. Also, we would note down what the school management requires (office room, staff room), and what the students require  (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
• Physical design

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 design. 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 and 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 stage.
• The output is one or more of the product components built to specifications, debugged, tested and integrated to satisfy the system architecture.
• This stage is usually taken care of by the development team consisting of programmers, interface designers and other specialists. 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.
• In our example, the building’s actual construction using labor and materials is done at this stage.

4. Testing:

Testing can be done for the product as a whole or for individual components. “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. Defects are noted down for the implementation team to correct. Once the corrections are made, a formal product documentation is prepared.

In the example, the school’s infrastructure is tested, likely by an audit team. In some cases, teachers are invited to come in and use the premises to provide feedback.

5. Installation:

Once the product’s testing is completed in all aspects, the product can be released into the market or installed at the customer’s premises. At this stage, the complete product documentation is also handed over.

In the case of our school, it is formally inaugurated (preferably by a big shot!) and the school commences operations!

6. Maintenance:

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

If major changes are required, the project may go back to the development team as a new project.

In our example, the school needs regular maintenance, mostly infrastructural, for example, faulty electrical wiring or leaking bathrooms. These problems need to be addressed from time to time.

As you can see by now, the stages in Waterfall Development Project Management 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 had adequately served the IT industry for many years, and for most projects, the stages still hold good while not as rigid.

There are, however, several projects for which the Waterfall project management Model is highly suited.

What kind of project is Waterfall Project Management suited to?

Product definition:

First, the result (product) must be capable of being well defined at the beginning itself. Projects in which the product owner is not very 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 clearly documented in all the stages. If the original members of the team quit, this forms the guide for project continuity.

Time and resources:

There must be no immediate urgency to release the product. The timelines are set at the beginning of the project and the team must adhere to them. Also, there must be ample resources available in terms of manpower and technology.

Risk and uncertainty:

Waterfall Project Management Tools does not work well in an environment of risk and uncertainty. For example, The Mobile app is a type of product that faces constant uncertainty in terms of customer acceptance and competition of 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

In IT projects, Waterfall Project Management is especially suited to those projects in which external hardware is required. The specifications of this cannot be changed midway, as this would result in a loss of millions of dollars.

When inadequacies in the Waterfall Project Management became apparent in the software industry, there was a great deal of thought about how IT teams can deliver maximum value to clients while ensuring flexibility in the workflow process.

And thus, the Agile Project Management System, which is now being adopted by most software companies, 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 on each of them. This kind of model enables the developers to incorporate required changes faster, and it is very effective where the customer environment is variable.

The positives of Waterfall Project Management steps are :

• Since the end product is known in its entirety, the planning and design are unambiguous.
• Potential issues that could arise in the project can be ironed out during the design phase itself; before any code has been written.
• Measuring the progress of work is easy since the stages are well defined.
• The stability of the team 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’s active participation is needed only in the testing phase. This is because all the requirements have been discussed threadbare, leaving no ambiguity.
• The product can be developed as a whole, instead of developing it in parts.
• Contract and client management issues are better handled under the Waterfall project management Model.

 The positives of Agile Project Management are :

• The customer can interact with the project team throughout the cycle and make changes to the product from time to time to suit the changing environment.
• If the product has to be released very soon due to market circumstances, the Agile Project Management team can release 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 provides the priority of features, the team knows that it focuses on the features offering the most business value.
• The process has its own momentum.
• Teams are fluid and flexible, enabling ideation from every member.
• Documentation is minimal, and 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 once the project is done, there are minimal changes.

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

Regardless, the Waterfall project management system remains an important component of most IT projects. One cannot say for sure 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 strictly an Agile model has only Scrum Masters. This is a hybrid combination of Agile and Waterfall Project Management models that some call “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 difficult to envision a future for IT projects that are completely Agile in the near future. 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 to come.

First Image source: picjumbo.com

Related Articles

1. Waterfall Project Management
2. Group Discussion Tips for Interview
3. Project Management Myths
4. Passion Project at Work