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 customers 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 (see Figure 8).

Figure 8: Accuracy of estimates of time necessary to implement a functionality (Source: McConnell, 1996, p. 168).

Software is never completely free of errors. Even for the well-known packages that are used by many (e.g. Word, Excel, Explorer, OSX, PHP, Flash), there are lists of known bugs available on the Internet. New releases regularly appear on the market, in which software errors have been removed. Customers sometimes expect error-free software. In practice, however, such a goal would make it impossible to complete a piece of software. Moreover, software errors are often not inherent in the software itself.

An educational game was made in Flash. It was agreed that the game would be delivered as a file and that the customer would install it himself on his own server. During the project, the customer requested that a high score feature be included in the game to increase competition between players. This would require a piece of script code in PHP. The game builders made and tested the script code on their own server, which worked in Linux. It worked. The game and script code were delivered to the customer. The customer, however, had a Windows server and, for some reason, the script no longer worked well. The high scores were not saved. The programmer eventually needed a week to resolve the problem. As it turned out, the combination of PHP and Windows does not always work well. The script itself contained absolutely no errors! By using a hack, he was able to get it to work, and everyone was satisfied but who should pay for that extra week of work?

Another software-development project also involved educational software. The problem was that the software worked for the programmers, but it did not work well for the customer. After trying nearly everything, the programmer decided to pay a visit to the customer. As it turned out, the customer was using an old Pentium III system. The slowness of the computer caused the poor performance of the software. The programmers had also tested the software on a Pentium III, but it had worked fine. Further investigation revealed that the customers computer was so slow because it was full of viruses and spyware.

The uncertainty that is illustrated by the examples above does not simplify the writing of project plans. It also complicates agreements between the parties involved. Someone must assume the risks for extra work that must be done. If payment is on an hourly basis, the customer assumes the risk. If a fixed price has been agreed (as in grant-funded projects), the software builder assumes the risk. When more than two parties are involved, it becomes even more complicated. In such a case, who should pay for the extra hours in the project?

Discussions often arise concerning who should be responsible for delays. In many cases, the guilty party is difficult to identify. It is quite possible that none of the parties involved is at fault, as the delay is actually the result of a faulty initial estimate of the number of hours that would be needed. Exceeding the number of project hours and the question of who should pay are frequent sources of conflict in the IT world.