Channels

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.

Lees ook:

De weg geplaveid naar volgend ICT debacle bij de overheid?

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.

Kennisbank onderwerpen:

Kennisbank onderwerpen:

 

Reageer

Na het plaatsen kunt u uw reactie nog 30 minuten aanpassen.

Reacties

De kern van het probleem is inderdaad dat het opdrachtgeverschap weer niet goed is belegd. Nico Beenker schrijft terecht: “dat de lijnorganisatie aan de basis van de IT-ontwikkeling staat”.
De consequentie is dan ook dat we niet meer over ICT-projecten moeten praten en zeker niet vanuit het perspectief van de ICT-er, Dus het erbij slepen van ICT-ontwikkelaanpakken als Agile en SCRUM helpt ook niet veel.

Wat verder zeker niet helpt is een adviesclub over ICT-projecten gevuld met ICT-ers. De opzet van het BIT zoals oorspronkelijk voorgesteld, is eerder deel van het probleem dan van de oplossing. De kritiek van Beenker is terecht maar ook volledig voorspelbaar. Het is een club die als ICT-specialisten naar projecten kijkt; niet een club die die vanuit opdrachtgeverschap en vanuit nut en noodzaak naar projecten kijkt,

Plaatsing van het BIT onder de CIO, zoals minister Blok heeft gedaan, versterkt dit probleem alleen maar. Het resultaat is dit soort adviezen.

Ik heb eerder op deze site een veel gelezen stuk geschreven met de titel: ICT-projecten komen in de problemen omdat het ICT-projecten zijn.
Als vervolg daarop: Het BIT komt in de problemen en heeft weinig nut omdat zij vinden dat (1) er ICT-projecten zijn waarover (2) vooral ICT-ers verstandige dingen kunnen zeggen.

Beste Nico,

Een waardevolle analyse, waarvoor dank. Maar wil toch graag een ander geluid laten horen, vooral omdat ik onlangs heb geparticipeerd aan een inhoudelijke sessie over de ins en outs (en vooral de werkwijze qua governance) van het BIT. Want het goede nieuws is absoluut dat het BIT de politiek confronteert met de consequenties haar besluiten. En juist dat is écht winst: daarmee wordt het traditionele patroon waarbij vaak onuitvoerbare opdrachten worden verstrekt doorbroken. Want het BIT confronteert de politiek keihard met de gevolgen van haar eigen keuzes. Wat hiervoor gewoon not done was: het ambtelijke apparaat was zo loyaal om het braaf uit te voeren en als je dan het lef had om daar iets van te zeggen was dat in de regel geen opstekertje voor je carrière. En als je dat maar lang genoeg gaat volhouden dan komt er van zelf wel een leerproces op gang.

Kort & goed: ik ben aanzienlijk minder somber gestemd – hier wordt mijns inziens écht een patroon doorbroken waarbij dat verstikkende watervalmanagement (iedereen die iets bedenkt en het daarna over die bekende stutting kiepert) ook wordt gekild.

Groet Dirk-Jan

Dirk-Jan en ik hebben fundamenteel verschillende visies en ideeën over de materie. Daar hebben we eerder al bewijs van gezien.

In mijn optiek is het ondenkbaar dat een opdrachtnemer een beeld vormt van de gezondheid van een project. Dat is ondenkbaar bij een externe leverancier want daarvan begrijpt iedereen dat er andere, tegengestelde belangen spelen (hoewel de overheid toch vreemd genoeg de regie geeft aan de leverancier: SPEER (Defensie) en de SVB zijn hiervan onthutsende voorbeelden).

Maar dat geldt ook voor interne leveranciers, zoals de CIO. Want dan gaat politiek, macht, status en budget spelen. Daarom is zowel het doel als de positionering van het BIT verkeerd en contraproductief.

ICT-ers hebben, zoals alle specialisten, te veel vertrouwen in hun eigen visie. Zij zien hun eigen bijdrage als doel, niet als middel. Verwijzend naar de vele projecten die om deze reden in de problemen komen en verwijzend naar andere bijdragen van Dirk-Jan op dit platform als pleitbezorger van de CIO’s: QED.

Neem hierbij ook in beschouwing de veel gebruikte verdedigingswal van overheids-ICT-ers: het ligt aan anderen, het ligt aan de politiek die iets “over die bekende stutting kiepert” (zie hierboven). De grootste negatieve overheidsklappers op ICT gebied zijn door CIO’s bedacht, gestart en uitgevoerd: SPEER, WIA en SVB zijn maar enkele voorbeelden. Daar had de politiek niets mee te maken. Het was het speelgoed van techneuten.

Een knappe analyse Nico,

Ook de reactie van Nico (Viergever) snijdt hout.

De waarde van de reactie van Dirk Jan kan ik niet begrijpen. Hij illustreert hoe iemand die in een systeem gevangen zit moeite heeft om vanuit een groter kader naar een probleem te kijken.

Overigens lijkt dit ook het probleem van het BIT management te zijn.

En ondertussen betalen we deze grappenmakerij allemaal met zijn allen.

Het echte vraagstuk is daarom: hoe doorbreken we dit?

My 2 cents for today

Toon alle 4 reacties
x
x