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