Staat het BIT op omvallen? Heeft het BIT eigenlijk wel zin? Zijn de ICT-projecten bij de overheid beter te beheersen? De problemen bij het BIT waren grotendeels te voorzien: de verkeerde problemen werden aangepakt binnen de verkeerde cultuur, de verkeerde organisatie en door de verkeerde personen.
Het NRC publiceerde twee artikelen over de negatieve houding van ministeries t.o.v. het Bureau ICT-toetsing (BIT). Het Bit zou te kritisch zijn en de ambtelijke top van het ministerie van BZK zou het BIT zelfs tegenwerken. Eerder kwamen al berichten in het nieuws over problemen binnen en buiten het BIT en stond de positie ter discussie.
Achtergrond
Al vele jaren staan ICT-projecten bij de overheid in een kwaad daglicht. Vele projecten mislukken, er is veel ophef over enorme overschrijdingen van tijd en budget. ICT-projecten van de overheid zijn zeer vaak negatief in het nieuws.
In 2015 werd door de Tweede Kamer de Tijdelijke Commissie ICT ingesteld onder leiding van Ton Elias. Deze commissie onderzocht een aantal ICT-projecten en zocht naar een rode lijn. Het viel op dat een van de grootste ICT-drama’s, het project SPEER van het Ministerie van Defensie, niet op de lijst van de “Commissie Elias” stond.
Uiteindelijk adviseerde de commissie om het Bureau ICT-toetsing (BIT) op te richten. Vanwege het grote belang en de onafhankelijkheid zou het BIT geplaatst moeten worden binnen het Ministerie van Algemene Zaken, onder de verantwoordelijkheid van de Minister-President.
Het parlement was het grotendeels eens met de conclusie van de commissie. Het BIT werd ingericht maar het parlement besloot om het bureau te plaatsen onder de CIO-Rijk binnen het Ministerie van BZK.
Sinds de start van het BIT waren er kritische geluiden te horen. Men zou onvoldoende kritisch, inconsequent en te laat reageren op problemen. Ook was er ophef over personen wat leidde tot verplaatsing van het BIT; het viel niet meer onder de CIO-Rijk. Recent kwamen berichten naar buiten dat diverse belangrijke spelers het BIT verlieten, volgens de wandelgangen uit onvrede met het beleid.
Fundamentele problemen
In mijn optiek waren de problemen bij het BIT grotendeels te voorzien: de verkeerde problemen werden aangepakt binnen de verkeerde cultuur, de verkeerde organisatie en door de verkeerde personen.
Verkeerde problemen
Het ging al vanaf het begin mis. De Commissie Elias richtte zich op ICT-projecten. Uiteraard volgt deze redenering het algemene gevoel dat juist dit soort projecten bijzonder is en daardoor grotere problemen oplevert. Het is helaas zo dat projecten die niets met ICT te maken hebben ook vaak grote problemen opleveren.
Een voorbeeld is de aanschaf van de nieuwe auto voor de politie. Om nog maar te zwijgen over de problemen bij het UWV, de Belastingdienst, de Nationale Politie en de "hervormingen" van de zorg.
Denk ook aan de recente problemen rond de verbouwing van het Binnenhof. Hier treft men een patroon aan dat sterk doet denken aan ICT-projecten; de opdrachtgever geeft de regie aan de opdrachtnemer en is na verloop van kostbare tijd gefrustreerd over tegenvallende resultaten. De opdrachtnemer ging in een ongewenste richting en werd gedreven door eigen belangen. Het is hierbij irrelevant of de opdrachtnemer een interne of externe commerciële partij is.
De echte problemen hebben weinig met ICT te maken maar veel meer met een organisatiecultuur die is gericht op stabiliteit en efficiëntie. Een gevolg is dat elke verandering, en dus ook (ICT) projecten, verkeerd wordt aangestuurd en problemen oplevert.
ICT-projecten komen in de problemen omdat het ICT-projecten zijn
Op verzoek van een parlementslid heb ik mij in 2013 gericht op een van de meest aansprekende ICT-projecten: SPEER bij het Ministerie van Defensie. Mijn analyse had als kern dat men zich mechanisch richtte op ICT terwijl de verandering vooral organisatorisch, logistiek was. ICT werd gezien als doel waar het slechts een middel was. Deze problematiek is niet uniek voor de overheid; een SAP-implementatie bij Lidl mislukte kostbaar op vergelijkbare wijze.
Op verzoek van Managementsite heb ik een verkorte versie geschreven van mijn SPEER-analyse. Deze bijdrage kreeg als titel: ICT-projecten komen in de problemen omdat het ICT-projecten zijn. Er zijn slechts heel weinig echte ICT-projecten. Dit zijn projecten van puur technische aard waarbij geen directe eisen en wensen van eindgebruikers in geding zijn. Voorbeelden zijn het inrichten van een server.
Verreweg de meeste “ICT-projecten” zijn niet primair technisch maar organisatorisch van aard. Wanneer de focus op de techniek komt te liggen onder aansturing van een technische ICT-manager (CIO), zijn problemen als bij SPEER en Lidl volstrekt voorspelbaar.
De Tijdelijke Commissie ICT ging hieraan volstrekt voorbij.
Met het BIT meer ICT expertise?
De commissie Elias wilde met het BIT meer ICT-expertise binnenhalen als "waakhond". Op grond van het voorgaande mag duidelijk zijn dat ik dat niet als oplossing zag maar eerder als versterking van de problemen.
Meer ICT-expertise binnenhalen als "waakhond" betekent juist een versterking van de problemen.
Er is hier sprake van een cultureel probleem. De vragende kant, een klant of opdrachtgever, zal zich richten op voordelen van een verandering. Daarentegen zal de leverende kant, de leverancier of opdrachtnemer, zich richten op het maken van het product en op de techniek. Ongeacht of de klant daarmee voordelen zal kunnen behalen of niet.
Wanneer de leverancier macht krijgt, zoals vaak gebeurt met “ICT-projecten”, zal het resultaat niet voldoen aan verwachtingen van de klant.
Dat werkt in het dagelijks leven zo; niemand zal een supermarkt binnenstappen en vervolgens aan de manager vragen om het winkelwagentje te vullen. Toch is het bij “ICT-projecten” gangbaar.
Bij SPEER lag de “regie” (wat hier ook mee werd bedoeld) bij een externe, commerciële leverancier en werd de Defensie-CIO gezien als opdrachtgever. Zie hier de oorzaak van het probleem van SPEER in een notendop.
Met het BIT heeft de Commissie Elias dit mechanisme versterkt. Er werden ICT-ers geworven om (met een focus op ICT) de “ICT-projecten” te toetsen. Door de plaatsing onder de CIO-Rijk werd de verkeerde focus nog eens versterkt.
De (cultuur van de) ICT-leverancier kreeg het nog meer voor het zeggen.
Organisatiecultuur van de overheid
De keuze voor het BIT en de positionering daarvan past echter wel in de heersende organisatiecultuur van de overheid. De overheid is georganiseerd als een Tayloristische machinebureaucratie. Vanuit het idee om zo efficiënt mogelijk te werken, is de overheid georganiseerd in gespecialiseerde silo’s. Zo is “beleid” en “uitvoering” meestal gescheiden en zijn diverse organisatiedelen op afstand geplaatst, bijvoorbeeld in ZBO’s.
Daarvoor betaalt overheid een hoge prijs; de flexibiliteit en de effectiviteit laten ernstig te wensen over wanneer een situatie afwijkt van de routine. Verandering verloopt uiterst moeizaam en mislukken van projecten ligt voor de hand.
Vanwege de gespecialiseerde silo’s hebben diverse organisaties grote afhankelijkheden met elkaar. Daardoor is besturing problematisch en zijn bestuurders moeilijk aan te spreken.
Toch boven verwachting
Toch heeft het BIT boven verwachting gepresteerd. Tegen de verwachting in heeft het bureau zich uitgelaten over de rechtvaardiging van bijvoorbeeld de Operatie BRP, waar kon worden verwacht dat de ICT-ers zich slechts zouden richten op technische haalbaarheid. Dat het BIT zich structureel laat en onvoldoende uitsprak over de rechtvaardiging van “ICT-projecten”, was dan weer wel een gevolg van hun focus.
De reden dat het BIT boven verwachting presteerde, ligt vooral op het persoonlijke vlak. De inmiddels opgestapte CIO-Rijk keek verder dan zijn ICT-neus lang was. Ook het inmiddels afgetreden Bureauhoofd vervulde in deze zin een positieve rol.
De overheids-cultuur wint
Diverse belangrijke personen zijn inmiddels verdwenen. Het BIT kreeg soms juichende kritieken maar ook was er erg veel weerstand. Binnen de cultuur en organisatiestructuren van de overheid wordt toezicht van buitenaf niet op prijs gesteld wanneer er sprake is van kritiek.
Gebrekkig opdrachtgeverschap
Wat ook de toekomst is van het BIT, er zal altijd sprake blijven van structurele problemen.
De overheid heeft problemen met alle soorten projecten; niet slechts met “ICT-projecten”. Daar zal een toezichthouder vanuit de ICT-discipline niet veel aan veranderen.
Juist aan de kant van de opdrachtgever hebben overheidsprojecten zeer veel te winnen.
Uit bijvoorbeeld de mislukte Operatie BRP blijkt dat de echte problemen aan de kant van de opdrachtgever liggen. Weliswaar stond bij BRP geen ICT-leverancier aan het roer maar een functionaris van de vragende kant. Maar door een volstrekt kortzichtige focus op tijd en budget valt deze opdrachtgever zeer veel te verwijten.
Nico Viergever
Noot Redactie. Zie ook het Dossier ICT projecten en IT projectmanagement bij de overheid waarin ManagementSite het slagen en falen van ICT projecten systematisch bijhoudt en de remedie op 1A4'tje heeft samengevat.
Kom met uw praktijkervaringen op het terrein van managen en organiseren
Deel uw kennis, schrijf 3 columns of artikelen en ontvang een gratis pro-abonnement (twv €200)
Word een pro!
SCHRIJF MEE >>
Maar veel van de verdere analyse is volstrekt fout. Bedrijven moeten juist wel standaard SW aanschaffen, als ze geen bijzondere processen hebben die een concurrentie voordeel hebben. Alleen als een bedrijf iets bijzonders heeft in zijn processen dat een wezenlijk concurrentie voordeel oplevert is maatwerk SW te justificeren als een dergelijk proces nog niet ondersteund wordt door SW die op de markt is.
Lees het, overigens vaak verkeerd begrepen, artikel van Carr uit 2003 nog eens heel grondig en laat de verregaande consequenties daarvan nog eens goed tot u doordringen.
https://hbr.org/2003/05/it-doesnt-matter
Er staat helemaal niet dat je bij oude technologie moet blijven of alleen standaard SW mag gebruiken. Maar er staat dat je heel kritisch moet zijn wanneer je maatwerk SW inzet. Voor de overgrote meerderheid van organisaties volstaat “HEMA-software”, oftewel gewoon standaard SW, waarbij de organisatie zich aanpast aan de best practices die in die SW zitten. Wie denkt dat hij een financiële administratie beter op een andere manier kan runnen dan in de SW van Exact is geprogrammeerd, en dus dure aanpassingen doet aan Exact, is in 99,9% van de gevallen niet goed wijs!
De gedachte dat eigen processen heel slim zijn, en dat er daarom geen SW is die dat op precies die manier ondersteunt, is de hoofdoorzaak van de vele mislukkingen bij informatieprojecten in de overheid en bij bedrijven. Omdat er dan maatwerk SW gemaakt wordt, of standaard SW van bijvoorbeeld SAP megalomaan aangepast wordt, om de eigen dommigheden van processen te kunnen implementeren; of, erger nog, de misfit van het gekozen pakket weg te poetsen.
Dat stelde Carr al in 2003 heel scherp aan de kaak; maar de consequenties daarvan zijn nog slecht in de IT-sector doorgedrongen. En de business verantwoordelijken weten logischerwijze niet beter en worden misleid door mooie verkoopverhalen van bijvoorbeeld SAP.
Ik heb geen oordeel over wat bij Speer (Defensie) aan de hand was. Uiteraard zat daar ook de lijnorganisatie te weinig aan de knoppen. Daarnaast zijn er, volgens de filosofie van Carr, 3 mogelijkheden van fundamentele gemaakte fouten:
1. De processen waren onverstandig en ze moesten toch zo nodig precies zo in de aangepaste SAP SW komen. Remedie: de processen hadden eerst opnieuw ontworpen moeten worden en vervolgens had standaard SW prima kunnen passen.
2. De processen waren prima, maar:
a. met SAP is de verkeerde keuze gemaakt, er waren andere pakketten die beter zouden aansluiten bij de bijzonderheden. Remedie: kies een ander pakket dat veel beter aansluit, en waarbij geen of nauwelijks aanpassingen nodig zijn.
b. de bijzonderheden van die processen zijn onvoldoende geïsoleerd, waardoor onnodig grote ingrepen in standaard SAP SW is gedaan. Remedie: isoleer de bijzonderheden en kies daarbij het beste pakket en pas dat zo nodig een beetje aan of maak nieuwe maatwerk SW voor dat onderdeel. Voor de overige procesonderdelen gebruik je standaard SW!
Hieruit blijkt dat er wel degelijk een zeer belangrijke sturende rol van een deskundige CIO/IT-er of architect nodig is in IT-projecten om dergelijke keuzes verantwoord te maken; gebruikers en lijnmanagement kunnen dat i.h.a. echt niet. Maar uiteraard wel in zeer nauwe samenwerking met “de business”, zodat de business doelen voorop blijven staan.
"veel van de verdere analyse is volstrekt fout"? Grote woorden. Is dit persoonlijk?
Ik zie bij de rest van jouw reactie geen (directe) relatie met mijn verhaal.