The waterfall method assumes a number of phases. In their project plans, project leaders must include estimates of the amount of time (and therefore money) that will be needed for each phase. We have already seen that time estimates are generally difficult for any project, particularly if they must be made in the early stages of a project. For software projects, it is simply impossible. Imagine that it were feasible to compile a qualitatively adequate list of functionalities in the definition phase. In theory, the project team should then be able to provide a reasonable estimate of how much time will be necessary to implement each functionality. In practice, however, there are too many uncertainties to allow a reasonable estimate (e.g. McConnell, 1996):
- Once a functionality has been made, it is often discovered that the customer does not need it after all. The hours that were used in implementing this functionality can therefore be regarded as useless.
- Requirements change during the project.
- Should the functionality be implemented expensively or inexpensively? There are many possible methods of implementation and realisation.
- How will the functionality be designed technically? The design largely determines the amount of time that will be needed to make it.
- How high must the quality of the functionality be? For example, should a web application always remain completely available, or can it be offline for a few hours each year?
- The time needed to identify and repair errors in software can vary from minutes to weeks.
- How long will it take to install and integrate the new software into the customer’s existing systems?
- The lack of knowledge concerning possible solutions also complicates the estimation of time. Further, it is difficult to estimate how long it will take to acquire the necessary knowledge.
The list above shows that many factors can affect the amount of time that will ultimately prove necessary to implement a new piece of software. Research (McConnell, 1996, p. 168) has shown that the estimates of the time needed to implement a functionality at the beginning of a project varies between four times too little time and four times too much time. This means that the amount of time necessary can turn out to be either four times higher or four times lower than a faulty estimate. These estimates become more accurate as the project progresses.
After the functional design has been made, the margin is reduced to twenty-five per cent too much or too little. Only when the functionality is implemented can an estimate be provided with a high level of certainty.
Wouter Baars has a Master of Science degree in Industrial Engineering and Management Science. He has been a project manager for several years for The European commission, Waag Society, KPN (Dutch telecom provider) and many smaller organizations. He is specialized in creative projects such as serious game development, e-learning and software development. Currently he is teaching project management and coaching organizations that are working on their project management. More info on his work: www.projectmanagement-training.net.
Originally published by DANS – Data Archiving and Networked Services – The Hague