Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het redactionele gedachtegoed van de redactie.

Succesvolle ICT-projecten bestaan echt wel

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.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/4860569). © Jaarbeurs IT Media.
?

 

Reacties

Voor mijn beleving staat de kans in het slagen van een IT project recht evenredig met het aantal managers die zich er inhoudelijk op technisch vlak mee bemoeit hebben.

Leuk verhaal maar ik mis een belangrijk aspect.
Gebrek aan visie, Gebrek aan talent, Gebrek aan gekwalificeerde mensen.

Ofwel, projecten die zich enkel van mensen en methodieken gebruiken die tegenwoordig ongeveer facto standaard zijn in plaats van te kijken welke technologie (en daarmee dus mensen) nu echt geschikt zijn om een project te starten.
Een werkwijze die veelal is gestoelt op 'Maar iedereen doet dat toch zo' of 'Maar ik kan geen mensen vinden die deze technologie beheersen'
Ach ja... laat maar gaan....

Ik heb me geprobeerd te focussen op factoren die wel goed gaan.

Als een hele rij managers de kans krijgt zich er mee te bemoeien is er waarschijnlijk geen sprake van goed eigenaarschap en waarschijnlijk ook onvoldoende focus.

Gebrek aan visie, talent en gekwalificeerde mensen volgt in mijn beleving ook uit onvoldoende ingevuld eigenaarschap. Als je echt eigenaar bent van een project dan heb je visie en accepteer je niet dat er talentloze ongekwalificeerde mensen in jouw project een rol van belang spelen.

@Pascal
Vooral dat laatste: gebrek aan gekwalificeerde mensen. Ik zie zo vaak dat de selectie van de bij het project betrokken technici vaak als een soort "afterthought" plaatsvindt in de trant van: "o, zet maar even uit bij een recruiter". Vervolgens vergeet men aan de kandidaten te vragen of deze ervaring hebben met de gebruikte technologie. Laatst nog een goedkope (want selectie vind plaats op basis van prijs) Windows man op een Unix project gekregen .. erg vermoeiend.

KJ, zelf ook recentelijk weer een staaltje van dergelijke stuurmanskunst gezien, zonde van de investeringen.

@Frank, ik begrijp je opmerking, ik denk echter dat je in deze vergeet dat een eigenaar soms wel weet wat hij graag zou willen maar niet hoe hij dat voor elkaar moet krijgen. In een wereld waarin glitter en glamour (en natuurlijk vooral de prijs) bepalend zijn kan het nogal eens voorkomen dat verkeerde keuze worden gemaakt.

Frank,

graag voeg ik aan deze reacties toe dat op 4 oktober een 'Teamperformance College Tour' georganiseerd wordt op de Universiteit Tilburg waarin bovengenoemde onderzoek verder besproken wordt.

Zie Computable agenda : http://www.computable.nl/content/agenda/4870558/1589222/college-tour-towards-high-performance-software-teamwork.html.

Michiel

Frank,
Het was me niet duidelijk geworden of ik dit artikel door de bril van opdrachtgever moest lezen of opdrachtnemer.

De doelstelling en succesvolle afronding van een ict-project voor een opdrachtnemer en opdrachtgever kunnen verschillend zijn.

Frank,

Zou je aan kunnen geven in welk deel van de ICT je de meeste succesvolle projecten ziet?

Ik stel vraag naar aanleiding van eerdere discussie over requirements en de stakeholders;-)

Pascal en KJ,

Ik herken de frustratie over de slechte bemensing van projecten. Ik heb daar ook geen pasklare oplossing voor. Ik constateer dat het een factor is die van groot belang is om een project succesvol te laten zijn. Ik denk ook dat iedereen dat wel met me eens is . . en toch gebeurt het niet. Er zijn vaak ook wel goede redenen voor waarom het niet lukt, maar je zou je moeten afvragen of je dan je project wel moet starten. Ik ben een tijd functioneel eigenaar geweest van een technisch best complexe applicatie. Daar had ik de luxe dat releases niet tijdkritisch waren en ik kon wachten tot de developer beschikbaar was die volledig was ingewerkt op de complexiteit van de applicatie. Die afweging wordt maar zelden gemaakt. Als er al over wordt nagedacht dan hoor ik: "Die luxe hebben we hier niet."

Als je moet kiezen tussen wachten en mislukken, wat doe je dan?

Reza,

Voor een succesvol project heb je zowel de opdrachtgever als de opdrachtnemer nodig.

Het zicht op de omgeving (bestaat niet) is vooral een aansporing voor de opdrachtnemers om verder te kijken dan alleen het ICT-project. Bij organisaties die gebruik maken van een regie-organisatie die opdrachtgever is voor de ICT-projecten geldt die aansporing ook voor de (gedelegeerd) opdrachtgever.

Het zicht op het echte doel geldt voor beide kanten. Aan beide kanten is lef nodig om de stekker uit een ICT-project te trekken dat niet meer bijdraagt aan een gewijzigd doel.

De sterke eigenaar geldt uiteraard vooral voor de opdrachtgever. Niet alle organisaties beseffen dat een opdrachtgever voldoende mandaat moet hebben om zijn werk te kunnen doen. Voor opdrachtnemers is het lastig om dat probleem bespreekbaar te maken.

Focus geldt voor beide kanten. Zonder focus neemt het risico toe dat een project gaat zwabberen of dat er zich teveel mensen mee gaan bemoeien.

Leuk zoals ik het bedoel is vooral voor de opdrachtnemer. Maar ik kan me niet voorstellen dat een project er slechter van wordt als de opdrachtgever plezier heeft in die rol.

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:

http://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.

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.

Het valt op dat deze discussie zonder directe aanleiding om de zoveel maanden weer opduikt, en dan gelijktijdig in diverse media.

Dit onderwerp - 'Succes- & Faalfactoren van projecten', en 'Project Recovery' - bestaat inmiddels al zo'n 20 jaar***.
De literatuur is er, de onderzoeken zijn er, de rapporten zijn er.

Een paar toppers :
- requirements : SME'ers en architecten zijn niet betrokken in voortraject
- usability : eindgebruikers worden niet betrokken
- functionaliteit : testmanagement is niet betrokken in voortraject
- CFI ; aanbesteding voor laagste prijs leidt enige tijd later tot duur transitie-traject (ik heb er diverse gedaan)
- bij de 'oplossing' wordt niet nagedacht over een rol-back (terug naar oude situatie) of transitie (migratie naar andere situatie of leverancier)
- beheerders (funct. & techn.) : zijn niet betrokken in voortraject
- Lessons Learned : worden niet gebruikt in het voortraject, en niet gemaakt bij project-closure
- risicomanagement (bus. & proj.) : wordt niet of nauwelijks gedaan
- er is nooit tijd/geld om het goed te doen, maar altijd tijd om het over te doen

En de allerbelangrijkste : opdrachtgeverschap.
De 'pijnhebber' start het project en trekt asap zijn handen er vanaf, bij oplevering is toch iemand anders de 'pijnkrijger'.
Bovengenoemde punten - en meer - zijn hierop terug te voeren.

____________________
*** zo lang ga ik er al in mee.

Beste P.J.

Ik ben het niet helemaal met je eens. Ik kom nog net niet aan de twintig jaar, maar meestal gaat het over de faalfactoren. Als je die omdraait kom je wel op succesfactoren, maar dan ga je toch uit van het negatieve en blijkbaar zijn we daar wat immuun voor geworden. Bij het schrijven van dit stukje viel het me op hoe lastig het is om juist de succesfactoren te benoemen.

Verder herken ik inderdaad het rijtje faalfactoren dat je noemt. Vanuit het benoemen van de faalfactoren lijken we de afgelopen twintig jaar niet veel opgeschoten te zijn. Toch zie ik wel lichtpuntjes. Eén daarvan is het gebruik van BVP als aanbestedingsmiddel. Geen woud aan zinvolle en minder zinvolle requirements, maar een heldere probleembeschrijving die de opdractnemer op mag lossen. Ik durf niet te beweren dat het een wondermiddel is, maar door de opdrachtnemer mede eigenaar van het projectsucces te maken wordt de kans op succes een stuk groter.

Computable Expert
Frank  Vogelezang

Frank Vogelezang
Senior IT Benchmarking Consultant, Metri IT Benchmarking. Expert van Computable voor de topics Management, Outsourcing en ERP.
Hele profiel

Lees meer over:
Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×