Dat de presentatie van de parlementaire enquêtecommissie ICT enigszins pijnlijk zou kunnen worden zat er een beetje in, maar ik heb mijn hoofd een paar keer vrij hard op tafel geslagen toen Kamervoorzitter Van Miltenburg zei: “Ik moest eerlijk gezegd wel even googlen wat dat nou precies betekent, dat ICT.” Maar goed, ze maakte wel in één keer inzichtelijk waar het om ging: het onvermogen van de overheid wat betreft ICT.
Een van de aspecten die in het rapport van de commissie aandacht kreeg was ‘scope creep’. Gedurende een project komen er steeds meer eisen op tafel en uiteindelijk dijt dat uit tot een onhandelbare moloch. Dan lijkt het een logische maatregel om aan het begin van een project precies vast te leggen wat je gaat maken.
De Sociale Verzekeringsbank moest onlangs bekend maken dat het een nieuw ICT systeem, dat voor 44 miljoen euro was ontwikkeld, niet in gebruik zou nemen. Op de vraag van Radio 1 of de SVB een procedure zou beginnen tegen leverancier CapGemini omdat het systeem niet werkte, antwoordde de woordvoerster: “Wij nemen het systeem niet in gebruik omdat het bij oplevering niet bleek te voldoen aan onze verwachtingen.” CapGemini had geleverd waar de SVB om vroeg, alleen waar de SVB om vroeg was niet wat de SVB nodig had.
En dat is een vaker terugkerend probleem bij ICT ontwikkeling: je moet een offerte aanvragen voor een systeem, zonder dat je weet wat dat systeem precies moet doen en hoe het dat moet doen. Toen eind 2009 het nieuwe landelijke computersysteem van de politie, BVH, werd ingevoerd verzuchtte een geïnterviewde politieman in De Volkskrant dat hij in plaats van 30% nu 60% van zijn tijd kwijt was aan papierwerk. Er waren wel mensen van de politie betrokken geweest bij de ontwikkeling van het systeem, maar alleen van de afdeling inkoop. Geen daadwerkelijke eindgebruikers.
Onder zowel scope creep als onbruikbare systemen ligt eenzelfde probleem: in de ICT wordt er te weinig ontworpen. Vaak wordt er rechtstreeks van offerte naar implementatie gesprongen. Iedereen die wel eens ontwerpt weet dat het de eerste keer meestal niet raak is. Je moet een paar keer terug, herontwerpen, kijken of het nu wel werkt. Itereren dus. Zo verbeter je je ontwerp. En zo kom je ook tot betere eisen. ‘Wicked problems’, venijnige vraagstukken, heet dat in ontwerpjargon: een probleemstelling leidt tot een ontwerp, dat weer leidt tot een betere probleemstelling, etc. Dat itereren is inherent aan ontwerpen.
De ICT sector zou toe moeten naar een projectfasering met een grondige ontwerpstap. Meer aandacht voor het inventariseren van gebruikseisen (eisen van gebruikers dus, niet van ICT’ers en inkopers) en waarin iteratief wordt ontworpen. En dan, als het ontwerp enigszins volwassen is, dán kiezen wanneer je welk deel wilt doen en kunt betalen, en de implementatie aanbesteden. De gemiddelde afdeling inkoop wordt alleen niet blij van zoveel onzekerheid. Maar helaas omzeil je die onzekerheid niet door dan maar zo weinig mogelijk te ontwerpen.