Zes cio's bogen zich onder de kundige leiding van moderator en CIOnet-stichter Hendrik Deckers over die vraag. Alain Grijseels, cio van het RIZIV (Rijksinstituut voor Ziekte- en Invaliditeitsverzekering), leidde het debat in met een perfect overzicht van wat er zoal kan mislopen bij een project en waar dan de verantwoordelijkheden kunnen liggen. Interessant om te weten was op de eerste plaats waarom een project wèl slaagt. Grijseels haalde daarbij cijfers aan van het PMI, het Project Management Institute, waaruit blijkt dat zowat driekwart van het succes van een project op voorhand al bepaald wordt door er gebruikers bij te betrekken, de steun van het management te krijgen, duidelijk de vereisten te definiëren, alles goed te plannen en realistische verwachtingen te koesteren. Waarom falen projecten dan? "In de eerste plaats door een gebrek aan best practices in projectbeheer", beklemtoont Alain Grijseels. "De projectmanager wordt overdonderd door gebruikers, kan zijn team niet aansturen, kan niet plannen en gaat op een bepaald moment gewoon de mist in. Daarnaast is er ook een gebrek aan steun van de stakeholders - zeg maar de gebruikers die het resultaat niet goedkeuren. Als je die twee dingen, die samen goed zijn voor bijna 80% van de falingen, in de hand kan houden, dan is er veel kans dat je project op koers blijft".
...

Zes cio's bogen zich onder de kundige leiding van moderator en CIOnet-stichter Hendrik Deckers over die vraag. Alain Grijseels, cio van het RIZIV (Rijksinstituut voor Ziekte- en Invaliditeitsverzekering), leidde het debat in met een perfect overzicht van wat er zoal kan mislopen bij een project en waar dan de verantwoordelijkheden kunnen liggen. Interessant om te weten was op de eerste plaats waarom een project wèl slaagt. Grijseels haalde daarbij cijfers aan van het PMI, het Project Management Institute, waaruit blijkt dat zowat driekwart van het succes van een project op voorhand al bepaald wordt door er gebruikers bij te betrekken, de steun van het management te krijgen, duidelijk de vereisten te definiëren, alles goed te plannen en realistische verwachtingen te koesteren. Waarom falen projecten dan? "In de eerste plaats door een gebrek aan best practices in projectbeheer", beklemtoont Alain Grijseels. "De projectmanager wordt overdonderd door gebruikers, kan zijn team niet aansturen, kan niet plannen en gaat op een bepaald moment gewoon de mist in. Daarnaast is er ook een gebrek aan steun van de stakeholders - zeg maar de gebruikers die het resultaat niet goedkeuren. Als je die twee dingen, die samen goed zijn voor bijna 80% van de falingen, in de hand kan houden, dan is er veel kans dat je project op koers blijft". Veel heeft blijkbaar te maken met het precies omschrijven van de uiteindelijke doelstelling van een project, de scope. "Het kan best zijn dat je bij de aanvang je scope om allerlei redenen niet goed hebt kunnen omschrijven en dat je pas in de loop van het project zekerheid krijgt over scope en resources", zegt Michael Moens van Krefima. Philippe Niesten, cio van Herstal Group, is het daar volmondig mee eens. "Dat is ook de reden waarom ik denk dat geen enkel project op tijd en binnen budget kan afgerond worden omdat er altijd een probleem van definitie is - de gebruiker heeft niet precies bepaald wat hij wenst en ziet zijn wensen dan nog evolueren vooraleer het project opgeleverd wordt. Ik heb ooit contracten gekend waar men bij het tekenen van het document al wist waar men wijzigingen ging aanbrengen". Louis Mahy, cio bij Record Bank, voegt er een leuke noot aan toe : "Mijn ervaring bij ING is: als je met de Nederlanders werkt, dan worden alle projecten altijd op tijd en binnen budget opgeleverd. 99% van alle projecten bij hen lukt - omdat ze de scope veranderen !" Alain Grijseels geeft grif toe dat het een bekend gegeven is dat iedereen verborgen agenda's heeft, vaak komt het er op aan om die op tijd te ontdekken - een kwestie van soft skills, management, lobbying. Hij haalt een praktijkgeval aan bij een grote overheidsdienst waar de specificaties slecht omschreven waren, de projectmanager het na zes maand voor bekeken hield en het ontwikkelingsbudget al op was op het moment dat de hardware geïnstalleerd was. "Gevolg? Het moreel van het team zat onder nul, de sponsor bleef maar beloften doen, de gebruikers hadden klachten op alle vlakken, en alle indicatoren stonden op rood. In de planning waren 600 mandagen voorzien maar het zouden er uiteindelijk 3.000 worden, met een totaal onhaalbare scope." Als kersverse projectmanager greep Grijseels onmiddellijk in. De stuurgroep werd verruimd met sleutelgebruikers, alle procedures werden geformaliseerd met meeting minutes en formele acceptaties, deliverables werden afgetekend. "Je gaat heel formeel werken, geen willekeur meer, met een precieze omschrijving van rollen en verantwoordelijkheden. Je begint aan teambuilding te doen, je zorgt voor een directe communicatie met alle gebruikers, en je gaat opnieuw vertrouwen creëren bij stakeholders en gebruikers. En de resultaten bleven niet uit, plots zag men dat er iets gebeurde en dat de snelheid van ontwikkeling verhoogd was, er kwam meer enthousiasme, meer motivatie." Lessons learned voor Alain Grijseels? "Methodologie en formalismen zijn nodig. Je moet een project ook kunnen en durven stoppen, maar dan moet je ook het empowerment van het management hebben daartoe. Als er geen sponsor meer is, is er ook geen project meer. En een projectmanager is een lonesome cowboy, maar hij moet dat aankunnen, hij moet een olifantenvel hebben en in staat zijn klappen te incasseren en weer recht te staan." Voor Philippe Niesten is de figuur van de projectmanager cruciaal. "Er wordt te weinig gekeken naar de persoonlijkheid van de projectmanager. Ik geloof niet dat je een projectmanager wordt, je bent het of je bent het niet, je kan iemand ook niet opleiden in die zin. We geloven ten onrechte dat een goede programmeur een goede analist en later ook een goede projectmanager kan worden - dat is een fundamentele fout. Veel mislukkingen zijn dan ook te wijten aan de persoonlijkheid van de projectmanager die niet over de juiste competenties beschikt. Sterker nog, ik heb al vastgesteld dat projectmanagers vaak erg slechte informatici zijn maar daarentegen prima in staat zijn aan teambuilding te doen met uitstekende resultaten tot gevolg". Alain Guillemyn, cio bij International Car Operators, sluit zich daar bij aan: "Een projectmanager is iemand die zo geboren is, het moet in zijn genen zitten. Je kan van een techie die enkel om de bits geeft, nooit een goeie projectmanager maken. Een van de belangrijke factoren in het welslagen van een project is immers de capaciteit die een projectmanager heeft om zijn team mee te nemen van vlag naar vlag en tegelijkertijd ook de communicatie met de business te onderhouden. Zoiets kan je niet aanleren". Kalman Tiboldi, cio van TVH, ziet nog een gevoelig punt. "Is de eerste vraag eigenlijk niet: gaat het wel om een it-project, en wat is het verschil tussen een it- en een businessproject? Onze ervaring is dat er nooit problemen zijn aan de it-kant, wel met de afstemming van it op de business. En dat is een kwestie van communicatie. De fundamentele vraag is dan: moeten we altijd een projectmanager uit de it-kant kiezen? Ik doe dat nooit. Je hebt een businessproject? Doe maar, jij trekt het dan, ik kom met mijn technische kennis om het te mogelijk te maken, maar jij trekt het project. Het probleem dat ik vaak zie is: wie leidt dan de dans, wie is de uiteindelijke verantwoordelijke voor het project, voor het eventuele falen, voor de lobbying?" Alain Guillemyn: "Ik zou daar graag willen op inpikken want dat is heel belangrijk. It-projecten moeten toch altijd kaderen binnen een it-strategie die geënt moet zijn op een businessstrategie. Eigenlijk is het de business die een probleem moet oplossen en it levert daarvoor enkel de tools". Louis Mahy gaat zelfs nog een stapje verder: "Bij ons bestaan er geen it-projecten, op enkele kleine infrastructuurprojecten na, al de rest zijn businessprojecten - er kan geen it-project zijn als er geen vraag is vanuit de business". "Mijn ervaring is dat zoiets inderdaad niet werkt", stelt Alain Grijseels. "Vroeger kwam men naar ons, naar it, legde het project voor en vroeg dan een programma daarvoor. Dat werkt niet - er zijn projecten faliekant mislukt omdat de it-jongens niet wisten wat eronder zat of hoe ze het moesten implementeren of situeren. Nu hebben we business-projecten, vaak op grote schaal, met spin-offs, de it-projecten. Het proces wordt op businessniveau gedefinieerd, en pas daarna wordt het een requirement dat naar it gaat. Maar altijd is er dan steering waarbij de sponsor van het businessproject vertegenwoordigd is." Toch kan ook het omgekeerde, zegt Philippe Niesten. "Wij hebben bij ons virtualisatieproject ook mensen van de business betrokken, al droegen zij op het loutere it-vlak niet bij, maar ze hebben wel kunnen vaststellen dat er door die virtualisatie meer flexibiliteit was, meer capaciteit, en een hogere snelheid, en we hebben hen gevraagd om daar het effect op hun business van na te gaan. Zo is er toch een band met ict gecreëerd. En eigenaardig: we hebben geen problemen gehad om enkele noodzakelijke budgetverhogingen te krijgen...". Kalman Tiboldi wijst op een ander belangrijk aspect, de omvang van een project. "Wij proberen onze projecten zo klein mogelijk op te splitsen om dan met zichtbare resultaten op korte termijn te kunnen tonen aan de business dat het werkt, om dan de volgende stap aan te vatten. Veel hangt natuurlijk af van de flexibiliteit van je architectuur, maar de mensen zijn wel beter gemotiveerd want ze zien sneller resultaten". "Klopt", zegt Alain Guillemyn, "het is belangrijk dat zowel de it- als de businessmensen de vlag zien staan en daar naartoe werken - en dan is er weer een volgende vlag". Louis Mahy nuanceert: "Een it-project kan natuurlijk altijd een businessproject worden, want zelfs een virtualisatieproject is geen it-project voor mij. Daartoe moet het voor de business wel duidelijk zijn dat het op een of andere manier geld oplevert en dat ze het dus moeten sponsoren. Daarom vinden we hier steeds vaker businessprojectleiders terug, mensen die van de business komen en it leren. En ik heb vooral met hen successen gezien, zelden met it'ers die dan business-projectmanagers werden." Alain Grijseels heeft dat bij het Riziv praktisch opgelost. "Wij hebben een structuur van ict-coördinatoren gecreëerd, mensen die bij de staf van de algemene directie zitten en die zowel de business kennen als ict begrijpen. En elke programmanager heeft zijn tegenhanger bij de ict-coördinatoren, en op die manier kunnen we de projecten ontdekken die echt aandacht vragen." En wat met de invloed van de crisis? Louis Mahy: "Voor mij is de crisis een opportuniteit, we kunnen nu gemakkelijker een discussie hebben over de kostenbatenanalyse van elk project dan bijvoorbeeld twee jaar geleden. Voor een goeie projectmanager is de crisis prima want het is nu voor hem gemakkelijker om zijn zaak te verdedigen". Philippe Niesten bevestigt dat. "Wij komen als it goed gewapend in deze zakelijke crisis terecht omdat wij met onze organisatie al 10 jaar geleden orde op zaken gesteld hebben. Vroeger was het vooral bodyshopping, maar daar zijn we steeds meer van teruggekomen, we zijn steeds vaker op projecten overgestapt - en daar is ict veel beter gewapend, veel competenter in projecten dan tien jaar geleden." "Dat is de kans die de crisis ons nu biedt", zegt Mahy: "We zijn al goed in projectmanagement maar kunnen er nu ook nog het sponsorship voor krijgen want de business heeft belangstelling. Waar de business vroeger zei 'dat is it die zich amuseert met kleurtjes en een Excel-sheet', zien ze nu in dat het wel degelijk nuttig kan zijn". "Klopt", zegt Kalman Tiboldi, "iedereen kijkt naar de prioriteiten die gewijzigd zijn, het gaat vooral om het investeringsrendement. Voor kleinere projecten willen we snellere resultaten zien." Alain Grijseels beaamt dat: "Ik start geen project van twee jaar meer op, het wordt opgesplitst in een aantal tastbare resultaten van zes maand, want het probleem is dat er na twee jaar altijd wel iets veranderd is - technologie, business, wetgeving, er is altijd iets. We wisten twee jaar geleden niet dat we nu in een crisis zouden zitten die alles weer op de helling zou zetten. Wij gaan zelfs nog verder, ik spreek over agile scrum - wij willen dat er tastbare resultaten zijn om de week of veertien dagen. Als je naar twee jaar toewerkt, dan verdampt je project, met alle gevolgen vandien, en vaak is het dan weggesmeten geld." Alain Guillemyn wijst toch op een gevaar van die kortere aanpak. "Er zijn positieve en negatieve gevolgen aan de crisis. Positief is dat we een project strikter gaan opvolgen, dat we ook kortere projecten opzetten, met een snelle break-even. Maar het grote gevaar is dat we zouden vervallen in wat je in de jaren zeventig zag, dat je steeds meer kleinere oplossingen gaat zoeken en dus weer in silo's gaat werken en geen overkoepelende end-to-end oplossing meer krijgt." Wat is dan de rol van de cio nog in dat geheel ? "Ik kan dat in één woord samenvatten", zegt Philippe Niesten, "professionalisme, proberen al wie betrokken is in een project professioneler te maken. Ik moet als cio op het vlak van vorming, tools en ervaring de mensen professioneler maken. Ik denk dat we in it tot op heden heel veel artiesten en weinig professionals hebben gehad, en dat moeten we nu omkeren." Voor Michael Moens is de businessbetrokkenheid van de CIO cruciaal. "De business zit nog dichter bij de crisis dan it, en dus is het belangrijk voor mij de juiste sponsors en het goeie sponsorship mee te hebben voor de juiste projecten, en erg selectief te zijn met de juiste prioriteiten." "De rol van de cio is aan een fundamentele verandering onderhevig", stelt Tiboldi. "Voor ons is de crisis een opportuniteit om te tonen dat we met een goed professioneel team niet alleen alles onder controle kunnen houden maar ook de toegevoegde waarde van it kunnen bevestigen. En de cio is vandaag de centrale figuur in alle projecten". Frans Godden