Minder dan de helft alle ICT-projecten volledig succesvol
Minder dan de helft van alle ICT-projecten (48 procent) is volledig succesvol. Dat blijkt uit de Ernst & Young ICT Barometer van juni 2007. In totaal mislukt vier procent van alle gestarte ICT projecten volkomen. Bij Ernst & Young hebben ze een rekensommetje gemaakt. Naar zeer ruwe schatting worden er volgens de accountantsorganisatie 380.000 ICT projecten per jaar gestart. Vier procent daarvan, dat zijn grofweg 15.000 volledig mislukte projecten. Per jaar. Dat is duur.
In de ICT Barometer, die tweemaandelijks wordt uitgevoerd door InterviewNSS, komen zeshonderd directeuren, managers en professionals uit het Nederlandse bedrijfsleven aan het woord. De respondenten wijzen verschillende oorzaken aan voor het falen van een project.
Meestal werkt een ICT toepassing niet door technische problemen in een organisatie (37 procent van de respondenten voert dit als reden op). 28 procent van de ondervraagden wijt het mislukken van een project aan het niet voldoen aan de verwachting van de klant, 23 procent wijt het falen aan uitloop in tijd. Voor 11 procent van de respondenten is kostenoverschrijding de belangrijkste oorzaak van mislukken.
Op de site van de ICT Barometer is het rapport in pdf te downloaden. Ook staat er nog een aardig video-interview met de directeur ICT Leadership bij Ernst & Young, Jacob Verschuur. En ook Nico Huizing, partner van Ernst & Young EDP Audit, heeft nog een aantal interessante opmerkingen over ICT projecten op video gezet.
Van april 2007 tot juni 2011 was ik freelance editor/ communitymanager / hoofdredacteur bij Marketingfacts. Tussendoor werkte ik bij Insites Consulting, IDG Nederland, Saatchi&Saatchi;/Leo Burnett (voor Samsung) en voor onderzoeksbureau WUA. Vanaf 1 november 2021 vorm ik samen met Luuk Ros de hoofdredactie van Marketingfacts.
@Matthijs Als je even de moeite neemt en goed met Google aan de slag gaat, verwacht ik dat je ditzelfde bericht de afgelopen tien jaar aantreft.
De vraag is of je deze post ook alvast kunt schrijven voor vrijdag 21 juni 2008 of dat we er nu echt eens wat aan gaan doen met z’n allen. Ontwikkelingen genoeg die bedoeld zijn om dit percentage omhoog te krijgen: Agile-projecten, requirementmanagement, risico-analyse, kwaliteitsmanagement, quality gates, usability-labs, geen mega-projecten maar behapbare klussen en natuurlijk een gedegen testproces. Ik kan het rijtje nog veel langer maken, maar de vraag is op dé oplossing er wel tussenzit. Want hoe mooi onze methoden, aanpak en technieken ook mogen zijn, dit soort cijfers blijft aantonen dat we blijkbaar toch nog ergens de plank goed misslaan.
@Marc, ik heb me daarover de afgelopen jaren wel verbaasd. Hoe kan het nu toch dat (met name in de ICT) planningen en eindresultaten ‘nooit’ kloppen. je zou toch zeggen dat men leert van fouten en het een tweede keer beter (of in ieder geval anders) doet?
Ik vrees overigens wel dat je gelijk hebt en dat we over een aantal jaren weer hetzelfde bericht kunnen plaatsen.
@Marco – omdat het door de aard van het werk ondoenlijk is een precieze inschatting te geven van hoeveel tijd het zal kosten – als ik jou een Sudoku-boekje geef kun je mij ook niet exact aangeven wanneer je ze allemaal hebt opgelost.
Datzelfde geldt, vooral bij grote projecten, voor het vertalen van de wens van de klant naar een technische oplossing. Als die vertaling niet helemaal klopt krijg je wijzigingen in het plan, die weer niet in te schatten zijn.
@Peter: met je eens dat het niet eenvoudig is, maar door de introductie van FO’s, TO’s, change request procedures, etc. moet het toch mogelijk zijn om een wat realistische inschatting te maken van tijd en kosten?
@Marco Ik denk dat die realistische inschattingen nog wel eens lukken, maar het probleem zit ook vaak in de scope die ondertussen wijzigt als gevolg van nieuwe inzichten, marktwerking en bewegende concurrenten. Het bekende time-to-market versus doorlooptijden.
Inderdaad is dit een kopie van het bericht van de laatste 4 jaar volgens mij. Elke keer weer, elke keer de helft.
De reden hiervoor is denk ik tweeledig: ten eerste communiceert ICT niet goed met de rest van de wereld. Mijn vader zegt altijd: communiceren is zo dicht mogelijk langs elkaar op praten. ICT’ers en marketeers of anderen praten met een oceaan ertussen langs elkaar. Communiceren met ICT’ers en communiceren voor ICT’ers is nog steeds een ondergeschoven kindje heleaas.
Ten tweede omdat men vaak niet weet wat men wil of men uitgaat van iets dat niet past. Vraag maar eens aan een klant wat hij of zij nu echt wil en veelal (zeker bij grotere organisaties, niet bij ondernemers) krijg je de vraag terug: waar kan ik uit kiezen? Wat bied je aan?
Daarnaast wordt er vaak gekeken naar grote programma’s (Siebel, Sap, etc) en dat moet dan… maar of het echt past is twee.
Ik ben het 100% met Vincent eens dat SAAS hierin een grote oplossing kan bieden. Want ten eerste kan je klein beginnen met testen voordat je het organisatie breed uitrolt. Ook is de switch als het goed is makkelijker zodat systemen beter bij je organisatie kunnen passen. Wat de pricing betreft is het denk ik een kwestie van nieuwigheid dat ze dergelijke praktijken er op na kunnen houden….
Ik merk dat er ook vaak het ‘binnen = binnen’ principe erg populair is. Ook al zou de communicatie op orde zijn, de requirements goed gemanaged zijn, etc. etc.. Er wordt in een eerder stadium (al dan niet willens en wetens) voor een te laag bedrag een offerte uitgebracht.
Het idee: ‘Zijn we eenmaal binnen, komen ze toch niet meer van ons af.’
Zolang de ICTer de koning met 1 oog is en de rest (zo goed als) blind, zal dit, imho, ook niet veranderen.
@Marco, voor de gemiddelde inkoper is het moeilijk de prijs/prestatieverhouding hard te krijgen.
Bijvoorbeeld: 4 partijen in de race. 3 van de 4 zitten redelijk dicht bij elkaar. De vierde biedt aan het project te doen voor een kwart van de prijs van de andere drie. Met de goedkoopste gaat men in zee. Voor partij 4 is het een mooi project voor de stagiaires/juniors. Zij kunnen hun kennis opbouwen. Gevolg: voor een te lage prijs wordt een heel ander project geleverd dan inkopers hadden gedacht. Men heeft niet onder controle wat kwaliteit betekent, wat prestatie precies inhoudt.
Een goede prijs moet je laten afhangen van prestaties van een bedrijf uit het verleden. Als ik hoge uurlonen reken maar nooit een project laat mislukken, ben ik voor jou veel goedkoper dan clubs die het voor weinig doen, niet afleveren, het geld opstrijken en jou met de rotzooi laten zitten.
@Peter, natuurlijk zijn realistische deadlines in te schatten. Je moet alleen uitkijken dat er gedurende het project niet zoveel uitbreidingen bijkomen zonder dat de prijs of de doorlooptijd wordt aangepast.
Heel vaak beginnen de problemen al met onmogelijke contracten.
@Hein – theoretisch wel, alleen is het lastig de juiste mate van diepgang van de inventarisatie te vinden. Te weinig betekent een te vage inschatting, te veel betekent dat je in het voortraject te veel tijd moet investeren.
Ernst & Young (2007) laat enkele interessante inzichten zien.
De redenen die genoemd worden voor het niet geheel succesvol zijn:
– 28% toepassing voldoet niet (volledig) aan verwachtingen
– 23% project is uitgelopen qua tijd
– 19% toepassing werkt niet door technische problemen
– 18% toepassing werkt niet door problemen in organisatie
– 11% project is uitgelopen qua kosten
– 5% problemen met leverancier
Maar dit geeft mijns inziens nog een te rooskleurig beeld, zeker wat betreft het percentage projecten dat uitloopt qua kosten. Allereerst wordt overwerk, om wat voor reden dan ook, in 40% van de gevallen niet geboekt. Bovendien kiezen ICT professionals er bewust voor om uren niet aan projecten door te berekenen, naarmate het budget meer overschreden wordt. Verliezen worden hierdoor gedeeltelijk door ICT bedrijven zelf genomen en in sterke mate zelfs onzichtbaar gemaakt.
De bovenstaande discussie lijkt gefocust op enkele van de genoemde redenen van falen: a) niet opleveren van alle deliverables, b) technisch niet goed functioneren, c) over budget gaan, en d) niet tijdig opleveren. Dit kan inderdaad veroorzaakt worden door het te goedkoop aanbieden, waardoor er wellicht teveel onervaren consultants op het project komen of er onvoldoende sterk project management is. De inrichting van het koopproces zal hier een invloed op hebben.
Niet alle redenen van falen worden er echter volledig mee verklaard. Het grootste probleem is namelijk niet zozeer het te laat of over budget opleveren van een programma, maar het niet functioneren ervan in de organisatie, hetzij door technische, hetzij door organisatorische problemen. Ook het niet voldoen aan de verwachtingen heeft voor de meeste organisaties een grotere impact dan een budgetoverschrijding.
Interessant is om te kijken hoe dergelijke problemen kunnen worden aangepakt. Eén van de eerste echt uitgebreide onderzoeken naar het falen van ICT projecten was het Chaos onderzoek (1994) van de Standish Group. Zij brachten ondermeer ook de succesfactoren in kaart. De top 5 succesfactoren:
1. User involvement
2. Executive support
3. Clear statement of requirements
4. Proper planning
5. Realistic expectations
De succesfactoren 3 tot 5 kunnen inderdaad deels verklaard worden met het verkooptraject en de verwachtingen die daar geschapen worden. De belangrijkste twee succesfactoren blijken op een heel ander vlak te liggen. Succes wordt in belangrijke mate bepaald door het betrekken van de organisatie in ICT trajecten gedurende het traject.
Eenzelfde probleem doet zich al enige tijd voor in strategie consulting. Slechts 30% (!) van de strategische projecten wordt naar tevredenheid en verwachtingen opgeleverd. En in dit deel van de consulting markt wordt minder dan in ICT op prijs geconcurreerd, zodat daar de oorzaak niet zo makkelijk kan worden gelegd.
De top 5 succesfactoren vertoont overeenkomsten (Leading Strategic Change, 2002):
1. Insufficient mobilisation
2. Inadequate leadership
3. Poor change management
4. Bad team composition
5. Incrementalism (focus on small changes)
Enkele management consulting firms zijn erin geslaagd deze lessen te vertalen naar nieuwe project aanpakken. Deze aanpakken zijn gebaseerd op wat ik noem “co-creatie”. Het onafhankelijke advies, de inhoudelijke analyses en ervaring/expertise van de consultant worden nog steeds ingezet. Maar er wordt ook zorgvuldig gekeken naar wat de organisatie zelf in een project kan en moet inbrengen. In de project design fase is al uitgebreid nagedacht over het betrekken van mensen in de organisatie op verschillende cruciale momenten: om mee te denken, ideeën te ontwikkelen en keuzes te helpen maken. Dit is een zeer doeltreffende manier om resultaten te bereiken en gewoon een betere en in de praktijk werkende oplossing of nieuwe richting te formuleren.
In ICT projecten zal de verhouding tussen de uren in realisatie van systemen en de uren in change geheel anders liggen dan in een strategieproject. Prima. Echter, de isolatie van projectwerkzaamheden en wat er speelt in de organisatie, kan ook hier wel eens te strikt zijn. Met alle gevolgen van dien.
Gerelateerde artikelen
Marketingfacts. Elke dag vers. Mis niks!
Marketingfacts. Elke dag vers. Mis niks!