It should be possible for all intermediate results to be tested by users throughout the entire trajectory of the project

In the definition phase and the design phase, customers are asked to formulate their requirements as well as possible. This is difficult for two reasons. First, customers have only a limited conception of the possibilities or impossibilities of IT. They do not have a good idea of what is or should be possible or what they should or should not want. Second, customers often have only limited knowledge of their own business processes. Many IT projects involve the computerisation of a customers existing business practices. Even though customers may have worked with the processes for many years, they are often not able to define their own business processes. They can work fine in their own way, but cannot say exactly what that way is. The precise definition of processes is a precondition for making software that will drive computerisation. The complexity for customers thus increases if they must describe existing processes.

The list of requirements that is developed in the definition phase is often incomplete. In the implementation phase, programmers make software according to this incomplete list. When users are confronted with the initial versions of the new software, additional requirements are identified. It looks good, but now can you make it so that I don’t have to keep entering my password? Programmers often complain that customers do not know what they want. Customers appeal to the fact that, because software developers are professionals, they should have determined earlier in the process what the customers wanted.

In a software project that involved the automatic processing of applications for a web-based service, an extensive functional design was made. Long lists of requirements from the customer were compiled. A number of screen designs and flow charts were added, after which the programmers could get started. Probably because the project was under extreme time pressure or perhaps because the customers organisation was rather chaotic, the designers had neglected to include one important component: manual administration. The applications were processed by the software. Because the processing of the applications was to be automatic, the programmers thought that no manual administration would be desired. This requirement also did not appear in the functional design. When the software was delivered for testing, the customer realised that there were exceptions in some of the applications. These applications could not be processed automatically, but would have to be handled manually. The software, however, worked only automatically.

In the waterfall method, the actual project result is tested at the end of the implementation phase. This is late in the development process. The time between the definition phase, design phase and implementation phase sometimes amounts to months or even more than a year. If design errors are discovered in a late stage of the project, it can be expensive or sometimes even impossible to adapt software without beginning an entirely new project. Because we have seen that it is practically impossible to specify all requirements beforehand, a working method that allows the possibility of testing (intermediate) results earlier is desirable.

Comparing a number of prospective software houses, a customer asked the competing parties what was possible. One party was somewhat reserved and doubted whether some of the customers requests would be feasible. The other party had an aggressive sales representative. When the customer asked the sales representative if a particular request would be possible, the sales representative telephoned his programmers. Can we build a functionality that can do X? The programmer, who thought primarily in technical terms, answered that, in principal, anything was possible. Neither the programmer nor the sales representative worried about feasibility in terms of project management (e.g. time, money, complexity, risk).

The sales representatives enthusiasm was more effective than the other parties reserved attitude had been. The customer chose the aggressive sales representatives offer. The newly acquired project subsequently came into the hands of a project leader and a group of programmers. After a time, it became apparent that the project did not fulfil the customers expectations. This had partially to do with the fact that the processes were much more complicated for the customer than they had originally appeared. During a heated discussion between the two parties, the customer referred to the fact that the sales representative had said that functionality X would not be a problem.