Een tandeloos BIT is prima, mits een scherpe tong.

Het BIT (Bureau ICT Toetsing) voert toetsen uit op overheids-IT-projecten met een IT-component van meer dan € 5 miljoen. Over de vorming van het BIT is de afgelopen maanden veel geschreven en gesproken. Het is het enige concrete uitvloeisel van de Commissie Elias die een omvangrijk parlementair onderzoek deed naar de IT-zeperds bij de overheid. Scepsis overheerst bij de meesten, het BIT zou geen tanden hebben en geen macht. In dit artikel wordt ingegaan op de vraag of het BIT tanden nodig heeft om nieuwe IT-fiasco’s bij de overheid te voorkomen. De toegevoegde waarde van het BIT zou moeten blijken uit de werkwijze en de adviezen van het BIT. Adviseren kan toch ook zonder tanden?

Het BIT beoordeelt of IT-projecten die gestart worden een kans van slagen hebben of anders moeten worden ingericht. Dit doet het BIT uit eigen beweging of op verzoek van een bewindspersoon of de Tweede Kamer. Er zijn inmiddels drie projecten bekeken door het BIT, waaronder het programma oBPR (de modernisering van de gemeentelijke basisadministratie van personen).

Wat adviseert het BIT?

Het advies van het BIT is gerichtaan Gert-Jan Buitendijk, de verantwoordelijk DG voor het programma operatie BasisRegistratie Personen (oBPR). Het BIT signaleert de volgende problemen:

• Het oBPR wordt grootschalig verstoord door wijzigingen die zeer kostbaar en vertragend zijn, sommige wijzigingen lijken geen zakelijk gerechtvaardigd doel te dienen;
• De code uit eerdere fasen van oBPR is niet gedocumenteerd en introduceert onzekerheid over de planning;
• De complexiteit van oBPR is te hoog wat deels veroorzaakt is door verkeerde beleidsinterpretatie van de makers en anderzijds door de aanwezigheid van onnodige functionaliteit in het systeem;
• De beheerders van het systeem zijn bij het maken onvoldoende betrokken geweest en het onduidelijk of het systeem door hen wel in beheer genomen kan worden;
• Het systeem vergt grote inspanningen bij gemeenten om aan te sluiten op de nieuwe GBA, vertraging bij gemeenten leidt gegarandeerd tot uitloop van de oBPR;
• Een deel van de functies van de nieuwe GBA is doorgeschoven naar een vervolgfase en de realisatie daarvan zal nog eens twee jaar duren.

Wanneer je de problemen zo onder elkaar ziet staan zou je verwachten dat het BIT tot een sombere conclusie komt. Maar dat is niet zo. Het BIT is van mening dat het programma ‘succesvol afgerond kan worden mits een aantal risico’s en onzekerheden nadrukkelijker gemanaged worden’.

Voor ik naar het advies van het BIT ga, wil ik even wijzen op het volgende.

Uit de gesignaleerde problemen kan je  opmaken dat de systeemontwikkeling in het geplaagde oBPR programma in een ononderbroken stroom loopt van plan naar realisatie (als in een waterval). Een fout (of een wijziging) in het ontwerp leidt tot een fout (of een wijziging) in het bouwen, in het testen, het implementeren, et cetera. Zo ontstaat er een nare kettingreactie van fout-op-fout (of wijziging op wijziging) en kan het dus gebeuren dat er onnodige functies en zeer, zeer kostbare wijzigingen worden doorgevoerd. Vergelijkbare problemen hebben zich bij vrijwel alle grote IT-zeperds van de overheid voorgedaan. De projecten/programma’s zijn te groot, te lang, te complex en er is geen helder opdrachtgeverschap. Dat weten we al 20 jaar.

Terug naar het advies van het BIT. Het BIT adviseert in het geval van oBPR een aantal ‘concrete maatregelen’. Kort samengevat is het advies aan de DG:

• Zorg ervoor dat er geen wijzigingen meer komen;
• Maak een nieuwe planning en werk ingeval van onzekerheden met bandbreedtes;
• Laat onnodige wensen varen;
• Betrek de beheerders en voorkom verrassingen in de planning.

Wat heeft een DG aan zo'n advies

Duhh, bent u daar nog? Wat heeft een DG aan zo’n advies? Er komen altijd wijzigingen! Wat moet Gert-Jan Buitendijk nu doen? Tegen de tweede kamer zeggen dat ze moet ophouden met wetten en beleid maken?
Dit advies is te gek voor woorden. Veel IT-programma’s zijn ingebed in een onbeheersbare en complexe omgeving. En wat is het advies van het BIT: Geen wijzigingen meer. Dat kan je net zo goed stoppen met zo'n IT-programma.

Achterhaalde visie op systeem ontwikkeling?

Veel beter zou het zijn om een advies aan de DG te geven dat hem instaat stelt het oBPR beter te richten en gericht te houden. Concreet zou het advies aan Gert-Jan Buitendijk suggesties voor maatregelen moeten bevatten die er toe leiden dat hij het oBPR beter laat omgaan met wijzigingen en onzekerheden in de planningen en met requirements (wensen). Maar dat doet het BIT niet. Het BIT legt de verantwoordelijkheid voor de problemen enerzijds bij de politiek (die maar eens even terughoudend moet zijn met wijzigingen) en anderzijds bij de programmaleiding (die beter moet plannen en transparanter moet zijn over de gevolgen van een wijziging). Wanneer het BIT een moderne kijk op systeemontwikkeling en het programmamanagement daarvan zou hanteren, zouden ze dit niet zo stellen. Het BIT lijkt nog vast te zitten in het oude denken: eerst specificeren, dan realiseren.

Dus rijst de vraag: hoe kijkt het BIT eigenlijk naar IT-programma’s en projecten?

Ter verdieping het ik het toetskader van het BIT, Versie 1.1, van 22 september 2015 er op nageslagen. Het BIT-toetsteam gebruikt dit toetskader om zich snel een beeld te vormen van alle aspecten van een project en de daarmee samenhangende risico’s.

Een modern toetskader, maar verkeerd uitgelegd?

De onderwerpen die in het toetskader van het BIT aan de orde zijn is de business case (de zakelijke verantwoording) en de (meerjarige) financiële dekking voor het project én voor de beheerfase van het systeem. Daarnaast formuleert het BIT een mening over de rollen, de taken en de verantwoordelijkheden en de bevoegdheden in de projectorganisatie, waarbij men kijkt naar de helderheid waarin de rollen zijn vastgelegd en worden ingevuld door mensen met voldoende kennis en ervaring. Uitgangspunt moet een heldere scope-beschrijving zijn waarbij het BIT een oordeel vormt over wat de minimale omvang van het project moet zijn. Dit vanuit de gedachte dat grote projecten in delen moeten worden opgeknipt, waardoor in theorie de complexiteit en/of de doorlooptijd korter wordt en het resultaat aantoonbaar in stappen worden bereikt. Volgens het toetskader moet de ontwerp- bouw- en testfase van het project is zo kort mogelijk gehouden zijn of zijn geïntegreerd in een Agile/Scrum aanpak. Dit klinkt allemaal modern en verstandig, maar waarom benoemt het BIT het probleem bij oBPR niet? Het is toch duidelijk dat het geplaagde oBPR niet voldoet aan deze criteria, want fout-op-fout en kostbare wijziging-op-wijziging?

Dit brengt me op de vraag hoe legt het BIT haar eigen toetskader uit?
Is er sprake van gebrek aan durf om zaken te benoemen? Of legt ze haar eigen toetskader (dat je uit elk modern ICT-boekje kunt halen) gewoon verkeerd uit? In de uitleg van het toetskader valt het BIT echt door de mand in haar advies over het programma.

Implementatie en overdracht naar de lijn
Een voorbeeld is de oriëntatie op lange fasen. Het BIT spreekt van ‘Implementatie en overdracht naar de lijn’. Het BIT vindt dat de ‘na uiterlijk 2 jaar de implementatie bij eindgebruikers moet zijn begonnen’. Deze periode is absurd lang en in strijd met het eigen toetskader dat Agile/Scrum predikt. Wanneer blijkt dat alleen het ontwerpen al maanden gaat duren en het dus jaren duurt voor er software geïmplementeerd kan worden bij eindgebruikers, moeten er direct alarmbellen gaan rinkelen. Een IT-ontwerp dat maanden in beslag neemt, is voor een foutloze uitvoering meestal té complex. En dat blijkt ook zo te zijn in het oBPR programma (en al die andere overheidsfiasco’s).

Bovendien, wat succesvolle IT-projecten met elkaar gemeen hebben is dat er helemaal geen overdracht is naar de lijnorganisatie, maar dat de lijnorganisatie aan de basis van de IT-ontwikkeling staat. En dus de drijvende kracht is. Er komt in een succesvol IT-project onder hun leiding veel sneller concreet resultaat, dat direct door hen gebruikt wordt. De oriëntatie is dus geen jaren maar maanden.

Terughoudend met wijzigingen
Een ander bewijs voor het verkeerd uitleggen van het eigen toetskader is het advies om maar terughoudend te zijn met wijzigingen. Dat is onrealistisch. Wijzigingen kunnen heel valide zijn en een IT-programma moet daarmee om kunnen gaan. Maar, een wijziging moet door/voor de projecteigenaar geprioriteerd worden en er moet een positieve business case voor zijn. In een gezond IT-programma toont de eigenaar van het programma (als deze goed gecast is, is dat de belangrijkste representant uit de lijnorganisatie) zélf aan dat de wijziging doorgevoerd moét worden. En rekent voor (of laat dat doen) dat de wijziging zakelijk verantwoord is. Wanneer de verantwoordelijkheden in een IT-programma goed belegd zijn is het dus onmogelijk dat er een verkeerde beeldvorming rond functionaliteit of de noodzaak van een wijziging ontstaat.
Het is niet de programmaleiding die het nut van doorvoeren van een wijziging (en de gevolgen daarvan) moet uitleggen, het is de eigenaar/opdrachtgever die dat moet doen.

Dát had de conclusie van het BIT moeten zijn. Het BIT had moeten zeggen: “Gert-Jan, ga eens eigenaarschap nemen en kom uit je ivoren toren, want er gebeuren dingen in jouw programma die zakelijk onverantwoord blijken te zijn”. Je hebt voor een dergelijk advies toch geen tanden nodig? Hooguit wat lef én een scherpe tong. De politiek heeft de tanden en doet de rest. Maar de politiek moet wel helder geïnformeerd worden over wat er mis gaat. Dat is niet gebeurd en dus verandert er waarschijnlijk niets in het oBPR programma.

Noot: Meer info over ICT projectmanagement bij de overheid.