Een project is geslaagd — maar volgens welke maatstaf?
Aan het einde van een project valt bijna altijd een oordeel: geslaagd, deels geslaagd, mislukt. Opvallend is hoe vaak pas op dát moment wordt bepaald wat succes betekende. Er wordt teruggekeken naar wat er ligt, en van daaruit wordt de lat neergezet. Dat is geen evaluatie, dat is een verklaring achteraf — en de uitkomst staat dan al vast voordat de vraag is gesteld.
Eén bouwsteen uit vier onafhankelijke kaders
Vier evaluatiekaders — OECD DAC (breed toegepast, overdraagbaar kader, oorspronkelijk ontwikkeld voor ontwikkelingssamenwerking), de Britse Gate 5-toets, de PRINCE2-praktijk en het CIPP-model van Stufflebeam — zijn onafhankelijk van elkaar tot dezelfde bouwstenen gekomen. Eén daarvan: criteria die vooraf zijn vastgesteld, niet achteraf. Naast het toetsen van baten tegen de oorspronkelijke belofte en onafhankelijke validatie, is dit een van de terugkerende elementen waar deze kaders los van elkaar op uitkomen.
De logica is simpel. Zodra de criteria pas na oplevering worden geformuleerd, is er geen vergelijking meer mogelijk tussen belofte en resultaat — alleen nog een beschrijving van het resultaat zelf, ingekleurd door wat er nu eenmaal is opgeleverd.
Waarom dit in de praktijk misgaat
Bij de start van een project wordt succes vaak vaag omschreven: "een werkend systeem", "tevreden gebruikers", "binnen budget en planning" — zonder dat wordt vastgelegd wát dat concreet betekent en wanneer dat wordt getoetst. Tegen de tijd dat het project klaar is, is de context veranderd, is scope bijgesteld, zijn er nieuwe stakeholders — en wordt de invulling van "succes" daarop aangepast. Niet uit kwade wil, maar omdat er nooit een vaste referentie was om tegen te toetsen.
Het gevolg is een evaluatie die vooral bevestigt wat al bekend was, in plaats van iets test. Batenrealisatie is dan het duidelijkste voorbeeld: als niet vooraf is vastgelegd welke baten wanneer gerealiseerd moesten zijn, is achteraf onmogelijk hard te maken of ze er zijn.
Wat dit concreet vraagt
Vooraf vastgestelde criteria betekent niet een dik document bij de start dat nooit meer wordt ingezien. Het betekent drie dingen die praktisch te doen zijn:
- Leg vast wat succes meet, niet alleen wat het project oplevert. Een lijst met deliverables is geen succescriterium; een norm waartegen die deliverables worden getoetst wel.
- Leg vast wannéér dat wordt getoetst. Sommige baten zijn pas maanden na oplevering zichtbaar — dat moment moet al bij de start op de kalender staan, niet pas worden bedacht als de vraag actueel wordt.
- Wijzig de criteria niet stilzwijgend. Scope en omstandigheden veranderen gedurende een project vaak terecht. Als de criteria daardoor moeten meebewegen, hoort die aanpassing zelf vastgelegd en onderbouwd te worden — niet stilzwijgend te verdwijnen in de eindrapportage.
Geen garantie, wel een voorwaarde
Dat vier onafhankelijke kaders dit los van elkaar als bouwsteen benoemen, betekent niet dat een project met vooraf vastgestelde criteria automatisch beter verloopt of dat een evaluatie met deze bouwsteen aantoonbaar tot betere volgende projecten leidt. Wat het wel betekent: zonder vooraf vastgestelde criteria is een evaluatie achteraf niet meer dan een samenvatting met een cijfer erbij. De vraag of een project geslaagd is, kan dan nooit eerlijk beantwoord worden — omdat niemand vooraf heeft vastgelegd wat het antwoord zou moeten verklaren.
Bepaal vooraf welke succescriteria gehanteerd worden en op welk moment die worden getoetst: dutchmind.com/producten/evaluatiescore (€15) toetst een projectevaluatie tegen dat uitgangspunt.
Bronnen
- OECD DAC Network on Development Evaluation (EvalNet) (2019), Evaluation Criteria (herzien, DCD/DAC(2019)58 FINAL) — one.oecd.org.
- HM Government / Cabinet Office–IPA (nu NISTA) (2021), Gate 5: Operations Review and Benefits Realisation (Assurance Portfolio Standard, V1.0) — assets.publishing.service.gov.uk.
- PRINCE2-praktijk — End Project Report en Lessons Report Template (prince2.wiki, secundaire bron, geen officiële AXELOS-manual).
- Stufflebeam, D.L. (2015), CIPP Model checklist (2e ed.) — rszarf.ips.uw.edu.pl.