How to Use nTask for Waterfall Project Management – A Practical Guide for First Timers

We did an extensive analysis of various factors that influence waterfall project management. This helped us to simplify how nTask project management software can be used for solving such issues. Waterfall is a popular SDLC project management model.

However, it is a complicated one at various points. This write-up details how you can use nTask to get by with maximum productivity concerning all your waterfall oriented business models. We have gone an extra mile to illustrate various real-life use cases and examples where waterfall is implemented, and how one can use nTask to further simplify that process – so on and so forth.

What Do You Need to Know about Waterfall Project Management?

The Waterfall methodology is the traditional and the most common methodology used for project management. It follows a sequential, linear process which is why it is often described as a “linear-sequential life cycle model”. As the name suggests, Waterfall focuses on planning the lifecycle of the project by dividing the project into distinctive, separate and exclusive parts: In a Waterfall model, each phase must be completed before the next phase can begin.

The completion of each distinctive step in the Waterfall methodology leads to the next stage of the project just like an actual waterfall. Once a segment of the project is completed no other changes can be made to it and neither can a step be skipped to complete the next one. Each stage is thus dependent upon the completion of the preceding steps or levels. This makes the Waterfall Model most useful for smaller projects with well-defined requirements and fewer uncertainties. Its simplicity and ease of implementation has made it the most popular version of the systems development life cycle (SDLC) for software engineering and IT projects.

When using the Waterfall Model, the emphasis lies on making sure the requirements and design fit the needs of the project before moving on to the later stages of development.

Background of waterfall project management

Source – Codeacademy.com

The origin of the Waterfall Model is often attributed to the manufacturing and construction industries. The Waterfall methodology was ideal for these industries as they follow a highly structured production process: requirements are clearly stated and outlined during the initial stage of the process and the rest of the stages are devised based on the requirements. Just like in the Waterfall methodology, any later changes in any stage of the project management cycle is not only too costly but impossible in some cases.

Dr. Winston W. Royce often but mistakenly called the “father of Waterfall”, is accredited with the first formal description of the process in an article he wrote in 1970. What Dr. Royce was describing was a flawed model for software development as he argued for a model with multiple iterations or runs. He argued that without multiple iterations of the project, with the first being a prototype, the project would be too risky and even invite failure. In his opinion, the prototype iteration was essential for better understanding the requirements and technologies involved in the project and to ensure that the final product delivered what the customer required.

Additional Reading:

Top 7 Features to Look for in Your Free Project Management Tools

While Dr. Royce is attributed to the first known description of the process, the first known presentation is attributed to Herbert D. Benington. On 29 June 1956, Herbert D. Benington gave a presentation about the development of software for SAGE at Symposium on advanced programming methods for digital computers. In his presentation, he described the use of such phases in software engineering. Still the term, “Waterfall” was not used to describe the process.

According to Wikipedia, Bell and Thayer were the first to use the term “Waterfall” in a 1976 paper.

In the 1980s, the Waterfall Model came under intense criticism because of its rigid nature.

Due to the changing needs of the software development industry and the failure of the linearity of the Waterfall Model in providing early feedback, many versions of the Waterfall Model has emerged. These versions are often collectively referred to as Modified Waterfall Models.

The more modern Waterfall Model has feedback loops into the previous phases to allow for modifications. Other versions of the Waterfall model are Peter DeGrace’s “sashimi model” (waterfall with overlapping phases), the V-Model or the Bent Waterfall Model, etc.

The Waterfall Methodology and its Evolution – The Traditional Waterfall Model

Since the 1970s, businesses and projects have employed the Waterfall methodology for project management. Utilizing a simple flowchart that started from point A and followed sequential steps to reach its end was not only easy to understand but to implement also. The stages of the Waterfall methodology were developed by Dr. Royce with the view towards preventing costly revisions in the latter part of the project development cycle. Dr. Royce was attempting to explain how in his experience the Waterfall Model comes attached with risks of failure.

In Royce’s original waterfall model, he outlined these stages to emphasize the importance of these steps for large and complex software development projects. He also wanted to point out that as the steps are planned and executed differently, the best utilization of resources requires that the team must include people who can best perform these steps.

Typical Stages of a Waterfall Model

The various stages of the Waterfall Model can be modified, eliminated or augmented depending upon the project framework and requirements.

The sequential steps in a typical Waterfall model are as follows:

1. Conception: This phase is where the idea for the project germinates. This phase involves a rough assessment of the process e.g. is the project beneficial, what would be the costs involved etc.
2. Initiation: After the conception, the project is initiated by hiring a project team, defining objectives, scope, purpose, and deliverables. This stage is critical as the Waterfall Model emphasizes making sure that the requirements and design fit the needs of the project.
3. Requirement Gathering and Analysis: All possible project requirements are gathered and analyzed by the team to see the project’s feasibility. This might also require that the team understands the client’s business model and analyze the potential risks involved with the project. All of the information created in this phase is then documented in a requirement specification document.
4. Design: In this phase, the requirement specification are studied, evaluated and system design is prepared for the completion of the project. Hardware and software requirements are identified and overall system architecture is defined. The design specifications made in this phase are used in the coding phase.
5. Implementation/Coding: This is the phase where development/coding actually begins as per the design specification. The project manager delegate tasks among team members usually consisting of programmers, interface designers, and other specialists, using tools such as compilers, debuggers, interpreters and media editors. Depending upon the nature of the project and the team size, the team is divided into smaller units.
6. In most cases, the system is first developed in small programs called units and they are integrated into the next phase. As each unit develops, it is tested for its functionality, referred to as Unit Testing. The final output of this step can be one or more product components that are built according to a pre-defined coding standard and debugged, tested and integrated to satisfy the system architecture requirements. No matter the team size, collaboration and coordination are critical to ensure that all the requirements are met.
7. Testing: Once all units developed are integrated, the entire system developed is then tested for any errors. In this phase, compliance with client’s expectations is also verified.
8. Deployment: Upon the completion of all the testing, the product or process is delivered to the customer, released into the market or implemented. During this process, all prevalent industry-specific guidelines, regulations and/or organizational guidelines should strictly adhere. Furthermore, post-implementation verification and testing must be carried out to confirm the success of the final implementation.
9. Maintenance: In the case any issues are identified by the end-user, the development team is required to resolve, change, or modify the product to ensure its effectiveness. The maintenance period is usually for a specified and previously agreed period of time.

Diagram 2: Basic Representation of a Typical Waterfall Model for Software Development

Popularity of the Waterfall PM Model

Why did the Waterfall Model gain such ubiquitous popularity despite Dr. Royce’s attempt in warning people of the pitfalls of the model?

The Waterfall methodology is the most common methodology used for project management. This model was being used in various industries even before the name “waterfall” was given to it. The main reasons for the popularity and widespread use of the Waterfall Model are as follows:

• Easy to understand, use and manage

Most project managers find the structure of the Waterfall Model easy to understand and implement as it follows the lifecycle of a project. Moreover, there is no need to train the team and familiarize them with the Waterfall methodology. The rigidity of the whole process not only makes it simple to implement and control but also reduces the burden of project management.

• Disciplined

The clearly structured approach of the Waterfall Model makes it easy to monitor and as each stage finishes the project manager and client can see visible progress. As a maximum amount of time is spent on the requirement and design phase, the chances of the team missing the deadline are drastically reduced.

• Quality and Detailed Documentation

Documentation is maintained and updated from the initial stages. The rigorous way documents are updated ensures that there is complete understanding between the team and the client as to what will be delivered. This not only makes planning and designing more straightforward but also helps stakeholders if they need to see more detail about a certain phase.

• Minimum Customer Involvement

The Waterfall Model is designed in such a way that once the requirement has been clearly defined and understood, a customer presence is not strictly required. This removes any additional burden on the team and prevents the introduction of any new changes in the later phase of the project, which in turn ensures the project timely completion.

• Departmentalization

Waterfall Model’s flexibility allows for various members of the team to be involved in or continues work on other projects depending upon which phase the project is in. With scheduled deadlines set for each stage of development, the project moves through the development process sequentially freeing up resources.

• Quality Insurance

This model is ideal for projects whose requirements are clearly and strictly defined and where any changes in the requirements later would not be possible. Furthermore, the Waterfall Model is ideal for projects where the quality of the product is given preference over time or cost concerns.

Why Don’t More Projects Use the Waterfall Project Management Model?

Some of the biggest advantages of the Waterfall Model turn into its drawbacks depending upon the nature of the project.

The biggest limitation of the Waterfall methodology for software development projects is that it is not well-suited for long or large-scale projects. Other disadvantages include: (6)

• Little to No Changes or Revisions:

The Waterfall Model’s emphasis on clear and well-defined requirements means that once finalized, any changes in requirements would not only be difficult but also costly. Thus, the Waterfall Model is not suitable for projects with vague requirements. This also means that any change in software and hardware in long-term projects would be challenging to address. This also implies that any unexpected project occurrences cannot be addressed using this method.

• Late Delivery of Product:

As the earlier stages of the model are devoted to understanding the requirements, the software development starts later in the project lifecycle. This means that the stakeholders can’t see the software until later in the project lifecycle.

• Impracticality of Gathering Accurate and Complete Requirements:

Gathering clear, well-defined and complete requirements in the initial phase are not only difficult, for some projects it can be impractical as well. Often customers do not have a clear picture of all the requirements early in the project lifecycle instead they learn and clarify requirements as the project progresses.

Modern Depiction of the Waterfall Model

Despite its various drawbacks, the modern Waterfall Model is amongst the most common software development life cycle (SDLC) models. The modern version of the Waterfall Model contains feedback loops throughout the project lifecycle including post-delivery maintenance.

In this model, Testing is not a separate phase but rather is performed continually throughout the software process. This is given special importance during the maintenance phase to ensure that not only does the software works as required but that any additional requirements are also incorporated into the design.

The Modern Waterfall Model clearly depicts the route to be taken during development and maintenance until the retirement of the software. The Modern Waterfall Model removes many of the issues with the traditional Waterfall Model, however, it does come with issues of its own. For example, the completion of each phase includes complete and quality documentation of that phases and approval by software quality assurance (SQA) group and this must also be done in case of any modifications. The insistence on maintaining complete documentation might result in delays and unnecessary paperwork.

The ACME Super ATM Use-Case Model for Withdrawing Cash

Brief Description:

This use case describes how a Bank Customer uses an ATM to withdraw money from a bank account.

Actors:

The figure below shows all the actors in the ACME Super ATM use-case model.

The actors include customers, bank system, service administrator and security administrator.

Preconditions:

• The bank Customer must possess a bank card.
• The network connection to the Bank System must be active.
• The system must have at least some cash that can be dispensed.
• The cash withdrawal service option must be available.

Basic Flow:

• Insert Card
• Read Card
• Authenticate Customer
• Select Withdrawal
• The system displays the different service options that are currently available on the machine
• Select Amount
• The system prompts for the amount to be withdrawn by displaying the list of standard withdrawal amounts
• Confirm Withdrawal
• Perform Assess Funds on Hand
• Perform Conduct Transaction
• Eject Card
• The Customer takes the bank card from the machine
• Dispense Cash
• The system dispenses the requested amount to the Customer
• The system records a transaction log entry for the withdrawal
• Use Case End

Alternate Flows:

Alternate Flows include the flows for the following scenarios:

• Handle the Withdrawal of a Non-Standard Amount
• Handle Unreadable Bank Card
• Receipt Handling
• Error Handling
• Handle the Bank System Stopping Responding

Exception Flows:

Exception Flows include the flows for the following scenarios:

• Assess Funds on Hand
• Conduct Withdrawal
• Service Shutdown
• Handle Transaction Adjustments

Post Conditions:

• The ATM has returned the card and dispensed the cash to the Customer, and the withdrawal is registered on the Customer’s account.
• The ATM has returned the card to the Customer, and no withdrawal is registered on the Customer’s account.
• The ATM has returned the card, but has not supplied the amount of cash registered as withdrawn from the Customer’s account; the discrepancy is registered on the ATM’s logs.
• The ATM has kept the card, no withdrawal has registered on the Customer’s account, and the Customer has been notified where to contact for more information.

Public Extension Points:

None

Special Requirements

• Reliable Cash Dispensing

In The ACME Super ATM Use-Case Model for Withdrawing Cash, all the requirements are fixed and clearly defined, hence the Waterfall Model is ideal for this example. Once the requirements had been noted very little feedback was required from the customer and the development and design stages could be completed following a liner sequential pattern. The project could be easily managed with the help of project management software like nTask with each stage clearly defined and broken down according to the requirements.

The ACME Super ATM Use-Case Model to Authenticate Customer

Brief Description:

This use case is used to authenticate that the individual using the ATM (the Customer) is authorized to use the inserted bank card and that the account associated with the bank card is active.

Actors:

The actors include customer, bank system, service administrator and security administrator.

Preconditions:

• The bank card has been inserted into the ATM.
• The bank card information has been read successfully.
• A Customer is in dialogue with the including use case.
• The ATM Session ID has been created.

Basic Flow

• Validate Card Information
• The system sends the bank card information to the Bank System
• The system also sends the ATM ID and the ATM session identifier to the Bank System
• The Bank System acknowledges that the bank card information is valid and that the card can be used
• Validate User Identity
• The system prompts the Customer for the PIN
• The Customer enters the PIN
• The system checks that the entered PIN is identical to the PIN read from the bank card
• PIN Validated
• Use Case Ends

Alternate Flows:

Alternate Flows include the flows for the following scenarios:

• Handle No Communications With the Bank System
• Handle No Communications With the Customer’s Bank
• Handle Inactive Card or Account
• Handle Stolen Bank Card
• Handle Invalid Bank Card Information
• Handle Correct PIN Not Entered
• Error Handling
• Handle the Bank System Stopping Responding

Exception Flows:

Exception Flows include the flows for the following scenarios:

• Assess Funds on Hand
• Conduct Withdrawal
• Service Shutdown
• Handle Transaction Adjustments

Post Conditions:

• The Customer has been authorized to use the card.
• The Customer has been barred from using the card, and the card has been confiscated.
• The Customer has been barred from using the card, and the card has not been confiscated.

Public Extension Points

None

Special Requirements

None

In The ACME Super ATM Use-Case Model to Authenticate Customer all the requirements are fixed and clearly defined. The project size is small and can be easily completed with the help of a rigid process. Once the requirements had been noted the development and design stages could be completed in a linear process. The project could be easily managed with the help of project management software like nTask with each stage clearly defined and broken down according to the requirements.

Industry Application – United States Department of Defense

The widely referenced example of the usage of the Waterfall methodology is that of the United States Department of Defense. In 1985, the United States Department of Defense used the Waterfall approach in DOD-STD-2167A, their standards for working with software development contractors. Although they did not specify their methodology as “waterfall”, United States Department of Defense (DOD) still employs the basic principles of the Waterfall Model.

The United States government settled on the Waterfall Model as the model’s advantages perfectly fulfilled its requirements. The federal government insisted on engineering rigor and a superior quality product while maintaining great control over the final product. This along with the inclusion of the six phases-Preliminary Design, Detailed Design, Coding, and Unit Testing, Integration, and Testing- combined with extensive documentation, a strong preference for a single-pass, sequential development method, and heavy oversight makes DOD-STD-2167 the best example of the Waterfall Method.

In 1986, a draft copy of Revision A to MIL-STD 2167 appeared which removed the emphasis on top-down design and proposed the use of rapid prototyping as an alternative to the waterfall. This was because the Waterfall Model was under heavy criticism during the time. Despite the fact that DOD has been distancing themselves from the Waterfall Methodology, the US Federal software development and acquisition still retained a strong hardware-oriented and waterfall approach.

A 2010 report by National Research Council emphasized how many of the terminology used to describe the engineering and manufacturing development phases focus on elements of Waterfall Model like preliminary design reviews and critical design reviews.  This emphasis on the Waterfall Project Management Methodology can be because of an increased emphasis on quality and confidentiality. The separate phases of the Waterfall Model ensure that not every member of the team is involved in the whole project.

In 2000, DOD Instruction (DODI) 5000.2 identified evolutionary acquisition as the preferred approach for acquisition. However, the 5000 series regulations remain dominated by terminology specific to the Waterfall Model. Preliminary design reviews (PDRs) and critical design reviews (CDRs), trademarks of the Waterfall Model, are prescribed for every program.

Is Waterfall Project Management Model for you?

Despite its many drawbacks and restrictions, the Waterfall Model is still used today. However, no one project management method fits the needs of all businesses, not even all projects handled by the same business. So, whether it is the ideal model for your project needs depends upon a variety of factors.

As business varies according to type, size, industry, and many other factors, so do projects. Rather than looking for a methodology that is best, businesses should learn these methodologies, their uses, and applications and decide upon the best methodology for them according to the following variables:

• Organizational goals
• Core values
• Project constraints
• Project stakeholders
• Project size
• Cost of the project
• Ability to take risks
• Need for flexibility

The Waterfall Model is used by businesses whose end product’s requirements are fixed yet time and money are variable. The Waterfall Model allows project managers to start the same project multiple times until the desired outcome is reached. Not many businesses would find the built-in mechanism of the Waterfall methodology to adjust and re-think their approach until they reach the optimum outcome desirable.

Waterfall methodology is ideal for projects with clearly understood, fixed and documented requirements, well-understood technical tools, architectures and infrastructures, access to ample resources with the required expertise, a stable well-defined product, and a short lifecycle. The Waterfall Model’s linear approach does not allow for discovery or any changes to the initial product requirements. Any changes to the requirements would necessitate that the project must return to stage one and the whole process start all over again. This can be a serious problem in many industries, most of whom work on a strict timeline.

The following table is pretty helpful. Take a look.

Table 1: Waterfall Model Requirements

Project management methodology is vital for today’s businesses. By using an appropriate style for your business, you can transform the way your team collaborates, works on tasks, and accomplishes project milestones.

Application in Software Industry

The Waterfall Model is widely used in the software industry when the requirements of the product are clearly defined. According to Royce, the simplest program can be completed in just two steps: Analysis and Coding. However, for programs that are more complex more planning may be required.

The first step for the development of any software would be to create the functional specification. For the Waterfall Model to be effective, it is important that these specifications are well-planned and clearly defined. This would involve talking to business experts and examining the business processes currently being catered for by manual or legacy computer systems to better understand the business process.

When requirements are noted, they must be confirmed by business experts and clients.  When the functional specification is finalized the final copy of the requirements is drafted and locked in.

This is followed by the production of a non-working prototype application along with the user interface. This helps the client, as well as the developers, understand how the product would function. Once this stage is completed, the development of the software commences.

When the application is complete and tested, a beta release is published and provided for testing.  Any bugs found are rapidly repaired.  When no significant bugs remain, the application can go live as release version 1.0.

Application for the Automobile Industry

Industries like construction and manufacturing have been using the Waterfall Model since before Dr. Royce published his paper in 1970. The assembly and manufacturing process of the automobile industry is rigid and requires little adjustments once the plant has been set up. Thus, the major requirements are discussed and settled before the plant is even set up and the design and production process is set up keeping in mind the requirements.

The assembly process itself follows a series of tasks that must be performed just so or the whole process collapses. Only once a stage is completed can the process move forward to the next stage. Any changes to the requirements could require a complete overhaul of the process and require extra time and money.

nTask Vs Waterfall In SDLC

Once you have determined that the Waterfall Model is the model most suited to your needs, you must consider the use of a cloud-based collaborative project management system like nTask. Collaborative tools like nTask are specifically designed to increase your team’s productivity and efficiency no matter what project management methodology you use.

With the help of nTask, you can easily manage projects of varying sizes, assign and delegate tasks, share files and information in real-time and fulfill all your project management needs.

Decided to try the waterfall methodology? Now that you’ve seen the importance of documentation within this method, you know the first step is to find a platform to track all the necessary tasks and share them with your team.

nTask can help from the moment you gather requirements to the testing phase:

• Manage and clearly outline the duration and involved stakeholders of each stage.
• Gather, discuss and document all the requirements in real-time with all the relevant stakeholders. With nTask, the next stage will start only at the completion of the previous stage followed only by complete documentation and approval.
• Create a workflow for your team based on the finalized requirements. nTask allows you to a clear view of the project’s progress and allows you to provide feedback on each and every task in each stage of the Waterfall Model.
• nTask makes it easy to collaborate and communicate with the whole team or just part of the team.
• Making, maintaining and sharing complete documentation for each stage of the Waterfall Model is easy with the help of nTask. You can control who can view documentation so that only relevant information is shared with team members.

Although at this point we hate to cut-off, this is a two-part post. For further updates, bookmark this page and don’t forget to follow up after a week or two. By now, if you have anything to share, you can do so through the comments section below. Alternatively, you can send us an email at fwilson@ntaskmanager.com. We’d love to get back to you.

Also Read:

• The 21 Best Free Productivity Apps of 2024
• The 23 Best To-do List Apps of 2024 for Personal Task Management
• 10 Essential Project Management Skills for Project Managers of 2024
• Getting Things Done (GTD) Method and 14 Best GTD Apps & Tools
• Top 19 Time Tracking Software to Improve Team Productivity
• 27 Best Task Management Software for Startups in 2024
• 36 Best Free Productivity Apps of 2024
• 30 Best To-do List Apps of 2024 for Personal Task Management
• 22 Best Free Project Management Tools for Agile Teams in 2024
• Managing Virtual Teams: Challenges, Tips & Virtual Team Management Tools
• 47 Best Team Work Quotes To Celebrate Collaboration & Motivation