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.
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.