Project Management Techniques: Waterfall

In trying to understand the field of project management a good first step is to understand the main theoretical frameworks behind project management methods.  For the next few posts I will be researching these core paradigms and writing about my findings here.

The first method I am lookingwaterfall at is termed the Waterfall Method.   The idea behind the ‘pure’ version of this method is that each stage of the project is completed before moving on to the next without returning to the a previous step in the project.  Each step is considered 100% complete once the project continues on to the next step.

Sounds pretty good right?  Why not start by completely planning the project, following up with creating all the detailed requirements then document all requirements.  Once this is done, the thinking goes, every aspect of the project and its associated tasks will be so well understood that the rest of the project will be a breeze.  All that’s left to do is move the project through the development stage, verify the results and viola! you have a completed project to deliver to your customers.

The benefits to this are supposed to be safety.  The assumption is that if you have everything planned and accounted for up front then you won’t have to deal with pesky issues like big project changes at costly and inconvenient points in the project.  You should be able to come in on time and on budget.

There are many sites where you can find what I think of as “the legend of the waterfall model”.  The idea is that this model came to be adopted by software development from the manufacturing and construction industries. Both these industries have structured physical environment and any after-changes are almost impossible. During the start of software development industry, there were no formal software development methodologies, therefore this model from the manufacturing and construction industries was adapted for software development.

The Waterfall method is generally considered to have some pretty serious downsides and is widely criticized for being inflexible and unrealistic if the goal is to deliver an end product that customers actually want. A project is a complex undertaking and everyone involved has to learn as they go.

David Parnas, in A Rational Design Process: How and Why to Fake It, writes:

“Many of the details only become known to us as we progress in the implementation. Some of the things that we learn invalidate our design and we must backtrack.”

The reality of a need for some level of change management and adaptability in a project has lead to other, more iterative project management methods, such as Modified Waterfall and Agile.

Have you participated on a project that has utilized the pure Waterfall methodology of project management?  If you have let me know how it went and the type of project it was used for.


4 thoughts on “Project Management Techniques: Waterfall

  1. Nice post Heather! I have worked on some custom software projects where the waterfall method was strictly adhered to. It was usually clean and organized, but one of the problems I ran into was that the customers usually want to see some form of the software before the official release. From there I moved into either modified waterfall or completely agile methods where the client can see progress with each stage of the project.

    Looking forward to your next post!

  2. Pingback: Project Management Techniques: Agile | Project Reno

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s