Even processes are likely to determine the way

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 main thing that influences the
decision what methodology is
used are probably the existing
processes. 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 how they should implement projects in the most
effective and efficient way while reducing risks. 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.

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 3
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 may 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 get a lesser time frame to
complete test execution and since more time is spent during the initial stages
for detailed documentation, leaving testing only an afterthought, not much
attention is paid to it.

 

 

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 and longer
delivery time to the list. Anyway, which approach do you prefer? Which factors
made you decide?