rssColumns

ICT bij het Rijk: lessons learned

De Algemene Rekenkamer doet onderzoek naar de aanpak van ICT-projecten binnen de bedrijfsvoering van het Rijk. We kijken of het Rijk een effectieve aanpak kiest en daarbij lering heeft getrokken uit eerdere onderzoeken van de Algemene Rekenkamer naar ICT-projecten, informatiehuishouding en grip op informatievoorziening (IT-governance). Verwachte publicatiedatum is 2013.

Dit onderzoek van de rekenkamer maakt duidelijk dat de overheid in haar maag zit met de te hoge kosten en het mislukken van ICT projecten. Op internet kom je vele voorbeelden tegen over mislukte overheidsprojecten, waarbij ingewikkelde of minder ingewikkelde applicaties volledig aan de grond lopen, te weten:

• Elektronisch Patienten Dossier (EPD): Invoering wordt al jaren vooruitgeschoven.
• SPEER: samenvoegen logistiek van de krijgsmachtonderdelen. Verschillende malen uitgesteld. Kosten 240 miljoen tot een miljard.
• Aansluiting UWV en Belastingdienst deels mislukt. Duizenden gegevens verdwenen. Kosten: 200 miljoen.
• Elektronisch kinddossier. Aanbesteding dit jaar mislukt, moet overnieuw. Nog begroot: 14 miljoen.
• P-direct. Samenvoeging personeelsadministraties van acht ministeries. Aanbesteding mislukt, afkoopsom 20 miljoen. Nog voor 700 miljoen begroot.
• Hoger Beroepssysteem: stopgezet 2001, kosten 13 miljoen euro.
• Politie Suite Opsporing (PSO): Landelijk systeem voor registratie van misdrijven te gebruiken voor de opsporing. Definitief afgeblazen in 2005. Kosten 430 miljoen.
• C2000 politie e.a. hulpdiensten: Jaren vertraging door gebrekkige samenwerking hulpdiensten en korpsen. Implementatie kost nog 72 miljoen.

 (bron Intermediair)

Ik kan niet wachten op de publicatie van de 'lessons learned' van grote ICT-projecten bij de overheid. Moeten we eigenlijk nog wachten op dat rapport of kunnen we de uitkomst wel zo’n beetje voorspellen?

Waarom mislukken die projecten? Maar al te vaak wordt het beeld neergezet dat de overheid de schuld is van het mislukken. Werken die ambtenaren niet slim of niet hard of verandert de scope drie keer per dag waardoor de planning niet gehaald wordt en de businesscase niet gerealiseerd wordt? Ik heb gemerkt dat dat wel meevalt.  Overheidsmedewerkers zijn zich vaak enorm bewust van de noodzaak om zorgvuldig te werken en procedures te volgen. Binnen de profit sector zijn we eraan gewend geraakt om nogal eens een bocht af te snijden als het resultaat daarbij gebaat is; het doel heiligt de middelen. Dit kun je niet vragen van het Rijk. Binnen het Rijk leven mensen nu eenmaal in de werkelijkheid dat ze ten allen tijde ter verantwoording kunnen worden geroepen en er geen verzachtende omstandigheden zijn voor het negeren van de regels.

Waar gaat het dan wel mis? In veel gevallen worden ICT projecten ingezet om bestuurlijke samenwerking vorm te geven. De totstandkoming van een dergelijk project kent vele stappen waarbij het bij elke stap een uitdaging is om zonder brokken naar de volgende stap te gaan.

De eerste stap die we moeten zetten is het schrijven van een Programma van Eisen. Veel leveranciers roepen om het hardst dat de overheid haar eisen slecht opschrijft. Dat is in een aantal gevallen waar, maar daar waar de leverancier schermt met zijn professionalisme moet deze zich ook afvragen wat er dan wel gevraagd wordt, wat is eigenlijk de functionele behoefte achter een eis. Ga niet zelf zitten interpreteren om er vervolgens pas in de GAT achter te komen dat je niet hebt gebouwd wat de klant vraagt met alle gevolgen van dien. Als overheid moet je je natuurlijk bewust zijn van de gevolgen als je bij de vervanging van een systeem je eigen eisen niet Smart kunt maken of daarbij geen ondersteuning zoekt. Dat gebeurt maar al te vaak. Dus schroom niet om iemand van buiten objectief te laten kijken naar je Programma van Eisen.

Als de eisen naar inzicht van de overheid helder zijn volgt stap 2, de aanbesteding, sommige projecten worden daarbij fixed price aanbesteed. Naar mijn mening is het nog nooit gelukt om een complex systeem fixed price te bouwen. Waarom ga je dan toch op basis van fixed price aanbesteden? Als je een klein pakket koopt waarin simpel is te voorspellen wat je krijgt, hoe het eruitziet en wat je ervoor moet doen om het in gebruik te nemen zie ik geen probleem in het doen van een fixed price aanbesteding. Moet je, zoals in zoveel gevallen bij de Overheid, je interne processen aanpassen, hoe is het dan in je opgekomen om fixed price aan te besteden?

Als leverancier kun je natuurlijk ook op je klompen aanvoelen dat je een fixed price systeem alleen kunt aanbieden als je absoluut honderd procent zeker weet dat je kunt en gaat leveren wat de klant vraagt, ik heb respect voor de leveranciers die daaraan niet meewerken.

Voor veel leveranciers speelt echter het binnenhalen van de klus een belangrijkere rol dan de vraag of je echt kunt wat de klant vraagt, hierdoor neem je bewust het risico om met je klant in conflict te komen, dat polder je niet altijd weg met als resultaat een mislukt project. 

Stap 3 is ontwikkelen en implementeren. Mijn vraag is waarom bij grote projecten systeemontwikkeling en implementatie in het zelfde project en contract worden gebracht? Koppel ontwikkeling en implementatie los  van elkaar en daarmee kun je onderscheid maken in de contractvorm voor beiden. Een implementatie volgt op een succesvol uitgevoerde acceptatietest (je weet al wat je krijgt) en is beter fixed price te doen.

We hebben nu een  systeem gebouwd dat een vervanger is voor bestaande functionaliteit, dus hebben we een Programma van Eisen en allerlei onderbouwingen opgesteld en als we dan eindelijk zijn aangekomen bij stap 4, de migratie van de oude gegevens, dan blijkt vaak dat de leverancier van het oude systeem niet van plan is om mee te werken. Deze  is nog wat chagrijnig over het missen van de aanbesteding en probeert te rekken wat er te rekken valt, want verlengen betekent kassa!

Leg dus ook contractueel vast wat de leverancier van het oude systeem moet doen als je een systeem eenmaal opdoekt. En ja dames en heren leveranciers, ook uw product heeft niet het eeuwige leven, dus bedenk dat je een keer kan worden afgedankt. Bedenk ook dat je een rol kunt spelen in de implementatie van het nieuwe systeem, misschien niet aan de kant van de ontwikkelkant, maar wel aan de implementatiekant. Gooi dus niet je glazen in door alleen maar chagrijnig te kijken naar de concurrent die aan de haal gaat met “jouw klus”.

Mijn conclusie is dat er geen verschil is tussen een overheidsproject of een project binnen de commerciële dienstverlening op één ding na. Aan de hand van bovenstaande projecten kun je concluderen  dat een aantal van deze projecten eigenlijk geen ICT projecten zijn maar  bestuurlijke integratietrajecten waarbij ICT een rol speelt , maar die alleen als ICT project zijn geclassificeerd. Dit vertroebelt het beeld dat ontstaat over het mislukken van het project. Tevens is dit het grootste risico voor je project.

Het is zaak om een aantal items scherp op het netvlies te houden anders raken deze makkelijk buiten beeld. Wat zijn dan de punten waarop zowel overheid als leveranciers zichzelf kunnen verbeteren, ik trap alvast wat open deuren in

• Wat ga je eigenlijk ondersteunen of afdwingen
• Maak je deliverables samen smart
• Werk samen, praat er niet alleen over
• Als leverancier is het niet handig je te verschuilen achter het programma van eisen van de klant als er iets misgaat. Wees je bewust dat je erin zit voor de lange termijn. Misschien is het slimmer in de ontwikkelfase wat makkelijker met zaken om te gaan
• Probeer de functionaliteit op te knippen in stukken en functionaliteit af te testen in delen.
• Je bouwt iets voor mensen om mee te gaan werken, zijn die nog in beeld?
• Hou de de communicatielijnen kort en pas je boodschap aan aan de ontvanger

Willem Jan Baas, w.j.baas@ventus.nl – Service Manager - http://nl.linkedin.com/pub/willem-jan-baas/1/a67/863