Methodology Showdown, Part II: Waterfall

In this installment of the methodology showdown, we’re going to tackle the Waterfall methodology.  Last week we talked about Agile, and where it can shine.  This week we’ll talk about where Waterfall is the right choice, and how you can use it to achieve success.

Waterfall is an older methodology, but it’s hung around for good reason: it’s a really solid path to success.

Waterfall takes its name from the nature of the methodology itself: each stage happens in sequence, flowing into the next phase.  sdlc_waterfall_model

Where it Works

Waterfall works in well-defined projects, or in projects where there are many stakeholders.  Waterfall has a reputation for being documentation-heavy, but that can be a good thing.  Think of the space shuttle: many teams from many companies agreed on the specifications and performance of each part in a giant machine.  The end result was individually crafted parts to create a more complicated whole.

The documentation phase of the process is really two parts: discovery and planning.  Get the stakeholders together and figure out what they want and need in writing.  Then take information, make a plan, and present it in writing.  Both the requirements document and the plan get signed and approved by all the stakeholders.  It’s those two documents that serve as the yardstick for success.

Who it Works For (And Who it Doesn’t)

You’ll see Waterfall used a lot in larger companies and especially government contracts.  It’s partially an issue of company culture, but there also a degree of permanence to the Waterfall methodology that fits the needs of slower-moving business units.

For instance, point-of-sale systems or inventory control software; they need to meet the users’ needs from the start, and then shouldn’t change significantly for years.  Yes, there will be bugs and perhaps new features, but systems like that require permanence and longevity.  That’s where a Waterfall methodology really shines.  This is due in part to the comprehensive documentation the gets assembled at the beginning- everyone gets to see and agree on the end goal.

Waterfall has a weak spot though.  Once the discovery phase is complete, changing the requirements is like trying trying to change the direction of a bullet after it’s been fired from a gun.  That’s why getting the documentation right is so important.  If the stakeholders aren’t all empowered to be engaged, honest, and cooperative, the requirements document will be wrong.  Poor requirements yield poor results.

That being said, find a tech partner with a disciplined and process-driven approach to discovery.  That discipline might make the early phases feel slow, but will yield better results.

A Programmer’s View

The old saying, “Ready, Aim, Fire!” needs to be kept in mind when using Waterfall.  My experience is that successful projects keep those three words in the right order.  As a coder, I really like to dive into the nitty-gritty as soon as I can, and many clients like to see working code as soon as possible.  However, only after “Ready, Aim” should you pull the trigger.

I’m the rare programmer who likes writing documentation.  I like it in part because I like solving problems for people, and the documents are for people who can’t read the code.  That is to say, I like to write for the vast majority of users.  Not every programmer shares this enthusiasm, so find a tech partner who will produce human-readable documents.  Remember, those documents are there to solve problems and improve the results.

Submit a Comment

Your email address will not be published. Required fields are marked *