Model:a pattern or way of doing things that other people can follow ~ its application to project planning and software development.

For example, a business model will lay out methodology that a company can use to create, deliver, and capture value and revenue. The assumption is that if someone follows certain steps, procedures, and processes then the results of the business can be duplicated time and time again.

This is one reason why franchises are so popular. Someone has already gone through the trouble of figuring out all the nuances of how to make a business work and assembled an Operations Manual for others to follow. All things being equal, if these instructions are followed precisely then positive results from that business can almost be guaranteed.

The same applies in principle to different models used for creating software. When it comes to project management and software development there are plenty of models to choose from. For example, there is Scrum, Extreme Programming, Lean, Prince2, PMBOK, and Unified to mention a few. We are going to spend some time focusing on a software planning methodology that has been around for some time now…the waterfall model.

What is the Waterfall Model?

As the name suggests, the waterfall model starts at the top and flows downhill. There are various phases that a project will go through on its way toward completion. The standard phases are:

• Requirements
• Design
• Implementation
• Validation
• Maintenance

Depending upon the organization, there may be variations on each of these names.  For example, implementation may be termed build or validation may be called quality assurance. Yet, the purpose of each phase remains intact regardless of the name each one is called.

Just like a waterfall, the flow of the project through these phases only goes one way. Each phase must be complete prior to moving to the next phase. Once you move to the next phase there is, theoretically, no going back to a previous phase and making changes.

The reality is of course different than the theory and people will go back and make changes after the project has moved from one phase to the next. While this is possible, it does introduce unnecessary complexity and delay into the project since the waterfall method is not designed to work this way.

What are the Standard Waterfall Method Phases for my Project?

The following phases are typical when it comes to using the waterfall method for software planning:

Project Requirements

This is the phase that answers the question “what needs to be built?” This phase is concentrated on discovery, interviews, workshops, requirements gathering sessions, and other techniques for answering this most important question. It’s important to gather as much information up front as to what needs to be built so as to not introduce additional requirements much later in the software planning and development process.

It’s vital to get sign-off from all people that have a stake in the project. This includes clients if it is work that is being done for another company to internal approvals if it is a project for your own company. This document will be referred back to throughout the process to make sure the software is meeting the needs of what it was envisioned to accomplish.

Project Design

Once everyone agrees on what it is that needs to be built, the next question that needs to be answered when it comes to software planning is “how are we going to build this?” This is the part of the software planning process where you bring in the engineers, developers, and other technical people and explain to them what needs to be accomplished. They need to have an accurate and deep understanding in order to determine if this is a project that can be built off existing code or if this will require a fresh start. As with the sign-offs during the Requirements phase, it is equally as important to have approvals at this phase as well. Moving forward without approvals can come back and give the project manager and the team much unnecessary anxiety.

Project Implementation

This is the fun part of the project where people can actually start “slinging code”. Based upon the technical specifications that were created from the design phase, developers and engineers will know exactly what needs to be built and can start on putting the pieces together. The first two phases mentioned above (requirements and design) are typically victims in the software planning process. How so? Most people love to jump right into the implementation part of the Waterfall method. There is usually a desire to jump in head-first much further down the stream than where it actually begins. Resist the temptation to do this in your software planning process. The time you spend on the first two phases will more than make up for itself as your team works through the implementation phase.

Project Verification

Testing can begin now that the code has been built to spec. Again, this is another area that unfortunately has some shortcuts taken from time to time. “Of course it works,” the developer says. “I tested it myself on my own machine and it worked flawlessly.” The problem here is that the software is not going to be running on his machine. It’s going to be on the web and / or running on thousands of machines that are configured differently than his. That’s why it’s so important to do the testing in as close to a real world environment as possible. Plus, the code that this person wrote may work just fine by itself. But, the second it starts interacting with code that others have written it may not work as well. It is during this verification phase that all of the various pieces are assembled and given a thorough testing prior to the software being released into a production environment.

Project Maintenance

The final phase of the waterfall method is some form of maintenance. This phase is many times overlooked during the software planning process based upon the assumption that everything will work just fine and never need any updates or “tweaking”. The ideal situation for maintenance is to turn this function over to a specialized team that can make these bug fixes and patches while the core team is now heads down on their next development project.

The waterfall method has been around for some time now and has worked very effectively in many software development shops. Does it have its share of drawbacks? Sure. There is a considerable amount of paperwork that is necessary in order to keep up with the requirements, design, approval and other aspects of the project. Plus, it may have a tendency to slow things down as a project shouldn’t move forward into the next phase until the prior phase is 100% complete. These are all drawbacks, however, so long as you are aware of them you can work through and set expectations accordingly.

The waterfall method may not be right for every project. But, if your software planning requires a disciplined and thoughtful approach to getting work out the door then it may be just what you need for your next project!

ProjectPlan.com is methodology agnostic! Try ProjectPlan.com FREE for 30 days and implement any methodology you want to use. Whether it’s SCRUM, Waterfall, PMBOK, or a home-made combination of your own, our software supports them all!