Elke ambtenaar boven een bepaalde schaal zou eigenlijk verplicht een opleiding ICT-‘opdrachtgeverschap’ moeten volgen.
Op 20 december 2016 mocht ik mijn boek ‘Terug in de toekomst, geschiedenis van het generieke informatiserings- en automatiseringsbeleid van de Nederlandse overheid van 1985 en 2015’ in Nieuwspoort presenteren. Het boek sluit af met een negental stellingen. Met de redactie van iBestuur is afgesproken dat ik elk van die stellingen in een column zou toelichten. Vandaag de zevende stelling.
Stelling 7: Wat betreft de grote ICT-projecten is het belangrijkste probleem waarschijnlijk nog steeds het slechte opdrachtgeverschap bij de overheid. Er zijn voldoende instrumenten (methodieken, architectuur, audits) maar die worden slecht gebruikt. Elke ambtenaar boven een bepaalde schaal zou verplicht een opleiding ‘opdrachtgeverschap’ moeten volgen. Elke hogere ambtenaar komt er namelijk mee in aanraking. Iedere topambtenaar moet kennis en ervaring hebben met ICT.
Al in 1987 kwam de Centrale Commissie Overheidsinformatievoorziening (CCOI), toen ingesteld door de minister van BZK, tot de conclusie dat het mislukken van verschillende grote ICT-projecten binnen de overheid vooral kwam door het gebrek aan kennis en kunde wat betreft het leiden ervan. In 2008 kwam de Algemene Rekenkamer tot dezelfde conclusie, daarna gevolgd door de commissie Elias die, u raadt het al! Het vaak ontbreken van een goede invulling van het opdrachtgeverschap voor grote ICT intensieve projecten is dus niet alleen een oud, maar ook een hardnekkig probleem. Hoe komt dat nu?
Als daarop een eenvoudig antwoord viel te geven, zou het probleem waarschijnlijk niet al zo lang bestaan. Ik denk dan ook dat de problemen rond het opdrachtgeverschap vrij complex zijn en bovendien in de tijd zijn verschoven. Ik wil dat analyseren langs drie assen: de wijze van systeemontwikkeling, de aard van de systemen en de soort opdrachtgever.
Allereerst de wijze van systeemontwikkeling. In de jaren tachtig van de vorige eeuw werden de problemen rond het succesvol afronden van grote projecten in belangrijke mate veroorzaakt door de nieuwe, en door opdrachtgevers vaak nog onbegrepen, technologie. Onduidelijk was wat er technisch wel of niet kon en er waren veel moeilijk te doorgronden leveranciers gebonden oplossingen. Bovendien had een opdrachtgever (en zijn ondersteuners) vaak te weinig technische kennis van zaken om goed tegenspel aan die leveranciers te kunnen bieden. Leveranciers leverden dan technisch werkende systemen op die echter niet de oplossing waren voor de bestaande problemen.
Om dit soort zaken te voorkomen, werd daarna in toenemende mate gebruik gemaakt van methodieken voor systeemontwikkeling, met als bekendste voorbeeld SDM (System Development Methodology). Voor de echt grote systemen leidde dit echter tot bergen papier en een lange doorlooptijd tot er echt iets werd gebouwd. Opdrachtgevers raakten geleidelijk het zicht kwijt en de gebruikers kregen uiteindelijk iets wat ze niet wilden. Dit loste de problemen dus niet echt op.
Maar geleidelijk hebben opdrachtgevers hiervan geleerd. Projecten worden tegenwoordig meer in stukken verdeeld waardoor ze beter zijn te overzien en methoden als ‘agile’ zorgen voor kortere doorlooptijden en sneller tot concrete resultaten. Wat dit betreft gaat het echt beter.
Dan nu de tweede as: de aard van de systemen. In de vorige eeuw waren de projecten, zoals eerder gezegd, nog in belangrijke mate echt technisch van aard. Mede door het ontbreken van technische standaarden was binnen het opdrachtgeverschap technische kennis dus noodzakelijk. Bovendien ging het meestal om het automatiseren van bestaande processen. Wat later besefte men echter dat de meeste baten konden worden gegenereerd door het aanpassen van die processen aan de nieuwe technologische mogelijkheden. Daardoor kregen projecten echter een veel grotere organisatorische impact en moest ook het opdrachtgeverschap daaraan worden aangepast. Kennis van processen en aandacht voor communicatie werd steeds belangrijker. Momenteel gaan projecten vaak over organisatiegrenzen en zelfs over bestuurslagen heen wat weer andere competenties binnen het opdrachtgeverschap vraagt. Maar ook dat beginnen we te leren en er worden specifieke methodieken die, indien goed toegepast, in vrijwel alle gevallen tot een goed resultaat kunnen leiden. Voor projecten en programma’s zijn Prince2 en MSP (Managing Successful Projects) goede voorbeelden.
Tot slot van de analyse de derde as: de soort opdrachtgever. Ook hier verschoof een en ander in de loop van de tijd. In het begin waren technisch geschoolde ambtenaren de opdrachtgevers van de eveneens technische projecten. Je werd dus een betere opdrachtgever als je meer van de techniek begreep. In de fase daarna moest je vooral een goede projectleider zijn die zorgde dat er resultaten werden bereikt. Dit soort ambtenaren stonden meestal wat buiten de gewone lijn in de organisatie, hadden niet altijd een hoge rang en werden afgerekend op de te bereiken resultaten. Hier werd je dus een betere opdrachtgever als je meer begreep van projectmanagement. Maar heden ten dage is het leiden van projecten, juist door het veranderen van processen en het vaak organisatie overstijgende karakter, veel complexer. De opdrachtgever moet veel domeinkennis hebben, bestuurlijk gevoel en aandacht voor communicatie. Maar dit zijn precies de competenties die een normale lijnmanager binnen de overheid ook moet hebben. Daardoor ontstaat een nieuwe soort opdrachtgever, die wel veel beschikt over deze competenties maar vaak niet over de ook noodzakelijke competenties op het terrein van de twee andere assen: systeemontwikkeling en projectmanagement!
Hier ligt volgens mij de kern van de huidige problemen rond het opdrachtgeverschap. De huidige opdrachtgevers hebben vaak problemen omdat zij geselecteerd zijn op hun meer beleidsmatige competenties en niet op hun kennis van systeemontwikkeling en projectmanagement. Op zich is dat begrijpelijk maar die andere competenties zullen zij (op hoofdlijnen!) ook moeten hebben. Omdat elke ambtenaar vanaf een bepaald niveau nu, en zeker ook in de komende jaren, geconfronteerd zal worden met het fungeren als opdrachtgever van ICT intensieve projecten, zal zo’n ambtenaar over bewezen kennis betreffende die twee andere competentiegebieden moeten beschikken. Anders is hij onvoldoende geschikt voor zijn taak! Van ambtenaren van dit niveau eisen we financiële kennis en kennis van personeelsbeleid. Op het terrein van de informatievoorziening mag het niet anders zijn!
Ik pleit daarom voor aantoonbare kennis en ervaring op het terrein van systeemontwikkeling en projectmanagement vanaf de rang van directeur binnen een organisatie. Daarvoor zou ook een standaard opleiding moeten komen zodat er ook op het terrein van systeemontwikkeling en projectmanagement standaarden binnen de Nederlandse overheid ontstaan.
En voor diegenen die denken dat je dit alles aan de markt zou kunnen overlaten, bedenk: je kunt alles uitbesteden, behalve het opdrachtgeverschap!
Het boek is verkrijgbaar via https://www.sdu.nl/terug-in-de-toekomst.html
Typo : MSP = Managing Successful Programmes
Als IT arbiter zie ik regelmatig dat het slecht is gesteld met het leveranciersmanagement en opdrachtgeverschap bij klanten van IT bedrijven. Met het betoog van Rob Meijer in het achterhoofd valt op dat : 1) Ook in het bedrijfsleven de competenties op het gebied van leveranciersmanagement en opdrachtgeverschap vaak slecht zijn ontwikkeld. 2) Bij de overheid die competenties zo slecht zijn ontwikkeld dat geschillen tussen klanten en leveranciers uiterst zelden worden voorgelegd aan het arbitrage instituut. Ze worden ook niet betwist bij de rechtbank, want dan zouden we ze terugvinden in de openbaarheid van de Rechtspraak.
Dan blijft er maar één conclusie over: “daar waar bedrijven wel het conflict met de IT leverancier oppakken gaan overheden geschilbeslechting doorgaans uit de weg”. Vermoedelijk vanwege hetgeen Rob in stelling 7 aankaart. Met die stelling ben ik het volledig eens. Maar als ik de finale uitwerking daarvan in de laatste alinea lees, frons ik mijn wenkbrauwen een beetje. Ik denk namelijk niet dat topambtenaren een opleiding op het gebied van systeemontwikkeling en projectmanagement moeten doorlopen. Dat is volgens mij het terrein van professionals.
Ik denk dat topambtenaren meer baat hebben bij een opleiding leveranciersmanagement en opdrachtgeverschap met een curriculum dat primair aandacht besteedt aan businessmodellen bij IT leveranciers, marktwerking, juridische IT aspecten, architectuur van informatiesystemen, standaardisatie, en legacy versus innovatie. Misschien ook een klein beetje systeemontwikkeling en projectmanagement.
Een opleiding die er voor zorgt dat de topambtenaar zijn of haar mannetje/vrouwtje staat in de selectie en contractering van IT leveranciers en vervolgens in de stuurgroep die de uitvoering aanstuurt. Een topambtenaar die weet hoe meerwerk en kostenstijging kunnen worden voorkomen en zich niets op de mouw laat spelden door de leverancier.
“aantoonbare kennis en ervaring op het terrein van systeemontwikkeling en projectmanagement vanaf de rang van directeur binnen een organisatie.”
Bestuurskunde, praktijk en vele onderzoeken tonen aan dat dat niet gaat werken.
Al het hierboven aangedragene beweegt zich op een detail-niveau waarop een ‘directeur+’ zich niet beweegt. Op het Directeur+-niveau gaat het om het WAT en zelden om het HOE.
Maar inderdaad “je kunt alles uitbesteden, behalve het opdrachtgeverschap”.
Of anders gezegd : ‘de *eind*verantwoordelijkheid voor Governance & Compliance kan niet worden gedelegeerd’. Ook al omdat die eindverantwoordelijkheid wettelijk is vastgelegd en onderhevig is aan politieke controle.
We hebben hebben het met andere woorden dus over strategisch opdrachtgeverschap.
Met een bottom-up ‘Out-of-the-Box-denken’ zal men geen oplossing bereiken.
Met een top-down ‘Outside-the-Box-denken’ zou men kunnen stellen dat Directeur+-ambtenaren – teneinde strategisch opdrachtgeverschap in te kunnen vullen – ‘BIT-proof’ moeten zijn en op IPMA-A-niveau moeten kunnen acteren.
Dat is een geheel andere benadering en invulling, maar op het juiste niveau, en ook volstrekt haalbaar.