De zes fasen van projectmanagement

In dit hoofdstuk wordt de traditionele wijze van projectmanagement geschetst. Het model dat hier besproken wordt, vormt de basis voor veel projectmanagementmethodes.

Om een project in zo goed mogelijke banen te leiden, is het nuttig het project op te delen in fasen. Door het faseren van het project, wordt het totale werk opgedeeld in kleinere delen, die daardoor makkelijker te overzien zijn. Hieronder wordt een faseringsmodel gegeven dat in de praktijk zijn nut heeft bewezen. Het werkt met zes fases:

1. Initiatiefase
2. Definitiefase
3. Ontwerpfase
4. Voorbereidingsfase
5. Realisatiefase
6. Nazorgfase

Initiatiefase

De initiatiefase is het begin van het project. In deze fase wordt een idee voor een project nader onderzocht en uitgewerkt. Doel van deze fase is te onderzoeken of het project wel haalbaar is. Verder wordt er gekeken wie het project zou kunnen uitvoeren, welke partij(en) betrokken zouden moeten zijn bij het project en of er voldoende draagvlak is voor het project (bij betrokkenen).

De (beoogde) projectleider maakt in deze fase een projectvoorstel waarin hij bovenstaande zaken beschrijft. Een businessplan of subsidieverzoeken zijn voorbeelden van dergelijke projectvoorstellen. Diegenen die het project sponsoren zullen het projectvoorstel beoordelen en bij goedkeuring de financiering verzorgen. Vanaf die goedkeuring is het project officieel gestart.

De vragen die beantwoord moeten worden in de initiatiefase zijn:

• Waarom dit project?
• Is het project haalbaar?
• Wie zijn eventuele partners in dit project
• Wat moet het resultaat zijn?
• Waar liggen de grenzen van het project (wat hoort er niet meer bij het project?

Een belangrijke kwaliteit van een projectleider is dat hij goed ‘nee’ kan zeggen. Als mensen eenmaal enthousiast worden voor een project heeft dat de neiging steeds groter te worden. ‘Als we nu toch bezig zijn, dan kunnen we net zo goed er ook voor zorgen dat…’, is dan de gedachtegang. Een project waarbij men steeds meer wil en dat zich steeds uitbreidt, zal vrijwel zeker uit de planning lopen en waarschijnlijk nooit het doel bereiken.

In de initiatiefase gaan de projectpartners een (tijdelijke) relatie met elkaar aan. Om te voorkomen dat er verkeerde verwachtingen over de resultaten van een project ontstaan is het verstandig om expliciet af te spreken wat voor een soort project er gestart wordt:

• Een research & development project
• Een project om een prototype of ‘proof of concept’ te leveren
• Een project dat een werkend product op gaat leveren

De keuze voor een project bepaald in hoge mate het resultaat van een project. Een research & development project levert bijvoorbeeld een rapport op waarin onderzocht wordt of een toepassing technisch haalbaar is. Een project waarin een prototype ontwikkeld wordt levert alle functionaliteit van een applicatie maar hoeft nog niet geschikt te zijn voor bijvoorbeeld honderden gebruikers. Een project wat een werkend product oplevert dient ook rekening te houden met het regelen van onderhoud, handleidingen en het functionele beheer van een applicatie.

Veel misverstanden en/of conflicten ontstaan omdat de partijen over en weer dit niet helder voor ogen hebben. De klant verwacht een werkend product terwijl het projectteam denkt een prototype te moeten leveren. De financier denkt dat het project een werkend stuk software oplevert, terwijl het projectteam eerst moet onderzoeken of het überhaupt technisch kan.

Definitiefase

Nadat het projectplan, dat gemaakt is in de initiatiefase, 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 erom de verwachtingen van betrokken partijen boven water te krijgen over wat men denkt dat het resultaat moet zijn. Hoeveel bestanden moeten er gearchiveerd gaan worden? Moet de metadata voldoen aan het Data Documenta-tion Initiative (DDI) formaat of volstaat het Dublin Core (DC) formaat? Mogen bestanden in hun originele formaat gedeponeerd worden of worden slechts ‘Preferred Standards’ geaccepteerd? Moet de depositor van een dataset zorgdragen voor een correcte verwerking van een dataset in het archief of is dit de verantwoordelijkheid van een archivaris? Welke garanties worden gegeven op het projectresultaat? Enzovoort.

Verwachtingen project

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 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.

Ontwerpfase

Met de eisen- en wensenlijst uit de definitiefase kunnen ontwerpkeuzes worden gemaakt. In de ontwerpfase wordt er een ontwerp of worden er enkele ontwerpen gemaakt waarmee men denkt het projectresultaat te kunnen bereiken. Afhankelijk van waar het project over gaat, valt dan te denken aan maquettes, schetsen, flowcharts, site-trees, html-schermontwerpen, prototypen, foto-impressies, UML-schema’s en dergelijke.

Uit de gemaakte ontwerpen wordt door de bestuurders van het project een keuze gemaakt voor het definitief te realiseren ontwerp. Dan start de voorbereidingsfase. Ook hier geldt dat een ontwerp als het eenmaal gekozen is, in een later stadium van het project niet meer gewijzigd mag worden.

Bij een jonge organisatie waar het er erg informeel aan toe ging, werd de afdeling design geleid door een kunstenaar. Er kon eigenlijk niet echt gesproken worden van een ‘afdeling design’, meer van een groep samenwerkende designers. Daarbij kwam dat iedereen het veel te druk had, het hoofd van de afdeling inclusief.

Voor een project moesten er ontwerpen gemaakt worden. Die ontwerpen waren erg belangrijk voor het slagen van het project. Een jonge ontwerper die lid was van het projectteam maakte de ontwerpen. Het hoofd van de designafdeling was eindverantwoordelijk voor de ontwerpen. Maar hij kwam nooit op de vergaderingen van het projectteam opdagen, als de ontwerpen besproken werden. De projectleider nodigde hem wel altijd uit en stuurde hem ook e-mails met de schetsen van zijn jonge collega. Er kwam nooit een reactie op. De projectleider en de jonge designer gingen er onterecht vanuit dat het hoofd design de ontwerpen goedkeurde. Vervolgens startte de realisatiefase. Toen het project bijna klaar was, kreeg het hoofd design het resultaat te zien. Hij reageerde woedend en vond dat het helemaal opnieuw moest gebeuren. Alleen was toen het budget nagenoeg op.

Voorbereidingsfase

In de voorbereidingsfase wordt alles geregeld dat nodig is voor de realisatie van het project. Eventuele leveranciers of onderaannemers worden ingeschakeld, een draaiboek wordt gemaakt, materialen en hulpmiddelen worden besteld, instructies aan het personeel worden gegeven, enzovoort. De voorbereidingsfase is klaar als het uitvoeren ‘zo’ kan starten. Alles moet dus duidelijk zijn voor de uitvoerende partijen.

In sommige, met name wat kleinere projecten, is een formele voorbereidings-fase wellicht overbodig. Het gaat erom dat duidelijk is wat er moet gebeuren in de realisatiefase, door wie en op welk moment.

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.