6 Manieren om een IT project te laten mislukken
In mijn praktijk als gerechtelijk deskundige kom ik van alles tegen: van goed functionerende leveranciers met onredelijk afnemers, leveranciers die er een potje van maken, beloftes die niet waar gemaakt worden, kosten die de pan uitrijzen, doorlooptijden die niet gehaald worden en nog veel meer.
Uit al die probleemgevallen heb ik een paar manieren gedestilleerd die gegarandeerd een mislukt IT project opleveren.
1: Vage projectdetails zonder voorbeelden
Als gebruikers een nieuwe IT oplossing willen, is het zelden in detail duidelijk wat er moet komen “Dit XYZ moet geautomatiseerd worden”. En dat is niet verwonderlijk, want men moet in termen die men niet voldoende beheerst, specificeren wat er nog niet is.
Zo’n vage start staat garant voor een mislukt IT project.
In de minst slechte vorm wordt de bestaande werkwijze geautomatiseerd, maar daarmee haal je maar weinig winst. Het kan al beter worden als men voorbeelden verzameld van oplossingen die vergelijkbaar zijn, bijvoorbeeld in de vorm van een mood-board, iets dat bij ontwerpen in ander omgevingen veel vaker gebruikt wordt.
2: Slechte naamgeving en doelformulering
Een vage naamgeving van een project, bijvoorbeeld: “Snellere orderafhandeling”, levert een serieuze bijdrage aan een mislukking. Onduidelijk is wat het SMART meetbare resultaat moet zijn van het IT project. Een goede naamgeving, vergezeld van een duidelijk omschreven en objectief meetbaar doel van het IT project, maakt de kans op mislukken aanmerkelijk kleiner.
3: Onrealistische planning
Om een IT project te starten gaat men niet over één nacht ijs. En hoe omvangrijker het project, des te langer wordt er aan de afwegingen (doel, omvang, leverancierskeuze, budget) gesleuteld. Is men dan uiteindelijk zover en gaat men over tot de uitvoering, dan is het vaak niet zo dat de realisatie termijnen zijn opgeschoven: bijvoorbeeld het moet 1 januari live gaan. Combineer dat met het optimisme van sales mensen aand e kant van de leverancier en het onvoldoende gefundeerde optimise van de IT uitvoerders over de vermeende eenvoud van het project en de basis voor een mislukt project is verder vormgegeven.
4: Een website als Facebook voor EUR 1.000
Niet zelden heb ik de vraag voorbij zien komen: maar dat kan bij Facebook (of vul iedere andere website van een wereldspeler maar in) toch ook? Alsof de techniek die bij dat soort site gebruikt wordt eenvoudig voor iedereen zonder kosten beschikbaar is.
Als ik aan de kant van de leverancier sta in zo’n fase, dan is mijn antwoord:
Dat kan, doe mij het budget van Facebook dan maar
IT techniek is niet zo te dupliceren. Het feit dat iedereen de ontwikkeling van dergelijke sites ervaart en dat als vanzelfsprekende norm hanteert voor een eigen oplossing is een nagel aan de doodkist van een IT project.
5: Slechte budgettering en voortgangscontrole
Vol enthousiasme start een IT project. Gebruikers zijn vol verwachting, budget is nog onaangeroerd en lijkt ruim voldoende, de leverancier ziet dat als pot met goud aan het einde van de regenboog. Maar uit ervaring weet ik dat ieder project complexer is dan aan het begin was aangenomen.
Strakke bewaking van tijd, budget en gerealiseerde functionaliteit en vaak daaraan gekoppelde moeilijk keuzes om dingen niet te doen, zijn essentieel om het IT project niet te laten ontsporen. Een stevige projectleider bewijst hierbij zijn waarde. Zonder deze bewaking kom ik als gerechtelijke deskundige om de hoek kijken als het project is ontspoort.
6: “Het is niet zo ingewikkeld”
Dat is vaak de mening van de gebruiker en (in het begin) ook het idee van de automatiseerder die aan de slag gaat. Maar gaandeweg blijkt het altijd ingewikkelder en complexer, doordat in eerste fase alleen de “happy flow” is bekeken, terwijl het meeste werk gaat zitten in de uitzonderingen die onvoldoende in beeld waren bij de start.
Zeg eens: “Het is ingewikkeld proces” bij de start en kijk dan eens hoe men acteert.
Het alternatief voor geen mislukking
Een paar aandachtspunten zijn voorbij gekomen: duidelijke omschrijving, realistische budget en planning, strakke controle, enz. Maar ook een uitstekende oplossing is om, voordat het project begint, een onafhankelijke IT deskundige naar de opzet te laten kijken.
Vreemde ogen dwingen, zei mijn moeder altijd
En zo is het maar net.
Beter vroegtijdig recht gezet, dan achteraf voor het gerecht gezet