Batenrealisatie: van oplevering naar echte waarde

Gepubliceerd 2026-07-02 · Het onderzoek achter Project-simulator

Het project leverde op tijd, het systeem ging live en het team vierde feest. Een jaar later vraagt iemand uit de directie: is het eigenlijk beter geworden? En niemand weet het. Dat is precies het probleem dat de onderzoekers John Ward en Elizabeth Daniel van de Cranfield School of Management aanpakten in hun boek Benefits Management uit 2006.

Hun boodschap is ongemakkelijk maar bevrijdend: de baten van een project ontstaan niet bij de oplevering. Ze ontstaan in de organisatie, achteraf, en alleen als iemand er eigenaar van is en actief werkt om ze werkelijkheid te maken. De werkwijze die zij beschrijven heet vaak batenrealisatie, en die is een vanzelfsprekend onderdeel geworden van moderne project- en portfoliosturing.

Wat zegt het onderzoek?

Ward en Daniel bouwden hun boek op vele jaren onderzoek naar investeringen in informatiesystemen en IT. Een terugkerend patroon was dat organisaties baten inboekten in de businesscase — efficiëntere processen, tevredener klanten, lagere kosten — maar nooit nagingen of die er ook echt kwamen. Men ging ervan uit dat de baten vanzelf zouden komen zodra de techniek er stond. Dat doen ze zelden.

Hun verklaring: techniek en projectopleveringen creëren op zichzelf geen waarde. Waarde ontstaat pas als mensen in de organisatie hun manier van werken veranderen. Daarom moeten baten vroeg worden geïdentificeerd, gekoppeld aan concrete veranderingen in de organisatie en vooral eigenaren krijgen — mensen in de organisatie, niet in het project, die er verantwoordelijk voor zijn dat de baten daadwerkelijk worden binnengehaald. Ward en Daniel beschrijven hiervoor een compleet werkproces, met een batenrealisatieplan en een opvolging die doorloopt nadat het project is afgesloten.

Een belangrijk gevolg is dat projectdoelen en effectdoelen uit elkaar gehouden moeten worden. Het project is verantwoordelijk voor het opleveren van een resultaat — een systeem, een proces, een product — binnen zijn kaders. Het effect, de meetbare baat in de organisatie, is van de opdrachtgever of sponsor en wordt lang na de overdracht gerealiseerd. Worden ze door elkaar gehaald, dan kan niemand ergens op worden aangesproken — het project krijgt de schuld van uitgebleven effecten waar het geen invloed op heeft, en de organisatie ontloopt haar verantwoordelijkheid voor de verandering.

Wat betekent dit voor jou als projectleider?

Houd projectdoelen en effectdoelen in elk document gescheiden. Schrijf het expliciet op: dit levert het project op, dit is de baat die daarna moet ontstaan, en die is van de sponsor. Dat beschermt jou én de baat — jij wordt beoordeeld op het juiste, en de baat krijgt een verantwoordelijke.

Eis voor elke baat een eigenaar. Als niemand in de organisatie zijn naam bij een beloofde baat wil zetten, is dat een waarschuwingssignaal: of de baat is niet geloofwaardig, of niemand gaat hem binnenhalen. Kaart het aan bij je sponsor voordat het project echt van start gaat — het eigenaarschap is dan veel makkelijker te regelen dan wanneer de oplevering nadert.

Gebruik de businessbaten onderweg als kompas. Als wijzigingsverzoeken en bezuinigingen worden besproken, ga dan terug naar de baten: welk van de beloofde effecten wordt door dit besluit versterkt of bedreigd? Dat verhoogt de kwaliteit van de besluiten en van je gesprekken met de stuurgroep.

Zo train je dit

Het moeilijkste van batenrealisatie is vaak het gesprek met de sponsor: de verantwoordelijkheid voor het effect vriendelijk maar beslist teruggeven waar die thuishoort, zonder dat de relatie of het vertrouwen er onderweg schade van oploopt. In Project-simulator oefen je sponsor- en stuurgroepgesprekken tegen AI-tegenspelers en krijg je feedback gebaseerd op je eigen woorden. Je kunt het een week gratis proberen.