10.0 Waterval versus cyclisch projectbeheer (deel 3) – Projectlevenscyclus en resultaten

Gedurende de levenscyclus van het project moeten gebruikers in staat zijn om alle tussentijdse resultaten te testen. #

Klanten worden aangespoord om hun behoeften zo nauwkeurig mogelijk te definiëren tijdens de definitie- en ontwerpfasen. Dit is om twee redenen een uitdaging. Om te beginnen hebben consumenten een beperkt begrip van de mogelijkheden en onmogelijkheden van informatietechnologie. Ze hebben geen idee wat haalbaar is of zou moeten zijn, en ook niet wat ze wel of niet zouden moeten wensen. Ten tweede ontbreekt het consumenten vaak aan een grondig begrip van hun eigen bedrijfsprocessen.

Tal van IT-initiatieven omvatten de automatisering van de huidige bedrijfsprocessen van een organisatie. Hoewel consumenten al lange tijd met processen werken, missen ze vaak het vermogen om hun eigen bedrijfsprocessen te ontwerpen. Ze kunnen op hun eigen manier goed functioneren, maar kunnen niet aangeven wat die manier is. Exacte procesdefinitie is vereist voordat software wordt ontwikkeld die de automatisering aanstuurt. De complexiteit van klanten neemt toe als gevolg van het moeten uitleggen van huidige procedures.

Criteria bepalen #

Vaak is de lijst met criteria die tijdens de definitiefase ontstaan, onvolledig. Programmeurs maken software in overeenstemming met deze deellijst tijdens de implementatiefase. Wanneer consumenten bètaversies van nieuwe software tegenkomen, worden extra behoeften duidelijk. ‘Het ziet er mooi uit, maar zou je het misschien kunnen repareren zodat ik niet steeds mijn wachtwoord hoef in te voeren?’ Programmeurs klagen vaak dat klanten niet zeker weten wat ze willen. Klanten stellen dat softwareontwikkelaars als experts eerder in het proces hadden moeten vaststellen wat de klanten willen.

Er is een uitgebreid functioneel ontwerp gemaakt voor een softwareproject dat de geautomatiseerde verwerking van applicaties voor een webgebaseerde service omvatte. Tal van klantbehoeften werden gebundeld. Na het toevoegen van enkele schermontwerpen en stroomtekeningen konden de programmeurs aan de slag.

Klanten en beperkingen beheren #

Mogelijk als gevolg van de grote tijdsdruk van het project of mogelijk als gevolg van de nogal chaotische organisatie van de klant, waren de ontwerpers vergeten uit een cruciaal onderdeel te bestaan: handmatige administratie. Het programma verwerkte de aanvragen. Omdat de aanvragen automatisch verwerkt zouden worden, redeneerden de programmeurs dat er geen menselijke administratie nodig zou zijn. Ook dit criterium is in het functioneel ontwerp weggelaten.

Toen het programma ter test werd aangeboden, ontdekte de klant dat veel apps uitzonderingen hadden. Deze aanvragen kunnen niet automatisch worden verwerkt en moeten handmatig worden afgehandeld. Het programma werkte echter volledig automatisch.

De waterval projectmanagement vereist het testen van het werkelijke resultaat van het project aan het einde van de uitvoeringsfase. Dit is een late ontwikkelingsstadium . Tussen de definitiefase, ontwerpfase en implementatiefase kunnen maanden of zelfs meer dan een jaar verstrijken. Als ontwerpfouten in een laat stadium van het project worden gevonden, kan het kostbaar, zo niet onmogelijk zijn om het programma aan te passen zonder een volledig nieuw project te starten. Aangezien het vrijwel onmogelijk is om alle criteria vooraf vast te stellen, is een werkaanpak die toetsing van (tussen)uitkomsten mogelijk maakt wenselijk.

Vereisten analyseren #

Bij het vergelijken van een aantal potentiële softwarebedrijven vroeg een opdrachtgever naar de mogelijkheden. Een partij aarzelde en zette vraagtekens bij de haalbaarheid van veel van de eisen van de klant. De tegenpartij werd vertegenwoordigd door een agressieve verkoopagent.

Toen een klant informeerde naar de haalbaarheid van een specifiek verzoek, belde de verkoper zijn codeurs. ‘Kunnen we een functie maken die X doet?’ De programmeur, die vooral in technische termen dacht, zei dat alles theoretisch mogelijk was. Noch de programmeur, noch de verkoper maakte zich zorgen over project management haalbaarheid (bijvoorbeeld tijd, geld, complexiteit en risico).

De opwinding van de verkoopvertegenwoordiger presteerde beter dan de terughoudende houding van de andere partij. De klant koos voor het agressieve aanbod van de verkoper. Het nieuw verworven project werd vervolgens overgedragen aan een projectmanager en een team van programmeurs.

Na enige tijd werd duidelijk dat het project niet voldeed aan de verwachtingen van de klant. Dit kwam mede doordat de procedures voor de opdrachtgever veel complexer waren dan ze in eerste instantie leken. Tijdens een verhit gesprek tussen beide partijen zei de klant dat de verkoper ‘had aangegeven dat functionaliteit X geen probleem zou zijn.