4 Reasons Why Waterfall isn’t a Fit for your Team

By Joel Roberts

Even though the Agile method is now being increasingly adopted by organizations worldwide, especially for software development, too many organizations still cling to Waterfall. The existing processes are probably influencing the decision of what methodology is used.

Your organization’s current processes are likely to determine the way you run your project, regardless of its nature. But, this shouldn’t be the case. Project managers are more than able to assist their organizations and suggest effective ways of implementing projects while reducing risks at the same time.

For this, you need to have a deeper understanding of how each project management methodology may impact the project and its success. Choosing the right methodology can be key to successful completion of a project. So, if your organization still uses the waterfall methodology, read on and see for yourself why this needs to change.

Waterfall Method and its flaws

As you know, the Waterfall method is a sequential approach, separating a project into different phases, where one phase has to be completed before starting the next one.

So here are the 4 crucial flaws caused by this:

#1 No Flexibility

The Waterfall method in its core means following a predetermined set of steps, as the methodology, in its traditional form, leaves almost no room for unexpected changes or revisions. You have to be clear with all the development requirements beforehand and just keep your team always moving forward.

A probable and highly undesirable scenario is that your team will carefully follow the steps nearly to the end of the project but, they may face an unforeseen obstruction that requires a change in scope or goals. Since the used methodology doesn’t welcome change, proceeding with the initial plan won’t be easy.  As you’ll have already put a considerable amount of work into a project, under very specific and fixed assumptions, an unexpected change to any parameter of the project may render much of the finished work useless.

This may have severe consequences and even throw off the entire timeline. Another aspect of Waterfall that reduces flexibility is that Waterfall projects are highly integrated and not an object-oriented approach.

#2 Uncertain and Time-consuming Preplanning

When using this method, you must produce a detailed and thorough requirement definition in one of the earliest phases of the project. But, in such an early phase of the project, trying to define the requirements is often very difficult.

Therefore, many of the requirements are subject to change throughout the project. Specifying requirements in advance means that a lot of the requirements are based on assumptions. You may come across many difficulties to validate those assumptions since the first builds are not available until late in the development phase.

Even the client has to outline all their preferences upfront, without seeing a working version. Once the first builds are available, it’s often too late to change requirements without substantial delays of the project. Also, when planning everything up front, very often you can overlook certain changes due to business plans or market influences. Since change is unwelcome and difficult to carry out, any new developments or changes of requirements which may occur after the initial agreement could raise serious concerns.

#3 Delayed Testing Period

Testing is a very important phase of a project as the results have an impact on all the work that has been done. The best practice would be to integrate testing as a fundamental and continual process throughout development. This has been the case with more recent SDLC models, whereas the waterfall model largely differs, leaving the testing until quite late into the life cycle.

This means quality and security issues or integration problems with existing products are typically discovered quite late in the process. Fixing such issues requires a lot of effort. What’s worse, sometimes testing may be short-changed in order to stay on schedule, and that means that bugs will be discovered by the customer only after the delivery of the product.

In turn, this makes fixing the code expensive and time-consuming. It has been shown that a bug identified at a later stage can cost up to 60 percent more to get fixed, as compared to its cost when identified at an earlier stage.

Another issue related to the testing is the possible appearance of careless coding practices. Testing teams often have less time to complete test execution and since more time is spent during the initial stages for detailed documentation, not enough attention is paid to testing.

#4 Lack of Client or Stakeholder Interaction

At times when communication seems to be one of the crucial factors that can impact project’s success, you cannot afford to leave the client or stakeholders out. In the Waterfall method a lot of time is spent with the client at the outset, with an attempt to document all the perceived requirements.

After this has been done, the implementation team usually take over and the client has no say until the project is nearly done. However, the feedback that arrives late into the development cycle can present a significant issue.

Due to the strict sequential process enforced by the waterfall model, an unforeseen requirement or request for a change, although not impossible to be done, will be both costly and time-consuming for everyone involved in the project. So, this method is definitely not suitable for projects with moderate to high risk of change of requirements.

If you are still not completely convinced with these reasons, add the high amounts of risk and uncertainty, longer delivery time, and other challenges that project schedulers might face to the list.

Considering the shortcomings of the Waterfall approach, which method do you prefer? Which factors made you decide?

Please provide some feedback in the comments section.

**************************************************************

Joel RobertsAbout the Author:

Joel Roberts is a Project Management Consultant and an established author with more than 12 years of experience in working for PrimaveraReader – Primavera P6 companion tool for viewing and analyzing project plans by the project team.

She is passionate about Mind Mapping and innovation management and her articles have been featured in more than a hundred project management and business websites.

Understanding PRINCE2 in the Project Management Context

Any project manager will come across many different project management methodologies and frameworks during their careers. Today I want to write about one such method, Prince 2 to help you understand it better in the project management context of achieving all of the project goals and objectives while adhering to classic project constraints – usually scope, quality, time and budget.

What is PRINCE2?

PRINCE2 is a process-based approach to project management providing an easily tailored and scale-able method for the management of all types of projects. Each process is defined with its key inputs and outputs together with the specific objectives to be achieved and activities to be carried out.

The method describes how a project is divided into manageable stages enabling efficient control of resources and regular progress monitoring. The various roles and responsibilities for managing a project are fully described and are adaptable to suit the project’s size and complexity and the skills of the organisation.

Project planning using PRINCE2 is product-based which means the project plans are focused on delivering results and are not simply about planning when the various activities on the project will be done. Driving any PRINCE2 project is the business case, which describes the organisation’s justification, commitment and rationale for the deliverables or outcome. The business case is reviewed regularly during the project so as to ensure the business objectives, which often change during the life-cycle of the project, are still being met.

Why usePRINCE2?

PRINCE2 provides organisations with a standard approach to the management of projects. The method embodies proven and established best practice. It is generic, non-proprietary and widely recognised. PRINCE2 also offers benefits to the organisation as a whole. These are achieved through the controllable use of resources and the ability to manage business and project risk more effectively.

PRINCE2 enables projects to have:

  • a controlled and organised start, middle and end
  • regular reviews of progress against plan and against the Business Case
  • flexible decision points
  • automatic management control of any deviations from the plan
  • involvement of management and stakeholders at the right time and place during the project the necessary controls and breakpoints to work successfully within any required contractual framework
  • a common language across all interested parties thereby ensuring effective communication channels between the project team, project management and the rest of the organisation

Please comment about your experience with Prince2 or any other methodology that is worth sharing.

Remember to subscribe to my RSS for the next article on Prince2.