In recent weeks I found myself having discussions about the appropriateness of using the Waterfall Software Development Life Cycle in large enterprise wide transformation programs. The core argument I have come across, suggesting that Waterfall is not suitable, is that due to the very hierarchical nature of the Waterfall life-cycle (where each phase requires the completion of the previous phase before any work can commence – e.g. Design cannot commence before the Analysis is complete, Build cannot commence before Design is complete, etc) projects tend to take far too long to the point that the perceived business benefits cannot get realised on time to be of any value to the business.
What I find fascinating about such discussions is that the people raising them forget that organisations have made a substantial leap forward since the 1950’s and 1960’s. Organisational mentality allowing Information Technology Divisions to operate in a semi dictatorial and independent fashion has since dramatically changed and in today’s world IT is a far more collaborative environment, playing alongside and with co-operation of the other organisational disciplines, while at the same time being seen as a full business partner, supporting the organisation and enabling business functionality.
With that in mind, the discussion about the appropriateness or otherwise of the Waterfall SDLC should be based on objective arguments. First and foremost, the decision to utilise any SDLC should be based on the appropriateness to the environment in which it is meant to be deployed. This ‘appropriateness’ could be measured basded on the following factors:
- Availability of resources – what type of resources does your organisation ‘own’. Are they experienced in the methodology you intend to employ?
- Availability of Subject Matter Experts – does your organisation allow the release of key SME’s for the duration of the project? Can they provide the on-going support required by Agile or are they only available to support analysis and testing?
- Transition to Support – what level of documentation would the support department require in order to assume responsibility for the on-going application support?
- Incremental release of business value – does it make sense and is it relevant to break up the the project delivery into smaller, incremental components?
The assumption that Waterfall based projects are wasteful seems to be based on another assumption that those who drive these projects run them incorrectly. This, quite obviously, is not a valid assumption to make. A Waterfall based project can be as successful in delivering value for money provided that it is managed correctly. A similar observation can be easily made about Agile based projects – to succeed they need to be executed correctly.
The following argument has been raised before but is worth mentioning again – the project management principles required to execute an Agile based project are not different to the ones required to execute a Waterfall based project. The notion that Waterfall deliveries are prone to scope creep, lack of user involvement,and cost and schedule overruns , is prejudicial to say the least and suggests a lack of basic understanding of modern project management techniques.
In all projects, and regardless of the methodology, you need to know what you are delivering, how you will have it delivered and how you will deal with changes affecting your scope. If you haven’t figured out the basics it doesn’t matter what development methodology you use as either case you will fail.
Think about it!