Since I finished university in 2004, I was told that software projects were done in a certain way. Back then, I did not consider its name or if it was appropriate or there were other options. As time went by, I experienced and saw evidence that the method I had known was often not very successful.
What they were talking about was the waterfall software development model. It was about fitting everything into a pre-established flow of phases: analysis, design, implementation, testing, deployment and maintenance, where you cannot advance to the next phase if the previous one is not completely finished. When they tell you this is how it is done, and also without having much experience in the sector, one considers it valid. However, when one sees again and again that the planning is not fulfilled in most cases and that the so-called project manager was in a rage when the time forecast in each phase or subphase upset his valuable Gantt chart, or that it was necessary to go back a phase, out of necessity, I began to suspect that something was not being done very well. And it wasn’t because the team didn’t know how to do its job.
Empirical data that makes you think
An interesting figure I learnt a long time ago is that 84% of IT projects fail (Standish Report Chaos) for some reason related to the methodology. The last updated report that I have seen speaks of 71% failure, which means that at least we are improving in something, although there is much room for improvement. There is always a gap between what is planned and what is executed, so there is no point in trying to squeeze in the development of a project because of deadlines.
If we were to freeze a system’s specifications and make it independent of time and external influences such as the market or the needs of the business area, for example, this model could perhaps work. However, in software development my experience tells me that it is a utopia, the only constant is change. So spending time documenting and fixing a project’s specifications, especially when it’s a large project, doesn’t make much sense, because they will probably change. Fortunately, some computer scholars have already realized this and created the agile manifesto.
In summary, this is an invitation to stop planning and documenting, taking better care of having software up and running as soon as possible (as the lean principles also mention), responding to what the client has validated, with an attitude of being flexible and decisive in the face of to any type of change that may come, prioritizing collaboration between people rather than striving to follow a certain pre-established process.
From the same Chaos Report, I am struck by this information:
Is it so evident that for the execution of IT projects we should NOT continue using development models from the last century? It seems that the evidence coming from our personal experience is corroborated with the data from thousands of projects involved in this study.
Aspects for and against the waterfall model
To wrap things up, I will try to provide the pros and cons of the cascade model, since this methodology is useful in some cases.
- Easy to understand and manage, given the rigidity of the model.
- The phases are completed in order and sequentially, making implementation a simple process.
- It can work well for small projects where specifications can be closed more easily and where changes in scope or direction are not likely.
- It is very suitable for projects where the cost of error is very high: designing an aeroplane, sending a rocket to the moon, a high-speed train, etc, …
- No running software is obtained until the end of the development cycle.
- There are high levels of risk and uncertainty since the model does not adapt to the changes that may come.
- Changes cannot be easily incorporated.
- Not a good model for complex projects where the scope cannot be easily fixed or circumstances are expected to alter the product developed.
- It is difficult to have an idea of the progress of the project in each phase.
- Bottlenecks cannot be anticipated or identified to then address them quickly enough for the success of the project.
At ASPgems we offer more articles like this one as recurring and necessary research work on software development models. Watch this space!