Als ik de laatste berichten mag geloven, is de totale schade van mislukte projecten groter dan alle ICT beveiligingsincidenten bij elkaar. Kijk naar Walvis. Kijk naar het Elektronisch Kind Dossier. Of P-Direkt. VIDI. Project Toeslagen bij de belastingdienst. GPS bij justitie. MULAN, SUB, Sagitta. Nu ook het megaproject Gemeentelijke Basis Administratie gestrekt is gegaan, is er veel aandacht voor de projectaanpak. De SP heeft een meldpunt ingericht en de Kamer wil een parlementair onderzoek. Met deze reeks aanhoudende ICT-fiasco's bij de overheid komen langs alle kanten de beste stuurlui belangeloos langswaaien met hun adviezen. Hopen op een parlementaire enquête dus, want dan kun we misschien wel op TV vertellen dat we het beter weten.

De communis opinio is dat er een gebrek is aan kennis en dat er onrealistische tijdspaden opgelegd worden aan de projecten. Het is wel interessant te zien hoe deze twee zaken aangepakt worden. Ik wil dat zelf ook wel eens leren.

Alle adviezen bieden ongeveer dezelfde drie recepten - strakker managen op de plannen en de procesinrichting, kopiëren van succesvolle systemen en projecten elders en meer controle op alle stappen. En omdat het de overheid betreft zie je ook een vierde recept: uitbesteden. Deze – uiteraard goedbedoelde - adviezen zijn staan garant voor nog meer probleemprojecten. Ze leiden tot afgeraffelde en slecht doordachte systemen, die opengebroken kunnen worden zodra iemand de moeite neemt. Een vooruitzicht dat, gezien de toename van overheidsbrede informatiesystemen met privacygevoelige informatie, niet vrolijk stemt. Laten we de recepten eens nader bekijken.

Recept 1: Strakker Managen
Strakker managen is het management-equivalent van keihard aanpakken: iedereen is het direct met je eens. Als je de stukken van de ministeries bekijkt, lees je zinnen als "Er is voor de ontwikkelprojecten van P-Direkt een op PRINCE II gebaseerde aanpak, inclusief kwaliteits- en risicomanagement en een sluitende overleg- en informatiestructuur. Op gezette tijden vinden audits plaats." Nou, dat is dus al lang strak geregeld.

Of toch niet? Prince II is een besturingsmodel voor IT-projecten uit de jaren '80 en het vertoont dan ook wat sleetse plekken. Het richt zich bijvoorbeeld op kleinere en middelgrote projecten van een paar maanden tot hooguit een jaar, en veronderstelt een Controlled Environment. De complexiteit is sindsdien enorm toegenomen (zo is de rekenkracht en de hoeveelheid data verduizendvoudigd en gaan projecten niet meer over losse systemen maar over geïntegreerde systemen, dus 1000x1000x1000) en tegelijkertijd is de macht van de ICT behoorlijk afgenomen. En passant zijn we de Controlled Environment ook kwijt geraakt. In 1988 kon je tegen de klantorganisatie misschien nog zeggen dat ze gedurende het project de werkelijkheid maar even moesten bevriezen. Nu kan dat niet meer.

En dan de bureaucratie die voortkomt uit Prince II: een enorme hoeveelheid papier- en tijdsverbruik, waardoor de tijdspaden inderdaad onrealistisch kunnen worden. Een beetje PID (Project Initiatie Document onder Prince) heeft de toon, omvang en detaillering van een regeerakkoord van tot elkaar veroordeelde partijen. Dat opstellen kost al gauw een jaar, die afgaat van het budget, de ontwikkeltijd en de bouwtijd. Als de PID ook nog gepaard gaat met een aanbesteding kun je het qua omvang en realisme eerder vergelijken met het verzameld werk van Tolkien. Vaak kost de voorbereiding meer dan 80% van de tijd en het budget. Het bouwproject houdt zich vervolgens maanden bezig met dit alles weer overboord gooien. Dat sommige projecten onder politieke (tijds)druk de PID fase overslaan is dan ook begrijpelijk, maar niet automatisch de oorzaak van eventueel later falen.

Een manier van 'strakker managen' is het project opknippen in meerdere, kleine projecten en dat dan in een programma onderbrengen. Dat moet de stuurbaarheid ten goede komen. Maar een project is pas interessant voor je status als het groot is. Dus het stuurbaar maken op de manier die de rekenkamer aanraadt, zal de ambitie van de bestuurders en projectmanagers doen verschuiven naar de programma's waar die projecten onder vallen. Dus er komt een extra laag middenkader bij, en de projectmanagers worden allemaal programmamanagers. Dat is reuze fijn voor ze, maar hoe dit helpt tegen de kwaal is mij niet geheel duidelijk. Zo storten niet alleen projecten, maar ook hele programma’s af.

Wat ook kan, en heel modieus is, is 'dakpansgewijs plannen': al aan de volgende stap beginnen als de vorige nog niet helemaal (of helemaal niet) klaar is. Het is daarbij niet erg dat iets niet lukt, we gaan al bouwen aan de volgende stap als we alleen maar een schets hebben. De aanname is dat de eindsituatie niet veel zal afwijken en alle problemen binnen de gekozen aanpak oplosbaar zijn. Hiermee wordt niet alleen de tijdsdruk opgevoerd, maar de inhoudelijke druk op de ontwerpers nog veel meer - als iets inherent verkeerd blijkt, kun je niet meer veranderen. Dit leidt ertoe dat alle initiële aannames koste wat kost overeind moeten blijven. We zetten de dominosteentjes heel dicht op elkaar, dan vallen ze vast niet om. Als dit tot een goed systeem leidt terwijl je met een samengeraapt team werkt aan iets complexers dan een Winzip implementatie, is dat stom toeval.

Intussen pleit Binnenlandse Zaken voor Centrale Coördinatie van de grootschalige ICT-projecten. Niet verrassend is dat het ministerie zélf deze verantwoordelijke taak wel op zich wil nemen. Gegeven de traditionele interdepartementale kippendrift en het algemene landjepik lijkt mij dit een geheid recept voor nog veel grotere drama's. Of hebben ze een medicijn uitgevonden tegen de 'Not Invented Here' en 'Over de Schutting'-syndromen?

De kritiek op de overheidsprojecten gaat duidelijk een bepaalde kant op: de kwakzalvers geven de patiënt de schuld. Dat noemen we met een memorabele term alibimanagement, en als recept roepen wij projectmanagers in koor: strakker managen. Geen Changes, gedetailleerdere ontwerpen, uitgebreide inventarisaties, meer kwaliteitsbeheer, meer rapportages. Allemaal versterkt door een extra laag als Centrale Coördinatie, al dan niet overheidsbreed. Kortom: meer macht voor de projectmanager! De kwaal wordt als medicijn voorgeschreven, maar niet in een afgezwakte vorm zoals bij een vaccin.

Recept 2: Successen kopiëren
We weten niet waarom sommige projecten lukken, maar als we gewoon blind alles hetzelfde doen dan boeken wij óók succes. Zo werkt de methode Best Practice. Onze OV-kaart bijvoorbeeld zou een exacte kopie worden van de Octopus kaart in Hong Kong. Need I say more? De managerial insteek bij kopiëren is dat je alle risico's al kent en de oplossingen daarvoor dus ook. De Octopus kaart is in 1997 in gebruik genomen, en wordt anno 2008 nog steeds als argument gebruikt dat het hier helemaal goed gaat komen.

Maar Octopus gebruikt onder meer single DES, dus moest Translink voor die andere chip kiezen, die nu gekraakt is. Maar goed, je kunt nog altijd de schijn van kopiëren ophouden en vervolgens schijnsturen en je schijnsuccessen vieren op de noodzakelijke champagnemomenten. Wat TLS dan ook maar deed. Waar TLS vervolgens achter kwam is dat Hong Kong geen Nederland is. Zo is de overgang in Hong Kong bot afgedwongen en is een stad - hoe groot dan ook - iets anders dan een land met tig vervoersmaatschappijen. Een deel van het succes in Hong Kong was ook dat de Octopus feitelijk tevens een chipknip is. En die hebben we hier al. Bovendien kampten de inwoners van Hong Kong met een nijpend gebrek aan muntgeld. Wij niet.

Translink wilde in haar megalomanie niet alleen de strippenkaart vervangen maar ook de chipknip. Dat de chipknip hier ook maar niet wil aanslaan, ondanks de gezamenlijke dwang van overheid en financiële sector en tegen een beduidend hoger budget dan de hele OV-kaart, had toch iets duidelijk moeten maken. Dezelfde misser hebben we gezien bij dat andere megasucces, C2000. Lesje projectmanagement: een succesvol project kún je niet kopiëren. Zit in de definitie van het woord project - het is eenmalig. Oftewel ook dit recept is de kwaal zélf.

Recept 3: Meer Controleren
Dit recept ligt in het verlengde van 'lekker strak managen' en wordt vooral door auditoren en consultants aangeraden. Huur mij in en het komt hélemaal goed. Auditing controleert of je doet wat je op papier hebt gezet – of je dat op de goede manier doet. Maar of je het goede doet? Dat zou de vraag moeten zijn. Zo lang de auditor echter niet helderziend is kan hij alleen afwijkingen op de plannen zien. Veranderingen in de werkelijkheid of fouten in de initiële aannames komen niet boven tafel. Een audit op een lopend project is een apart vak, zeker als het project niet conform waterval werkt. Auditing is zeker nuttig maar zal bij onrealistische verwachtingen al snel in een verdomhoekje belanden – er is immers niets ergers dan falend toezicht op de publieke zaak, nietwaar? Dat rijdt in een Saab leasebak en kan geeneens toveren... Tssk.

Zo lang een audit impliceert dat alles conform een vooraf in detail vastgelegde planning gebeurt – daar wordt immers tegen geaudit – is de inzet van een auditor een symptoom van de kwaal.

Een 'second opinion' van onafhankelijke specialisten zoals recent in zwang is geraakt, zou de traditionele beperking van de audit moeten ondervangen. Maar als projectmanager heb je erg veel mogelijkheden om een ongewenste uitkomst van een second opinion buiten scope te plaatsen: de koers veranderen is immers vreselijk kostbaar, vertragend en anders stel je de competentie van de ander ter discussie. Feitelijk is een second opinion die sterk afwijkt gezichtsverlies voor het hele project én de opdrachtgever. Als je de second opinion 'meeneemt' is dat meestal alleen voor de vorm, anders loopt je hele team boos weg. En daar gaat je continuïteit.

Bedenk je ook dat alleen helderzienden een goede second opinion zó uit de mouw kunnen schudden. In de twee weken die er meestal voor gegeven wordt aan iemand die even op de bank zit, krijg je doorgaans niet veel meer dan wat platitudes in een standaardrapportje: strakker scopen, meer communiceren en meer tussentijds rapporteren. Menig adviseur zal – al dan niet impliciet – voorstellen een collega van dezelfde firma in te huren. Dit medicijn heeft hooguit een placebo-effect.

Recept 4: Uitbesteden
De ondertoon in veel commentaren op de falende projecten bij de overheid is dat je maar beter kunt uitbesteden, want de overheid maakt er maar een potje van. Leuk hoor, maar laten we deze marketingvariant op de aloude ambtenarengrappen maar even vergeten. Veel van de genoemde projecten zijn juist uitgevoerd door 'gerenommeerde marktpartijen'. Dat die hun klant de schuld geven wil niet automatisch zeggen dat dat daadwerkelijk zo is. En de niet-uitbestede projecten krijgen te maken met uitbestede delen van de eigen organisatie en da's ook geen feest, hoor. De veronderstelling dat de procedures niet worden gevolgd is evenzeer onjuist. Er wordt ook bij de overheid al jaren lustig en grootschalig ge-in-, ge-out- en ge-resourced, geaudit, gemanaged en gerapporteerd en het helpt geen bal.

Bij uitbesteden of met een politiek correcte term 'sourcen' ga je systemen langs arbitraire lijnen opknippen en versnipperen over tal van leveranciers. Alleen: een systeem is helaas geen stuk ijzer waar toevallig wat applicaties op wonen. Het is een complex geheel van vele lagen en componenten. Er is geen mate van strak aansturen en auditen die de puzzel kan oplossen als je dat verspreidt over verschillende partijen. Je kunt immers niet naar één partij outsourcen want dan krijgt die te veel macht, toch?

In dit geval is het recept nog veel erger dan de kwaal: uitbesteden over meerdere partijen is sturingstechnisch een kansloze opgave. Je besteedt het LAN uit aan de één, de back-end aan de ander – maar zónder de applicaties, die gaan naar een paar anderen, weer een ander doet het rekencentrum, en als klap op de vuurpijl laat je nog een andere leverancier de Security 'doen'. Echt waar, dit bestaat. Schuiven met lucifersdoosjes, terwijl je op je vingers kan natellen dat dit een recept voor drama's is. Security gáát over macht, zeker de macht over de ICT maar meer en meer ook over de hele organisatie. 'Ik ga eens lekker het systeem en de processen van mijn concurrenten afkeuren. Want wij hebben een breder portfolio dan alleen Security, zeker sinds die laatste fusie'. Jij zal zoiets misschien niet denken, maar je Security vakgenoten zijn jammer genoeg meestal wat minder integer.

Wat fascinerend is dat niet één van de voorgeschreven medicijnen zich richt op de kwaal ‘gebrek aan kennis’ en alleen als je het erin wilt lezen op de kwaal onrealistische tijdspaden. Iedereen wijst als schuldige 'de klant die telkens wat anders wil' aan. Dit veronderstelt dat als je vooraf precies bepaalt wat je wilt en daar verder niet aan sleutelt, het helemaal goed komt. Nu is één van de vaak genoemde oorzaken de tegenvallende complexiteit van de beveiliging, die telkens wat anders wil en niet precies weet hoe..... Is dat iets anders willen of iets anders moeten - omdat zoiets triviaals als de werkelijkheid zo af en toe verandert en dat je vooraf gewoon niet alles kon weten?

Van PID en aanbesteding tot in de projectuitvoering heerst de fictie dat de requirements niet zullen veranderen en dat alle aannames kloppen. Maar gedurende het project verandert de werkelijkheid toch. Heus wel. Zeker als het project 5 jaar loopt. O tjee, wéér een tegenvaller. De waterval benadering is het werkelijke probleem, een gedetailleerde planning die niet gebaseerd is op realistische veronderstellingen houdt in dat het project van tegenvaller naar tegenvaller strompelt tot het uit zijn lijden wordt verlost.

Om te adviseren om dan maar uit te besteden aan 'marktpartijen' die niet in staat blijken om in zeven jaar een MS Access 2.0 bestandje te porten naar een ASP.Net-applicatie en nooit van testen hebben gehoord maar wel mooie kwaliteitscertificaten en processen hebben, is nog erger. Als drie pleisters niet helpen tegen een acute depressie, zou een hele doos dan wel helpen? Er wordt al veel te veel geborgd, belegd en afgekaderd in de wondere wereld van de digitale Betuwelijn.

Maar ik ben bang dat we ook in de toekomst strak zullen vasthouden aan het oorspronkelijke plan, omdat iedere verandering nu eenmaal tot vertraging en gezichtsverlies leidt. Er komt geen ruimte voor voortschrijdend inzicht. We blijven nare ontwikkelingen als het kraken van kerncomponenten negeren. En naar aanleiding van de reeks fiasco's die nu in de publiciteit zijn gaan we nóg krachtdadiger sturen, projecten nog complexer maken, nóg meer 'naar de markt brengen' en nóg steviger vasthouden aan het oorspronkelijke megaplan. En daardoor gaan we dus nóg grotere megafiasco's meemaken, met systemen die live gaan met vijftien jaar oude technologie, die niet getest zijn en waar alle rafels dus nog aanzitten. Er is de komende tijd nog zat te pappen en nat te houden, dus als je je verveelt, kun je ook in de Security komen werken.

Peter Rietveld, Senior Security consultant bij Traxion - The Identity Management Specialists -

Vorige columns van Peter