IT-beleid en -beheer zijn niet pragmatisch genoeg

Een alternatief is een ‘pragmatische’ kijk op beleid en beheer, die uitgaat van een weerbarstige realiteit waar nooit volledig greep op te krijgen is en waar geen garantie is op resultaten, slechts op het vergroten van de kans daarop. Door middel van deze pragmatische kijk op ICT wordt er een realistisch verwachtingspatroon gegeven, zodat er meer greep op ICT ontstaat en uiteindelijk betere resultaten geboekt kunnen worden. Dat ICT lastig is te managen, veel projecten mislukken, uitlopen en te veel kosten, is inmiddels algemeen bekend. Er zijn vele onderzoeken uitgevoerd, die alle leiden tot schokkende krantenkoppen. Zo stelt het onderzoek ‘trends in ICT’ van Ernst & Young dat het 90 procent van de grote bedrijven niet lukt om binnen het budget en de tijdsplanning ICT-projecten te realiseren. En: drie van de vijf grote bedrijven geven aan inmiddels voor een andere ICT-leverancier gekozen te hebben of dit binnenkort te zullen doen. Op een conferentie van ICT-managers gaf 95 procent aan ontevreden te zijn over de uitvoering van ICT-projecten, terwijl slechts 27 procent van de projecten wordt afgerond volgens de oorspronkelijke doelstelling. De overige projecten waren in belangrijke mate eenvoudigweg mislukt. Deze cijfers geven voldoende aanleiding om uiterst kritisch te kijken naar de achterliggende oorzaken van dit falen. Er is in de loop van de jaren veel onderzocht, gesproken en gediscussieerd over deze oorzaken. Dit heeft geleid tot de opkomst van een aantal methoden en technieken. Deze methoden en technieken leveren een raamwerk op waarbinnen het ICT-beleid en -beheer kan worden vorm gegeven. Itil en Prince zijn bekende voorbeelden, net als het al wat oudere ‘projectmatig werken’. Hoewel deze methoden en technieken verschillen wat betreft toepassingsgebied en reikwijdte, hebben zij toch hetzelfde doel. Aan de hand van een bedachte structuur wordt er een veelheid aan procedures en richtlijnen opgebouwd. Deze zouden na een fors implementatietraject uiteindelijk greep op het ICT-beleid, de ontwikkelingen en het beheer moeten opleveren. Toch zijn de succescijfers van ICT-projecten niet merkbaar hoger geworden, terwijl Itil ruim intrede heeft gedaan in de automatiseringswereld en het projectmatig werken overal wordt toegepast. Als we bovenstaande cijfers willen verklaren en verbeteren is er blijkbaar meer nodig dan het wijzen op nieuwe methoden en technieken. Dan moet er iets fundamenteels mis zijn in het beleid en in de werkwijzen die ICT-afdelingen hanteren. Helaas wordt op dit vlak weinig onderzocht of nagedacht. Er moeten onderliggende aannamen zijn die de uiteindelijke werking van deze methoden frustreren. Dit moeten aannamen zijn die in de praktijk niet kloppen, terwijl ze wel voor waar worden gehouden. Welke zouden dat kunnen zijn? Een eerste aanname heeft te maken met de ICT-technologie. De enorme snelheid van de technologische ontwikkeling valt moeilijk te onderschatten. Hoewel de principiële werking van hardware en software niet wezenlijk is veranderd, is de technologie van nu vele malen complexer dan die van twintig jaar geleden, en volstrekt niet meer te vergelijken met die van veertig jaar geleden. Er zijn wel vergelijkingen getrokken met de technologische ontwikkeling van bijvoorbeeld de radio, telefoon of de auto. Deze zijn in tientallen jaren ontwikkeld in een tempo die zowel gebruikers, ontwikkelaars als beheerders konden bijhouden. Dit is volstrekt niet het geval met de ICT-technologie. Kon twintig jaar geleden een systeembeheerder nog greep hebben op alle hardware en software, nu kan een beheerder slechts in grote lijnen begrijpen hoe zij werken. Alleen de zeer gespecialiseerde expert kan nog iets zeggen over de exacte werking van een bepaalde component (een harde schijf, een netwerkprotocol of een gedeelte van een stuk software). Al met al kan het als een wonder worden beschouwd dat deze technologie werkende systemen oplevert, omdat deze technologie verre van foutloos functioneert. Ter illustratie: Windows 2000 bevat 21 duizend bekende bugs en een veelvoud daarvan aan nog onbekende bugs. Dus naast de enorme complexiteit van ICT-technologie is er ook nog sprake van een grote hoeveelheid storingen. Slechts enkele grotere bedrijven zijn in staat alle noodzakelijke expertise aan te wenden. Nog afgezien van de vraag of al deze expertise uiteindelijk voldoende is voor het beheren van een systeem, zal het merendeel van de bedrijven daar nooit toe in staat zijn. Men kan slechts een aantal generalisten inhuren die zo goed mogelijk proberen de gebruikte technologie te beheren. De werkwijze die dan ook feitelijk wordt toegepast, is dat er pas bij problemen waar nauwelijks een ‘work around’ voor kan worden bedacht, externe expertise wordt ingehuurd om problemen op te lossen. Ook dat is zeker geen garantie voor succes. Vaak komt het dan ook voor dat systemen uiteindelijk worden afgedankt, men wacht op een volgende versie, men stapt over op een nieuw systeem of leert met de gebreken te leven. Het bovenstaande zal slechts een buitenstaander verbazen. Iedereen die in de ICT werkzaam is weet dat dit de realiteit is. Het verbazingwekkende is dat toch bij een nieuw te implementeren systeem als uitgangspunt wordt genomen dat dit systeem logisch is opgebouwd en daardoor volledig beheersbaar is. Als men een nieuwe server aanschaft, een stuk software ontwikkelt of een koppeling tussen systemen realiseert, gaat men ervan uit dat deze componenten zich volstrekt logisch en inzichtelijk zullen gedragen, zodat ze de gewenste functionaliteit zullen opleveren. Vooral de schijnbare logische opbouw van de technologie versterkt deze indruk. De folders, handboeken en leveranciers zullen nooit iets anders zeggen dan dat hun systeem het eenvoudigweg doet. Maar ook de betrokken professionals werken hier aan mee. Er zijn maar weinig systeembeheerders die zullen toegeven dat ze feitelijk nauwelijks weten wat voor software of apparaat ze in beheer hebben. Men weet uit ervaring en opleiding veel van de globale werking van het systeem. Samengevat: principieel kan het kloppen dat een systeem logisch werkt en beheersbaar is (hoewel dat ook betwijfeld kan worden gezien de enorme hoeveelheden bugs en storingen). Voor de meeste bedrijven is in de praktijk een systeem slechts zelden logisch en beheersbaar, simpelweg omdat zij geen toegang hebben tot een onbeperkte hoeveelheid kennis. Dit is een duidelijk voorbeeld van een onuitgesproken aanname die in praktijk feitelijk onjuist is. Een tweede aanname betreft het definiëren van het gewenste resultaat. Voorafgaand aan nieuwe ontwikkelingen formuleert men wat het uiteindelijke resultaat zal moeten zijn. De start is een wens van de organisatie op een abstract niveau, zoals ‘het controleerbaar maken van het werkproces’, ‘het bieden van een extranetapplicatie’ of ‘het leveren van managementinformatie’. De problemen doen zich voor als deze resultaten worden vertaald in functionele specificaties. Het blijkt uiterst lastig te zijn te definiëren wat een systeem uiteindelijk zal moeten doen. De praktijk van ICT-ontwikkelingen bestaat dan ook uit het veelvuldig afwijken van vooraf gedefinieerde specificaties. Dit komt omdat het een probleem is om helder en eenduidig te formuleren, zodat er geen verschillende interpretaties kunnen bestaan. Dit lijkt in de praktijk bijna onmogelijk, omdat het alleen te bereiken is met een min of meer ongelimiteerd budget, onbeperkte doorlooptijd en met medewerkers met een zeer hoog kennisniveau. Er zijn maar weinig organisaties die daartoe de mogelijkheden en de tijd hebben. Een nog groter probleem is dat de specificaties tijdens en zelfs aan het einde van het project nog worden bijgesteld. Dit gebeurt soms daadwerkelijk, door middel van een aanpassing in de specificaties, maar nog vaker gebeurt het zonder dat dit expliciet wordt gemaakt. De afwijking zelf kan een probleem opleveren, omdat er iets wordt gerealiseerd dat de gebruikers of managers niet willen. Maar zelfs al is de afwijking een gewenste aanpassing, dan nog gaat het tegen de basisprincipes in van de heersende methode en technieken. Die stellen eenvoudigweg: eerst precies definiëren wat je wilt, dan pas aan de slag. Daarnaast bestaat er nog het principe van ‘voortschrijdend inzicht’. De organisatie kan pas precies aangeven wat ze wil op het moment dat de organisatie er intensief mee bezig gaat. Deze realiteit staat feitelijk haaks op de eenvoudige aanname van bijvoorbeeld Itil en Prince dat het mogelijk is om eenduidige productspecificaties op te stellen. Vanuit deze specificaties wordt immers het gehele ontwikkelingsproces gestuurd en achteraf gecontroleerd. Ook hier is dus sprake van een geaccepteerde aanname die in de praktijk eenvoudigweg niet juist is. Een derde en laatste voorbeeld van een onjuiste aanname betreft de planning. Er is bijna geen planning die niet uitloopt. Zeker grotere invoeringsprojecten zijn slechts zelden beheersbaar. Dit komt vaak omdat de planning niet zorgvuldig is gemaakt. Er worden veel activiteiten simpelweg onderschat. En externe redenen bepalen vaak de uiteindelijke opleverdatum, in plaats van een datum die haalbaar is gezien het gehele projectplan. Toch wordt een ruime planning, met reële deadlines, ook vaak niet gehaald. Er moet dan ook meer aan de hand zijn met planningen. Er zijn hiervoor minstens drie redenen aan te geven. Ten eerste gaat men voorbij aan de invloed van de planning zelf op de voortgang van de planning. De paradox van een planning is dat een te krap geplande activiteit eerder klaar is dan een te ruim geplande activiteit. Een andere paradox is: de activiteiten die niet te plannen zijn, zijn het meest gebaat bij een planning; de activiteiten die eenvoudig planbaar zijn hebben geen planning nodig. Ten tweede wordt er een papieren schijnzekerheid gecreëerd, die de idee achterlaat dat het project planbaar en beheersbaar is. Doordat precies op papier staat wanneer wie wat moet doen, lijkt het alsof het nu slechts nog een kwestie van uitvoeren is. Vanuit deze schijnzekerheid wordt er te weinig aandacht en prioriteit gegeven aan de uitvoering ervan, zowel door het management als door de medewerkers zelf. De derde en cruciale reden is dat veel activiteiten eenvoudigweg niet te plannen zijn. De doorlooptijd is vaak niet in te schatten. De complexiteit van een activiteit wordt pas duidelijk op het moment dat men aan de activiteit begint. Het inzicht dat men verwerft bij het uitvoeren van de werkzaamheden is precies het inzicht dat men eigenlijk nodig heeft om de doorlooptijd van de activiteit te kunnen plannen. Dit wordt mede veroorzaakt door de al eerder genoemde complexe technologie (en daarmee de onberekenbaarheid van hardware en software), maar ook doordat het automatiseren van bedrijfsprocessen grote impact heeft op de werkprocessen en op de eigen ICT-infrastructuur. Ook komen vaak beperkingen en storingen van eerder gekozen oplossingen pas aan het licht als er op wordt doorgebouwd. En toch wordt elk project gestart met een planning waarvan de ervaring leert dat die niet haalbaar is. Dat betekent overigens niet dat planningen niet zinvol zijn, maar wel dat zij een verkeerde rol spelen, vooral als het gaat om het managen van ICT-projecten. De verkeerde aanname is: dat planningen een project volledig beheersbaar maken. De hierboven genoemde voorbeelden (er zijn er meer te noemen) van verkeerde aannamen laten zien dat men uitgaat van een omgeving waarin er voldoende mankracht is, voldoende tijd, kennis, en voldoende greep op de toegepaste technologie en doorlooptijd. Waar uitkomsten perfect definieerbaar zijn en resultaten zijn af te dwingen door middel van het toepassen van de juiste methodes en technieken. Deze aannamen zijn met recht ‘idealistisch’ te noemen. Ze zouden waar kunnen zijn, iedereen hoopt dat ze waar zijn, en managers zullen altijd beweren dat er in ieder geval naar wordt gestreefd. Iedereen die in de ICT werkt weet echter dat ze niet conform de realiteit zijn. Dat is de uiteindelijke reden waarom ook deze methoden vaak niet de vooruitgang leveren die ze beloven. Er is altijd een tekort aan mankracht, tijd en kennis. Men heeft maar (zeer) beperkt greep op de gebruikte technologie en doorlooptijd, uitkomsten zijn zeker niet perfect definieerbaar en resultaten laten zich niet afdwingen. Dat deze hindernissen er zijn, is niet zozeer het probleem. De kern van het probleem ligt in het feit dat de methoden en technieken er niet van uitgaan dat deze hindernissen bestaan. Feitelijk wordt er niet voldoende geleerd van de fouten uit vorige projecten. De kern is: men behandelt deze tegenvallende resultaten als incidenten en niet als symptomen van methodieken die slecht werken. Een aanzet voor een alternatieve benadering zonder deze foutieve aannamen is het pragmatisme. Het pragmatisme stelt dat men het moet doen met de observeringen die we doen in onze omgeving. Dit betekent dat we niet vanachter een bureau een theorie kunnen bedenken over hoe ICT werkt of zou moeten werken. Alleen waarnemingen en ervaringen uit de praktijk zijn een goede basis voor methodieken. Daarnaast wordt een theorie beoordeeld op het resultaat dat ermee wordt behaald. Een theorie die zeer waarschijnlijk klinkt maar in de praktijk geen resultaten oplevert, zal door een pragmatische bril worden betiteld als onjuist of zelfs als onwaar. Dat betekent het einde voor alle eenvoudige indelingen en theorieën. De weerbarstige werkelijkheid bij ICT-beleid en -beheer is dusdanig complex dat deze niet meer volstaan. De opvallende consequentie is het erkennen dat men maar beperkt greep heeft op deze werkelijkheid, zodat er nooit een garantie op succes bestaat binnen een gegeven tijd. Er is slechts sprake van het vergroten van de kans op succes. Deze meer pragmatische benadering komt men inmiddels steeds meer tegen. Zo wordt in het boek van R.Wagter een en ander over DYnamische Architectuur (‘DYA: snelheid en samenhang in business- en ICT-architectuur’) gesproken, over het bewust ontwikkelen zonder architectuur. Er worden situaties benoemd waarin het verantwoord en verstandig is juist zonder architectuur te ontwikkelen. Ook wordt het pragmatische principe ‘just enough, just in time’ verdedigd, wat wil zeggen dat architectuur alleen ontwikkeld moet worden als daar een concrete vraag naar is voor het realiseren van business-doelen. Ook bij ‘quick and dirty’-ontwikkelingsmethodes (of het opkomende ‘extreme programming’) zijn een voorbeeld van een pragmatische kijk op ICT-projecten. Daarbij wordt immers niet van tevoren veel tijd verspild met het nadenken over wat men eigenlijk wil ontwikkelen, men begint simpelweg met ontwikkelen, samen met een ervaren gebruikersgroep. Vanzelfsprekend is deze pragmatische kijk op ICT-ontwikkelingen en -beheer nog niet veel meer dan een aanzet tot een alternatief. Maar in ieder geval zal met een pragmatische benadering altijd een realistischere kijk op ICT ontstaan, zodat er minder irreële verwachtingen worden gecreëerd en men meer greep krijgt op het ICT- beleid en -beheer. Drs. Menno N. Rasch werkt voor de Utrechtse maatschap 3namiek, die zich richt op interdisciplinair onderzoek en advisering op het raakvlak van ICT en organisatie (menno@3namiek.nl).