Je leest er geregeld over in kranten en vakbladen: grote en dure automatiseringsprojecten die voor nogal wat problemen zorgen. Denk bijvoorbeeld aan vertraging bij de ontwikkeling en implementatie van een systeem, overschrijding van het geplande budget of een tegenvallende functionaliteit. Soms mislukken projecten zelfs faliekant en wordt een systeem niet eens in gebruik genomen. Uit research van marktonderzoeksbureau Standish Group blijkt zelfs dat slechts een minderheid (circa zeven procent) van de grote ICT-projecten uiteindelijk uitdraait op een succes. Als de zeer grote ICT-projecten buiten beschouwing worden gelaten, rijst er een duidelijk positiever beeld op uit de cijfers.

Maar hoe komt het dat juist de grote IT-projecten zo vaak tot mislukken zijn gedoemd? Wat zijn de belangrijkste problemen en pijnpunten? En wat kunnen we hiervan leren om dergelijke projecten beter aan te pakken? In dit blogartikel geven wij onze visie op deze problematiek.

<21 class="title">Oorzaken van falende IT-projecten

Er zijn in de praktijk diverse factoren die bijdragen aan het falen van IT-projecten. We zetten de belangrijkste voor je op een rij.

Grote ambities, verkeerde uitvoering

IT-projecten worden van tevoren vaak heel groots en ambitieus neergezet. Op zich is er natuurlijk niets mis met ambitie. Maar de weg die wordt bewandeld om die ambitie te vervullen, leidt in de praktijk vaak tot verschillende, soms zelfs sterk contrasterende visies. Door die verschillende visies worden er vaak geen heldere probleemdefinities, doelstellingen en eisen geformuleerd. Het gevolg: er ontstaat onduidelijkheid over de scope en kerndoelstellingen van een project.

Bij EsperantoXL geloven we daarom veel meer in een stap-voor-stap-aanpak. Omdat veel IT-projecten in beginsel te groots zijn opgezet, mis je uiteindelijk flexibiliteit. Dit maakt het lastig om in te springen op actuele marktontwikkelingen of technische noviteiten. Door een IT-systeem stap voor stap te ontwikkelen en te implementeren, wordt bijsturen een stuk gemakkelijker. Bovendien loop je zo ook minder kans op een financiële strop of vertraging van het project.

Een teveel aan complexiteit

De expertise die je nodig hebt om een project succesvol af te ronden, neemt toe naarmate een project complexer en grootschaliger wordt. Nieuwe technologie, het gebruiken en aanpassen van interfaces met andere bedrijfssystemen of het herontwikkelen van legacy-processen zijn aspecten die het moderne IT-landschap steeds complexer maken. Maar juist omdat IT-projecten steeds ingewikkelder worden, nemen ook de risico’s toe die ontstaan als je de juiste kennis niet in huis hebt of de omvang van een project verkeerd inschat. Dit besef ontbreekt soms bij managers, waardoor projecten het aanwezige kennisniveau binnen een organisatie overstijgen en onbeheersbaar worden. Het onderzoek van Standish Group wijst duidelijk uit dat de uitbreiding van complexiteitsonderdelen als ondernemingsomvang en systeemomvang bijna altijd leidt tot een toename van de totale projectomvang.

Gebrek aan executive management

Bij grote projecten zijn ook veel verschillende stakeholders betrokken. Die betrokkenen hebben allemaal hun eigen agenda en soms verschillende verwachtingen van de voordelen en functionaliteiten die nieuwe systemen opleveren. Om al die mensen toch op één lijn te krijgen, is goed en daadkrachtig executive management een absolute vereiste. Als het management van bovenaf te wensen overlaat, en niemand echt de regie durft te nemen, bestaat het gevaar dat er conflicten ontstaan tussen stakeholders. Partijen zijn het dan veelal niet eens over gewenste specificaties. Dergelijk zwak ownership leidt vaak tot gemiste deadlines, vertragingen in de planning, ontwikkelings- en implementatieproblemen of overschrijdingen van het budget. Ontwerpen worden door de bovenstaande problemen bovendien geregeld niet tijdig goedgekeurd of zelfs helemaal afgekeurd.

Een teveel aan bureaucratie kan eveneens een belemmering zijn voor goed projectmanagement. Beslissingen moeten in zo’n geval langs een te groot aantal mensen om goedgekeurd te worden. Dit gaat ten koste van de flexibiliteit. Ook de kosten van een project kunnen uit de hand lopen door de betrokkenheid van een overdaad aan mensen. Bij EsperantoXL werken we daarom liever met kleine en deskundige projectteams. Zo blijft een project overzichtelijk, zijn de communicatielijnen kort en kan er snel en flexibel worden ingespeeld op veranderende wensen, eisen en bedrijfsprocessen.

Het ontbreken van betrokkenheid bij gebruikers in een project

Een hoge complexiteitsfactor, slecht gedefinieerde projectdoelstellingen en een gebrekkig management zijn ook niet bevorderlijk voor de betrokkenheid van gebruikers bij de uitvoering van een IT-project. Om een IT-project te laten renderen, is een goede wisselwerking tussen de automatiseerder en gebruiker een absolute vereiste. Als gebruikers bijvoorbeeld regelmatig te maken krijgen met uitval of bij elke kleinigheid contact moeten opnemen met de ontwikkelaar, ontstaan er vanzelf irritaties die al snel kunnen uitmonden in algehele ontevredenheid.

Om de betrokkenheid te vergroten, is het ook belangrijk om de verwachtingen en bevindingen van gebruikers geregeld te evalueren. Komen de vooruitzichten overeen met de daadwerkelijke ervaringen? Wat werkt wel naar tevredenheid en wat niet? En wat zijn de belangrijkste verbeterpunten? Door je als automatiseerder en bedrijfsmanagement dat soort vragen te stellen, houd je continu de vinger aan de pols en betrek je gebruikers actief bij het IT-project.

Gebrek aan duidelijke bedrijfsdoelstellingen

Ook de scope en het doel van een IT-project kunnen vaag worden als je het project te ambitieus neerzet. Een manager start het project met een heldere doelstelling. Maar als het ontwikkelings- en implementatieproces vordert, komen er vaak mensen bij die ook hun ideeën te berde brengen en invloed op het concept uitoefenen. Hierdoor worden bedrijfsdoelstellingen gaandeweg onduidelijker, wat vaak leidt tot een te brede scope en een gebrekkig projectontwerp. Als een systeem niet volledig of onjuist is gespecificeerd, heeft dat onmiddellijk gevolgen voor de planning, kosten en kwaliteit van het project. Het is dus belangrijk om, in nauw overleg met de technische experts, vast te stellen wat een systeem nou precies moet doen en hoe het aansluit op je belangrijkste bedrijfsdoelstellingen.

Hoe voorkom je dat grote IT-projecten falen?


Nu we meer inzicht hebben in de redenen achter het falen van grote IT-projecten, is het tijd om te kijken hoe je mislukkingen het beste kunt voorkomen. Ons advies is vooral om van start te gaan met wat je minimaal nodig hebt in de vorm van een minimal viable product (MVP). Dit is de eerste versie van een dienst of product die zo snel mogelijk kan worden uitgerold naar de klant.

Een MVP bevat in elk geval de basisfactoren (de aspecten of functionaliteiten die minimaal nodig zijn om een klant tevreden te stellen), eventueel al aangevuld met een aantal prestatiefactoren (factoren die niet per definitie essentieel zijn, maar wel invloed hebben op de klanttevredenheid). In een later stadium kun je hier nog wow-factoren (niet direct noodzakelijke, maar wel mooie extra functionaliteiten) aan toevoegen. Een MVP heeft als voordeel dat de klant al in een vroeg stadium feedback kan leveren op het ontwerp. Zo weet je snel welke keuzes in de smaak vallen en welke functionaliteiten in het vervolgtraject de hoogste prioriteit moeten krijgen. Die functionaliteiten kunnen vervolgens worden toegevoegd aan het product-backlog.

Beginnen met wat je minimaal nodig hebt, levert op operationeel gebied de nodige voordelen op. We bespreken ze hieronder even kort.

  • Kleinere, maar zichtbare successen leiden op termijn tot meer draagvlak binnen de organisatie. Als medewerkers tussentijds concrete resultaten zien, zullen ze eerder overtuigd raken van de wenselijkheid en noodzaak van het IT-project.
  • Door klein te beginnen en langzaam uit te bouwen, kan de organisatie stap voor stap wennen aan het nieuwe IT-systeem.
  • Werken met een MVP-aanpak geeft je de mogelijkheid om resultaten sneller te toetsen en tussentijds zaken bij te sturen.
  • Het wordt gemakkelijker om in te spelen op actuele marktontwikkelingen en -veranderingen. Ontwikkelingen in het IT-landschap gaan namelijk zo snel dat een systeem spoedig achterhaald kan zijn als het niet tussentijds wordt aangepast aan de digitale actualiteit.

Pijnpunten bij RPA-projecten


Het is ook goed om even in te zoomen op veelvoorkomende pijnpunten die optreden bij specifieke soorten IT-projecten zoals Robotic Process Automation (RPA) en Rapid Application Development (RAD). In het geval van RPA maakt een bedrijf gebruik van softwarerobots om repetitieve taken en processen te automatiseren. Omdat zo’n robot feitelijk een virtuele medewerker is, moet je goed nadenken over de vraag hoe je hem inpast in de organisatie. Zo moet je medewerkers trainen in het werken met de robots om het beste uit RPA te halen.

Daarnaast heb je bij een RPA-project natuurlijk ook te maken met uitdagingen op het gebied van veiligheid, privacy en compliance. Het gevaar bestaat dat hier niet genoeg aandacht aan wordt besteed bij het opstellen en formuleren van je belangrijkste projectdoelstellingen. Let dan ook altijd op de onderstaande punten bij een RPA-project.

  • Verzeker je ervan dat de softwarerobots en RPA-structuur goed beveiligd zijn tegen hacks. Zorg dus voor een goede encryptie van data. Let ook op de aanwezigheid van voldoende logging om aanvallen en problemen tijdig te detecteren.
  • Geef de robots niet meer rechten dan ze nodig hebben voor het uitvoeren van hun primaire en essentiële taken.
  • De softwarerobots moeten adequaat om kunnen gaan met onverwachte problemen en crashes.

Juist door kleine stappen te maken, leer je sneller en wordt het gemakkelijker om het geleerde snel toe te passen en om te zetten in functionaliteiten met meerwaarde. Onze RPA-visie gaat dan ook uit van klein beginnen, en pas daarna versnellen en opschalen. Vergelijk het met een zware sportprestatie: ongetraind en onvoorbereid een marathon lopen lukt ook niet.

Pijnpunten bij RAD-projecten


Een typisch kenmerk van RAD-projecten is dat er vaak wordt gewerkt met low-code en no-code. Een potentieel pijnpunt hierbij is dat je als organisatie continu mensen moet meevoeren in de wereld van citizen development (mensen met beperkte IT-kennis die zelf applicaties ontwikkelen). Je medewerkers moeten dus aan de slag met low- en no-code, wat in eerste instantie best intimiderend kan zijn als je geen doorgewinterde IT-expert bent.

Toch zijn er wel goede manieren om het beste uit citizen development te halen. Een paar tips.

  • Kies een gebruiksvriendelijk en gemakkelijk te begrijpen platform zoals Betty Blocks of WEM.
  • Zorg voor een goede kruisbestuiving tussen citizen developers en de IT-afdelingen. Dat kan door de eerste groep de noodzakelijke tools te geven en de IT-afdeling tevens nauw te betrekken bij het ontwikkelen van nieuwe applicaties. Op die manier kan het project van een citizen developer ook eenvoudig worden overgezet naar een IT-afdeling.
  • Benut de expertise van verschillende typen citizen developers zoals line-of-business-ontwikkelaars, business developers (zakelijke experts met een technische inslag) en power users (parttime-ontwikkelaars die in hun vrije tijd apps bouwen voor eigen gebruik of het stroomlijnen van taken).

Ook hier brengt een stapsgewijze aanpak uitkomst. Door het IT-project stap voor stap uit te rollen, raken mensen al werkend en lerend bekend met de bijzonderheden van RAD. Daarnaast leidt het werken in kleine stappen tot meer draagvlak onder de eigen mensen om met het project in de weer te gaan.

Conclusie: denk groot, maar handel klein


Er zijn verschillende redenen waarom grote IT-projecten geregeld mislukken. In de kern gaat het meestal om de volgende problemen:

  • de complexiteit of scope van een project wordt verkeerd ingeschat;
  • het executive management heeft niet genoeg oog voor zijn ‘ownership-rol’;
  • gebruikers worden onvoldoende betrokken bij het IT-project;
  • bedrijfsdoelstellingen worden niet duidelijk omschreven of onvoldoende gekoppeld aan de technische eisen van het project.

Veel van de bovenstaande problemen zijn te voorkomen door IT-systemen stap voor stap te ontwikkelen. Begin met wat je minimaal nodig hebt en voeg de verdere functionaliteiten gaandeweg het ontwikkelingsproces toe. Zeker in het geval van RPA en RAD kan de gebruiker zo gedurende het proces feedback geven en voor optimale bijsturing zorgen.

Ben je benieuwd naar onze werkwijze en wil je weten hoe wij jou kunnen helpen bij het opzetten en uitvoeren van jouw IT-project? Neem dan gerust vrijblijvend contact met ons op. Ons streven is namelijk altijd om jouw organisatie in digitale topvorm te brengen!

FAQs


Wat is het beste low-code platform?

Volgens onderzoeksbureau Gartner behoren Betty Blocks, Mendix en OutSystems tot de beste low-code platforms.

Wat is een low-code framework?

Een low-code framework biedt een raamwerk voor softwareontwikkeling waarbij programmeurs op een visuele manier applicaties modelleren en weinig tot geen code hoeven te schrijven.

Waarom is low-code de toekomst?

Low-code heeft de toekomst omdat de methode toelaat op een heel visuele en intuïtieve manier applicaties te ontwikkelen, waarbij je weinig tot geen code hoeft te schrijven. Zo kunnen bedrijven veel sneller applicaties inzetten die inspelen op de noden van klanten.

Agile versus waterval

In deze Whitepaper vertellen we wat het verschil is tussen de waterval aanpak en agile werken.

Lees meer
Bram Berkelaar

Bram Berkelaar

CEO

Wil je meer weten over dit onderwerp? Neem dan contact met ons op.
Wij kunnen je er meer over vertellen.

Gerelateerde Blog


toon alles