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
@ John Duinkerken
Dank Dat hebben er meerder gezegd. Heb de stap ook gewaagd doch er geen enkele respons verder op gekregen dus tja.
Belerend. Ach, al iedereen vanuit eigen perspectief, leest discipline, reageert, wat overigens ook vaan een herhaling is van opinie en zetten, valt het denk ik nog wel mee hoor.
Ehm, managers tegen de haren instrijken? Mijn ervaring is dan de meesten knap vol van zichzelf zijn en al gauw terug stappen in persoonlijke rollenpatroon. Overigens, laatste slechts mijn ervaring met… geen veroordelen. (Ieder doet wat die doet.)
Ik hoef de rekeningen van de mishaps niet te betalen dus is het voor mij slechts af en toe een speldeprikje. (Vanuit mijn perceptie dan)
Cultuuromslag
Alsjeblieft niet beste John. Als je goed leest, dan zie je dat de basis van mijn betoog telkens de basis is van IT. Wat daar ‘bovenop’ gebeurd, vind ik dan weer weinig interessant. Interessant vind ik persoonlijk telkens weer aan kunnen wijzen waarom zaken telkens weer fout gaan.
Soms ter lering, soms ter vermaak. Ieder neemt er maar het hare/zijne uit. Edoch, hebben wij het over overheid, heb ik daar een zeer stellige mening over. Bedrijfsleven heeft een eigen proces bij #FAils. (Exit) Overheid is al jaren aan het falen en ik moet daar mede, gelegaliseerd afgeperst, aan mee betalen. Dus ook hier, tja.
Ik hoef geen mensen zo nodig over de streep te trekken als hen alleen maar op ‘een mogelijkheid’ te wijzen. Commerciële IT heeft alles te maken met reductie en besparen. Als dat niet lukt? Krijg je automatisch heel veel hoge rekeningen. Niet in het voordeel van IT (aanzien) en natuurlijk ook niet in voordeel van betrokkenen. (Spijtig)
Zal proberen in de toekomst met lengte en schrijfstijl rekening te houden. (Promise)
Vrijwel alle innovatie projecten die ik zie mislukken zijn te groot in termen van scope, doorlooptijd of aantal stakeholders. Dit leidt tot complexiteit in techniek, organisatie en communicatie die nauwelijks meer te managen valt.
Een eerste vereiste zou derhalve moeten zijn dat een project qua scope, doorlooptijd en impact binnen bepaalde grenzen moet blijven en daar dan ook keihard aan vast wordt gehouden. Neem het voorstel bij de kop en reduceer het zover dat het binnen 3-4 maanden kan worden gerealiseerd en productief wordt. Dat houdt het overzichtelijk. Randvoorwaarde: zorg dat je een kristalheldere visie hebt over je de ICT architectuur, gebaseerd op onafhankelijke deelblokken die autonoom kunnen ontwikkelen.
@ Reza,
Ik wil even terug komen wat je in 1 van je reacties aangeeft:
“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”
Bij het aanschaffen van een Centrale Storage oplossing is juist het voorwerk van cruciaal belang voor het slagen van het project. Heb je zelf niet de kennis, schakel dan een kennispartij in. Meten blijft in storage-land nu eenmaal meten en veel is door een gedegen voorbereiding te voorkomen. Een gedegen voorbereiding zorgt er juist voor dat Storage niet altijd “duur” hoeft te zijn en maakt de kosten juist overzichtelijk. Want vooraf kan je natuurlijk perfect controleren wat de karakterstieken van je applicaties en de daarbij horende applicaties zijn. Als je hier pas tijdens de implementatie achter komt dan heb je in mijn optiek je huiswerk niet goed gedaan.
En bij infra-projecten zijn scrum en agile ook goed inzetbaar. Het euvel zit vaak in het feit dat de infra-mensen wat minder ervaren zijn met deze methodieken en de daarbij horende dynamiek . Dus wat extra begeleiding en coaching is dan geen over bodige luxe.
Rob,
Mee eens met de zaken die je hierboven hebt aangegeven. Sterker nog, deze punten zijn tijdens deze sessie ter discussie gekomen. Ik weet het niet maar misschien worden ze ook in deel 2 of 3 gepubliceerd.
Ewout,
Gelukkig ken ik je al goed en daardoor ben ik al bekend met je communicatiewijze en daarin je minder sterke kanten. Anders had ik je in mijn reactie anders benaderd.
Om terug te gaan naar je reactie, wanneer je lang in de oude versie van een systeem hebt gezeten dan heb je het niet meer over de upgrade en change management maar wel een (grote) verandering waardoor veel zaken anders moeten ingericht worden.
Ben je blij als je dat change management mag noemen? Prima toch, wie ben ik om je tegen te spreken 🙂
Ruud,
Hoe je meer weet hoe je minder kans op mislukking en tegenslagen hebt. Ik ben een voorstander van het gebruikmaken van externe kennis en expertise bijvoorbeeld in het haalbaarheidsonderzoek en ook later bij de implementatie.
Of je Scrum/Agile in een infra-traject kan toepassen…..dat weet ik niet! Men is gewend om in dit soort trajecten veel zaken van te voeren zeker te stellen voordat ze het traject starten. Dan verwijs ik naar je reactie hierboven die naar mijn mening gebaseerd is op de behoefte aan de zekerheid die men voor en tijdens een infra-traject nodig heeft.
Ik denk dat Agile/Scrum meer steun krijgen als hun gedachtengoed breder in de organisatie geïntroduceerd en geadopteerd worden.
Voor de duidelijkheid, ik zie Agile/Scrum niet als het wondermiddel!
Reza,
Dank voor je reactie.
Ik zie beide ook niet als het nieuwe wondermiddel. Maar ik heb dit in enkele infra-projecten met succes weten toe te passen. Ik deel wel je mening dat niet in ieder project het geval is.
@Reza
Als je (te) lang in oude systeem blijft hangen is er sprake van slecht configuratie management, het stukje lifecycle management dat uit gaat van de technische veroudering in plaats van de economische afschrijving. Dat hierdoor niet alleen een ’technical debt’ ontstaat in het ijzer maar ook de kennis los je dus niet op met een projectmatige IT aanpak. Zeker niet als je door blijft gaan met het stapelen van puntoplossingen zoals we afgelopen decennium hebben gedaan.
Om die redenen hebben wij dus een fabric platform ontwikkeld waarbij je de hardware kunt vervangen zonder impact op de bovenliggende software, infrastructuur ontwikkeld zich nu eenmaal sneller dan de meeste software. Betreffende je betoog over centrale opslag wil ik je wijzen op de ontwikkeling van SDS en het feit dat niet de back-up maar je archief vaak het probleem is. Tenslotte bewaar je een backup veel korter en is dus makkelijker uit te faseren, meestal dus wel binnen 3 maanden. In 9 van de 10 gevallen is het zorgenkindje bij infrastructuur projecten de data migratie waarvan echter vaak 80% statisch is omdat dit niet meer is dan een online archief.
Mijn communicatiewijze is misschien minder tactisch maar soms is er dus gewoon een hint met een knuppel nodig want met gissen blijf je missen. Natuurlijk kunnen we elke probleem met steeds meer techniek op gaan lossen maar dat is niet erg efficiënt, doeltreffend misschien maar zeker niet doelmatig als ik kijk naar de oplopende en telkens terugkerende kosten voor migratie. Gek genoeg worden die kosten nog steeds niet meegenomen in TCO/ROI berekeningen want als je het over investeringen hebt moet je ook denken aan charge back oplossingen. Hoewel ik enige bezwaren zie in cloud computing vind ik de ontwikkelingen rond doorbelasting natuurlijk prachtig.
Kortom, ik blijf bij mijn voorgaande reactie want als je een haalbaarheidsonderzoek nodig hebt voor een infrastructuur project dan mis je de essentie van de IT transformatie die gaande is. Een IT manager zorgt dat hij elke investering in de infrastructuur dubbel en dwars terugverdiend door niet alleen slim om te gaan met de techniek maar ook de licenties. En betreffende de zoektocht naar zekerheid is dat dus vaak de oorzaak van de ’technical debt’ die er te vinden is in menige infrastructuur.
C’est le ton qui fait la musique 😉
“C’est le ton qui fait la musique ;-)” – En dat uit jouw mond Ewout, haha. Dan is de muziek zeker heavy metal maar met gasten die wel het conservatorium hebben afgemaakt…
Artikel is een goed initiatief, het verslag iets te kort waardoor het inhoud mist en er veel ruimte tot discussie komt.
Wat ik het leukste vind, is het stukje over het bepalen van succes van een project, en dat het niet eenduidig is en achteraf zelfs zonder input nog kan veranderen.
Discussie over hoe je succes boekt met IT projecten… Daar zal altijd wel discussie over blijven. Alleen het IT veld is al zo breed. Ik denk dat het zwaartepunt niet meer zit in de techniek, al moet je in de basis wel goede keuzes maken. Ik vind reactie van Rob van Linden wel zinvol. En je kent mijn parade paardje wel; Gall’s Law
“A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.”
En daarvoor komt de vraag: “Welk probleem los je op?”
Plak er een goed model van een oplossing onder en je bent “good to go” om een team samen te stellen, en dan komt de echte uitdaging pas.