What is the Traditional Waterfall Model and Why does it Fail?

Oscar Wilde, the celebrated Irish poet and playwright, wrote: “Success is a science; if you have the conditions, you get the results”. But how can we really gauge success and in this case its opposite; failure? As abstracts, they are both interpreted subjectively by each and every one of us but, in terms of the science of Project Management and the Waterfall Model, we can hopefully draw more objective conclusions.    

A Definition of Waterfall

Without doubt, it’s best to start at the beginning and explain what the much-criticized Traditional Waterfall Model is all about. Regarded as the first linear-sequential approach to product design, its roots can be traced back to the manufacturing and construction industries, its name as a metaphor of the cascading down-flow of water in a waterfall. Used in hardware development, its methodology was subsequently adapted for the development of software. Debates continue as to who actually gave it the name “Waterfall” but it is fairly safe to say that in 1970 Winston Royce, an American computer scientist, was the first to write a detailed article on the subject in terms of software development.

Royce’s Model

The six stages of the Model flow chronologically from 1-6 as follows:

1. SOFTWARE REQUIREMENTS
2. ANALYSIS
3. SYSTEM DESIGN
4. CODING & IMPLEMENTATION
5. TESTING & VERIFICATION
6. OPERATION & MAINTENANCE

Each of these phases is specific as to what should be accomplished:

1. All the requirements of the system and software to be developed in addition to dead-lines and guidelines are incorporated at this stage. This definition and planning are depicted in a product requirements document.
2. To guide the feasibility of production, costing and technical resources, specifications are analyzed to create models and business logic.
3. In order to specify technical design requirements, such as hardware and programming, a system design document is produced. This is also known as software or system architecture.
4. Based upon the results of the previous stages, the system is designed and developed in smaller units before being tested for its functionality. The completion of this Unit Testing occurs when the software is integrated together.
5. Once integrated, the whole system is tested for faults and failures. Systematically, it highlights any issues which need to be resolved before moving on.
6. Once deemed functional and subsequently released, namely the product goes live on the market, other issues may be faced. Hence, this stage corrects, adapts and perfects. Maintenance, sometimes known as patching, provides for on-going changes in response to the customer environment.

As can be seen, the Waterfall Model is based primarily on the concept that there are very distinct phases within a product’s development and as they do not overlap, once completed and signed off cannot be revisited.          

Waterfall in Use

In the same way that Waterfall is used in the construction industry, heavy engineering and military projects, where investment is massive and mistakes very costly, let’s think of Oscar Wilde again and imagine being a theatre producer who’s successfully put on eight of his nine plays and it’s time to produce the final one. A lot of money is going to be invested and stands to be lost but hopefully you have already got the following:

• Clear, fixed and well-documented requirements to authentically produce any of his plays.
• A definitive target audience.
• A complete knowledge of technical needs.
• A cast of well-known and talented actors and adept support crews.
• A short time deadline to produce the play.
• A lot of understanding and experience of the work to be done.

If you can boast all of these, then the Waterfall Model could be appropriate because the different stages can be implemented in a simple and easy-to-understand manner despite it being a big project having relationships with many external factors. Because of the solid early documentation, it allows large teams to move towards a common goal in a departmentalized and controlled way. Milestones are clearly defined within a structured and disciplined organization; “It is late summer now and everything has to have been finished in logical and defined stages so we’re all ready for the opening night on 20th December.” Similarly, any problem found early on (your lead actor has signed a contract to make a film in Hollywood in the winter) is easier and cheaper to correct in the early stages.    

Overall, it’s clear that everyone knows what they are doing, because they’ve done it well before, there are a limited number of external issues which could affect the progress of the project and, more importantly, the audience will love the end result so your show should be successful and make money. The same can apply to the use of the Waterfall Model in other areas of project management but software development is not quite the same.  

The Failings of Waterfall

In software development projects there is not the assumption that you have complete and perfect knowledge before you start. Waterfall uses the theory that what you want at the beginning is what you get at the end so there is little, if any room, for significant changes in direction. Being an inflexible model which does not provide for feedback, it is difficult to highlight new requirements and thus change course. The creation of new software needs to be responsive to changes in technology, any problems encountered along the way, ideas originating from the developers and, last but not least, constantly changing customer needs. If you use Waterfall you end up with pretty much what you had planned at the beginning and that may no longer be relevant.

The Stages

Since Waterfall employs stages, it maintains the belief that each phase must be 100% complete before moving on to the next. This rigidity has an obvious problem; if your project needs unexpected changes or revisions, you must go back to where the requirement has to be altered and start that phase all over again. This will almost certainly incur added costs in terms of time and money. If the problem is not addressed, then it is most likely that the product will end up being sub-standard and unacceptable to the end user.

The End User

Waterfall concentrates very little on the end user of a product. As a methodology, it focuses more on guiding the internal process of development and helping the teams within it. The constantly changing needs of end users are not considered because they are rarely involved. They neither have input nor are updated on the progress of the project so it is quite likely that the end product will be unacceptable to them. This runs the risk of causing the worst case scenario; namely, that if released and then rejected by the consumer, the entire project will have to go back to the very beginning and be completely redone.

Quality Testing

Quality testing does not appear in Waterfall until you are into the second half of the project. Therefore, if you are at an advanced stage when you discover quality problems with the product its flow can be blocked. Imagine the bottom of a real waterfall and how the direct flow of water can be disrupted by a few over-hanging tree trunks. It is also quite likely that, by leaving testing until the latter stages of a project, the teams involved may cut this phase short since they are under pressure to complete before a time deadline.

No Overlapping

Processes within this model do not overlap and, as a result, efficiency is undoubtedly reduced. Therefore, critics argue that it is not satisfactory for complex, high risk and object-orientated projects. However, it is worth noting that modifications to the “pure” Waterfall Model have been created in an attempt to overcome this and other shortfalls; the most relevant being; “Sashimi” (Waterfall with Overlapping Phases.) and “Rapid Development.”

Documentation

In the early days of software development, when much was unexplored and needed to be recorded, it was probably quite acceptable to advocate extensive documentation in order to assist in the future. However, times change and this requirement within the Waterfall Model may now appear as over-kill, especially when viewed against the procedures used within more modern Agile Methodology.

The People

Back in the 1970s, the bosses were the bosses, the workers the workers. Besides being staged in terms of work, Waterfall also implies that project management has a rigid organizational structure originating at the top of a company hierarchy and flowing down to the bottom. Half a century later and things have changed. We now appreciate that in many cases the best ideas and the best insight within a project can evolve from those actually working hands-on. Constant feedback from those people, and then adjusting accordingly, helps us overcome problems, brings greater productivity and increases quality.

Competing Ideas

Although we are talking about why one concept fails, it is still worth mentioning why another can succeed. In the same environment that Waterfall appears inadequate, Agile Methodology has proven results. Its use over the past few decades in project management has been a significant factor in the way that Waterfall is now regarded as a failure. Advances in technology and ever-demanding customers demand an approach that is not so rigidly structured but is based upon flexibility. Staying competitive and relevant in today’s market needs outward, rather than inward, focus. “The customer is king” and Agile acknowledges this.      

Although we have considered how the Waterfall Model fails the needs of computer software development and many other spheres of project design and management in the modern world, particularly if it is compared to the success of the Agile alternative, perhaps in the end we could be a little more lenient towards the concept. Its application, or partial application, where deemed appropriate may be relevant in some contexts. So, in your particular domain and before deciding upon which approach to take, think again about the original quotation from Oscar Wilde and turn it completely on its head; “Failure is negligence; if you don’t have the conditions, you don’t get the results.”…..You do not want failure, you want successful results, but what are your conditions?