Operatie BRP is mislukt. Een analyse.

Staatssecretaris  Raymond Knops (BZK)
Staatssecretaris Raymond Knops (BZK)

En een afwijkende mening!

In 2017 besloot toenmalig minister van BZK Plasterk om de operatie Basisregistratie Personen (oBRP) onafgerond te beëindigen nadat er vele jaren aan is gewerkt, er diverse herstarts (uiteraard vergezeld van interessante naamwijzigingen) zijn geweest en meer dan 100 miljoen Euro is besteed.

De opvolger van minister Plasterk op dit dossier is staatssecretaris Knops. Na een unaniem aangenomen motie waarmee de Tweede Kamer inzicht verlangde naar aansturing en besluitvorming van oBRP, heeft staatssecretaris Knops een commissie aangesteld. Deze commissie heeft een rapport geproduceerd met als titel “Niet te stoppen”.

Wat is de waarde van dit rapport? Hoe sterk zijn de adviezen? Zijn er dingen die de commissie wel beschreef maar niet (voldoende) benoemde?

Het rapport

Het rapport “Niet te stoppen” heeft de volgende indeling:

  • Feitenreconstructie; dit is verreweg het grootste deel van het rapport. Het rapport tracht zo feitelijk mogelijk in vijf periodes van 2009 (herstart mGBA) tot 2017 (stopzetten oBRP) weer te geven wat zich heeft afgespeeld. Dit deel van het rapport is zeer lezenswaardig maar bevat ook erg veel zeer belangrijke feiten die door de commissie niet verwerkt zijn in verdere beoordeling en aanbevelingen.
  • Analyse; in dit deel beoordeelt de commissie de feiten en tracht ze te duiden.
  • Lessen; welke lessen kunnen volgens de commissie worden getrokken op basis van het voorgaande.

De kwaliteit van het rapport

Om maar direct met de deur in huis te vallen: de feitenreconstructie ziet er prima uit. Na het beëindigen van oBRP is de website uit de lucht gehaald en daarmee is informatie niet (meer eenvoudig) te controleren. Maar het feitenrelaas ziet er volledig en consistent uit. Het bevatte ook geen verrassingen voor iemand die de cultuur en werkwijze van ministeries in dit soort projecten kent.

Heel anders wordt het als ik kijk naar de Analyse en Lessen. Hier wordt weer eens gestrooid met alle denkbare clichés en wordt volledig voorbijgegaan aan belangrijke feiten die het project onbeheersbaar hebben gemaakt, eigenlijk op een vergelijkbare wijze waarop de ook in het rapport genoemde Tijdelijke Commissie ICT (Commissie Elias) dat ook deed. Hierdoor zijn de adviezen en lessen weinig zinvol.

Pagina 122 uit het rapport

Wat het rapport niet (goed) ziet

Om te beginnen: het rapport onderkent nauwelijks dat er eigenlijk geen moment is geweest dat oBRP “in control” was. De organisatie, voor zover die er expliciet was, haperde aan alle kanten en er was overduidelijk geen eigenaarschap, en dus geen effectief opdrachtgeverschap aanwezig.

De eerste alarmbel gaat al af bij het lezen van de inleiding van het rapport.

Inleiding pagina 2Inleiding pagina 3

De commissie ziet niet dat de technische kant volledig ondergeschikt had moeten zijn aan de bestuurlijke kant. Het doel is bepalend en ICT en techniek zijn geen doelen maar middel. Bij een eerder grote overheidsproject schreef ik al dat “ICT-projecten komen in de problemen omdat het ICT-projecten zijn”. Dat geldt ook voor een groot deel OBRP en zeker als oorzaak voor het gebrek een effectieve sturing.

Het “met de kennis van nu” argument

De rapportage wijst erop dat het met de kennis achteraf gemakkelijk is te oordelen.

 Pagina 121

Maar wie bijvoorbeeld de pagina’s op mijn website op waarde schat, kon gedurende het feitenrelaas diverse trends zien en voorspellingen doen.

Deze en andere punten maken dat het “met de kennis van nu” argument niet opgaat. Wanneer het ministerie en oBRP hadden geïnvesteerd in relevante kennis en/of gebruik had gemaakt van de juiste adviseurs, was het programma heel anders, veel beter verlopen.

Geen moment “in control”.

Want: geen opdrachtgeverschap en geen business case

Het rapport maakt duidelijk dat oBRP niet werd bestuurd door een effectieve programmaorganisatie. Het opdrachtgeverschap was zeer operationeel en bestond eigenlijk slechts op papier.

Hoe er (niet) werd omgegaan met de business case zegt alles over het opdrachtgeverschap en over de “control”. In een programma waar plannen en richting continu wijzingen, kan het niet zo zijn dat een business case slechts twee maal herzien wordt. Elke wijziging van plannen en richting heeft automatisch een wijziging van de business case tot gevolg.

Dat de business case voor oBRP geen serieus sturingsinstrument en niet meer dan een papieren tijger was, bleek ook heel duidelijk uit het feit dat de zeer beperkte herzieningen werden uitgevoerd door externe, zelfs commerciële partijen.

Pagina 69

Er was geen sprake van effectief opdrachtgeverschap en eigenaarschap bij oBRP. En dus was men niet “in control”. Het is daarbij veelzeggend, zelfs treurig dat het BIT, een technisch adviesorgaan en extern aan het programma, hier vragen over moet stellen en dat dit vrijwel direct leidt tot stopzetten van oBRP.

Pagina 104

Is het (nog) wel de moeite waard?

Dit is de meest fundamentele vraag voor elk project of programma. De business case dient ervoor om op deze vraag een onderbouwd antwoord te geven. Helaas werd hier door oBRP volledig aan voorbij gegaan. De business case was een papieren tijger die slechts werd opgesteld en beperkt onderhouden omdat een procedure het vereiste...

Plannen en risico’s voor de bühne

Ook de manier waarop oBRP omging met plannen, risico’s en met rapportages (voortgang en escalatie) heeft weinig met effectieve beheersing te maken. Een programma is per definitie meer risicovol dan de dagelijkse, routinematige gang van zaken. Toch werd een poging gedaan om het programma met routinematige middelen (budgetten) te besturen, vrijwel volledig door lijnfunctionarissen. Dit soort besturing (voor zover daar sprake van is), stort een programma onmiddellijk in een permanente staat van crisis. Een permanente staat van crisis heeft vervolgens tot gevolg dat men dit de normale gang van zaken gaat vinden, waardoor afwijking van planning de norm wordt en er daardoor ook geen pogingen gedaan worden om het programma in een beter vaarwater te krijgen. De zeer incidentele actualiseringen van plannen (en risico’s) zijn daarbij veelzeggend. De plannen, inclusief risico’s hadden vrijwel doorlopend bijgewerkt moeten worden als reflectie van de op dat bekende status en als een startpunt voor effectieve beheersing.

Pagina 59

Schijnbeheersing en lage kwaliteit

Zoals gebruikelijk in een machinebureaucratie (waar stafafdelingen het voor het zeggen hebben), werd ook bij oBRP "gestuurd" op tijd en geld. Het rapport toont met regelmaat delen van de planning die een lachwekkende en volkomen onrealistische “precisie” (tot op het niveau van een Euro) pretenderen.

Pagina 44

De focus op tijd en geld heeft een ander, zeer negatief effect: het gaat ten koste van kwaliteit. Dat gaat op langere termijn erg veel tijd en geld kosten. Het volkomen voorspelbare gebrek aan kwaliteit komt op diverse momenten en verschillende manieren aan de oppervlakte.

Voorbeeld Codegeneratoren

Het programma maakte gebruik van zelfgebouwde codegeneratoren. De code die hiermee werd gegenereerd voldeed echter niet aan de normen; een nette manier om een gebrek aan kwaliteit te benoemen. De gegenereerde code werd gedurende het programma herschreven, met meetbare gevolgen die aantoonde hoe gebrekkig de oorspronkelijke code was.

 Pagina 73

Uiteraard heeft de “Refactoring” (of skelettransplantatie, zoals René Veldwijk het noemde) gevolgen gehad. Afgezien van de inspanning die moest worden gestoken in het herschrijven van de code, moest ook opnieuw getest worden.

Matige kwaliteit, gebrekkige kwaliteitsbeheersing en "op hoop van zegen".

Op diverse andere punten blijkt dat dat de software niet goed werkt, onterecht gereed is gemeld of niet gereed is. Het rapport lijkt dit te zien als een "fact of life" en niet te voorkomen.

 Pagina 76

Alsof het nog niet erg genoeg was: het “Hek”

De obsessie met tijd en geld leidde tot een bizar en verdragend besluit. De stuurgroep dient te gaan over geld en tijd; functionaliteit is daarvan een afgeleide. Dat is echt de omgekeerde wereld en leidde tot verdere kwaliteitsproblemen.

Pagina 41

In elk gezond project of programma is tijd en geld een consequentie van de doelen die bereikt moeten worden. Bij elke wijziging van scope en kwaliteit wordt vervolgens beoordeeld of de wijziging de moeite waard is. Maar de stuurgroep koos voor een desastreuze koers: zolang er op tijd en binnen budget wordt geleverd, is het goed. Deze houding had uiteraard voorspelbaar grote en dure consequenties. Problemen en nieuwe eisen werden vooruitgeschoven wat door verdere kortzichtige ontwikkeling binnen "het hek" de consequenties van de wijziging in de toekomst groter en risicovoller zou maken. Dat bleek ook wel:

Pagina 86

Programmatische aanpak? Gestructureerde aanpak?

Alles wat tot nu toe is besproken geeft geen indicatie van een programmatische of gestructureerde aanpak. Hoewel zo nu en dan wat termen (PID, Product Breakdown Structure, Quality Assurance) langskomen die een indicatie kunnen geven van een Best Practice methode (PRINCE2), is ook daarvan geen sprake.

Toch komt de partij die Quality Assurance taken heeft, PBLQ HEC, met een opzienbarende en tegenstrijdig verhaal. Er waren allerlei organisatorische problemen en om daaraan het hoofd te bieden wordt een periodieke evaluatie aanbevolen. Dit was op zich al een slechte aanbeveling want problemen moet je aanpakken wanneer ze optreden (event driven). Periodieke (“time driven”) beheersing is hierbij per definitie niet aan te bevelen.

Maar nog problematischer: PBLQ HEC viod dat oBRP de methode Managing Successful Programmes (MSP) voldoende toepaste.

Pagina 54

Waarom is deze inschatting problematisch? Omdat dit verregaande incompetentie aantoont en dat is geen goede zaak voor borging die bij belangrijke programma's en zeker bij oBRP van groot belang is.

Wanneer bedrijven uit de ICT-industrie zich uitlaten over methodes als PRINCE2 en MSP gaat het vrijwel altijd mis. Vanuit hun eigen cultuur is er geen enkel begrip voor methodes die niet primair uitgaan van opleveren volgens specificatie. Methodes die zich richten op lange termijn doelen, het beheersen vanuit een business case, zijn methodes die een cultuur bedienen die volledig anders is dan de oplever-cultuur. PRINCE2 en zeker MSP zijn methodes voor beheersing door een klant en die zich richten op doelen. Leveranciers richten zich op korte termijn doelen: het maken van de middelen, zoals software. Een organisatie die zich richt op “het snijvlak van IT en organisatie”, zoals PBLQ zichzelf positioneerde, zit in hun denken aan de leverancierskant. In de jaren dat ik op afstand met deze organisatie heb kennis gemaakt, bleek dat ook wel. In diverse Gateway Reviews heb ik vrijwel altijd kritiek gehad op het missen van structurele problemen terwijl symptomen wel benoemd werden. Als consequentie waren de adviezen meestal matig.

Dit is verre van uniek voor PBLQ. Wat echter wel uniek is aan deze organisatie, is dat zij door hun oorsprong (voortgekomen uit het ministerie van BZK) en medewerkers (ex-ambtenaren) erg veel toegang hebben tot overheidsopdrachten. Omdat PBLQ zeer nauwe historische banden heeft met de overheid zullen adviezen ook volledig in lijn zijn met de cultuur van de overheid en zal kritiek of een afwijkende mening zeldzaam zijn.

Elke organisatie en manager krijgt de adviseurs die zij verdienen

De CIO BZK deelde een aantal observaties die de kern van mijn kritiek op de gehanteerde Quality Assurance raken:

 Pagina 84/85

De CIO heeft een uitstekend punt. Het is moeilijk om opdrachtnemers te vinden die zich onafhankelijk willen en durven op te stellen. Ook bij oBRP en zeker in het geval van PBLQ bleek dit een probleem.

Einde van deel 1

Dit is een eerste reactie op de beëindiging van oBRP en het rapport "Niet te stoppen". In een volgend deel zal ik ingaan op zaken die in het rapport minder of zelfs geen aandacht kregen maar die in mijn optiek wel degelijk een grote impact hadden.

Tot dan zie ik uiteraard reacties en commentaren (hieronder graag!) met zeer veel belangstelling tegemoet!

Over de auteur

Specialist in effective change.

Accredited MSP™ and PRINCE2® trainer.

comments powered by Disqus