De projectdefinitie beschrijft waar het om draait bij het project, de kern zeg maar. Het is het antwoord op de essentiële vraag: “Wat leveren we aan het einde van het traject op?” Daarnaast vertelt het waarom we dat doen, wat ermee bereikt moet worden, voor wie het belangrijk is en waar rekening mee gehouden moet worden. Stuk voor stuk cruciale zaken voor de opdrachtgever, projectleider, -team en alle andere belanghebbenden.

Eerst denken, dan doen 

Op een nieuw project wordt vaak enthousiast gereageerd. Iedereen heeft er zin in en wil zo snel mogelijk aan de slag. Maar ook hier geldt het aloude adagium ‘bezint eer ge begint’. Het heeft geen zin om met elkaar een ladder op te klimmen om er eenmaal boven achter te komen dat je op het verkeerde dak staat. Een goede projectdefinitie zorgt ervoor dat in ieder geval de belangrijkste spelers dezelfde kant op willen, dat er ‘wilsovereenstemming’ is. Is die er niet, dan is er ook geen gedeelde projectdefinitie en dus ook geen project. De projectdefinitie ‘dwingt’ je als het ware om eerst een heldere koers uit te zetten.

Twee werelden verbinden

De meeste opdrachtgevers leven in een andere (bestuurlijke) wereld dan de projectleider en het -team. Er gelden daar andere regels en woorden als ‘resultaat’ en ‘helderheid’ hebben daar een andere betekenis. De projectleider zal ervoor moeten zorgen dat beide werelden aan elkaar worden gekoppeld. Hij moet zorgen voor wederzijds begrip en een minimum aan ruis. De projectdefinitie helpt daarbij.

De 9 elementen van de projectdefinitie

De Projectdefinitie bestaat uit negen, onderling samenhangende elementen. Dit zijn:

1. Uitdaging of probleem

Waar gaat het precies om? Is het een kans die je wil benutten of een probleem dat opgelost moet worden? Met behulp van onderstaande vragen weet je of je een goede probleemstelling te pakken hebt:

• Wat gaat er mis als er aan de huidige situatie niets gedaan wordt? Heel veel ‘problemen’ bestaan vaak al jaren in organisaties, zonder dat dat echt erg was. Of er is al van alles geprobeerd. Dus wat is dan het echte probleem dat opgelost moet worden?
• En als het allemaal wel erg genoeg is, lukt dat dan door dit project nu op te starten? Is het antwoord daarop negatief, dan moet de uitdaging minder ruim geformuleerd worden.

2. Urgentie

Waarom nú? Waarom is het niet een half jaar eerder al opgepakt? En wat als we nog even wachten, is dat dan erg? Hoeveel prioriteit heeft het? Wie zit er eigenlijk op te wachten? De urgentie kan consequenties hebben voor de planning, aandacht en het geduld van de opdrachtgever en andere stakeholders.

3. Doel

Wat is het doel, de achterliggende reden voor het project? Soms zijn er zelfs meerdere doelstellingen te benoemen. Zolang ze niet tegenstrijdig zijn, kan dat. Betrokkenen kunnen zo hun eigen redenen hebben om een project belangrijk te vinden. Dan helpt het wel als iedereen zich in de projectdefinitie kan vinden.

4. Resultaat

De omschrijving van het resultaat moet antwoord geven op de vraag: wat hebben we precies in handen als we met het project klaar zijn? En daarmee moet het resultaat concreet, tastbaar en zichtbaar zijn. Als het moet, kunnen dat ook meerdere (deel) resultaten zijn. ‘Grotere klanttevredenheid’ of ‘het bevorderen van een efficiëntere aanpak’ zijn niet tastbaar en dus géén resultaten. Dat zijn doelstellingen (zie doelstelling) of positieve effecten (zie effecten).

Wees realistisch als het gaat om het omschrijven van resultaten. De projectleider is verantwoordelijk voor het halen ervan. Lukt het niet, dan heeft de projectleider het niet goed gedaan. Dat is vervelend voor de projectleider. Aan de andere kant, verstevigt deze resultaatverantwoordelijkheid ook zijn positie in allerlei onderhandelingen rond het project. Want wie verantwoordelijk is, mag ook eisen stellen. Dat niet alle projectleiders en opdrachtgevers daar voldoende van doordrongen zijn, is een ander verhaal. Dat komt aan bod in de modules opdrachtgeverschap en persoonlijk leiderschap.

5. Afbakening

Ofwel, wat lever je niet op? Dit zijn de dingen die je in het project buiten beschouwing laat, die je niet gaat doen of waar je niet achteraangaat. Soms verzet de cultuur van de organisatie zich tegen zo’n ‘negatieve’ opsomming. Toch is het belangrijk: je stuurt ermee de verwachtingen van de opdrachtgever en andere stakeholders. Vaak leidt het tot een soort onderhandeling tussen projectleider en opdrachtgever over de reikwijdte van het project en dat is precies wat we willen. Het verscherpt de opdracht.

Bovendien levert het een mooie check op: als het team de geformuleerde resultaten oplevert en een ander, nog te starten, project zou zorgen voor de ‘wat-niet-lijst’ uit de afbakening, dan zou het probleem opgelost moeten zijn. Is dat niet zo, dan is het zaak om nog eens naar de vraag uit de projectdefinitie te kijken, naar het geformuleerde resultaat of toch naar de hier genoemde afbakening.

6. Effecten

Naast het resultaat van je project, dat wat je ermee voor ogen hebt, kan een project ook andere consequenties hebben. Dat noemen we de (neven)effecten. Deze kunnen zowel positief dan wel negatief of bedoeld dan wel onbedoeld zijn. Positief bedoeld zijn effecten die in lijn liggen met de beoogde doelstelling. Positief onbedoeld zijn effecten die je als bijvangst kunt zien. Met andere woorden, daar zet je niet actief tijd, geld of mensen op in en helpt als zodanig bij de afbakening. Wel kunnen ze achteraf nog tot ‘bedoeld effect’ gepromoveerd worden, als blijkt dat de opdrachtgever het toch heel interessant vindt.

Negatief onbedoelde effecten vragen (later) om een nadere risicoanalyse. Bedoelde negatieve effecten bestaan niet. Dat leidt soms tot verwarring. Stel een project is gericht op het terugdringen van de structurele loonkosten, dan is het afnemen van het aantal formatieplaatsen heel vervelend voor de werknemer, maar het is geen bedoeld negatief effect. Wel kun je deze categorie effecten beschouwen als mogelijk ‘bijkomende (acceptabele) schade’ en dat helpt in verwachtingsmanagement.

Het verschil tussen de effecten en de resultaten van een project is soms een lastige, maar wel een heel belangrijke. De projectleider is verantwoordelijk voor de resultaten, ongeacht of daarmee de beoogde effecten behaald worden. Alleen denkt het opdrachtgevend systeem daar meestal heel anders over. Dat is vaak – terecht – meer geïnteresseerd in de effecten dan in de resultaten. Het is daarom voor een projectleider van essentieel belang om ervoor te zorgen dat de resultaten die het project oplevert ook werkelijk gaan leiden tot de gewenste effecten. Mochten daar twijfels over zijn, dan is het zaak voor de projectleider om een stevig gesprek te hebben met de opdrachtgever over de vermeende oorzaak-gevolg relatie tussen resultaat en effect.

Een lastig aspect van veel effecten is bovendien dat ze niet alleen beïnvloed worden door het projectresultaat, maar ook nog door heel veel andere omstandigheden. En deze andere omstandigheden bevinden zich lang niet altijd binnen ‘de cirkel van invloed’ van de projectleider en zijn team. Neem bijvoorbeeld gebruikers en lijnmanagers; zij kunnen bepalend zijn. En daarmee hebben we gelijk een van de spannendste dilemma’s van PMC te pakken. Want hoe ga je om met beoogde effecten, waarvan je weet dat je erop beoordeeld gaat worden, terwijl je de realisatie ervan niet kan garanderen of afdwingen? Helemaal is dat niet op te lossen, maar wat je wel kan doen is:
• In de afbakening scherp verduidelijken waarvoor je niet verantwoordelijk wil of kan zijn.
• Met de opdrachtgever afspreken waar zijn verantwoordelijkheid ligt ten aanzien van de beoogde effecten. De opdrachtgever heeft vaak meer middelen beschikbaar om die effecten af te dwingen dan de projectleider.
• In je activiteitenplan bewust ‘extra’ activiteiten opnemen die het waarschijnlijker maken dat de beoogde effecten gerealiseerd worden.

7. Gebruikers van het eindresultaat

Wie is de doelgroep of de klant? Kunnen we daarin nader specificeren? Wie zijn het die uiteindelijk van het project gaan profiteren? Maar ook: wie hebben er (potentieel) last van? Beiden gelden als ‘gebruikers’ en verdienen het (ten minste) om gehoord te worden. Aard en omvang van deze lijst heeft belangrijke consequenties voor thema’s als stakeholdermanagement, het opdrachtgevend systeem, projectorganisatie, teamsamenstelling en risicomanagement.

Een individu of partij opnemen in de lijst van gebruikers is niet hetzelfde als iemand ook een rol geven in de oordeels- of besluitvorming over het project. Wat prima is, zolang de beslissing om iemand daar niet in op te nemen, een bewuste is en niet het gevolg van een niet goed doordachte projectdefinitie.

8. Randvoorwaarden

Randvoorwaarden zijn onwrikbare eisen van de opdrachtgever, die meestal betrekking hebben op kwaliteit, budget en planning. Het zijn afspraken waar niet zomaar aan getornd mag worden. Als de omstandigheden wijzigen, zijn ze wellicht bespreekbaar, maar tot er andere randvoorwaarden worden vastgesteld, gelden ze als ‘een streep in het zand’.

Wel moet de projectleider zich afvragen of hij onder de gestelde voorwaarden het project uit wil en kan voeren. Ook is het interessant om te kijken naar wat het team (absoluut) nodig heeft om het project succesvol te laten zijn; wat zijn daar eigenlijk de randvoorwaarden? Is er bijvoorbeeld een minimale beschikbaarheid van teamleden voor deze opdracht nodig of financiële ruimte om specifieke expertise in te huren? Wil je daar aan de voorkant afspraken over maken met de opdrachtgever, moeten ze als randvoorwaarde terugkomen in de projectdefinitie.

9. Relaties met andere projecten, programma's en activiteiten

Van welke andere projecten of activiteiten ben je afhankelijk en welke projecten zijn afhankelijk van jou. Heb je bijvoorbeeld van elkaar gegevens nodig, dan doet zich al snel een aantal afstemmingsvragen voor. Ook zou het niet de eerste keer zijn dat een opdrachtgevend systeem gelijktijdig twee of meerdere projecten in gang zet, die vrijwel hetzelfde beogen te bereiken. Het helpt dan zeer als je daarvan op de hoogte bent. Het is tevens een kans om te kijken of jouw, het andere project, of allebei elkaar kunnen versterken of versnellen.

Projectdefinitie als een kompas

Ondanks dat het zinvol is om voorafgaand aan de start van het project alle negen elementen zo helder mogelijk te formuleren, is een projectdefinitie niet in beton gegoten. Er kan gedurende het hele project nog van alles gebeuren, waardoor allerlei zaken veranderd, aangepast of herzien moeten worden. En dat is prima. In die zin is PMC heel ‘agile’. Er geldt eigenlijk maar een voorwaarde: er mag geen onduidelijkheid bestaan over de actuele inhoud. De projectdefinitie fungeert als kompas voor de verdere uitwerking van het project.

Drie keer is scheepsrecht

Een projectdefinitie wordt meestal in drie rondes opgesteld, namelijk:

1. Projectopdracht als startsein
In de initiatieffase wordt bekeken of het vraagstuk wat op tafel ligt ook inderdaad (het beste als project) opgepakt kan/moet worden. Dit doen de (beoogde) opdrachtgever en projectleider. Als dat een ja is, zijn zij ook degenen die de projectopdracht of briefing schrijven. Dit is dan een eerste, globale omschrijving van het project en zie je in de praktijk ook terugkomen in de vorm van een startnotitie, project-initiatie-document (PID), memo of projectopdracht. Meestal bevat deze al meerdere elementen van de projectdefinitie, zoals de uitdaging/probleemstelling, urgentie, resultaten en beoogde positieve effecten.

Overeenstemming over de projectopdracht wordt doorgaans gekoppeld aan het formele besluit om de definitiefase te starten. In die fase werkt een projectteam de briefing verder uit tot een volwaardige projectdefinitie, waarin alle negen elementen aan bod komen.

2. Projectdefinitie als uitkomst van de collectieve intake
Op basis van de (goedgekeurde) projectopdracht vindt, tijdens de Projectstart-up, de collectieve intake plaats. De concept projectdefinitie (briefing), op papier, is daarbij een handig instrument om de teamleden mee te nemen in het verhaal. Zo voorkom je de bekende 'fluisterspelvalkuil'. Het spel waarbij er bij iedere (fluister)stap steeds een beetje informatie verloren gaat… De collectieve intake is een gesprek tussen de opdrachtgever en het projectteam. Het doel is om helder te krijgen wat het project precies inhoudt en hoe dat aangepakt moet worden. En om daar te komen, moet je vragen, vragen, vragen.

3. Definitieve projectdefinitie (nou ja, voorlopig…)
Nu dat de bedoeling duidelijk is, kunnen vervolgens de activiteiten- en beheersplannen gemaakt worden. Meestal wordt aan de hand daarvan de projectdefinitie verder aangescherpt, waarna deze formeel in het projectcontract kan worden opgenomen. Tijdens de uitvoering van een project blijft het natuurlijk altijd mogelijk om, op basis van nieuwe inzichten, de projectdefinitie aan te passen. Inclusief de consequenties daarvan voor budget, planning of kwaliteitseisen. Maar dit kan alleen in het volle daglicht en transparant voor alle betrokkenen.

Gewoon maar vast beginnen

We zeiden het al aan het begin: vaak willen opdrachtgever, projectleider en teamleden zo snel mogelijk aan de slag. De opdracht is nog nieuw, het enthousiasme groot. Doen krijgt dan al snel voorrang boven denken. En dat is begrijpelijk, maar dat maakt het nog geen goed plan. Sterker nog: het is een kenmerk van een goede projectleider om de rug recht te houden en niet van start te gaan voordat de projectdefinitie helemaal is uit onderhandeld en er geen speld meer tussen te krijgen is. En pas nadat de vertaling heeft plaatsgevonden naar tenminste een grof activiteitenplan, met indicaties voor tijd en budget.

Waarom? Omdat je helderheid en eenduidigheid nodig hebt om in een project effectief en efficiënt te kunnen zijn. Omdat impliciete verwachtingen eerst expliciet moeten worden gemaakt om ermee te kunnen werken. We besteden daarom relatief veel tijd en energie ‘aan de voorkant’ van een project, opdat het vervolg gesmeerd verloopt.

Dan nog even dit

Een van de vele misvattingen rond ‘agile werken’ is dat het gaat om eerst maar eens ‘aan de slag gaan’ en dat de richtinggevende keuzes ‘werkende weg’ wel volgen. In de praktijk leidt dit vooral tot onduidelijkheid en (mogelijke) verspilling van tijd en energie. Of, om met de Kollumer kat uit Alice in Wonderland te spreken: ‘Als je niet weet waar je heen wilt, kom je altijd wel ergens uit. Als je maar lang genoeg doorloopt.’ Dat heeft echter meer te maken met een ondoordachte en slecht voorbereide start van een project dan met agile, in de zin van de bereidheid om je project(resultaat) aan te passen aan nieuwe of veranderde omstandigheden.