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 Documentation 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 zorg dragen 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.

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.