The Product Pipe

If you work in IT Program Management, undoubtedly you’ve been involved in the countless process framework debates.   With businesses looking for closer alignment of IT projects with broader enterprise goals and strategies, most are now emphasizing agile project management.

And as consultants banter with PMOs as to the ideal process framework, no doubt the terms critical path, Scrum, PMBOK, LEAN Six Sigma, SAFe and other methods have been discussed around the water cooler.

And among these project management terms, you’ve also heard that Waterfall – one of the most widely used framework –  is going to die.

(Humm…)   I think it’s time for some background.

What is Waterfall?

Simply put, “Waterfall” is the sequential alignment of activities in the most expedient order given available resources and a presumed timeline.  Waterfall is based on completing a project in discrete phases.  No phase begins until the prior dependent phase is complete, and the only way to revisit a phase is to start over at phase one. It’s a clear step-by-step process.

If waterfall sounds strict, that’s because the framework’s history has its roots in industries like manufacturing and construction.  In those industries, project phases must happen sequentially, because, well… there’s no good way to un-pour a concrete foundation.  Right?

As you can imagine, precise planning is key whenever using waterfall.  A project’s requirements must be clear upfront, and everyone involved must be well aware of ALL requirements.

Waterfall phases…

The specific waterfall phases may vary, but they generally include:

1. Requirement gathering and documentation – Gathering a comprehensive set of requirements.
2. System design – A system topology that outlines the specifics – such as programming languages, hardware and business functionality.
3. Development – This is where coders create the desired business functionality as well as the supporting infrastructure.
4. Testing – Testers methodically use the system to determine if the functionality meets the specifications defined in the requirements.
5. Deployment – This is where the team submits the system for production release.
6. Maintenance – Once delivered to production, the team may need to create patches and other releases to enhance the application.

And with Waterfall’s focus with upfront planning and documentation, it has three major benefits that cannot be ignored:

• Training is simple – Thorough requirements phase of waterfall means that documentation is available and complete and therefore adding team members is easier.
• Shows progress – Since waterfall requires documenting all activities in the best sequence of completion, the project plan naturally illustrates progress and eliminates much of the guesswork in determining the timeline.
• Is easy to manage – These benefits, combined with the sequential system, means you’ll know where the project is at any given time and if the project is on track.

And these benefits are why the Waterfall development framework has been popular for so long.

Waterfall for software development

For software development, Waterfall can be problematic if the requirements aren’t clear and static before the system design phase begins. Unfortunately, users rarely have the complete details of what they want.

Late-stage revision can be a serious undertaking.  In fact, strict adherents to the waterfall system would argue that a need for revision means the product requirements weren’t accurate, and therefore the project must return to stage one. This can be a serious problem in many industries, particularly the ever-changing world of software.

With software product development, it’s been shown that an agile approach is most often the best fit for a project if the requirements could change or that revision will be necessary.

Realistically, most software development is best done with one of the iterative frameworks that embraces changing requirements and features.

When should we use Waterfall?

I ran a Big Data program a few years back at a enterprise software / hardware manufacturer.   This program’s mission was to create a business data lake, recast the business features with newer technology and to decommission a traditional structured data warehouse.

One of the six streams of work in this program was to construct a converged hardware platform… which, I might add, is similar to constructing a building, meaning that there were specific activities that needed to occur in a specific order.   And since we knew what these activities were and that they were unlikely to change.   So the hardware infrastructure project stream was run as waterfall.

However, the software work streams (e.g., creating an ingestion engine or reporting applications) were run using Agile to get the benefits of direct, daily business engagement and to be able to experiment as we were developing an emerging technology with requirements that were not set in stone.

The waterfall development methodology is best for projects that are well defined… from the beginning. And whenever you are certain that the project requirements are static, then waterfall project management provides a straightforward way to push a project along a clearly defined path. It’s simple to manage and easy to track.

And so waterfall will never die.  Nor should it.

Kevin Griggs is a technology program manager who helps organizations establish program management offices and manages complex programs across a variety of industry verticals.   Kevin can be reached at kevin@kevingriggs.net.