In de definitiefase en de ontwerpfase wordt van klanten gevraagd hun eisen en wensen zo goed mogelijk te formuleren. Dat is lastig om twee redenen. Ten eerste hebben klanten maar een beperkte voorstelling van de (on)mogelijkheden van ICT. Ze weten niet goed wat er kan of zou kunnen en dus weten ze ook niet goed wat ze wel of niet moeten wensen. Ten tweede hebben klanten vaak maar een beperkte kennis van hun eigen bedrijfsprocessen. Veel ICT-projecten gaan over het automatiseren van bestaande bedrijfsprocessen bij een klant. Hoewel de klant misschien al vele jaren volgens die processen werkt, blijkt vaak dat hij niet goed in staat is om zijn eigen bedrijfsproces te definiëren. Hij kan prima op zijn eigen manier werken, maar hij kan niet zeggen welke manier dat nu precies is. Deze precieze definiëring van processen is wel een voorwaarde voor het maken van software die de automatisering zal aansturen. De complexiteit voor klant neemt daarbij toe als hij ook nog eens niet bestaande processen moet gaan beschrijven.

Vaak zie je dat er in de definitiefase een eisen- en wensenlijst op tafel komt die onvolledig is. In de realisatiefase maken de programmeurs de software op basis van die onvolledige lijst. Wanneer de gebruiker dan de eerste versies van de nieuwe software voorgeschoteld krijgt, komen er meer eisen en wensen op tafel. Dat ziet er goed uit, kan je het nu ook zo maken dat ik met een knopje kan inloggen zodat ik niet steeds mijn password hoef te herhalen. De programmeurs verzuchten dat de klant niet weet wat ie wil. De klant beroept zich op het ‘feit’ dat de softwareontwikkelaars professionals zijn en eerder hadden moeten inzien dat de klant dat wilde.

Bij een softwareproject voor de automatische afhandeling van aanvragen voor een dienst via het web was een uitgebreid functioneel ontwerp gemaakt. Lange lijsten van eisen en wensen van de klant waren opgesteld. Een aantal schermontwerpen en flow charts waren toegevoegd waarna de programmeurs aan de slag konden.

Wellicht omdat het project onder grote tijdsdruk stond of misschien omdat de organisatie van de klant behoorlijk rommelig was, bleek dat de ontwerpers een belangrijk onderdeel waren vergeten: handmatig beheer.
De aanvragen werden door de software verwerkt. Omdat het verwerken van de aanvragen automatisch zou moeten verlopen, dachten de programmeurs dat er geen handmatig beheer gewenst zou zijn. Die eis stond ook niet in het functioneel ontwerp. Toen de software werd opgeleverd om te testen, realiseerde de klant zich dat er uitzonderingen waren bij de aanvragen. Sommige aanvragen mochten niet automatisch verwerkt worden maar moesten handmatig verwerkt worden. De software werkte echter alleen automatisch…

In het watervalmodel wordt het gerealiseerde projectresultaat getest aan het einde van de realisatiefase. Dat is laat in het ontwikkelingstraject. In de tijd liggen er meerdere maanden, soms zelfs meer dan een jaar, tussen de definitiefase, ontwerpfase en de realisatiefase. Als er in een laat stadium fouten in het ontwerp boven water komen, is het duur of soms zelfs onmogelijk om de software nog aan te passen, zonder een geheel nieuw project te starten. Omdat we gezien hebben dat het eigenlijk onmogelijk is alle eisen en wensen vooraf goed te definiëren zou een werkwijze wenselijk zijn waarbij het mogelijk is om (tussen) resultaten eerder te testen. De terugkoppeling moet veel eerder komen zodat er betere besluiten genomen kunnen worden.

Bij de keuze voor een softwarehuis werden enkele partijen vergeleken. De klant vroeg bij de concurrerende partijen wat er zoal mogelijk was. De ene partij was wat terughoudend en had zijn twijfels of bepaalde klantwensen wel zonder meer uitvoerbaar waren. De andere partij had een gedreven verkoper in dienst. Als de klant aan de verkoper vroeg of een bepaalde wens mogelijk was, belde hij met een van zijn programmeurs. Kunnen wij een functionaliteit bouwen die X kan? De programmeur dacht voornamelijk in termen van techniek en antwoordde daarop dat in principe alles mogelijk was. De programmeur en de verkoper maakten zich beiden niet druk om de haalbaarheid in termen van projectmanagement (tijd, geld, complexiteit, risico’s, en dergelijke).

Het enthousiasme van de verkoper werkte beter dan de wat terughoudende houding van de andere partij. De klant koos voor de aanbieding van de gedreven verkoper. Het vers binnengehaalde project kwam vervolgens in handen van een projectleider en een groep programmeurs. Na verloop van tijd bleek dat het project niet voldeed aan de wensen van de klant. Dat had onder andere te maken met het feit dat de processen bij de klant veel ingewikkelder bleken dan op het eerste oog leek. Bij een zwaar weer gesprek tussen beide partijen beriep de klant zich op het feit dat de verkoper had gezegd dat functionaliteit X geen enkel probleem zou zijn.