ICT projecten bestaan niet, deel 3: Richtingen voor verbetering
Met grote regelmaat horen we over mislukkende ‘ICT-projecten’ bij de overheid. In deel 1 van dit drieluik ging ik in op de misvatting dat de oorzaak hiervan in ‘de techniek’ is gelegen. In deel 2 benoemde ik enkele onderliggende foutieve beelden en veronderstellingen over informatievoorziening in ‘de buitenwereld’, die bijdragen onverstandige keuzen in de aanpak. Maar wie oorzaken duidt moet ook proberen om oplossingen aan te dragen. Wat zou bijdragen aan verbetering? Daarom een aantal richtingen die ik hiervoor zie in dit deel 3.
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?
Maar eerst…wat helpt niet?
Ik kan het niet laten om toch eerst nog even in te gaan op veel-geopperde suggesties die niet helpen! Bijvoorbeeld dat we ‘slimmere ICT-ers’ nodig hebben: de beter betaalde ‘superslimme nerds’, zoals Ton Elias dit voorjaar verklaarde in dit magazine. Of dat ‘de markt’ het beter kan. Dat is onzin. Zolang de context hetzelfde blijft zoals beschreven in dit drieluik kan geen slimme programmeur of marktpartij het verschil maken. Alsof je door een betere aannemer een betere ruimtelijke ordening krijgt.
Ook de roep om ‘fixed price’ contracten en ‘resultaatverplichtingen’ draagt niet bij. Perverse prikkels om uren te verbranden moeten we terugdringen, maar ‘fixed price’ werkt alleen als scope, doel en resultaat in voldoende detail vaststaan. Dat is bij dit soort trajecten inherent niet het geval. Net zoals buiten de ICT trouwens bij complexe veranderingen. Zou iemand ooit de herontwikkeling van een heel stadsdeel fixed-price aanbesteden? Met een resultaatverplichting dat de leefbaarheid meetbaar beter wordt?
Betere en strengere toetsing op kwaliteit en projectaanpak? Meer AcICT? Dat helpt tot op zekere hoogte. AcICT doet tal van relevante constateringen, maar ongewild draagt de instelling van dit instituut juist bij aan een onjuiste en contraproductieve framing. Namelijk dat de problemen bij ICT-projecten technisch van aard zijn en dat er ‘experts’ nodig zijn om dat op te lossen. Ongewild wordt juist verantwoordelijkheid weggenomen bij de opdrachtgever en bij de lijn. BIT zei bij de Omgevingswet niet ‘Minister, u wilt te veel tegelijk, uw stap is te groot’ maar ‘Het systeem is ingewikkelder dan nodig’. Sóms is het voor stakeholders best comfortabel om tegenvallers in verandertrajecten te kunnen wijten aan technische beperkingen. ‘Tsja, dat ligt bij de ICT hè, daar hebben we geen grip op!’.
Richtingen voor oplossingen
Voor complexe problemen is vaak geen ‘panklare oplossing’. Laat ik niet de pretentie hebben om die hier even te bieden. Maar ik zie wel richtingen, een mix van competenties en veranderingen in aanpak die kunnen bijdragen aan verbetering.
1. Beter bewust bekwaam
Werken aan bewustzijn en kennis bij beleidsmakers en opdrachtgevers
Niet zozeer van ‘de ICT’ als technisch vehikel, maar bewustzijn en kennis van de essentie van informatie en informatiemanagement; van de wetmatigheden in informatieketens, van de interactie tussen proces, organisatie en informatie. Bewustzijn van de mechanismen die ik noemde in deel 1 en 2. De bereidheid om het wél te willen snappen en er verantwoordelijkheid voor te nemen, in plaats van te verwijzen naar ‘de experts’. De overheid is in de uitvoering grotendeels een informatie-verwerkende ‘machine’. Het is daarom vreemd dat in overheidsmanagement wel bestuurskundigen, juristen en economen zitten, maar nauwelijks informatiekundigen.
2. ICT is here to stay en hoort bij je werk
Meer aandacht voor informatievoorziening in opleidingen public management
Wie iets wil managen zal enige notie moeten hebben van de inhoud daarvan. Wie opleidingscurricula van bestuurskunde, rechten en public management bekijkt, zal zien dat onderwerpen als informatie en ICT daarin nauwelijks aandacht krijgen. Er überhaupt weinig aandacht voor ‘uitvoering’. In bedrijfskundige opleidingen vinden we vakken als operations management, supply chain management, logistics management en business information management, maar de evenknieën hiervan in de publieke sector zijn schaars. Alsof de overheid geen operatie heeft? Het effectueren van beleid vraagt om (aanpassingen in) miljoenen transacties en interventies, waarbij honderden regels gelden, uitgevoerd door duizenden ambtenaren ‘in symbiose’ met ‘hun’ aan elkaar gekoppelde ICT-systemen. Operations en ICT verdienen een grotere plek in onze opleidingen in de publieke sector.
3. Niets zo fijn als haalbare plannen
Realiteitszin bij het stellen van ambities
We moeten begrijpen dat stelselveranderingen een lange doorlooptijd hebben en dat ICT niet even omgetoverd kan worden. In de fysieke wereld snappen we dat. We snappen dat de verbouwing van Utrecht CS 10 jaar moest duren, omdat we het zien. We moeten accepteren dat zulke beperkingen ook bestaan in de transformatie van organisaties en hun informatievoorziening, in plaats van deze te duiden als onkunde of zelfs onwil. Iedere minister die trots zegt ‘dit traject is de grootste stelselherziening sinds de grondwet’ mag verplicht een maand in retraite om zijn/haar overmoed te overdenken. Kunnen we met minder ingrijpende, kleinere interventies wellicht hetzelfde bereiken? Stapsgewijs? Dat moet de norm zijn. En áls dat niet kan, besef dan dat de verbouwing lang duurt en tegenvallers zál kennen.
4. Beeld geven aan de onzichtbare wereld
Leren de essentie van informatievoorziening begrijpelijk te vertellen
Ja, ook de ICT beroepsgroep verdient extra opleiding. Zoals bij Bouwkunde vanaf dag één presentatietekeningen en maquettes gemaakt worden, zo zouden ICT-ers getraind moeten worden in het begrijpelijk maken van de onzichtbare wereld. Taal vinden om deze te kunnen verbeelden voor de manager. De sleutelrol daarvoor ligt bij de architectuur. Echter, ook de taal, modellering en benadering van de architectuur staat vaak ver af van het lijnmanagement. Te technisch, te gedetailleerd, te complex, te modelmatig. Als karikatuur: toon een ArchiMate plaat aan de gemiddelde manager en die krijgt terstond vlekken in de nek; of beschouwt het als een artefact nuttig voor ‘de ICT’. Er zijn diverse stromingen en initiatieven die er wel in slagen om de brug te slaan, maar verbreding daarvan is nodig.
5. Eigenlijk zijn ICT-ers net juristen… maar dan anders
Onderzoeken van de spanning tussen de juridische en de digitale praktijk
In de relatie tussen de juridische en de ICT-discipline zie ik regelmatig spraakverwarring en frictie. Gemopper over ‘juristen die onmogelijke dingen willen’ en ‘ICT-ers die gewoon eens moeten bouwen wat in de wet staat’. (Met nadruk: ik wil hiermee niet met de vinger wijzen naar wie dan ook, het gaat me enkel om het illustreren van de beleving). Beide onzichtbare werelden hebben een eigen taal, met eigen regels en conventies; met een bevolking die hecht aan ‘regelvastheid’ en structuur. Maar juridische vormvereisten en procedurevereisten kunnen leiden tot complexiteit in digitale oplossingen. De tekstuele benadering van juristen, mét alle interpretatievraagstukken en aandacht voor uitzonderingen botst met de noodzaak tot modellering in een ICT-systeem. Tenslotte speelt dat de relatie tussen regelgeving en ICT voornamelijk eenzijdig gericht is: ‘Dit zijn de regels zoals ze zijn, we kunnen die niet bijstellen maar moeten het ermee doen’.
Het zou veel waard zijn dit vraagstuk verder in beeld te brengen met praktijkmensen en wetenschappers vanuit beide disciplines. Hoe kunnen we elkaar beter vinden? De ministeries van BZK en JenV zouden hierin een rol kunnen nemen.
Voorbeeld
Juridische grondbeginselen stellen dat de bekendmaking van een besluit met rechtsgevolgen voor éénieder kenbaar moet zijn. Dit betekent onder meer: een besluit moet gepresenteerd worden op een mensleesbare wijze (nu én in de toekomst), de authenticiteit moet aantoonbaar zijn en besluiten moeten in een absoluut onveranderlijke vorm worden opgeslagen. De standaard die hiervoor is toegestaan is PDF-A, waarbij de onveranderlijkheid is geborgd door het gebruik van zogenaamde hashes. Maar technieken die we in de ICT (en in ons gewone leven!) heel gewoon vinden, bijvoorbeeld het werken met hyperlinks en het verwijzen naar kaartlagen in GIS-systemen, voldoen niet aan de bovengenoemde eisen; althans niet zonder aanvullende maatregelen. Dit betekende dat – in het kader van de Omgevingswet – een aanzienlijk discussie en technische inspanning benodigd was om te komen tot een wijze waarop het gebruik van GML nu is toegestaan als authentieke bron in bekendmakingen.
6. Agile, maar dan écht
Sturen op stapsgewijze ontwikkeling én implementatie
We hebben onze mond vol van Agile werken (en passen dit inderdaad in toenemende mate toe), maar in de grote ICT-projecten overheerst toch nog de Big-Bang implementatie. De huidige sturing en governance ‘dwingen’ zelfs in deze richting.
Als we werkelijk in stappen willen ontwikkelen en (vooral) implementeren, dan zullen we dit moeten inbedden in onze totale aanpak: in governance, in financiële kaders, in contractering én in juridische randvoorwaarden. Dus ook in wet- en regelgeving als die de basis vormt voor nieuwe ontwikkelingen. Die moet incrementele ontwikkeling en (vooral) stapsgewijze ingebruikname faciliteren. Dat betekent ook dat we bij het opstellen van de projectaanpak de kosten moeten nemen van een gefaseerde implementatie, in plaats van die later als ‘overschrijding’ om de oren te krijgen.
7. Weten wat we gezamenlijk willen!
Versterken sturing en regie in behoeftestelling
In ICT-rapporten wordt veel gesproken over sturing en regie op de ICT, op de techniek. Maar in mijn ogen ligt er meer noodzaak bij sturing en regie op de behoeftestelling. Op ‘de business’ dus. Geen geringe uitdaging, schreef ik al in deel 1. Essentieel daarbij is de competentie om dilemma’s en (ketenbreed) te maken keuzen als managementvraag neer te leggen op het juiste niveau, in begrijpelijke termen! Dit vraagt vaardigheden om de nieuwe ‘situatie’ te ontwerpen en doorgronden, om de effecten op ketenniveau te doorzien en om business en ICT tot het goede gesprek hierover te brengen. Dát is de cruciale competentie waar een versterking nodig is. Dit vraagt geen ‘supernerds’ maar communicatieve analisten en verbinders. En natuurlijk tijd van de besluitvormers om de voorgelegde keuze echt te begrijpen.
8. Wat als het een stad was?
Kunnen we leren van transities in stedenbouw?
Ik heb in dit drieluik een aantal maal paralellen getrokken met complexe ontwikkelingen als stedenbouw en infrastructurele projecten. Een vraag die door mijn hoofd speelt is in hoeverre ‘ICT-projecten’ kunnen leren van de daar gehanteerde principes? Dat betekent ander stakeholder management. En ook dat de transitie ingebouwd moet zijn in het ontwerp. Architecturen gaan nog altijd te veel over het gewenste ‘nieuwe landschap’, en vaak wordt de transitie daarheen pas te laat in beschouwing genomen. Mooi die stip op de horizon, waar zitten de barrières in de weg daarheen? Hoe gaan we daar mee om?
9. Niets zo fijn als realistische beloften
Verhogen realiteitszin in het ICT-domein.
In de spiegel kijken dus! Stoppen met het wekken van irreële verwachtingen en het doen van te grote beloften. Iedere ICT er die zegt ‘Straks kunt u met één druk de knop of één klik op de kaart dit of dat zien’ mag in dezelfde retraite als de minister hiervoor genoemd. De werkelijkheid is te complex daarvoor. Laten we vooral reëel worden.
Tot slot
Wat begin dit jaar begon als een wat getergd commentaar van mij in iBestuur is uitgegroeid tot dit drieluik. ICT-projecten bestaan natuurlijk best, maar de projecten waarmee we in het publieke domein de grootste moeite hebben betreffen eigenlijk altijd verandertrajecten, mét een ICT-component daarin. Alleen als we ze op die manier benaderen kunnen we verbetering bereiken. Bewustzijn en kennis van de verwevenheid van ICT en proces zijn daarbij een eerste vereiste. En dan is er een wereld te winnen.
Wat een prachtig drieluik! En wat een rake waarnemingen en zinvolle oplossingsrichtingen!
Een mooi antwoord ook op de lopende actie herprogrammeerdeoverheid.nl
Dat juridische vormvereisten en procedurevereisten kunnen leiden tot complexiteit in digitale oplossingen hoeft niet zo te zijn. Je kunt die zaken prima scheiden.
Het ontwikkelen van bedrijfsmodellen is een belangrijk onderwerp in de bedrijfskunde, maar het ook een kunst. Je kunt ook anders kijken naar de benodigde bedrijfsrollen en -modellen. Door juridische eisen te expliciteren, met de in Nederland ontwikkelde en door de Rijksoverheid breed gesteunde Calculemus/FLINT methodiek kun je die vorm- en procedure eisen bewezen platslaan tot het niveau dat je aan computers (en zelfs aan bestuurders) uit kunt leggen.
Impliciet wordt in dit blog uitgegaan van ICT projecten als ‘harde infrastructuur’. Dan kun je stellen dat digibeten (noem ze voor het gemak Juristen), randvoorwaarden stellen aan IT-ers die nu eenmaal moeten werken met een heel pallet aan oude en nieuwe systemen, die – elk hun eigen manier – slechts 1 of 0, aan of uit, spreken. And never the two will meet.
Door echter te gaan denken in Data Governance structuren en een gegevensecosysteem canvas, kun je een hele rage aan bedrijfsmodellen kwijt in een bepaald gegevensecosysteem. Elk gegevenecosysteem bestaat tenslotte uit dezelfde grootheden:
• Doel en kernbehoeften
• Belangrijke belanghebbenden en hun rollen
• Ecosysteembereik, regels en bedrijfsmodellen
• Gegevens- en waardestromen
• Problemen en vragen
• Diensten en infrastructuur
• Bestuur
Dat Bestuur is gemandateerd om iets te mogen of te moeten. Rechten of plichten.
Calculemus/FLINT pluist die eisen uiteen en in IT-taal kun je dat vervolgens vertalen naar Policy Encorcement Points en Policy Decision Points in de Zachte Infrastructuur, waaronder ook identiteit (wie ben je dan?) en authorisatie (wat mag je dan?) terug vindt.
Het is niet voor niets dat de Universiteit van Maastricht haar Rechten Faculteit zeer nauw laat samenwerken met haar Data Science Faculteit. Het is niet voor niets dat de Europese Unie strategisch inzet op het concept http://www.internationaldataspaces.org en het is niet voor niets dat het Leipniz Instituut als sinds de vorige eeuwwisseling (die van 1900!) slimme data dingen doet met wetten en regels. Zoals Leipniz zelf al zei (in het Latijn dan): “Cum proscriptae sint controversiae, calculemus.” Vrij vertaald: “Wanneer geschillen verboden zijn, laten we dan berekenen.”
Leipniz’ was overtuigd van de kracht van wiskundige logica en redenering om geschillen op te lossen en tot waarheid te komen. De Calculemus methode leidt tot FLINT: computer instructies in normale mensentaal, ook wel bekend als JSON – api’s. Data Spaces werken met de jongste generatie van JSON, NGSI-LD en in de combinatie van die twee kun je wel degelijk juridische randvoorwaarden zo vertalen dat computers en legacy systemen er ook wat mee kunnen.
Dank voor je reactie Vincent. Ik bedoelde niet te zeggen dat juridische vormvereisten en procedurevereisten *onvermijdelijk* zullen leiden tot complexiteit, maar wel dat dit vaak voorkomt. Ik ga me graag verder verdiepen in de methode die je benoemt. En de uitdaging blijft vervolgens om alle afzonderlijke groepen en perspectieven ‘mee te krijgen’ in het model, en hen elkaar te laten verstaan in de discussie erover.
Aan wat Wimfred schrijft zou ik wel een bijdrage willen leveren. Ben er ook mee bezig, richting een mogelijke oplossing. Ook onderzoek naar Leibniz, naar mijn ervaring is dat niet op de juiste wijze ingezet en werkt daardoor niet zomaar productief.
Mede belangrijk: 7 en 8
7. WETEN WAT WE GEZAMENLIJK WILLEN! Versterken sturing en regie in behoeftestelling
8. WAT ALS HET EEN STAD WAS? … Dat betekent ander stakeholder management. En ook dat de transitie ingebouwd moet zijn in het ontwerp
Mijn stijl is meer het ontwikkelen, beproeven en beschrijven van een nieuwe aanpak dan opschrijven/detailleren wat en waar er verbeterd moet worden.
Wat ik gedaan heb is de werkwijze exploreren, toepassen, uitschrijven in de notatie zelf en publiceren in een boek. Ook zijn er enige voorbeelden van (grote) toepassingen.
Dank Wimfred en bij gelegenheid kunnen we er verder op in gaan. Groet, Bram