Het resultaat van een project definieren

Je hebt de opdracht aangenomen. Je hebt inmiddels ook een goed beeld gekregen van de inhoud van het projectplan. Je kunt nu echt starten met schrijven. Je eerste stap is het resultaat definiëren: wat gaan we precies maken? Nu gaat je team fantasie, gezond verstand en goede bronnen gebruiken.

Kijkt iedereen naar dezelfde film?

Dit bepalen opdrachtgever en projectleider (soms samen met andere teamleden) samen. Het team zoekt uit of de opdrachtgever zijn doelen wel gaat bereiken met het resultaat dat hij zelf bedacht heeft. Iedereen moet het eindproduct (de marketingcampagne, de nieuwe helpdeskprocedure of het festival) als een film voor zich zien. Het is de bedoeling dat iedereen naar dezelfde film zit te kijken!

Eerst uitgebreid stilstaan WAT, daarna pas wie, hoe, waar, hoeveel…

Bij het aannemen van de opdracht is de business case bepaald. Het Waarom van het project is daarin heel concreet geworden. Nu ga je het Wat zo accuraat mogelijk uitwerken. De definitie van het resultaat en de eisen aan de kwaliteit zijn namelijk de belangrijkste onderdelen van het projectplan. Al het andere, de fasering en de beheersplannen voor Tijd, Geld, Organisatie en Informatie, worden door het Waarom en het Wat bepaald. Pas als je precies weet wat je moet maken, weet je welke activiteiten je moet uitvoeren. En pas dan kun je plannen hoeveel tijd, geld en mensen je daarvoor nodig hebt.

Resultaat in onderdelen?

Vaak levert een project meer dan één resultaat op. Bij voorbeeld een nieuw ontwerp voor de inpakprocedure van brood, een nieuw ontwerp voor de etiketten en een instructie voor de medewerkers. Benoem dan elk resultaat afzonderlijk en geef aan hoe ze met elkaar samenhangen. Is een nieuw etiket noodzakelijk voor de nieuwe inpakprocedure?

Resultaatdefinitie motiveert

Naast praktisch nut heeft een resultaatdefinitie ‘emotioneel’ belang. Een goede definitie motiveert zowel de opdrachtgever als het team om zich in te zetten. Wat zien we voor ons, waar werken we naartoe? Niet een ‘rapport’ (hoewel je je resultaat vaak wel in een rapport onderbouwd of maar een ontwerp voor een website gericht op jonge concertbezoekers, een nieuw productieproces voor stoelen van gerecycled plastic, een game voor senioren die veilig leren internetbankieren…

Onderzoek doen naar het WAT

Een doelstelling is niet hetzelfde als een resultaat. Heel vaak wordt dit in projecten door de war gehaald. Als poppodium Het Patronaat en de nieuwe bioscoop aan de overkant samen een festival voor jongeren organiseren is dat niet hun doel. Hun doelstelling is om meer jongeren naar concerten en de film te krijgen. Of misschien is het doel nog wel groter: Haarlem als uitgaansstad promoten. Het festival is een middel om dat doel te bereiken. Misschien zijn andere middelen wel effectiever? Daarom is het slim om het op te leveren resultaat nog eens kritisch te bekijken.

Voorleggen aan de opdrachtgever

Het projectteam kan met een alternatieve oplossing komen of adviseren het resultaat in onderdelen op te splitsen. In het geval van het Patronaatproject bijvoorbeeld een festival, publiciteitscampagne en een serie Idols-achtige shows die op de lokale tv komen. Laat de Plant zijn fantasie gebruiken en de Monitor bedenken of het idee goed in elkaar zit, de Zorgdrager de risico's analyseren en de Voorzitter en Brononderzoeker de opdrachtgever enthousiasmeren en overtuigen. De opdrachtgever kan al helemaal verknocht zijn aan zijn eigen idee. Dan heb je heel wat weerstand te overwinnen.

Terug naar Het Patronaat. De opdrachtgever is ongelukkig met de terugloop van het aantal jonge concertbezoekers. Hij denkt dat een festival als begin van een wervingscampagne de oplossing is. Als projectteam moet je je afvragen of de opdrachtgever daarmee echt geholpen is. Je stelt voor om eerst een probleemanalyse uit te voeren en een behoefteanalyse bij de doelgroep. Misschien blijkt dat de programmering niet aansluit bij de doelgroep, of dat jongeren de kaartjes te duur vinden. Is een festival om de bekendheid te vergroten dan wel de oplossing? Blijkt uit je onderzoek dat een festival weinig helpt, dan kun je een alternatief voorstellen. Wil de opdrachtgever toch per se een festival dan kan hij je niet verantwoordelijk stellen voor het bereiken van zijn doel. Je onderzoek heeft waarschijnlijk wel goede informatie opgeleverd voor gewenste invulling van zo’n event.

Programma van Eisen

De opdrachtgever brengt bepaalde eisen aan het resultaat in. Het projectteam doet onderzoek naar de haalbaarheid van die eisen en voegt zelf eisen toe die helpen om de doelen te bereiken.

Denk voor een festival aan:

• Er moet plaats zijn voor 1000 man
• Op 1000 man moeten er 25 wc’s zijn
• Maaltijden mogen niet meer dan € 8,50 kosten
• Het programma start om 14.00 eer en eindigt om 24.00 uur
• Tot 22.00 uur mag het lawaai 85 decibel zijn, na 22.00 uur is het maximum 70 dbel

Het team wordt gevraagd om juist hier zijn deskundigheid in te brengen. Na overleg stellen beide partijen de eisen vast in een Programma van Eisen dat onderdeel wordt van de Resultaatdefinitie.

Hoe kom je aan eisen?

De opdrachtgever heeft soms zelf al eisen (ook wel ‘specificaties’ of ‘kwaliteitscriteria’) bedacht die hij aan het team voorlegt. Het team verzamelt informatie en verdiept zich in on- en offline vakliteratuur (deskresearch), doet onderzoek in de organisatie van de opdrachtgever en in zijn omgeving om de eisen van de opdrachtgever verder te detailleren en om andere belangrijke eisen te vinden. Neem ook de tijd om uitgebreid te brainstormen! Maak voor dit onderzoek binnen je team een taakverdeling. En leg alles wat jullie aan nuttigs vinden vast in een bronnendossier.

Eisen verdelen in categorieën

Je kunt verschillende analyses uitvoeren om eisen te vinden. Je kunt de eisen in categorieën verdelen om het overzicht te houden. In volgorde van belangrijkheid:

• Randvoorwaarden

Uit deskresearch komen ook randvoorwaarden: aan welke wettelijke eisen moet het resultaat voldoen, zijn er milieunormen (lawaai bij een openluchtevenement) of veiligheidsbeperkingen? Het beleid van de organisatie kan ook randvoorwaarden opleveren. Je mag bijvoorbeeld alleen met partijen werken waarmee de organisatie een raamcontract heeft. Dit zijn voorwaarden waar noch jouw team, noch de opdrachtgever iets over te zeggen heeft. Iedereen MOET zich er gewoon aan houden. Verwar ze dus niet met de randvoorwaarden die de opdrachtgever stelt aan de uitvoering van het project.

• Functionele eisen

Uit een situatie- of probleemanalyse in de vorm van een SWOT-analyse, een onderzoek naar het ‘Probleem achter het Probleem’, research op internet of in vakliteratuur komen het gewenste resultaat en functionele eisen: wat moet het resultaat zijn en wat moet het kunnen zodat het probleem van de opdrachtgever is opgelost? Je denkt oplossingsgericht: Waarmee kunnen we de oorzaken van het probleem wegnemen? Is dit probleem in andere organisaties ook al opgelost? En hoe dan? Hiervoor kun je ook mensen in de organisatie interviewen of de productie of dienstverlening observeren.

• Operationele eisen

Uit een belangen- en behoefteanalyse komen operationele eisen: welke eisen stellen de doelgroep, de klanten of de gebruikers en andere partijen die er belang bij hebben? Vragen: Hoe gaan ze het bedienen of ervaren? Hoeveel willen ze betalen en waar willen ze het kopen? Wie gaan er last van hebben of moeten er rekening mee houden? Denk bij andere belangenpartijen aan leveranciers of medewerkers van andere afdelingen. Houd interviews en luister goed zodat je kunt concluderen wat echt belangrijk is voor het succes van je product.

• Ontwerpbeperkingen

Het team kan zichzelf ontwerpbeperkingen opleggen. Denk hierbij aan jullie eigen principes: je wilt met duurzame materialen werken, of alleen met open source software. Hieruit spreekt jullie visie op kwaliteit, op jullie vak en op de wereld.

Risicoanalyse

Ten slotte maak je met je team nog een risicoanalyse. Wat kan er mis gaan bij de uitvoering van het project? Wat kan het succes in de weg staan? Denk aan nieuwe politieke ontwikkelingen of faillissement van een leverancier... En met welke maatregelen ga je die risico's ondervangen? Bedenk ook wie voor die maatregelen verantwoordelijk zijn. Je kunt pas goede beheersplannen opstellen als je een risicoanalyse hebt gedaan.

Verfijnen en besluiten nemen in projectstart-up

Heb je het onderzoek afgerond, dan is het tijd voor de projectstart-up. Stel je hierbij voor dat het team, de opdrachtgever en soms ook nog externe experts een werkconferentie houden om de resultaatdefinitie te verfijnen, besluiten te nemen over de eisen en een start te maken met de planning.

SMART formuleren

Tijdens de projectstart-up presenteert het team de gevonden eisen. Je hebt pas iets aan eisen als ze concreet geformuleerd zijn. Als ze te vaag blijven, kun je ze niet als norm gebruiken. De standaardformule is ‘SMART’. Er zijn helaas geen regels te geven over hoe gedetailleerd je moet zijn. Dit is een kwestie van gezond verstand. Doe onderzoek, pas creatieve technieken toe in je team, bespreek de eisen met de opdrachtgever. Vermijd in elk geval ER-doelen! Check of iedereen hetzelfde bedoelt.

Uitstapje: docent als begeleider

Doe je een project in je opleiding, dan zijn er vaak een of meer docenten aanwezig om het proces te begeleiden en hun vakkennis in te brengen. Realiseer je dan dat dit onderzoek en het sparren met je docent over de eisen het meest leerzame deel van het project is. Als je docent tenminste zelf ook zijn huiswerk gedaan heeft. Is je plan klaar, dan hoef je het alleen nog maar uit te voeren en dat kan een stuk minder spannend zijn…

Besluiten over prioriteiten

Niet alle eisen zijn even belangrijk. Maak op zijn minst onderscheid tussen ‘noodzakelijk’ (‘als het hier niet aan voldoet, halen we het doel niet) en ‘wenselijk’ (zou mooi zijn, maar kan zonder). Kom je in tijd- of geldnood, dan kun je met de opdrachtgever besluiten de wenselijke eisen te laten vallen. Er zijn verschillende methoden om een oordeel te vormen over prioriteiten en vervolgens een besluit te nemen. Denk aan MOSCOW:

1. Must have (randvoorwaarden en functionele eisen)
2. Should have (deel van operationele eisen)
3. Could have (deel van operationele eisen)
4. Would have (ontwerpbeperkingen)

Randvoorwaarden schrijven

In het projectvoorstel heb je al met de opdrachtgever besproken onder welke randvoorwaarden het project moet worden uitgevoerd. Als de Resultaatdefinitie rond is, stel je samen de randvoorwaarden bij. Uit je onderzoek blijkt bijvoorbeeld dat het resultaat dat de opdrachtgever graag wil toch niet haalbaar is in de tijd die hij geeft of met het budget dat hij heeft gereserveerd.

Resultaat of randvoorwaarden veranderen

Stel dat de opdrachtgever wil werken met de machines die hij nu in zijn hal heeft staan, want die zijn nog niet afgeschreven. Uit je onderzoek komt dat deze toch niet geschikt zijn voor het product dat hij wil maken. Wil hij toch per se die machines handhaven, dan moeten de eisen aan het product aangepast worden zodat de machines wel bruikbaar zijn.

Wie kan het regelen?

Andersom kun jij als team ook voorwaarden aan de opdrachtgever stellen. Je kunt bijvoorbeeld alleen dat festival organiseren als de opdrachtgever zijn podiumapparatuur beschikbaar stelt en garandeert dat deze goed functioneert of ervoor zorgt dat alle vrijwilligers op die dag beschikbaar zijn. Dat wat niet binnen jouw macht ligt, maar binnen de macht van de opdrachtgever en noodzakelijk is voor een goed resultaat, moet in de Randvoorwaarden komen te staan.De opdrachtgever maakt de afweging welk resultaat hij wil en onder welke voorwaarden dat voor hem haalbaar is. Daar kom je na enig onderhandelen uit en dan leg je de Randvoorwaarden vast.

Plannen op basis van Resultaatdefinitie

Is helemaal duidelijk wat je team gaat maken, en onder welke Randvoorwaarden, dan kun je overstappen naar de planning van je project: wie gaat wat doen…

Auteur: Isabelle Langeveld