10 valkuilen en 5 kansen van IT-projecten

‘A significant percentage of IT project failures, perhaps most, could have been avoided using techniques we already know how to apply. For shame, we can do better than this’ (L. Hatton). In dit artikel geven wij allereerst 10 redenen voor het mislukken van IT-projecten.

Het overgrote deel daarvan blijkt te managen te zijn. In het tweede deel geven wij 5 adviezen om deze valkuilen van IT-projecten te vermijden. We gaan daarbij uit van projecten waarbij naast technologie ook werkwijzen in organisaties betrokken zijn, misschien zelfs wel klanten en leveranciers.

10 redenen waarom IT-projecten mislukken

1. Opbrengsten worden overschat
Veel IT-projecten zijn innovaties in de zin dat ze worden beleefd als iets nieuws. Innovaties brengen onzekerheid, namelijk over de aard en consequenties ervan. Iemand die moet beslissen over een IT-project, zal zijn onzekerheid reduceren met informatie. Mensen baseren hun afweging over voor- en nadelen in hoge mate op het vertrouwen dat zij hebben in de bron van hun informatie.

Vaak spelen leveranciers een rol, aangezien zij een eigen belang hebben bij het introduceren van nieuwe technologie en advisering. De mate waarin de opbrengst van het IT-project wordt beleefd als beter dan de bestaande oplossing (het relatieve voordeel van de innovatie), wordt in de praktijk vertekend door selectieve informatie tijdens het beslissingsproces.

Beslissers richten zich op de gewenste uitkomsten, maar zien ongewenste over het hoofd – een fenomeen dat ook wel bekendstaat als ‘poor probability estimation’. Ook komt het voor dat de beslisser leunt op informatie van leveranciers, die worden beschouwd als expert, ook wel ‘overconfidence’ genoemd.

Per saldo leiden deze effecten ertoe dat de opbrengsten van het project worden overschat.

2. Kosten worden onderschat
De kosten van automatisering staan in vrijwel elke organisatie onder druk, terwijl ze in de huidige marktomstandigheden van schaarste stijgen. Voor een deel van de IT-budgetten is het legitiem om ze op kosten te managen, omdat het meer facilitaire technologie betreft.

IT-projecten zijn per definitie geen cost, maar value drivers. Value drivers zijn gericht op ontwikkeling van de toekomstige performance van de onderneming. In de praktijk echter worden veel budgetten van IT-projecten vanuit kosten opgebouwd, en staat de IT-discipline onder druk om lage kosten te offreren, zeker als de IT-discipline of een leverancier een (semi-)commercieel belang heeft om het project te acquireren.

Als dan tijdens het project interne of externe kennis uitvalt of de technologische complexiteit valt tegen, ontstaat er direct een budgettair probleem, met dito overschrijdingen. Het vergt veel ervaring en managerial wijsheid om te lage offertes te herkennen en binnen of buiten de offerte te repareren.

3. Projectrisico ’s worden genegerd
‘(…) the importance of risk management is poorly understood’. IT-projecten zijn inherent risicovol. De meest voorkomende risico’s zijn tijdcompressie en requirements creep.

Uit onderzoek blijkt dat het reduceren van de tijd die nodig is voor een IT-project het risico op falen zeer sterk doet toenemen. Een ander veelvoorkomend risico met grote gevolgen is het schuiven van requirements. Oudere IT-projectmanagementaanpakken leggen aan het begin van een project alle requirements formeel vast.

Het probleem daarbij is dat gebruikers niet in staat zijn alle requirements goed en volledig te specificeren. Hierdoor ontstaat rework en verdwijnt een deel of zelfs alle waarde van het project. Het antwoord daarop was de iteratieve aanpak. Daarbij wordt telkens een deel van de requirements gespecificeerd en gerealiseerd, waarna ze in een volgende fase worden verdiept of uitgebreid.

Kenmerkend voor deze aanpak zijn projecten die nooit afkomen. Vanzelfsprekend is het vrijwel onmogelijk dat ‘never ending projects’ waarde creëren. De aanpak om dat weer tegen te gaan is gebaseerd op best practices en standaardsoftware. Een uit de gebruikersorganisatie veel gehoord bezwaar tegen deze aanpak is de beperking die wordt ervaren van het standaardproduct of de voorgedefinieerde implementatie.

Hierbij kan waarde verloren gaan als niet bijzondere aandacht wordt besteed aan inbedding van de technologie in de organisatie. Kortom, een perfecte methode om de risico’s van IT-projecten te vinden en te managen bestaat niet. Daarmee is de te kiezen aanpak een managerial beslissing.

4. Onderscheid tussen project – en benefits – risico wordt niet gemaakt
Naast het projectrisico kennen ITprojecten risico’s in andere onderdelen van het bedrijf dan IT: ‘benefits risk’. Een klassieker is de businesscase die leunt op productiviteitswinst. Als die winst over een groot aantal medewerkers is verdeeld, is het risico dat die in de praktijk niet zijn te combineren tot fte’s waarmee kosten ook daadwerkelijk dalen.

In dat geval is de benefit van het project dus niet (volledig) incasseerbaar. Een ander ‘benefits risk’ is concurrentienadeel of gemiste waarde, doordat niet de juiste projecten de jaarlijkse IT-portfolio halen. Businesscases die niet uitkomen, wijzen op verkeerde investeringsbeslissingen en verkeerde allocatie van schaarse mensen en middelen. Die hebben niet alleen het beoogde rendement niet gehaald, maar hadden in dezelfde tijd andere dingen kunnen doen die wel of hoger hadden gerendeerd.

Risicomanagement bij IT-projecten beweegt zich veelal op het terrein van projectrisico, en veel minder op dat van de integrale businesscase waarin ook niet-IT benefits worden meegenomen.

5. IT-projecten zijn organisatieveranderingen
De IT-projecten waar dit artikel zich op richt, zijn organisatieveranderingen. Een gangbare projectmanagementmethode voor IT-projecten, Prince2, richt zich op de structuur en formele beheersing van het project.

Uit onderzoek blijkt dat de adoptie van innovaties een complex proces is dat wordt beïnvloed door vijf heel andere elementen. In de eerste plaats de kenmerken van de innovatie, zoals het relatieve voordeel en de mate waarin dit aansluit bij bestaande ervaringen.

Daarnaast is van invloed of de innovatiebeslissing is genomen door degenen die het betreft, individueel, als groep of door anderen. Verder spelen mee de kanalen die worden gebruikt om over de innovatie te communiceren, de aard van de groep betrokkenen, hun normen, cohesie en dergelijke, en de mate waarin de change agent door de groep wordt geaccepteerd en vertrouwd.

Om het nog ingewikkelder te maken: voor al deze elementen geldt dat de manier waarop ze door de betrokkenen worden beleefd, zwaarder weegt dan wat je ‘objectief’ kunt vaststellen. Vanuit het standpunt van een projectmanager is het goed te begrijpen dat dat wel een beetje veel hooi op de vork is. De organisatieverandering goed en volledig tot stand laten komen is dan ook veel meer een managerial verantwoordelijkheid.

Omdat verandering risicovol is en moeilijk, wentelen veel managers die verantwoordelijkheid af op het project, dat de verandering vervolgens maar beperkt realiseert. Organisaties die IT-projecten doen, zouden dus eigenlijk heel goed moeten zijn in organisatieverandering.

6. Effecten op de omgeving worden niet meegenomen
Businesscases van IT-projecten richten zich op het project. Logisch. Minder logisch is dat de effecten van het project op de omgeving over het hoofd worden gezien. Ze vormen vanuit het perspectief van de projectmanager als het ware ‘externalities’, die daarmee ‘out of scope’ zijn.

De organisatie krijgt wel te maken met deze effecten. Vanuit managementperspectief moet je er dus wel rekening mee houden. Switching costs bijvoorbeeld, als je met een IT-project wilt wisselen van leverancier of het van de ene naar een andere leverancier moet overdragen.

Een ander voorbeeld zijn contracting costs, de kosten voor het sluiten van het contract. Die kunnen in het geval van een omvangrijke tender behoorlijk oplopen en het rendement van een project negatief beïnvloeden. Een externality is ook de mogelijke periode van verhoogde aantallen incidenten, doordat gebruikers nog onder in hun leercurve zitten.

Tenslotte worden de operationele kosten na oplevering onderschat, waardoor de waarde van het project vermindert of geheel verdwijnt. Het vergt weer de al eerder genoemde expertise en managerial wijsheid om externalities te zien en mee te wegen in besluitvorming.

7. De (enterprise ) architectuur is onderontwikeld
Wat goed is voor een onderdeel van het bedrijf, is dat niet per definitie voor het concern als geheel: het klassieke ‘suboptimal problem’. Andersom geldt ook dat een afdeling kan worden gevraagd te reorganiseren, omdat dit waardevol is voor de onderneming als geheel.

Om actief op ondernemingswaarde te managen is inzicht nodig in het specifieke raderwerk van value drivers, financiële indicatoren en waardecreërend vermogen. Vervolgens moet dit inzicht worden vertaald naar informatie en systemen. Het inzicht in de relatie tussen operationele en strategische value drivers wordt in het IT-vakgebied aangeduid als (enterprise) architectuur.

Als er in organisaties aan architectuur wordt gedaan, gebeurt dat vaak binnen de IT-discipline en richt men zich op technologie. Dat is op zich waardevol, maar levert niet het volle potentieel aan waardecreatie in de organisatie op dat het zou kunnen hebben.

Zonder diepgaand inzicht in de architectuur van de onderneming lopen organisaties het risico op over- of onderinvestering in IT.

8. Het gevaar van interferentie wordt niet onderkend
Vooral in wat grotere organisaties gebeurt het niet zelden dat IT-projecten elkaar, of dat IT- en andere activiteiten elkaar in de weg zitten. De belangen van een ERP-implementatie kunnen haaks staan op die van de marketingafdeling die met e-commerce aan de slag wil.

Binnen de ITdiscipline treedt interferentie op als een project rekencapaciteit en mensen nodig heeft die niet beschikbaar zijn door verbouwing van de infrastructurele technologie in bijvoorbeeld het rekencentrum of netwerk.

Hoe meer technologie aan elkaar hangt, wat bij veel bedrijven in toenemende mate het geval is, hoe gevoeliger die is voor interferentie, tussen projecten onderling en tussen projecten en andere activiteiten.

Het is dus zaak om ITprojecten niet als separate entiteiten te managen, maar als programma’s van onderling samenhangende projecten die organisaties veranderen om strategische waarde te creëren. De functie die daarvoor kan zorgen is programmamanagement.

9. Auditregime op IT ontbreekt
Het is heel normaal dat een accountant de boeken controleert. We zijn daaraan gewend en handelen daar ook naar. In IT-land is er schijnbaar een blind vertrouwen dat degenen die eraan werken het ook wel zullen weten. Sourcecode, inrichtingen bij (semi-) standaardprogrammatuur en uitbestede infrastructuren staan over het algemeen niet onder een auditregime, anders dan als onderbouwing voor accountantsverklaringen.

Als je met legacy geconfronteerd wordt waarvan de kennis ontbreekt, is het probleem je vaak al boven het hoofd gegroeid. Frequente wijzigingen die onder hoge druk, ook van management en bestuurders, zijn doorgevoerd, waarbij alle software-engineeringdiscipline uit het oog is verloren, brengt op de korte termijn soelaas, maar op de lange termijn investeringen die nodig zijn, maar niet gepleegd kunnen worden.

Enkele voorbeelden: in een systeem tref je verschillende algoritmes aan voor dezelfde functionaliteit, waarvan tevens een aantal foutief. Of functionaliteit wordt zo geprogrammeerd dat het een performance bottleneck blijkt te zijn. Een statusrapport over de kwaliteit kan de issues aan het licht brengen die tot venijnige problemen kunnen uitgroeien, tenzij je tijdig maatregelen neemt.

Of controle op outsourcing: doet men geen vreemde dingen, en zijn de rekeningen die men stuurt terecht? Hoeveel IT-projecten bevatten een audit op de deliverables? Het vergt opnieuw managerial wijsheid om in te zien wanneer audits op IT moeten worden toegepast.

10. Er is sprake van zwak leiderschap
Last but not least, IT-projecten worden te vaak slecht geleid. In essentie op twee fronten: dat van het projecten programmamanagement binnen de IT-discipline, en dat van het leiderschap in de andere bedrijfsfuncties of de organisatie als geheel.

Jarenlang heeft de IT-discipline zichzelf en anderen geprogrammeerd met denken in vraag en aanbod: het demandsupplymodel. De aanname onder dit model is dat er een wereld bestaat die business heet (‘demand’) en een die IT heet (‘supply’); demand stelt vragen, supply geeft antwoord.

De werkelijkheid is echter veel complexer. Door gebrek aan IT-expertise gedraagt demand zich niet zoals in het model is bedoeld. Supply bestaat niet uit één, maar uit meer entiteiten, die onderling ook demand-supplyachtige verhoudingen hebben.

Dit geldt eens te meer bij outsourcing. Tijd is een probleem, want pas wanneer demand een vraag stelt, kan supply aan het werk gaan. Tenslotte gaat dit denken voorbij aan het integrerende en strategische karakter van veel IT. In onze ideale wereld bestaat er geen onderscheid tussen IT en de rest van het bedrijf, waar het een integraal onderdeel van is: IT = business.

Sommige auteurs betogen dat de executive board zelf zich zou moeten bemoeien met strategische IT-investeringsbeslissingen, het creëren van een shared service center voor generieke technologie, (enterprise) architectuur zoals eerder beschreven en standaards voor uitwisseling van gegevens tussen systemen. Businessunits en individuele managers hebben dan beslissingsvrijheid binnen deze frameworks.

Die wereld is nog ver weg in omgevingen die op het klassieke demand-supplydenken zijn gebaseerd en die worden geleid door directies en besturen die weinig affiniteit hebben met IT.

We stellen bij IT-projecten dus een groot aantal valkuilen vast. Is IT dan hopeloos verloren? Natuurlijk niet, want uit de voorgaande beschouwingen blijkt dat het managen van al deze valkuilen is te leren. Goed geleide ITprojecten dragen wel degelijk bij aan strategische waardecreatie. In het hiernavolgende geven wij 5 adviezen voor organisaties die zich willen verbeteren in het managen van waardecreërende IT-projecten.

5 adviezen om deze valkuilen te vermijden

1. Beoordeel rentabiliteit tegenover het risicoprofiel
Om te weten tegen welk kostenniveau een IT-project zich kan veroorloven, moet het risicoprofiel van het project bekend zijn. Een project met hoge risico’s is alleen gerechtvaardigd bij een groot realiseerbaar rendementspotentieel. Daarbij is het essentieel om onderscheid te maken tussen de risico’s die een succesvolle oplevering in de weg staan (projectrisico’s) en de risico’s voor de onderneming bij het falen of niet uitvoeren van het project (benefits risico’s).

Uit onderzoek blijkt dat op deze manier beschouwd veel IT-projecten weinig waarde creëren of zelfs waarde vernietigen. De middelen die vrij kunnen komen uit onvoldoende renderende projecten, kunnen worden ingezet op projecten die wel aan de criteria voldoen. Dit resulteert in een veel betere allocatie van de schaarse middelen voor IT-projecten en in een hoger waardecreërend vermogen ervan.

2. Manage IT-projecten als risk return portfolio’s
Veel IT-projecten zijn in zichzelf niet rendabel. Hard- en softwareleveranciers maken hun producten eens in de zoveel tijd overbodig om met vervangingen nieuwe inkomsten te genereren. Elk bedrijf moet die marktbewegingen op enig moment volgen, ook al brengen ze geen nieuwe omzet, rendement of concurrentievoordelen.

Daarnaast staan projecten met een hoog rendementspotentieel. Door ITprojecten van verschillende risico- en rendementsprofielen te combineren kan een goed overall rendement worden gerealiseerd. De samenstelling van de portefeuille en de overall rendementseis is afhankelijk van business- en marktomstandigheden.

Maar door een combinatie zijn organisaties in ieder geval in staat zowel hogerisicoprojecten te doen, omdat die worden gemitigeerd met lagerisicoprojecten, als om in zichzelf niet-renderende projecten toe te laten.

3. Gebruik de integrerende kennis van IT
Geen bedrijfsdiscipline heeft zo’n brede en diepe kennis van het bedrijf als IT. IT moet wel, want IT werkt overal. Het onderdeel van het vakgebied dat dit soort kennis en inzichten vastlegt en toegankelijk maakt voor anderen heet architectuur. Zo kunnen IT-architecten bijvoorbeeld afwegen om problemen op te lossen bij finance of bij procurement, door betere afspraken te maken met leveranciers.

De integrerende kennis van IT kan ook grote meerwaarde hebben in mergers, acquisities en allianties of divestments, evenals bij strategische transformatie. Vanzelfsprekend vergt dit wel een IT-discipline die daartoe in staat is en die op die manier wordt geleid.

4. Zet IT-projecten in als leerschol voor leiderschap
Uit onderzoek blijkt dat het doormaken van intense ervaringen wezenlijk bijdraagt aan het ontwikkelen van leiderschap. Mensen die complexe IT-projecten of programma’s – inclusief de bijbehorende organisatieontwikkeling – succesvol hebben geleid, hebben na afloop daarvan een schat aan ervaring.

Deze mensen zijn vanzelfsprekend waardevol voor volgende IT-projecten, maar ook om door te stromen naar andere onderdelen van het bedrijf. Daarmee zijn IT-projecten en programma’s ideale leerscholen voor nieuw managementtalent.

Dat werkt naar twee kanten positief: mensen met algemeen managementpotentieel leiden IT-projecten, waardoor die in potentie integraler worden geleid, en er ontstaat een instroom in het management die steeds beter om kan gaan met IT-projecten.

Omdat het leiden van complexe IT-projecten moeilijk en risicovol is, lijkt ons dit advies van toepassing op medewerkers met al enige managementervaring. Vanzelfsprekend blijft daarnaast de rol van technisch projectmanagement binnen de IT-discipline noodzakelijk.

5. Verzwaar de rol van de CIO
De executive die de integrerende rol van IT in de organisatie bij uitstek tot waarde kan laten komen, is de chief information officer, de CIO. Dit is degene die de expertise en de managerial wijsheid kan inbrengen om IT-projecten te beoordelen, bij te sturen of tegen te houden.

De functie van CIO is nog relatief jong, per definitie interdisciplinair, met een vakgebied dat inhoudelijk nog sterk in ontwikkeling is. In sommige gevallen wordt de functie nu bekleed door mensen die zijn opgegroeid in het demand- supply-denken en in technologie.

In veel gevallen werken zij onder de generatie CEO’s die in het analoge tijdperk groot zijn geworden. Het is zaak om de CIO-positie in te vullen vanuit strategisch perspectief en daarbij uit te gaan van integratie van IT in het businessmodel. Alleen dan komt het waardecreërende potentieel van IT maximaal tot zijn recht.

Vanzelfsprekend geldt voor huidige en aankomende CIO’s dat zij deze verwachtingen moeten inlossen. Dat daarvoor een brede en diepe voorbereiding in theorie en praktijk noodzakelijk is, spreekt voor zich. Het perspectief voor deze mensen in het digitale tijdperk is goed: als CEO’s immers geen IT meer aanleren, is het tijd voor CIO’s om CEO te worden.

WOUTER HAASLOOP WERNER MBA is CIO van Maxeda en voorzitter van de Advisory Board van CIOnet The Netherlands. PROF. DR. CHRIS VERHOEF is hoogleraar aan de afdeling Information Management and Software Engineering van de Vrije Universiteit Amsterdam