Een mislukt IT-project is geen IT-project

IT-projecten hebben de naam dat ze vaak mislukken. Daar kun je twee dingen over zeggen, zegt Bart Stofberg. Ten eerste: Er bestaan helemaal geen IT-projecten, hooguit zijn er businessprojecten met veel IT erin. Ten tweede: Wanneer vind je eigenlijk dat een project is mislukt? Over beide zaken bestaan veel misverstanden. Die hebben allebei te maken met het verschil tussen katten en wasmachines.

In zijn boek Antifragiel stelt Nassim Nicholas Taleb dat er eigenlijk maar twee soorten constructies zijn: katten en wasmachines. Als je het gedrag van een wasmachine wilt veranderen, pak je de tekening, je verwerkt je plan in de tekening en je voert de verandering door. Klaar. Als je het gedrag van een kat wilt veranderen, dan stel je jezelf een veranderdoel, je onderneemt acties en je kijkt wat het effect is van die acties. Daarna stuur je bij, je kijkt naar het effect en je stuurt nog een keer bij. Enzovoort. Tot je na een tijdje constateert dat je tachtig procent van je doel hebt gehaald en dat dat al heel mooi is.

Van IT-projecten kun je natuurlijk gemakkelijk zeggen dat het wasmachineveranderingen zijn, met het functioneel ontwerp als bouwtekening. En zo gaan we er meestal ook mee om. Alleen, IT-projecten bestaan natuurlijk helemaal niet. Als we IT-project zeggen, dan bedoelen we meestal een businessproject met een zware IT-component. Veel IT, maar natuurlijk nog wel steeds een businessproject. Die IT moet wel ergens toe leiden.

En een businessproject is natuurlijk altijd een katverandering, De meeste projecten met veel IT erin zijn complex, hebben invloed op de omgeving van medewerkers, managers en vaak klanten en andere stakeholders. Juist die complexiteit en al die mensen maken het project in hoge mate onvoorspelbaar. En dus een katverandering. Het IT-deel is verreweg het meest wasmachine-achtige stuk. Als je een project een IT-project noemt, maak je er eigenlijk al meteen een wasmachineproject van. Dan focussen we onszelf veel te veel op de IT en veel te weinig op al die mensen die door de verandering worden geraakt. En als die mensen ons verrassen, dan zeggen we dat IT-projecten altijd mislukken. Denk maar aan de OV-chipkaart. Dat project is mislukt omdat de reizigers geen zin hadden om vier euro te betalen als ze vergeten waren uit te klokken en omdat er ook mensen bleken te bestaan die het leuk vonden om de beveiliging te kraken. Wasmachinedenken in een katomgeving, dat is wat er echt misging.

Voorspelbaar

Als we blijven denken dat alles voorspelbaar is en maakbaar, dan zullen projecten blijven mislukken. Dan denken we dat het normaal is om te krijgen waar je op hoopt. Als we blijven denken dat het gedrag van de gebouwde IT voorspelbaar is, als we blijven denken dat het gedrag van medewerkers, klanten en andere stakeholders (hackers!) voorspelbaar is, dan zullen projecten steeds weer langer duren, meer geld kosten en minder opleveren dan we hadden gedacht. En dan zullen we blijven roepen dat IT-projecten altijd mislukken, vooral omdat het juist helemaal geen IT-projecten zijn.

Want wees eerlijk, hoe kom je en hoe besluit je tot requirements? Hoe besluit je dat je met de nieuwe IT goed kunt werken? Hoe kom je tot de juiste manier waarop we de nieuwe IT in de business gaan gebruiken? Hoe gaat de nieuwe werkwijze er uitzien en wat betekent dat voor medewerkers, klanten, gebruikers en anderen? Hoe vruchtbaar wordt de samenwerking tussen opdrachtgever en leverancier en wat zijn de consequenties daarvan op de nieuwe IT en op de nieuwe bedrijfsvoering? Kunnen we al die vragen van tevoren zo goed beantwoorden dat we vooraf een ontwerp kunnen maken dat overal in voorziet? Of beter nog, een ontwerp dat alles voorziet?

Nee, natuurlijk kunnen we dat niet. We kunnen de toekomst niet voorspellen. Zodra een project onvoorspelbare aspecten krijgt, wordt het een katveranderingsproject. Een complex systeem is niet meer voorspelbaar, medewerkers en managers met een belang en een verwachting zijn niet voorspelbaar, klanten, gebruikers en belangengroeperingen buiten de onderneming zijn niet voorspelbaar en de wereld waarin we leven is al helemaal niet voorspelbaar. Eigenlijk zijn alleen eenvoudige systemen die niet worden gebruikt door interne medewerkers, die geen gevolgen hebben voor klanten en de buitenwereld en die niet worden geraakt door gebeurtenissen buiten de onderneming, nog redelijk voorspelbaar te realiseren.

Meestal maken we het onszelf nog extra moeilijk. Om goedkeuring te krijgen voor een project, moet je vaak langdurig de voordelen van het project overdrijven en de nadelen bagatelliseren. Als je dan eindelijk toestemming krijgt, begin je eigenlijk al aan een kansloze opdracht. Te veel verwachtingen en te weinig budget. En een katveranderingsproject.

Zo’n katveranderingsproject moet je op een heel andere manier aanpakken. Een katverandering heeft een duidelijk doel en een duidelijke businesscase. Hoe groter de onvoorspelbaarheid van het project, hoe overtuigender de businesscase moet zijn. Om tegenvallers op te vangen. Doel en businesscase zijn leidend bij alles wat het project doet, bij elke keuze in het project kiezen we de optie die, via de businesscase, het beste bijdraagt aan het doel. In zo’n project heeft de projectleider geen budget, maar hij geeft eerlijk aan hoeveel hij nog verwacht nodig te hebben. Zijn planning is een verwachting, geen budget. Die verwachting is altijd actueel, dat is wat we nu, op basis van alle feiten, mogen verwachten. Zodat de stuurgroep, op basis van die eerlijke verwachting, kan besluiten om maar te stoppen met het project.

Niet mislukt

Projecten doen we meestal met behulp van PRINCE2. Die letters staan voor PRojects IN Controlled Environments. Die projecten bestaan helemaal niet meer, en als ze al bestaan, zijn ze niet zo spannend. Zodra het project invloed heeft op de wereld van mensen, houdt het project op een controlled environment te hebben. Eigenlijk moeten we snel overstappen op PRINCE3, PRojects IN Chaotic Environments. Een heleboel principes kunnen gewoon hetzelfde blijven, maar er zijn een paar grote verschillen. Bij PRINCE3 gaan we uit van onvoorspelbare projectleden, onvoorspelbare omgevingen en onvoorspelbare projectuitkomsten (denk aan de uitkomsten van een Sprint). In een PRINCE3-project houden we de omgeving goed in de gaten, kijken we wat de effecten zijn van onze interventies en sturen we voortdurend bij. In een PRINCE3-project hebben we geen budget, maar wel een eerlijke en actuele verwachting van de kosten. En verder hebben we in een PRINCE3-project natuurlijk nog gewoon een ideale stuurgroepsamenstelling, nog steeds een richtinggevende en meeveranderende businesscase en een zekere fasering. Natuurlijk stellen we nog steeds alles af op het doel en de businesscase en sturen we nog steeds op risico’s en afwijkingen.

Op die manier accepteren we dat het project minder voorspelbaar is dan we zouden willen, zodat we met z’n allen minder krampachtig om kunnen gaan met onze verwachtingen en ons geld.

Want waarom zou een project dat dertig procent over budget gaat per definitie zijn mislukt? Dat hangt er toch helemaal vanaf wat het project heeft opgeleverd? Als een onvoorspelbaar project dertig procent duurder is geworden dan we van tevoren hadden verwacht, maar het heeft toch nog steeds veel meer opgeleverd dan het heeft gekost, dan is het project toch juist heel erg geslaagd? Waarom zouden we dat mislukt noemen? Alleen omdat we niet willen accepteren dat verandering onvoorspelbaar is?

Vroeger, toen ik nog studeerde, stuurde ik heel strak op de kosten van mijn vakanties, zoveel geld had ik niet tenslotte. Als tegenwoordig mijn vakantie dertig procent duurder wordt dan ik had verwacht, is zij meestal veel meer dan dertig procent leuker geweest. En dan is die extra dertig procent de som van een heleboel bewuste keuzes geweest. Een dure extra boottocht door een natuurreservaat, een paar heel erg lekkere restaurants, een heel bijzonder, maar duur, museumbezoek en veel meer terrasjes dan gepland. Dat kun je dan toch geen mislukte vakantie noemen?

IT, emoties en EPD

Het Electronisch Patiënten Dossier (EPD) is een verzameling IT-toepassingen, waarin medische patiëntgegevens worden opgeslagen, opdat medische hulpverleners die kunnen raadplegen als dat nodig is. Technisch is gekozen voor een complexe structuur. Het project is gestart in 2008 en stilgelegd in 2010 en 2011. In 2011, 2012 en 2013 zijn rigoureuze veranderingen doorgevoerd in de scope van het project. Maar moet je het EPD nou een mislukt IT-project noemen? Onder andere de Eerste Kamer (toen de Tweede voor was), de Tweede Kamer en de Landelijke Huisartsen Vereniging waren tegen de gekozen invulling. Het College Bescherming Persoonsgegevens en de Inspectie voor de Gezondheidszorg maakten zich zorgen over de privacy-aspecten van het EPD.

Onder andere de Nederlandse Patiënten Consumenten Federatie en de Vereniging van Zorgaanbieders voor Zorgcommunicatie waren juist heel erg voor. Door de voortdurende commotie bleef het project een speelbal van maatschappelijke discussie, met de IT-planning in de hand. Een veranderaanpak, die was gebaseerd op katverandering, had vanaf het begin rekening gehouden met alle emoties, had daar adequater op gereageerd en was uiteindelijk veel productiever geweest.

Tag

Onderwerp



Niet gevonden? Vraag het de redactie!

Heeft u het antwoord op uw vraag niet gevonden, of bent u op zoek naar specifieke informatie? Laat het ons weten! Dan zorgen we ervoor dat deze content zo snel mogelijk wordt toegevoegd, of persoonlijk aan u wordt geleverd!

Stel uw vraag