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.
**************************************************************
About 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.
Every company struggles to manage projects and teams effectively. From small startups with tight deadlines to large conglomerates making long-term strategic moves, they all need to balance resources with requirements, and future work with current operations. In my experience with this whole range of environments, I’ve had varying degrees of success with project management tools. I’ve used big, cumbersome legacy tools and compared them with small, simple, free apps.
Projects, tasks, and task details are the first thing you see when opening Nuvro. Each is neatly organized in its own column, to get a quick overview. Each shows progressively more detail, and the amount of detail is selectable. Specifically, the project folders in the left-most column can be expanded and collapsed to your preference. The middle tasks column is high-level, while the right column with task details gives you the opportunity to address more immediate or short-term concerns.
When I logon to Nuvro, it shows project folders and tasks. It also shows me a calendar of my assigned tasks organized by due date. This is convenient, because I can concentrate on those that are overdue or shortly due.
Nuvro presents organization and individual performance information in a unique and novel format. Unlike any other tool I have used, Nuvro tracks performance in real-time, visible to the appropriate levels of the organization hierarchy. As with workload, managers can access this information in a consistent format across our teams. Performance dashboards show current productivity as a predictor of future results.