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.
