Doordat mislukte ict-projecten regelmatig de krant halen, lijkt het onmogelijk om succesvolle ict-projecten uit te voeren. Het is waar dat er nog steeds (te) veel ict-projecten de eindstreep niet halen, maar er zijn er genoeg die succesvol worden afgerond en juist daar kunnen we veel van leren. Daarom een aantal observaties die kunnen helpen om nog meer ict-projecten succesvol te laten zijn.
Laten we bij het begin beginnen, want uit veel analyses blijkt dat daar vaak al de kiem gelegd wordt van het succes, of van het ontbreken ervan. Een eerste vaststelling is dat pure ict-projecten heel erg zeldzaam zijn. Een organisatie wil iets veranderen of verbeteren en heeft daar ict voor nodig. Hoewel de bijdrage van ict steeds groter wordt is deze vrijwel nooit 100 procent. Hoe goed het ict-project ook is uitgevoerd, het is pas succesvol als de volledige verandering of verbetering succesvol is.
Een succesvol ict-project heeft zicht op de omgeving waar het onderdeel van is. Zelfs als opdrachtgevers expliciet vragen om een strakke focus op het ict-project heb je meer kans op een succesvol project als je zicht houdt op de hele omgeving.
Bestaat niet
Zoals gezegd zijn pure ict-projecten zeldzaam. Daarom is het ook goed om de financiële impact van het ict-project op een succesvolle verandering of verbetering in de organisatie in beeld te hebben. Als een project langer duurt of meer kost dan oorspronkelijk begroot is een aanpassing van de scope een veel gehanteerde middel om het project binnen de afgesproken tijd en geld te houden. Toch is dit niet altijd de beste oplossing, omdat de business case van de totale verandering of verbetering gebaseerd is op de volledige scope van het ict-project. Voor de totale organisatie kan een latere en/of duurdere oplevering weleens een succesvollere oplossing zijn dan dat je een project oplevert met een beperkte scope.
Doel
Een ict-project levert een bijdrage aan een verandering of verbetering in de organisatie. Dat is het echte doel. Als dat doel verandert moet je je afvragen of het project nog zin heeft. Op tijd stoppen levert de organisatie een beter resultaat dan tegen beter weten in het project afmaken. Als dat echte doel helder is, zijn onduidelijkheden in requirements makkelijker op te lossen en is prioriteit in de backlog helder.
Bij kleinere projecten ligt het doel vaak dichterbij. De relatie tussen het ict-project en de gewenste verandering of verbetering is dan goed zichtbaar. Daarom zijn kleine projecten ook vaker succesvol dan grote.
Eigenaar
Bij veel ict-projecten wordt de eigenaar van het product of de dienst waar het project een bijdrage levert de opdrachtgever van het ict-project. Daarbij wordt vaak niet gekeken of deze persoon wel voldoende tijd heeft of de juiste skills en competenties bezit om opdrachtgever te zijn. Hij moet voldoende invloed en mandaat hebben om te kunnen besluiten of besluitvorming tot stand te brengen, hij moet tussen de organisatie en het project betrokkenheid kunnen creëren en resultaatgericht zijn. Dit is iets heel anders als het managen van de dagelijkse operatie rondom een product of dienst. Bij succesvolle ict-projecten is de opdrachtgever in staat om het opdrachtgeverschap te combineren met lijnmanagement, of is er een speciale opdrachtgever aangesteld met voldoende invloed en mandaat met alleen focus op het gewenste resultaat.
Focus
Succesvolle ict-projecten leveren de belangrijkste dingen eerst en extra zaken later. Een reden waarom sommige projecten niet succesvol zijn is dat er te veel tijd gaat zitten in het werkend krijgen van functionaliteit die weinig impact heeft op de bedrijfsvoering. Moeten alle mogelijke uitzonderingsgevallen worden geautomatiseerd of is het acceptabel dat je complexe zaken in een aparte stroom door menselijke specialisten laat afhandelen? Succesvolle ict-projecten maken gericht gebruik van de tachtig/twintig regel en leveren eerst de belangrijkste functionaliteit op.
Dat hoeft niet per se Agile. Voor processen of diensten met een lange doorlooptijd kun je gericht beginnen met het realiseren van de invoer- of bestelmodule. Vervolgens kun je zonder tijdsdruk complexe koppelingen met de rest van het applicatielandschap maken.
De laatste waarneming is niet per se noodzakelijk voor een succesvol resultaat. Uit onderzoek blijkt wel dat het goed is voor een kwalitatief nog beter resultaat:
Leuk
Door de Software Improvement Group is recent onderzoek gedaan naar de relatie tussen de kwaliteit van het teamwork en de effectiviteit en efficiëntie van de teams. In dit onderzoek zijn 29 teams met in totaal 199 teamleden uit achttien verschillende organisaties onderzocht. Hieruit bleek dat er een relatie bestaat tussen goed functionerende teams en betere resultaten.
Probeer het zelf eens uit. Neem een succesvol en een niet succesvol ict-project in gedachten en loop de bovenstaande punten maar eens na. Ik lees graag je reactie.
Ewout,
Ik heb het even nagekeken of ik daar een uitspraak over kan doen. Als ik kijk naar de projecten waar ik zicht op heb kan ik daar niet een type project of een sector uithalen waar structureel meer of minder succesvolle projecten lopen. Ik heb wel een paar vermoedens. Ik heb het niet echt onderzocht, dus ik durf niet te beweren dat dit de echte redenen zijn:
Wat ik zie is dat complexe trajecten wat minder vaak succesvol zijn. Ik vermoed dat dat ligt aan het grote aantal betrokken partijen aan de opdrachtgeverskant en het grote aantal betrokken specialismen aan de opdrachtnemerskant. Een gebrek aan focus en/of eigenaarschap.
Ook zie je een bepaalde mate van organisatiegevoeligheid. Bij sommige organisaties zijn meer succesvolle projecten dan bij andere. Dat kan soms per afdeling/divisie/dienst verschillen. Ik vermoed dat daar vooral het mandaat van de opdrachtgever een sterke rol speelt.
Frank,
Mijn ervaring is dat de ict-projecten mislukken omdat de omvang van verandering en de complexiteit onderschat worden, doelstelling niet reeel is en de ambitie groter is dan de capaciteit van de organisatie en de werkelijkheid waar de organisatie zich in bevindt.
Neem bijvoorbeel een ict-project van een samenwerkingsverband tussen twee gemeenten. In dit kader worden niet alleen de ict zaken geraakt maar ook de organisatorische aspecten van twee gemeenten. Wanneer je verschillende componenten uit dit veranderingstraject uit elkaar trekt en wanneer je als opdrachtgever meer tijdvrij maakt voor elke component(gefaseerd uitvoeren) dan kun je altijd deze veranderingen beheerst in goede banen leiden, risico`s verkleinen, meer ruimte creeren om indien nodig de doelstelling bij te stellen en kortom de successfactoren vergroten.
Wanneer het effect van verandering en de complexiteit van het project onderschat worden waardoor de doelstelling van het project niet meer haalbaar is dan horen we direct “weer een ict-project dat mislukt is”
@Frank Vogelezang, 13-09-2013 10:19
“Als je moet kiezen tussen wachten en mislukken, wat doe je dan?”
De vraag is wat scherp gesteld, maar (zoals Reza in feite zegt) als succes afhankelijk wordt van uitstel, dan zit er wat verkeerd in je planning.
Mijn ervaring met mislukte ict-projecten hebben vooral te maken met gefragmenteerde organisaties: een groot aantal betrokken partijen (zowel intern als extern) in verschillende tijdzone’s, zware en trage change mechanismen (vooral tussen interne en externe partijen) en personeel bij outsourcing companies met een hoog verloop en onvoldoende kennis.
Goed om te zien dat je reageert op de reacties alhier.
Frank,
Misschien snap ik het niet maar als je iets wilt verbeteren is het handig als je weet waar het knelpunt zit, in reacties lijkt me een heleboel expertise en ervaring naar voren te komen. Misschien nog niet voldoende voor een wetmatigheid maar……
P.S.
Succes kent vele vaders maar mislukking blijft vaak een wees.
Frank,
Is er in het onderzoek ook nog iets naar voren gekomen t.a.v. het maken van modellen. Ik kan me voorstellen dat als je voordat je een IT project start snapt hoe de business in elkaar steekt, je dezelfde taal als de business spreekt (semantisch model) en je snapt hoe de processen lopen (procesmodel) dat je dan beter in staat bent om technologie succesvol te implementeren.
Tim,
Heb je het over “sectorkennis”? of wel:
https://www.computable.nl/artikel/opinie/management/4551069/2379250/gezocht-projectmanager-als-kameleon.html
Aan Tim en Reza, volkomen gelijk. Mocht ik met al mijn Erp ervaring ( uitgezonderd financiële modules) een boekhoudpakket ontwerpen, dan bestaat de kans dat dit computertechnisch beter in elkaar steekt, snel en soepel werkt, maar dat negen enkele boekhouder daar kan of wilt werken. Branchenkennis is een must, geholpen door een goede analyse en duidelijk scoop.
Ewout,
Je hebt gelijk dat het handig is om te weten waar het knelpunt zit. Ik was daar ook mee begonnen, maar dan wordt het de zoveelste zwanenzang over mislukkende ICT-projecten. De redenen kennen we . . en toch lijkt dat weinig te helpen. Vandaar dat ik het eens van de andere kant heb willen benaderen door te kijken wat succesvolle ICT-projecten gemeen hebben.
Als de vaders daardoor voor alle kinderen gaan zorgen en niet alleen voor de succesvolle scheelt dat misschien een aantal wezen.
Reza en KJ,
Het is een feit dat veel ICT-projecten mislukken door zaken die (vanuit de ICT gezien) niet strikt een onderdeel zijn van het ICT-project. Als het project vervolgens mislukt is het weer een voorbeeld van een mislukt ICT-project. Maar echte ICT-projecten zijn zeldzaam. Het voorbeeld dat Reza noemt is daar een heel goed voorbeeld van. Twee gemeenten besluiten dat samenwerken een goed idee is. Een ICT-project is dan een onderdeel van een grote organisatorische verandering. Als je je daar niet bewust van bent, of je alleen focust op de opdracht om twee ICT landschappen samen te voegen, is er een grote kans dat je een niet succesvol project gaat doen.
Dat geldt overigens niet specifiek voor ICT-projecten. Ik denk wel dat ICT-projecten meer dan andere typen projecten last hebben van het feit dat ze een onderdeel zijn van een groter geheel. Daarom heb ik de succesfactoren om daar oog voor te hebben bovenaan mijn lijst gezet.
Tim, Reza en Jos,
Het hebben van kennis van de materie en het spreken van de taal van de business is inderdaad een factor die nog aan mijn rijtje toegevoegd had kunnen worden. Of je dat doet door mensen met kennis in je project te hebben, het te modelleren zoals Tim voorstelt, of borgt dat de klant zorgt dat de juiste kennis beschikbaar is, zoals Reza in zijn artikel schrijft maakt denk ik niet zo veel uit. Maar kennis van de materie is zeker belangrijk. Er zijn best wel niet succesvolle ICT-projecten aan te wijzen die volgens het recept dat Jos schetst tot stand zijn gekomen.