Benefitrealisatie: eerst de mensen, dan pas de projecten
Geert Barandat · bijgewerkt op 26 september 2026
Benefitrealisatie, ook batenrealisatie of batenmanagement genoemd, zorgt dat een verandering de waarde oplevert waarvoor ze gestart is. Ze begint niet bij het project, maar bij de benefit en bij de mensen die hem moeten waarmaken: welke waarde wil je, wat moet er daarvoor voor hen veranderen, en welk project draagt daar echt toe bij.
Waarom de benefit na de go-live verdwijnt
De meeste organisaties beginnen bij het project. Er is een doelstelling, er wordt een project voor opgezet, en de benefit staat in de business case. Die volgorde lijkt logisch. Ze loopt op vier plaatsen vast.
Na de goedkeuring verandert de maatstaf. De business case dient om budget te krijgen. Daarna betekent succes op tijd en binnen budget opgeleverd. De benefit wordt een document in een map.
Oplevering telt als succes. De go-live staat op groen, ook als niemand anders werkt. Of de benefit er komt, meet niemand, want het project is afgesloten.
Mensen komen pas aan het einde. Change management wordt de fase waarin je een ontworpen oplossing moet verkopen. Weerstand is dan duur, want er is al gebouwd.
Elke kloof wordt een project. Wie vanuit projecten denkt, lost alles op met een project. Ook wat met een andere werkafspraak, een nieuwe rol of een opleiding opgelost was.
De cyclus, stap voor stap
Vertrekken vanuit de benefit draait de volgorde om. Het project komt niet eerst, maar als laatste, als middel.
- De benefit
- De verandering
- De gewenste werking
- Wat ontbreekt
- Project of ingreep
- ↺ Wat je hoortstuurt bij: de verandering · de gewenste werking · wat ontbreekt · het project
1 · De benefit. Welke waarde wil je realiseren, en hoe zie je dat ze er is? Een benefit zonder startpunt is een wens. Je legt vast waar je vandaag staat, en waar dat cijfer vandaan komt.
2 · De verandering. Wat moet er voor medewerkers, teams en de organisatie anders zijn om die benefit mogelijk te maken? Dit is de vraag die in de gewone weg pas aan het einde gesteld wordt.
3 · De gewenste werking. Hoe werkt de organisatie dan concreet? Wie doet wat, met welke afspraken, in welke rol? De mensen die de verandering dragen, vullen dit mee in.
4 · Wat ontbreekt. Wat kan de organisatie vandaag nog niet, dat ze dan wel moet kunnen? Dat is de kloof die je moet dichten.
5 · Het project, of een kleinere ingreep. Pas nu kies je het middel. Soms is dat een project. Soms volstaat een werkafspraak, een rol of een opleiding. Je kiest het kleinste middel dat de kloof dicht.
6 · Wat je hoort. Tijdens de uitvoering luister je naar de teams. Wat je hoort, kan de verandering, de gewenste werking, wat ontbreekt en het project bijsturen, terwijl ze lopen. Alleen de benefit blijft staan: die is de maatstaf. Het einde is niet de go-live, maar het moment waarop de benefit er is.
Hoe dit zich verhoudt tot MSP en het Benefits Dependency Network
Vertrekken vanuit de benefit is op zich niet nieuw. MSP tekent eerst een blueprint van de toekomstige organisatie, en pas dan de projecten. Het Benefits Dependency Network van Ward en Daniel wordt van de doelstelling naar de middelen gebouwd, met de veranderingen als aparte schakel. Deze aanpak staat op die schouders.
Het verschil zit in drie dingen die de klassieke methodes open laten.
Wie de gewenste werking invult, en wanneer. In veel programma's tekent het programmateam de blueprint. Hier vullen de mensen die de verandering dragen hem mee in, voor er gebouwd wordt.
Feedback verandert het project, niet alleen de rapportering. In de klassieke cyclus stuur je bij tussen tranches. Hier kan wat de teams zeggen een project van vorm doen veranderen terwijl het loopt.
De aanname blijft zichtbaar. Tussen een uitkomst en een benefit zit altijd een veronderstelling. Je rekent ze niet weg. Je zet naast elkaar wat je verwachtte en wat je ziet, en iemand beslist, met naam en datum.
Wat het vraagt van een organisatie
Deze weg is niet moeilijker, maar wel eerlijker. Hij vraagt vier dingen.
Een benefit met een startpunt. Zonder nulmeting is elke latere meting een mening.
De bereidheid om te stoppen. Als een project niet meer bijdraagt aan de benefit, stuur je het bij of stop je het. Dat is geen falen, dat is portfoliomanagement.
Change aan het begin. De change manager werkt al voor het project start, om de verandering en de gewenste werking mee vorm te geven.
Een vast ritme om terug te kijken. Per kwartaal, of per golf van initiatieven, de vraag: komt de benefit, en klopt onze veronderstelling nog?
In Cohentis staat de benefit vooraan
Klik om te vergroten
In het change portfolio begin je bij de benefit. De benefit map toont de keten naar het initiatief, en leest standaard vanaf de benefit: waar je heen wilt, en wat daarvoor nodig is. Wat een benefit kost, het nadeel, staat in dezelfde kolom. Per benefit zie je het startpunt, het doel en de laatste meting, met de datum en het plan waar die meting vandaan komt.
Een succescriterium in een changeplan koppel je aan de benefit in het portfolio. Wat de change manager meet, reist terug naar de benefit waarover het ging. Zo zie je op portfolioniveau of de verandering landt, niet alleen of het project loopt.
In je werkafspraken leg je vast dat er een change manager is voor het project start. Het dashboard meldt elk initiatief dat zonder goedgekeurd wordt.
Veelgestelde vragen
Wat is benefitrealisatie?
Benefitrealisatie zorgt dat een verandering de waarde oplevert waarvoor ze gestart is. Ze vertrekt bij de benefit en kiest het project als middel, in plaats van omgekeerd.
Wat is het verschil tussen een output, een uitkomst en een benefit?
Een output is wat een project oplevert, bijvoorbeeld een nieuw systeem. Een uitkomst is wat er daardoor anders gebeurt, bijvoorbeeld dat teams hun planning in dat systeem maken. Een benefit is de waarde die dat oplevert, bijvoorbeeld minder overuren.
Wat is een nadeel in benefitrealisatie?
Een nadeel is wat een verandering kost of bemoeilijkt, voor wie ze raakt. Het hoort naast de benefit te staan, zodat de afweging zichtbaar blijft.
Wanneer stop je een project?
Wanneer het niet meer bijdraagt aan de benefit waarvoor het gestart is, en bijsturen niet volstaat. Dat vraagt een benefit met een startpunt en een vast moment om terug te kijken.
Hoe verhoudt deze aanpak zich tot MSP?
MSP vertrekt ook vanuit de gewenste toekomstige toestand. Deze aanpak voegt daar twee dingen aan toe: de mensen die de verandering dragen, vullen die toestand mee in, en wat de teams zeggen, stuurt de projecten bij terwijl ze lopen.