People often react to failure by re-intensifying their efforts - trying to perfect the approach that failed last time. In the First World War, the reaction to stalemate in trench warfare was more bombardments and more human wave assaults. As a rule, if you keep on doing the same things you tend to get the same results. This is a lesson that can be learnt by the IT industry. We have assembled enough history to know that many IT projects fail in a predictable fashion and one of the chief culprits is our slavish adherence to the waterfall model of application development.

The problem with the waterfall model is that it has become hardwired into the thinking of project planners. It has become so pervasive that the requirements, design, build, and test progression is a given in most projects. In the early days of simple, stand-alone applications, the waterfall model worked well spawning a host of voluminous methodologies, but it does not suit the problems of the complex, risky, and integrated projects that IT has to deliver today.

In the 60's and 70's, IT developed stand-alone, batch applications. The complexities of integrating applications were only dreamed of by ambitious database architects. Today, hardly any development is made in isolation unless, like the NHS IT project, you give yourself the luxury of a scorched earth IT strategy. Because of its origins, the waterfall method does not address integration but ignores it until the end of the project, when we encounter the familiar task of trying to stitch together disparate applications and change schedules to the annoyance of the operations manager.

Another change in the nature of IT projects is that most of today's projects have a high proportion of reuse - implementing packages and reusing frameworks. The waterfall idea of creating a detailed set of requirements and then trying to find a package that fits is neither economic not practical. Increasingly, organisations are seeing the benefits of solution-constrained development rather than greenfield design. What is wrong with asking the user to adopt industry best practices that are encapsulated in a successful package? Rather this than IT spending a fortune implementing the users' Spanish practices? Package-led design means making the waterfall run uphill – and flexing the user requirements and not the application.

So, if the waterfall model is a bad fit to today's IT projects, what is the best methodology? This is the wrong question – life is more complicated than this. There is not one best methodology but a toolkit of methods to select when you have gained a clear view of the problems and risks faced in a project.

• If there are significant user uncertainties then Joint Requirements Planning and Joint Applications Design is the way forward.
• If there is technical risk then an iterative approach can mitigate these risks.
• If integration is a key result then establish a strong configuration and change management approach.
• If a package is the cheapest solution then concentrate on change management and process re-engineering.

Organisations that base their approach on waterfall methodologies need to rethink their approach or run the risk of being stuck in IT trench warfare. A judicious approach selecting creative approaches that tackle today's problems will create a better and cheaper solution.