Defensie GrIT; het rapport van ABDTOPConsuIt

De geit en de kool

Allereerst valt op dat de ABd de geit en de kool wil sparen. Op vrij luchtige toon wordt voorkomen dat iemand zich aangevallen voelt. Er wordt zelfs nadrukkelijk geschreven dat er geen uitspraken worden gedaan over het functioneren van personen en de kwaliteit van prestaties. Iedereen heeft immers zo hun best gedaan.

Wanneer een project/programma met dit belang, deze omvang en gevolgen wordt onderzocht en wanneer het hoger management zulke (organisatorische, basale) steken laat vallen, mag een scherper oordeel verwacht worden.

Gescheiden werelden

Het ABd-rapport heeft als titel “Gescheiden werelden”. Dit duidt op de verzuilde manier van acteren van het ministerie en van het programma. Diverse onderdelen werkten onvoldoende samen, deelden onvoldoende informatie en werkten zelfs in volstrekte isolatie van elkaar.

Deze constatering werd niet zo expliciet getrokken door de rapportage van het BIT maar is voor de hand liggend. Eerder was dit ook bij het SPEER-project zichtbaar.

In een machinebureaucratie, wat de overheid is, is verzuiling gangbaar. Elk onderdeel komt primair op voor de eigen belangen en zet het grotere belang op de tweede plaats. Dat heb ik eerder ook al gesteld na een evaluatie van Operatie BRP.

De organisatiecultuur van een machinebureaucratie is een belangrijke oorzaak van falende projecten, met welke inhoud dan ook (en heeft dus niets met ICT te maken).

Onduidelijke rollen

Uit het BIT-rapport werd het al duidelijk en de ABd maakt het in hun onderzoek expliciet: rollen en verantwoordelijkheden zijn bij GrIT verre van duidelijk en niet of nauwelijks gedefinieerd. Zoals in vrijwel elk “ICT-project” is de CIO, de interne leverancier en dienstverlener de spin in het web. Als het waar is dat GrIT over alleen de “harde” ICT gaat, dus alleen de hardware en susteemsoftware, is de centrale rol voor de CIO in dit geval ook nog eens verdedigbaar. Want dan zal GrIT geen direct gevolg hebben voor eindgebruikers, zoals applicatiebouw (bijvoorbeeld SPEER) dat wel heeft.

Maar dan volgt direct de vraag: waarom zijn diverse andere, niet-ICT-functionarissen zo direct betrokken bij GrIT.

Het door de ABd in de bijlage geleverde organigram van het programma geeft een bizar beeld. Het lijkt er nog het meest op dat allerlei functionarissen in een kamer zijn gezet zodat ook zij kunnen meepraten. Een doelgerichte stuurgroep en duidelijke rollen zijn, gezien dit plaatje, geen prioriteit geweest. De meest bizarre is de constructie van een opdrachtgever die een opdrachtnemer aanstuurt die dan weer een gedelegeerd opdrachtnemer aanstuurt. Hoe verzin je het!

Maar verreweg de meest merkwaardige rol is die van Senior User. Die rol zou zijn belegd bij de CDS. Omdat het ABd-rapport strooit met afkortingen maar die niet toelicht, is de aanname dat CDS staat voor Commandant der Strijdkrachten. Wanneer dat waar is, dan is deze keuze volstrekt onbegrijpelijk, onrealistisch en onwerkbaar.

De rol van Senior User wordt gebruikt in de methode PRINCE2 (projectmanagement, geen programmamanagement). Dit lid van de stuurgroep, iemand met beslismacht dus, vertegenwoordigt de eindgebruikers en is binnen de stuurgroep verantwoordelijk voor de te leveren voordelen (benefits) en daardoor ook eindverantwoordelijk voor de definitie van de gevraagde kwaliteit. De Senior User legt daarover verantwoording af aan de voorzitter van de stuurgroep: de Business Executive, de (gedelegeerd) opdrachtgever. En daarmee wordt deze rol binnen GrID bijzonder merkwaardig; de CDS die verantwoording aflegt aan de CIO? Dat gaat niet werken.

Afgezien van de PRINCE2 definitie is het natuurlijk ook uiterst naïef om te veronderstellen dat de CDS “voldoende zichtbaar” zou kunnen zijn als Senior User binnen het programma. De CDS is te ver verwijderd van de werkvloer en heeft daarmee per definitie te weinig kennis om zich actief en geloofwaardig inhoudelijk te bemoeien met het programma.

QA – Quality Assurance

Dan als laatste een voor velen relatief onbeduidend punt: de ABd heeft kritiek op de invulling van QA. De term Quality Assurance (QA) is mij bekend uit de methodes PRINCE2 en MSP. Binnen het MSP Programma Management wordt QA gedefinieerd als een (onafhankelijke) adviseur die op alle niveaus, van opdrachtgeverschap tot onderliggende projecten, effectiviteit beoordeelt. Binnen PRINCE2 wordt deze definitie grotendeels overgenomen als een functie die van buiten het project naar de effectiviteit van het project kijkt; een functie van het programma of van het mandaterende bedrijfsmanagement.

Het essentiële verschil tussen Assurance (borging) en Audit is dat borging vooruitkijkt en adviseert maar dat auditing terugkijkt en beoordeelt of op de juiste manier, meestal procedureel, is gewerkt. Daarmee heeft Assurance meer te maken met leiderschap (de goede dingen doen) en Audit meer te maken met management (de dingen goed doen).

Ook helpt de Assurance-functie om Watermeloen-rapportages te voorkomen; Groen aan de buitenkant, Rood aan de binnenkant. Ook bij GrIT lijken Watermeloen-rapportages gebruikelijk gezien de reacties op kritiek die erop neer komen dat alles goed gaat en alles nog eens moet worden uitgelegd.

De functie van Assurance valt te vergelijken met die van de Hofnar. Een hofnar kon vrijuit en vaak confronterend spreken. De woorden van de hofnar werden serieus genomen en zijn kop ging er nooit af. In een goed functionerende situatie gaat dat met Assurance ook zo. Helaas is het meestal zo dat een adviseur de klant moet vertellen wat een klant wil horen. Wanneer een “inconvenient truth” wordt verteld, betekent het vaak het einde van de adviseur. Daardoor worden veel adviseurs in de Assurance-functie nutteloze ja-knikkers om aan de opdracht te kleven; voor mij een reden om niet meer in loondienst voor een consultancy te werken.

Eerder tijdens mijn evaluatie van Operatie BRP (oBRP) uitte ik stevige kritiek op de Assurance functie. Enige weken geleden liet minister Knops (BiZa) de Tweede Kamer weten dat dit dossier zal worden gebruikt om expliciet lessen van te leren. De Kwaliteitsborging werd hierbij expliciet genoemd.

Zowel bij GrIT als bij oBRP werd dus gesteld dat QA beter moet. Zou dat ook serieus worden opgepakt? Zou dan ook de conclusie worden getrokken dat een betere QA slechts mogelijk is onder veel beter Opdrachtgeverschap?

Wordt vervolgd

Over GrIt zal het laatste woord voorlopig nog niet gezegd zijn. Staatssecretaris Visser zal komen met nieuwe scenario’s en er wordt gespeculeerd over schadeclaims van IBM.

Ik ben benieuwd hoe dit alles zal verlopen. Het is duidelijk dat dingen fundamenteel zullen moeten veranderen. Wordt ongetwijfeld vervolgd.