Naar aanleiding van advies van het Bureau ICT Toetsing (BIT) heeft het ministerie van Binnenlandse Zaken en Koninkrijksrelaties besloten om Operatie BRP met negen maanden uit te stellen. Gevolg: een extra kostenpost van 8,6 miljoen euro. Redenen voor de vertraging liggen in wijzigen in wetgeving en het feit dat software die in ontwikkeling is, moeilijker aan te passen is dan software die klaar is.
Het BIT stelt in zijn rapport dat ict-programma’s vrijwel nooit lopen zoals aan het begin is bedacht. De vraag is daarom niet óf zich van alles voordoet, maar hoe daarmee wordt omgegaan. Mede op advies van het BIT heeft het programma in samenwerking met de beheerorganisatie een integrale planning opgesteld waarin het nog resterende ontwikkeltraject in detail is uitgewerkt, waarin de nieuwe ontwikkelingen zijn meegenomen en waarin naast het ontwikkeltraject ook de acceptatie, inproductiename en implementatie meer in detail zijn uitgewerkt. Op advies van het BIT heeft het programma ook de resterende onzekerheden in kaart gebracht, en het moment dat die onzekerheden zijn opgelost.
Meerwerk
Het ontwikkeltraject in de nieuwe integrale planning neemt negen maanden meer tijd in beslag. De ontwikkeling van de nieuwe voorzieningen zal in het derde kwartaal van 2017 gereed zijn. Dit komt doordat eerdere wijzigingen en tegenvallers de lucht al uit de planning hadden doen verdwijnen, het programma, in opvolging van aanbevelingen in het kader van reviews, moet voldoen aan nieuwe of gewijzigde (zwaardere) eisen en er is meerwerk ten opzichte van de oorspronkelijke opdracht,.
Wijzigingen in de in ontwikkeling zijnde BRP hebben grote consequenties. Dat komt doordat het programma niet alleen de BRP ontwikkelt, maar daarnaast ook twee andere systemen bouwt. Het eerste is bedoeld om de gegevens uit de GBA te converteren naar de BRP-database. Het tweede systeem is specifiek bedoeld om een geleidelijke transitie van gemeenten en afnemers mogelijk te maken. Dit ‘migratiesysteem’ vertaalt berichten van gemeenten die nog volgens de huidige systematiek werken naar de nieuwe BRP-variant en vertaalt berichten van de nieuwe BRP terug ten behoeve van afnemers die nog volgens de oude systematiek werken. Als gevolg van de verschillen tussen de GBA en de BRP gaat het hier om complexe systemen. Het een en ander betekent dat het programma wijzigingen in functionaliteit niet alleen in de in ontwikkeling zijnde BRP moet verwerken, maar ook in de twee andere systemen.
Opnieuw doorlopen
Een andere reden dat wijzigingen grote consequenties hebben is dat de BRP, en hetzelfde geldt voor de beide andere systemen, nog niet in productie is, maar nog in ontwikkeling is. Onderdelen die moeten worden toegevoegd of gewijzigd moeten veelal het gehele ontwikkelproces, van analyse en ontwerp tot en met testen opnieuw doorlopen.
Bij het uitwerken van de integrale planning is de keuze gemaakt om extra zekerheden in te bouwen rond de beheerste inproductiename van de BRP, mede naar aanleiding van de aanbevelingen van het BIT. Dat kost enkele maanden extra tijd en leidt er in combinatie met de langere ontwikkeltijd toe dat de BRP in mei 2018 gereed zal zijn voor aansluiting van de koploper-afnemers, twee maanden later gevolgd door koploper-gemeenten. De eerder afgesproken implementatietermijn zal voor afnemers en gemeenten gehandhaafd blijven op maximaal twee jaar. Wel wordt er meer tijd genomen voor de periode om koplopers aan te sluiten, om zo voldoende waarborgen te hebben dat aan eventuele kinderziektes goed het hoofd kan worden geboden, voor het moment dat de massale aansluiting van afnemers en gemeenten start.
Hogere kosten
De extra kosten van 8,6 miljoen euro worden primair veroorzaakt doordat medewerkers langer aan het werk zijn en doordat de ontwikkelingsinfrastructuur langer benodigd is. Naast de kosten van de langer lopende inzet van het ontwikkelteam liggen ook de kosten van acceptatie, implementatie en communicatie daardoor hoger dan in de vigerende begroting. Tenslotte zijn nu ook posten opgenomen voor nog door te voeren wijzigingen.
Hier is het eerste falen van BIT een feit. Het is niet een kwestie van hoe hiermee om te gaan maar nu eens gewoon basaal IT project management toe te gaan passen.
Beste Bit,
Klaarblijkelijk heeft u sinds de opheffing van het RCC in Goud, van de problemen die u mede veroorzaakt op het vlak van IT, domweg niets maar dan ook niets geleerd. Dat toont meteen uw valkuil dat u van IT en noodzakelijke procesvoering maar bar weinig begrijpt, laat staan dat uw IT dienstverlener dit ordentelijk over weet te brengen.
Kort en goed.
Een IT proces dien vooraf aan voorwaarden te voldoen om in gang te kunnen worden gezet. Voldoet zij niet, dan is falen het gevolg. Als u er niet voor zorgt dat alleen al dit gegeven mandetoir word, dan heeft u geen toevoegende waarde.
Het stelselmatig wijzigen van input in klaarblijkelijk onvolkomen IT processen, is gewoon ‘heading for disaster.’ Als u dat niet begrijpt? Dan heeft u op die plaats weinig te zoeken.
Kinderziektes
Er bestaan in IT processen niet zoiets als kinderziektes. Daar heb je namelijk een gedegen testprogramma voor waarna normaliter een ‘Pilot’ volgt. Die pilot is dan de lakmoesproef en als u nu over kinderziektes spreekt, is dat reden drie dat u als BIT geen toevoegende waarde heeft.
Minister Plasterk
U bent het prototype van de veroorzaker van miljoenen/miljardensachde door politieke impotentie en incompetentie wat IT betreft. Ook bij u gaat de wetmatigheid op, if you don’t know ‘Jack Shit’, stay out of the kitchen. In Nederlands, als je ergens geen verstand van hebt maar je wil wel de scepter zwaaien, krijg je daar hele grote voorspelbare schade van.
En u denkt dat ik hiervoor de overheid zou moeten betalen?
Een wel zeer bijzonder advies van het BIT. “… dat ict-programma’s vrijwel nooit lopen zoals aan het begin is bedacht.”. Een open deur. “De vraag is daarom niet óf zich van alles voordoet, maar hoe daarmee wordt omgegaan.” En wat adviseert het BIT om er mee om te gaan? “Integrale planning”, “in detail uitgewerkt”, “resterende onzekerheden in kaart gebracht”. Hmmm. Weten we dan nu tot het einde van het project ook al wat zich “van alles” nog voor gaat doen?
Dit klinkt krampachtig. Eerst goed plannen. Dan wijzigt de wereld, zodat het plan niet meer klopt. Remedie? Nog beter plannen. Blijft de wereld dan nu wel constant?
Onzekerheid is niet uit te bannen. Wegplannen is heiloos. De uitweg is, inderdaad, hoe er mee om gegaan wordt. En dat is het te accepteren. Er zijn al goede voorbeelden: Agile-programmeermethoden en chaordisch projectmanagement werken vanuit het uitgangspunt dat de wereld voortdurend en onvoorspelbaar verandert.
Onzekerheid blijft. Dat is een zekerheid. Ook in IT. Het lijkt wel het echte leven!
Ook fijn te zien dat het Rijks ICT-dashboard weer geheel actueel is.