Steven Djohan: Waarom een IT-project geen vliegtuig is maar wel evengoed zou moeten landen

Stopzetting Basisregistratie personen

Op 5 juli 2017 werd bekend dat het ministerie van BZK na 16 jaar stopt met het grote IT-project Basisregistratie Personen (BRP). Voor het project was ooit een budget van 96 miljoen voorzien. Recentelijk bleek dat het afmaken en invoeren van de BRP nog minimaal € 225 miljoen gaat kosten. Daarnaast is de beoogde einddatum telkens opgeschoven en zou het project op z’n vroegst pas in 2023 klaar zijn.

De BRP kent een lange geschiedenis met veel politieke aandacht. Al in 2013 vormde het project één van de zeven grote IT projecten die door de commissie Elias werd onderzocht. Ook toen was men kritisch op de veranderingen die aan het oorspronkelijke ontwerp waren doorgevoerd, de inadequate projectbeheersing en de gebrekkige communicatie met de eindgebruiker. Minister Plassterk besloot toen echter het project nog een kans te geven, een beslissing waar hij dit jaar op heeft moeten terugkomen.

Lessen trekken uit het verleden

Onlangs stelden hoogleraren van de Universiteit Maastricht en Antwerp Management School Iske, Harmsen en Mulder voor om lessen te trekken uit het recente drama van de BRP. (zie ook: https://www.nrc.nl/nieuws/2017/07/17/ontleed-kostbare-ict-mislukking-zoals-een-vliegtuigongeluk-12128567-a1566963 Een goed en belangrijk advies. Want hoewel het evalueren van dergelijke projecten op papier hoort te gebeuren conform de interne richtlijnen en gebruikelijke project- en programmamanagementmethodieken, komt het in de praktijk (nog) te weinig voor. Hetzelfde geldt overigens ook voor het ordentelijke afwikkelen van de BRP bij zowel het Rijk als de gemeenten.

Een IT-crash is geen vliegtuigcrash

Iske, Harmsen en Mulder opperen om mislukte IT-projecten op vergelijkbare wijze als incidenten in de luchtvaartindustrie te evalueren. In de luchtvaartindustrie wordt na een incident alles op alles gezet om de oorzaak van een incident te achterhalen met totale openheid en grondigheid. Een fantastisch streven, maar voordat de aanpak daadwerkelijk op IT-projecten van toepassing kunnen zijn moeten er eerst een aantal grote uitdagingen worden opgelost:

 

  1. De perverse prikkel: Bij vliegtuigongelukken hebben alle partijen, de autoriteiten, vliegtuigmaatschappijen evenals vliegtuigbouwers en toeleveranciers een gedeeld belang om zo snel en goed mogelijk weten wat er gebeurd is. Het gaat tenslotte om veiligheid en mensenlevens, en daarnaast om economische en reputatieschade voor de hele sector. Evaluaties van mislukte IT-projecten uit het verleden laten echter vaak zien dat er niet zoiets is als een gedeeld belang. Verantwoordelijken kunnen niet eenduidig worden aangetoond en de mislukking van een project kan zelfs voor bepaalde betrokkenen voordelen hebben (perverse prikkels). IT-leveranciers hebben veelal geen zin om een kijkje in hun keuken te geven aan hun opdrachtgevers. Daarnaast zorgen wissels van betrokken vaak voor een beperkt gemeenschappelijk geheugen.
  2. Een veelvoud aan oorzaken: Oorzaken bij vliegtuigincidenten zijn daarnaast vaak te herleiden tot technische mankementen, fouten in gevolgde procedures of menselijk handelen. Bij mislukte IT-projecten is er vaak sprake van meerdere oorzaken die zich vaak over langere tijd hebben voorgedaan en die elkaar versterken.
  3. The show must go on: Tenslotte worden bij vliegtuigongelukken vliegtuigen van hetzelfde type als betrokken bij het ongeluk aan de grond gehouden tot duidelijk is wat de oorzaak is van een incident. Deze werkwijze houdt de druk op de ketel. In het huidige IT-landschap is het niet haast voor te stellen wat er kan gebeuren als we er voor zouden kiezen bepaalde “besmette” projecten aan de grond te houden. Het blijkt in de praktijk daarom moeilijk om dezelfde pressie uit te oefenen.

BIT met een bite

Om ervoor te zorgen dat er daadwerkelijk geleerd kan worden van kostbare IT-mislukkingen is het daarom noodzakelijk de “perverse prikkels” uit de projecten te halen, duidelijk af te bakenen in hoeverre het gaat om een “technisch mankement” (of aspecten als projectmanagement) en manieren te vinden om toch de druk op het uitvoeren van een gedegen onderzoek te houden. Dit betekent dat verschillende partijen van opdrachtgevers tot leveranciers medewerking moeten leveren aan onafhankelijk evaluaties, gericht op het trekken van lessen voor de toekomst. Hiertoe dient de overheid bijvoorbeeld in contracten met leveranciers ook clausules op te nemen inzake medewerking bij onafhankelijke evaluaties. Ook zouden huidig en oud-betrokkenen projectmedewerkers van de opdrachtgevers vrijuit moeten kunnen praten over ervaringen en lessen Daarnaast zou bij het daadwerkelijk onafhankelijk evalueren het BIT (Bureau ICT-Toetsing) een rol moeten spelen. Bij de oprichting van het BIT was een belangrijk aandachtspunt de doorzettingsmacht van het BIT om gevraagd en ongevraagd advies te kunnen geven over projecten. Juist nu zou het BIT haar tanden moeten laten zien. Tenslotte geldt het nastreven van openheid en transparantie. Geef ook de onafgemaakte producten en ontwerpen van de BRP zoveel mogelijk vrij. Het vrijgeven van onafgemaakte ontwerpen en code leidt tot het kunnen trekken van lessen evenals het stimuleren van nieuwe innovaties.

 

Wanneer aan deze voorwaarden kan worden gedaan is het begin daar om daadwerkelijk grip op IT-projecten te krijgen. Wellicht is een direct kopie van het luchtvaartmodel nog een (lucht)brug te ver, maar de vergelijking zou zeker moeten helpen om nieuwe evaluaties van mislukte IT-projecten beter te laten landen!