Op de afsluitende bijeenkomst van het nieuwe zaaksysteem bij een middelgrote gemeente klinkt applaus: opgeleverd op de afgesproken datum, binnen het budget van ruim een miljoen euro, alle afgesproken functionaliteit gebouwd. De projectleider krijgt een schouderklop en de volgende opdracht. Niemand stelt de vraag die een jaar later nog telt: zijn de dertig procent kortere doorlooptijden voor aanvragen, die in de business case stonden, er ook echt gekomen?
Dat is geen uitzondering. Het is het patroon waarop evaluatie achteraf meestal struikelt: projecten worden afgesloten op basis van de vraag of ze geleverd hebben wat was afgesproken, niet op basis van de vraag of ze hebben opgeleverd wat was beloofd.
Twee verschillende beloftes
Een projectplan belooft iets anders dan een business case. Het plan belooft scope, tijd en geld: dit systeem, op die datum, voor dat budget. De business case belooft een baat: minder doorlooptijd, lagere kosten, hogere klanttevredenheid. Een project kan slagen op de eerste belofte en volledig stil blijven over de tweede, en dat gebeurt structureel, omdat niemand na opleveren nog de opdracht heeft om de baat te meten.
De Algemene Rekenkamer constateerde dit al in 2013 voor ICT-projecten van het Rijk: batenrealisatie wordt te weinig bewaakt. Niet omdat niemand het belangrijk vindt, maar omdat er na de livegang geen aangewezen moment meer is waarop iemand die vraag nog stelt. Het project is klaar, het team is ontbonden, de volgende aanbesteding wacht.
Wat vier kaders gemeen hebben
OECD DAC, een breed toegepast, overdraagbaar kader voor evaluatie dat is ontwikkeld binnen ontwikkelingssamenwerking, zet de batentoets tegen de belofte voorop: niet 'is het opgeleverd' maar 'deed het wat het moest doen'. Het Britse Gate 5, de PRINCE2-praktijk en het CIPP-model van Stufflebeam komen, onafhankelijk van elkaar ontwikkeld, op dezelfde kern uit. Vier verschillende tradities, één conclusie: een evaluatie die alleen naar levering kijkt, evalueert het verkeerde.
De vraag die ontbreekt bij opleveren
Het praktische probleem is niet dat organisaties geen criteria hebben. Het projectplan staat vol criteria, ze zijn alleen van het verkeerde type. Scope, tijd en geld zijn eenvoudig te checken bij opleveren: het systeem draait of draait niet, de rekening is er of is er niet. Een baat als 'dertig procent snellere doorlooptijd' is pas meetbaar na een periode van echt gebruik, als de livegang al lang gevierd is en de aandacht al naar het volgende project is verschoven.
Dat verklaart waarom ex-ante toetsing, sinds de commissie-Elias verplicht voor rijks-ICT, wel standaard is en ex-post toetsing van baten niet: de eerste hoort bij het moment waarop iedereen nog kijkt, de tweede bij het moment waarop niemand meer kijkt.
Voor een projectleider die dit patroon wil doorbreken, is de eerste stap niet een uitgebreider evaluatieproces, maar een andere vraag bij opleveren: niet 'hebben we gebouwd wat was afgesproken', maar 'aan welke baat uit de business case gaan we dit over zes maanden nog toetsen, en wie doet dat'. Zonder die tweede vraag blijft 'op tijd en binnen budget' het enige antwoord dat ooit wordt gegeven.