Als de kans dat een vliegtuig neerstort meer dan 80% is, stap jij dan nog in een vliegtuig? Meer dan 80% van de ICT gerelateerde projecten mislukken
5 minuten
Door Ron Linssen
Maar wat is eigenlijk ‘een mislukt project’? Waarom mislukken ICT projecten? En wat kun je doen om mislukking van ICT projecten te voorkomen? Zonder te pretenderen ‘the silver bullet’ te presenteren, geef ik in dit artikel graag antwoord op deze drie vragen en deel ik mijn visie en ervaringen over projectsucces opdat iedereen die te maken heeft met projecten hiervan kan profiteren.
Projectsucces: het is en blijft complex. Dat wil echter niet zeggen dat er niet vele manieren zijn om de kans op succes significant te verhogen, dat is mijn overtuiging en de ervaring van Quantra. Het significant verhogen van de kans begint met een goed begrip van ‘het probleem’, daarom allereerst antwoord op bovenstaande 3 vragen.
Vraag 1: Wat is eigenlijk ‘een mislukt project’?
Hierover zijn de meningen erg verdeeld. Daarnaast zijn er vele verschillende zienswijzen en statistieken, sommigen met een direct commercieel belang. Sinds de start van mijn werkzame leven verzamel ik statistieken en gebruik ik vaak en met veel plezier de inzichten van de Standish Group, een gerenommeerd onderzoeksbureau dat al vele jaren cijfers bijhoudt over projecten in hun ‘CHAOS (Comprehensive Human Appraisal for Originating Software) Reports'. Zij hanteren 6 parameters voor succes: Op tijd, binnen budget, resultaat behaald, doel behaald, waardevol en naar tevredenheid. Deze samengevoegd bepaald of een project wel of niet succesvol is geweest. Standish rangschikt aan de hand van deze criteria projecten in 3 categorieën. Succesful, challenged & failed:
Succesful: project scoort positief op alle 6 criteria.
Challenged: project is afgerond maar niet positief op alle 6 criteria.
Failed: project is (vroegtijdig) afgebroken.
Het resultaat, in de tijd gezien:
Bron: Standish Group CHAOS Reports 2011-2020
Wat valt u op, naast dat het een zeer laag percentage (rond de 30%) van successen is? Het veranderd bijna niet! Er is geen stijgende lijn zichtbaar wat betreft succesvolle projecten. Is dát niet nog veel erger eigenlijk? Een gegeven om ons zorgen over te maken.. Daarnaast gaat het om astronomische bedragen die gemoeid zijn bij dit soort projecten. Private ondernemingen lopen hier niet mee te koop, alleen voor publieke instellingen worden regelmatig cijfers gepubliceerd waarbij het alleen al voor de Nederlandse overheden zou gaan om een bedrag tot € 5 Miljard. Twee voorbeelden van private ondernemingen die te denken geven en wél de publiciteit haalden:
Augustus 2018: Lidl stopt met SAP implementatie, na ruim 5 jaar en € 500 miljoen aan kosten.
Augustus 2019: Leaseplan stopt met ERP implementatie, na eveneens ruim 5 jaar en meer dan €100 miljoen aan kosten.
Maar waar kan het dan aan liggen dat ICT projecten blijven mislukken? Daarvoor is het belangrijk de oorzaken van falen te onderkennen.
Vraag 2: Waarom mislukken ICT projecten?
De volgende oorzaken worden gemiddeld genomen het meest genoemd in verschillende onderzoeken:
Wijziging van scope of prioriteiten;
Onnauwkeurige eisen aan het resultaat;
Onvoldoende resources, teveel tegelijk doen;
Project sponsors niet betrokken of onvoldoende verantwoordelijkheidsbesef;
Onvoldoende betrokkenheid;
Onverwachte risico’s of veranderende omstandigheden;
Onrealistische planning / oplevering;
Slecht projectmanagement.
Allemaal herkenbaar, allemaal hele valide redenen dat het ‘wel eens’ mis kan gaan. Het valt mij echter op dat de oorzaak "Technische of algehele complexiteit” ontbreekt. Je zou verwachten dat die erbij hoort, omdat dat vaak wordt aangegeven door externe consultants / implementatie experts. Echter komt deze oorzaak pas na de top 8 terug in de statistieken met 3%.
Wat valt nog meer op? Het lijken ogenschijnlijk punten die goed omgezet kunnen worden in verbetering, zodat we leren en volgende projecten niet met dezelfde oorzaken uit de bocht vliegen. Tijd voor een verdieping op de vraag:
Waarom blijven ICT projecten mislukken?
Als je het mij vraagt is dat de échte vraag. De hiervoor genoemde oorzaken: hoe veranderen die in de tijd, want als we een oorzaak kennen, kunnen we toch maatregelen nemen? Dat vraagt om een historische analyse van oorzaken. Dit is iets lastiger om goed boven water te krijgen maar de volgende statistiek hebben we kunnen opmaken uit diverse onderzoeken:
Bron: PMI
Het heeft er alle schijn van dat dezelfde of zeer vergelijkbare redenen of oorzaken dé reden zijn voor het niet succesvol zijn van projecten, al jaar op jaar op jaar. Dat komt ook overeen met Quantra's eigen ervaringen, waarbij we zeer regelmatig Project Portfoliomanagement inrichten bij organisaties, met als doel projecten meer succesvol te laten worden. Daar zien we dezelfde oorzaken vrijwel altijd terugkomen.
Moeten we ermee leren leven, het als “niet oplosbaar” beschouwen omdat (ICT) projecten nu eenmaal lastig zijn en altijd wel andere -nieuwere- technologieën omvatten en daarmee onverwachte problemen onvermijdelijk? Zoals eerder aangegeven, is slechts bij 3% van de projecten technische complexiteit de oorzaak voor falen. Hoewel we het hiermee eenvoudig kunnen afdoen, is dat naar mijn mening aantoonbaar een verkeerde veronderstelling.
Willen we dan niet dat het verbetert, vinden we het wel prima zo? De eerste CEO of CFO/CIO die het prettig vindt dat zijn project te laat en te duur is geworden, zonder op te leveren wat is beloofd moet ik nog tegenkomen. Dat kan en mag geen optie zijn. Toch?
Blijft over: We leren vaak niet van onze fouten, omdat we ze onvoldoende in beeld hebben. Hierdoor veranderen de verkeerde dingen of veranderen niet goed genoeg.
Tijd om dáár verandering in te brengen lijkt mij.
Vraag 3: Wat kun je doen om mislukking te voorkomen?
Logischerwijs is het eerste antwoord: leer van fouten; de redenen waarom het bij jouw organisatie misgaat. De kans is erg groot dat de hiervoor genoemde 8 hoofdoorzaken ook in meer of mindere mate bij jouw organisatie aan de orde zijn. Ook kan het zijn dat technische complexiteit bij jou wél meer dan voor 3% voor falen bijdraagt, wanneer veel aan innovatie en vernieuwing wordt gedaan. Veelal vind je ‘hoe’ adviezen terug om de kans op succes te vergroten: betere projectleiders, een hoogwaardig project portfolio team, betere tooling. Mijn en onze suggesties ter verbetering zitten in de ‘wat’ sfeer, omdat een betere projectleider nog altijd de mist in kan gaan als onderstaande niet wordt aangepakt:
Kies de organisatievorm die past bij ‘de opdracht’: organiseer je het als project, als programma, in de lijn, of agile?
Een project is een organisatievorm met voor én nadelen. Vaak wordt gekozen voor deze vorm terwijl het net zo goed of beter in de lijn kan worden opgepakt of in een agile team. En áls je kiest voor ‘project’, realiseer je dan wat dit eigenlijk inhoudt: een tijdelijke organisatie met een concreet eenmalig doel dat met gelimiteerde middelen (tijd, geld, resources) moet worden bereikt.Maak een écht goed projectplan.
Wat is dat, een echt goed projectplan? Verbazingwekkend welke misvattingen hierbij bestaan en hoeveel slechte plannen er zijn, zonder concrete doelen, resultaten, tijdslijnen, inconsistentie. Een goed plan houdt rekening met alle redenen waarom het project mis zou kunnen gaan en neemt maatregelen om dat te voorkomen. En dat kan ook echt in beperkte tijd. Een vaak gehoorde reden om geen goed plan te maken: dat kost teveel tijd…De stuurgroep stuurt.
Een andere misvatting is dat de projectmanager het project bestuurt. Onder verwijzing naar punt 1 (realiseer je wat een project inhoudt): een stuurgroep bestuurt het project en mandateert de projectmanager. Daarmee is de verantwoordelijkheid niet weg. Als de projectmanager en de stuurgroepleden dit goed begrijpen en toepassen, moet het mogelijk zijn om de oorzaken voor potentieel falen tijdig te signaleren en in te grijpen zodat bijgestuurd kan worden.Voortgangsbewaking is een kunst.
In het verlengde van punt 3 maar met zekerheid een apart punt. Waarom stuurt een stuurgroep niet altijd zoals het hoort? Omdat ze de informatie niet hebben om dat tijdig te kunnen doen. Goede voortgangsbewaking is een kunst. En néé, ook hier is ‘een tool’ niet dé oplossing!Het bewaken van de business case.
Stel dat met inachtneming van het 1e verbeterpunt een project altijd alleen start met een gedegen business case (zakelijke rechtvaardiging), hoe bewaken we die dan? Altijd lastig maar wel essentieel. Om teleurstelling te voorkomen is dit essentieel. Hoewel Lidl en Leaseplan wellicht wat laat ingrepen, hebben ze wél het lef getoond om dat te doen, op basis van inzichten in de business case.
Welke bijdragen leveren bovenstaande 5 punten in meer (X) of mindere (x) mate aan het adresseren van de 8 hoofdoorzaken onder vraag 2 (Waarom mislukken ICT projecten)? Ik heb het in onderstaande tabel weergegeven.
Bron: Quantra BV
En de conclusie is...
Het is onze volle overtuiging en ervaring dat met de 5 attentiepunten (Organisatie, Plan, Sturing, Voortgang en Businesscase) het maximale kan worden gedaan om projecten succesvol te laten zijn. Het blijft complex maar de complexiteit wordt beheersbaar en bestuurbaar. Dit zijn slechts de hoofdlijnen per verbeterpunt. Het doet geen recht aan de complexiteit (en de omvang) van ‘de uitdaging’ om te veronderstellen in 3-4 pagina’s en een paar regels per succesfactor alles op te lossen. Dan is ook mijn doel, kennis en ervaring delen opdat allen hiervan kunnen profiteren, nog niet bereikt.
De volgende 5 donderdagen zal ik daarom meer details en gedachten delen per attentiepunt. Mochten er in de tussentijd suggesties ter verbetering zijn voor mij en/of gerichte vragen, laat het mij vooral weten want ook ik wil blijven leren.
Volgende week donderdag deel 1 van 5; 'Kies de organisatievorm die past bij de opdracht'. Hierin vertel ik waarom het zo belangrijk is om de juiste organisatievorm te kiezen bij het specifieke karakter van een opdracht. Op basis van welke criteria doe je dat? Wat zijn veel voorkomende missers? En wat zijn hiervan de gevolgen?
Tot volgende week donderdag!
Ron Linssen