Een Project Charter schrijven dat de stuurgroep goedkeurt

De meeste project charters worden niet afgekeurd omdat ze slecht geschreven zijn. Ze worden afgekeurd omdat een lid van de stuurgroep een vraag stelt die het document niet beantwoordt, en dan volgt er een tweede ronde. Dat kost twee weken. De secties hieronder zijn precies de secties waar die vragen vandaan komen.

Wat een project charter formeel doet

Een charter autoriseert een project. Dat is een juridisch-organisatorische handeling, geen communicatiemiddel. Het legt vast dat een specifieke persoon budget en mandaat vrijgeeft aan een specifieke projectmanager, binnen specifieke grenzen, voor een specifiek resultaat.

Die vier woorden — persoon, mandaat, grenzen, resultaat — zijn de test. Kun je ze alle vier binnen dertig seconden uit je charter halen? Zo niet, dan is het een projectbeschrijving en geen charter.

In PRINCE2 is de rolverdeling scherper dan in PMBOK. Wat PMBOK het charter noemt, valt in PRINCE2 uiteen in de Project Brief (opstartfase) en de Project Initiation Documentation (initiatiefase). Werk je in een organisatie die PRINCE2 zegt te volgen maar één document wil, maak dan expliciet welke van de twee je levert. Anders krijg je halverwege het verwijt dat er "geen PID" is.

De zes secties waar het misgaat

1. Doelstellingen die niet meetbaar zijn

"Het verbeteren van de klanttevredenheid" is geen doelstelling, het is een richting. Een stuurgroep kan niet beoordelen of dat is gehaald, dus kan het project nooit formeel worden afgesloten.

Een bruikbare formulering bevat een grootheid, een startwaarde, een streefwaarde en een meetmoment: "De NPS onder zakelijke klanten stijgt van 12 naar 25, gemeten in het kwartaalonderzoek van Q3 2027." Ontbreekt de startwaarde, dan is er geen nulmeting en discussieer je achteraf over het referentiepunt.

Weet je de startwaarde niet? Zet dat er dan zo in — "nulmeting uit te voeren vóór 1 oktober; streefwaarde wordt daarna vastgesteld" — in plaats van een getal te verzinnen dat later niet blijkt te kloppen.

2. Scope die alleen zegt wat er wél gebeurt

Elke scopeparagraaf heeft twee helften. De helft die iedereen schrijft is "binnen scope". De helft die de ruzies voorkomt is "buiten scope".

Zet er expliciet in wat mensen redelijkerwijs zouden kunnen verwachten maar niet krijgen. Bij een uitrol van laadinfrastructuur: geen vervanging van het wagenpark, geen zonnepanelen, geen beheer na oplevering. Bij een systeemmigratie: geen datamigratie ouder dan vijf jaar, geen aanpassing van rapportages, geen training van eindgebruikers.

De regel: als iemand het zou kunnen aannemen, hoort het in "buiten scope". Wat er niet staat, wordt later gratis verwacht.

3. Ontbrekende toleranties

Dit is de sectie die in PRINCE2-organisaties het vaakst leeg blijft en die het hardst gemist wordt.

Een tolerantie is de speelruimte waarbinnen de projectmanager zelfstandig mag beslissen. Zonder toleranties moet je voor elke afwijking terug naar de stuurgroep, of — realistischer — beslis je zelf en ontdekt de stuurgroep het achteraf. Beide zijn slecht.

Leg minimaal vast: kostentolerantie (bijvoorbeeld ±10%), tijdtolerantie (bijvoorbeeld +4 weken op de einddatum), en scopetolerantie (welke deelresultaten mogen sneuvelen als het knelt en welke absoluut niet). Voeg toe wat er gebeurt als een tolerantie dreigt te worden overschreden: een Exception Report binnen vijf werkdagen, gevolgd door een besluit van de stuurgroep.

4. Stakeholders zonder rol

Een lijst met namen en afdelingen is geen stakeholderanalyse. Wat de stuurgroep nodig heeft, is wie waarover beslist.

Gebruik een RACI-tabel op deelresultaatniveau, niet op projectniveau. "Wie is verantwoordelijk voor het project" levert altijd hetzelfde antwoord op. "Wie accepteert de opgeleverde netaansluiting" is de vraag die zes maanden later voor vertraging zorgt.

Let op de klassieke fout: precies één A (accountable) per rij. Twee A's betekent dat niemand beslist.

5. Risico's zonder eigenaar en zonder respons

Een risicoregister met alleen beschrijvingen is een zorgenlijst. Een bruikbaar register heeft per risico vijf kolommen: beschrijving, kans, impact, responsstrategie en eigenaar.

De responsstrategie is er één van vier: vermijden (de oorzaak wegnemen), beperken (kans of impact verkleinen), overdragen (verzekeren of contractueel bij een leverancier leggen), of accepteren (bewust niets doen en een reservering aanhouden). "Monitoren" is geen strategie; dat is uitstel.

De eigenaar is een persoon, geen afdeling. "Inkoop" belt niemand terug.

6. Aannames die als feiten zijn opgeschreven

Als de brief zegt "de bestaande netaansluitingen hebben voldoende capaciteit" en niemand heeft dat getoetst, dan is dat een aanname en hoort het in de sectie Aannames — niet in de achtergrond alsof het vaststaat.

Dit is het verschil tussen een charter dat je later beschermt en een charter dat tegen je wordt gebruikt. Aannames die expliciet zijn vastgelegd en zijn goedgekeurd, verschuiven het risico naar de stuurgroep. Aannames die je stilzwijgend als feit hebt opgeschreven, blijven van jou.

Een werkbare hoofdstukindeling

Deze volgorde werkt in zowel PRINCE2- als PMBOK-omgevingen en laat zich makkelijk aanpassen aan een bedrijfstemplate:

Werkt jouw PMO met een vast sjabloon, houd dat dan aan. Een charter dat afwijkt van de huisstijl krijgt commentaar op de vorm in plaats van op de inhoud, en dat kost een ronde.

Voordat je verstuurt

Loop deze vijf punten na. Ze vangen het merendeel van de tweede rondes af.

Staat er bij elke doelstelling een getal en een meetmoment. Bevat de scopesectie minstens drie punten onder "buiten scope". Staat er bij elk risico een naam van een persoon. Zijn de toleranties in getallen uitgedrukt en niet in woorden als "beperkt". Is elke aanname die niet is geverifieerd ook daadwerkelijk als aanname gemarkeerd.

Kun je op alle vijf ja zeggen, dan is de kans groot dat de vragen uit de stuurgroep over inhoud gaan en niet over gaten.