Datasheet

Approaches to Project Management
❘
19
Planning
Each phase in the Waterfall method is predicated on successfully completing the prior phase. Each
phase builds on the work and decisions made in the prior phase, and the team can adjust its plans
accordingly. This implies that decisions made in early phases have an increasingly large impact in
later phases. That being the case, earlier phases focus on solidifying the requirements and design of
the system, with little code or engineering work taking place until later.
A central concept in this method is that problems uncovered earlier in the process are much easier to
correct than those found later. For instance, in the bridge example, it would be very expensive
to move the bridge once constructed, so the engineering team has to be 100% sure of the location
before the fi rst stone is moved. The same concept can also be applied in some software projects. If the
requirements are very stable and clearly understood, then a lengthy design phase, including prototyping
and feedback, followed by a shorter development phase, can deliver a product for a predictable cost.
Documentation
Documentation is the primary communication vehicle between phases of the Waterfall method.
Heavy reliance on documentation allows project phases to start, be staffed by experts, produce a
result (a document), and then wind down in a predictable manner. It also enables a large team to
switch players throughout a project in order to maximize people ’ s time. Finally, it provides a written
record of progress so there is transparency into why, when, and by whom decisions are made.
Requirements gathered from stakeholders are cataloged and assembled into a document that
becomes the defi nition of success. This primary document is called the requirements defi nition,
business requirements document, or something similar. The document essentially becomes the
contract between the business users and the technical implementation team. If, when the system
is deployed, it meets the requirements listed in this document, the system is deemed successful.
Therefore, both teams must fully understand this document.
After the requirements defi nition is reviewed and approved by the business users, a more technical
team translates it into a functional specifi cation (or spec). The functional spec describes what the
system will do. It depicts screens, database tables, fi eld - level validation, and workfl ow. It translates
the business requirements into something that the team can build. The business user must also
review and approve this document, since it precisely describes the system that will be built. The
functional spec also typically includes a traceability matrix that references the requirements
document. This matrix ensures that the functional specifi cation addresses all business requirements.
Following the functional spec is a detailed design document, the fi rst document that addresses the
technology. Its purpose is to map the functional spec into a blueprint of a system. After system
architects approve the detailed design, construction begins.
Don ’ t underestimate the language barrier between customers and engineers.
Customers may have diffi culty articulating what they want, and engineers may not
fully understand what they need to build. If these people are speaking different
languages, each will be misunderstood.
CH001.indd 19CH001.indd 19 3/23/11 2:47:03 PM3/23/11 2:47:03 PM