“It is not on requirements”, it has become one of the quotes most spoken by project managers these days. This approach is typical of a Waterfall project management model. For those who do not know what it is, the Waterfall model, assumes that before starting any kind of development in the project, all requirements must be perfectly closed, and accepted by the customer.
It is therefore a linear process, first requirements are defined, then a work breakdown structure (WBS) is created, project team draw up estimates for the tasks to be performed and finally the project manager builds the project plan with tasks, durations, precedence’s, allocates resources and calculates when the project will end. In a very simplistic way, this is what happens in a typical waterfall project. This type of model is very useful in projects where the requirements are unlikely to be changed (for example the construction of a bridge), or where the success of the project is defined by completion of all scope.
However, today I like to write about software projects. There are critical software projects (software from a nuclear power plant, or software of a spaceship of NASA), but the vast majority of the software produced it´s not critical. On most of the times, the requirements are changed as the project is progressing, either because the business or the market has evolved, or some requirements are no longer necessary. The software lifecycle is decreasing, changing constantly, and…
Are you interested in this Topic?
Do your registration on the WINNING website and download the document here



