Hoe IT-projecten slagen en falen

De achterflap van dit handzame boekje van 160 pagina’s belooft dat het meer in detail zal ingaan op het falen van projecten en daarmee een taboe zal doorbreken! Dat maakt het helemaal interessant om te lezen. Vol goede moed begon ik dus aan het boekje. De schrijfster interviewde voor het boek dertig betrokkenen bij verschillende projecten.

De achterflap van dit handzame boekje van 160 pagina’s belooft dat het meer in detail zal ingaan op het falen van projecten en daarmee een taboe zal doorbreken! Dat maakt het helemaal interessant om te lezen. Vol goede moed begon ik dus aan het boekje. De schrijfster interviewde voor het boek dertig betrokkenen bij verschillende projecten. Zij ging vooral op zoek naar de menselijke, organisatorische en sociale dimensies van IT-projecten. Hierbij wil zij aantonen dat het echt niet zo is dat alleen bij de overheid van alles misgaat. Daarnaast wil ze duidelijk maken dat wat zij de ‘immateriële lasten van de invoering van ICT’ noemt, ‘oneerlijk verdeeld’ zijn. Ze bedoelt hiermee dat CIO’s, projectleiders e.d. vaak getroffen worden door burn-outs als gevolg van kinderziektes en gebrek aan IT-beheersing. Tja, als je als direct verantwoordelijke niet in de stress mag schieten als de zaken verkeerd gaan, wanneer dan wel? Het is toch juist jouw vak om te zorgen dat het goed gaat?

Overheidsprojecten
Op basis van allerlei praktijkgevallen komt de schrijfster tot enkele algemene conclusies over de oorzaken van het mislukken van ICT-projecten. Een fraai rariteitenkabinet, dat de lezer meevoert langs projecten die we allemaal wel kennen, zoals het Belastingdienst-UWV drama rond Walvis/ Sub, buitenlandse projecten van twintig jaar geleden (vind ik eerlijk gezegd niet zo sterk als onderbouwing voor verbetermaatregelen), P-Direkt (gestart in 2001 en afgesloten in 2011 tegen een budget van € 300 miljoen, en dit wordt dan ook nog eens door de auteur een succes genoemd!) en wat minder bekende projecten, zoals het project waar de auteur zelf bij betrokken was (archeologie en monumenten). Alhoewel ze stelt dat er in de private sector ook veel misgaat, speelden de aangehaalde mislukkingen toch bijna allemaal bij de overheid. Dat is niet zo verbazingwekkend, want bij de uitwerking van de oorzaken blijken sommige oorzaken ook alleen of bijna alleen bij de overheid te spelen.
Een mislukt project wordt gedefinieerd als een project waarvan het eindresultaat niet aan de oorspronkelijke verwachtingen van de opdrachtgever voldoet. Dat lijkt een vrij goede definitie, ware het niet dat een van de veel voorkomende oorzaken van mislukken bij de overheidsprojecten verschuiving van doelen en ambities is. In deze gevallen zal een projectresultaat dat exact bestaat uit hetgeen de opdrachtgever oorspronkelijk verwachtte, sowieso worden gezien als mislukt.

Frustratie
Bij het benoemen van oorzaken komt Schönfeld tot algemene oorzaken (die voor alle mislukte projecten gelden) en specifieke overheidsoorzaken.
Als belangrijkste algemene oorzaak noemt zij het feit dat ICT als vakgebied nog erg jong en onvolwassen is. In tegenstelling tot bijvoorbeeld civiele bouwkunst, die al duizenden jaren bestaat. Nou ja, alsof niet alle grote bouwprojecten aan exact hetzelfde euvel leiden als IT-projecten: duurt langer, kost meer (Stopera, Noord/Zuidlijn, Betuwelijn, Deltawerken, you name it). Gelukkig wordt er toch wel vooruitgang geboekt, want volgens onderzoek van de Standish Group ging het percentage geslaagde projecten omhoog van 26% in 1998 naar 38% in 2010. Dus eigenlijk mislukt er maar 62%, al ligt dat percentage bij de overheid aanmerkelijk hoger.
Dat moet wel vreselijk frustrerend zijn. En die frustratie klinkt ook bij tijd en wijle door in het boek. Het gevaar daarvan is natuurlijk dat je al snel vervalt in wat ik voor de herkenbaarheid maar even ‘het klassieke DIVgedrag’ noem: gebrek aan erkenning van jouw expertise en degenen die erover gaan snappen het niet. Voorbeelden hiervan in het boek zijn: de IT’ers zijn zielig want ze raken heel vaak overspannen; IT’ers bij de overheid worden veel te weinig betaald; bestuurders snappen niets van de complexiteit; de politiek heeft steeds onrealistische wensen en toch hebben zij het voor het zeggen.

Kwart eeuw mislukkingen
Als je hier overheen kunt lezen is Hoe IT-projecten slagen en falen een aardig boek. Het is best goed geschreven (al klinkt het ambtelijk taalgebruik af en toe wel door) en komt met goede conclusies, ook al zijn die niet allemaal even nieuw. Dat hoeft tenslotte ook niet. Het zou toch raar zijn als we na een kwart eeuw mislukkingen niet al enigszins inzicht zouden hebben in de oorzaken van het falen. Persoonlijk vind ik dat de auteur het verdient dat iedere opdrachtgever dit boekje koopt, en wel vanwege de volgende observaties:

• Prince2 is vaker veroorzaker van mislukken dan dat het helpt een project te laten slagen; in werkelijkheid regeert Pino (Prince in name only). De methode zou vervangen moeten worden door een methodiek waarin plaats is ingeruimd voor de menselijke interactie.
• Het aanbestedingsproces werkt mislukkingen in de hand; een prachtig voorbeeld is natuurlijk de uitspraak van de rechter in januari van dit jaar, waarbij het Kadaster € 10 miljoen moest betalen, omdat een softwarebedrijf na een aanbestedingsprocedure de opdracht ter waarde van € 50.000 niet had gekregen. Om je te bescheuren, als het geen belastinggeld zou zijn…

Health check
Het boek sluit af met overigens volkomen terechte observaties over de problemen rond beveiliging en privacybescherming. DigiNotar, Lektober, maar ook het EPD (weer een reden waarom projecten kunnen falen, score 14 jaar en € 300 miljoen) hebben ons de ogen wel geopend.
De conclusie van Schönfeld is dat het nog wel vijftig jaar zal duren voordat honderd procent van de projecten zal slagen. Persoonlijk denk ik dat, aangezien de Deltawerken ook niet volledig heeft geprofiteerd van de leereffecten van mislukkingen sinds de bouw van de Grote Piramide, dat nog wel een optimistische inschatting is. Tot die tijd blijven we last houden van de belangrijkste faalfactoren:

• te grote ambities,
• slecht opdrachtgeverschap,
• onvolwassen markt.

Het belangrijkste wapen hiertegen zou moeten zijn: een veel betere voorbereiding, een soort health check vooraf, die duidelijk moet maken of een organisatie een voorgenomen project wel aankan. Daarbij gevoegd: meer zeggenschap voor keyplayers (projectleiders, programmamanager en opdrachtgevers), een belangrijker rol voor ICT-architecten, haalbaarheidstoetsen en aandacht voor goed opdrachtgeverschap. Eerlijk gezegd denk ik dat we het daarmee niet gaan redden. Bovendien blijft er best iets te zeggen voor een systeem, waarbij de politiek uiteindelijk mag zeggen wat er moet gebeuren en niet de uitvoerders. Maar misschien is dat mijn ouderwetse 1.0-opvatting.
Is dit een taboedoorbrekend boek? Ik vind van niet, maar wellicht kent de schrijfster meer taboes dan ik. Het is wel een handzaam boek, dat verstandige dingen zegt over het leren van mislukkingen en voorstellen doet voor verbetering. Het is ook een echt IT-boek geworden: IT’ers zijn vooral slachtoffer, de oorzaken van mislukkingen liggen vooral buiten ICT en de oplossingen vooral erbinnen. Klinkt bekend?

gertjan.degraaf@dino4.nl, Gert-Jan de Graaf is hoofdredacteur van Od.

* Carolien Lucy Schönfeld, Hoe IT-projecten slagen en falen – Leren van pijnlijke ervaringen, Sdu: Academic Service, 2012, ISBN 9789012583749.