Grote it-projecten bij de overheid hebben een slecht trackrecord. Wat gebeurt er in zo’n kolossaal project als het misgaat? Is dat een uniek incident of is er een rode draad in te herkennen?
Bij de Raad voor de Rechtspraak ging het om het project Kwaliteit En Innovatie rechterlijke macht (KEI). Na zes jaar ontwikkelen, tweehonderd miljoen euro kosten ging vier jaar geleden de stekker er uit. De nieuwe poging, Project Digitale Toegankelijkheid (DT) loopt ook al weer en tijdje.
Het programma Areaal Informatie Rijkswaterstaat / Bouwwerk Informatie Management (Airbim) is op advies van het BIT stopgezet. De operatie Basisregistratie Personen (oBRP) werd beëindigd nadat er vele jaren aan is gewerkt en meer dan honderd miljoen euro aan is besteed. Getouwtrek tussen de waterschappen resulteerde in uiteenlopende en zelfs conflicterende eisen voor het Waterschappen Tax-I-project. Het nieuwe systeem voor het innen van belasting komt na escalaties, ingebrekestellingen, pauzes, deadline-verschuivingen, testfases, externe bemiddelingen en doorstarts uiteindelijk niet van de grond. De schade werd voor de rechter geschikt. De Omgevingswet en PGB-2.0 hebben de kenmerken van gigantisch fiasco’s in wording.
Als je een aantal van deze incidenten op een rij zet, heeft het er alle schijn van dat er bij de overheid iets speciaals aan de hand is. Er spelen tal van factoren, de nalatenschap van de commissie-Elias er één is. Want die laat zien dat dit probleem verre van nieuw is.
Spraakmakende voorbeelden
Twintig jaar geleden was er een aantal spraakmakende voorbeelden van it-projecten bij de overheid die volledig misgingen. Hoger Beroep Strafrechtsysteem (28 miljoen euro), CWI’s CWIntake (35 miljoen euro), Elektronisch Patiënten Dossier (driehonderd miljoen euro). Het totale schadebedrag van falende it-projecten bij de overheid werd destijds door uiteenlopende partijen al geschat op zo’n vijf miljard euro per jaar.
In 2013-2014 voerde de commissie-Elias (VVD) een parlementair onderzoek uit naar falende it-projecten bij de overheid. Een belangrijke verdienste van de commissie was de oprichting van het tijdelijke Bureau ICT-toetsing (BIT) dat eind 2020 ophield te bestaan. Het Adviescollege ICT-toetsing is de opvolger, dat globaal uit dezelfde kleine groep mensen bestaat, maar nu in een meer permanente setting. Het BIT heeft in de voorbije jaren om verstandige redenen voor honderden miljoenen aan overheids-it-projecten tegengehouden en gaf daarbij ook adviezen. Een opsomming van BIT-adviezen van de afgelopen jaren:
- Stem projecten af op de aanwezige deskundigheid;
- Beslis zorgvuldiger over het vervangen van bestaande it-systemen;
- Wees terughoudend met de ontwikkeling van ‘generieke’ functionaliteit;
- Zet de gebruiker écht centraal;
- Verbeter het inzicht in it-kosten voor vernieuwing en instandhouding;
- Geef de cio een sterkere positie;
- Geef de it-competentie een hogere waardering;
- Zorg dat duidelijk is wat het project moet gaan opleveren;
- Houd het simpel waar dat kan;
- Zet technologie en ontwikkelmethodes weloverwogen in;
- Houd de planning realistisch;
- Maak tijdig bijsturen mogelijk;
- Plan voor de gehele levensduur.
Neutraal geformuleerd
Het zal u opvallen dat de adviezen eenvoudig zijn en geen it-jargon bevatten. Ze zijn neutraal geformuleerd zodat het moeilijk is om het er mee oneens te zijn. En dat terwijl de context waarin ze gegeven werden niet bepaald low-profile was. Het ging immers over it-projecten van miljoenen die stopgezet werden of in problemen verkeerden. Onderbemensing, de dreiging van een tijdelijk bestaan en een fragiel mandaat zullen er vermoedelijk voor gezorgd hebben dat het BIT de adviezen destijds zo neutraal heeft verwoord. Laten we, om het allemaal wat prikkelender te stellen, eens een eenvoudig gedachte-experiment doen met deze BIT-adviezen. Hieronder is een aantal geherformuleerd tot een vraag.
- Wie beslist onzorgvuldig over het vervangen van bestaande it-systemen?
- Wie zet de gebruiker niet ‘echt centraal’?
- Wie heeft onvoldoende inzicht in it-kosten voor vernieuwing en instandhouding?
- Wie geeft de cio geen sterkere positie?
- Wie accepteert onduidelijkheid over wat een project moet gaan opleveren?
- Wie vraagt niet om bijstuurmomenten?
Laten we onze aandacht nu richten op organisaties die met hun falende it-projecten en scheve systemen al jaren in het nieuws zijn. Welke functionaris zou typisch worden geraadpleegd bij het beantwoorden van bovenstaande vragen? Wie zou het overzicht moeten hebben, wie beslist er, wie geeft er goedkeuring? Bij wie komt u uit? Juist. We komen uit bij de (top)managers van deze organisaties. Zij hebben de verantwoordelijkheid om it-projecten beter te richten en ze beter te laten verlopen door er beter over te beslissen.
In ‘Perfecte Driehoeksverhoudingen’ (zie kader) heb ik een syndroom onderzocht dat een rol speelt in het falen van it-projecten. Daarin speelt het leiderschap een cruciale rol. Leiders staan immers opgesteld voor het (aan)brengen van: richting, begrip, vertrouwen, regie, inzicht, duidelijkheid, eerlijkheid en transparantie. Dit zijn geen willekeurig bij elkaar geharkte kreten, maar de acht fatale gebreken van slecht algemeen management die, indien vergezeld met twee andere verschijnselen tot het syndroom leiden dat it-projecten om zeep helpt.
De conclusie moet daarom de volgende zijn: we hebben beter algemeen leiderschap nodig bij deze overheden, diensten en uitvoeringsorganisaties.
Boek
‘Perfecte Driehoeksverhoudingen; De beste remedie tegen scheve informatietechnologie’ van drs. Nico Beenker verschijnt deze maand.
ISBN 9789081531030
Prijs: € 39,95
@Nico, de tamme CIO neemt wellicht niet altijd zijn verantwoordelijkheden en de interne leverancier kan te klein zijn om als uitvoerend opdrachtgever op te treden. Maar dit geldt net zo goed voor het bedrijfsleven. De opdrachtgever (overheidsinstelling, bedrijf) wil enerzijds meer automatiseren / moet regelmatig de systemen technisch vernieuwen, maar wil of moet tegelijkertijd ook innoveren. En accountmanagers beloven te vaak te veel bij grootschalige projecten die ze zelf niet kunnen overzien. Een tehuis runnen voor honderd kinderen is heel wat anders dan 100 kinderen laten verzorgen door 50 gezinnen met 2 kinderen. Maar de toezegging dat het kan (met disclaimer) is precies wat de opdrachtgever wil horen. Daarbij is er vaak sprake van een onvoldoende concrete opdracht, te weinig commitment, te weinig geld, te weinig tijd, enz. Een goede CIO ziet de valkuilen die door de betrokkenen zelf gegraven worden, omdat leiders falen. Maar als de CIO en CEO faalt, dan wordt het Yes we can not.
Ik kan niet oordelen over enig teken van begrip vanuit Elias in een gesprek of ergenissen daarin aangezien dat nogal subjectief is. Wat betreft een terugkerend cliché van de stuurlui aan de wal in het verwachtingsmanagement lijkt het me wel beter om mijlenver van de onderbuik gevoelens te blijven. Oja, de opmerking van Japie over schaalbaarheid in het Tayloriaanse denken betreft niet zo zeer de uitvoer maar de governance waarbij ik een gebrek aan kennis in sturing vermoed. En binnen de overheid staan de letters CIO voor Carriére Is Over omdat het een functie zonder betekenis is, een vanuit Amerika overgewaaide rol die eigenlijk niet goed past in de organisatiestructuur van de overheid.
Ton Elias, was dat niet degene die niet wist wat een IP adres is? 🙂
@Jaap: oneens met jouw mening over de CIO. Een CIO is een interne dienstverlener/ interne leverancier en kan alleen optreden als opdrachtgever voor de harde ICT-kant, zaken die te maken hebben met de infra.
Helaas zetten veel organisaties (daar heb je gelijk in), ook de overheid, deze rol ook in bij opdrachtgeverschap voor b.v. applicatieontwikkeling. In die gevallen is er vrijwel zeker sprake van ineffectief opdrachtgeverschap, vaak zelfs nog gevaarlijker dan wanneer je de klus commercieel volledig uitbesteedt.
Op min site schreef ik daarover over diverse voorbeelden, zoals SPEER (MinDef) en Aldi.
Daarom zit daar ook de probleem van het BIT; onder de CIO.
@Nico, de Chief Information Officer is dus voor jou een Chief Infrastructure Officer (al la Capgemini)? Dit is in mijn ogen meer een CTO. Anderen zien de CIO meer als Chief Innovation Officer. Wat je allemaal met drie dezelfde letter kan (vooral in de ICT). Elke CxO moet aangeven waar niet alleen de letters voor staan, maar vooral ook wat de functie inhoudt. Anders worden mensen opgezadeld met de verantwoordelijkheid van een ander of erger er kan een verantwoordelijkheid nergens belegd zijn. Die ligt ergens achter een schutting, zoals de programma- en projectmanagers snel zullen merken.
Normaal is de CIO verantwoordelijk voor de inkoop van ICT (en niet meer de CFO) en soms ook voor zaken als GDPR. Het zou niet moeten uitmaken of er extern of intern wordt ingekocht en of dat intern deels weer wordt uitbesteed. De CIO moet geen conflicterende petten accepteren en bijvoorbeeld verantwoordelijkheid nemen om systemen te ontwikkelen. Dan moet de CIO eigen vlees gaan keuren. De interne ontwikkelorganisatie is uiteindelijk een profit center die moet kunnen concurreren. De CIO is er voor het bedrijfsbelang en kan opdrachtgever zijn voor b.v. applicatieontwikkeling. Bij grote gedifferentieerde organisaties, is het beter dat de baas van de gebruikersorganisatie opdrachtgever van applicatieontwikkeling wordt. Maar mij lijkt het vooral belangrijk dat de taken, verantwoordelijkheden, bevoegdheden (dus ook mandateren) logisch belegd zijn en behapbaar.
Voordat ik überhaupt iets gedaan krijg bij een overheids organisatie, bijvoorbeeld een simpele POC, ben ik al een jaar verder voordat ik alle 26 afdelingen en 200 chefs heb gesproken die allemaal uiteraard iets te zeggen moeten hebben, vooral voor eigen functie-behoud. En dan mogen we aan de hand van 2 miljoen requierments, die vaak haaks op elkaar staan, een oplossing bedenken voor het e.e.a. En of dat nu over software of hardware gaat, maakt niet uit. En dan maar klagen dat het aan de IT ligt.
Niels, dat is het nadeel, wanneer iedere overheid en/of instantie zelf het wiel wil uitvinden.
Gebruik maken van ervaring van anderen is blijkbaar moeilijk.
@Niels, ik was vrijwel altijd in de gelukkige omstandigheid dat ik ze dan veel succes kon wensen en eruit kon stappen. Het heeft geen enkele zin om te gaan pappen en nathouden behalve misshien dat je je hypotheek ermee kunt betalen. Je pleegt door te blijven een enorme aanslag op je kennisniveau op langere termijn want dat soort gekkengestichten vormt dan op een gegeven moment nog je enige referentiekader.
Pragmatische sales jongens zoals Niels willen graag een PoC maar vaak is dat één van de vele puntoplossingen die voor een silo zorgt waardoor ik de anderen alweer hoor klagen dat er niet onder architectuur gewerkt wordt. En met onder architectuur werken bedoel ik grip krijgen op zoiets als de informatievoorziening want specificaties hebben veelal tot doel om tot een open standaard te komen. De gegevensuitwisselingen tussen systemen mogen bijvoorbeeld niet op hindernissen stuiten zoals leveranciersafhankelijke intellectuele eigendommen. Kortom, verkopen van licenties middels een PoC is dan ook geen oplossing voor de problematiek als we kijken naar de miljarden die de overheid jaarlijks moet betalen voor het gebruik van software.
Het probleem is en blijft de Tayloriaanse, gefragmenteerde, silo-organisatie van de overheid die het laatste decennium alleen maar erger is geworden. Met daar direct aan gekoppeld zeer gebrekkig opdrachtgeverschap.
Daar komen projecten van allerlei aard doorlopend ernstig door in de problemen. Vooral wanneer de focus ligt op het middel (b.v. ICT) en niet op het doel. De focus op middel i.p.v. doel is trouwens ook een vrijwel onvermijdelijk gevolg van de silo-organisatie; elke silo wil wat het beste is voor hun deel. Een hoger doel wordt daarbij uit het oog verloren.