Klanten vragen niet naar het aantal mislukte projecten bij een ict-dienstverlener. Als ze dat wel zouden doen, zouden ze wellicht niet met de dienstverlener in zee gaan. Dat concludeert Nico Beenker na 25 interviews met ict-opdrachtgevers, ict-dienstverleners en materiespecialisten. Hij schreef hierover het boek Lead IT or Lose IT. Uit Beenkers onderzoek blijkt dat het ene dienstenbedrijf het andere niet is. Bij de ene faalt 92 procent van de projecten, bij de ander gebeurt dat bijna nooit.
Het verschil in kwaliteit bij de dienstverleners heeft te maken met de bedrijfscultuur van de organisatie. ‘Bedrijven waarbij er sterk toezicht is op de kwaliteit van de dienstverlening doen het beter dan anderen waar dat niet zo is', zegt Beenker.
‘Over het algemeen zijn dat de grote internationale dienstverleners. Bij het doorsnee dienstenbedrijf is er minder aandacht voor kwalitatieve procedures. Er worden vaker dezelfde fouten gemaakt. Er zijn bijvoorbeeld weinig maatregelen om projecten op de rails te houden. Daaraan zie je dat de interne governance niet goed is geregeld.'
Beenker concludeert dat 53 procent van de projecten voor de implementatie van standaardpakketsoftware deels of volledig faalt. 80 procent van de projecten mislukt voordat de informatietechnologie in beeld komt. De problemen worden niet veroorzaakt door technische problemen, maar door onduidelijkheid in de communicatie en het dichttimmeren van alle onzekerheden in het selectie- en implementatieproces.
Definitieverschil
Klant en opdrachtnemer hebben overigens een andere definitie van projectfalen, merkte Beenker. ‘Vaak worden tijdens een project nieuwe afspraken gemaakt tussen klant en opdrachtnemer over meerwerk. De opdrachtnemer houdt vast aan deze afspraken en heeft daarom een veel rooskleuriger beeld van het project. Het project voldeed immers aan de nieuwe afspraken. De klant vindt echter dat de nieuwe afspraak niet het eerste plan was en vindt dat het project is mislukt.'
Het boek Lead IT or Lose IT biedt naast een stuk praktijktheorie en het onderzoeksverslag dertien praktische hulpmiddelen voor het leiden van projecten voor de implementatie van standaardpakketsoftware.
Helaas geen heldere definitie want men nu verstaat onder “falen”. Dus blijft het een beetje gokken wat er nu bedoeld wordt.
Het wordt wel duidelijk dat business en ICT nog bij lange na niet voldoende op elkaar zijn afgestemd om samen tot een succes te komen. Maar zo zit het contract vaak ook niet in elkaar, dus beide partijen oogsten vaak wat ze zaaien.
Tsja, een nieuwe vriendin vraag je tenslotte ook niet zo gauw naar het aantal van haar mislukte vorige relaties.
Hoe wil je de reputatie achterhalen? Aan de dienstverlener hoef je niet om referenties te vragen. Die zal de “slechte” projecten niet aangeven. Forums of dergelijke worden veelal alleen gebruikt om slechte ervaringen kwijt te kunnen. De goede ervaring kunnen door eigen medewerkers geplaatst zijn. Dus is het wellicht geen onwil om de reputatie te controleren maar weet men niet hoe of waar.
Wat wij heel vaak zien in deze, is dat er niet op een adekwate manier wordt gecommuniceerd, men begrijpt elkaar verkeerd, of er worden verwachtingen geschept die zo niet worden uitgevoerd.
veel ellende kan worden bespaart met een goede coaching tussen beide partijen die de klant begrijpt en de programeur vertaalslag kan maken.
@ Anko, jouw opmerking is terecht. Wat is falen? Wat is een project? et cetera. Wij hebben alleen het falen (te laat, te duur, of geheel afgebroken) van projecten met standaard software onderzocht. IT-leveranciers zijn instaat deze cijfers uit de eigen organisatie op te lepelen.
Ik vind de laatste constatering het meest verbijsterend: “Klant en opdrachtgever hebben overigens een andere definitie van…”
Dit is in veel organisaties het grootste probleem maar wordt blijkbaar weinig meer herkend. Hoe is het mogelijk dat klant en opdrachtgever niet dezelfde persoon/groep is? Hoe is het mogelijk dat dit volslagen gebrek aan gezond verstand zo geaccepteerd is?
Heel herkenbaar, volgens mij is ongeveer een jaar geleden Moret tot vergelijkbare cijfers gekomen voor IT projecten in het algemeen, iets positiever geformuleerd namelijk ca 50% van de projecten wordt als succesvol gezien, daarmee dus de rest niet… Definitie van succes en falen is vaak arbitrair, wat overigens vooral komt omdat organisaties vooraf helemaal niet denken in termen van succes. Het is vaak lastig om de essentie van een project te achterhalen, meerdere stakeholders hebben eigen, niet altijd synchrone, doelen. Procesverbeteringen, performance verbetering, “koppen”reductie, “de nieuwste versie”, iedereen kan er wel een paar verzinnen. De PID heeft lang niet altijd uitsluitsel en een business case geeft vaak een eenzijdige, en niet zelden ten faveure van goedkeuring gemanipuleerd beeld.
Ik probeer om bij de start van een project overeenstemming te krijgen over wat de criteria zullen zijn om een bepaald project geslaagd te noemen. Dat kost tijd, discussie en som frustratie, maar het helpt niet alleen om vast te stellen of er succes is (dat is voor de statistiek) maar ook om tijdens het project makkelijker de noodzakelijke keuzes te kunnen maken of compromissen te sluiten. Tot op zeker hoogte is succes dus een keuze (vooraf).
Zou de klant vooral eens naar de cowboy-intermediair moeten kijken hier in nl. Komen ze weleens bedrogen uit, vrees ik !
Dit artikel is een beetje te kort door de bocht. Opdrachten die zonder nader onderzoek op de golfbaan zijn vergeven kom je heel zelden tegen. De grote dienstverleners en grote klanten kennen elkaar sowieso al vele jaren en doen regelmatig aan evaluatie. Verder ik heb nog nooit een opdrachtgever ontmoet die niet geïnteresseerd is in de reputatie van de dienstverlener, zelfs niet bij opdrachtgevers die de ICT slecht geregeld hadden.
Ook is de reputatie van elke dienstverlener van enige omvang heel gemakkelijk te achterhalen. Probleemgevallen staan bijvoorbeeld op het internet. Even contact zoeken met die klanten en leveranciers om te vragen hoe de problemen opgelost zijn (zonder te vragen wie de problemen veroorzaakt heeft) en je krijgt heel veel nuttige informatie. Ook van de opgegeven referenties kan je veel nuttige informatie krijgen. Waarom is die referentie positief? Waarom ging het toen goed?
Over blijft het punt van verschillen in definities. Daar gaat het vaak mis, ook binnen de partijen zelf. Een goed kwaliteitssysteem kan hier veel communicatieproblemen voorkomen. Conclusie; de klant controleert de reputatie van dienstverlener misschien niet altijd even goed, maar het probleem zit in de communicatie. Dat probleem is niet onderkende cultuurverschillen, een andere perceptie van wat belangrijk is en onvoldoende commitment bij partijen om helder te communiceren over wat hen zou moeten binden.
Redactie, bij de relatie klant – leverancier of opdrachtgever – opdrachtnemer, heb ik wel een beeld. Maar wat is het bedoelde verschil tussen klant en opdrachtgever?
“Bij de ene faalt 92 procent van de projecten, bij de ander gebeurt dat bijna nooit.” “Bedrijven waarbij er sterk toezicht is op de kwaliteit van de dienstverlening doen het beter dan anderen waar dat niet zo is.”
Een eenvoudig advies luidt dan ook: Vraag uw dienstverlener naar de resultaten van zijn 3 laatste projecten en controleer deze resultaten bij de opdrachtgevers. Heb je 3 ontevreden opdrachtgevers dan heb je een dienstverlener die niet leert van zijn fouten en kennelijk ook geen maatregelen neemt om herhaling te voorkomen.
Het gaat om het vastleggen van heldere afspraken, nakomen van beloften en het sturen van verwachtingen. Een goede dienstverlener levert volgens afspraak, binnen de afgesproken doorlooptijden, binnen budget en overtreft de verwachtingen van de opdrachtgever.