There are many development methodologies to choose from, and new managers often struggle when deciding which to use. Waterfall development is popular among new managers because it’s straightforward and it facilitates project management.

Waterfall development makes it easy to keep your project under control. It limits the amount of cross-team interaction that occurs during development, it’s relatively easy to estimate, and it allows for greater ease in project management since plans aren’t constantly being revised.

Waterfall development has a few shortcomings, but if you’ve got a new role to fill, a new team to work with, and a solution that will support this style, it can help you get your feet wet before you move on to more advanced methods.

The basic tiered approach
Waterfall development, also known as the Systems Development Lifecycle Model (SDLC), is an approach to software development that breaks a project into finite phases. Each phase is performed in order, and each depends on the completion of preceding phases.

Under the waterfall development method, each portion of work is evaluated separately and is often performed by different teams. There are various schools of thought about what the actual phases should be, but the progression always relies on heavy up-front planning. Here’s a common breakdown of the waterfall development process:

  1. Evaluate the problem—This is where the concept is born. Identify deficiencies with existing solutions and gather information.
  2. Propose a solution—Present a detailed description of the solution, including pros and cons and the problems the software will address. Finalize timelines, budgets, work breakdown structures, and other supporting documentation. Most importantly, identify and analyze requirements.
  3. Design the architecture—Once the proposal has been accepted, create models of the solution, including workflow and dataflow diagrams, module and functionality layouts, and any other descriptions required by the solution. A vigorous review process usually accompanies this phase.
  4. Develop the code—Use the blueprints created in previous phases to write, debug, and unit-test the code. Next, integrate the code and test portions of the system. Finally, test the entire system. This cycle isn’t complete until all tests have passed.
  5. Deploy and use the system—Roll out the resulting functionality and provide training and documentation to users as needed.
  6. Maintain the solution—Support and upgrade the software when necessary and fix post-production bugs.

Sometimes testing is done in a separate phase that includes debugging, instead of performing the debugging in the development phase. Other variations break out the gathering of requirements into a phase by itself. Wherever the lines are drawn, the above process is performed one time and incorporates the entire solution.

The waterfall development process is especially popular for government projects, where the planning phase extends beyond most corporate deployments. Other uses for this method are projects for well-understood solutions that are familiar to the team or that require little innovation.

There’s a time and place for this development model, however, and not all solutions will be successful using this rigid methodology.

Where waterfall gets its power
The waterfall development methodology is popular with new managers because it facilitates project estimation. Everything is planned up front, making it easy to determine expected costs and timelines.

Another benefit is that all requirements must be validated and the exit criteria used to determine success defined before a single line of code is written. This keeps the project’s goals very clear.

Since the work is performed in stages, only one team at a time manages the project. This simplifies the manager’s job and allows him or her to work closely with each team member. This interaction is great for cutting your teeth with a new staff.

When waterfall falls short
Unfortunately, the waterfall methodology has a number of drawbacks. There are inherent flaws that can hinder success if each phase isn’t completed diligently.

While the waterfall methodology is easy on the manager, it can be grueling for developers. Since testing comes at the end of the development phase, subsystem testing can reveal problems with the code that must be rectified quickly, often at the expense of planned architecture.

Debugging can be complicated since developers are often working on other projects at this stage, and the needed changes can cut into their productivity and work quality. Sometimes workarounds must be slapped into place, compromising the solution’s integrity.

Another potential danger is that you won’t know if the solution is successful until very close to launch, leaving little time and room for correction. Oversights and flawed design work can seriously affect your launch date.

Other criticisms of this model include the fact that there’s no room for feedback anywhere in the process, except at the end of a phase. Also, there’s no room for changes once development has begun. Finally, if system testing shows that capacity or performance isn’t up to snuff, it may be impossible to correct.

You must evaluate your situation carefully before deploying the waterfall methodology. If the customer expects to be involved once work has begun, or you’re dealing with a lot of unknowns, you’re probably better off using an iterative development process.

Why waterfall might work for you
If your project can support an isolated development effort, waterfall development may work in your shop. Be thorough in due diligence, and make sure your teams know what to expect. Correct, attentive use of this traditional method can deliver a successful solution while easing the task of managing your project and team.