12.0 Waterval versus cyclisch projectbeheer (deel 5) – Voorwaarden voor het beheren van cyclische projecten

Gebruikers/klanten nemen actief deel #

Elke cyclus van cyclisch projectmanagement omvat de ontwikkeling van eisen, ontwerp, uitvoering en testen. Dit houdt in dat er in de loop van een cyclus veel keuzes moeten worden gemaakt. Als het programma de wensen van de klant nauwkeurig moet weergeven, moet de klant een actief lid zijn van het projectteam.

Klanten moeten hun eisen zo duidelijk mogelijk communiceren aan programmeurs en ontwerpers. Vaak gaat het om wekelijkse (of in ieder geval tweewekelijkse) deelname aan het projectteam.

Binnen een project dragen consumenten bij aan het definiëren van benodigde features en fietsplanning. Ze werken mee aan acceptatietesten, keuren tussentijdse bevindingen goed of af en dragen bij aan de algehele richting van het project. Daarnaast leidt actieve klantbetrokkenheid tot betere resultaten bij het gebruik van de watervalmethode.

Het team heeft de bevoegdheid om keuzes te maken. #

Binnen een cyclus moet het projectteam in staat worden gesteld om eigen beslissingen te nemen. Als het projectteam deze bevoegdheid niet heeft, zal het cyclische model van projectmanagement niet werken. Als gedurende een cyclus constante goedkeuring van leidinggevenden vereist is, kan dit leiden tot stagnatie. Daarnaast zijn buitenstaanders vaak niet op de hoogte van wat er gebeurt omdat ze niet actief betrokken zijn bij het projectteam; dit maakt het voor hen moeilijk om rationele beslissingen te nemen.

De output van het project (software) kan worden ontleed in kleinere componenten. #

Cyclisch projectmanagement is een methode voor het managen van projecten waarbij delen van het project in een reeks cycli worden voltooid. Dit is alleen mogelijk als de software die wordt ontwikkeld, ontleedbaar is in een aantal min of meer verschillende componenten.

De vereisten van het management voor projectbeheersoftware zijn voornamelijk wereldwijd; het management stelt geen directe, concrete of specifieke eisen. Een van de voordelen van cyclisch projectmanagement is de nauwe samenwerking tussen de klant, ontwerpers, programmeurs en eventuele testers tijdens de cycli. Als aan het begin van een project specifieke en concrete eisen worden gesteld, beperkt dit het vermogen van het projectteam om bij het maken van ontwerpkeuzes naar eigen goeddunken te oordelen. Tal van eisen aan een project blijken tijdens het proces aanpassing nodig te hebben en dienen dus niet (te) vast te staan bij de start.

De klant begrijpt de werkzaamheden. #

Als er binnen een cyclus belangrijk technisch werk moet plaatsvinden dat voor de klant moeilijk te begrijpen is, bestaat het risico dat de klant niet in staat is om effectief bij te dragen aan het team. In een dergelijke situatie heeft de klant weinig inspraak in de ontwerpbeslissingen die moeten worden genomen.

Een soortgelijk risico bestaat wanneer de klant niet op de hoogte is van de voortgang. Veel van het werk kan bijvoorbeeld worden besteed aan codering, met weinig aandacht voor de gebruikersinterface. Het is van cruciaal belang dat klanten voldoende inzicht hebben in de inhoud en het verloop van een cyclus om niet aan de zijlijn te worden geduwd.

Het moet mogelijk zijn om op de schreden terug te keren. #

Ook bij cyclisch projectmanagement volgen teams soms paden die niet goed blijken te zijn. In zo’n geval moet het mogelijk zijn om een stap terug te doen. Indien een tijdens een cyclus aangemaakte nieuwe module onvoldoende blijkt te zijn, moet het werken met de vorige module weer mogelijk zijn. Dit stelt eisen, met name aan de archivering en documentatie van projectmaterialen. CVS en Subversion zijn twee handige tools voor deze taken (zie Bijlage 3 voor een volledige lijst met tools).

Naast programmeervaardigheden moeten programmeurs effectief kunnen communiceren met klanten en vice versa. Teamleden moeten intellectuele denkers zijn. Discipline is vereist om door te gaan met het werk.

Ook de organisatie waarin het project wordt uitgevoerd moet voldoende draagvlak bieden voor deze werkwijze. Tijdregistratie-, archiverings- en planningssystemen zijn nodig om de projecten te ondersteunen. Deze registratiesystemen bieden de essentiële openheid om een rechtvaardige toewijzing van middelen over projecten en tijdsperioden te garanderen.

Prioritering #

Projecten moeten voldoende belang krijgen en er moeten teamleden voor beschikbaar worden gesteld. Het is niet effectief om van teamleden te eisen dat ze aan te veel taken tegelijk werken. Als een organisatie niet voldoende is aangepast aan projectmatig werken, leidt de cyclische projectmanagementflexibiliteit waarschijnlijk tot chaos. Daarnaast is de watervaltechniek gebaat bij een georganiseerde aanpak van projectmanagement (zie Wijnen, 2004, p. 111).

De directeur van een softwareontwikkelingsbedrijf, die meer visionair dan manager was, had bijna elke maand een geweldig idee en initieerde voortdurend nieuwe initiatieven in zijn bedrijf. Als gevolg hiervan werden oudere projecten nooit voltooid en werkten werknemers aan maar liefst vijf projecten tegelijk. De charismatische directeur had net een boek gelezen over snelle applicatieontwikkeling (RAD) en was er erg enthousiast over – vooral het ‘snelle’ element. Hij plakte de fundamentele ideeën van RAD op het kopieerapparaat en verwachtte toen dat iedereen met deze noties zou gaan werken. Het was tenslotte een uitstekende techniek.

Risico’s van cyclisch projectmanagement #

Cyclische projectmanagementtechnieken laten soms onvoldoende tijd over om de vereiste functies uit te voeren. Doordat de looptijd van het project vastligt, zullen er vrijwel zeker minder functies worden toegevoegd dan aanvankelijk voorzien.

Hoewel dit een legitieme zorg is, is het ook inherent aan de watervalbenadering . De bepalende stap van de watervalbenadering omvat een diepgaand onderzoek van de vereisten. Deze analyse zal waarschijnlijk leiden tot een beter tijdbeheer. Om bovengenoemde redenen is dit in de praktijk vaak niet het geval.

Bovendien worden functionaliteiten in deze aanpak weggelaten vanwege een gebrek aan middelen om ze te ontwikkelen.

Bij kringloopbenaderingen wordt pragmatisch omgegaan met eisen. Behoeften in cycli kunnen bijvoorbeeld als volgt worden geclassificeerd met behulp van de MoSCoW-criteria (Stapleton, 2003):

  • Must Have: systeemkritische vereisten
  • Zou moeten hebben: kritische behoeften waar gebruikers echt naar verlangen
  • Zou kunnen hebben: gewenste behoeften die gemakkelijk kunnen worden genegeerd
  • Want to Have: vereisten waaraan deze keer niet zal worden voldaan: vereisten die tot later kunnen wachten

Ongeacht of bepaalde capaciteiten niet meer beschikbaar zijn, de DANS-projectmanagers zijn van mening dat cyclisch werken leidt tot een hogere klanttevredenheid dan de watervalaanpak. Hoe dan ook, verwachtingen worden regelmatig effectiever gecontroleerd en projecten leiden routinematig tot resultaten die werken, zelfs als ze minder complex zijn dan aanvankelijk gedacht.

Potentiële nadelen begrijpen #

Een vaak genoemd nadeel van XP is dat er veel vermogen wordt overgedragen aan programmeurs. Als ze deze bevoegdheid misbruiken, kunnen ze het gebrek aan technische expertise van de klant in hun voordeel uitbuiten. Om dit scenario te vermijden is een projectleider nodig die zowel de belangen van de programmeurs als de klant kan behartigen. Deze projectleiders helpen hun opdrachtgevers bij het selecteren en plannen van cycli, bij het inzichtelijk maken van de technische onderbouwing van hun selecties en bij het verzorgen van administratie en rapportage.

Ten slotte is een ander nadeel van XP dat de implementatie van de methode een hoge leercurve vereist voor programmeurs, managers en consumenten.