The "traditional" way of running projects incorporates a waterfall methodology, in which - as the visual allusion indicates - a project is broken up into (typically quite large) phases of flat activity, that must be completed and closed off completely before the project can move on (go over a fall) into the next phase of activity.

In the last decade, this waterfall methodology has been challenged by the concept of an agile methodology. Agile methodologies are inherently user-centred and iterative.

The problem with waterfall methodology
Historically, waterfall methodologies have been the first and only recourse of project managers when considering how to develop software.

In this kind of methodology, project requirements are first fully defined and "locked down" (i.e. not allowed to change). Design is then allowed to commence, and then stopped (i.e. locked down and not allowed to change) before code creation is undertaken. Then, when coding has stopped and been locked down, testing takes place at the very end of the process - typically only to ensure that there are no bugs or defects.

In waterfall methodology, each phase is a complete (self-contained) activity that leads to the next only via the very narrow funnel of a formal sign-off. Documentation and rigidity are at the heart of this methodology. The project team is expected to conform to a structured plan, to go away and work from this as a separate unit from the customer, and to return with a completed piece of software within the timeframe and budget conforming to initial expectations.

The problem with waterfall methodologies is that they don't work for complex software projects! In particular:

• A waterfall approach does not allow for the design process to overlap with the requirement process, or influence it in any way. This means issues arising out of the design process, which create the need for changes, can only be taken on board by the project team if a rigid and constricting change control process is followed
• Initial expectations are likely to have changed dramatically over the course of the development. Indeed, by the time a customer has got to the stage of fully defining the detailed requirements, business needs may have changed
• Traditional waterfall methodologies require that customers tell the developers everything that they might want in the system before the next waterfall steps can occur. The result is bloatware, i.e. software so richly featured that the majority (65% to 80%) of delivered functionality is rarely or ever used by anyone

In response to these kinds of issues with waterfall methodology, iterative, lightweight development processes were originated, now collectively referred to as agile methodology.