Dat grote projecten lang niet altijd goed verlopen, is zo langzamerhand wel bekend. Maar ook de implementatie van standaardsoftware gaat opvallend vaak mis. Ruim de helft faalt. De projecten gaan over tijd en over budget of worden zelfs helemaal afgebroken. Eindverantwoordelijke opdrachtgevers zijn meestal zélf schuldig aan het falen, maar sommige gerenommeerde Nederlandse ict-dienstverleners maken hen het uitglijden wel heel erg gemakkelijk.
Ict in organisaties is tegenwoordig méér en méér confectiewerk. Een manager van een telecombedrijf 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. Bovendien heerst er onder businessmanagers een hardnekkig misverstand dat je van ict verstand moet hebben om als projectopdrachtgever goed te kunnen functioneren.
Het opdrachtgeverschap wordt daarom maar al te graag overgelaten aan iemand met ‘verstand van zaken': een ict-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 weinigen op dat inadequaat opdrachtgeverschap de kernoorzaak is.
Oorzaken van falen
Meer dan de helft (53 procent) van de ict-projecten met bedrijfssoftware faalt deels of volledig. Slechts één op de twintig projecten faalt door onvoorziene technologische problemen. Een veel groter deel, namelijk vier van de tien, faalt door onduidelijkheden in de voorbereidingen of door slecht geformuleerde projectdoelen. Daarnaast is er een deel dat ontspoort tijdens het ontwerpen. Het falen wordt niet veroorzaakt door technische problemen, maar vooral door onduidelijkheid in de communicatie en het dichttimmeren van alle onzekerheden in het selectie- en implementatieproces. Vier van de vijf falende projecten met standaard software falen al vóórdat de informatietechnologie in beeld komt, dus vóórdat er überhaupt door ict'ers aan het softwarepakket gesleuteld wordt.
De opdrachtgevers van deze probleemprojecten ervaren het moment van falen anders. Zij zijn van mening dat falende projecten pas tegen het einde in de problemen komen: tijdens het testen en het in gebruik nemen van de bedrijfssoftware. Dat is begrijpelijk omdat voor een opdrachtgever het projectresultaat pas echt concreet wordt op het moment dat het systeem getest wordt. Hieruit kunnen we concluderen 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 hier tekort en er is te weinig aandacht voor de samenhang tussen de bedrijfsvoering en de ict. Dit komt tot uiting bij het gebrekkig richten van het project, het maken en gebruiken van een businesscase, het hanteren van business acceptatiecriteria en bij het sluiten van een contract met een ict-dienstverlener.
Te laat
Het gevolg is dat opdrachtgevers pas merken dat hun project gaat falen op het moment dat het softwarepakket is ingericht. Dan blijkt het systeem misschien technische wel te functioneren, het is immers standaard software, maar niet aan de behoefte van de organisatie te voldoen. Het ict-systeem staat scheef op de operatie, maar voor bijsturen is het te laat omdat het geld al is gespendeerd. Na veel gedoe en regelmatig ook een conflict met de ict-dienstverlener gaat het systeem daarna ‘in godsnaam maar live'.
De enorme schaal waarop dit in Nederland gebeurt is in toenemende mate een verklaring voor de wonderlijke informatiedoolhoven die méér en méér organisaties zijn. Eindeloos doorverbinden, slechte communicatie, onbeantwoorde vragen en allerhande fouten en misverstanden gedijen het beste in organisaties waar de ict-systemen scheef staan op het werkproces.
Een goed opdrachtgever maakt werk van de samenhang tussen de bedrijfsvoering en de iict. Hij staat gesteld voor het richten van zijn project en het gericht houden van zijn project. Bij falende projecten ontbreekt deze regie hetgeen door de Nederlandse IT-dienstverleners onvoldoende wordt opgevangen of wordt afgedwongen. Er bestaat een verband tussen het gebruik van ict-richtinstrumenten (de governance afspraken, de businesscase, de businessacceptatiecriteria) én het projectsucces van individuele ict-dienstverleners. Hoe minder een dienstverlener van deze instrumenten gebruik maakt, hoe groter de kans op falen.
Delegerende baas
Organisatiebrede ict-projecten met standaard software vragen een besturing die zich uitstrekt over alle disciplines, dus boven functionele domeinen als ‘de business', stafafdelingen, en (externe) ict-specialisten. Daarom is het opdrachtgeverschap per definitie het werkveld van het algemeen management. Verstand hebben van ict is géén vereiste, wel goed opdrachtgeverschap! De grootste faaloorzaak is de ‘delegerende baas' die de noodzaak voor deze besturing niet ziet, maar ook de Nederlandse ict-dienstverleners hebben een aandeel in het falen.
Hoe minder een dienstverlener toeziet op adequaat opdrachtgeverschap, en haar eindverantwoordelijke opdrachtgever niet in de juiste rol manoeuvreert, hoe groter de kans op falen. Daarin is nog een wereld te winnen, want de ene Nederlandse ict-dienstverlener is lang de andere niet. Bij één ‘gerenommeerde' Nederlandse dienstverlener faalt maar liefst 92 procent van de projecten, bij de anderen gebeurt dat minder of bijna nooit. Dit gegeven levert een eenvoudige lakmoesproef. Als het proces 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 of haar tijdelijke rol als eindverantwoordelijk opdrachtgever nauwelijks betrokken, is dat een voorspelling dat het niet goed zal gaan.
Nico Beenker mmc, certified management consultant
Onderzoek
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 ict-bedrijven (Accenture, Capgemini, Deloitte, IBM, Ordina, CRMpartners, Innoveer én hun klanten. De onderzoeksbevindingen zijn samen met dertien praktische ict-hulpmiddelen voor businessmanagers gebundeld in een nieuw Nederlandstalig boek, getiteld ‘Lead IT or Lose IT', dat 31 maart is verschenen bij www.managementboek.nl. ISBN 978-90-815310-1-6.
Binnen IPMA-NL is een groep bezig met het thema ‘Goed Opdrachtgeverschap.
De in het artikel verwoorde problematiek is ons zeer bekend. Overigens geldt dit fenomeen niet alleen bij ICT pakketimplementaties (het commentaar van Job Cohen als opdrachtgever van de Noord-Zuidlijn problemen was ook “wij zijn maar amateurs en moeten op de professionals vertrouwen).
Waarom zo moeilijk doen (zoals IPMA). Gewoon de hoofdstukken van PRINCE2 over de Business Case en Organisatie eens goed lezen! Juist: die hoofdstukken waarvan IT leveranciers (ook in hun trainingen) graag stukken weglaten.
Dus:
– Er bestaan geen IT projecten, alleen projecten met een zakelijke rechtvaardiging (business case).
– De opdrachtgever, niet de leverancier is de baas. Er is ook geen partnership want klant en leverancier hebben tegenstrijdige business cases. Kosten van een klant zijn baten voor een leverancier.
– Dit geldt ook voor indterne leveranciers, zoals een interne IT afdeling!
– Een goede vertegenwoordiging van de klant kan wonderen doen. Kijk eens goed naar de rollen van Executive en Senior User.
– Juist door de tegenstridige business cases kan een project maar beter door de klant worden gemanaged. Dus geen IT project manager van de (interne) leverancier maar een business PM van de klant.
We hoeven het wiel niet elke keer opnieuw uit te vinden. Het is allemaal al daar. En het eindelijk eens toepassen kan veel problemen voorkomen!
Dat opdrachtgevers niet altijd bovenop een door hen gestart project zitten was aanleiding voor het boekje _PRINCE2 voor opdrachtgevers_ door Michiel van der Molen (2006).
Ook de bron van PRINCE2, het Office of Government Commerce, heeft het dikke PRINCE2-boek (2005) gesplitst in een dik deel _Managing successful projects with PRINCE2_ en een dun deel _Directing successful projects with PRINCE2_ (2009).
Van een business executive (opdrachtgever) wordt in het kader van PRINCE2 blijkbaar ook iets verwacht.
Nou hebben opdrachtgevers vaak wel meer te doen dan alleen de door hen gestarte projecten richting te geven. Het is dan ook aan de projectleider om de opdrachtgever zover te krijgen dat hij zijn verantwoordelijkheid waarmaakt.
Zie ook het artikel _Prince2 alleen is niet voldoende_, https://www.computable.nl/artikel/ict_topics/beleid/3300436/2379250/prince2-alleen-is-niet-voldoende.html, waarin MORT (1973) wordt besproken als methodiek om oorzaken van falen of onderpresteren op te sporen.
Dit artikel geeft vooral te denken over degenen die de implementatie doen.
Als je merkt dat de verkeerde expertise afgevaardigd is namens de opdrachtgever, waarom doe je daar dan niets aan?
Als je merkt dat je niet representatieve eindgebruikers toegewezen krijgt als tester, waarom doe je daar dan niets aan?
Als de projectdoelen niet goed zijn geformuleerd, waarom neem je het project dan eigenlijk aan?
Wanneer je een project aanneemt, en het mislukt, dan heb je als aannemer een foute inschatting gemaakt, en hier niet goed op geacteerd; de opdrachtgever kan nooit fout zijn geweest.
Ik vind het een beetje goedkope smoes om de opdrachtgever de schuld te geven.