Management
Waarom 2022 een rampjaar was voor grote IT-projecten van de overheid
IT-budgetten grote projecten inmiddels met 1,3 miljard overschreden.
IT-budgetten grote projecten inmiddels met 1,3 miljard overschreden.
2022 was opnieuw een rampjaar voor de grote IT-budgetten van de overheid. Het merendeel (64%) van de 119 grote IT-overheidsprojecten van meer dan 5 miljoen euro is nog altijd fors vertraagd en de totaal beraamde kosten van de grote projecten stegen door naar 6 miljard, ruim 1,3 miljard meer dan gepland. Hoe komt het dat grote IT-projecten altijd uit de hand lopen? AG Connect en Binnenlands Bestuur analyseerden de tien duurste IT-projecten in uitvoering.
In 2022 bestierde de overheid 119 grote IT-projecten ter waarde van inmiddels een kleine 6 miljard euro. Bijna twee op drie IT-projecten (64%) liep inmiddels vertraging op. Voor 44% geldt zelf al meer dan een jaar vertraging. In 2022 werden vier IT-projecten met succes afgerond, maar aan de overige 115 IT-projecten worden meegenomen naar 2023. Daaronder vallen ook tien kolossale projecten van meer dan 100 miljoen euro, die allemaal zo hun eigen problemen kennen.
Top 10 projecten vs. de rest
Er zit een opmerkelijk gapend gat tussen de top tien IT-projecten en de rest van de 119 projecten boven de 5 miljoen euro. Niet alleen zijn de budgetten veel groter, ook de overschrijdingen zijn dat. Voor de tien duurste projecten is nu zo’n 701 miljoen euro meer uitgegeven dan oorspronkelijk gepland. De overige 109 projecten zijn samen goed voor ruim 600 miljoen aan budgetoverschrijding.
Deze ‘stille IT-ramp’ van de overheid kent uiteenlopende oorzaken, maar bij de grootste projecten zijn belangrijke gemene delers aan te wijzen. Om de oorzaken van al die vertraging en uit de hand gelopen kosten in kaart te brengen, bestudeerden AG Connect en Binnenlands Bestuur de top tien duurste IT-projecten. De stand van zaken per project wordt de komende dagen in een serie gepubliceerd op de websites.
Media-aandacht beperkt
Slechts enkele van de top 10 projecten genieten publieke belangstelling en worden in de Tweede Kamer op de voet gevolgd, waaronder de veel bekritiseerde IT van de Belastingdienst en de software van de Omgevingswet. Het merendeel van de 119 grote IT-projecten wordt in de Kamer niet of amper besproken, terwijl ze gezamenlijk 1,3 miljard duurder dan gepland zijn. Ter vergelijking: de in het NOS-journaal veelbesproken Fyra-treinen zorgden voor een verlies van 67 miljoen euro.
IT-specialist Rene Jan Veldwijk, die eerder falende projecten als de Basisregistratie Persoonsgegevens in de media op de kaart te zette met kritische artikelen in Computable, ziet de belangstelling rondom IT in de Kamer terugvallen. Hij vindt dat de Tweede Kamer de almaar uitdijende IT-projecten niet scherp genoeg volgt, zo vertelt hij aan AG Connect en Binnenlands Bestuur. “Met name de versplintering in de politiek is een probleem. Partijen met minder dan tien zetels hebben geen IT-specialisten. En wel goed presterende Kamerleden krijgen al snel andere portefeuilles.” Veldwijk is niet verbaasd over de enorme bedragen waarmee budgetten worden overschreden. “Dit is het grootste ‘spending’ kabinet sinds lange tijd. De bedragen zijn voor burgers abstract. Een miljoen of een miljard voor een IT-project, dat verschil merkt niemand op.”
De rol van de Tweede Kamer
Kees Verhoeven, meerdere keren verkozen als IT-politicus van het jaar, deelt die kritiek. Volgens hem zitten Kamerleden soms liever in spelshows op tv dan dat ze op achter een bureau IT-projecten doorspitten. “Voor veel Kamerleden zijn IT-dossiers niet spannend genoeg, alleen als het helemaal mis blijkt te zijn staan ze bij de interruptiemicrofoon schande te roepen. Maar tot die tijd worden geen vragen gesteld over projecten die niet lekker lopen, terwijl een vinger aan de pols heel belangrijk is om verdere rampspoed te voorkomen.” De in de politiek gelouterde Verhoeven denkt dat Kamerleden genoeg informatie krijgen van het kabinet: “De brieven worden verstuurd, soms op onhandige tijdstippen. Maar ze worden niet proactief gevolgd.”
Erfenissen uit de periode 2014-2016
Bij het onder de loep nemen van de top tien duurste IT-projecten valt op dat acht tussen 2014 en 2016 zijn opgestart. Een periode waarin men Den Haag al de geldverslindende IT-mislukkingen achter de rug had. Terwijl het bedrijfsleven overstapte naar ‘lean en agile’, bleef de overheid kiezen voor groots opgezette projecten. Wel was het toezicht inmiddels flink aangescherpt met de in 2012 ingestelde Commissie Elias, naar een leiding van Parlementair onderzoek naar IT-projecten bij de overheid. IT-projecten werden in de jaren erna kritischer bekeken dan ooit en beoordeeld door externe bureaus en toezichthouders, zoals bureau BIT (nu AcICT). Vrijwel ieder project uit de top 10 moest na de start opnieuw naar de tekentafel omdat verschillende randvoorwaarden voor een succesvolle implementatie bleken vergeten.
Te veel complexiteit
In de snel digitaliserende samenleving liep de overheid over van ambities op IT-vlak. Denk aan incidenten op de Noordzee gedetailleerder in beeld krijgen, de IT-systemen van de Belastingdienst vernieuwen, moderne verkeersmanagementsystemen realiseren, het luchtverkeersleidingsysteem van Schiphol vervangen. Allemaal complexe megaprojecten die nu grote vertraging en extra kosten kennen. Hét voorbeeld bij uitstek van te veel complexiteit is de software van Omgevingswet (nr. 5). Om een vloeiend systeem op te tuigen waarmee burgers met één klik vergunningaanvragen toetsen, moet informatie uit duizenden bronnen worden samengebracht, met ruim 90.000 verschillende begrippen en ontelbaar veel regels op gebied van onder meer brandveiligheid, cultuurhistorie, water en natuur. Bovendien moest de informatie van honderden verschillende organisaties komen. Critici noemden het project ‘een te complexe wonderdoos’. Nadat het project meerdere keren werd uitgesteld staat het nu vooral nog in het teken van vereenvoudigen en vele fouten oplossen.
Volgens Verhoeven is het nagenoeg een feit dat grote projecten nu eenmaal uitlopen. “Er is een natuurlijke neiging om ze te optimistisch in te schatten. Vanuit de Tweede Kamer is er veel druk om IT-projecten snel en goedkoop te regelen. Er wordt gevraagd om systemen die maatwerk kunnen leveren en daarbij enorm veel informatiefactoren moeten verwerken. Dat vergt zeer complexe IT die doorgaans niet waargemaakt kan worden, zoals de Omgevingswet.” Volgens Verhoeven krijgen ambtenaren die vaak héél goed hun werk zijn onterecht de schuld van ‘falende IT-projecten’. “Wanneer de besluitvorming telkens het uiterste vraagt, dan is het niet heel verrassend dat ze misgaan. Een reële inschatting wordt zelden gegeven.”
Wetswijzigingen worden grote IT-projecten
Wat ook opvalt in de top 10 IT-projecten is dat IT-systemen moeten worden aangepast op wetgeving die vanuit de Tweede Kamer wordt bedacht, waar kennis over IT bij velen amper aanwezig is. Zo werd in 2022 door de Tweede Kamer onder meer besloten dat de btw op groente en fruit verlaagd moet worden, wat aanpassingen in IT-systemen vergde die jaren zullen duren. Hetzelfde is ook terug te zien in Brussel, waar de Europese Commissie douane-systemen en regelgeving wilde uniformeren (nr. 10), waarna vervolgens ieder lidstaat op eigen houtje de IT-systemen moet aanpassen. Ook de eerdergenoemde Omgevingswet (nr. 5) had al lang moeten ingaan, maar is gekoppeld aan software die er verre van klaar voor is.
Wetgeving aanpassen en maatwerk vragen drijven ambtenaren die het moeten uitvoeren tot het uiterste op IT-gebied. “De AOW is een goed voorbeeld van hoe het óók kan. Dat is een zeer eenvoudige regeling: iedereen krijgt AOW, het bedrag is overal hetzelfde. Wanneer je de AOW inkomen gerelateerd gaat maken, heb je echter een heel ingewikkeld systeem nodig om alle persoonlijke factoren mee te nemen. De AOW kent die problemen niet vanwege zijn eenvoud.”
Grote beloftes
Een terugkerend patroon lijkt echter dat er vanuit Den Haag steeds grote beloftes worden gedaan, maar dat er geen of weinig zicht is op de IT-uitvoeringscapaciteit van de overheid. Verantwoordelijken schuiven ingewikkelde IT-projecten vaak graag door naar een volgend kabinet. Jarenlange vertragingen zijn daardoor eerder regel dan uitzondering. Sommige IT-projecten duren al meer dan tien jaar, bijvoorbeeld de vernieuwing van verkeersmanagementsystemen van Rijkswaterstaat (nr. 7) en de modernisering van het communicatienetwerk C2000 voor de hulp- en veiligheidsdiensten (nr. 3). Beide projecten hebben weliswaar grote stappen gemaakt, maar zijn nog altijd niet helemaal afgerond.
Meer dan alleen een IT-systeem
Voor de top tien projecten geldt vaak dat de plannen voor nieuwe IT-systemen niet goed uitgewerkt zijn. Kosten nemen een vlucht omdat er meer bij komt kijken dan alleen een nieuw systeem ontwikkelen. Dit is onder meer terug te zien bij de nieuwe verkeersmanagementsystemen van Rijkswaterstaat, waarbij toen het project in gang werd gezet nog niets in kaart was gebracht over de kosten van de implementatie en de wijziging van werkprocessen. Het nieuwe Maritiem Operatiecentrum voor de Kustwacht (nr. 6), waarbij het project al bezig zonder de behoeftes van ketenpartners in kaart te brengen is ook een voorbeeld. Plannen voor nieuwe IT-systemen worden meestal gewijzigd (scope-wijziging) vanwege de aard, omvang en beperkingen van het project die later pas duidelijk worden.
Legacy-problemen en datakwaliteit
Veelvoorkomend zijn ook ambitieus opgezette projecten die al snel stokoude problemen tegenkomen die lang zijn blijven liggen. Zo viel de vernieuwing van het Basisregister Onderwijs (nr. 9) 35 miljoen duurder uit door diverse tegenvallers op gebied van legacy en de beroerde datakwaliteit. Registraties hebben eerst ‘opschoning’ nodig voordat de migratie naar een nieuw systeem kan starten. Bij de vernieuwing van de IT-systemen van de Belastingdienst (nr. 2) zijn dezelfde soort problemen om de hoek komen kijken, alleen dan een graadje erger. Ingevlogen onderzoekers troffen al snel een ‘technische schuld’ aan van meer dan 50%, wat betekent dat meer dan de helft van de applicaties is aan vervanging toe was.
Sommige systemen, zoals die van de omzetbelasting, dateren zelfs uit 1982 en belastingpercentages kunnen niet worden aangepast. Volgens IT-specialist Veldwijk wordt ‘handwerk’ bij ICT-projecten nog wel eens onderschat, met name rondom projecten waarbij de datakwaliteit van registraties moet worden opgeschoond. “Gemeenten bijvoorbeeld, voeren allemaal registraties over personen in. Soms zitten er in de registraties waanzinnig veel inconsequenties. Dan weet je als overheid niet meer wat waarheid is. Het kost vele uren om alle fouten eruit te krijgen.”
Toevallige tegenvallers
Dan zijn er nog reguliere tegenvallers waarmee ieder IT-project te maken heeft. Uit de analyse van de top 10 IT-projecten wordt in ieder geval duidelijk dat twee van de 10 projecten tijdens de coronapandemie nog verder in het slop zijn geraakt. Juist tijdens de belangrijke implementatiefase werd het niet of nauwelijks mogelijk om internationaal te reizen voor leveranciers. Daardoor liep het nieuwe verkeersmanagementsystemen van Rijkswaterstaat (nr. 7) verdere vertraging op. Ook bij het nieuwe Maritiem Operatiecentrum voor de Kustwacht (nr. 6) werden operationele werkzaamheden op locatie tijdelijk stopgezet, wat een flinke vertraging opleverde en extra miljoenen kostte.
Ook het gebrek aan voldoende personeel de laatste jaren een steeds nijpender probleem, dat vaak wordt omgezet in extra vertraging. Zo werkt het ministerie van Infrastructuur en Waterstaat aan een miljarden kostend digitaal systeem voor treinbeveiliging (nr. 1), maar monteurs voor de benodigde aanpassingen aan de treinen en sporen zijn amper te krijgen. Door de soms forse vertragingen in de projecten vormen prijsbijstellingen en indexeringen een flinke extra kostenpost. Zo steeg het benodigde budget door van 2,4 naar 2,5 miljard door.
Rol toezichthouder
Wat opvalt bij de top 10 grote IT-projecten is de belangrijke rol van de toezichthouder BIT (nu AcICT). Ieder groot IT-project werd tussentijds of vooraf van scherpe kritiek voorzien, maar het effect is niet altijd duidelijk. Opvallend is de rol die het BIT speelde in 2017 toen het UWV een nieuw datacentrum (nr. 8) wilde bouwen. Het UWV was een klant bij IBM, maar omdat BIT vreesde voor een lock in-effect werd geadviseerd om in zee te gaan met een andere partij die lagere contractkosten hanteert: het consortium bestaande uit DXC Technology, CGI en Equinix. De transitie naar het nieuwe datacentrum bleek vervolgens veel meer werk dan gedacht en pakte veel duurder uit, zo’n 50 miljoen meer dan de oorspronkelijke planning. De vraag rijst daardoor of UWV niet beter gewoon bij IBM had kunnen blijven.
Voortgang in 2023 onduidelijk
2023 is voor de top 10 projecten cruciaal, maar de voortgang van diverse IT-projecten is al een tijdje niet bijgewerkt op het ICT Dashboard. De doorontwikkeling van het Basisregister Onderwijs (nr. 9) zou in 2022 al worden afgerond, maar het project is nog niet afgemeld op het ICT Dashboard van het Rijk. Het UWV moet volgens planning halverwege 2023 volledig over zijn naar een nieuw datacenter, maar de Tweede Kamer werd voor het laatst in 2021 hierover geïnformeerd. De Omgevingswet moet halverwege 2023 worden ingevoerd, al zijn de laatste signalen hierover vanuit gemeenten zijn dat dit zéér lastig gaat worden. Het Radiobedienings‐ en Alarmeringssysteem (RABS) van het communicatienetwerk C2000 (nr. 3), waar al sinds de jaren negentig aan wordt gewerkt, moet halverwege 2023 dan écht worden zijn afgerond. In de media blijft het vooralsnog relatief stil over deze onderwerpen.
Geleerd van het verleden
Verhoeven gelooft dat er geleerd is van lessen uit het verleden. “Er is meer kennis dan ooit, projecten worden beter ingericht en er is dankzij Commissie Elias en BIT meer grip dan voorheen. Het zou alleen prettig zijn als de politieke besluitvorming niet voortdurend het onmogelijke vraagt de ambtelijke organisatie. Stel je ambities bij, doe minder lukraak beloftes aan de burger en wees reëel over budgetten en looptijden.”
@R. Heinen: En als Hammer & Champy niet overtuigen, dan is er nog de 'DEMO methode' van Jan Dietz, of 'Rapid Enterprise Design' van J.B.F. Mulder. Research van beide wetenschappers heeft zijn waarde in de praktijk inmiddels al vaak bewezen.
@R. Heinen: legacy naast een nieuw systeem? Uit onderzoek is gebleken dat bij omvangrijke processen het beter is om eerst het proces te vernieuwen. Lees hiervoor bijvoorbeeld het boek 'De bijl aan de wortel' van Hammer & Champy. De Belastingdienst is een voorbeeld: de belastingwetgeving is inmiddels zo complex gemaakt dat een wijziging in de systemen doorvoeren al gauw drie jaar vergt.
Naar aanleiding van Commissie Elias werd een parlementaire enquete gehouden. Daarin werden ook een aantal experts bevraagd waaronder Prof Hans Mulder en Prof Chris Verhoef. Onafhankelijk schatten zij de faalkosten van "IT-projecten bij de overheid" toen op een bedrag in de ordegrootte van (naar ik me herinner) 5 miljard/jr resp 2 miljard/jr. En "falen" in de betekenis van : tijd is op, geld is op en je hebt NIETS.
Als ik het artikel zo lees is het er zoveel jaar nog niet echt beter op geworden. Het blijft toch verwonderlijk en stuitend hoe hardleers de overheid is. Blijkbaar teveel onkunde en onvermogen en een politiek die denkt dat alles kan en ook snel.
Wat mij betreft zouden geleerde lessen nu eindelijk eens geleerd mogen worden:
1 - IT-projecten bestaan niet. Het zijn organisatieveranderingen waarin een grote proces, informatie en technologiecomponent zit, die samenhangen met gelijktijdige veranderingen in bijv dienstverlening of werkwijzes. En dat hierbij veel legacy opgeruimd moet worden (systemen, processen, maar ook werkcultuur en ingesleten patronen) dat mag duidelijk zijn.
2 - Door de Standish Group wordt al tientallen jaren onderzoek gedaan naar succes- en faalfactoren van IT-gedreven veranderingen. Ze hebben meen ik wereldwijd zo'n 50.000 projecten geevalueerd. Daarbij onderscheid tussen aanpakken (waterval, agile) en omvang/complexiteit van projecten.
Overheid (politici, ministers, ambtenaren): Lees hun top 10 van factoren en je weet voor altijd waar je op moet letten.
Ik zal een voorbeeld geven wat ikzelf heb ervaren. Als programmeur bij CFI werd ik in 2005 ingezet bij een nieuw project LONDO (Een systeem die de salarissen voor leraren moest bereken) dat ter vervanging diende van het “oude” systeem. De directeur (Mw. Oldeniel) had samen met een externe kompaan uitgedacht dat dit op een nieuwe leest diende te geschieden. Dat hield in dat er diverse componenten waren, die elk een eigen taak zouden hebben. Elk component werd een database-object. Communicatie tussen diverse systemen deden wij vroeger met database-links, maar dit nieuwe systeem kreeg een aparte manier van communiceren, door gebruik te maken van berichten. Had je bijvoorbeeld bij het berekenen extra informatie uit een andere component nodig, dan werd er een bericht samengesteld, waarin diverse gegevens in voorkwamen, zoals het vragende component en welke gegevens het uit het andere component wilde hebben. Dit bericht werd dan verstuurd naar een bovenliggend systeem die dat bericht dan naar het juiste component verstuurde. Het ontvangende component moest dan dat bericht uitlezen, waarna met de vraag aan de slag werd gegaan. Wee je gebeente als dat ontvangende component nog iets moest hebben uit een nog ander component. Dan maakte dat component ook weer een bericht aan en stuurde dat weer door naar… etc, etc, etc. Tenslotte kreeg het eerste component antwoord op zijn vraag en kon aan de slag tot aan de volgende vraag.
Kortom, de berichten vlogen om je oren en als er iets fout ging in de procedure, zat je je gek te zoeken waar het fout ging.
Ik heb destijds aan mijn meerdere geantwoord dat dit het niet ging worden, maar het was de opdracht van de directeur, dus…
Het systeem was op een gegeven moment klaar en het werd uitgetest. Rete traag was het. Nadat mijn collega samen met een externe kracht dit systeem op zijn snelst werkend had gekregen, deed de berekening van de salarissen van leraren er een knappe week over en de directie was enthousiast.
Echter, het oude systeem deed er slechts één nacht over. Wat heet dan vooruitgang??
Uit de analyse blijkt dat van de 100% er 31% aanpassingen en 18% endogene wijzigingen zijn. Oftewel, bijna 50% is puur door aangepaste eisen aan het project. Dit noemen we scope creep; elke wijziging hierop heeft een effect op doorlooptijd, budget en functionaliteit. Als dit in scope wordt genomen, gaat de overheid daarmee akkoord met die wijzigingen en kun je niet spreken van uitloop of duurdere projecten.
Laat onverlet dat de overheid IT weliswaar moet doen maar dat dit niet hun core-activiteit is. Koppel daarbij de technical debt die bij de overheid (en bij willekeurig welke groot bedrijf) bestaat en de belabberde datakwaliteit dan is het niet verbazend dat projecten veel langer duren en meer kosten.
Om dat op te lossen, zijn er verschillende mogelijkheden. Denk aan teams met focus op constante dataverbetering, focus op technical debt (waaronder uitschakelen en afbreken), compartimentalisering van software (denk aan bijv microservices) en op een agile manier de systemen verbeteren of vervangen. Dat dit niet in een vloek of een zucht klaar is, is wel helder. Dat dit beter moet, ook.
Eind jaren 90 was er een chef bij CFI die zijn automatiseringsafdeling wilde uitbreiden tot minimaal 149 mensen, die allen een eigen specifieke taak zouden uitvoeren. De bedoeling was om die aantal medewerkers niet alleen voor CFI te laten werken, maar voor elk ministerie die daar behoefte aan had.
In een kort tijdsbestek werd dit idee in flarden geschoten, want het toverwoord van de almachtige bestuurders heette “uitbesteding”. En vanaf het moment dat er werd uitbesteed, heb ik (eerst als programmeur, en daarna als informatieanalist/functioneel ontwerper zijnde) zelf mogen ervaren dat alles trager werd opgeleverd. Elke wijziging in een (nieuw) systeem moest bij de outsourcer aangemeld worden, waarna het pas in een periodieke aanpassingssessie werd opgenomen. Voorbeeld: Een jaar na mijn pensioen hoorde ik dat een wijzigingsvoorstel van mijn hand eindelijk was doorgevoerd. Wat heet dan slagvaardig !?!?
Wat ik begrepen heb, wordt nu ook het analyse en systeemontwerp geoutsoured. Mensen die niks van de gebruikte systemen weten. Als programmeurs worden meestal jonge mensen gebruikt, die bij de overheid het programmeren echt gaan leren toepassen, dus nagenoeg totaal geen ervaring bezitten. Maar waar wel knappe bedragen voor neergelegd moeten worden. Dus dat brengt al grote vertragingen mee. Daarnaast doet zich voor dat ervaren uitvoerders (ambtenaren dus) van die systemen niet bij de opzet van die nieuwe systemen ingezet worden, omdat die niet op de werkvloer gemist kunnen worden. Al met al zorgt dat m.i. nu voor de chaos bij de overheid.
Oplossing zou kunnen zijn om een eigen ministerie op te richten, dat alleen voor de overheid werkt en die na verloop van tijd voldoende expertise heeft om alle systemen bij de overheid te onderhouden en dan te stoppen met het outsourcen. Scheelt mijn inziens veel aan mislukte projecten, want voor dat geld wat er nu aan mislukte, of te laat opgeleverde automatiseringssystemen wordt uitgegeven, kun je heel wat nieuwe ambtenaren betalen.
Interessante materie, maar (off topic) wel stik vol taalfouten (daar kan ik zelf ook wat van, maar in dit geval loopt het zo de spigaten uit dat ik me er aan stoor). Redactie, doe je werk!
Sjoerd,
Duidelijk.
Wat gaan wij daaraan doen als burgers/belastingbetalers (de belangrijkste stakeholder van de overheid)?
Hoe zorgen wij dat de IT-verkrotting en de datachaos bij de overheid de volle aandacht krijgt van het kabinet en de Tweede Kamer?
Heeft AG onderzoeksjournalisten die de onderste steen boven kunnen krijgen (zoiets als Watergate of de Affaire Monica Lewinsky)?
Het laatste plaatje, de tabel snap ik niet helemaal. Dat zou bij een projectje van een miljard uitkomen dat hier 330 miljoen uitgegeven wordt aan hardware, software en verbindingen?
En welke hardware, software, verbindingen hebben we het hier dan over? Ik mag aannemen dat software die nieuw geschreven moet worden (eigenlijk wat het hele project inhoud) niet onder dit veld valt?
Dus een nieuwe onderzeese glaskabel naar de USA, een compleet datacentrum in Zeewolde en een licentie Office 2016?
Dank voor deze interessante analyse. Een van de oorzaken voor de problemen zijn de legacy systemen. Een manier om de transitie van legacy systemen naar nieuwe innovatieve ICT systemen aan te pakken is om beide systemen naast elkaar te laten draaien en produktstromen 1-voor-1 van de legacy systemen naar de nieuwe ICT systemen over te hevelen.