Realisatiefase

In de realisatiefase wordt het project zichtbaar. In deze fase vindt de bouw van het projectresultaat plaats. Programmeurs zijn aan het coderen, designers zijn bezig beeldmateriaal te ontwikkelen, aannemers zijn aan het bouwen, de reorganisatie wordt daadwerkelijk in gang gezet. Het is de fase dat een project zichtbaar wordt voor buitenstaanders. Voor hen lijkt het alsof het project nu pas gestart is. Het is de ‘doe’ fase. In deze fase is het van belang om de vaart er goed in te houden.

Bij een project was over het hoofd gezien dat een van de belangrijkste teamleden elk moment vader kon worden en zich ongeveer een maand niet op het werk zou laten zien. Om het team niet stil te laten vallen, werd een externe specialist ingehuurd, die zijn werk overnam. Het team kon verder, maar de externe kracht drukte behoorlijk op de begroting.

Aan het einde van de realisatiefase wordt het resultaat gecontroleerd aan de hand van de eisen- en wensenlijst uit de definitiefase. Het resultaat wordt ook gecontroleerd aan de hand van de ontwerpen. Er wordt bijvoorbeeld getest of de webapplicatie inderdaad Explorer 5 en Firefox 1.0 en hoger ondersteunt. Of dat de afwerking van een gebouw inderdaad heeft plaatsgevonden volgens afspraak. Of dat de gebruikte materialen inderdaad de materialen zijn als bepaald in de definitiefase. Als aan alle eisen en wensen is voldaan en als het resultaat overeenkomt met de ontwerpen dan is deze fase klaar.

Betrokkenen moeten in hun achterhoofd houden dat het vrijwel nooit helemaal zal lukken om het projectresultaat te verkrijgen, dat exact voldoet aan de oorspronkelijke eisen en wensen van de definitiefase. Door onverwachte gebeurtenissen en door voortschrijdend inzicht zal het projectteam tijdens de realisatie van het project soms moeten afwijken van de eisen- en wensenlijst en de ontwerpdocumenten. Dit is een potentiële bron van conflicten, in het bijzonder als er een externe klant is die het projectresultaat heeft besteld. De klant zal zich dan namelijk beroepen op de afspraken die gemaakt zijn in de definitiefase.

De regel is dat na de definitiefase er geen wijzigen meer mogen zijn in de eisen en wensen. Dat geldt ook voor de ontwerpen: na de ontwerpfase mag er niets meer veranderen aan het ontwerp. Als dit toch moet (en dat moet soms), is het van belang dat de projectleider er voor zorgt dat de wijziging zo snel mogelijk besproken wordt met de betrokkenen (met name de beslissers of klant). Daarbij is het van belang dat de besloten verandering goed gedocumenteerd wordt, dit om latere misverstanden te voorkomen. Over de documentatie van het project volgt later meer.

Nazorgfase

Een fase die vaak over het hoofd gezien wordt, maar die erg belangrijk is, is de nazorgfase. In de nazorgfase wordt alles geregeld om het projectresultaat daadwerkelijk te doen landen. Voorbeelden van activiteiten die in de nazorg plaatsvinden zijn handleidingen schrijven, instructie en training voor gebruikers, helpdesk inrichten, onderhoud van het resultaat, evaluatie van het project zelf, schrijven van het projectverslag, een feestje om het bereikte resultaat te vieren, overdracht naar beheerders, opheffen van het projectteam en dergelijke.

De centrale vraag in deze fase is wanneer en waar het project ophoudt. Onder projectleiders wordt er vaak gegrapt dat de eerste 90% van een project snel gaat en dat de laatste 10% nog jaren voortduurt. Het is van belang dat bij het begin van het project al goed wordt nagedacht over waar de grenzen van het project liggen, zodat in de nazorgfase het project bij het bereiken van die grens afgesloten kan worden.

Soms is het voor de betrokkenen niet duidelijk of een project een prototype of een werkend product op zal leveren. Dit speelt met name bij vernieuwende projecten, waar de uitkomst onzeker is. De klant denkt dat hij een werkend product krijgt, terwijl het projectteam denkt bezig te zijn met het bouwen van een prototype. Dit uit zich vooral in de  nazorgfase. Zo was er een softwareproject waarbij iets heel nieuws werd geprobeerd. Het was spannend of het allemaal resultaat zou opleveren. Uiteindelijk was er goed resultaat. Het team leverde een stuk software op dat goed werkte. Althans in een testopstelling.
De klant, die niet zoveel wist van ICT, dacht echter dat hij een werkend product had gekregen. Het had immers op zijn bureaucomputer gewerkt. De software werkte ook wel, maar toen het geïnstalleerd werd bij zijn 50 werknemers, begon het prototype kuren te vertonen en was het af en toe instabiel. De programmeurs konden de software wel repareren, maar hadden daar geen tijd voor omdat ze alweer met een volgend project bezig waren. Bovendien hadden ze helemaal geen zin in het oplappen van iets wat zij zagen als een probeersel. Toen Microsoft een paar maanden later met servicepack 2 voor Windows uitkwam, deed de software het helemaal niet meer. De klant was boos omdat het “product’’ wéér niet goed werkte. Omdat het een belangrijke klant was probeerde de projectleider het een en ander bij de programmeurs gedaan te krijgen. Maar de programmeurs verzetten zich. Het repareren van de bugs verstoorde hun nieuwe project te vaak. Bovendien was het in hun ogen maar een prototype. Om het geschikt te maken voor groot gebruik, moest de hele architectuur gewijzigd worden. Ze vroegen zich af wanneer het nu eens klaar zou zijn met de stroom van klachten van de klant.

Kern van het 6-fasenmodel is ‘eerst denken en dan doen’. Elke fase heeft zijn eigen werkpakket. Elk werkpakket heeft zijn eigen aspecten waarop geconcentreerd moet worden. Op die manier hoef je dan bijvoorbeeld in de realisatiefase niet meer te discussiëren over wat er nu gemaakt moet worden. Dat is, als het goed is, bepaald in de definitiefase en ontwerpfase. Zie onder andere Wijnen en Kor (Wijnen, 2004, Kor, 2002) voor een uitgebreidere beschrijving van het 6-fasenmodel en de takenpakketten per fase.

Klik hier voor het oorsponkelijke document van Wouter Baars op projectmanagement-training.nl.

Een goede webdesigner moet niet alleen weten welke HTML codes hij kan gebruiken en of zijn website wel snel genoeg laadt. Hij moet ook rekening houden met rechten van anderen.

Bij het ontwerpen van een site kan niet zomaar alles gebruikt worden. Het is niet toegestaan om andermans tekst, plaatjes, muziek of scripts over te nemen op een website. Zeker bij muziek kan dat snel leiden tot grote juridische problemen.

Daarnaast kan blijken dat de domeinnaam -al dan niet toevallig- sterk lijkt op iemands merk. Ook worden merknamen wel gebruikt in meta-tags of magneetwoorden bij zoekmachines. Hiervoor is vrijwel altijd toestemming van de merkhouder vereist. Tevens bestaat er -zeker bij online winkels en andere commerciële websites- de kans dat inbreuk wordt gemaakt op een octrooi van een ander.

Auteursrecht

Overnemen van andermans tekst of afbeeldingen is inbreuk op het auteursrecht. Stijlen, concepten en ideeën mag je wel overnemen. Helaas is het in de praktijk vaak moeilijk om tegen inbreuk op te treden.

Gebruik van andermans werk

Op webpagina’s, maar ook op de individuele afbeeldingen, geluidsbestanden, scripts en andere onderdelen van een website rust auteursrecht. Het maakt niet uit of er een expliciete copyright-vermelding bij staat, of dat de rechten zijn voorbehouden of dat het gratis op Internet wordt aangeboden.

Dit betekent dat het overnemen of hergebruiken van onderdelen van andermans website niet is toegestaan. Een plaatje van iemand anders’ site kopiëren en op je eigen site zetten, mag dus niet. Ook mag je geen teksten of afbeeldingen uit boeken inscannen en op je website plaatsen.

Stijlen en ideeën over vormgeving (zoals een navigatiebalk bovenaan, het gebruik van tabbladen of een icoontje van een winkelwagentje) zijn niet beschermd. De concrete uitwerking daarvan wel. Je mag dus best net als Amazon.com de onderdelen van je winkel aangeven met tabbladen en een icoontje van een winkelwagentje gebruiken om bestellingen te verwerken. Je mag alleen niet precies dezelfde tabbladen of precies hetzelfde icoontje gebruiken.

Overnemen door anderen

Het omgekeerde kan zich natuurlijk ook voordoen: je hebt een mooie website gemaakt, en iemand anders gaat met de tekst, afbeeldingen of scripts aan de haal. Meestal is het erg lastig om hier iets aan te doen. Het beste is om zo snel mogelijk bewijs te verzamelen van wat er overgenomen is, en door wie. Daarna kun je een vriendelijke doch dringende brief (liever per post dan per e-mail) sturen naar de beheerder van de site met het verzoek deze materialen binnen een paar dagen weg te halen. Ga niet eisen dat alles direct moet worden weggehaald, of meteen dreigen met een rechtszaak. De rechter zal niet snel geneigd zijn een partij die zich onredelijk opstelt gelijk te geven. En om drie uur ‘s nachts een mailtje sturen met de opdracht onmiddellijk een bepaald plaatje te verwijderen is niet redelijk.

Reageert de andere partij niet, ook niet als je de brief per aangetekende post verstuurt, dan is de volgende stap de provider aanspreken. Veel providers hanteren de regel dat een webpagina wordt verwijderd als er een klacht over inbreuk op auteursrecht binnenkomt.

Een rechtszaak starten is een uiterste redmiddel. Dit is erg duur, en wordt niet gedekt door een eventuele rechtsbijstandverzekering. Conflicten omtrent intellectuele eigendom (en dat is het auteursrecht) zijn vrijwel altijd uitgesloten van dekking. Verder is er het probleem dat schade moeilijk aan te tonen zal zijn, zeker bij hobby sites beheerd door particulieren.

Aanbieden van bestanden zonder toestemming

Auteursrechtelijke problemen doen zich vaak voor bij mensen die MP3′s of software op een website aanbieden. Vrijwel altijd gaat het hier om aanbieden zonder toestemming van de rechthebbenden. Organisaties als de BUMA/Stemra, BREIN of de BSA zijn erg actief bij het zoeken naar dergelijke websites. De beheerders -en hun providers- kunnen dan op korte termijn een boze brief verwachten met de dreiging van een rechtszaak. Providers wachten dat meestal niet af en gooien de bestanden van de website (of sluiten simpelweg de hele site). De algemene voorwaarden bij het hosting contract staan dit vrijwel altijd toe.

Linken naar andermans werk

Een hyperlink is legaal, behalve in bijzondere situaties. Gebruik van frames of inline links, of het veroorzaken van overlast kan zo’n bijzondere situatie opleveren.

Een ander auteursrechtelijk probleem waar Web designers tegenaan kunnen lopen, is hergebruik van andermans werk. Het is mogelijk om in een website een afbeelding die op een andere server staat te presenteren als onderdeel van je eigen webpagina. Ook filmpjes en muziek bestanden kunnen op deze manier worden verwerkt in een website. Met behulp van frames is het zelfs mogelijk om gehele webpagina’s van derden als integraal onderdeel van je eigen site te presenteren. Hierbij wordt er niet gekopieerd, maar alleen een link gelegd naar het werk op die andere website.

Hyperlinken op zich is toegestaan. Bijzondere omstandigheden kunnen dat veranderen. Zo is het ‘framen’ van andermans site onrechtmatig als dat zonder toestemming gebeurt (Vriend/Batavus). Het dieplinken naar een afbeelding op andermans site kan worden gezien als inbreuk op het auteursrecht.

Ook los van auteursrecht kan de beheerder van die andere website een claim hebben. Wie schade lijdt door onrechtmatig handelen, kan eisen dat deze wordt vergoed door de pleger daarvan. Dat kan bij een hyperlink ook het geval zijn.

Als het gaat om hergebruik van een databank die op Internet wordt aangeboden, dan kan er sprake zijn van inbreuk op het databankenrecht.

Een niet-juridisch risico bij dergelijk hergebruik is dat de beheerder van die andere website de afbeelding kan vervangen door bijvoorbeeld een porno plaatje of een beledigende tekst. Het verstandigst is dus altijd om gewoon toestemming te vragen.

De domeinnaam

Gebruik van andermans merk (of een daarop lijkend woord) in een domeinnaam kan voor juridische problemen zorgen.

Een goede domeinnaam is van groot belang voor elke website. Je website moet immers opvallen tussen al die andere sites die over hetzelfde onderwerp gaan. Het lijkt dan slim om gebruik te maken van een bekend woord dat betrekking heeft op dat onderwerp, bijvoorbeeld de naam van een automerk bij een site over raceauto’s. Dit is echter niet toegestaan zonder toestemming van de houder van dat merk.

Er zijn al zeer veel rechtszaken gevoerd over gebruik van andermans merk bij een domeinnaam. Meestal won de merkhouder, tenzij de website duidelijk over een ander onderwerp ging en dus niets met het merk te maken had. Verzin dus liever een eigen, originele naam voor je website.

Ook het gebruik van andermans merk in zogeheten “meta-tags” (onzichtbare steekwoorden bedoeld voor zoekmachines) of het verkopen van “magneetwoorden” kan merkinbreuk zijn. Magneetwoorden worden bij zoekmachines gebruikt. Een Eindhovens hotel kan bijvoorbeeld het magneetwoord “hotel eindhoven” kopen bij een zoekmachine. Tikt iemand dat in bij die zoekmachine, dan krijgt hij een advertentie van dat hotel te zien. In de zaak VNU/Monsterboard werd het magneetwoord “intermediair” verkocht aan Monsterboard. VNU, eigenaar van het merk Intermediair, vond dit merkinbreuk, en kreeg van de rechter gelijk.

Octrooien

Wie zaken doet in of met de VS, moet rekening houden met de mogelijkheid van een octrooi op de software of e-commerce techniek die hij gebruikt.

Het is sinds een aantal jaar mogelijk octrooi te krijgen op e-commerce technieken en andere software-uitvindingen. Twee bekende voorbeelden zijn het met één druk op de knop bestellen van boeken van Amazon.com en het “noem je prijs” systeem van Priceline. Anderen mogen dit systeem niet toepassen in de landen waar het octrooi geldig is.

Nu geldt voor veel van dergelijke octrooien dat zij alleen in de Verenigde Staten geldig zijn. Het toepassen van een dergelijk techniek op een website die gehost wordt op een server die fysiek in Nederland staat, zou dus geen probleem moeten zijn. Amerikaanse rechters denken daar echter nog wel eens anders over, en redeneren dat het aanbieden van de techniek aan gebruikers in Amerika toepassen van de techniek in Amerika is.

Het is mogelijk dat er binnen organisaties sprake is van verschillende volwassenheidsniveaus.

Dit kan vooral het geval zijn bij grote multifunctionele organisaties waar verschillende onderdelen zelfstandig functioneren.

De volgende volwassenheidskenmerken spelen een rol:

Cultuur

De bedrijfscultuur bepaalt in grote mate het volwassenheidsniveau van een organisatie. Hier zijn boeken over vol geschreven, en dit valt duidelijk buiten te bestek van dit artikel.
Wat hier niet buiten valt is awareness, normen en standaarden voor bewustzijn en bewustwording, compliance methodieken en tot slot de mate waar een organisatie überhaupt over informatiebeveiliging discussieert. De uitspraak “soft skills are the organisation’s hardest diamonds” geeft aan dat cultuur als belangrijk volwassenheidskenmerk te boek staat.

Standvastigheid en mate van onzekerheid

Rond een project is het eindresultaat wat telt. Een organisatie kan hier een zekere onzekerheid over hebben, los van het niveau binnen de organisatie of de betrokken functie.
Motivatie van de organisatie als geheel of een deel daarvan dat binnen het project een rol speelt geeft een duidelijke draai aan de mate van standvastigheid. Niet gemotiveerd zijn van mensen rond informatiebeveiliging zorgt dat de koppeling naar het project niet gaat lukken.
Dit beïnvloedt het eindresultaat. De mate van onzekerheid rond het eindresultaat kan worden weggenomen door een risk assessment uit te (laten) voeren met sturing op fasering, de methodiek waarmee het project wordt aangepakt en bestuurd, de project organisatie en als laatste de verhouding tussen de voorbereiding en de uitvoering.

Projectonzekerheid kan op vier manieren geïdentificeerd worden:

Variatie, Voorziene onzekerheid, Onvoorziene onzekerheid, Chaos

Variatie is opgehangen rondom de meer traditionele aanpakken, terwijl chaos zich uit in aanpakken die ruimte bieden aan verandering.

Besturing

De mate waarin een organisatie controle heeft over haar informatiebeveiliging bepaalt in grote mate het volwassenheidsniveau. Hoe minder volwassen, hoe meer activiteiten noodzakelijk zijn om te zorgen dat de al eerder genoemde koppeling tussen informatiebeveiliging en het project slaagt. Bij controle past ook het kiezen van een juiste strategie voor het in balans krijgen en houden van projectvoorbereiding versus projectuitvoering.

Omvang

Een grote organisatie zal per definitie meer tijd hebben geïnvesteerd in het formaliseren van processen, het opstellen van regels en het doorvoeren van een procesgestuurde werkwijze voor informatiebeveiliging. De rol van de verantwoordelijk manager voor informatiebeveiliging, de security officer (CISO) en eventuele andere functionarissen is hierin van belang. Dit heeft een directe relatie met de projectorganisatie. Zal de CISO participeren hierin? Of juist niet? Twee petten dan? Hier moet goed over nagedacht worden.

Beleid

De aanwezigheid van beleid voor informatiebeveiliging is een belangrijk vertrekpunt voor een project waarin informatiebeveiliging een rol speelt. Het volwassenheidsniveau van een organisatie heeft een directe relatie met dit beleid. Hoe is het tot stand gekomen, en hoe wordt het bijgehouden? Is iedereen binnen de organisatie er van doordrongen dat er überhaupt beleid is? Het geeft aan in hoeverre er is nagedacht over informatiebeveiliging in termen van strategie, organisatie en tactische richtingen. Naarmate beleid en gerelateerde aspecten beter zijn uitgekristalliseerd zal een organisatie sneller en efficiënter informatiebeveiliging kunnen inbedden in een project. De manier waarop de organisatie omgaat met dit beleid is tevens bepalend voor het volwassenheidsniveau. Ofwel, er kan beleid voor informatiebeveiliging zijn, maar als daar niet op de juiste wijze mee wordt omgegaan (denk aan up-to-date houden), dan is dot eerder een negatief aspect dan positief. De wisselwerking tussen de projectorganisatie en de bestaande beveiligingsorganisatie speelt hierbij tevens een belangrijke rol.

Technologie

De mate waarop technologie is ingevoerd en beschikbaar is binnen een organisatie geeft aan hoe het bedrijf met informatiebeveiliging omgaat. Techniek is een logisch gevolg van een uitgezette koers voor informatiebeveiliging. Tenminste als het goed is. Dit aspect speelt en een rol bij het volwassenheidsniveau, maar nog meer binnen het inbedden van informatiebeveiliging in het project zelf. In de praktijk kan namelijk duidelijk worden dat de operationele techniek achterhaald is, niet werkbaar is of juist een extra verbeterslag moet doorlopen om binnen het project en later in de operationele processen juist te kunnen werken.

De match tussen eisen (requirements) voor techniek en het volwassenheidsniveau van een organisatie zijn cruciaal in het vaststellen van de wijze waarop deze technologie moet worden ingezet, zowel binnen het project als in een later operationeel stadium.

Complexiteit

Complexiteit heeft twee invalshoeken. De complexiteit van de organisatie zelf speelt een rol. Is het bijvoorbeeld mogelijk binnen een complexe procesgestuurde organisatie projecten los daarvan te laten functioneren? Vooral de wijze waarop het project zelf wordt aangevlogen door fasering, methodiek, projectorganisatie en de verhouding tussen voorbereiding en daadwerkelijk uitvoering is in grote mate afhankelijk van het volwassenheidsniveaus van de organisatie. Een volwassen organisatie zal projecten gestroomlijnd aanlopen. De complexiteit heeft tevens een relatie met security alignment. Als hiervoor duidelijk afspraken zijn gemaakt binnen het bedrijf dan zullen de projectkenmerken als fasering, organisatie en methodiek eenvoudiger in te vullen zijn.

Gezamenlijk bepalen de hierboven beschreven aspecten het volwassenheidsniveau van een organisatie en dus de mate waarop, snelheid en effectiviteit waarmee informatiebeveiliging in het project een rol krijgt toebedeeld en wordt ingebed.

Management support

De mate waarin het management (top management, hoger en middenmanagement van alle relevante organisatieonderdelen) het project ondersteund is essentieel in het slagen van het project. Zonder managementondersteuning kan een project maar beter gestopt worden. Het management is namelijk de aangewezen plaats om aanwezig potentieel in de organisatie te mobiliseren en in te zetten in een project [4]. Ondersteunt het management het project niet, dan komt er van de inzet van dit potentieel en het gebruik van beschikbare interne kennis niets terecht.

Dit artikel is een onderdeel van een expertbrief van het GVIB. Klik hier voor het volledige artikel.

Het is belangrijk om in een zo vroeg mogelijk stadium de eisen en wensen boven tafel te krijgen. Wijnen (Wijnen, 2004) onderscheidt een aantal categorieën projecteisen die kunnen dienen als geheugensteun:

• Randvoorwaarden
• Functionele eisen
• Operationele eisen
• Ontwerpbeperkingen

Randvoorwaarden vormen de context waarbinnen het project uitgevoerd moet worden. Voorbeelden hiervan zijn wetgeving, arbo-eisen, keurmerkeisen en dergelijke. Deze eisen zijn niet te beïnvloeden vanuit het project.

Functionele eisen zijn eisen die gaan over hoe goed het projectresultaat moet zijn. Bijvoorbeeld hoe energiezuinig een nieuwe auto moet zijn, of hoeveel kamers een nieuw gebouw moet hebben.

Operationele eisen gaan over de eisen aan het gebruik van het projectresultaat. Bijvoorbeeld dat na het realiseren van het softwareproject, het aantal storingen met 90% afneemt. Ontwerpbeperkingen tenslotte zijn eisen die te maken hebben met de realisatie van het project zelf. Bijvoorbeeld dat er in het project niet gewerkt wordt met giftige materialen, of niet gewerkt wordt met internationale leveranciers waarvan niet duidelijk is of ze kinderarbeid toepassen. Bij de ontwikkeling van een webapplicatie voor een consortium van grote organisaties was men vergeten in de definitiefase af te spreken welke browser ondersteund zou worden door de applicatie. Het consortium ging er vanuit dat dit Microsoft Explorer zou zijn, omdat die door ‘iedereen’ gebruikt wordt. De programmeurs maakten de applicatie in Firefox, omdat zij daar zelf mee werkten en omdat die een aantal functies had, die erg handig waren tijdens het ontwikkelen. Omdat de meeste websites gemaakt voor Firefox er ook wel goed uitzien in Explorer, viel het niet direct op, maar tegen het einde van het project begon de klant te klagen dat de website ‘er niet goed uitzag’. De programmeurs, die in Firefox keken, vonden natuurlijk dat de website er wel goed uitzag en begrepen de klacht niet. Toen het probleem van de twee browsers duidelijk werd, reageerden de programmeurs defensief:’ Kunnen ze geen Firefox installeren, dat is toch gratis’. De organisaties waren echter gebonden aan de bureaucratisch werkende systeembeheerders die om de een of andere reden, wellicht terecht, weigerden Firefox naast Explorer te installeren. Waar de systeembeheerders dat wel wilden, was het een langdurig traject en waren er ook extra kosten voor de tijd die de beheerders ervoor nodig hadden. Uiteindelijk werd er besloten dat de applicatie ook geschikt gemaakt moest worden voor Explorer. Dat was nog behoorlijk wat werk waardoor het project (nog meer) uitliep dan het al deed. Over de extra kosten moest onderhandeld worden. Toen bleek ook nog dat de verschillende organisaties met verschillende versies van Microsoft Explorer werkten…

Het is heel belangrijk dat alle betrokkenen in een project kunnen meedenken in de definitiefase. Vooral ook de eindgebruikers die het projectresultaat gaan gebruiken. Het komt vaak voor dat de eindgebruikers niet de opdrachtgevers zijn voor het project, wat wellicht de reden is dat ze vaak over het hoofd worden gezien. De opdrachtgever, die voor het project betaalt, wordt wel uitgenodigd om mee te denken over eisen en wensen in de definitiefase. Toch is het voor het eindresultaat veel belangrijker de toekomstige gebruikers uit te nodigen. Als uitgangspunt is het een goede gewoonte om in de definitiefase een aantal bijeenkomsten te organiseren met alle betrokkenen bij een project.

Bij de ontwikkeling van een educatieve videogame, werden de gebruikers (jongeren) pas in een laat stadium betrokken bij het project. Toen de game al nagenoeg af was, werd aan een groep jongeren gevraagd de game te testen. De jongeren leken aanvankelijk mild en vriendelijk in hun oordeel. Bij doorvragen bleek echter dat ze de game ‘eigenlijk ontzettend saai vonden en zeker niet gingen spelen’.

Waren de jongeren eerder in het project betrokken, dan was de game wellicht een succes geweest. Nu staat de game vrijwel onbezocht op een site op het internet.

Het resultaat van de definitiefase is een eisen- en wensenlijst van de diverse betrokken partijen bij het project. Nu is het natuurlijk zo dat elke eis en wens zijn keerzijde kent. Hoe mooier het project moet worden uitgevoerd, hoe meer tijd en geld het kost. Ook kan het zijn dat bepaalde eisen strijdig zijn. De ontwikkeling van een nieuw kopieerapparaat moet minder milieubelastend zijn, maar moet ook voldoen aan eisen aan brandveiligheid. Daarom moeten er volgens de norm brandvertragende, milieubelastende materialen gebruikt worden. Dat betekent dat er over sommige eisen en wensen onderhandeld moet worden.

Uiteindelijk zal er een definitieve eisen- en wensenlijst boven tafel komen die goedgekeurd moet worden door de beslissers over het project. Met dit goedgekeurde document kan de ontwerpfase starten. Met het afsluiten van de definitiefase wordt een belangrijk deel van de afspraken tussen klant en projectteam vastgelegd. De eisen- en wensenlijst vormt de richtlijn waar het projectresultaat aan moet gaan voldoen. Daar zal het projectteam op worden afgerekend. Het betekent ook dat de klant nu geen aanvullende eisen of wensen meer mag stellen.

Een deel van een nieuwe expositie van een museum bestond uit een computerinstallatie. Het maken van de installatie was een project. In dit project was er nooit een definitiefase geweest, zodat afspraken tussen het museum en de bouwers van de installatie niet duidelijk waren. Toen de computer van de installatie halverwege de expositie stuk ging, dacht het museum dat het onder de garantie van het project viel. Het projectteam dacht daar echter anders over. Overleg tussen directeuren was nodig om een regeling te treffen.

Klik hier voor het oorsponkelijke document op projectmanagement-training.nl.

1. Neem de rol aan van product owner

Belangrijk is de rol die de User Experience-professional inneemt in het project. Jeff Patton adviseert: “Als UX-professional neem je in de rol van product owner verantwoordelijkheid voor business goals. Product owners werken in het verleden, het heden en de toekomst. Ontwikkelteams werken enkel aan de huidige iteratie en zijn daarnaast hooguit bezig de vorige release te repareren.”

De product owner vervult veel rollen:

• Advocaat van de business: begrijpt de behoefte van de opdrachtgever en selecteert een mix van features die zijn doelen helpt bereiken.
• Advocaat van de klant: begrijpt de behoefte van de organisatie die het product koopt en selecteert een mix van features die waardevol voor hem zijn.
• Advocaat van de gebruiker: kan vanuit de gebruiker uitleggen waarom het product wel of niet voor hem werkt, en aangeven hoe hij het product wel wil kunnen gebruiken.
• Materiedeskundige: beantwoordt technische vragen over het ‘domein’ (o.a. gebruik, gebruiker, organisatie, markt) aan degenen die het product maken.
• Ontwerper: voegt business-, klant- en gebruikersbehoeften samen in een productontwerp dat voor iedereen bevredigend is. Bewaakt coherentie terwijl het product wordt gemaakt en uitgebreid.
• Communicator: is in staat om de visie achter en de bedoeling van het product te communiceren, daarmee helpen feature- en ontwerpbeslissingen te nemen.
• Besluitnemer: neemt bij conflicterende doelen, belangen en/of meningen, moeilijke productbeslissingen.

2. Word een ontwerpfacilitator

“Design isn’t something that designers produce, design is a process that designers facilitate.” – Leah Buley (Adaptive Path)

Idealiter denkt iedereen in je agile-team mee over ontwerp. Faciliteer het team daarin. Gebruik bijvoorbeeld workshops om:

• informatie te verzamelen en te analyseren;
• ontwerpideeën te vormen;
• anderen te betrekken in het ontwerpproces;
• onderzoek en kennis te delen.

“Design by community is not design by committee.” – Leisa Reichelt (Disambiguity)

Samenwerken in ontwerp betekent niet dat dat jij niet meer verantwoordelijk bent voor het ontwerp. Gebruik je team, klanten en gebruikers om informatie en inzichten te verzamelen en te betrekken in besluitvorming. Sommige beslissingen neem je als team, andere neem jij als ontwerper en product owner.

3. Onderzoek, modelleer en ontwerp vooraf, maar niet teveel

Ook in agile (Scrum)-projecten is er een stap die altijd voor de iteratieve ‘sprints’ komt: het definiëren van het productbacklog. Het productbacklog is de ‘masterlijst’ van alle gewenste functionaliteiten in het product. Bij de start van een agile-project wordt niet verwacht dat er  al een uitputtende lijst gemaakt kan worden. Agile gaat immers uit van voortschrijdend inzicht. Er wordt dan ook niet heel veel tijd in gestoken. Meestal worden de meest voor de hand liggende dingen opgeschreven, wat vaak al meer dan genoeg is voor de eerste sprint.

Dat neemt niet weg dat het maken van het productbacklog een fase op zich is, waar veel aandacht aan besteed moet worden. Dit is een ideaal moment om wat user research te doen en businessdoelen vast te stellen. Probeer ook een globaal beeld te vormen van de interactie die jij bij het product en de gebruikers vindt passen. Gebruik dit vervolgens allemaal bij het schrijven van de gebruikerscenario’s (user stories).

Denk ook alvast na hoe je in de rest van het project om wilt gaan met user / usability research.

4. Hak je ontwerpwerk in brokken…

…maar voorkom dat ontwerptijd in het gedrang komt. Dit kun je doen door ontwerpintensieve iteraties af te wisselen met ontwikkelintensieve iteraties.

Voor contentgedreven websites is dit een stuk lastiger dan voor de meeste applicaties. In applicaties zijn functionaliteiten vaak te relateren aan specifieke acties (knoppen, menu-items) en daardoor goed te isoleren. Bij veel websites dragen vaak veel pagina’s direct of indirect bij aan de conversie. Een gemiddelde contentpagina is een puzzelstukje in meerdere scenario’s. Hoe hak je dus het interactieontwerp van een website op in brokken? Een aanpak die ik zelf onlangs gebruikt heb, is beginnen met de basisbouwstenen van een site (structuur, navigatie en generieke functionaliteiten), en daarna pas één voor één onderdelen als home, nieuws en project uitwerken. Risico hierbij blijft natuurlijk dat je eilandjes ontwerpt in plaats van een coherente user experience, zoals ik in mijn eerste artikel al aangaf.

Patton adviseert: organiseer de user stories in een schema, beperk je niet tot alleen prioriteren. Een schema helpt het grote plaatje te blijven zien.

5. Werk parallel aan de huidige iteratie vooruit aan de volgende en evalueer / test de vorige

Bron: Case Study of Customer Input For a Successful Product, Lynn Miller

Bovenstaande afbeelding vat het mooi samen: in iteratie X, test iteratie X-1, ontwerp iteratie X+1 en doe alvast user research voor iteratie X+2.

6. Maak prototypes simpeler (‘low fidelity’) naarmate de samenwerking met ontwikkelaars intensiveert

Eigen ervaring: als je samenwerkt met een nieuwe outsourcing partij ergens in India of Jordanië, dan moet het functioneel ontwerp exact laten zien en beschrijven wat er gebouwd moet worden. Wat er staat, wordt letterlijk genomen, en wat er niet staat, wordt niet opgepakt. Omgekeerd is het wellicht overbodig om in detail te modelleren en beschrijven hoe een bepaald component zich moet gedragen als je naast de developer zit en continu overlegt over features.

7. Gebruik prototypes / wireframes voor discussie in plaats van specificatie

“Use wireframes as communication space, not as blueprints.” – Jeff Patton

Er gaat snel veel werk zitten in het schrijven van een functioneel ontwerp. Maar hoe lang na oplevering c.q. live-gang blijft het FO een goede blueprint? Sterker nog, hoe vaak worden er niet al tijdens de bouw- of stabilisatiefase van het project functionele wijzigingen aangebracht, die niet meer bijgewerkt worden in het FO?

Een agile-suggestie: schets de interface, hang het aan de muur en bediscussieer het met het team. Laat ze vragen stellen, notities maken en zelf annotaties toevoegen aan de schetsen. Zo krijgen ze precies de specs die ze nodig hebben en omdat ze het zelf (in hun eigen woorden) opgeschreven hebben, begrijpen ze de specs waarschijnlijk ook beter.

Uitdaging voor de projectmanager en klant: “Beoordeel het ontwerp niet op de documentatie, maar op het gevolgde proces.”

Sommige agile interactieontwerpers documenteren nog wel de historie van ontwerpbeslissingen, voor zichzelf of andere/volgende interactieontwerpers.

8. Organiseer continu user research in een eigen spoor, los van development

Als vervolg op punt 3: er was niet genoeg tijd om al het user research te doen voordat het development begon. Je hebt vast ook niet voldoende tijd per iteratie om de alle benodigde research voor de user story te doen. Misschien is het dus beter om user research zijn eigen tempo te laten volgen. Plan vaste (wekelijkse?) momenten in om user research te doen voor nog uit te werken functionaliteiten.

Het liefst werk je, ook tijdens de vaste momenten, met een groep gebruikers. Creëer een pool die groot genoeg is om niet iedere week met dezelfde gebruikers te hoeven zitten. Daarmee houd je gebruikersfeedback vanuit een frisse blik. Plan mensen wel ruim van tevoren in, zodat ze weten wanneer iets van ze verwacht wordt.

9. Combineer meerdere doelen als je met gebruikers zit

Je kunt de pool gebruiken voor zowel user research (vooraf) als usability testing (achteraf). Sterker nog: je hebt al niet veel tijd om je gebruikers te betrekken. Benut je tijd met gebruikers dus zo goed mogelijk door in dezelfde sessie:

• informatiebehoefte- en taakanalyse te doen;
• feedback te krijgen op ontwerpen in wording;
• feedback te krijgen op het werkende product (afgeronde sprints).

10. Test en optimaliseer de user interface ‘ultra’ iteratief

Hier heb ik zelf erg goede ervaringen mee. Voor mij is tijd met gebruikers meestal ook erg schaars. Sterker nog, ik zie ze in veel projecten alleen maar bij cardsorting of het testen van een ‘paper’ prototype. Waarbij paper tegenwoordig bij mij meestal een klikbaar prototype (gegenereerd door Axure) is. Deze usability tests duren vaak maar 1 dag, of soms twee keer een halve dag met een dag ertussen. Als na 2 testsessies evident is dat iets niet werkt, dan pas ik het ter plekke aan en compileer het op tijd voor de derde testsessie.

Ik vind het belangrijker om aan het einde van de dag een ontwerp te hebben waar tussentijds al belangrijke verbeteringen zijn doorgevoerd, maar dat zelf misschien alleen nog maar door de laatste 2 gebruikers getest is, dan een onderzoeksrapport waar keurig in staat hoeveel procent van de gebruikers tegen welk knelpunt aangelopen zijn.

Valkuil

Als laatste tip een kleine waarschuwing. Als je erg gericht bent op vooruit kijken en iteratief ontwerpen, is het gemakkelijk om in de valkuil te lopen van de evaluatiefase per cyclus overslaan. Inclusief usability testing. ‘Geen tijd’ is een slecht excuus. Als je alleen focust op zo snel mogelijk alles ontwerpen en bouwen, als je de backlog niet verandert, dan ben je niet met agile, maar met waterval bezig.

Klik hier voor het oorsponkelijke artikel op Frankwatching.com.

‘Scrummen’ is een manier van agile (‘vlug en lenig’) werken. Een project wordt opgedeeld in korte ‘sprints’ waarin steeds samen met de klant wordt gewerkt aan een concreet resultaat.

Wij hebben inmiddels veel ervaring opgebouwd met Scrum en andere vormen van Agile ontwerpen. In drie artikelen wil ik graag onze ervaringen delen en de basics van Scrum uiteenzetten. Mijn advies aan ontwerpers: just do it!

Scrum: wat heb je nodig?

Hieronder zie je een overzicht van het scrumproces. De totale hoeveelheid werk (product backlog) wordt ingedeeld in een aantal sprints. In dit artikel beschrijf ik de belangrijkste onderdelen van Scrum.

Het Scrumproces (bron: Wikipedia)

Scrum room

Scrum drijft op ad hoc-communicatie tussen de teamleden. Het hele team zit daarom in één ruimte. Altijd. Zelfs één deur tussen twee teamleden decimeert de communicatiebandbreedte tussen die twee teamleden!

Onze ervaring

De Scrum room…

• … hoeft niet dedicated te zijn, dus er mogen niet-projectleden bij zitten. Maar een Agile Design project maakt veel lawaai, dus aan te raden is het niet.
• … moet veel muurruimte hebben. Eén van de belangrijkste pijlers van Scrum is: maak het fysiek. Werk op papier. Werk je op de computer? Haal alles eruit, hang alles op. Schrijf en corrigeer op de prints, zodat iedereen het ziet.
• … moet een ruime voorraad pennen, papier, post-its in alle kleuren en Scotch invisible tape bevatten.
• … moet echt VAN het team zijn. Maak het eigen. Ja, hang die poster van Jakob Nielsen maar op. Don’t be shy.

Soorten sprints

Scrum gebruikt een projectopdeling in ‘sprints’. Een sprint duurt tussen 2 en 4 weken, met 3 weken als duidelijk optimum. Fabrique onderscheidt deze sprints:

• Sprint 0 – De eerste sprint, die als ‘kwartiermakersfase’ zou kunnen worden gekenmerkt. Alle benodigde aanleveringen worden gedaan, research wordt gedaan, persona’s en scenario’s worden opgesteld, en er wordt een redelijk precieze omschrijving van de scope van het project gemaakt. In Scrum heet dat laatste de product backlog.
• Zelfgereguleerde sprints – Soms plannen we een aantal gelijkvormige sprints achter elkaar. Deze sprints zijn communicerende vaten. Het team bewaakt zijn eigen voortgang (velocity) per sprint, en stuurt -indien nodig- bij. Dit is de klassieke Scrum aanpak.
• Fixed deliverable sprints – Het kan handiger zijn om elke sprint een vast resultaat te geven, zoals een tak van een website, of verschillende middelen.
• Split sprints – in dit sprinttype zijn in één ruimte twee scrum teams tegelijkertijd bezig: een design team en een software-ontwikkelingsteam. Daily scrums zijn gezamenlijk, maar het ontwikkelaarsteam loopt één sprint achter, en bouwt wat het design team in de sprint ervoor heeft ontworpen. Ja, “au”. Maar het werkt.
• Sweep sprint – Soms is het handiger om het rework op sprintresultaten niet meteen te doen, maar al het rework te verzamelen in één laatste sprint.

Onze ervaring

• Fixed deliverable sprints is de meest laagdrempelige vorm om mee te beginnen. De fixed deliverables geven houvast en zorgen dat je je geen zorgen hoeft te maken over ingewikkelde zaken zoals velocity, of een grote homogene product backlog. De meeste van onze Agile projecten hebben fixed deliverable sprints.
• Agile projecten mèt ontwikkeling zijn bij ons split sprints. We hebben geprobeerd om ontwerp en ontwikkeling in één sprint te vatten, maar het is om allerlei redenen heel lastig, zo niet onmogelijk, om het efficiënt te laten gebeuren. Het doet pijn om zo’n waterval te moeten laten bestaan, maar uit rondvraag blijkt dat ook anderen met hetzelfde probleem zitten. Jammer!
• Toch streven we er nog steeds naar om split sprints te voorkomen. We proberen nog verschillende dingen uit, bijvoorbeeld eerder prototypen, of tweetallen maken van ontwerper en programmeur.

Product backlog

Elke sprint bestaat uit meerdere stories. Een story is een herkenbare, min of meer op zichzelf staande eenheid in de sprint. De verzameling van alle stories over het hele project, heet de product backlog. Hier zie je de product backlog van het Allerhande project voor Albert Heijn. De items worden ingedeeld in drie groepen, van grof idee naar ready for sprint. Terwijl de sprints vorderen, zorgt de product owner (de klant) er samen met de scrum master voor dat de product backlog gevuld blijft, en dat de stories snel genoeg concreet worden. Een story is ready for sprint als er genoeg input voor aanwezig is, en er een redelijk heldere inschatting gemaakt kan worden van de bijbehorende ontwerp- en ontwikkelinspanning.

TIP: Besteed met een deel van het agile team iedere dag 10 minuten om stories te concretiseren, en zo de volgende sprint voor te bereiden.

User stories

Een story is geredeneerd vanuit een user benefit, en ziet er bijvoorbeeld zo uit:

As a user I want to see all previous orders so that I can easily reorder.

Het is belangrijk dat je met echte verhalen werkt, omdat je dan veel duidelijker de user benefit voor ogen hebt. Door een story wordt duidelijk waarom we een bepaalde feature willen. Stories dwingen de klant ook om na te denken over waarom zij een bepaald feature willen.

Het is goed om duidelijke afspraken te maken wanneer een story klaar is, om tegenvallers aan het eind van de sprint te voorkomen. Hiernaast zie je een voorbeeld van een Definition of Done-blad.

Onze ervaring

In sommige situaties kunnen klassieke user stories uitlopen op semantische discussie en onenigheid tijdens de sprint over hoe die user need beantwoord moet worden. In die gevallen zien stories er daarom zo uit, bijvoorbeeld:

• Layout en navigatie
• Homepage
• Product detailpagina
• Ingewikkelde functionaliteit X

Tasks

Elke story wordt voor aanvang van de sprint opgesplitst in taken. Typische taken zijn:

• Wireframe schets
• Business rules opstellen
• Bellen met X
• Paper prototypen & testen

Zolang taken nog niet worden uitgevoerd, hebben ze geen eigenaar. De teamleden kiezen zelf welke taken ze gaan uitvoeren en voegen dan hun naam toe aan de taak.

Scrum board

Het Scrum board geeft het grote overzicht over alles wat nog gedaan moet worden, en al gedaan is. Hiernaast zie je een aantal voorbeelden van scrum boards. Een goed onderhouden scrum board is meer waard dan duizend Excel sheets!

De belangrijkste onderdelen van het scrum board zijn:

• Stories en tasks statusgebied – Welke tasks zijn nog in voorraad, welke zijn checked out (‘wordt op dit moment aan gewerkt’), en welke zijn done.
• Burndown chart - De tijdens de daily sprint besproken voortgang wordt aan de hand van de eerder gedane schattingen omgezet in een aantal dagen. Dit wordt van de werkvoorraad afgetrokken, en zo ontstaat een mooie rechte lijn naar beneden.
• Unplanned items – Gebruik je hoofd niet om te onthouden. Bedenk je iets dat “ook nog moet gebeuren” maar dat nog nergens is opgeschreven? Maak een post-it en plak hem bij de unplanned items. Scrum master of projectleider zorgen ervoor dat ze in de workflow een plek krijgen.
• Evaluatieblad – Scrummen is leren, ieder project, iedere dag opnieuw. Na iedere sprint, maar vaak ook al tijdens de daily scrum, kijken we wat er beter kan, wat al beter gaat, en wat helemaal top gaat.

Onze ervaring

Sommige scrummasters vinden het handig om een extra kolom in het statusgebied toe te voegen: keuring door product owner. De product owner, meestal de klant, ziet dan welke taken op zijn keuring wachten. Hij of zij kan ze bespreken en vervolgens naar rechts (done) of naar links (checked out) verplaatsen.

Klik hier voor het oorspronkelijke artikel op Frankwatching.com

Design versus development

De toepassing van agile in de designwereld is nog vrij nieuw. Lang niet iedereen is ervan overtuigd dat er überhaupt een rol voor ontwerpers is weggelegd in agile. Agile is ontstaan in de software-wereld als agile development. Het is een ‘conceptueel raamwerk’ met daarbinnen een aantal methodieken, waaronder scrum.

Veel van wat er over agile wordt geschreven en gezegd is nog steeds sterk beïnvloed door de afkomst uit de software ontwikkelaars-hoek. Uit veel publicaties blijkt een moeizame relatie tussen ontwerpers en developers in agile methoden, verrassend genoeg nog moeizamer dan bij de ‘waterval-methode’, waarbij ontwikkeling volgt op het ontwerp. Velen, zoals David Farkas, Jonathan Arnowitz en Marc Sasinski berusten daarom in een subtiele scheiding van User Experience Design en Agile development.

Onze ervaringen tonen echter aan dat de methode heel goed toegepast kan worden op het ontwerpproces. Daarbij onderscheiden we twee ambitieniveaus:

1. Integratie ontwerpers en klant. De ontwerpende disciplines en de klant werken gelijktijdig in één team. Dit is dus een agile project zonder ontwikkelaars in de kern van het team. Dat noem ik agile design.
2. Integratie van alle disciplines, inclusief ontwikkelaars. Dit is wat ons betreft nog steeds de heilige graal van agile: volledige integratie. Ook op dit vlak hebben we ervaring opgedaan.

What the f*ck is scrum?

Scrum is een vorm van agile werken. In feite is scrummen het samen duwen en trekken aan één project. Het hele proces is opgeknipt in kortlopende ‘sprints’ met strakke deadlines en duidelijke doelen. Interactieontwerpers, visueel ontwerpers en webontwikkelaars zitten niet rustig te wachten tot de ander klaar is, maar sprinten tegelijkertijd naar hun doel.

Scrummen gaat gepaard met speciale rituelen en technieken. De dagelijkse ‘daily scrum’ bijvoorbeeld, een staande bespreking van maximaal 20 minuten. Om ongestoord te kunnen scrummen en de samenwerking te intensiveren werkt iedereen samen in één scrum room.

Hoe pakken wij scrum en agile design aan?

De belofte van agile

Agile design heeft voor ons en voor onze klanten de volgende voordelen:

1. Het is snel en de leverzekerheid is groot: op tijd én binnen budget.
2. Ideeën, schetsen, twijfels, afspraken, alles wordt zonder drempel uitgewisseld.
3. Het project heeft een zelfsturend karakter. Het team is zelf de drijvende kracht.
4. Doordat zomin mogelijk informatie in computers blijft hangen, is het overzicht voor iedereen binnen oogopslag te krijgen.
5. Er is een veel intensievere en effectievere band tussen opdrachtgever en bureau. Read my lips: No More Foam Boards!
6. Door deze voordelen is de kwaliteit van het eindproduct hoger.

Waar zit de catch?

1. Agile is niet goedkoper, voor wie dat verwachtte. De kosten zijn vergelijkbaar met de ‘watervalmethode’.
2. Aanwezigheid van de klant in het ontwerpteam is essentieel.
3. Agile vraagt veel van de openheid van de teamleden en de klant. Een agile team zou, om maar wat te noemen, ook relaxed een paar uur met elkaar in de kroeg moeten kunnen hangen.
4. Agile projecten vragen veel energie. Wat doe je op de niet-scrumdagen? En wat gebeurt er met je bureauplanning als al je projecten agile zijn?

So here we are…

Dave Kelly, IDEO

Agile design is ook voor ons nog een ontdekkingstocht. Maar de paradigmaverschuiving heeft zich voor ons al voltrokken. De centrale vraag is voor ons niet: “Hoe kan ik agile development combineren met mijn ontwerpproces” maar “Hoe kan ik agile toepassen op mijn ontwerpproces?”

Agile is niet het exclusieve speeltje van developers, waarbij ontwerpers aan de kant mogen meekijken. Move over, developers: designers are here to stay!

Klik hier voor het volledige artikel op Frankwatching.com.

Scrum team

Een scrum-team is multidisciplinair, maar hoeft niet groot te zijn! Het grootste scrumteam waarmee we ooit gewerkt hebben was 12 man groot, inclusief ontwikkelaars, het kleinste scrumteam bestond uit 3 man.

Een scrum-team bij Fabrique bestaat doorgaans uit deze leden:

• Product owner – dit is doorgaans de klant. Eén of meerdere stake holders vanuit de klant kunnen eigen aandachtgebieden verzorgen, zoals design acceptatie, business rules, content, organisatie klaarstomen. Zie ook de notitie onder ‘onze ervaring’!
• Interactieontwerper – de interactieontwerper speelt de rol van architect, integrator, uitwerker, tekenaar.
• Visueel ontwerper – de visueel ontwerper voegt communicatie toe en onderhoudt nauwe banden met de klant over de karakteristieken van de content.
• Software ontwikkelaar / technisch architect – de software ontwikkelaar bekijkt samen met de ontwerpers de user stories en geeft in een vroeg stadium mogelijkheden en grenzen aan. Hij of zij implementeert het ontwerp en bespreekt design issues.
• Copywriter (short copy / editorial) – De copywriter heeft, naast z’n eigen deliverables, veel ad-hoc contact met het hele team om het product te voorzien van pakkende copy, heldere inleidingen et cetera.

Naast de vaste teamleden is er een aantal rollen in te vullen:

• Scrum master – de scrum master houdt het proces in de gaten. Moet over veel procescreativiteit beschikken en is een drijvende kracht. Hij/zij spreekt alle teamleden aan op hun verantwoordelijkheid. In sommige gevallen is hij of zij ook verantwoordelijk voor kwaliteitborging, als art director of interaction director. Eén van de teamleden neemt de rol van scrum master aan.
• Stake holder – Deze belanghebbenden kunnen op sleutelmomenten aanschuiven, input geven of ontwerpen bekijken. Een stake holder kan vanuit de klant aanschuiven, vanuit het bureau, of vanuit een andere partij, zoals een implementatiepartner. Voorbeelden van stake-holders:
  • Specialisten op het gebied van marketing of middelenmix, SEO, Usability testing
  • Kwaliteitbewaking in de vorm van een director, of tester
  • Account manager van het bureau
• Projectleider – Hoe beter Agile loopt, hoe meer de projectleider op de achtergrond kan blijven. Hij of zij regelt capaciteit, faciliteiten, afspraken, en budgetmonitoring.

Onze ervaring: product owner

• Volgens de klassieke regels van de Scrum maakt de product owner geen deel uit van het Scrum team. In mijn ervaring is dat vaak juist wel een heel effectieve werkwijze. De klant heeft tenslotte eigen taken. Het Scrum proces helpt ook hem om voortgang te boeken. We slagen er meestal in om de klant in het team op te nemen.
• Aan de andere kant: de opdrachtgever altijd in de buurt is niet altijd een zegen. Sommige opdrachtgevers zitten je heel erg op de huid, zoomen enorm in op details waar ze graag uren over praten, of worden heel zenuwachtig van het ontwerpproces zelf, waarin soms 80% van het resultaat ontstaat in de laatste 20% van de tijd. In zulke gevallen is het beter om de opdrachtgever tweemaal per week een dagdeel langs te laten komen. Minder krachtig, maar nog steeds beter dan waterval.
• Als de klant geen product owner ter beschikking kan stellen dan kan het bureau er één aanwijzen. De rol is te vergelijken met die van een projectleider of accountmanager, hij of zij schippert dan tussen de interne en externe belangen en voorkeuren.

Onze ervaring: pro-actief team

• Een cruciaal punt is dat alle teamleden over hun eigen discipline heen moeten kunnen werken, anders zou een miniwaterval binnen een sprint kunnen ontstaan, of teveel dependencies, wat tot wachtende teamleden leidt. Gooi je pet in het midden. Loop naar het task-board, kijk wat je kunt doen.
• Voor het hele scrum-team geldt tenslotte dat het sociaal nogal onverschrokken moet zijn. Daarin schuilt misschien wel het moeilijkste van Scrum: het proces faciliteert het meten van voortgang, maar eist tegelijkertijd veel initiatief van alle teamleden. Met name de scrum master moet man en paard bij naam durven noemen, mensen op hun intenties en afgegeven schattingen wijzen en hen af en toe met kracht uit hun comfortzone kunnen trekken.

Overleg

Het sluitstuk in dit drieluik gaat over overleg. Zoals ik hierboven al schreef: tijdens elke sprint vindt er doorlopend overleg plaats. Toch is een aantal vaste typen overleg essentieel.

Overleg: Sprint planning meeting

Tijdens de sprint planning meeting worden alle stories van die sprint gesplitst in taken. Vervolgens worden alle stories door het team gezamenlijk ingeschat in een proces dat ook wel bekend staat als ‘planning poker’. De product owner (meestal de klant) is als eigenaar van de product backlog uiteraard aanwezig bij deze bijeenkomst en oppert eigen taken

Aan het eind van de sessie worden de stories gezamenlijk op prioriteit geordend en overgebracht naar het scrum board. De product owner heeft het laatste woord over de prioriteitstelling.

Onze ervaring: planning poker met de klant

Hoewel de scrummethode zegt dat de product owner niet deelneemt aan de planning poker, is het onze ervaring dat dit wel zin heeft. Als de product owner met sterk afwijkende schattingen komt, is het interessant het waarom daarvan te achterhalen. Heeft hij eerdere ervaringen? Meer kennis van het product? Verwacht hij dat juist dit onderdeel een spetterende RIA wordt?

Daily scrum

Een daily scrum wordt altijd staande gehouden, en duurt maximaal 20 minuten. De teamleden vertellen één voor één wat ze de voorgaande dag gedaan hebben, en ze bepalen in een tweede rondje welke taken ze op zich nemen voor de komende dag. Ook wordt besproken wat de dependencies zijn, de onderlinge afhankelijkheden. Inhoudelijke discussies worden gesignaleerd, maar voor later bewaard.

De daily scrum is voor de scrum master een belangrijk dagelijks meetmoment van voortgang en team-attitude.

Onze ervaring: tweede stand-up

Met name bij geïntegreerde development sprints kan het zinnig zijn om op een vast moment, later op de dag, een tweede stand-up te houden waarbij je in 10-15 minuten naar de laatste stand van het gebouwde product kijkt. Zo geef je iedereen gelegenheid om zijn feedback te geven op het product (het héle team moet achter hetgeen staan dat je oplevert) en kun je de laatste puntjes op de i spotten.

Overleg met de klant

De communicatie met de klant is in Agile Design radicaal anders. Hij of zij is in het scrum team aanwezig als product owner, doet volop mee aan discussies over het ontwerp en over het proces. Dit heeft als effect dat presenteren eigenlijk niet meer nodig is. De kennis van het wat en waarom van het ontwerp is gemeenschappelijk ontstaan.

De product owner vertegenwoordigt alle stakeholders aan klantzijde, wiens inzichten in het project meegenomen moeten worden. We verwachten wel van de product owner dat hij of zij uiteindelijk beslissingsbevoegd is.

Product demo

Aan het eind van elke sprint wordt het product gedemonstreerd. Omdat de klant tijdens de hele sprint aanwezig was, grijpen we de demo vaak aan om bijvoorbeeld een stuurgroep mee te nemen in de projectvoortgang. Eventuele opmerkingen worden meegenomen als story in de volgende sprint, of liever nog in de sprint daarna.

Onze ervaring: sprintresultaat

In de klassieke Agile/Scrum methode is het resultaat van een sprint altijd een werkend product of een deel daarvan. In onze Agile Design interpretatie kan het product van alles zijn, zolang het maar een herkenbaar en afgesproken deliverable is van het project:

• Een werkend product of een deel daarvan
• Een klikbaar prototype
• Een set ontwerpen en documentatie

Retrospective

Elke sprint wordt afgesloten met een retrospective. De retrospective werkt voor ons echt als een afsluiting van de sprint waarin we de gang van zaken in de vorige sprint evalueren, en waarin iedereen zijn hart kan luchten. Lessen worden opgeschreven en aan het scrum-board toegevoegd. Hierna zijn we als team weer helemaal klaar voor de volgende sprint.

Onze ervaring: retrospective

Uit planningsoverwegingen en de deadlinesfeer aan het eind van een sprint, komt het wel eens voor dat we de sprint planning meeting (de aftrap van een sprint) openen met een korte retrospective. Hoe begrijpelijk dit ook is, een retrospective doe je aan het eind van de betreffende sprint, niet aan het begin van de volgende. In onze ervaring wil je zo min mogelijk ‘staartjes’ van de vorige sprint in een nieuwe sprint: dat vertraagt en vertroebelt.

Scrum is not the silver bullet

Stel je voor dat je er zit: scrum room ingericht, zorgvuldig een team samengesteld, alle rollen benoemd (en vervolgens het interdisciplinaire onderstreept), drie kilo post-its klaar voor de strijd. Waar moet je dan nog op letten?

Juist dankzij de vergaderrondjes, post-its, bijhouden van de scrum room enzovoorts, kan er een gevaarlijk effect optreden, dat ik het “in-slaap-sus-effect” noem. Het ziet eruit dat je lekker bezig bent, de post-its verschuiven, de burndown chart gaat mooi naar beneden, maar ondertussen blijft er veel onzichtbaar werk liggen. Losse eindjes waar je je ogen liever voor sluit. Taken die net wat te snel naar “Klaar” zijn gegaan. De documentatie die net wat té bondig is opgesteld. Deze zaken zullen je in de volgende sprint opbreken. De juiste team-attitude en een scherpe scrummaster kunnen dit voorkomen.

Top tien aandachtspunten bij scrum

1. Creëer een sprintsfeer. Een voortkabbelende sprint is…geen sprint.
2. Wacht niet. Nooit. Loop naar het scrum board, pak een taak op. Beperk je daarbij niet tot de taken die bij “jouw” discipline horen.
3. “Definitief” materiaal is niet altijd nodig. Werk met wat je hebt.
4. Definieer “done” en stick to it.
5. Let goed op de beslissingsbevoegdheid van de product owner. Is die te gering, dan werk je op drijfzand.
6. Werk fysiek. Schets, print uit. Maak foto’s.
7. Bespreek resultaat maar geef elkaar de ruimte. Wees daarbij niet bang om over een “andere” discipline te praten.
8. Benoem fuck-ups. Neem geen blad voor de mond.
9. Vrees niemands input. Haal criticasters juist binnen.
10. Vier successen, groot en klein.

Door Pieter Jongerius, klik hier voor het oorspronkelijke artikel op Frankwatching.

De focus op “rechtsgeldigheid” heeft me altijd verbaasd. Er is nooit discussie geweest of bijvoorbeeld een mondelinge toezegging rechtsgeldig zou zijn. Afspraak is afspraak, zeggen juristen dan. Alleen bewijzen wat er mondeling is afgesproken, ja dat is lastig. Maar bij e-mail schiet ineens iedereen in een juridische stuip want oh jee zou de rechter dat niet categorisch afkeuren omdat het triviaal vervalsbaar is?

Ik vermoed dat dit te maken heeft met een vaag onthouden discussie over de rechtsgeldigheid van faxen. Daar was de vraag of een faxbericht geaccepteerd mocht worden als akte, of dat echt alleen het origineel voor dat doel geschikt was. Ja, ook de akte telt in die situatie, bepaalde de Hoge Raad begin jaren negentig. Een faxapparaat produceert een letterlijke kopie, en indien gewenst kan het papieren origineel altijd worden opgevraagd en vergeleken. Misschien is daaruit het idee ontstaan dat een elektronisch document alleen rechtsgeldig is wanneer er ook een papieren origineel is.

Die rechtspraak ging echter specifiek over ‘aktes’, ondertekende geschriften die bedoeld zijn als bewijs van bijvoorbeeld een koop of erkenning van een schuld. Daarvan eist de wet inderdaad dat ze schriftelijk zijn, maar sinds een paar jaar kan dat ook elektronisch. Het grote probleem bij elektronische akten zit hem dan ook meer in de handtekening, want een elektronische handtekening zetten is een heel gedoe.

Wanneer de wet geen akte eist, dan mag alles als bewijs worden gebruikt. De rechter kijkt niet naar het middel waarin dat bewijs vervat zit, maar kijkt naar wat het bewijs bewijst. Pas als er iemand gaat roepen dat het bewijs vervalst is, dan wordt er gekeken naar hoe waarschijnlijk dat is in dit geschil. Je komt dus niet ver met “dit is mail, iedereen weet dat dat te vervalsen is” – nee, je moet bewijzen dat deze mail vervalst is.

Ook in strafzaken is het geen probleem om e-mail als bewijs te gebruiken. Daar ligt het iets lastiger, want de wet (art. 339 Strafvordering) noemt een beperkt aantal bewijsmiddelen en “e-mail” staat niet in die lijst. Er staat wel “schriftelijke bescheiden”, en dit mag volgens de Hoge Raad worden gelezen als “zolang er maar letters te zien zijn”. Een spandoek en sms-bericht zijn “schriftelijk” verklaard volgens dat oordeel, en e-mail valt er natuurlijk ook onder. In de strafrechtspraak hebben rechters dan ook weinig moeite met bijvoorbeeld bedreigingen per e-mail “schriftelijk” noemen.

Bij digitalisering van officiële stukken gelden er soms ook nog specifieke regels. Als een proces-verbaal schriftelijk moet zijn, mag men dit dan als gescande PDF opslaan en het originele stuk papier shredden? Daar zijn de geleerden het geloof ik nog niet over eens.

Maar in de dagelijkse praktijk durf ik met stelligheid te zeggen: ja e-mail is rechtsgeldig. Waar de meeste mensen e-mail voor gebruiken, gelden geen specifieke regels over het middel e-mail als zodanig. Een koop gesloten per e-mail is rechtsgeldig. Een mededeling per e-mail mag je de rechter laten lezen, en die mag daaruit conclusies trekken. Een e-mail met strafbare inhoud mag je aan de politie geven, en die kan daarmee een strafrechtelijk onderzoek opstarten. En uiteindelijk kan de afzender veroordeeld worden voor het versturen van die mail.

En dat e-mail triviaal te vervalsen is, is volstrekt irrelevant.

1. Projectleden/projectteam
   De projectleden zijn de teamleden in het project. De mensen die het project daadwerkelijk uitvoeren en die taken hebben binnen het project. Vaak hebben teamleden verschillende expertisegebieden. Teamleden kunnen intern zijn (eigen personeel) en/of extern (van projectpartners, klanten, gebruikers of ingehuurd personeel).
2. Projectleider
   De projectleider is diegene die het projectteam aanstuurt en de eindverantwoordelijkheid heeft over het projectresultaat. Afhankelijk van hoe het wordt afgesproken, kan het natuurlijk zo zijn dat de projectleider verantwoordelijkheden delegeert aan teamleden en/of dat externe managers de verantwoordelijkheid hebben over een onderdeel van het project.
            Binnen cyclische projecten behartigt de projectleider zowel de belangen van de klant als de programmeurs. Hij zorgt ervoor dat de klant voldoende technische uitleg krijgt en helpt de klant met het kiezen en prioriteren van functionaliteiten.
3. Projectmanager
   De termen projectleider en projectmanager worden vaak door elkaar gebruikt. Gebruikelijk is dat een projectmanager meerdere projecten leidt en een projectleider vaak maar één. De projectleider bevindt zich dan ook vaak ‘dichter op de werkvloer’ dan een projectmanager, die zich doorgaans meer met sturing en cijfers bezighoudt. Andere betekenissen en afbakeningen komen ook voor en de termen worden vaak door elkaar gebruikt.
4. Programmamanager
   De programmamanager is diegene die een aantal projecten in een organisatie beoordeeld. Aan hem rapporteert de projectleider/projectmanager. Vaak is de programmamanager lid van het management team.
5. Klant
   De klant is de partij die het projectresultaat besteld heeft. Hij of zij kan actief in het project deelnemen of meer afstand houden. De klant is soms ook de gebruiker van het projectresultaat maar dat is niet altijd het geval. Stel dat een universiteit een webapplicatie wenst voor zijn medewerkers en studenten, dan is de universiteit de klant en zijn de medewerkers en studenten de gebruikers.
6. Gebruikers
   De gebruikers zijn diegenen die het projectresultaat gaan gebruiken.
   Het is belangrijk om deze mensen te betrekken in de definitiefase, ontwerpfase en bij het testen van het project.
7. Projectpartner
   De projectpartner is een derde partij (organisatie) waarmee het project wordt uitgevoerd. Wanneer er meerdere partijen deelnemen aan het project is het uiteraard belangrijk om de verantwoordelijkheden en taken goed af te bakenen.
8. Opdrachtgever/klant/sponsor
   De partij(en) die het project financieel mogelijk maakt. Dit is vaak (maar niet altijd) ook de partij die het projectresultaat gaat gebruiken. De opdrachtgever zorgt voor de financiering van het project en is derhalve ook de partij aan wie verantwoording wordt afgelegd over het projectresultaat.

Klik hier voor het oorspronkelijke artikel op projectmanagement-training.nl.

1. Functionaliteitenaanwas
   Functionaliteiten aanwas is het fenomeen dat naarmate het project vordert, er steeds nieuwe functionaliteiten bij bedacht en gevraagd worden. Hierdoor komt de software nooit af.
2. Goudranden
   Goudranden is het fenomeen dat programmeurs en designers allerlei details van de software of ontwerpen te mooi willen maken. Er wordt veel tijd gestoken in het verbeteren van details, terwijl die verbeteringen niet gevraagd zijn door de klant of opdrachtgever. Vaak voegen de details weinig toe aan het gewenste resultaat.
3. Kwaliteitscontroles overslaan
   Door tijdsdruk komen programmeurs of projectteams wel eens in de verleiding om het testen over te slaan. Dit leidt vaak tot meer vertraging dan de tijd die bespaard is met het overslaan van de test. Hoe langer het duurt dat een fout wordt gevonden in software, des te exponentieel meer tijd het kost om hem te herstellen.
4. Te optimistische planningen
   Een te optimistische planning leidt tot veel druk op het projectteam. Het team zal aanvankelijk trachten de (niet reële) deadlines te halen. Hierdoor wordt er slordig gewerkt en zullen er meer fouten gemaakt worden, die weer tot vertragingen leiden.
            Wees in dit kader vooral beducht op het van bovenaf opleggen van planningen. Soms wordt de wens een project snel(ler) af te ronden vooral ingegeven door strategische motieven, maar als dat niet redelijkerwijs kan, moet dat ook niet geprobeerd worden. Het zal er niet sneller door gaan en het uiteindelijke product zal er niet beter van worden.
5. Werken aan veel projecten tegelijk
   Door het werk te versnipperen over veel verschillende projecten (of andere taken), ontstaan er wachttijden waardoor projecten veel vertraging oplopen.
6. Slechte ontwerpen
   Het ontbreken van, of slecht uitgevoerde ontwerpen, leidt tot vertragingen omdat er dan in een later stadium veel revisies nodig zijn.
7. Het ‘oplossing-voor-alles’ syndroom
   Het gebruiken van de juiste software voor een project is belangrijk. Het ene softwareplatform is beter geschikt voor bepaalde toepassingen dan het andere. Het is echter een valkuil om te denken dat het gebruiken van bepaalde software tot hele grote productiviteitsverbeteringen leidt.
8. Onderzoeksgeoriënteerde projecten
   Projecten waarbij software gemaakt moet worden én onderzoek gedaan wordt, zijn moeilijk te managen. De onzekerheden van het onderzoek zijn heel groot. Onduidelijk is wanneer en of er voortgang geboekt zal worden bij het onderzoek. Wanneer de software ontwikkeling afhankelijk is van onderzoeksresultaten, komt deze regelmatig stil te liggen.
9. Matig personeel
   Personeel dat onvoldoende bekwaam is, zal het project vertragen. Daarbij speelt niet alleen de technisch inhoudelijke kennis over het projectonderwerp een rol, maar ook de kennis en vaardigheid om met elkaar het spel van het project te spelen.
10. Klant komt afspraken niet na
    Klanten realiseren zich niet altijd dat van hen een behoorlijke bijdrage gevraagd wordt als ze een project laten uitvoeren. Waneer een klant niet of niet op tijd reageert op de onderwerpen waar hij bij moet meedenken, komt het project stil te liggen. Of erger, het team gaat verder zonder dat er goed meegedacht is door de klant, wat later weer tot conflicten kan leiden.
11. Spanning tussen klant en ontwikkelaars
    De spanning die kan ontstaan tussen klant en ontwikkelaars, bijvoorbeeld omdat het project niet snel genoeg verloopt, leidt zelf ook tot meer vertraging omdat de benodigde vertrouwensbasis en werksfeer verstoord is.

Klik hier voor het oorspronkelijke artikel op Projectmanagement-training.nl.

Coördinatie van projecten

In eerdere hoofdstukken is beschreven dat de GOKIT factoren de parameters zijn waarop projecten gerapporteerd en gestuurd worden. Ook bij het afstemmen van meerdere projecten spelen deze GOKIT factoren weer een belangrijke rol:

Geld: om te zien of projecten financieel mogelijk zijn
Organisatie: om onderlinge afspraken te maken over de hiërarchie tussen projecten onderling en projecten en de overige afdelingen
Kwaliteit: om te zien of de doelstellingen van een project passen binnen de strategie van de organisatie
Informatie: Om af te spreken hoe, wat en wanneer er gerapporteerd wordt over een project aan het management team?
Tijd: om te schatten hoeveel inzet van mensen er nodig is in een bepaalde periode om tot een goede verdeling te komen van de medewerkers over de projectteams.

Voor aanvang van een project en na elke projectfase moet de projectleider een inschatting geven van de GOKIT factoren voor de rest van het project. Daarnaast evalueert hij na elke fase de GOKIT factoren tot dan toe. Deze gegevens worden overlegd aan een programmamanager of aan het management team om al dan niet gezamenlijk met de projectleider en externe partijen (klanten, financiers) besluiten te nemen over het project. Hieronder staan een aantal van de belangrijkste besliscriteria beschreven, met name op het vlak van de afstemming van projecten.

Geld
Bij de beoordeling van geldzaken door een programma manager gaat het om de volgende zaken:

• Is het project als geheel en de volgende fase in het bijzonder voldoende gefinancierd?
• Wat zijn eventuele financiële risico’s van het project? Moet er een go-no-go moment worden afgesproken?
• Hoe is de liquiditeitsprognose van het project? Ontstaat er een probleem als de inkomsten van een project later zijn dan de uitgaven (bijvoorbeeld als de subsidie pas betaald wordt na afloop van een langdurig project)?

Door alle budgetten op te tellen kan de programmamanager een jaarplanning maken van de projecten. Daarbij let hij er op of er voldoende projectomzet in de pijplijn zit zodat de projectmedewerkers gefinancierd zijn. Bij onvoldoende projectomzet, moeten er nieuwe projecten geworven worden. Bij teveel omzet zal er extra personeel ingehuurd moeten worden en/of moeten projecten worden uitgesteld of zelfs afgeblazen.

Het geeft een beeld of de projecten als geheel financieel rendabel genoeg zijn. Stel dat je als organisatie 10 projecten doet van elk 2000 uur. Je hebt 20 FTE aan projectmedewerkers in dienst. Verderop zullen we zien dat daarmee ongeveer alle uren van die medewerkers zijn verdeeld. Stel dat deze 20 FTE per jaar een miljoen kosten aan loonkosten. Wanneer deze projecten minder dan een miljoen opbrengen (aan subsidie, interne financiering, commerciële opbrengsten) is er een probleem. Mogelijk moeten de tarieven worden aangepast of moeten onrendabele projecten geschrapt worden.

Voor projecten geldt dat de afwijking tussen begroting en reëel benodigde bedragen groot kunnen zijn. Met name als er sprake is van gesubsidieerde projecten kan de afwijking substantieel zijn (zie Projectrapportage). Om dit soort onzekerheid op te vangen moet de programmamanager een bedrag reserveren voor het opvangen van tegenvallers bij één of meer van de projecten.
Begrotingen zijn soms ook te ruim. In dat geval is het wel zaak dat projectleiders bereid zijn om delen van hun budget in te leveren. Anders kunnen projecten alleen maar binnen budget blijven óf te duur zijn. Als te duur ingeschatte projecten een deel inleveren aan de projecten die aanvankelijk te goedkoop zijn ingeschat zou de organisatie gemiddeld (redelijk) neutraal moeten uitkomen.

Wat doe je als organisatie als je 100.000 euro subsidie hebt gekregen voor een project en het blijkt dat je maar 80.000 euro nodig hebt? Dat geld komt wel op, er zijn zoveel nuttige dingen die nog gedaan kunnen worden voor dat geld. Bijvoorbeeld dat andere project dat 150.000 euro kreeg, maar dat eigenlijk 200.000 euro nodig had. Gelukkig is niet te achterhalen wat die programmeurs allemaal deden in de uren die ze schreven op de projecten. Dus een beetje schuiven met uren en het klopt allemaal weer.

Logisch dat organisaties zo omgaan met hun gesubsidieerde projecten, ze kunnen niet veel anders. Het is een direct gevolg van het feit dat organisaties bij een aanvraag een totaal budget moeten opstellen waar ze later niet meer van mogen afwijken. Een gevolg van deze situatie is dat de (financiële) projectrapportages van gesubsidieerde projecten met een korrel zout genomen moeten worden. Vanuit het oogpunt van projectmanagement is dat jammer omdat nu niet goed te achterhalen is hoeveel projecten echt gekost hebben. Vanuit het oogpunt van accountability van het subsidiegeld is het ook geen goede zaak.

Tijd
Als alle begrotingen van de uren van de projecten die een organisatie in een komende periode gaat uitvoeren bij elkaar opgeteld worden, geeft dat een indicatie van de werkdruk. Op jaarbasis moet het totaal aantal FTE in dienst meer zijn dan alle uren opgeteld uit de projectplannen.

Bijvoorbeeld: 10 projecten ‘verbruiken’ samen 20.000 uur. In de organisatie werken 20 FTE. Per FTE wordt er in onze organisatie 1700 uur gewerkt. Daarvan is 70% vrij voor projecten en 30% voor algemeen werk (vergaderen, email, reistijd, overige werkzaamheden, studieverlof). Netto komt dat neer op: 20 x 1700 x 70% = 23800 uur per jaar beschikbaar voor projecten. In dit voorbeeld is er dus globaal gezien voldoende capaciteit om deze projecten uit te voeren komend jaar. Veel meer kan er niet bij zonder meer mensen in dienst te nemen (ook hier is een marge nodig).

Bovenstaande controle is een globale controle op jaarbasis. Daarnaast is een fijnere controle van de capaciteit nodig, gespecificeerd naar de taken of rollen die projectmedewerkers hebben. Die 20 FTE moet verder onderverdeeld worden naar verschillende rollen binnen een project (bijvoorbeeld: programmeurs, projectleiders, designers, systeembeheerders). Het kan best zo zijn dat er in totaal voldoende mensen in dienst zijn om de plannen voor komend jaar uit te voeren, maar bijvoorbeeld te veel projectleiders en te weinig programmeurs.

Tenslotte moet de werklast (aantal verwachte uren) van de projecten niet alleen per jaar overeenkomen met het aantal beschikbare uren van de medewerkers, dit moet ook gelden voor kortere periodes. Als in het bovenstaande voorbeeld alle projecten gepland zijn in de eerste drie maanden van het jaar, is er toch een knelpunt, alhoewel er voldoende mensen in dienst zijn op jaarbasis.
De operationele verdeling van mensen op maand of zelfs weekbasis gebeurt op basis van de plannen van de fases van de projecten of tijdboxen als het gaat om cyclische projecten. Daarnaast is een wekelijks of maandelijks overleg van programmamanager met alle projectleiders nodig om de mensen operationeel in te plannen.

Ten aanzien van tijd wordt een aantal klachten veelvuldig gehoord in projectorganisaties:

• Er is geen goed beeld van de werkdruk die er heerst. De sales afdeling of het management blijven er maar nieuwe projecten bij doen terwijl we nu al niet goed toekomen aan de projecten die we nu moeten uitvoeren.
• Als één van de projecten uitloopt, dan heeft dat heel veel gevolgen voor andere projecten. Omdat we de resources moeten delen, betekent dat vertraging in het eerste project ook alle andere projecten vertraagt.

De eerste klacht komt veel voor bij snel groeiende organisaties waar men vooral oog heeft voor het werven van zoveel mogelijk omzet. Door bovenstaande controle mechanismen in te voeren, ontstaat er overzicht over de capaciteit op jaarbasis en op operationele basis van maand tot maand of zelfs week tot week.

De tweede klacht heeft een paar oorzaken. Allereerst is het bij organisaties waar deze klacht voorkomt vaak zo dat men niet goed in staat is oude projecten af te sluiten. Elke keer als het project klaar zou moeten zijn, komt er weer een nieuwe eis van de klant, een nieuwe bug of een uitbreiding op het project. Om dit tegen te gaan is het belangrijk om bij het begin van het project zo duidelijk mogelijke afspraken te maken wanneer het project klaar is. Zie ook eerdere hoofdstukken over dit probleem.

Daarnaast geldt er bij de tweede klacht ook dat er sprake is van een (te) hoge werkdruk. Omdat het zo druk is, worden er geen marges tussen de projecten gepland. Hierdoor heeft een kleine uitloop van een vorig project direct gevolgen heeft voor volgende projecten.

Tenslotte kan gezegd worden dat het tweede probleem minder vaak voor komt bij organisaties die cyclisch projectmanagement toepassen, omdat daar met vaste tijdboxen gewerkt wordt.

Om de productiviteit te verhogen wordt personeel vaak op te veel projecten ingezet. Een poging de verloren uurtjes te vullen met andere projecten leidt echter tot ernstige vertragingen. Het volgende voorbeeld illustreert dat (overgenomen en aangepast uit Goldratt, 2002):
Stel dat iemand een project A moet uitvoeren dat bestaat uit drie taken a en een project B moet uitvoeren dat bestaat uit drie taken b. Elke taak kost 5 eenheden tijd.
Als hij ze uitvoert in de volgorde aaa, bbb dan is taak A klaar na 5 + 5 + 5 = 15 eenheden. Taak B is ook na 15 eenheden klaar, gemeten vanaf het moment dat project B start.

Als hij ze echter niet na elkaar maar tegelijk, dat wil zeggen door elkaar moet uitvoeren, ziet het plaatje er anders uit. Stel dat hij een taak a steeds afwisselt met een taak b. De volgorde van werken is dan ababab.
Nu duurt het 5 + 5 + 5 + 5 + 5 = 25 eenheden voordat A klaar is en ook 25 eenheden voordat B klaar is. Daarbij het feit dat het switchen tussen projecten zelf ook tijd kost nog niet meegenomen.

Volgens (Goldratt, 2002) is de praktijk dat veel personeel binnen organisaties ingezet wordt op veel verschillende projecten tegelijk een van de belangrijkste oorzaken van het feit dat projecten (veel) te lang duren. Projecten waar een doorlooptijd van drie maanden voor staat duren in de praktijk soms wel meer dan twee jaar. Als de projecten één voor één na elkaar werden gedaan, waren ze elk na ongeveer drie maanden klaar geweest.

Uit bovenstaand voorbeeld, maar bijvoorbeeld ook uit de kennis van de wachtrijtheorie blijkt dat het niet verstandig is om het personeel te vol te bezetten. Uit kostenoverwegingen op korte termijn zijn management teams er vooral op gefocust om iedereen zo veel mogelijk te laten werken. Hierdoor gaat er veel snelheid in projecten verloren. Het kan best zo zijn dat het verhogen van de bezettingsgraad van het personeel met 10% leidt tot een verhoging van de gemiddelde doorlooptijd van projecten met 40%. Deze kosten van vertraging zijn echter veel minder zichtbaar, zeker in non-profit organisaties.

Tijdschrijven
Het is aan de programmamanager om bij aanvang van een nieuw project bovenstaande controles op financieel vlak en op gebied van urencapaciteit uit te voeren. Dit moet hij tevens doen tussen de fases van een project, dan worden de begrotingen immers bijgesteld.
Maar niet alleen het vooruitkijken is van belang, ook het evalueren van de uiteindelijk gerealiseerde begrotingen (van tijd en geld) moet gebeuren. Zijn de projecten inderdaad rendabel of kostendekkend geweest, zoals begroot? Had dat ene project inderdaad 450 uur nodig of is dit anders gelopen? Deze vragen moeten gesteld en beantwoord worden om de kwaliteit van het projectwerk in de toekomst te verbeteren.
Om deze evaluatie te kunnen uitvoeren is de aanwezigheid van een tijdschrijfsysteem noodzakelijk. Ook voor de wekelijkse sturing van projecten door projectleiders is een tijdschrijfsysteem overigens wenselijk.
In organisaties is er vaak weerstand tegen een tijdschrijfsysteem. Mensen voelen zich gecontroleerd en hebben een hekel aan administratieve klusjes. Een andere bron van weerstand is wellicht dat opeens zichtbaar wordt dat er (vaak) zo weinig vooruitgang geboekt is. Het implementeren van een geschikt tijdschrijfsysteem is een project op zich.
Een belangrijk argument voor het invoeren van een tijdschrijfsysteem is de transparantie die ontstaat. Medewerkers klagen (vaak) over een te hoge werkdruk. Het gebruik van een tijdschrijfsysteem waarin zowel de urenplanningen als de urenverantwoording staat maakt die werkdruk zichtbaar. Wanneer er nu een project ‘over de schutting’ gegooid wordt door het management of door de sales afdeling kan het projectteam zwart op wit aantonen dat het de komende tijd vol zit en dat het nieuwe project nog even moet wachten.

Waar moet een tijdschrijfsysteem aan voldoen?

• Een tijdschrijfsysteem moet door de hele organisatie gebruikt worden, ook door de boekhoudafdeling.
• Een tijdschrijfsysteem moet overal benaderbaar zijn (bv.webbased).
• Projectleiders moeten snel de rapportages van uren kunnen zien (er mag niet meer dan 1 week tussen tijdschrijven en interne rapportage zitten).
• In het tijdschrijfsysteem moeten de (uren-)planningen verwerkt zijn.
• In het tijdschrijfsysteem moet geschreven kunnen worden op werkpakketten in projectfases van projecten. Het schrijven op algemene projectnamen is niet afdoende.

De projectleiders hemel
Voor veel projectleiders is het lastig om de teamleden binnen de begroting te laten werken. Uitvoerenden lijken niet veel om de klok te geven en ook al is er een afspraak dat een klus niet langer mag duren dan een paar uur, er is altijd wel een reden waarom het toch langer duurde.

Bij een architectenbureau hebben ze dit probleem aangepakt door de verantwoordelijkheden om te draaien. De technische tekenaars van dat bureau moeten als interne freelancers hun werk gaan werven bij de projectleiders. Hierbij is onderlinge concurrentie toegestaan. Dus als een tekenaar zegt dat hij het in minder tijd kan dan zijn collega, krijgt hij de klus. Bovendien is 8 uur ook echt 8 uur. Dus als het niet klaar is, moet de technisch tekenaar het in zijn eigen tijd afmaken. Heerlijk om daar projectleider te zijn, misschien wat minder prettig om projectmedewerker te zijn.

Organisatie van meerdere projecten naast elkaar
In (Wijnen, 2004, p. 187 en verder) wordt er onderscheid gemaakt tussen drie structuren van projectmanagement ten opzichte van de moederorganisatie:

• de overleg- of coördinatiestructuur;
• de matrixstructuur;
• de zuivere projectstructuur.

In de overleg- of coördinatiestructuur bestaat het projectteam meestal uit alleen de projectleider zelf. Deze projectleider heeft niet veel gezag over andere medewerkers. Hij is bezig met een licht project, vaak onderzoekswerk om een advies aan het management uit te brengen. Als deze projectleider de inzet nodig heeft van andere medewerkers in de organisatie dan kan hij ze informeel om hulp vragen of moet hij dat via hun bazen regelen.

Een project door middel van de overlegstructuur. De projectleider (vaak staflid) staat geheel buiten de afdelingen.

Bij de matrixstructuur is de organisatiestructuur zodanig opgezet dat de teamleden zowel in een projectteam werken (parttime) als in hun functie binnen de lijnorganisatie (parttime). Ook als mensen binnen meer projecten tegelijk werken zou je kunnen spreken van een matrixorganisatie.
Groot voordeel ten opzichte van de overlegstructuur is dat er sprake is van een projectteam dat bestaat uit meerdere mensen. Hierdoor kan dit projectteam meer realiseren dan in de situatie van de overlegorganisatie, omdat daar de projectleider er voornamelijk alleen voor staat. De projectleider heeft meer gezag in deze situatie. Hij heeft daadwerkelijk de leiding over zijn team. Voor de teamleden kan er op dit punt wel verwarring ontstaan omdat ze nu twee bazen hebben: de projectleider en het hoofd van de afdeling waar ze in werken. Als medewerkers in meerdere projecten tegelijk werken kan het zelfs zo zijn dat ze meer dan twee bazen hebben.

Het is belangrijk dat de afdelingshoofden en projectleider(s) onderling duidelijke afspraken maken over de inzet van mensen. De praktijk leert nog wel eens dat dit niet gebeurt. Van alle kanten wordt er aan medewerkers getrokken en die doen (noodgedwongen) eerst het werk van de baas die het hardst schreeuwt. Dat dit niet altijd het werk is dat de hoogste prioriteit heeft voor de organisatie als geheel, moge duidelijk zijn.

Projecten georganiseerd volgens het matrix model. Leden van een projectteam hebben twee bazen: de projectleider en het afdelingshoofd.

Bij de zuivere projectstructuur, worden de medewerkers uit de organisatie gehaald en werken zij voor de duur van het project alleen maar in het project. Deze vorm is het meest geschikt voor grote, zware projecten. Het projectteam is in hoge mate autonoom en de teamleden hebben alleen de projectleider als baas. Belangrijk nadeel van deze structuur is dat het duur en ingrijpend is voor de organisatie. Medewerkers worden namelijk gedurende lange tijd van hun oorspronkelijke werk gehaald.

Schema van de zuivere projectstructuur. Het projectteam staat redelijk autonoom buiten de rest van de organisatie

Het hangt voornamelijk van de projecten af, welke organisatiestructuur het beste is. Voor kleine projecten is de overlegstructuur goed geschikt en voor grote, langdurige en zware projecten is de zuivere projectstructuur het best geschikt. In de praktijk worden veel projecten georganiseerd door middel van een matrixstructuur omdat veel projecten tussen deze twee uitersten in zitten. Bij het matrixmodel is de coördinatie van de projecten wel het lastigst.

Klik hier voor het oorspronkelijke artikel op projectmangement-training.nl.

Om dit dilemma te omzeilen wordt binnen DANS voor softwareontwikkeling met het beste van twee methoden gewerkt. De projecten starten met de watervalmethode, zodat er goed nagedacht wordt over eisen, wensen en ontwerp. Na de ontwerpfase wordt overgegaan op cyclisch werken, waarbij flexibel omgegaan kan worden met eisen, wensen en ontwerpen. Voor het cyclische deel van de DANS-methode wordt gebruik gemaakt van eXtreem Programming (XP) (Chromatic, 2003, [ii], [iii]). Binnen de cycli vindt nadere definiëring, nader ontwerp, realisatie en testen plaats. Als de software vervolgens voldoende is ontwikkeld start de nazorgfase. Hieronder wordt deze werkwijze stap voor stap verder beschreven.

Figuur 11: Schematische weergave van de DANS-methode voor softwareontwikkeling

Initiatiefase

De initiatiefase begint bij een idee voor een project. Er is nog geen budget beschikbaar voor het project. Doel van deze fase is het schrijven van een projectplan op basis waarvan financiering intern of extern aangevraagd kan worden.

Activiteiten initiatiefase:

• uitwerken idee
• onderzoeken draagvlak
• contacten leggen met eventuele partners
• financieringsmogelijkheden onderzoeken
• eerste globale inschatting van de GOKIT factoren voor het project
• concrete inschatting GOKIT factoren voor de definitiefase
• begrenzen van het project
• schrijven projectplan
• aanvragen financiering of contractafspraken maken met een eventuele klant

Resultaat initiatiefase:

• goedgekeurd en gefinancierd projectplan
• (eventueel) contract met klant

Uitvoering/Beslissingen:

• (beoogd) projectleider
• opdrachtgever
• (eventueel) klant

Hulpmiddelen:

• Zie bijlage 10 voor een model van een projectplan

Als het mogelijk is om de financiering in trances te krijgen is dit te verkiezen boven financiering in één keer na de initiatiefase. Bij gefaseerde financiering wordt in de initiatiefase een financieringsverzoek gedaan voor een relatief klein bedrag in de initiatiefase voor het uitvoeren van de definitiefase en ontwerpfase. Op basis van de uitkomst van deze fases wordt aan het einde van de ontwerpfase een tweede financieringsverzoek gedaan voor de rest van het project.

Definitiefase

Nadat een projectplan is goedgekeurd, komt het project in de tweede fase, de definitiefase. In deze fase worden de eisen en wensen die aan een projectresultaat gesteld worden zo goed en compleet mogelijk bepaald. Het gaat er om de verwachtingen van de betrokken partijen over wat het projectresultaat moet zijn boven tafel te krijgen. Hierbij kan de lijst uit hoofdstuk 1 als geheugensteun dienen:

• randvoorwaarden
• functionele eisen
• operationele eisen
• ontwerpbeperkingen

Het is heel belangrijk dat alle betrokkenen in een project kunnen meedenken in de definitiefase. Vooral ook de eindgebruikers die het projectresultaat gaan gebruiken.

Activiteiten definitiefase:

• eisen en wensenlijst opstellen samen met opdrachtgever, (eventuele) klant, eindgebruikers, experts, projectteam
• eisen en wensen afwegen
• haalbaarheid eisen en wensen toetsen
• rapportage aan opdrachtgever en/of klant van eisen en wensen
• rapportage van de GOKIT factoren tot nu toe (gerealiseerd)
• nieuwe prognose van de globale GOKIT factoren voor de rest van het project
• prognose van de concrete GOKIT factoren voor de ontwerpfase

Resultaat definitiefase:

• goedgekeurde (voorlopige) eisen en wensenlijst
• goedgekeurde GOKIT rapportage en prognoses

Uitvoering:

• (beoogd) projectleider
• opdrachtgever
• (eventueel) klant
• eindgebruikers
• experts
• (toekomstige) programmeurs en ontwerpers
• systeembeheerder (in verband met eisen en wensen in de nazorgfase)

Beslissingen/goedkeuring:

• projectleider
• opdrachtgever
• (eventueel) klant

Hulpmiddelen:

• zie bijlage 10 voor een model van een projectplan

Bij de watervalmethode geldt dat er in principe na de definitiefase geen andere of aanvullende eisen meer gesteld mogen worden aan het project. De eisen en wensenlijst vormt als het ware de basis voor het contract tussen het projectteam en de opdrachtgever of klant. De eisen en wensenlijst is datgene waar het projectresultaat uiteindelijk aan moet voldoen.

Omdat we gezien hebben dat dit bij software projecten tot problemen leidt, wordt deze strikte manier van werken hier niet gevolgd. De definitiefase wordt hier gebruikt om een onderzoek naar de eisen en wensen te laten plaatsvinden zodat het project zo goed mogelijk richting krijgt. Ook wordt er beschreven wat er allemaal niet gemaakt wordt. Dit om de verwachtingen tussen klant en makers helder te krijgen. Mocht door het voortschrijdende inzicht in de cyclische fases blijken dat bepaalde eisen en wensen anders ingevuld moeten worden, dan is dat bij deze werkwijze mogelijk (uiteraard in overleg en goed gedocumenteerd)

Ontwerpfase

Met de eisen- en wensenlijst uit de definitiefase kan het projectteam keuzes maken over hoe de software eruit moet komen te zien. De ontwerpfase van ICT projecten heeft een ontwerpdocument als resultaat. In het ontwerpdocument wordt het concept nader uitgewerkt en in grote lijnen wordt er een technisch ontwerp uitgewerkt. Doel is om te onderzoeken hoe de software er zowel technisch als functioneel uit zou kunnen zien (een voorbeeld van een functioneel ontwerpdocument is te vinden op [iv]).
In dit kader is het handig om in de ontwerpfase te werken met dummy’s die voorgelegd worden aan de opdrachtgevers en/of klanten en eindgebruikers.
Een dummy is een snel in elkaar gezet, niet werkende of slechts deels werkend stuk software dat vooral dient om het ontwerp te evalueren. Dummy’s hebben het voordeel boven schema’s op papier dat ze er uitzien als het beoogde eindproduct.

Bij de watervalmethode is het na de goedkeuring van de ontwerpdocumenten door de klant in principe niet meer mogelijk op ontwerpbeslissingen terug te komen. Bij de DANS-werkwijze kan dat wel. De ontwerpdocumenten dienen als eerste uitgangspunt voor de bouwers, maar mocht door voortschrijdend inzicht blijken dat er wijzigingen nodig zijn, dan kunnen die doorgevoerd worden.

Als in de cyclische fasen besloten wordt het ontwerp aan te passen, dan moet die wijziging niet alleen geprogrammeerd worden, maar ook bijgewerkt worden in een zogenaamd projectlog.

Als naar mening van het projectteam het ontwerp voldoende is uitgewerkt, start de cyclische fase.

Activiteiten ontwerpfase:

• Ontwerpdocumenten opstellen
• Mock-ups (dummies) maken en evalueren met klant
• rapportage gekozen ontwerp
• rapportage van de GOKIT factoren tot nu toe (gerealiseerd)
• nieuwe prognose van de globale GOKIT factoren voor de rest van het project
• prognose van de concrete GOKIT factoren voor de cyclische fase

Resultaat ontwerpfase:

• goedgekeurd ontwerpdocument
• goedgekeurde GOKIT rapportage en prognoses

Uitvoering:

• projectleider
• designers
• programmeurs
• (eventueel) eindgebruikers voor evaluatie ontwerpen

Beslissingen/Goedkeuring:

• projectleider
• opdrachtgever
• (eventueel) klant

Hulpmiddelen:

• zie [i] voor een handleiding voor het maken van een ontwerp document
• zie de bijlage 10 voor een model van een projectplan

Cyclische fase

De werkwijze in de cyclische fase is ontleend aan XP. In deze fase wordt een aantal cycli na elkaar uitgevoerd. Een cyclus duurt maximaal een tot twee weken. In elke cyclus vinden de volgende activiteiten plaats:

• plannen
• onderzoeken van functionaliteiten
• ontwerpen van functionaliteiten
• realiseren van functionaliteiten
• testen van functionaliteiten
• opleveren van functionaliteiten

Plannen
Aan het einde van de ontwerpfase is een inschatting gemaakt van het aantal cycli dat nodig is voor het bereiken van het projectdoel. Dit gebeurt op basis van het functionele en technische ontwerp. Een cyclus duurt nooit lang, ergens tussen de twee en vier weken. In een cyclus komen altijd de activiteiten plannen, onderzoeken, ontwerpen, realiseren, testen en opleveren voor. Per cyclus wordt dus maar gewerkt aan enkele functionaliteiten, soms maar aan één.

De spelregels voor het plannen zijn als volgt. De gewenste functionaliteiten worden door de projectleider samen met de klant op zogenaamde storycards opgeschreven. Begonnen wordt met de functionaliteiten die bepaald zijn in de definitie- en ontwerpfase op storycards te schrijven. Op basis van die storycards maken de programmeurs een takenlijst, een lijst van dingen die zij moeten doen om die functionaliteit te realiseren. Die taken mogen in de regel niet langer duren dan een paar uur. Als een taak langer duurt, moet hij gesplitst worden in verschillende subtaken of moet de storycard gesplitst worden in meerdere storycards. Als een storycard te veel werk is om in één cyclus plaats te vinden, moet hij worden teruggegeven aan de klant. De klant moet de wensen dan opsplitsen en verdelen over meer storycards.
Per taak geeft de programmeur aan hoeveel tijd hij er voor nodig denkt te hebben. Zo ontstaat een ureninschatting per storycard. Op basis van de ureninschattingen van de storycards kan de klant nu samen met de projectleider aangeven welke van de functionaliteiten ze als eerste gerealiseerd willen zien in de eerstvolgende cyclus.

Hoe lang duurt het om een website te maken en deze te vullen met 50 pagina’s tekst en een aantal foto’s? Een snel antwoord van de ontwerper dat het ‘ongeveer twee weken duurt’ is veel te grof. Het zou best wel eens veel langer kunnen duren. Wordt deze taak uitgesplitst dan blijkt dat er een CSS gemaakt moet worden, overleggen met de opdrachtgever over het ontwerp, het ontwerp programmeren in xhtml, de teksten inkorten voor het internet, de pagina’s vullen met de teksten, de foto’s geschikt maken voor het internet, de foto’s plaatsen, controle door de klant en de laatste foutjes eruit halen.

Door het werk uit te splitsen in kleinere delen, blijkt het veel meer werk dan aanvankelijk gedacht. Ook realiseert de opdrachtgever zich dat hij ook een aantal dingen moet doen. Als nu per taak ingeschat wordt hoeveel uur werk het is, zal het een veel betere totaalschatting opleveren (en zal blijken dat het niet in twee weken kan).

Als de programmeurs aan de slag gaan, houden ze hun uren bij die ze nodig hebben voor het uitvoeren van een taak. Vaak blijkt dat ze meer uren nodig hebben dan ze aanvankelijk zelf geschat hadden. Doordat ze een terugkoppeling krijgen op hun eigen inschattingen, leren de programmeurs steeds betere schattingen te maken.
Uit de praktijk blijkt dat naarmate een project een tijdje loopt er een redelijk constante factor verschil is tussen de schattingen van de programmeurs en de werkelijk benodigde aantallen uren. Deze factor wordt de ‘dragfactor’ genoemd. De dragfactor kan na een paar cycli bepaald worden op basis van het gemiddelde verschil tussen de geschatte en benodigde uren. De dragfactor wordt gebruikt in planningen van toekomstige cycli en in rapportages. Met name het aantal uitstaande storycards met takenlijsten maal de dragfactor is een redelijk betrouwbare indicatie van de hoeveelheid tijd die nog nodig is voor het realiseren van de rest van het project.

Het aantal uren voor het project is beperkt, dus dat betekent dat er keuzes gemaakt moeten worden. Doordat er een redelijk inzicht is in het aantal benodigde uren voor het realiseren van een storycard, kan een goede afweging gemaakt worden tussen de verschillende storycards. Sommige storycards zullen simpeler uitgevoerd moeten worden, andere storycards komen als geheel te vervallen. Belangrijk uitgangspunt bij het bepalen van de volgorde is dat risicovolle storycards als eerste behandeld moeten worden. Dit om zo snel mogelijk de belangrijkste risico’s uit te schakelen. Daarnaast gelden de MoSCoW-regels of een simpeler prioriteitstelling van 1 tot 5.

Figuur 12: Plannen van de functionaliteiten in de cycli

Onderzoeken en ontwerpen functionaliteiten
Door het maken van de takenlijsten voor de planning vindt het eerste onderzoek van de functionaliteit plaats. Door het vooraf bedenken welke deeltaken nodig zijn bij het realiseren van een functionaliteit, krijgt de programmeur meer inzicht in de functionaliteit zelf. Voor het verder onderzoeken en ontwerpen van de gewenste functionaliteit is de betrokkenheid (aanwezigheid) van de klant essentieel. Hij moet aangeven wat hij precies wil. De klant zal in het begin van het project veel contact hebben met de programmeurs. Later in het project kan dat afnemen, al moet er voor gewaakt worden dat programmeurs niet gaan denken voor de klant en dan verkeerde aannames doen.

Realiseren van de functionaliteiten
Nadat de klant en de makers een ontwerp voor de gewenste functionaliteit zijn overeengekomen, wordt deze gebouwd. Programmeurs werken daarbij altijd in paren (‘pairprogramming’ in XP termen). Dit lijkt wellicht improductief, maar pairprogramming biedt vele voordelen:

• kennis van twee programmeurs wordt gecombineerd
• minder tijd nodig voor overdracht van kennis of code binnen een project
• minder fouten tijdens het programmeren
• sneller knelpunten oplossen

Er is nog een ander voordeel: het grootste probleem is beginnen met programmeren. Eenmaal begonnen dan loopt het verder wel. Door paarsgewijs te programmeren, worden de programmeurs eerder door elkaar aangespoord te starten met werken.

Joel Spolsky was programmeur bij Microsoft en realiseerde zich dat hij maar zo’n drie uur per dag effectief werkte [v]. Vaak nog minder. Het lijkt erop dat meer collega’s dat hadden. De rest ging op aan koffiedrinken, e-mails lezen, internetten, praten met collega’s en de prachtige kantoortuin bekijken. Door te werken met een ander wordt je gemotiveerd en is de start makkelijker.

Overigens vraagt pairprogramming veel van de concentratie van programmeurs en niet alle programmeurs vinden het prettig. Bovendien werken niet alle combinaties van programmeurs prettig samen. Om deze nadelen te verzachten kan een team bijvoorbeeld besluiten om niet meer dan een halve dag per dag pairprogramming toe te passen (zie verder [vi] voor een discussie over pairprogramming).

Testen en opleveren
Essentieel is dat elke cyclus tot een release van een nieuw deel van de software leidt en dat elk deel dat opgeleverd wordt, getest is. Testen bestaat uit een unit test (test door de programmeurs) en een acceptatietest (test door de klant). Ook hierbij is de inzet van de klant dus nodig.

Achterliggend idee van het testen in elke cyclus is de theorie dat het exponentieel duurder wordt om fouten te herstellen naarmate het langer heeft geduurd voor ze gevonden zijn. Uitgangspunt bij het opleveren van software in elke cyclus is dat de klant zo snel mogelijk waar voor zijn geld krijgt en dat er snel feedback mogelijk is van de gebruikers naar de programmeurs. De klant ziet duidelijk de voortgang van het project. Dit is vooral psychologisch van belang en kan de verhouding met de klant aanzienlijk verbeteren.

Op een punt verschilt de werkwijze van DANS essentieel met de werkwijze van XP. XP schrijft voor dat er niet vooraf een ontwerp gemaakt mag worden voordat met programmeren wordt begonnen. Dit om maximale flexibiliteit te bereiken en niet al dingen vast te zetten, die later niet handig blijken te zijn. Naar mening van de auteur en adviseurs van dit handboek is het echter wel nuttig om te beginnen met het maken van een ontwerp in de definitiefase en ontwerpfase. De functionaliteiten die in die fases worden bepaald, mogen bij de DANS werkwijze wel worden aangepast in de cyclische fase in tegenstelling tot de werkwijze van de watervalmethode.

Activiteiten cyclische fase:

• doorlopen van een aantal cyclussen waarin onderzocht, ontworpen, gerealiseerd, getest en opgeleverd wordt
• opstellen van storycards
• keuzes maken uit de storycards
• plannen van de cycli
• voortgang bewaken (GOKIT)
• (aan het einde) prognose van de concrete GOKIT-factoren voor de nazorg fase

Uitvoering/beslissingen

• projectleider
• opdrachtgever of klant
• (eventueel) eindgebruikers voor testen en ontwerpen
• programmeurs en ontwerpers

Hulpmiddelen:

• zie bijlage 3 voor hulpmiddelen voor het registreren en bijhouden van de storycards en takenlijsten

Nazorgfase

Nadat voldoende resultaat is bereikt in de cyclische fase, start de nazorgfase. In deze fase moet het projectresultaat geborgd worden. Het hangt van het soort project en de afspraken met de opdrachtgever of klant af wat die borging inhoudt. Bij een onderzoeksproject volstaat wellicht een eindrapport, bij de ontwikkeling van een nieuw product zal meer nazorg nodig zijn.

De meeste problemen in de nazorgfase ontstaan omdat er bij het begin van het project geen duidelijke afspraken zijn gemaakt tussen klant of opdrachtgever en projectteam. Denk bijvoorbeeld aan de volgende punten:

• Hoe lang moet de nazorg duren?
• Waar bestaat de nazorg uit?
• Hoe snel moeten fouten hersteld worden?
• Zit er garantie op het projectresultaat?
• Wie is er verantwoordelijk voor bugs die gevonden worden ná het project?
• Moet er documentatie bij het projectresultaat worden geleverd?
• Is er training en/of opleiding nodig voor gebruikers?
• Wie is er verantwoordelijk voor updates?
• Wie wordt de eigenaar van de code, wie mag de code wijzigen?
• Wie betaalt de bovenstaande punten?

Het is belangrijk te beseffen dat een projectorganisatie gericht is op tijdelijke activiteiten en derhalve niet ingericht is om (lang) ondersteuning te bieden op de software die het zelf heeft ontwikkeld. Voor de langere termijn moet een andere vorm voor ondersteuning gevonden worden. Er zijn speciale (commerciële) organisaties voor het beheren van software. Deze organisaties bieden helpdeskondersteuning, trainingen, serverbeheer, applicatiebeheer en dergelijke. Voor kleine non-profit initiatieven zullen deze organisaties veelal (te) duur blijken.

Een ander traject dat bewandeld kan worden om de continuïteit van de software te waarborgen, is de software open source maken. Hier wordt een organisatie voor ingericht zodat een groep van ontwikkelaars en gebruikers in staat is om de software te onderhouden en te ondersteunen.

Activiteiten nazorgfase:

• rapportage van de GOKIT-factoren van het project
• opstellen en indienen eindverantwoording
• ontbinden team
• overdracht naar beheersorganisatie

Resultaat nazorgfase:

• projectverantwoording
• overdrachtsdocumenten

Uitvoering:

• projectleider
• teamleden
• systeembeheerder

Beslissingen/Goedkeuring:

• projectleider
• opdrachtgever
• (eventueel) klant

Klik hier voor het oorspronkelijke artikel op projectmanagement-training.nl

De ontwikkeling van software is een creatief proces

De ontwikkeling van software wordt door buitenstaanders eerder als ‘engineering’ dan als ‘iets uitvinden’ gezien. Toch heeft het wel raakvlakken met iets uitvinden. Iets uitvinden betekent dat je vooraf nooit precies weet wat er gaat komen.

De ontwerpers en programmeurs die nieuwe software gaan schrijven, moeten oplossingen bedenken voor de problemen die hen worden voorgeschoteld. Ondanks vele methodes en voorschriften van werken, blijft het schrijven van programmacode voor een groot deel nieuw en daardoor in hoge mate onzeker. De programmeurs kunnen voor hun oplossing kiezen uit wel miljoenen oplossingen, geschreven in tientallen programmeertalen, draaiend op duizendtallen verschillende hardwareconfiguraties, werkend op tientallen software platforms. Die vrijheid biedt een aantal voordelen, maar maakt ook dat het project moeilijker te beheersen is dan traditionele projecten als bijvoorbeeld constructie- of bouwprojecten.

Het is vrijwel onmogelijk alle eisen en wensen vooraf boven water te krijgen

De watervalmethode schrijft voor dat in de definitiefase de eisen en wensen als projectresultaat geformuleerd worden. Idealiter geval wordt van die eisen of wensen niet of nauwelijks meer afgeweken. Bij softwareontwikkeling volgens het watervalmodel wordt er in het begin van het project veel tijd besteed aan het analyseren van de benodigde functionaliteiten (eisen en wensen). Dit leidt tot een functioneel ontwerp (voor een nadere toelichting op functioneel ontwerpen, zie bijvoorbeeld [i]). Op basis van het functionele ontwerp gaat de softwarearchitect in de ontwerpfase een technisch ontwerp maken. In het technische ontwerp wordt beschreven hoe de gewenste functionaliteiten gerealiseerd moeten worden.

Dit lijkt allemaal vrij recht toe recht aan, maar stel de volgende situatie voor (voorbeeld aangepast van McConnell, 1996, p. 138): Er is een project voor de productie van een nieuwe auto. U bent een actieve autorijder en aan u wordt gevraagd de eisen en wensen te formuleren die er aan een auto zijn. U overlegt met andere autorijders en komt met een hele lijst:

• de auto moet plaats bieden aan 4 personen
• de auto moet een stuur linksvoor hebben, een rempedaal, een gaspedaal, een handrem
• de auto heeft 4 wielen
• de auto heeft witte koplampen en rode achterlichten enz. enz. (In de realiteit zou het een enorme lijst worden.)

De ontwerpers maken op basis van uw lijst een nieuw ontwerp, dat vervolgens, maanden later, gebouwd wordt. Dan, u loopt over straat en ziet een auto remmen. U realiseert zich dat u in deze lijst vergeten bent de remlichten te noemen! U belt onmiddellijk met de ingenieur van de autofabriek die zowat ontploft van uw telefoontje. U oppert nog dat het slechts om een kleinigheidje gaat. Maar voor de autobouwers is het rampzalig. De gemaakte auto’s moeten helemaal opengemaakt worden, er moeten kabels van de rempedalen naar achteren getrokken worden, het ontwerp van de achterkant moet helemaal opnieuw om ruimte te bieden voor de remlichten, de achterkleppen die al geproduceerd zijn moeten worden weggegooid, en ga zo maar door.

Bovenstaand voorbeeld lijkt misschien wat absurd maar bij softwareontwikkeling is het bijna dagelijkse realiteit. Programmeurs gaan er ten onrechte vanuit dat de opdrachtgever, klant of gebruiker van nieuw te ontwikkelen software precies weet wat hij wil. De opdrachtgever gaat er ten onrechte van uit dat de softwarebouwers in de kortste tijd alles kunnen maken (en aanpassen). Dit probleem is de grootste oorzaak van conflicten tussen klanten en softwarebouwers.

En dat er veel conflicten zijn tussen klanten en softwareleveranciers blijkt wel uit het volgende. Een startende ondernemer wilde een rechtsbijstandverzekering voor zijn bedrijf afsluiten. Hij informeerde naar de mogelijkheden. De tussenpersoon vroeg in welke branche de ondernemer actief zou zijn, waarop hij ‘ICT’ antwoordde. Helaas dan, reageerde de tussenpersoon, er zijn zo vaak rechtszaken tussen ICT- leveranciers en klanten dat er geen verzekeraar meer is die voor ICT-bedrijven een rechtsbijstandsverzekering wil afsluiten.

Het schatten van de benodigde hoeveelheid tijd is moeilijk

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.

Het is wenselijk dat alle tussenresultaten door de gebruiker gedurende het traject getest kunnen worden

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.

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.

Cyclische projectmanagementmethodes

Door bovengeschetste problematiek zijn er de afgelopen jaren andere methodes voor projectmanagement ontstaan die met name worden toegepast bij ICT- ontwikkelprojecten. DSDM, RUP, eXtreme Programming (XP), RAD, agile projectmanagement, zijn enkele van de namen van deze relatief nieuwe stromingen binnen projectmanagement (McConnell, 1996, Kroll, 2004, Chromatic, 2003, Stapleton, 2002, [ii], [iii])

Hoewel bovenstaande projectmanagementmethodes op aspecten van elkaar verschillen, komen ze in essentie overeen. Omdat de weg naar het einddoel bij ICT-projecten zo onzeker is gebleken, gaan deze methodes uit van het bereiken van het doel in een aantal korte cyclussen. Vandaar de benaming ‘cyclisch’ projectmanagement voor deze methodes.

Figuur 9: De activiteiten in een cyclus

Bij cyclisch projectmanagement tracht men bij het projectdoel te komen middels enkele korte cycli die na elkaar plaatsvinden. Elke cyclus duurt relatief kort, bij voorkeur korter dan een maand. Binnen een cyclus wordt een deel van het project uitgevoerd. Binnen een cyclus wordt geanalyseerd, ontworpen, gerealiseerd en getest. Dit is wezenlijk anders dan bij de watervalmethode waar die activiteiten allemaal in een eigen fase plaatsvinden. Bij de watervalmethode wordt bovendien maar éénmaal gedefinieerd, ontworpen, gerealiseerd en getest. Bij de cyclische methodes gebeurt dat vele malen na elkaar.

Tijdens de cycli worden verschillende onderdelen van de software gerealiseerd. De cycli staan daarmee maar deels los van elkaar. Nadat een cyclus is afgerond vindt evaluatie plaats. Mocht het zo zijn dat door voortschrijdent inzicht er nieuwe of andere eisen aan het project zijn ontstaan, dan worden de werkzaamheden van de komende cycli daarop aangepast.

Een cyclus begint bij het maken of bijstellen van de planning. Vervolgens worden de eisen- en wensen onderzocht van hetgeen dat gemaakt moet worden in deze cyclus. Er wordt een ontwerp gemaakt, dit ontwerp wordt geprogrammeerd en getest. Vervolgens vindt evaluatie plaats en bij sommige methodes ook in gebruikname van de nieuwe software. Daarna kan de volgende cyclus starten om het volgende deel van het project uit te voeren. (Voor een meer uitvoerige beschrijving van cyclische methodes en de verschillen tussen de methodieken zie onder andere Kroll, 2004, Chromatic, 2003, Stapleton 2002.)

De grote voordelen van het werken met een cyclische methode zijn:

• hogere kwaliteit van het product en betere implementatie van functionaliteiten
• Realistischer begroting van tijd en geld
• Projectteam komt minder onder druk te staan
• Hogere kwaliteit

Uit vorige hoofdstukken is gebleken dat het moeilijk of wellicht onmogelijk is om in een vroeg stadium in het project de gewenste functionaliteiten goed te bepalen. In de cyclische methoden worden de gewenste functionaliteiten middels enkele korte cycli gerealiseerd. Per cyclus wordt een klein deel van de gewenste functionaliteit niet alleen onderzocht, maar ook ontworpen, gerealiseerd, eventueel geïmplementeerd én getest. Met name het kort opeenvolgen van ontwerpen, realiseren en testen leidt tot betere kwaliteit. Het maakt dat het team in staat is aanpassingen te doen. Als een ontwerp in de praktijk niet goed uitpakt, wordt dit binnen het tijdvak van de cyclus duidelijk. Er kan dan bijgestuurd worden. Binnen deze manier van werken kan de klant dus vragen om aanpassingen.

Een andere reden dat cyclisch projectmanagement tot betere kwaliteit leidt is omdat er in een cyclus intensief wordt samengewerkt tussen klant, ontwerpers en programmeurs. Er is een multidisciplinair team dat gezamenlijk oplossingen bedenkt en uitvoert. Bij de watervalmethode is de klant vooral in het begin aan het woord bij het formuleren van de eisen en wensen, daarna maken ontwerpers een ontwerp en vervolgens programmeren de programmeurs de software. De projectleider is de schakel tussen al die partijen en moet ervoor zorgen dat de informatie over en weer terecht komt. In de praktijk betekent het bijvoorbeeld dat veel programmeurs en ontwerpers de klant nooit zien. Die komt pas weer in beeld als de software af is.

Cyclische projectmanagement methodes zijn vooral goed voor projecten waarbij men het te bereiken doel vooraf niet goed kan vaststellen, zoals creatieve projecten of onderzoeksprojecten. Door te werken in een aantal cycli met een multidisciplinair team waarin de eindgebruikers ook vertegenwoordigd zijn, leert het team wat nu eigenlijk echt de bedoeling is van het project en hoe dat het beste bereikt kan worden. In elke cyclus zit een reflectiemoment en is er de mogelijkheid tot bijsturen.

Bij waterval projecten wordt vooraf een doel geformuleerd. Reflectie op het oorspronkelijke doel is in mindere mate mogelijk. Het oorspronkelijk geformuleerde doel wordt niet (geheel) bereikt. En geconstateerd wordt dat zowel het oorspronkelijk geformuleerde doel als het bereikte doel helemaal niet de daadwerkelijk gewenste doelen zijn.

Figuur 10: Door cyclisch te werken wordt een beter resultaat bereikt (Illustratie: Rachèl Harmsen)

De laatste reden waarom een cyclische projectmethodiek tot een beter resultaat leidt is dat de klant na elke cyclus acceptatietests uitvoert. Bovendien wordt de kwaliteit verder verstevigd door van meet af aan uit te gaan van tests als criterium voor goed werkende functionaliteit. Programmeurs moeten daarvoor voordat ze hun code gaan schrijven zogenaamde ‘falende tests’ definiëren (unit tests). Alleen als de code de falende test passeert, is hij goed.

Hoe werkt testgericht werken? Bij testgericht werken moet de programmeur voordat hij nieuwe code schrijft, bewijzen dat er geen bugs in de nieuwe code zitten. Dit doet hij door een test te bedenken die een eventuele bug aan zal wijzen (falende tests), voordat hij gaat coderen.
Bijvoorbeeld, stel dat een programma gemaakt moet worden voor het berekenen van de juiste hoeveelheid wisselgeld die je moet terugkrijgen van een snoepmachine. Allereerst moet er getest worden of er al een functie bestaat die wisselgeld geeft. Deze functie wordt ‘geef_wisselgeld’ genoemd. Een simpele test zal gemaakt worden en als die uitgevoerd wordt dan zal er blijken dat er nog niet een functie ‘geef_wisselgeld’ bestaat. Wanneer de programmeur vervolgens de functie aanmaakt maar nog geen inhoud geeft, zal deze test slagen.

De volgende stap is dat getest moet worden of de machine de juiste hoeveelheid geld teruggeeft als er iets gekocht wordt. Stop 60 cent in de machine en koop een item van 50 cent. De test zal niet slagen, want de functie is nog leeg. De programmeur zal vervolgens de code schrijven. In de functie ‘geef_wisselgeld’ schrijft hij dat de hoeveelheid terug te geven wisselgeld de hoeveelheid geld is die er in de machine is gestopt minus de kostprijs van het gekozen snoep. De test zou nu moeten slagen. Enzovoort, voor elk deel van de software moet vooraf een test bedacht worden (voorbeeld vertaald en aangepast uit Chromatic, 2003, p. 27 e.v.)
Niet alleen de code moet (technisch) getest worden, ook de functionaliteiten moeten getest worden (acceptatie tests). Daarvoor moet de klant voor het coderen bepalen onder welke condities de nieuw te bouwen functionaliteiten geaccepteerd gaan worden. Bijvoorbeeld hoe snel een computer moet reageren op een bepaalde actie van een gebruiker. Met name het vooraf aangeven onder welke condities de nieuwe functionaliteit geaccepteerd zal worden, blijkt moeilijk en tijdrovend. Toch is de actieve rol van klanten bij het testen zeer bepalend voor het succes van het project.

Realistischer begroting van tijd en geld.
Bij een cyclische projectmethodiek worden de te realiseren functionaliteiten niet vastgepind aan het begin van het project. De beschikbare tijd wordt wel vastgelegd. Afgesproken wordt welke richting het project opgaat en onderweg wordt gekeken wat echt nodig, zinnig en realistisch is met betrekking tot de nieuw te maken software. Bij cyclische projecten worden dus niet de te realiseren functionaliteiten als vaststaand doel beschouwd, met als risico dat de benodigde uren (en dus benodigd geld) extreem uit de hand kunnen lopen. Om dat te voorkomen wordt de beschikbare tijd als uitgangspunt genomen en wordt gaandeweg gekeken wat men op realistische wijze kan maken in de beschikbare tijd.

Dit is ook de reden dat cyclische projectmanagementmethodes veel vriendelijker zijn voor het projectteam. Het team doet wat het kan in de gestelde tijd maar wordt niet onder druk gezet om onrealistische planningen te halen of te werken met veel te krappe begrotingen.

Ook het beheersen van externe leveranciers is gemakkelijker. Bij de watervalmethode zit je op een gegeven moment helemaal vast aan één leverancier tot het einde van het project, of die leverancier nu goed presteert of niet. Bij de cyclische werkwijze is het in principe mogelijk om per cyclus of zelfs per op te leveren component afspraken te maken en desnoods te wisselen van leverancier.

Voorwaarden voor cyclisch projectmanagement

Om cyclisch projectmanagement te kunnen toepassen moet aan een aantal voorwaarden voldaan zijn:

1. Actieve betrokkenheid van gebruikers/klanten
Bij cyclisch projectmanagement vindt het opstellen van eisen- en wensen, het ontwerpen, realiseren en testen in elke cyclus plaats. Dat betekent dat er veel beslissingen genomen moeten worden in een cyclus. Om in staat te zijn de wensen van de klant goed te laten uitkomen in de software, moet de klant actief meedoen in het projectteam. Hij moet zo goed mogelijk zijn wensen uitleggen aan de programmeurs en ontwerpers. Men moet denken aan wekelijkse of minimaal tweewekelijkse aanwezigheid in het projectteam.

Klanten houden zich binnen het project bezig met het bepalen van de gewenste functionaliteiten en de planning van de cycli. Ze denken mee over de acceptatietests, ze keuren tussenresultaten goed of af en denken mee over de algemene richting van het project. Overigens geldt ook voor de watervalmethode dat een actieve opstelling van de klant tot betere resultaten leidt.

2. Team mag besluiten nemen
Binnen een cyclus moet het projectteam geautoriseerd zijn om dat te doen wat het denkt dat het beste is. Als het projectteam niet deze macht heeft, werkt het cyclische projectmanagementmodel niet. Wanneer er tijdens een cyclus constant autorisatie nodig is van meerderen, zal dit leiden tot stagnatie. Bovendien weten buitenstaanders vaak niet goed wat er speelt omdat ze niet actief deelnemen in het projectteam, wat het voor hen moeilijk maakt zinnige beslissingen te nemen.

3. Projectresultaat (software) is opdeelbaar in kleinere delen
Bij cyclisch projectmanagement worden delen van het project uitgevoerd in een aantal cycli. Dat kan alleen als de te realiseren software opdeelbaar is in een aantal min of meer los van elkaar staande onderdelen.

4. Vanuit het management worden voornamelijk globale eisen ten aanzien van de software gesteld en niet direct concrete en specifieke eisen.
Een van de sterke punten van cyclisch projectmanagement is dat de klant, ontwerpers, programmeurs en eventueel testers nauw samenwerken binnen de cycli. Als er bij het project al direct in het begin heel specifieke en concrete eisen zijn gesteld aan de op te leveren software, dan belemmert dat de vrijheid van het projectteam om naar eigen inzicht ontwerpkeuzes te maken. Veel eisen aan een project blijken gaandeweg aangepast te moeten worden en moeten dus niet in het begin (te) vast liggen.

5. De activiteiten zijn voor de klant inzichtelijk
Als er binnen een cyclus veel technisch werk moet gebeuren, dat te moeilijk te begrijpen is voor de klant, bestaat er een risico dat hij niet in staat is goed mee te doen met het team. Hij heeft feitelijk niet veel in te brengen bij de ontwerp-beslissingen die genomen moeten worden.

Een dergelijk risico bestaat ook wanneer de voortgang voor de klant niet goed zichtbaar is. Bijvoorbeeld omdat er veel aan de code gewerkt is en minder aan de gebruikersinterface. Het is belangrijk dat de klant voldoende inzicht heeft in de inhoud en in de voortgang van een cyclus om ervoor te zorgen dat hij niet buiten spel komt te staan.

6. Een stap terug moet mogelijk zijn.
Ook bij cyclisch projectmanagement bewandelt het team soms een weg, waarvan men later moet concluderen dat het niet de juiste was. Dan moet het mogelijk zijn om een stap terug te doen. Als een nieuwe module is gemaakt in een cyclus en het blijkt dat hij niet bevalt, moet de oude module terug in gebruik kunnen worden genomen. Dit stelt met name eisen aan de archivering en documentatie van de projectmaterialen. CVS (Concurrent Versioning Systeem) of Subversion zijn hier bijvoorbeeld een nuttig hulpmiddel voor (zie bijlage 3 voor een lijst van hulpmiddelen).

7. Programmeurs moeten naast programmeren ook kunnen communiceren met klanten en vice versa. Teamleden moeten in staat zijn conceptueel te denken. Discipline is nodig om het testgericht werken vol te houden.

8. De organisatie waarbinnen het project plaatsvindt moet ook voldoende steun bieden aan deze manier van werken. Systemen voor tijdschrijven, archivering en planning zijn nodig om de projecten te ondersteunen. Deze registratiesystemen zorgen voor de transparantie welke nodig is voor een goede verdeling van resources over de projecten en in de tijd.

9. Projecten moeten voldoende prioriteit hebben, teamleden moeten worden vrijgemaakt voor projecten. Het werkt niet als teamleden in veel projecten tegelijk moeten werken. Als een organisatie onvoldoende ingesteld is op het werken met projecten dan zal de lenigheid van cyclisch projectmanagement eerder tot chaos leiden. Overigens is de watervalmethode ook gebaat bij een organisatie die ingesteld is op het werken met projecten (zie Wijnen, 2004, p. 111).

Een directeur van een softwarehuis die meer een visionair was dan een manager had bijna elke maand een goed idee en startte voortdurend nieuwe projecten in zijn bedrijf. Daardoor werden oude projecten nooit helemaal afgemaakt en deden de medewerkers soms wel vijf projecten tegelijk. De charismatische directeur had wel eens een boekje over rapid application development (RAD) gelezen en was er erg enthousiast over. Met name over het aspect ‘rapid’. Hij had boven het kopieerapparaat de uitgangspunten van RAD opgehangen en ging er vervolgens vanuit dat iedereen wel zou gaan werken volgens die uitgangspunten. Het was immers een prachtige methode.

Risico’s van cyclisch projectmanagement

Nu kan men opperen dat bij cyclische projectmanagementmethodes het zou kunnen voorkomen dat er onvoldoende tijd is voor het realiseren van de gewenste functionaliteiten. De hoeveelheid tijd is immers gefixeerd dus dat betekent dat er wellicht minder functionaliteit gemaakt zou kunnen worden dan aanvankelijk werd aangenomen.

Dit risico is inderdaad aanwezig, maar bestaat ook bij de watervalmethode. Bij de watervalmethode is er in de definitiefase een uitgebreide analyse van eisen en wensen. Op basis van die analyse zou je verwachten dat een betere planning van tijd mogelijk is. In de praktijk blijkt dit vaak niet het geval, om eerder genoemde redenen, en worden functionaliteiten uiteindelijk eveneens weggelaten, omdat het geld op is om ze te kunnen realiseren.

Bij cyclische methodieken wordt er op een pragmatische wijze omgegaan met eisen en wensen. Bijvoorbeeld door per cyclus de eisen en wensen in te delen volgens de MoSCoW regels (Stapleton, 2003):

• Must Have: eisen die essentieel zijn voor het systeem
• Should Have: belangrijke eisen die men graag wil
• Could Have: eisen die wenselijk zijn, maar die eenvoudig weggelaten kunnen worden
• Want to Have: but will not have this time round: eisen die wel kunnen wachten tot later

Ondanks dat het zou kunnen dat er voor bepaalde functionaliteiten geen tijd meer is, is de algemene consensus onder de projectmanagers van DANS dat cyclisch werken tot meer klanttevredenheid leidt dan de watervalmethode. In ieder geval worden de verwachtingen over en weer beter gemanaged en wordt er iets opgeleverd wat aantoonbaar werkt, al is dat wellicht minder uitgebreid dan aanvankelijk gehoopt.

Als nadeel van XP wordt vaak genoemd dat er veel macht bij de programmeurs komt te liggen. Als ze die macht misbruiken kunnen ze zich verschuilen achter het gebrek aan technische kennis bij de klant. Om dit te voorkomen is een sterke projectleider nodig die zowel de belangen van de programmeurs als die van de klant behartigt. Deze projectleider assisteert de klant bij het kiezen en plannen van de cycli, het inzichtelijk maken van de technische achtergronden bij keuzes en het uithanden nemen van administratie en rapportage.

Tenslotte kan nog als nadeel van XP worden aangehaald dat er een stijle leercurve is met betrekking tot de introductie van de methodiek bij zowel programmeurs, management als klanten.

Klik hier voor het oorspronkelijke artikel op Projectmanagement-training.nl.

Dit zijn de momenten waarop de projectleider met de opdrachtgevers om tafel moet om beslissingen ten aanzien van het project door te nemen. Het zijn de momenten waarop de GOKIT-factoren – waar nodig – bijgestuurd moeten worden. Als bijvoorbeeld is gebleken dat er in de definitiefase veel nieuwe onverwachte eisen op tafel zijn gekomen, kan het zijn dat een project veel duurder uitvalt. Het heeft dan geen enkele zin om door te gaan met de oude begroting.

De momenten na de fases zijn vaak tevens ‘go-no-go-momenten’, Momenten waarop besloten wordt of het project definitief doorgaat of stilgelegd wordt.

Figuur 6: Vijf belangrijke beslismomenten bij een project

Wat vaak gebeurt bij organisaties die niet met faseringen van projecten werken, is het volgende: in het begin wordt een projectplan geschreven, waarin de GOKIT factoren worden beschreven. Er is een tijdpad uitgezet (T), er is een budget opgesteld (G), een team is geformeerd (O), een doel is beschreven (K) en de hulpmiddelen voor de informatievoorziening in en rond het project zijn bepaald (I).
Tijdens het project controleert de projectleider nog wel of het project enigszins binnen het totale budget en tijdpad blijft, maar hij of zij stuurt niet echt bij. Tegen het einde van het project blijkt het allemaal toch weer duurder geworden of langer te duren dan verwacht. Om te voorkomen dat het nóg veel duurder wordt of langer duurt, wordt het project afgeknepen. Helaas is daardoor het projectresultaat niet echt naar tevredenheid.

Had de projectleider wel met het 6-fasenmodel gewerkt, dan had het team waarschijnlijk al in de ontwerpfase of misschien al in de definitiefase geconcludeerd dat het oorspronkelijke tijdpad en budget onvoldoende zou zijn. Als de projectleider dan bijgestuurd had, had men voor een eenvoudiger ontwerp kunnen kiezen dat sneller en goedkoper te realiseren zou zijn. Of men had om meer tijd en/of geld kunnen vragen bij de opdrachtgever. In ieder geval was er al maanden eerder duidelijkheid geweest over de status van het project. En was er sprake geweest van daadwerkelijk sturen van het project.

Onzekerheid in projectplannen

Onzekerheid hoort bij projecten. Men weet bij aanvang van het project niet precies hoeveel tijd nodig is, noch hoe duur het project exact zal uitpakken. Bij sommige projecten is het zelfs onzeker of het beoogde doel überhaupt bereikt zal worden. Dan komt het soms ook voor dat in een snel veranderende wereld de uitgangspunten van een project al veranderd zijn voordat een project klaar is. Bijvoorbeeld door technologische ontwikkelingen of ontwikkelingen in de markt of politiek.

Bij het maken van projectplannen kan de projectleider slechts schattingen maken van de GOKIT-factoren van een project. Schattingen van tijd, geld, team, kwaliteitsdoelen en benodigde informatie. Door het project uit te voeren ontstaat er meer kennis over het project zelf. In de initiatiefase is er alleen nog een idee. In de definitiefase is het idee verder afgebakend door middel van concrete eisen en wensen. In de ontwerpfase zijn er mogelijke ontwerpen onderzocht en gemaakt waardoor er weer meer duidelijk is. In de voorbereidingsfase weet men hoe het ontwerp gemaakt moet worden, in de realisatiefase is het daadwerkelijke projectresultaat gebouwd en in de nazorg zijn de losse eindjes aan elkaar geknoopt.

Hoe verder het project is, des te meer duidelijkheid er ontstaat. Het heeft daarom geen zin om in het begin van een project een nauwkeurige begroting te maken voor de nazorgfase die pas later plaatsvindt. Het project kan nog alle kanten op. Het idee is nog nauwelijks uitgewerkt. Waarschijnlijk is ook pas op hoofdlijnen bekend hoe de nazorg er uit moet komen te zien. Dat is te weinig informatie om een realistische, nauwkeurige begroting te kunnen maken van de nazorgfase. Een begroting op hoofdlijnen is op dat moment het maximaal haalbare.

De werkwijze in projectplannen is dus als volgt: er wordt een globale begroting voor het hele project gemaakt en een concrete begroting voor de eerstvolgende fase. Als een projectteam bijvoorbeeld vlak voor de realisatiefase staat (na de voorbereidingsfase), is heel goed bekend wat er moet gebeuren. Op dat moment is het mogelijk een nauwkeurige begroting van de realisatiefase te maken.

De globale begroting voor het totale project zal na elke fase bijgesteld moeten worden. Na elke fase is er meer kennis en zijn er besluiten genomen waardoor de globale begroting nader ingevuld kan worden. Op die manier wordt na elke fase de begroting van de totale kosten van het project steeds nauwkeuriger.

Het maken van een globale begroting voor het hele project en een concrete voor de eerstvolgende fase is niet alleen van belang voor de GOKIT-factor geld. Ook voor de andere factoren geldt dat er van globaal naar concreet wordt gewerkt.
Samenvatting begrotingen maken:

• vindt plaats vóór elke fase
• globale begroting voor het hele project opstellen of bijstellen
• concrete begroting maken voor de volgende fase
• alle GOKIT-factoren moeten opnieuw worden bekeken en begroot voor een nieuwe fase.

Door deze manier van begroten (met name van tijd en geld) wordt realistisch omgegaan met de onzekerheid die er meer in het begin en minder aan het einde van een project is. Het levert wel een probleem op voor organisaties die gefinancierd worden door overheidssubsidie en/of maatschappelijke fondsen. Dit geldt in het bijzonder voor organisaties die vernieuwende en dus onzekere projecten doen.

De meeste fondsen en subsidieverstrekkers eisen een complete en vaststaande begroting van een projectvoorstel vóórdat zij overgaan tot financiering. Dat betekent dat een organisatie die een project gefinancierd wil krijgen in een vroeg stadium al met een complete en concrete begroting moet komen. Maar in het begin is het project pas in de ideeënfase. Op dat moment is het dus helemaal niet mogelijk een reële inschatting van kosten en tijdpad te maken.

Pas na de ontwerpfase, als het idee nader is uitgewerkt en een ontwerp is gekozen, is er met voldoende nauwkeurigheid te zeggen hoeveel het project zal gaan kosten en hoe lang de uitvoering gaat duren. Dat moment is echter pas enkele maanden na het aanvraagmoment van de subsidie.

Het resultaat van deze werkwijze van subsidieverstrekkers en fondsen is dat veel organisaties een bedrag aanvragen op basis van een grove inschatting van de projectkosten. Vervolgens worden de projectactiviteiten ingesnoerd naar het verkregen budget. Dit zet het projectteam al klem bij de start van een project, terwijl er dan nog veel flexibiliteit nodig is.

Bij het uitwerken van het idee in de definitiefase en ontwerpfase blijkt dan vaak dat het tijdpad in de subsidieaanvraag niet haalbaar is. Het budget is niet passend, te veel voor sommige posten en meestal te weinig voor andere posten. Als de subsidieverstrekker dan ook nog eist dat er bijvoorbeeld niet meer dan 5% van de posten mag worden afgeweken, komt het projectteam onder grote druk te staan. Zaken moeten gerealiseerd worden binnen een te klein budget en in te korte tijd. Het leidt tot een hoop schuiven met posten. In de projectverantwoording is vervolgens veel tekst en analyses nodig waarom het gewenste resultaat niet bereikt is.

Deze situatie zou verbeteren als subsidieverstrekkers de financiering zouden koppelen aan de verschillende fases in plaats van in één keer vooraf te financieren. De initiële financiering zou dan zijn voor het doorlopen van de definitiefase en de ontwerpfase. Met een beperkt budget worden eisen en wensen nader uitgezocht en wordt een aantal alternatieve ontwerpen gemaakt. Op basis van deze ontwerpen wordt dan een vervolgaanvraag gedaan voor de realisatie en nazorg. Op deze manier worden projecten niet onnodig onder druk gezet. Bijkomend voordeel zou bovendien zijn dat de verwachtingen van betrokken partijen reëler wordt. Dat scheelt tijd, geld en teleurstellingen.

Klik hier voor het oorspronkelijke artikel op projectmanagement-training.nl.