I’m sure you’ve all heard of the waterfall development methodology—you know, analysis, design, coding, testing, implementation. Sometimes, we think of the waterfall process as we would an old uncle: it’s comfortable and familiar, and we don’t want to talk about it much.
Even though there are newer and sexier development processes available, most projects are still probably using some version of this approach to deliver their projects. And why not? If you had never heard of the waterfall method and were asked to solve a complex business problem, you would probably come up with something similar. Your instinct would be to understand the nature of the problem and what was needed in the solution (analysis), think about how you would build the solution (design), build and test the solution, and then implement it.
For most projects, that’s about it. However, as projects get larger, the tasks associated with each phase necessarily become more complex. The purpose of this article is to look more closely at the different phases of the waterfall methodology and show how it is used for larger projects. Since you’ll be exposed to this methodology at some point in your career (I’d be surprised if you haven’t been already), it’s important that you see the robustness of this approach and understand what the methodology really entails.
In general, the major phases are as follows:
Let’s look at each phase individually.
Some people consider the planning phase a part of the project management process (and I agree with them). I’ve included it here for completeness. Assuming that a project has begun through some type of prioritization and approval process, the first thing that happens is planning. At this point, the project manager is assigned, the business objectives are defined, scope is determined, risks and assumptions are identified, and so on. An estimate for project effort, cost, and duration is prepared, and an initial project workplan is created. The key deliverables from this phase are a Project Definition that describes and defines the project, Project Management Procedures that describe the processes for managing issues, scope, risk, communication, quality, etc., and a workplan that describes the activities needed to complete the project.
During the analysis stage, the business problem starts to be defined in greater detail. There are three areas of focus during this stage.
The first and most obvious element of the analysis stage is the collection of business requirements. Through a combination of techniques such as one-on-one discussions, group sessions, questionnaires, and surveys, the project team determines what the business needs are. These requirements should be prioritized in terms of things that must be present vs. those things that are nice to have. In addition to a formal business requirements document, you may also create a conceptual systems design that starts to bridge the analysis and design phases by describing business processes and transactions and high-level screens and reports.
Reuse, buy, or build?
The second fundamental focus in the analysis phase is the reuse, buy, or build decision. The first thing you look for is whether there is any solution in your company that will solve this business problem. For instance, you may discover that another division in your company has a solution that meets 90 percent of a business need. If you cannot reuse an internal solution, it may be advantageous to see if one exists in the marketplace. Depending on the circumstances, a packaged solution may end up saving your company money and deployment time. The third option (usually the default) is to build the solution internally.
The third purpose of the analysis phase is to create the strategy documents that will drive future decision-making on the project. These documents include a Testing Strategy, Training Strategy, Data Conversion Strategy, and Deployment Strategy. One of the keys to a successful project is to invest in planning and to set as much of the overall approach as possible early in the project. As an example, the Testing Strategy document describes which organizations need to be trained, what training will be provided, who is responsible for the training development and execution, and so on. You may decide to build the training material internally or look for a training company that could develop the content. Whatever you do, you need to decide this early rather than toward the end when the actual training takes place. Documenting the strategies allows the project manager to gain agreement on these overall approaches with the customer and the project team.
The design phase is where the business requirements start to be translated into an IT solution. Fundamental decisions are made in terms of the underlying technology. For instance, will this be a Web application or client/server? Will the development require COBOL, Visual Basic, or Java? Will we use SQL Server, Oracle, or DB2? The technology utilized will be based on the needs of the project and the current technology architecture used by your company. Online processes are translated into screens and workflow definitions. Batch processes are defined. Online screen and report layouts are built. Basically, the entire solution is built on paper (or using design tools) in a deliverable such as a Technical System Design Report. When you complete this phase, the solution can be turned over to the programmers to start implementing the solution in code.
The other thing that happens at this point is that the high-level strategy documents prepared earlier are fleshed out into more detailed planning documents. For instance, the Training Strategy is used as input to create a Training Plan. The Training Plan describes in detail what classes will be built, who will build them, who will teach them, who will be taught, where the training will be held, what the outline of the classes is, and so forth. In essence, just as the solution is designed, the training is also being designed in detail. Likewise, a Testing Plan, Data Conversion Plan, and Implementation Plan are created to guide the detailed activities necessary for construction.
The construction phase is the meat of the development process for many developers. (It is also the start of the development process for many unsuccessful projects.) Now the solution starts to be implemented in code. Each developer will be unit testing as the application is being developed (let’s assume that we aren’t using dual-programmer, Extreme Programming techniques yet). After unit testing, the testing process is guided by the Testing Plan, which describes integration testing, system testing, and user acceptance testing. Likewise, the training content is built according to the Training Plan, and the file conversion (if appropriate) is based on the Data Conversion Plan.
Notice, however, that if the prior phases were done correctly, there are no fundamental decisions remaining during the construction phase. This phase represents the building and testing of the solution based on all the prior analysis, design, strategies, and plans.
At this point, the fully tested solution is ready to be implemented. This could be as easy as saying that you are now live. Or it could be as complicated as integrating a complex series of related applications across multiple locations. Implementation could itself be huge. However, if you created an Implementation Strategy and Implementation Plan up front, this now becomes a matter of execution. Implementation may still be complex, but at least you don’t have to figure out everything from scratch. Depending on the timing of your project, you may also be training at this point, but again, it’s all in line with your training plan.
You see, the waterfall methodology can be quite complex and rich. There may be times when other methodologies might be more effective and efficient, but I don’t believe there are any projects that couldn’t be accomplished with this approach. The thing to remember is that you want to push as much of the planning forward in the project as possible. Start thinking about the end of the project at the beginning with the strategy documents. Translate the strategy documents into detailed plans during the design phase. Then, “simply” execute during the construction and implementation phases.
One down, two to go
Now that we’ve explored the mechanics of the waterfall methodology, we’ve laid the groundwork for two follow-up articles. Next time, we’ll take a detailed look at the Rapid Application Development (RAD) process. Then, we’ll wind up the series with an article that compares and contrasts the waterfall methodology with RAD and discusses when you might use one process rather than the other.