Met grote regelmaat horen we over mislukkende ‘ICT-projecten’ bij de overheid. En telkens worden de problemen in media en parlement geframed als ‘technisch’ van aard: meer ‘experts’, beter betaalde ‘ICT-nerds’ en strikter ‘IT-projectmanagement’ moeten ons redden. Maar juist door deze framing slaan we de plank mis en komen we nauwelijks tot verbeteringen. Als we de wezenlijke inhoudelijke en organisatorische uitdagingen bij ‘ICT-projecten’ beter zouden doorgronden, kunnen we hierover beter beslissen en besturen.
In deze serie van drie artikelen gaat Wimfred Grashoff in op de oorzaken van problemen bij wat men ‘ICT-projecten’ noemt. Op het spreekwoordelijke deel van de ijsberg ‘onder water’ dat vaak niet wordt gezien. Over de valkuilen in de manier waarop we ‘ICT-projecten’ uitvoeren en om onjuiste beelden en veronderstellingen bij beslissers die bijdragen aan onverstandige keuzen. En natuurlijk volgt de hamvraag: wat dan wel?
Zeven valkuilen
1. Groot denken, groot doen!
Hoe grote ambities leiden tot grote projecten
Vaak wordt de omvang van ‘ICT-projecten’ aangewezen als risico-verhogend. Terecht! Het rapport Elias wees al op het risico van grote projecten en pleitte voor een kleinere schaal. Maar, wat is de onderliggende oorzaak is van die grote projecten en programma’s? Het antwoord: politieke en bestuurlijke ambities! In politiek en bestuur bestaat een voorliefde voor groots en krachtig optreden. En gedurende de gehele parlementaire behandeling worden aanvullende beloften gedaan en complexiteit toegevoegd. Bij dit alles óverschatten we de maakbaarheid van verandering en ónderschatten we de complexiteit bij het concretiseren van abstract beleid in echte uitvoering. En bij alles geldt: hoe groter de ingreep, hoe meer onduidelijkheden en onzekerheden er zijn (zie punt 2), hoe meer toekomst er bedacht moet worden (zie punt 3), hoe meer partijen er betrokken zijn en hoe meer tegenstellingen te overbruggen (zie punt 4). Als de politiek kleinere projecten wil, mag men zich beperken in ambities en fasering omarmen.
2. Een centimeter in de onderhandeling is een kilometer in de uitvoering
Over het feit dat ambiguïteit prettig kan zijn in politiek, maar moeilijk in de uitvoering
In politiek gedreven processen is gebrek aan duidelijkheid en ambiguïteit van ambities een veelvoorkomend fenomeen. Onderhandelingen en besluitvorming concentreren zich op de grote lijnen; ambiguïteit helpt alle partijen om een interpretatie te geven past in hun beeld. Maar, wat bestuurlijk gezien ‘de details van de details’ zijn, is voor de uitvoering vaak van wezenlijk belang. ‘Een centimeter in de onderhandelingen is een kilometer in de uitvoering’. En daar beginnen de lastige discussies in het project.
3. ‘Doet u mij maar een elastische duikboot!’
Fundamentele fricties willen oplossen over de as van de ICT
Grote ICT-projecten van de overheid dienen bijna altijd een combinatie van tegengestelde doelen en wensen:
- én decentraliseren en verhogen transparantie voor de burger
- én betere dienstverlening én goedkoper
- én flexibeler én eenvoudiger én duidelijker
Nu is overbruggen van tegenstellingen intrinsiek de uitdaging in íeder ontwerp- en bouwproces; dat kan iedere architect onderschrijven. Maar we moeten ons wel bewust zijn van deze tegenstellingen; dat er keuzen gevraagd worden en dat het tijd en geld kost om tegenstellingen te hanteren. Dat doen we nauwelijks bij ICT-projecten. Sterker nog, we dichten aan ICT volstrekt irreële mogelijkheden toe om diepgewortelde tegenstellingen te overbruggen. Als een soort wonderolie om fundamentele spanningen tussen organisaties, processen, doelstellingen, perspectieven als sneeuw voor de zon te laten verdwijnen. En zo komen veel grote ‘ICT-projecten’ vol te staan met verwachtingen van elastische duikboten en gepantserde zweefvliegtuigen.
Een mooi voorbeeld is de frictie tussen het juridisch perspectief en dienstverlening in het omgevingsrecht. Dit is een fundamentele spanning waaraan het cliché dat ‘die juristen gewoon eens begrijpelijk moeten leren schrijven’ totaal geen recht doet. Het gaat in de basis om de vraag ‘wat mag je versimpelen in de communicatie met burgers zonder het recht geweld aan te doen?’. In het digitaal stelsel omgevingswet wordt gebruik gemaakt van ‘vragenbomen’ om de gebruiker op een eenvoudige wijze de weg te wijzen in complexe regels. Dat is een prima instrument met in potentie veel toegevoegde waarde. Maar evengoed blijkt telkens de frictie tussen het juridisch perspectief en het dienstverleningsperspectief. Een compacte en begrijpelijke vragenboom ‘op hoofdlijnen’ negeert per definitie een deel van de juridische regels die mogelijk relevant zijn; een juridisch volledige vragenboom – zelfs al is die keurig geschreven in taalniveau B1 – bevat een enorme lijst vragen met flinke toelichtingen, die de gewone burger doen afhaken. De perspectieven van de planjurist (die regelmatig moet verschijnen bij de Raad van State in een beroepszaak) en die van de dienstverlener (die wanhopige reacties krijgt van burgers en bedrijven) verschillen sterk.
4. Verzin de toekomst… achter de tekentafel
Over de onmogelijkheid om wezenlijke veranderingen tot in detail te doordenken
ICT projecten hebben vrijwel nooit betrekking op het ‘automatiseren’ van het ‘hier en nu’. Het gaat bijna altijd om een (fundamentele) vernieuwing die door de ICT ondersteund moet worden. Of het nu om dienstverlening bij het UWV gaat, om regulering onder de Omgevingswet, om samenwerking bij vergunningverlening: het gaat altijd om het neerzetten van een nieuwe praktijk die wezenlijk verschilt van de huidige. Die nieuwe werkelijkheid moet op een hoog detailniveau bedacht worden om de uitvoering te kunnen ondersteunen, inclusief talloze variaties en uitzonderingen. En juist dit verzinnen van de toekomst wordt bemoeilijkt door de schaalgrootte, de uiteenlopende perspectieven van betrokkenen (zie 5), de ambiguïteit en ingebakken tegenstellingen in de doelen (zie 2 en 3) en het gebrek aan regie in de keten. Bovendien geldt bij alles: het ‘verzinsel’ blijft een ‘tekentafel exercitie’, ook al betrek je duizend praktijkmensen.
5. Eigen model eerst…
Over de moeite om te komen tot één gedeeld model van de nieuwe werkelijkheid
Het ontwikkelen van informatiesystemen is in essentie het modelleren van de werkelijkheid. Modelleren van processen, van cliënten, van bedrijfsactiviteiten, van situaties, van interacties, etc etc. Deze modellen raken een organisatie in het hart. En ze zijn onvermijdelijk een vereenvoudiging van de werkelijkheid. Niet de programmeur is verantwoordelijk voor deze modellen, maar ‘de business’. Dit blijkt keer op keer de achilleshiel van ICT-projecten. Want in grotere overheidsprojecten is ALTIJD sprake van verschillende perspectieven!
Verschillende vakdisciplines, culturen, organisaties, juridische kaders en financieringsmodellen worden via de gewenste systemen rechtstreeks met elkaar geconfronteerd. Het denken vanuit verschillende perspectieven vertraagt en belemmert het komen tot één model, tot één ontwerp. We worden het gewoon niet eens! Of te langzaam. Of er volgt een complex compromis dat te veel perspectieven probeert te verenigen. De stakeholdermap van het programma omgevingswet telt ongeveer 40 stakeholders, (de implementerende overheden zelf – ruim 400 – nog niet eens meegenomen).
De roep om ‘strakke regie’ is daarom terecht, maar ook de grootste uitdaging. Want die regie moet niet primair gericht zijn op techniek, maar vooral op ‘de business’. Regie dus die rechtstreeks raakt aan de verantwoordelijkheden van ‘de lijn’, van alle betrokken partijen binnen de scope van het project. Waarbij beslissingen worden gevraagd op managementniveau over (ogenschijnlijke) details. En juist waar het betrekking heeft op grote overheidsprogramma’s met meerdere bestuurslagen is iets wat we ‘strakke regie’ regie noemen nauwelijks verenigbaar met ons staatsbestel. Het besturen van een groot overheidsprogramma heeft meer weg van het besturen van de Europese Unie dan van het managen van een project.
6. Een lastig passend harnas
Over complexiteit en incongruentie in juridische stelsels
ICT-projecten bij overheden gaan vrijwel altijd over het uitvoeren van wet- en regelgeving. Die regelgeving is al vastgesteld als de systemen nog moeten worden gebouwd. De regels zijn flexibel als beton en op sommige punten zeer gedetailleerd; ze zijn zelf het resultaat van een afzonderlijk tekentafel-traject en net zomin in de praktijk getest. Regelmatig blijken er tegenstrijdigheden, onduidelijkheden en inconsistenties, hetzij in hetgeen gereguleerd wordt, hetzij in de procedures die gelden. Jurisprudentie kan bovendien leiden tot een her-interpretatie van regels. Dat is onvermijdelijk én in de juridische praktijk overkomelijk, want met kundige juristen én de rechtspraak (in geval van geschillen) kunnen we hier best mee omgaan. Maar in ICT-ontwikkeling zijn dergelijke onduidelijkheden en inconsistenties fnuikend. Het systeem moet immers strikt voldoen aan de regels, en dus moet de ICT de tegenstrijdigheden opvangen. Het gevolg: complexiteit en kosten.
Een laatste punt dat hier genoemd moet worden is nog dat nieuwe wet- en regelgeving zelden stapsgewijs wordt ingevoerd. Dat brengt ons bij het volgende punt.
7. Big Boem
Hoe grote massale eenmalige implementaties bijna alleen kunnen falen
En dan komt de invoering. We hebben het model doordacht, besproken, ontworpen, getest, beproefd – desnoods tot in den treure – maar het blijft in essentie toch een één grote aanname. De eerste echte confrontatie van het systeem met de échte praktijk volgt pas bij implementatie. En die is meestal ‘Big Bang’. Hoewel we weten dat dit een groot risico is, en geen enkele andere sector het zo aanpakt. Ook hier moeten we kijken naar onderliggende redenen. Enerzijds is er het kostenargument: een gefaseerde implementatie betekent meestal het in de lucht houden van oud naast nieuw. Dit vraag ook allerlei tijdelijke complexe ‘transitie-voorzieningen’ om de stukjes ‘oud’ met ‘nieuw’ te laten samenwerken. Maar vooral speelt ook hier het juridische aspect: Het invoeren van een wet is bijna altijd gebonden aan één tijdstip. Er is bijna nooit gelegenheid om proef te draaien met een kleine voorlopersgroep, want dit brengt mogelijk rechtsongelijkheid met zich mee.
In twee volgende artikelen ga ik in een aantal foutieve veronderstellingen bij bestuurders en beslissers die bijdragen aan de hier beschreven problemen en een aantal oplossingsrichtingen.
Lees de hele serie:
Veel te vaak worden bijzaken hoofdzaken, omdat de persoon van de bijzaak, meer invloed of een grotere mond heeft en geen gedetailleerd idee heeft over de hoofdzaak. Een belangrijk voorbeeld in inclusie bij digitalisering. Bij elk ICT project wordt hierop gehamerd. Het is een belangrijk aspect in het algemeen belang, dus moet inclusie ook gezien worden als algemeen belang. Inclusie hoort geen ICT project te zijn, maar dient naast een ICT project te staan. Het belang van inclusie en het belang van het ICT project is hiermee het best gediend en bereikt hierdoor het beste resultaat voor beide onderdelen.
Beste Poppe, ik kan me vinden in de observatie dat soms ‘bijzaken’ in een project of programma veel aandacht krijgen omdat een specifieke stakeholder in staat is daarvoor veel aandacht te genereren.
Ik begrijp nog niet precies hoe je aan kijkt tegen ‘inclusie’ is in je voorbeeld. Beschouw je dit als een bijzaak waarop wordt gestuurd, of juist een hoofdzaak?
Goed stuk, ben benieuwd naar het vervolg.
Uiteraard mee eens, in de “technische” trainingen business analyse die ik geef, daar zit altijd het onderdeel “POPIT” in. POPIT staat voor People, Organisation, Process, IT/technology, en staat voor het principe dat je nooit alleen een IT project, of nooit alleen een procesverbeteringtraject hebt. Het is altijd alles.
Misschien moeten er meer trainingen of bewustwording sessies gevens worden aan managers en bestuurders om dat “holistisch” gedachtegoed nog beter onder de aandacht te brengen.
Beste Danny, dank voor je reactie. Het is inderdaad binnen de ICT wereld een (over)bekend gegeven dat Proces en ICT hand in hand gaan. De vraag is dan wat eraan bijdraagt dat we in praktijk zo lastig met die samenhang om kunnen gaan. is dat de grilligheid en niet lineariteit van veranderprocessen. Of met het feit dat we die verandering zelf pas gaandeweg kunnen doorgronden? Zoals ik bedoelde bij punt 4? Of…?
In deze zin zit m.i. een essentie: “ICT-projecten bij overheden gaan vrijwel altijd over het uitvoeren van wet- en regelgeving. “.
Dat maakt de overheid inderdaad uniek. Want dat impliceert eenrichtingverkeer, en het verfoeide watervalmodel . Maar geen enkel IT traject kan slagen als de omgeving zich niet ook kan aanpassen aan de IT realiteit. Dat leidt onvermijdelijk tot de bekende “square peg in a round hole” metafoor
Daar wil ik nog een mythe aan toevoegen: het denken dat IT een “systeem” is, iets statisch, een uitkomst van een ontwikkelproces, in plaats van een service: iets wat tijdens de gehele levensduur , continue moet kunnen meebewegen en zich moet kunnen aanpassen aan de veranderende omgeving en inzichten.
De USM methodiek rekent radikaal af met het concept “systeem”, zet het concept “service” centraal en wijst ons er op dat de problemen worden ingebouwd in de starre , een-richting omzetting van de wereld naar data en toepassingen in USM “laag 2” .
En tot overmaat van ramp wordt die noodzakelijke flexibiliteit om bij te stellen, bij te sturen, door te ontwikkelen, voortschrijdende inzichten te verwerken, geblokkeerd door het gehanteerde een-richtingsparadigma en de gebruikelijke aanbestedingsmethodiek die gebaseerd is op specificaties in plaats van inspanning en proces
Fantastisch artikel. Ieder van de genoemde onderdelen zou een hoofdstuk in een boek kunnen zijn. Veel te vaak worden we in de pers onthaald op berichten van professionele nerds die er vanuit lijken te gaan dat mislukte IT projecten bij de overheid worden veroorzaakt doordat er bij de overheid hoofdzakelijk prutsers werken. Ik kan me best voorstellen dat er hier en daar best ruimte is voor verbetering, maar de hier genoemde oorzaken worden veel te vaak niet genoemd en niet begrepen.