Opdrachtgever grootste risico bij IT-projecten

Dat IT-projecten vaak mislukken is bekend. Maar dat eindverantwoordelijke opdrachtgevers meestal zélf verantwoordelijk zijn voor de problemen, veel minder. Het mislukken van projecten gaat vaak gepaard met vage en steeds veranderende doelen, of met een stevige managementaanpak die roet in het eten gooit. Eindverantwoordelijke opdrachtgevers laten het afweten maar in de praktijk valt dit nauwelijks op. Sommige gerenommeerde IT-bedrijven maken hen het uitglijden ook wel erg gemakkelijk.

IT in organisaties is tegenwoordig méér en méér confectiewerk. IT-systemen worden steeds minder gebouwd: men koopt en implementeert standaardsoftware. Keuze is er te over. Een manager die een ERP-pakket moet selecteren en in de eigen organisatie laat implementeren, heeft daar meestal weinig ervaring mee. Een directeur van een zorginstelling die aan de slag gaat met een veelbelovend ZIS (Ziekenhuis Informatie Systeem) al evenmin. Gebrek aan ervaring leidt tot onzekerheid. Er heerst onder businessmanagers een hardnekkig misverstand dat je van IT verstand moet hebben om als projectopdrachtgever goed te kunnen functioneren. Bovendien zijn IT-projecten door hun bedenkelijke reputatie niet erg populair onder eindverantwoordelijken. Ze worden gezien als kostbaar, lastig te beheersen, risicovol en detaillistisch. ‘Van IT-projecten heb ik géén verstand en dat wil ik gráág zo houden’ is een veelgehoorde grap onder managers. Het opdrachtgeverschap wordt daarom maar al te graag overgelaten aan iemand met ‘verstand van zaken’: een IT-specialist of een gedelegeerd opdrachtgever. En daar gaat het mis. Op het moment dat je de doelstellingen te laag in de organisatie laat formuleren of laat uitwerken, moet je niet verbaasd zijn dat deze te technisch of te instrumenteel zijn en voor een goede projectbesturing niet geschikt. In de projectchaos die daarna ontstaat, valt het bijna niemand op dat inadequaat opdrachtgeverschap de kernoorzaak is.

Vijfenzestig miljoen en vijf jaar levert nagenoeg niets op

De afhoudende houding van het businessmanagement en het slecht georkestreerde opdrachtgeverschap is de belangrijkste faaloorzaak van pakketimplementaties. Het onderzoek bevestigt dat meer dan de helft (53%) van de IT-projecten met standaardsoftware deels of volledig faalt. Vier van de vijf falende projecten falen vóórdat de informatietechnologie in beeld komt. Het falen wordt niet veroorzaakt door technische problemen, maar vooral door onduidelijkheid in de communicatie en -zeer belangrijk- het dichttimmeren van alle onzekerheden in het selectie- en implementatieproces. Zelfs de doelen van een project zijn vaak niet eens duidelijk. In het onderzoek is er bijvoorbeeld sprake van een volledig falend IT-project dat oorspronkelijk op ruim vijftig miljoen Euro was geraamd. De doelstellingen van dit project bleven lang onduidelijk. Een betrokkene zei daarover: "Het eerste jaar was de doelstelling ‘het uitfaseren van bestaande ICT-systemen’. Daarna werd het doel ‘meer procesmatig werken’ en uiteindelijk werd het doel ‘klantwaarde’. Bij de laatste wijziging van het doel sloeg het weer helemaal door naar het nastreven van businessdoelen en werd de ICT weer vergeten. Daarom is het nooit echt goed van de grond gekomen. De eerste businesscase was een goede businesscase. Die was ook positief, alleen parallel gingen er reorganisaties lopen. Door deze reorganisaties werden de besparingen die in de businesscase stonden al gerealiseerd. Na drie jaar werd er weer een nieuwe businesscase gemaakt. Toen was de businesscase negatief omdat de creditkant deels al was gerealiseerd. Vervolgens werd er gezegd, het is toch wel noodzakelijk om het te doen, dus laten we het maar doen."

Typerend is dat het doel van dit kolossale project eerst in ‘IT-termen’ beschreven is: ‘het uitfaseren van bestaande ICT-systemen’. Daarin loopt men vast. Vervolgens grijpt men terug naar het doel van de IT-systemen en wordt het projectdoel: ‘meer procesmatig werken’. Maar ook dat levert niet de gewenste voortgang op. IT-dienstverleners en programmamanagers lopen steeds opnieuw vast. Koppen rollen daar waar de chaos het grootste is: op uitvoerend niveau. Nog één ultieme poging. Het doel wordt (het nog abstractere) ‘klantwaarde’. Wederom loopt men vast. In dit project werd dus jarenlang letterlijk gependeld tussen IT- en businessdoelstellingen zonder dat men elk van de twee definitief op zijn plek kreeg. Het project werd na vijf jaar en het spenderen van een ‘vertrouwelijk’ bedrag (van rond de 65 miljoen) gestaakt. Honderden mensen werkten jarenlang aan iets dat uiteindelijk  nagenoeg niets opleverde. Het is een hilarisch en zeer kostbaar voorbeeld van volkomen falend IT-opdrachtgeverschap dat de kwalificatie mismanagement met glans verdient, maar onopgemerkt blijft.

IT-opdrachtgever laat het gebeuren

Uit het onderzoek blijkt dat in 40% van de faalgevallen de projecten al tijdens de offerte/contractfase en daarop volgende definitiefase misgaan. Nog eens 40% van de faalgevallen ontstaan tijdens het ontwerpen van de specifieke toepassing van het standaardpakket. Globaal blijkt dat zo’n vier van de vijf falende IT-projecten falen vóórdat er met de technische realisatie gestart wordt.

De ondervraagde opdrachtgevers ervaren het moment van falen geheel anders. Zij zijn vrijwel allemaal van mening dat falende projecten pas tegen het einde in de problemen komen: tijdens het testen en bij de ingebruikname van de standaardsoftware. Dit verschil in perceptie van het moment van falen is misschien wel begrijpelijk omdat voor een opdrachtgever het projectresultaat pas echt concreet wordt wanneer systeem getest wordt. Maar het betekent ook dat de opdrachtgever niet in control was. Je mag in elk geval de conclusie trekken dat het samenwerkingsproces gedurende de voorbereidende-, ontwerp- en ontwikkelfase(n), tijdens welke de opdrachtgever tussenresultaten accepteert, kennelijk voor een opdrachtgever onvoldoende voorspellende waarde heeft voor het projectresultaat. Het opdrachtgeverschap schiet dus tekort. Er blijkt veel te weinig aandacht te zijn voor de samenhang tussen de bedrijfsvoering en de IT. Dit komt in het onderzoek tot uiting bij het gebrekkig richten van het project. Vooral door geen businesscase te maken, of deze niet te gebruiken voor de projectbesturing. Daarnaast is het gebrekkig of helemaal niet hanteren van op de business gerichte acceptatiecriteria een typisch voorbeeld van inadequaat IT-opdrachtgeverschap. Ook het sluiten van een onevenwichtig contract voor het verlenen van de IT-diensten is een belangrijk faalsymptoom. Eindverantwoordelijke opdrachtgevers geven dikwijls opdracht het proces juridisch helemaal dicht te timmeren, hetgeen een goede samenwerking frustreert. Opdrachtgevers laten vaak na de juiste vragen te stellen. Ze zijn daardoor niet effectief in het bewaken van de voortgang van een project. Het gevolg is dat opdrachtgevers pas 'merken' dat het project gaat falen op het moment dat het IT-systeem is ingericht en wordt getest. Dan blijkt het systeem misschien technisch wel te functioneren (het is immers standaardsoftware), maar niet aan de behoefte van de organisatie te voldoen. Het IT-systeem staat dan scheef op de operatie: het is niet of onvoldoende bruikbaar in de werkprocessen. Voor bijsturen is het te laat omdat het geld al is gespendeerd. Het falen is een feit.

Eerste faaloorzaak: een vaag en steeds veranderend doel

Wanneer we wat dieper ingaan op de oorzaken, blijkt een vaag en steeds veranderend doel één van twéé monumentale faaloorzaken te zijn, die beide zijn terug te voeren op de gebrekkige invulling van het opdrachtgeverschap. Maar hoe kan een project nu vage en steeds veranderende doelen hebben? De oorzaak zit dikwijls in de manier van denken en werken, in combinatie met afwezig leiderschap. IT’ers zijn geneigd IT-projectvoorstellen te doen die bij aanvang een onduidelijk of globaal doel hebben, omdat ze erop vertouwen dat ze het doel van het project gaandeweg zelf kunnen verhelderen. Dit van ‘grof naar fijn’ werken ziet men als een gangbaar onderdeel van de projectmatige IT-aanpak. Projectdoelen kunnen volgens veel IT'ers vooraf slechts globaal worden vastgesteld en worden daarna in het project uitgewerkt. Dit klinkt logisch en overtuigend. Het probleem hierbij is dat betrokkenen niet zelden hun eigen vermogen overschatten om de ontwikkelingen in de door hen zelf bedachte (en zinnig geachte) richting te kunnen sturen. Dat lukt zonder de hulp van het top-businessmanagement vaker niet dan wel. Het opdrachtgeverschap wordt vaak naar een te laag niveau gedelegeerd, zodat er een gebrek aan overzicht en zeggenschap is. De praktische obstakels die de IT'ers op hun weg aantreffen komen meestal pas in de tweede helft van het project op tafel. Ze kunnen allerhande vormen aannemen: de noodzakelijke afstemming tussen business en IT lukt niet, de IT-architecten van het hoofdkantoor werken niet mee, de achterliggende strategie is niet duidelijk zodat men niet weet wat men wil, het softwarepakket deugt niet, de infrastructuur is ongeschikt of nog niet klaar, afdelingsmanagers willen alleen maar tegenwerken, of hebben steeds maar nieuwe wensen, et cetera. Eindeloos doormodderen is vaak het gevolg. Wat er in feite als kernoorzaak onder zit, blijkt een slechte project governance en onduidelijke doelen bij de aanvang. Alle respondenten in het onderzoek, dus de opdrachtgevers, de opdrachtnemers, de geïnterviewde specialisten én de geënquêteerde projectbetrokkenen geven dit als voornaamste reden voor het falen. In de online enquête bijvoorbeeld werd verzocht de volgende zin af te maken:

Projecten gaan fout omdat…

• ‘de klant het project onvoldoende ondersteunt in de organisatie.’
• ‘de organisatiestrategie en bedrijfsdoelstellingen onduidelijk zijn.’
• ‘er fouten in de doelstellingsfase worden gemaakt.’
• ‘men niet de juiste tool kiest voor ‘het probleem’.’
• ‘men te veel in één keer wil neerzetten.’
• ‘de opdrachtgeversorganisatie onvoldoende helder heeft wat men exact wil bereiken.’
• ‘de focus op de doelstelling en de businesscase verloren gaat.’
• ‘men niet duidelijk weet wat men wil.’
• ‘de organisatie niet klaar is voor de nieuwe manier van werken.’
• ‘beslissers denken dat een pakketimplementatie al hun problemen oplost.’

Uit deze willekeurige greep uit de antwoorden van de projectbetrokkenen (consultants, projectleiders, etc.) blijkt een zekere onmacht. Onduidelijke uitgangspunten en doelstellingen zijn ook in hun ogen de voornaamste oorzaken voor falen.

Tweede faaloorzaak: de stevige managementaanpak

De tweede grote faaloorzaak typeer ik als volgt: ‘Het is de stevige managementaanpak die roet in het eten gooit.’ Dit zal ik toelichten. Eindverantwoordelijke opdrachtgevers hebben doorgaans erg weinig ervaring met grootschalige pakketimplementaties. Gemiddeld heeft men maar één of twee organisatiebrede IT-projecten als opdrachtgever meegemaakt. Daardoor ontbreekt het ze vóór aanvang van een omvangrijk project met standaardsoftware mogelijk aan een visie op het omgaan met onzekerheid in het project. Een manier om met die onzekerheid om te gaan, kan worden getypeerd als ‘de stevige managementaanpak’. Er staat veel op het spel en er mag niets misgaan. Dus de scope, het budget en de planning moeten vooraf 100% duidelijk zijn. Aangemoedigd door juristen en inkopers zet de opdrachtgever pas zijn handtekening onder een contract met de IT-leverancier als alle specificaties van het te realiseren IT-systeem 100% bekend zijn. Opdrachtgevers hebben daarnaast niet zelden een voorkeur voor een zogenaamd ‘fixed price contract’. Dit lijkt immers maximale duidelijkheid te geven.

De belangrijkste les die over ‘falende IT-projecten’ te leren valt, is dat het simpelweg onmogelijk is een complex project op voorhand helemaal in scope, tijd en budget te fixeren, en het systeem in zijn geheel te specificeren alvorens men het gaat realiseren. De meeste stevig gemanagede fixed price contracten gaan mis. Dit komt omdat het fixeren van scope, budget en planning niet alleen gevolgen heeft voor de prijs en de andere condities van het project, maar óók voor de samenwerking met het externe IT-bedrijf die de implementatie begeleidt. Dat is onder opdrachtgevers veel minder bekend. Bij het fixeren van een projectbudget wordt de onzekerheid over het verloop van het project niet weggenomen, ze wordt alleen overgeheveld naar de IT-leverancier. Dit heeft allerhande nare bijwerkingen die een goede samenwerking in de weg staan. De IT-leverancier gaat achter een façade van schijnzekerheid aan de slag. De kwaliteit van de samenwerking is lager omdat de informatievoorziening vanuit IT-leverancier naar de opdrachtgever onvolledig is. Uit het onderzoek blijkt dat projecten die in zijn geheel gefixeerd zijn in tijd en geld, váker teleurstellen dan projecten waarbij die fixatie op voorhand niet plaatsvindt. In beide faalvoorbeelden lijkt de aanpak overzichtelijk en gestructureerd. De ene keer is het doel losjes geformuleerd en zal het gaandeweg verhelderd worden, de andere keer wordt alles tot achter de komma gespecificeerd. Begeleid door professionele partijen zoals inkoop- en adviesbureaus, gaat men aan de slag. In beide gevallen gaat het uiteindelijk in meer dan de helft van de gevallen geheel of voor een deel fout. Organisaties leiden tonnen of zelfs miljoenen schade.

IT-bedrijven maken opdrachtgevers het uitglijden erg gemakkelijk

Organisatiebrede IT-projecten vragen een besturing die zich uitstrekt over alle disciplines, dus boven functionele domeinen als ‘de business’, stafafdelingen, en (externe) IT-specialisten. Daarom is IT-opdrachtgeverschap per definitie het werkveld van het algemeen management. Verstand hebben van IT is geen vereiste, wel goed opdrachtgeverschap! De grootste faaloorzaak is de ‘delegerende baas’ die de noodzaak voor deze besturing niet ziet, maar ook de Nederlandse IT-dienstverleners hebben een aandeel in het falen. Uit onderzoek blijkt dat de ene Nederlandse IT-dienstverlener de andere niet is. Vraag aan IT-dienstverleners: Hoeveel % van de eigen IT-projecten gaat over tijd én over budget of wordt afgebroken?

Bron: Interviews met IT-dienstverleners: Accenture, Capgemini, CRMWaypoint, Deloitte, IBM, Innoveer en Ordina.

Bij één ‘gerenommeerde’ Nederlandse IT-dienstverlener faalt maar liefst 92% van de projecten, bij de anderen gebeurt dat minder, of bijna nooit. Dat is iets om óók even bij stil te staan. Uit het onderzoek volgt dat er een duidelijk verband bestaat tussen het gebruik van IT-richtinstrumenten door IT-bedrijven en het percentage eigen faalgevallen. IT-richtinstrumenten zijn hulpmiddelen die men kan gebruiken voor het richten (op bedrijfsdoelen) en gericht houden van een IT-project. Denk daarbij aan het maken en (tijdens het project) gebruiken een business case; het besturen van het project aan de hand van businessacceptatiecriteria, het gebruik van een op de bedrijfsstrategie gebaseerde projectfase-overgangstoets, et cetera. Hoe minder een IT-dienstverlener van deze instrumenten gebruik maakt en dus onvoldoende op het functioneren van een opdrachtgever let en hem of haar niet in de rol van actief betrokken eindverantwoordelijk opdrachtgever manoeuvreert, hoe groter de kans op falen. Dit simpele gegeven verschaft een eenvoudige lakmoesproef. Als het proces in de aanloop naar een IT-project goed is verlopen, is er een groot beroep op de businessmanager gedaan. Als het proces niet goed is verlopen, en de businessmanager is in zijn tijdelijke rol als IT-opdrachtgever nauwelijks betrokken, dan is te voorspellen dat het niet goed zal gaan.

Raad voor de Rechtspraak: weer IT-problemen in de maak

De Raad voor de Rechtspraak heeft in april 2010, na een mislukte aanbesteding in 2009, de draad maar weer  eens  opgepakt. Ze onderneemt nu een tweede poging voor het realiseren van een nieuw IT-systeem op basis van standaardsoftware. Budget: 10 miljoen. De aanbestedingsdocumenten (Viro 2010) zijn dit voorjaar gepubliceerd. Uit deze documenten blijkt dat de Raad helaas wederom een zeer ongelukkige benadering kiest, die zeer waarschijnlijk tot grote problemen gaat leiden. Het uitgangspunt voor de voorgenomen IT-investering zijn de organisatorische doelen die de Raad voor de Rechtspraak doormaakt. Dit stelt nieuwe eisen aan de invulling van de bedrijfsprocessen van de Raad. De noodzakelijke organisatorische verandering moet mede mogelijk gemaakt worden door een nieuw IT-systeem, dat bijvoorbeeld het digitaal procederen in de toekomst ook mogelijk maakt. In de uitwerking van de aanbesteding van het Viro-project vindt men dat niet terug. Niet de organisatorische uitgangspunten en de organisatorische doelstellingen van de Raad staan centraal, maar de toepassing van standaardsoftware (ICT): het vervangen van een verouderd IT-systeem. De vraagstelling is nadrukkelijk opgesteld vanuit vier IT-invalshoeken, hierin ontbreekt de organisatorische invalshoek (veranderissues, spanningvelden, mensen, politiek, cultuur, kennis, organisatiestructuur) zo goed als geheel. Het perspectief van de businessmanager ontbreekt dus in de paparassen. De kans dat de Raad voor de Rechtspraak haar IT-doelen en haar organisatiedoelen tijdens het project alsnog bij elkaar houdt (of krijgt) is, door het ontbreken van waarborgen en selectie-eisen in de selectieleidraad (het belangrijkste en meest onderschatte aanbestedingsdocument), laag. De Raad stelt geen gerichte eisen aan de bekwaamheid van gegadigden op het gebied van organisatieontwikkeling en implementatiemanagement, terwijl deze nu juist het belangrijkste struikelblok zijn bij de implementatie van standaardsoftware. De gevolgen laten zich goed voorspellen.

Verbazing

Bij het inleveren van dit artikel stelde hoofdredacteur Willem Mastenbroek de volgende vraag: 'Nico, hoe kan het dat IT-bedrijven er dan niet voor zorgen dat het verantwoordelijke management bij de les blijft ??? Dat is toch eigenlijk een grote schande!' Hierin kan ik Willem alleen maar gelijk geven. Deze hele gang van zaken heeft mij ook verbaasd. Ik zal hier in een volgend artikel voor ManagementSite nader op ingaan. Hieronder alvast een voorschot:

• Zes van de zeven ondervraagde IT-dienstverleners geven onomwonden toe dat de projecten die zij doen MEESTAL NIET goed gealined zijn met de businesskant van hun opdrachtgever;
• IT-bedrijven laten na de doelen van een investering te checken. Ze brengen ook wanneer het businessdoel bij een klant NIET duidelijk is doodleuk een offerte uit;
• Door de klant opgestelde business cases worden door IT-bedrijven niet of nauwelijks gecontroleerd;
• IT-bedrijven krijgen (en nemen) veel te weinig tijd voor offertes;
• De projecten worden door IT-bedrijven niet goed op voortgang gecontroleerd en vaak slecht en door sommigen zelfs geheel niet geëvalueerd, één gerenommeerd Nederlands IT-bedrijf legt anno 2009 stelselmatig alleen de 'projectsuccessen' vast, zodat gevreesd moet worden dat daar al jaren dezelfde fouten gemaakt worden;
• Maatregelen die IT-bedrijven nemen om projecten op de rails te houden beslaan meestal uitsluitend IT-technische of projectmanagementaspecten, terwijl daar de uitdaging niet in zit. Projecten met standaard software mislukken immers niet door technische problemen, maar door miscommunicatie en het dichttimmeren van het samenwerkingsproces;

Het is dus een combinatie van onkunde en plat commercieel opportunisme. Klanten van IT-bedrijven hebben een significant lagere klanttevredenheid dan die van andere zakelijke dienstverleners. Deze situatie bestaat waarschijnlijk al vele jaren. Ze zal in mijn ogen blijven bestaan totdat eindverantwoordelijke opdrachtgevers eisen dat het beter moet. En hun verantwoordelijkheid daarin nemen.

De in dit artikel vermelde gegevens zijn afkomstig uit een onafhankelijk en representatief onderzoek van de auteur.

Het onderzoek bestond uit vijfentwintig gestructureerde interviews en een online enquête onder een zevental gerenommeerde IT-bedrijven waaronder Accenture, Capgemini, Deloitte, IBM en Ordina én hun klanten.

De onderzoeksbevindingen zijn samen met dertien praktische IT-hulpmiddelen voor businessmanagers gebundeld in een nieuw Nederlandstalig boek, getiteld ‘Lead IT or Lose IT’, dat onlangs is verschenen.