10 manieren om ICT-projecten te doen falen
Dominiek | donderdag 26 april 2007

In informatica-termen klinkt “5 jaar geleden” als een eeuwigheid: de meeste PC’s hadden toen nog geen DVD-lezers, nu is een DVD-schrijver al bijna standaard, van on-line filmpjes was er nauwelijks sprake, als ik mij niet vergis was zelfs breedband-internet toen nog maar nauwelijks in de huiskamers doorgedrongen en surften de meeste Belgen toen nog met een ouderwetse modem.

Inmiddels is het ook 5 jaar geleden dat Anthony Zecca, consultant bij de Cohn Consulting Group, zijn column “Broken Dreams – Why do so many IT projects fail to deliver on their expected values?” publiceerde. In tegenstelling tot het eerder vermelde, is deze column en de aangehaalde faalredenen nog steeds brandend actueel…

Heel veel bedrijven, werknemers, directies, non-profit-organisaties, overheidsdiensten en zo meer worden soms of regelmatig geconfronteerd met ICT-implementaties die niet geslaagd zijn of niet lijken te slagen. Waardoor men al even vaak met veel graagte op de pianist gaat knallen: een planningspakket dat niet binnen de bedrijfsgewoontes blijkt te functioneren, een juridisch systeem dat nog steeds niet werkt – ook al heeft de overheid er al miljarden in gepompt, een ERP-pakket waarmee het uren duurt om een correcte factuur te genereren, … Gebruikers geraken gefrustreerd, het systeem wordt binnen de kortste keren als ontoereikend bestempeld; de analist, programmeur of implementeerder fungeert steevast als zondebok van dienst.
En dat is nou net vaak het probleem: een ICT-oplossing wordt vaak als een soort van minuut-soepken gezien: we hebben snel een oplossing op probleem x nodig, dus zorg eens voor een informatica-oplossing. Which is wrong. IT is zelden of nooit een oplossing op zich, informatica is enkel bedoeld om oplossingen te faciliteren, te automatiseren, te laten verlopen zonder dat er exhaustief veel extra mankracht nodig is.
Computers zijn gemaakt om bepaalde zaken sneller, automatischer en correcter te kunnen [informatie opzoeken, gegevens vergelijken, berekeningen uitvoeren, opgemaakte documenten genereren en uitspugen] uitvoeren en zijn zelden een instant-oplossing voor fundamentele organisatorische problemen, een gebrek aan gestructureerde denk-/werkmethodes. Gebreken en gemis moeten eerst inhoudelijk en procedureel uitgedacht en opgevangen worden, pas daarna kan en mag beroep gedaan worden op informatie- en communicatietechnologie om de betreffende oplossingen te (helpen) implementeren.

Dit laatste lijken heel wat mensen zich niet te realiseren, al behelst dit ook een zeer grote taak en bevoegdheid voor directies en CEO’s. Zecca schreef dan ook dat IT-projecten in 90% van de gevallen falen omwille van 10 duidelijke redenen en dat het net vaak de functie is van CEO’s, influencers, leidinggevenden, beslissingsnemers en zaakvoerders om zich van deze zaken bewust te zijn…

1. ICT wordt vaak beschouwd als een oplossing op een organisatorisch probleem, in plaats van als een instrument dat gebruikt kan worden om een oplossing te implementeren.
Informatica en communicatietechnologie kan een ongelooflijk sterk instrument zijn om processen en logica te stroomlijnen. Maar dit behelst wel dat de betreffende processen en logica moeten bestaan: op problemen moeten er eerst [zo waterdicht mogelijke] oplossingen en procedures bedacht worden, pas daarna kunnen die ook daadwerkelijk geautomatiseerd worden.

Indien een stock slecht beheerd wordt en de mensen maken geen tijd om de werkelijke stockgegevens ook op papier of in een systeem bij te houden, dan kan er niet verwacht worden dat een computeroplossing op het correcte moment zal laten weten dat een stockbreuk dreigt of behoort een FIFO-beheersysteem niet tot de mogelijkheden.
“We slagen er niet in om orders of planningen op correcte wijze te verwerken, zorg eens voor een IT-oplossing,” is dan ook vaak al de verkeerde vraagstelling. Als men verzuipt onder een teveel aan gegevens of berekeningen en die wenst men te automatiseren, kan ICT wel van nut zijn; indien men echter van begin af aan niet goed weet waar men precies naar toe wil, is de kans groot dat er IT-matig een verkeerde oplossing geïmplementeerd wordt. Correcte behoeftenbepaling is op dat vlak a priori een absolute must.

CEO’s moeten dan ook ten volle het organisatorische basisprobleem begrijpen en zien te achterhalen hoe technologie kan helpen om dit weg te werken, maar evenzeer is het belangrijk in deze fase de niet-technologische aspecten van het probleem te achterhalen en werknemers te dwingen om de juiste regels te volgen. Enkel die regels kunnen geautomatiseerd worden.

2. Zonder een eenduidige en rechtlijnige strategie, zal IT nooit hulp kunnen bieden aan een bedrijf om haar missie te verwezenlijken.
CEO’s moeten eerst met hun team een duidelijke strategie uitwerken en dan evalueren in welke mate technologische mogelijkheden kunnen helpen om deze strategie ook daadwerkelijk uit te voeren, in plaats van technologie te beschouwen als “één van de vele overhead/kostenposten”.
De kracht van ICT komt pas tot uiting binnen een totaalstrategie, niet als technologisch gegeven op zich.

3. Topmanagers beshouwen IT-systemen en -projecten te vaak als “plug and play”-oplossingen en staren zich te vaak blind op de enorme moeite die nodig is om elke IT-oplossing effectief en efficiënt te implementeren.
Moeite, werk, inzet en mankracht zijn verschrikkelijk belangrijk bij elke implementatie op informatica-vlak. Vaak is het de bedoeling dat een ICT-oplossing ervoor zal zorgen dat de werkdruk afneemt en dat een heleboel routinezaken door computers i.p.v. door mensen uitgevoerd gaan worden. Dit is echter vaak pas de finale fase van een automatiseringsproject en voor men zo ver is, moet er wel degelijk op ernstige wijze geïnvesteerd worden in mankracht om die oplossing tot een goede implementatie te brengen.
De implementatie van informatiesystemen behelst vaak significante investeringen van HR resources, te vaak zien bedrijfsleiders part-time-investeringen als voldoende: “werk aan dit project als je er eens eventjes tijd voor hebt”.
Dit werkt niet. Dit kan niet werken.

4. ICT professionals zijn vertalers-tolken: zij moeten de wensen van de gebruikers op de juiste manier begrijpen, vertalen naar automatische oplossingen en de illusie van “de zilveren ICT-kogel” in de kiem smoren.
IT professionals moeten beseffen dat het de gebruikers zijn die informatica doen werken, niet de IT professionals zelf. Daarom is er nood aan een cultuur waarin informatici en gebruikers zich als partners beschouwen en gedragen.

CEO’s moeten die partnerschap ondersteunen en faciliteren. Een zeer goede manier hiervoor, is de samenstelling van een IT-stuurgroep die bestaat uit gebruikers, techneuten en directieleden. Op die manier zou communicatie, begrip en flexibiliteit tussen de kritische elementen (IT en de gebruiker) beter mogelijk gemaakt moeten kunnen worden.

5. “Zilveren kogels” bestaan niet, in tegenstelling tot wat beide partijen mogen vermoeden.
Er zijn nooit eenvoudige, eendimensionele basisredenen voor organisatorische problemen en er zijn al evenmin eenvoudige, eendimensionele oplossingen.
Zolang zowel gebruikers als IT blijven werken onder de absolute overtuiging dat automatisering het probleem zal oplossen (IT perspectief) en dat informatica niets meer is dan weggesmeten geld dat alleen maar overlast veroorzaakt (de kant van de gebruiker), zal het nooit werken.
CEO’s moeten er voor zorgen dat IT naadloos binnen hun bedrijven geïntegreerd wordt en dat beide partijen duidelijk beseffen dat informatica een noodzakelijke component is om tot een uitmuntend bedrijfsmodel te komen.

6. Er zal altijd weerstand zijn vanwege gebruikers die ICT steevast als een bedreiging voor hun job beschouwen en die daarom elke seconde redenen blijven uitvinden waarom het niet werkt (in plaats van er zelf te helpen voor zorgen dat de ICT-oplossing daadwerkelijk helpt).
CEO’s moeten vanaf de eerste seconde rekening houden met dit mentaliteitsprobleem. Als er inderdaad jobs zullen sneuvelen door nieuwe systemen en IT-projecten, moet daar vanaf het begin open over gecommuniceerd worden, zodat mensen wiens job niet in het gedrang komt ook een gevoel van veiligheid hebben.

7. Het is moeilijk om IT-voordelen naar cijfers om te zetten om aldus een ROI te kunnen berekenen, alvorens er enige investering gedaan is.
Dit is een zeer groot probleem, aangezien veel voordelen van automatisering niet in zwart/wit-termen uitgedrukt kunnen worden. Veel te vaak ontwikkelen IT-verantwoordelijken gefundeerde en overdachte ROI-analyses en in het grootste deel van de gevallen, duurt de implementatie langer, kost het meer en kunnen bepaalde beloofde kleine lettertjes nooit gerealiseerd worden.

CEO’s moeten aandringen op realistische ROI-modellen die zowel getest als opgevolgd kunnen worden. Ook moet er door de directie een aanvaardbare payback-periode gedefinieerd worden, liefst los van de “reeds geschatte payback-periode”. Als realistische veronderstellingen niet beloofd kunnen worden door de IT-projectleider, kan men beter niet tot investering overgaan.

8. Je kan geen BMW verwachten voor de prijs van een Honda
Bedrijfsleiders en directie moeten begrijpen dat ze enkel krijgen waarvoor ze [bereid zijn te] betalen. CEO’s en budgetverantwoordelijken zijn vaak de grootste schuldigen in deze materie, omdat ze vaak gaan eisen dat het IT-systeem alles kan, waarna ze beperkingen gaan opleggen op vlak van budget en middelen, zowel wat het informaticaproces als de professionals zelf betreft. Hierdoor zijn projecten vaak bij voorbaat gedoemt de falen.

Een Honda zal nooit een BMW zijn, hoe graag je dat ook wilt of hoe goed de chauffeur ook is.

9. Een duidelijk begrip van wat de IT-oplossing nu precies allemaal zal moeten kunnen doen, ontbreekt meer dan vaak.
Hoe simpel het ook moge klinken, één van de hoofdredenen waarom IT-investeringen falen, is omdat men op voorhand geen tijd, werk en analyse gespendeerd heeft om op duidelijke wijze in kaart te brengen welke organisatorische pijnpunten en verwachtingen er door de ICT-oplossing ingelost moeten worden.

Het is niet voldoende om te zeggen : “We hebben nu een goed planningspakket nodig”. De vraag is: aan welke verwachtingen moet dit pakket tegemoet komen, wat moet men er mee doen en hoe wil de directie concreet dat dit pakket werkt en gebruikt wordt.

In heel wat CRM-pakketten, bijvoorbeeld, kan een “persoon” in een “categorie” gestoken worden (bv. verkoper, klant, persoonlijke vriend, …). Maar soms is het belangrijk dat het management zich vervolgens gaat afvragen of een persoon niet in meerdere categorieën moet kunnen zitten, of die van categorie kan veranderen, op welke manier dit moet gebeuren of op welke manier welke regels in deze optiek afgedwongen moeten (kunnen) worden. CEO’s moeten de gebruikers aandringen om al hun verwachtingen en wensen in een A/B/C-structuur te gooien, waarna dit vooropgestelde model door de ICT-implementatoren afgetoetst moet worden om de mogelijke technologische oplossingen voor het bedrijf te evalueren.

10. Onterecht denken we te vaak “dat we uniek zijn”.
Dit is de strijdkreet die heel wat IT-projecten vaak bij voorbaat de vernieling in helpen en die tot grote frustraties en niet-ingeloste beloftes leidt. Op vandaag bestaan er zeer veel goede IT-technologieën en voor elke mogelijke vraag bestaan er heden meerdere mogelijke standaard-oplossingen. CEO’s moeten dan ook een systematische projectmethodologie afdwingen, waarmee op objectieve wijze bedrijfsbehoeften afgetoetst kunnen worden tegen bestaande technologische oplossingen op de markt. Vaak is het beter op zoek te gaan naar een goed huwelijk tussen deze twee factoren, dan steevast het wiel opnieuw te willen uitvinden, “maar dan wel het wiel dat het best bij onze gewoontes past”.

De meeste bedrijfsvereisten zijn alles behalve uniek; eerder zijn het gewoontes, policies en de bedrijfscultuur die uniek zijn (maar deze zijn vaak veel beter en makkelijker om te smeden).

Los daarvan: ICT-projecten begeleiden blijft elke dag een strijd. Tegen de vooroordelen, verwachtingen, ontevredenheid van de mensen die er ooit mee zullen moeten werken. Zelden vinden positieve signalen omwille van automatisering hun weg terug naar de implementatoren; vaak – héél vaak – bereiken wel alle negatieve opmerkingen en hun echo’s de betreffende dienst. Ook daar moet men zich bewust van zijn.
IT Professional? Het is de ideale suïcidale uitvalsbasis voor mensen die worstelen met een gebrek aan zelfzekerheid!


Trackback URL naar dit artikel : http://dominiek.be/2007/04/26/10-manieren-om-ict-projecten-te-doen-falen/trackback/

2 reacties op “10 manieren om ICT-projecten te doen falen”

  1. Robin sprak :

    Ja, ik kan jou (of Anthony) enkel maar gelijk geven in dit alles, al zit ik wel in een veel kleiner bedrijf dan jij. Vaak krijg ik tijdens een vergadering onverwacht de vraag: “We willen op dat formulier nog een knopje hebben die dit en dat doet. Robin, hoelang duurt dat om te maken?”. En dan moet je daar direct een tijdsduur op kunnen plakken. Enfin, zelfs als je denkt het te weten, komt er achteraf gezien nog altijd veel meer bij kijken dan je in eerste instantie dacht. (want als dat verandert moet dat, en dat, en dat ook nog aangepast worden).

    Ik had vroeger een manager die dacht “een kolom aan een tabel in een databank toevoegen: dat is 2 minuten werk”, of “en als die record niet moet getoond worden, dan maken we gewoon een yes/no kolom bij in de tabel, dat is zo gedaan.”

  2. links for 2007-04-26 » The Gryphin Experience sprak :

    [...] 10 manieren om ICT-projecten te doen falen Dominiek slaat de nagel op de kop over waarom er zoveel IT projecten falen of er zoveel discussie is tussen klant en leverancier… (tags: IT) [...]

Laat een reactie achter !

XHTML: Je kan de volgende tags gebruiken : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>