De vraag die Leon Dohmen in zijn column opwerpt bevat een redenering die niet klopt, maar wel aannemelijk lijkt: er is geen verband tussen het gebruik van IT en het succespercentage de IT-projecten.

Om te beginnen komt er véél méér IT tot stand zónder projectmatig werken, dan mét. Er is wellicht wél een verband tussen IT-uitgaven en gebruik van IT. Een belangrijk verschil.

Er wordt door veel onderzoekers, al vele jaren, melding gemaakt van het aanzienlijke faalpercentage van IT-projecten. In de media worden regelmatig dezelfde onderzoekscijfers over falende IT-projecten gequoot. Het populairst zijn de cijfers uit het jaarlijkse ‘CHAOS’ rapport van de The Standish Group uit Boston, USA en uit de ‘ICT Barometer’ van de Nederlandse tak van Ernst en Young.

Ik heb daar dit jaar een Nederlands onderzoek naar IT-projecten met standaard software aan toegevoegd. De definitie van het falen is (net als de definitie van een IT-project uiteraard) van zeer groot belang. De gevonden faalpercentages lopen sterk uiteen, tot wel twintig procent. De oorzaak ligt in de onderzoeksmethoden en de onderzochte populatie. De verschillende onderzoeksverslagen besteden daar aandacht aan.

De door Leon voorgestelde vingeroefening met rapportcijfers voegt naar mijn mening weinig toe. Zijn claim van 'een meer genuanceerd beeld' is weinig overtuigend gezien de slordige argumentatie.

Beste Leon,
als ik een wasmachine bestel voor een 800 euro, maar tijdens de installatie blijkt dat ik nog eens 500 euro moet bijbetalen aan allerlei gedoe voordat alles werkt, dan voel ik mij behoorlijk bekocht. Ook als het 'gedoe' te maken heeft met de onhandige plaats waar de wasmachine moet staan, of een kraan die het niet doet. Want dat was allemaal bekend toen de leverancier zijn offerte maakte.
En als de leverancier dan zegt "Maar meneer, u moet dat genuanceerd zien, want hij wast wel heel erg schoon" dan zeg ik: "Dat is je geraden ook, want dat had je beloofd, maar waarom zou ik daarom meer betalen dan we hadden afgesproken?"

De getallen over hoeveel projecten nu precies falen doen er niet zoveel toe, het zijn er in ieder geval teveel om zuiver toeval te zijn. Aan de techniek ligt het inderdaad niet. Er is iets fundamenteel mis met de wijze waarop de opdrachtgever en de aannemer 'samen' een opdracht in elkaar zetten, en voor beiden is de verleiding om het verkeerd te doen maar moeilijk te weerstaan.

Ik denk dat rapportcijfers achteraf uitdelen daar niet veel bij gaat helpen, ik denk wel dat het kan helpen als op de zaken die jij noemt VOORAF heel concrete streefwaarden worden afgesproken, en er ook afspraken gemaakt worden over hoe die gerealiseerd gaan worden.
Dan weet je daarna veel beter wat er allemaal goed en fout ging, en wie de extra rekening moet betalen.

Als we dat bij aanbestedingen met (semi) overheidsgeld eens verplicht zouden stellen, hoeveel levert dat dan jaarlijks dat op?

Charles, Nico, dank voor julle reacties. Charles, ik begrijp je opmerking m.b.t .achteraf rapportcijfers uitdelen. De bedoeling is ook dat je deze gebruikt om te achterhalen waarom een resultaat met een 5 wordt gewaardeerd of met een 7. De reden is belangrijker dan het cijfer zelf. Dus deze achteraf cijfers hebben vooral een leerdoel.

Verder wil ik benadrukken dat een IT-project ook maar een middel is om tot resultaat te komen. Waar volgens mij veel meer de nadruk op moet liggen - dat is een belangrijke eerste stap - is doorgronden hoe het samenspel van technologie, organisatie en personen in elkaar zit. Dit vaak ondoorzichtige en verweven samenspel ontleden - de psyche ervan leren begrijpen - krijgt veel te weinig aandacht. Als b.v. een moederconcern een ERP-implementatie wil doorvoeren omwille van het willen verbeteren van de centrale aansturing en het standaardiseren van processen, dan weet je op voorhand al dat autonomie van de locale vestigingen wordt aangetast en dat deze dit niet zomaar accepteren. Als je dit wil aanpakken met een IT-project waarin je alleen maar aandacht hebt voor tijd en geld en de daadwerkelijke problematiek (tegengestelde belangen tussen moederbedrijf en locale vestigingen) van de ERP-implementatie negeert of onderdrukt, dan wordt dat heel lastig zo niet onmogelijk om dit binnen de gestelde (tijd en geld) normen van het IT-project te realiseren.

Er zou dus veel meer interesse moeten zijn in de psyche van het samenspel tussen technologie, organisatie en personen en hoe je hier de juiste invloed op uit kunt oefenen. In het doorgronden van deze psyche zit volgens mij de sleutel tot resultaatverbetering van IT-projecten en niet in het vaststellen dat een IT-project is mislukt en of de opdrachtgever hier schuldig aan is of de projectleider.