Het watervalmodel gaat uit van een aantal fasen. In het projectplan moet de projectleider een schatting maken van de hoeveelheid tijd (en dus geld) die nodig is voor elke fase. We hebben al gezien dat het inschatten van de factor tijd lastig is bij projecten in zijn algemeenheid. Met name als die schatting gegeven moet worden in het beginstadium van het project. Voor softwareprojecten is het schier onmogelijk. Stel dat het zou lukken een kwalitatief goede lijst van functionaliteiten op te stellen in de definitiefase. In theorie zou het projectteam dan per functionaliteit redelijk moeten kunnen inschatten hoeveel tijd er nodig is voor de realisatie. De praktijk laat echter zien dat er te veel onzekerheden zijn om een redelijke inschatting te kunnen maken (o.a. McConnell, 1996):
- Als functionaliteit gemaakt is, blijkt nogal eens dat de klant hem toch niet nodig heeft. De gebruikte uren zijn als nutteloos te beschouwen.
- Eisen en wensen veranderen gedurende het project.
- Moet de functionaliteit goedkoop of duur worden uitgevoerd? Er zijn vele manieren van realisatie en implementatie mogelijk.
- Hoe wordt functionaliteit technisch ontworpen? Het ontwerp bepaalt in grote mate de tijd die nodig is voor het maken ervan.
- Hoe goed moet de kwaliteit zijn van functionaliteit? Bijvoorbeeld moet een webapplicatie altijd 100% beschikbaar zijn, of mag hij een paar uur per jaar offline zijn?
- Het vinden en herstellen van fouten in software varieert van minuten tot weken.
- Hoe lang duurt de installatie en integratie van de nieuwe software bij de bestaande systemen van de klant?
- Het ontbreken van kennis over mogelijke oplossingen maakt het schatten van de benodigde hoeveelheid tijd ook moeilijk. Het is daarbij ook moeilijk in te schatten hoe lang het verkrijgen van de benodigde kennis duurt.
Uit bovenstaande lijst blijkt dat er heel veel factoren zijn die van invloed zijn op de hoeveelheid tijd die uiteindelijk nodig blijkt te zijn voor de realisatie van software. Uit onderzoek (McConnell, 1996, p. 168) is gebleken dat de schattingen voor de benodigde tijd voor het realiseren van functionaliteit in het begin van een project varieert tussen vier keer te weinig tijd en vier keer teveel tijd. Dat betekent bij een verkeerde schatting dat de benodigde hoeveelheid tijd 4 maal hoger of lager kan uitvallen. Die schattingen worden nauwkeuriger naarmate het project verder is. Na het maken van een functioneel ontwerp is de marge echter nog altijd tussen de 25% teveel of te weinig. Pas vlak voordat functionaliteit gerealiseerd wordt, kan een schatting met redelijk hoge zekerheid gegeven worden (zie figuur 8).
Figuur 8: Nauwkeurigheid van inschatten van benodigde tijd voor het realiseren van een functionaliteit (Bron: McConnell, 1996, p. 168).
Software is nooit 100% foutloos. Zelfs van bekende software pakketten waar velen mee werken als Word, Excel, Explorer, OSX, PHP, Flash zijn er lijsten van bekende bugs te vinden op het internet. Er komen geregeld nieuwe releases op de markt waarvan er fouten uit de software gehaald zijn.
Klanten verwachten soms foutloze software maar als dat nagestreefd zou worden in de praktijk zou dat betekenen dat software nooit af is. Bovendien komt het niet zelden voor dat de fout in de software niet in de eigen software zit.
Een educatieve game werd gemaakt in Flash. Afgesproken was dat de game als bestand aangeleverd zou worden en dat de klant hem zelf zou installeren op zijn server. Gedurende het project wilde de klant graag dat er een high score aan de game zou worden toegevoegd om het competitieve element tussen de spelers te verhogen. Daarvoor was een stuk scriptcode nodig in PHP. De gamebouwers maakte die scriptcode en testten die op hun eigen server die op Linux draaide. Het werkte. De game en de scriptcode werden aangeleverd aan de klant. Die klant had echter een Windows server en om de een of andere reden werkte het script niet goed meer. De high scores werden niet opgeslagen.
Uiteindelijk had de programmeur een week nodig om het probleem op te lossen. Het bleek zo te zijn dat de combinatie van PHP en Windows server soms niet goed werkt. In het script zelf zat helemaal geen fout! Door een hack kon hij het werkend krijgen en iedereen was tevreden. Alhoewel, wie moest die week extra werk betalen?
Bij een ander softwareontwikkelingstraject werd ook educatieve software gemaakt. Het probleem was dat de software bij de programmeurs prima werkte, maar bij de klant het niet goed deed. Na van alles geprobeerd te hebben, besloot de programmeur bij de klant op bezoek te gaan. Daar bleek dat de computer van de klant een oude pentium III was. Door de traagheid van de computer deed de software het niet goed. Bij de programmeurs was echter ook getest op een pentium III en daar werkte het prima. Na verder onderzoek bleek dat de computer van de klant zo traag was omdat het systeem vol zat met virussen en spyware.
Bovenstaande onzekerheid maakt het schrijven van projectplannen niet eenvoudiger. Ook het maken van afspraken tussen betrokken partijen wordt er lastig door. Iemand moet het risico dragen voor het meerwerk dat gedaan moet worden. Als er betaald wordt op uurbasis, dan ligt het risico bij de klant. Als er een fixed price is afgesproken (zoals bij subsidiefinancieringen), ligt het risico bij de softwarebouwer. Als er meer dan twee partijen bij zijn betrokken, ligt het nog complexer. Wie betaalt er dan voor de meeruren op een project?
Vaak ontstaat er een discussie over wie er verantwoordelijk is voor de vertragingen. Het aanwijzen van een schuldige is in veel gevallen heel moeilijk. En wellicht is er überhaupt geen schuldige omdat er geen sprake is van vertraging, maar van een verkeerde inschatting van de hoeveelheid uren in de eerste plaats. Het overschrijden van het aantal projecturen en de vraag wie dat moet betalen, is een bron van conflicten in de IT-wereld.
