Ruim de helft van de ict’ers vindt dat klant en dienstverlener evenveel schuld dragen aan het falen van ict-projecten. Dat blijkt uit Computables jaarlijkse onderzoek naar ict-dienstverlening. Het onderzoek, waaraan bijna tweeduizend ict-managers en -professionals deelnamen, werd uitgevoerd door TNS Nipo. Slechts zeventien procent van de respondenten legt de schuld van projectfalen bij de dienstverlener. Elf procent legt hem bij de klant.
Als het gaat om de vraag wie de schuld heeft aan het mislukken van ict-projecten, zoeken ict'ers het antwoord het liefst in het midden. Dat blijkt uit Computables jaarlijkse onderzoek naar het imago van ict-dienstverleners dat door TNS Nipo is uitgevoerd onder bijna tweeduizend ict'ers.
52 procent van de respondenten antwoordt ‘Beiden dragen evenveel schuld', op de vraag ‘Wie draagt volgens u over het algemeen de meeste schuld aan het mislukken van ict-projecten?' Sommigen respondenten gaven op hun antwoord ook nog een toelichting, zoals ‘Zwartepieten heeft geen zin, er speelt een complex aan factoren' en ‘Waar er twee kijven hebben er twee schuld'.
Zeventien procent legt de schuld van mislukkende ict-projecten primair bij de ict-dienstverlener. Elf procent legt hem juist bij de klant. Zoals één van de respondenten zijn antwoordt toelicht: ‘De verwijtende vinger wijst meestal naar de uitvoerende partij, terwijl de oorzaak in mijn ogen vaak (zeventig procent) een interne organisatorische aangelegenheid is.'
Twintig procent heeft geen mening over dit onderwerp. Het volledige onderzoek is terug te vinden in de ICT Services Guide 2009.
ICT SERVICES GUIDE 2009
Het jaarlijkse onderzoek maakt deel uit van de ICT Services Guide 2009. In opdracht van Computable voerde TNS Nipo het onderzoek in februari en maart uit onder 1913 ict-managers en ambitieuze ict-professionals.
In de gids, die op 15 mei verschijnt, worden onder andere per topic rapportcijfers gegeven voor dienstverleners die actief zijn in dat ict-deelgebied. Respondenten konden per topic alleen de bedrijven waarderen waarmee ze daadwerkelijk ervaring hadden opgedaan. Ook werden de respondenten algemenere vragen en stellingen voorgelegd.
En het falen van de grafiekjes bij de artikelen de laatste tijd, wie z’n schuld is dat?
De taartpunt van 20% < 11% en 52% komt meer in de richting van 66%.
Ongelooflijk dat grafiekje! 🙂
Maar uhm, het falen van ICT projecten zit hem vaak in het onderschatten van de complexiteit en de schaal van het project. Daarbij komt dat er pas vaak in het midden van een project duidelijker richtlijnen worden gesteld voor wat betreft verantwoordelijkheden en doelstellingen.
Er is een vraag/behoefte -> vaak reageert IT door meteen oplossingen aan te leveren. Er wordt te weinig aandacht besteed aan de projectplanning en formulering van de doelstellingen in het algemeen. Gemiddeld lopen er een projecten spaak omdat er wel over na wordt gedacht wanneer zaken mis dreigen te gaan. Vaak is het dan te laat.
@tommie: Bekend en kloppend verhaal, alleen is dat imho een beetje achterhaald aan het worden. Ondertussen zijn het juist de dienstverleners die extra veel aandacht en tijd in de projectplanning, scope, doelstellingen etc. steken. Alleen is het vaak de opdrachtgever die daar weer keihard doorheen fiets na een maand of 2.
Tuurlijk kan je dan terugwijzen op de originele projectdefinitie maar uiteindelijk wil je als dienstverlener ook gewoon de opdracht blijven houden, dan maar met wijzigingen. Dan gaat de beerput open en gaat het vaak mis.
De kop zou moeten zijn: Falen van ICT-projecten is beider schuld. Niemands schuld zou betekenen dat niemand aangesproken hoeft te worden.
Beide partijen maken fouten. Waar het vooral fout is gegaan, dat verschilt uiteraard per project. Bij grote langdurige projecten is dit moeilijk te bepalen zonder auditing of evaluatie per projectfase.
Bekijk bij problemen samen wie het ontstane knelpunt zou kunnen helpen oplossen, dit ongeacht wie de verantwoordelijkheid draagt.
Computable: kloppen de cijfers niet of klopt het plaatje weer eens niet?
@Kevin
Was ook een beetje gestoeld op interne projecten. Voor ‘aannemers’ is het weer anders… Maar toch valt het wel te verkopen een project ‘strak’ te regelen / in te steken. Uiteindelijk draait het 9 van de 10 keer gewoon om euro’s.
In dit artikel is de simpelheid troef.
In het gros van de projecten wordt er over het algemeen gepland op niet teveel kosten maken zodat je de opdracht binnen haalt. Vervolgens wordt er te weinig tijd om het ontwerp per component voldoende compleet te maken. Bij voorkeur wordt de bouw en implementatie al gestart als de ‘requirements’ zijn verzameld. Tijdens de bouw komen de lacunes in het ontwerp naar boven die dan 3-5 keer zoveel tijd kosten om op te lossen. Worden de lacunes genegeerd dan komen ze alsnog naar boven tijdens het testen en dan kost het corrigeren 5-10 keer zoveel.
Dat staat nog los van het gaan voor de goedkoopste aanbieding door de opdrachtgever, het doen van veel te lage aanbiedingen door opdrachtnemers, het al te rigide volgen van de gekozen ‘IT-methode’, het zich voordoen als ‘architect’ van de diverse IT-aannemers en het inzetten van personeel met onvoldoende skills.
Elk project heeft zo zijn eigen merites en succes- en faalfactoren. Elke betrokkene heeft kans om daarvan te leren en het de volgende keer beter te doen. Dit artikel voegt daar heel weinig aan toe, mogelijk dat het onderzoek zelf wat dieper graaft.
Als je het aan de projectmanager vraagt zou het er wel eens op neer kunnen komen dat het aan de opdrachtgever ligt. Wordt een opdracht uitgevoerd ZONDER wijzigingen tussendoor en ZONDER dat er stelposten in de opdracht zitten, dan geef ik het een goede kans dat het aantal projecten dat faalt heel erg veel minder is.
Naar mijn mening is het belang van de leverancier vaak niet het belang van de klant. Teveel wordt er welliswaar gewerkt met een initiele planning maar is het zelfs in het belang van de leverancier om deze NIET te halen, meer uren is namelijk meer euro’s… Wat duidelijk is is dat geen enkel project zonder wijzigingen wordt geaccepteerd, ongeacht voor welke klant het project wordt uitgevoerd. We hebben namelijk geen methode waarin we eenduidig de requirements/specificaties kunnen vastleggen in een taal die zowel de klant als leverancier begrijpt en niet kan misverstaan. Daarnaast veranderd de wereld, wat vooral bij langdurige projecten voelbaar is. Waarom verwachten we dan nog steeds dat we door het opstellen van specificatie en de bijbehorende planning, het geheel in beton kunnen gieten en dan op planning kunnen werken? Uiteindelijk zullen wij als ITers dus moeten komen met een aanpak die planmatig is maar wel met de bekende wijzigingen om kan gaan, ondersteuning vanuit de klant is onontbeerlijk.