Waterfall methodology in IT Projects: Does it still make sense?

With the world permanently changing, countries are always evolving and so are their economies and companies. Especially in the IT sector, changes occur so fast that sometimes it can be challenging to keep up with everything that is new – a revolutionary methodology, a new developed technology, a software that was recently brought to the market.

In that way, does it still make sense to work with the Waterfall methodology in IT Projects or is it now in disuse? What other alternatives are available in the market? Let me take you for an overview on it.

The history behind it.

Firstly introduced in 1970 by Dr. Winston W. Royce, this methodology consists in a sequential approach of a software development process life cycle (SDLC) in software engineering and product development, in which a logical progression of steps is emphasized. As so, a new phase can only start when the immediate previous one is complete.

Going deeper in each methodology phase:

1. Requirements (Analysis): corresponds to the basis of future developments and consists in the process of gathering and specifying the software system requirements. Here, client and stakeholders are involved.
2. (System) Design: it includes the decision of the programming language that is going to be used and other high level technical details that should be planned.
3. Development: after the planning and designing stages are finished, it’s time to build the software. It corresponds to the translation of the requirements to code writing.
4. (System) Testing: here, test scripts are prepared and tested by software users or by a tester. As so, team’s main objective is to verify and guarantee that what was developed corresponds to the initial needs (requirements). Bugs and issues that were found must be reported and afterwards corrected and implemented by the software team, leading to a new period of tests.
5. Deployment: it is the moment for the application/system to be deployed into the respective live environment. It is the so-called “go live moment”. The final product is delivered to the client so it can be checked if it is aligned with the initial requirements.
6. Maintenance: once everything has been tested and successfully integrated, the client may request further changes to the system by delivering a change request to the software team. During this phase, the application is live and being used while the team performs any necessary changes.

The not so linear waterfall approach.

The Waterfall methodology is strictly defined and planned, but does it always work? Is it suitable to every company environment or to any activity sector? When is it appropriate to use?

Here are some scenarios in which it would be beneficial to use it:

• When client requirements do not change much;
• If the application to build is not vast, complex or does not have huge visibility or utility in the company;
• When requirements are specified and clear from the beginning, and do not lead to misunderstandings between stakeholders;
• If the project itself is short or has a specific time framework, meaning it is not continuous in time;
• If the development environment is stable;
• If resources are adequately trained and available;
• And finally, the necessary tools and techniques used are stable, and not dynamic.

So why did the Waterfall methodology become unmodern and less used? When it comes to developing new software, finding the right methodology is gold. Although lately many companies have been applying new ways of work, according to a report from the Project Management Institute from 2017, 51% of the organizations remain using the Waterfall methodology.

However, there are some downsides that make this methodology obsolete:

1. No space for creativity or to introduce changes during the process: by defining all the requirements in the first phase, it leads to the impossibility of introducing new requirements in the design or development phases, for example. This situation will most probably lead to the creation of a change request in the maintenance phase, whereas it could be included from the beginning of the project.
2. It might be more costly that initially projected: unforeseen changes will definitely contribute to a higher project cost. Although stakeholders can be very confident with the initial requirements, maybe their needs will change during the development process. Introducing changes in a product that is already built will lead to rework, meaning more time and team members involved in gathering the requirements once again, and to go through every phase of the methodology. Situations like this will certainly lead to more costs associated with the project.
3. Requirements can easily be misunderstood different people have different interpretations of the exact same requirements. By having one team to define and describe requirements and a different one to develop and implement them, it might lead to misinterpretation.
4. Major effort in documentation, less in product building: Following the Waterfall methodology, all the requirements must be entirely documented and approved by key stakeholders before the start of any development. Therefore, the hard work is concentrated in the initial phase, which can be either beneficial or detrimental to the project’s success.

So, what other alternatives do companies have to the Waterfall Methodology?

The collaborative agile methodology.

Agile is a framework that was officially launched as a methodology by a group of developers in 2001, when the Agile Manifesto was published.

Agile is an iterative approach to project management and software development that helps teams to deliver value to their customers faster, since it breaks up projects into several phases, continuously involving stakeholders and encouraging continuous improvement at every stage.

As an alternative of gambling everything on a huge launch, an Agile team delivers work in small, but consumable increments. Requirements, plans, and results are evaluated continuously so that teams have a natural mechanism for responding to change quickly.

So, what are the phases of the Agile life cycle?

1. Concept: the Product Owner (PO) will determine the scope of projects. In case there are several projects, a prioritization will be made. The PO is responsible for discussing the most important requirements with the client in order to produce and prepare documentation explaining key features and proposed results. Most of the times the requirement list is not long, since agile allows and promotes adding requirements during other stages. The PO is also responsible for determining project’s cost and time, and based on that the decision, to start the project.
2. Inception: the moment that the PO selects the team to work with. They can then start the design process, create a mock-up of the user interface and build the project architecture. In this phase project stakeholders are involved in order to help to determine the product functionality.
3. Iteration: also known as the construction phase, it usually corresponds to the longest phase, as most of the work is done here. The developers will work together with the rest of the team to combine all product requirements and customer feedback, turning the design into code. The objective is to build the basic functionality of the product by the end of the first sprint.
4. Release: in this phase, the quality assurance team needs to execute some tests to ensure that the software is fully functional. These Agile team members will test the system to ensure the code is clean and if potential bugs or defects are detected, developers will resolve them. Training to users is provided. Then finally, the product can then be released into production.
5. Maintenance: here the software will be fully deployed and made available to clients. During this phase, the software development team will provide support to keep the system running effortlessly and resolve any new bugs.
6. Retirement: this phase only occurs when either the developed software is being replaced with a new one, or the system itself has become obsolete or incompatible with the organization over time.

The benefits of working with Agile can be measured, making this methodology one of the most effective and interactive ones used in software development. I can mention a few reasons why:

• It empowers all the stakeholders that are involved in product development;
• Builds accountability and reveals team’s responsibility by encouraging the diversity of ideas;
• Promotes continuous improvement;
• Allows incremental and evolutionary changes rather than revolutionary;
• Identifies features that do not or will not work in the future by being tested and rejected in an early phase. This is only possible because of the tight feedback loops that provide benefits in Agile that are not as evident in Waterfall.

The differences: agile or waterfall approach?

• Customer collaboration over contract negotiation;
• Individuals and interaction over processes and tools;
• Responding to change over following a strict plan;
• Working solutions over comprehensive documentation.

In conclusion, there is not a better or worse way of working in project management in terms of the methodology to use. The one to adopt will depend on multiple factors such as cost, context, organizational maturity, functional and technical teams. Anyway, from my personal point of view, I would argue that the Waterfall methodology does not fit with most of the technological industries and its companies needs nowadays, since the economic and social environment changes every second and this methodology does not have the agility to keep up.

Cláudia Mota Silva
Polarising’s Business Analyst