We staan aan de vooravond van economisch herstel. Om toekomstbestendig te worden en te blijven, zetten organisaties in op innovatie. Dit heeft tot gevolg dat het aantal projecten met een grote it-component flink toeneemt. Desondanks blijken veel van deze projecten niet succesvol, waardoor innovatie afgeremd wordt. Tijdens een rondetafeldiscussie ging Computable op zoek naar het recept om it-projecten succesvol te maken. In dit artikel gaan we vooral in op wat succes is en welke voorbereidende maatregelen er getroffen moeten worden.
Naast de actualiteiten rondom mislukte it-projecten bij de overheid blijkt ook uit onderzoek van Carolien Schönfeld dat er jaarlijks wereldwijd door bedrijven en overheden 4300 miljard euro wordt verspild. Onderzoeken van Ernst & Young laten zien dat meer dan de helft van de it-projecten niet succesvol is. Tijd dus voor verandering, maar hoe kunnen we it-projecten succesvoller maken en hoe definieer je nu precies succes?
Om hierover van gedachte te wisselen en van elkaar te leren, initieerde Cerios, specialist op het gebied van it-projecten, samen met Computable een rondetafeldiscussie waar vertegenwoordigers van Ordina, Tata Steel, Cerios, Agentschap BPR, IonIT, en A/I/M aan deelnamen. Verslag van deze discussie verschijnt in een driedelige artikelenreeks, waarin de startfase van het project, de uitvoering en techniek en de vorm van het project aan bod komen.
Kpi’s
Na een introductieronde onder leiding van Sander Hulsman van Computable, mocht Leendert Hinds, projectmanager bij Tata Steel, de discussie aftrappen. Volgens hem zijn het opstellen van key performance indicators (kpi’s), goed stakeholdermanagement en governance cruciale onderdelen om een project tot een succes te volbrengen. Of een project de stempel succes krijgt, is van veel factoren afhankelijk. Het heeft zowel met de mensen, de techniek, de omgeving en de aard van het project te maken.
Bob van Zeist, managing director bij Cerios, sluit zich hier volledig bij aan. ‘Of een project succesvol is of niet, is zeer subjectief. Een organisatie kan na de oplevering van een project heel erg blij zijn, maar als later blijkt dat het ook veel goedkoper had gekund, is hetzelfde project ineens veel minder succesvol. Daarom is het definiëren van kpi’s ook zo belangrijk.’
Business case en haalbaarheidsonderzoek
Vanuit een infrastructuurachtergrond heeft projectleider Reza Sarshar van IonIT ook dagelijks te maken met it-projecten. In zijn optiek is een grondige businessanalyse en een goede business case erg belangrijk voorafgaand aan het project. ‘Goed vooruitblikken en kijken naar de haalbaarheid is onderdeel van de oplossing.’ Ondanks dat alle deelnemers het zo goed als eens zijn over de business case en het haalbaarheidsonderzoek wordt er ook een kritische noot geplaatst. Fred Bons, directeur projecten bij Ordina, is van mening dat je je niet altijd moet laten leiden door risico’s. Als je dat wel doet, dan wordt geen enkel project meer opgestart. ‘Soms moet je ook gewoon durven beginnen.’
Informatiedeskundige Steven van ‘t Veld van A/I/M gaat hier zelfs nog iets verder in. Hij constateert dat de meeste projecten beginnen met een businessanalyse, maar idealiter zou dit anders moeten zijn. ‘In de meest ideale situatie moet bijvoorbeeld ook de business case gemaakt worden door een ander dag degene die het project realiseert. Eerst weten, dan doen.’ Ben Zwartveld, business architect bij Agentschap BPR, vervolgt de discussie en vult aan vanuit zijn eigen achtergrond bij de overheid. Hij constateert juist dat projecten veel te snel worden gestart, waardoor organisaties en overheden eigenlijk altijd starten met een achterstand. Hij adviseert: ‘Kijk ook goed naar je architectuurdoelstellingen, en werk vervolgens een business case uit.’
Luister naar de expert
Toch blijkt een solide business case niet meteen het ei van Columbus in de weg naar succesvolle it-projecten. ‘Let wel op, de business case is een heel veranderlijk briefje en rechtvaardigt al snel tijdsdruk’, aldus Van Zeist. Ook blijkt de stem van de expert in het projectteam vaak niet hoog genoeg door te zingen in de organisatie, waardoor projecten die gedoemd zijn om te mislukken, toch doorgang vinden. Zwartveld: ‘De experts binnen een projectteam kunnen doorgaans een heel nauwkeurige voorspelling doen of het project kan slagen of niet. Zij zijn immers het meest vertrouwd met het it-landschap. Doordat hun stem niet gehoord wordt door de eindbeslissers, vinden veel projecten waarvan voorspeld was dat ze fout af gaan lopen, toch doorgang. De vraag is dan: wiens kop gaat er rollen?’ Fred Bons ziet dit ook vaak gebeuren, zeker bij externe opdrachtgevers.
Waar gaat het dan vaak mis bij it-projecten? Nieuwe wet- en regelgeving, zoals SEPA en de geplande decentralisaties, blijken hier invloed op te hebben. De overheid rekent niet terug hoe lang organisaties nodig hebben om hun systemen aan te passen aan nieuwe regelgeving, meestal wordt er gewoon een deadline aan gehangen. Dit maakt het voor organisaties erg lastig om op tijd compliant te zijn en door de grote tijdsdruk ligt mislukking al snel op de loer.
Niet laten afleiden
Dat er een grondige businessanalyse gedaan moet worden en een stevige business case gebouwd moet worden, staat als een paal boven water. Desondanks zijn projecten vaak zo verschillend van aard en hebben we te maken met zoveel verschillende systemen dat het haalbaarheidsonderzoek en de business case niet altijd leidend zouden moeten zijn. Verstandig is wel om vooraf goed na te denken over wanneer een project een succes is. Alleen als dit helder is, kan een project als ‘succes’ bestempeld worden. In het volgende deel van deze reeks wordt er verder ingegaan op de uitvoering van projecten, in het bijzonder op de Agile-methodiek.
Veranderlijk succes
Dat het succes van een project zeer veranderlijk is, blijkt wel uit het voorbeeld van het project rondom de studiefinanciering. Het project was op tijd afgerond, binnen het gestelde budget. Toch werd dit project in eerste instantie niet gezien als succesvol, want de implementatie van het nieuwe systeem was een drama. Eenmaal geïmplementeerd, bleek het project toch weer erg succesvol, want alles werkte naar behoren en de medewerkers konden er goed mee overweg. De studenten echter hadden er wat meer moeite mee. Zij konden niet goed overweg met het nieuwe systeem, waardoor het succes van het project weer in twijfel werd getrokken. Een aantal jaren later voerde de overheid een stelselwijziging door, waar het systeem niet op berekend was. Zo blijkt maar weer dat perceptie en het tijdspad erg belangrijk zijn.
Deelnemers
Reza Sarshar, projectleider bij IonIT
Leendert Hinds, projectmanager en business consultant bij Tata Steel Europe
Fred Bons, directeur projecten bij Ordina Nederland en bestuurslid van IPMA Nederland
Ben Zwartveld, business architect bij agentschap BPR
Bob van Zeist, managing director bij Cerios
Steven van ‘t Veld, business en information analist bij A/I/M
Gespreksleider: Sander Hulsman, hoofdredacteur a.i. bij Computable
Interessant, in dit stuk worden vooral de uitdagingen benoemd die een PL kan tegenkomen bij het leiden van zijn project en niet echt oplossingen. Ik lees verschillende uitgangspunten uit verschillende disciplines en met deze ingrediënten zou ik een taart moeten kunnen bakken. Mijn mening en ervaring met het falen van projecten is dat de oorzaak niet eenduidig te noemen is, ook hangt het af met welk soort project de organisatie te maken heeft en hoe ambitieus de organisatie is, ik pleit voor plan B, dat betekent dat een (project)organisatie rekening dient te houden met haalbaarheid van de doelstellingen, als doel A niet gehaald wordt dan gaan we voor variant B. Misschien moeten we accepteren dat het niet altijd mogelijk is om een project tot een succes te brengen en dat we dat ons realiseren en daar op inspelen. Immers 50% wordt wel gehaald en de vraag is wat daarvan het geheim is.
@Abderzak
In dit stuk worden naast uitdagingen wel degelijk oplossingen aangedragen.
Om een antwoord te geven op uw vraag naar succesvolle projecten hebben wij in het stuk vermeld dat kpi’s cruciaal zijn. Deze kpi’s moeten van tevoren opgesteld zijn en gedurende het project constant periodiek geëvalueerd worden.
Ik ben het geheel met u eens, dat bij het falen van een project de oorzaak niet eenduidig te noemen is. Daarom hebben wij in het stuk aangegeven dat het van veel factoren afhankelijk is of een project de stempel succes krijgt of niet. Het heeft zowel met de mensen, de techniek, de omgeving en de aard van het project te maken. In uw reactie onderschrijft u dit door te vermelden dat succesvolle projecten ook van de organisatie zelf afhangt.
In dit stuk hebben wij de kpi’s niet vermeld, aangezien er vele kpi’s te bedenken zijn.
In deze reactie noem ik een aantal die ik belangrijk vind. Deze zullen door de PM wel
eerst SMART gemaakt moeten worden.
Doorlooptijd
Budget
Klanttevredenheid
Overdracht naar beheer
Stakeholder management
Reactiviteit
Beschikbaarheid resources
Mate van escalatie
Samenwerking met BPM
Consistentheid
Gebruik Prince2
Governance en procedures
Projectadministratie
Samenwerking tussen project leden
Het geheim van de 50% projecten die volgens u wel succesvol zijn ligt simpelweg in het feit dat bij deze projecten de kpi’s van tevoren opgesteld worden en consistent periodiek geëvalueerd worden. Hierdoor kan men tijdens het project corrigerend handelen zodat deze projecten wel succesvol afgerond worden.
Dag Abderzak,
Als ik dit artikel lees dan zie ik niet alleen het adresseren van het probleem maar ook de aanvliegroute en hoe je dat zou kunnen oplossen of aanpakken. De mogelijke oplossing kan pas besproken worden als er meer duidelijkheid is over verschillende aspecten van het project en waarom dat vast is gelopen.
Zoals je aangaf het falen van een project te maken kan hebben met vele onderwerpen. We kunnen eea voor de start van het project inzichtelijk maken of voorkomen door eerst een haalbaarheidsonderzoek te verrichten. Maar zoals Fred aangaf dit neemt de kans op het falen niet weg!
Tijdens het haalbaarheidsonderzoek en ook onderzoek naar de business case krijgen we te maken met Plan B als alternatief. Altijd gedurende doorlooptijd van het project een plan B klaar hebben is bijna onmogelijk. Dat zien we vooral bij Infra-projecten. Je kunt pas plan B hebben als en duidelijk is waar je staat en hoe je je weg verder moet bewandelen (exception)
Het soort van een ict project bepaalt de aanpak, uitvoering en nog vele andere zaken. Als voorbeeld hoe je een ict softwareontwikkelingstraject uitvoert (bijvoorbeeld dmv Agile/scrum) is anders dan hoe je een infra-traject uitvoert (bijvoorbeeld dmv Prince2)
Met Agile en Scrum kun je je softwareontwikkelingstraject in stukjes opdelen die altijd aanpasbaar zijn maar dat kun je niet (altijd) met infra-trajecten doen waar de initiële investering (bijvoorbeeld voor de nieuwe storage/netwerk, virtualisatie infrastructuur etc etc)vrij hoog zijn en ook niet later aanpasbaar zijn.
Misschien is het niet verkeerd om deel 2 en 3 van deze serie te lezen (wordt binnenkort gepubliceerd)
Om met ‘ een’ deur binnen te ‘vallen’, Je hebt een punt die her en der al door iedereen is beschreven die vind dat zij/hij een project/traject succesvol heeft laten verlopen. Hele boekenkasten staan er van vol. Waarom gaat het dan zo vaak mis? is de vraag.
Even je gevraagde definitie;
Succes van een IT project/Programma
Dat is eenvoudig. Dat geld voor elke stap die je zet in en met IT.
‘ Het vlekkeloos laten verlopen van een IT proces zoals beoogd. ‘
Ongeacht hoe groot dat proces is.
Het tweede is definiëren van een succesvol commercieel IT project/programma
‘ Het vlekkeloos laten verlopen van een IT proces binnen gesteld budget en tijdsbestek’
Nu is het wachten mischien op de aanvullingen van die of gene vanuit eigen ‘ discipline’ maar dat laat ik even daar voor wat het is.
Nu je stelling waarom het dan zo vaak mis gaat. Ook hier zal ik wel weer een opmerking of wat krijgen maar herhaal mezelf gewoon.
Lineaire wetmatigheid
Anders dan andere projectvormen is elke stap in en met IT een lineaire statische aangelegenheid. Elke stap daarbinnen in een van te voren vastgelegde exacte stap. Elke stap heeft een gedefinieerde waarde.
Vereiste is dat elke stap, in en met IT, alleen maar succesvol kan zijn als er geen inbreuk word gedaan op dat lopende proces. Let wel, dat geld voor ELK IT proces, groot, klein, single, dual. Ik heb ergens in 1997 daarvoor een eenvoudige illustratie bedacht met een Russisch expert en die hebben we heel simpel de Civile Matrix genoemd. (Non Commercieel)
Er zijn 6 factoren die elk IT proces, klein of groot, om laat vallen.
1. Niet conformeren aan de wetmatigheden van IT
2. Meerdere tegengestelde processen gelijktijdig laten verlopen
3. Impotentie
4. Incompetentie
5 Politiek
6 Commercie
Het zal IT volkomen worst zijn wie welke visie hier op heeft, want IT is wat dat betreft gewoon dode materie die…. Alleen maar in beweging kan worden gezet door (In)put. U weet wel, (I)nput is (O)utput en Geen (I)nput = Geen (O)utput. zo eenvoudig is het even in een notedop.
Om het even welke methode je zou willen gebruiken, Bum, Scrum, Humtidum, Lean, Mean, Veil, Geil, Agile, als de betreffende methode niet volkomen is zoals IT, forget it. Het is dan niet de schuld van de mensen die het niet begrijpen maar van de allesoverziende PL/PM/G.O.D. die weliswaar een leuk ‘ opleidinkje’ heeft gehad, maar geen bal snapt van die rottige IT materie.
(Ik hou mijn hard al vast voor Ton Elias en co, geen van allen ballen verstand van IT maar het wel onderzoeken. Heel voorspelbaar kan daar niets uit komen.)
Ik volg Razar een heel eind tot zijn plan B. (Beetje Bull) wat mij betreft. Als een traject niet loopt zoals men het voor ogen had, begaat men de zoveelste fout. Een pot geld of blikjes met FTE open trekken om…
Halt
Als een traject dreigt te ontsporen doet u precies wat IT in dat geval ook zou doen. Elk proces STOPT bij een Error die groter is dan het proces. (Kijk echt even naar die matrix girls en guys, ik verdien er niets aan maar het helpt je veel meer dan je credit zou geven)
Wanneer je stopt namelijk, niet zeggen dat je niet zou kunnen stoppen, je kunt elk traject IT wise fantastisch opdelen in kleine behapbare stukken, Kun je zeer snel schakelen en analyseren waarom dat (Deel)proces nou precies niet dat doet wat men dacht. Ik ga hier even niet over processen die gewoon te dom voor woorden niet conform IT werden opgesteld. Ik verwijs even naar de eerdere 6 gemene delers.
Zoals ik voorgaande al stelde, gaat dat op voor elke discipline in en met IT. Platgeslagen als een dubbeltje, geen overbodige franje maar de focus op….. B. Want dat is tenslotte waar je met elke stap, in en met IT, naartoe wil.
Laatste tip!
Leg alle niet IT professionals nou eens gewoon uit waarom het nu eenmaal zo werkt en vraag vooral hun medewerking daarbij. Je zou toch eens vrolijk verbaast raken hoeveel mensen meer begrijpen van IT dan je dacht. Het heet communicatie dacht ik.
Goed dat er aandacht is voor het verbeteren van de route van succesvolle projecten. Terecht wordt genoemd dat een goede voorbereiding essentieel is: de initiatiefase waarvan de businesscase een belangrijk onderdeel is. Uit onderzoek blijkt dat in slechts 30% van de gevallen een businesscase wordt gebruikt. Er valt dus nog veel te verbeteren op dit punt. “De vis gaat rotten bij de kop”. De businesscase is het begin van een investeringstraject, waar een project onderdeel van is. Is deze van slechte kwaliteit, moet je niet verwachten dat het project succesvol gaat verlopen.
Terecht de opmerking dat je je niet altijd moet laten leiden door de risico’s: een opdrachtgever moeten denken in kansen en minder in bedreigingen. Het proces van de businesscase kan hierin veel duidelijkheid scheppen.
Zoals gezegd wordt de businesscase nog maar beperkt gebruikt. Maar wat veel verontrustender is, is het feit dat in meer dan 60% van de gevallen de businesscase wordt opgesteld door de opdrachtnemer: dit kan de projectmanager zijn die ook belast is met de realisatie van het project, de interne ICT afdeling of een externe leverancier. De justificatie van het project gebeurt door degene die ook belang heeft bij de realisatie van het project.
Deze aanpak is fundamenteel fout: zolang hier niets veranderd, zullen overschrijdingen aan de orde van de dag blijven.
Initiatie, realisatie en exploitatie zijn belangrijke fases voor een opdrachtgever: de verantwoordelijkheid kun je en mag je niet bij een (interne) opdrachtnemer neerleggen.
Ook bovenstaand initiatief (wat op zich goed is) wordt gekenmerkt door de zware vertegenwoordiging van de opdrachtnemende kant. Een slechte zaak: meehuilen met wolfen in het bos. Op deze manier zal er niet fundamenteel iets veranderen. Decennialang is er al sprake van forse budgetoverschrijdingen, decennialang wordt er geïnvesteerd in het verbeteren van de kwaliteit van professionals aan opdrachtnemende kant, decennialang wordt het onderwerp besproken op congressen, seminars, etc. Maar tot nu toe zijn forste budgetoverschrijdingen nog aan de orde van de dag. Voorlopig zal dat zo blijven. Zeker zolang het onderwerp Goed Opdrachtgeverschap niet op de agenda van bestuurders staat.
@Reza Dat infrastructuur projecten lastiger aanpasbaar zijn kan ik begrijpen maar ik denk dat voor software ontwikkelings trajecten ook wel geldt. Ook al wordt een ontwikkelingings een traject stapsgewijs uitgevoerd implemntatie beslissingen die genomen worden blijven je achtervolgen en bepalen je mogelijkheden en onmogelijkheden in de latere stadia. Het is een misverstand dat als je ‘agile’ ontwikkelt dat je zomaar van de hak op de tak kan springen. Dus, voor de software ontwikkelingstrajecten geldt ik denk wat het zelfde als voor de infra projecten.
Ben het wel eens met de opmerkingen van Zwartveld in de discussie, eerst even op je handen zitten voordat je wat doet en niet zomaar beginnen en dat er goed geluisterd naar de inhoudelijk en technisch ingevoerde mensen.
Louis,
Ik heb nog geen ervaring met softwareontwikkelingstrajecten. Ik kan me voorstellen dat je bij dit soort trajecten eerder klein en met minder kosten kan beginnen en het verder aangepast en flexibel doorontwikkelen. Bij infra trajecten heb je deze ruimte niet. De initiële investering in een infra traject is vrij hoog waardoor je de zaak niet altijd eenvoudig terug kan draaien. Bijvoorbeeld heb je een san-storage aangeschaft en geïmplementeerd (inclusief de hieraan gerelateerde zaken zoals je back-up software-hardware, netwerk uitbereiding, virtualisatie etc etc) dan heb je al een enorme investering gedaan. Vervolgens kom je in deze trajecten sommige dingen tegen waar je eerder geen weet van had (zoals de geschiktheid van je applicaties/onzichtbare kosten/ enorme I/O`s etc etc) Juist deze tegenslagen gaan de koers van je traject technisch en financieel gezien veranderen.
Ik vermoed dat dit soort zaken zich “minder” in een software-ontwikkelingstraject voordoen. Ik denk ook dat je dmv Agile/Scrum eea (dus niet alles) in dit soort trajecten beter kan aanpakken dan bij infra trajecten.
Hoe uitkomsten van een project ervaren worden is inderdaad nogal subjectief, alleraardigst vind ik dan ook de opmerking dat niet ieder project succesvol hoeft te zijn. De weg naar succesvolle projecten is daardoor misschien wel irrelevant omdat het uiteindelijk gaat om het rendement.
@Reza
Je kletst uit je nek, meeste infrastructuur projecten zijn gewoon ‘search and replace’ om de simpele redenen dat zowel budget als techniek de mogelijkheden beperken. Laten we niet van elke verandering een project maken want veel gaat gewoon om (achterstallig) onderhoud. Het is meer change management dan project management waarbij dit soort wijzigingen wel veel afhankelijkheden kennen natuurlijk. Argument van afschrijving vind ik in deze nogal ver gezocht, typische gevalletje van slecht configuratie management.
Noot aan de schrijver. We mogen dan wel in een kleine economisch opleving zitten op het moment maar de economie op het wereldwijde toneel is wel degelijk in mineur en zal dat voorlopig ook nog wel blijven. Vooralsnog is Europa hier absoluut geen uitzondering op. Het is een kwestie van even het internationale financiële nieuws bijhouden.
En een zijstap naar de mensen die veel hebben belegd om hier eens wat beter in te verdiepen want dan kan je er rekening mee houden.
@NumoQuest
Een ding is zeker. Je bent consequent in je betoog. En dat al heel lang.
Misschien dat je er een keer een stukje voor Computable over kan schrijven. Het zal iig een frisse wind zijn hier.
Tegelijkertijd ben je ook belerend en komt net iets te drammerig over. Dus wat dat betreft zou je een meer neutraal taalgebruik kunnen hanteren. Dan strijk je die managers niet in de haren.
Maar wat jij wilt is eigenlijk een cultuuromslag en daar zijn heel veel mensen heel huiverig voor. Laat dan maar eens zien dat het werkt en hoe de mensen in stappen hier naartoe kunnen werken. Dat zal veel meer mensen over de streep trekken.
Wat die Ton Elias en co betreft. Hopeloze zaak, niets meer aan doen. Die papagaaien alleen maar na wat ze ingefluisterd wordt. Te dom om te ……