‘Hoe kunnen we projecten met een groot it-component succesvoller maken?’ Dat was de hoofdvraag waar zes experts met diverse achtergronden zich recent over bogen in de vorm van een rondetafeldiscussie. De discussie werd geïnitieerd door Cerios, specialist op het gebied van it-projecten, en georganiseerd in samenwerking met Computable. In dit laatste deel van deze driedelige artikelenreeks wordt verder uitgediept hoe de techniek en uitvoering van projecten van invloed zijn op het succes en waarom er zo’n urgente behoefte is aan kleinere projecten.
Elk project, hoe complex ook, kan 100 procent succesvol zijn. Daar zijn de vertegenwoordigers van Ordina, Tata Steel, Cerios, Agentschap BPR, IonIT en A/I/M het er tijdens de rondetafeldiscussie over succesvolle it-projecten wel over eens. Uit de eerdere artikelen in deze reeks bleek al dat goed haalbaarheidsonderzoek en een business case belangrijk zijn in de voorbereidende fase, maar ook de keuze voor de methodiek is cruciaal in de weg naar succes. Zo bleek Agile-werken in de discussie rondom it-projecten ook direct een belangrijk gespreksonderwerp te zijn. Ondanks de uiteenlopende meningen was de conclusie dat Agile-werken zeker succesvol kan zijn, maar niet in iedere situatie. Als je echter als organisatie wendbaarheid nastreeft, dan biedt Agile zeker uitkomst. Maar wat moet je als organisatie nu echt doen om succesvol te zijn? Met deze vraag werd direct de vinger op de zere plek gelegd.
Stoeptegelmanagement
Volgens informatiedeskundige Steven van ‘t Veld van A/I/M moeten organisaties hun focus verleggen. ‘Alles draait om projecten, waardoor bijvoorbeeld ook de businessanalyse volledig projectgekoppeld is. Hierdoor mis je cruciale dingen. We zitten teveel vastgeroest in projecten.’ Bob van Zeist, managing director van Cerios, refereert hieraan door te spreken van stoeptegelmanagement. ‘Logisch ook, want er moet immers budget voor worden vrijgemaakt. Maar uiteindelijk draait het om de businessdoelstellingen, waardoor de term projecten als snel vervaagt.’
Een andere succesfactor die Van ‘t Veld noemt, is dat organisaties meer zouden moeten focussen op kennis van informatie. Organisaties zijn in zijn optiek teveel bezig met het maken van nieuwe dingen, in plaats van ook de integratieaspecten goed te belichten. ‘Zorg voor een goede inrichting van de onderliggende informatiestructuur’, zo pleit hij.
Behoefte aan kleinere projecten
De huidige marktdynamiek zorgt ervoor dat er soms heel snel nieuwe software opgeleverd moet worden. Dit zorgt soms voor kopzorgen bij de it-afdeling, die druk doende is om de fabriek draaiende te houden. Om toch snel in te kunnen spelen op kansen, pleit directeur projecten Fred Bons van Ordina voor een ‘tijdelijk wendbare club’ naast het huidige team. ‘Deze club kan geïsoleerd een Agile-project draaien. Het mooie aan deze vorm is dat eventueel het Agile-team de it-afdeling kan beïnvloeden. Hierdoor kunnen organisaties testen of Agile-werken iets voor hun is, of juist helemaal niet.’
Vanuit de diverse perspectieven op projecten blijkt wel dat de meeste projecten eigenlijk te groot zijn. Projectmanager Leendert Hinds van Tata Steel pleit voor kleinere deelprojecten. ‘Of je nu Agile werkt of niet, kleinere projecten zijn simpelweg veel beter te managen.’ ‘Logisch gevolg van kleinere projecten is wel dat er meerdere projecten ontstaan, die goed gemanaged dienen te worden’, vult Steven van ’t Veld aan. ‘Een goed ingericht project management office kan uitkomst bieden in deze spaghetti van losse projecten.’
Continuous delivery
Volgens Bob van Zeist van Cerios zorgt Agile wel voor kleinere overzichtelijkere projecten, maar toch ziet hij dat Agile nog niet volledig is ingevoerd, en dat organisaties daarom niet uitkomen bij de doelstellingen van Agile. ‘Nieuwe software wordt middels Agile wel sneller en beter ontwikkeld, maar komt niet per se sneller bij de eindgebruiker terecht. Nieuwe releases in productie zetten is namelijk een foutgevoelig proces, waardoor organisaties huiverig zijn om vaak te releasen. In deze tijd hebben we echter snel iets nieuws nodig, zoals een patch voor een beveiligingslek. Continuous dlivery adresseert deze problematiek door de hele keten.’
‘Continuous delivery automatiseert in feite het hele ontwikkelingsproces tot en met de in productiename, een goede enabler dus voor wendbaarheid’, vervolgt Van Zeist. ‘In plaats van twee keer per jaar te releasen, kan je met continuous delivery meer dan drie keer per dag pijnloos releasen.’ Toch blijkt dat hier de nodige kennis en ervaring voor nodig is, en juist daar zit de crux. Steven van ’t Veld constateert dat er te weinig mensen beschikbaar zijn met de juiste competenties en ervaring. ‘Je moet aannemers geen architectenwerk laten doen. Net als in de bouwwereld zou een strikte scheiding tussen analyse en realisatie een goed idee zijn als je projecten, aannemerswerk, wil verbeteren, zie bijvoorbeeld wat nu in de woningcorporatie wereld gebeurt en gebeurd is.’ Business architect Ben Zwartveld van Agentschap BPR vult aan: ‘We hebben een dringende behoefte aan het schaap met de vijf poten, maar daar zijn er helaas niet zoveel van.’
Opdrachtgever vs. opdrachtnemer
Zwartveld signaleert nog een aspect waardoor projecten vaak de mist in gaan. ‘Als je kijkt naar bijvoorbeeld it-projecten bij de overheid, dan zie je dat de it-afdeling daar vaak blindelings vertrouwt op de expertise van een externe partij, terwijl dit zeker niet altijd terecht is. Zo kan de opdrachtnemer bijvoorbeeld het besluit nemen dat SAP hét systeem wordt, omdat ze daar nou eenmaal veel kennis van hebben.’
Als later blijkt dat SAP een fiasco is, dan komen de kosten nog vaak op het conto van de opdrachtgever. Reza Sarshar: ‘Om dit te voorkomen dient de opdrachtgever haar taken in het adviestraject goed uit te voeren om tot een juist advies te komen. Samenwerking tussen opdrachtgever en opdrachtnemer in deze fase is zeer belangrijk.’ Sarshar ziet liever dat deze verantwoordelijk bij de opdrachtnemer komt te liggen, bijvoorbeeld door het fixed fee-principe. Toch valt er wel wat aan te merken op dit afrekenmodel. Het stimuleert namelijk niet de samenwerking tussen opdrachtnemer en opdrachtgever. ‘Samenwerking tussen alle betrokken partijen is heel belangrijk’, aldus Fred Bons van Ordina. ‘Uiteindelijk zal je met gezamenlijke kennis het meest bereiken, als elke partij als individu optreedt, sla je de plank mis.’
100 procent succes is utopie
Hoe kunnen we projecten succesvoller maken? Op die vraag kan geen eenduidig antwoord gegeven worden. Doordat projecten complex zijn, divers van aard en ieder afzonderlijk een ander doel dienen, is het lastig om een eenduidige strategie uit te kristalliseren. Er is nog een lange weg te gaan naar 100 procent succes. Toch staan Agile-werken, een krachtige business case, gedegen haalbaarheidsonderzoek, samenwerking en zelfs continuous delivery aan de basis van een succesvol project.
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 & information analist bij A/I/M
Gespreksleider: Sander Hulsman, hoofdredacteur a.i. bij Computable
Misschien een idee om er een of meerdere camera’s bij te zetten om zo er een filmpje van te kunnen maken zodat er een indruk gegeven kan worden van waar het gesprek over ging.
@ Johan,
Dat is zeker een goed idee. Dan krijg je toch meer ” feeling “. Al moet ik eerlijk toegeven dat het verslag van Sander ook goed te volgen is. Mijn complimenten daar voor.
Al met al is dit een goed iniatief en ik hoop dat we dit voor de andere topics ook gaan doen. Het levert zeer waardevolle discussies op. Waar voor dank.
Interessant artikel die, excusez moi, weer veel van hetzelfde is namelijk ‘de vraag’ die ik met flinke frequentie voorbij zie glijden.
Dan zucht ik weer eens en dan denk ik, keer eens terug naar de kern en de basis van IT. Hoe ziet die er uit, hoe werkt die. Goh tjee hee, klinkt wellicht een beetje badinerend maar vooruit, die is helemaal in niets veranderd sinds het gebruik van de methode van Joseph Marie Jacquard (1752–1834), de grondlegger van het hedendaagse IT/ICT.
Natuurlijk, veel van u fronsen nu de wenkbrauwen, wtf is die Joseph Marie Jacquard dan wel? Google hem eens en u weet het.
1. Automatiseren is het mechaniseren dan wel digitaliseren van veel voorkomende productieve handelingen en/of processen met het oogmerk die zelfstandig te laten verlopen
2. Doel van automatiseren is WINST! (Het verhogen van de productiviteit door minder inzet van mens en middelen.)
Dat was namelijk de gedachte van Joseph Marie Jacquard, die gebruik maakte van een wetmatigheid, en laat die heden ten dage nog steeds hetzelfde zijn. (I)nput is (O)utput. Je kunt namelijk alleen iets in beweging zetten, als je er ook iets in stopt. Wat dat dan ook moge zijn.
IT Project vs IT Traject management
Met jullie welnemen (of niet natuurlijk), als jullie nu nog eens een discussie willen opzetten over hoe IT projecten en IT trajecten nog succesvoller zouden moeten kunnen, dan vrees ik een beetje met grote vreze. Het klinkt interessant, en ik herhaal mezelf dan nog maar even een keer, ‘Loose Your Origin!!!’ Jullie approach is van ,sec, geheel vanuit individuele veld van expertise van de betrokkene.
Je bekijkt, beziet, beredeneerd je onderwerp daarvandaan terwijl de kern en antwoord van jullie onderwerp volkomen universeel is. Plots zie je dan ook weer een valkuil opduiken, Een Methodiek die…. in dit geval Agile genoemd die al of niet …. BS!
Ik zie jammer genoeg dat niet de hele tekst van mij werd over genomen.
Bottom line wat mij betreft, en het laatste dat ik er op mijn manier over ga zeggen.
Als je niet in staat bent te onderkennen dat er vier gemene delers debet zijn aan de fails, als je nu nog wil discussiëren wil over hoe de zo enorm vaak falende IT projecten en IT trajecten succesvoller zouden moeten worden, dan heb je gewoon niet begrepen hoe de materie waarop IT zich beweegt, je steeds in de bipsjes bijt.
Het is een grappig maar totaal voorspelbaar verhaal. En als je afsluit met “100% succes is een utopie”, dan haal je de 100% basis van wat IT/ICT in de kern is volkomen onderuit. Wat mij betreft heb je dan in en met IT/ICT, niet meer van doen.
Zo eenvoudig is dat.
Succes met uw initiatief.
In het kader van de discussie over Agile en de behoefte aan kleinere projecten het volgende.
De metafoor van de olifant in stukjes eten hoor ik hier vaak. Ook ik onderschrijf de les die in de metafoor verstopt zit. Maar wat ik zie gebeuren is het volgende:
Veel organisaties zetten regelmatig een strategie op papier. Tussen de regels door zit een hele kudde olifanten verstopt. Niemand heeft een goed beeld van hoe die beesten eruit zien. Maar verschillend afdelingen en teams beginnen wel een losse slurf, staart of oor te produceren. Hoe weten we dat dit ook leidt tot de juiste kudde olifanten?
Daarom pleit ik er voor om “groot” te denken en “klein” te doen. Definieer de kudde (portfolio) en de olifanten (projecten en programma’s) en manage die in samenhang. Vervolgens knip je ze in stukjes (werkpakketten, epics, use cases, user stories, …) en voer je ze zo iteratief/agile mogelijk uit.
Is stoeptegelmanagement de nieuwe naam voor projectleiders die met een plaat voor hun hoofd van alles een project willen maken, die project in plaats van resultaat gedreven zijn?
Opmerkelijk betoog van Fred Bons, klinkt alsof er een konkinkrijk geschapen wordt met Agile. Laat ik nu een aantal van dat soort projecten van dichtbij meegemaakt hebben en stellen dat dit (meestal) niet werkt binnen organisaties waar DNA sterk hierarchisch is. Een front-office die voor de muziek uit gaat lopen zorgt in 9 van de 10 gevallen voor een digitale facade als de backoffice geen gelijke tred ermee kan houden.
Hoe kunnen we projecten met een groot it-component succesvoller maken?’ Dat was de hoofdvraag waar zes experts met diverse achtergronden zich recent over bogen in de vorm van een rondetafeldiscussie.
Continous wendbaar delivered oldhookering eneebelt het releasen van hun conclusie : Geen idee !
Als we een business vraagstuk gaan opknippen in kleinere projecten die onderling afgestemd gaat worden, dan gaat een PMO office uitsluitend helpen met de ‘blauwe’ kant van projectmanagement: planningen, resultaten, cijfers etc. Maar waar dat soort projecten vooral behoefte aan hebben is inhoudelijke afstemming, en daar is mijns inziens een PMO office niet voor toegerust. Dat moet je oplossen met product owners, procesanalisten en acceptatietesters die vroeg in de projecten meedenken.
Overigens ben ik het niet eens met de stelling dat projecten 100% succesvol kunnen zijn, daarvoor verandert de wereld te snel, zijn uitgangssituaties vaak onvoldoende in kaart gebracht en mensen nu eenmaal de neiging om van mening te veranderen. Daar is als project niet tegenop te boksen. Je kunt het wel nastreven, maar halen zul je het nooit.
De conclusies lijken vanzelfsprekend, maar zijn niet revolutionair. Een beetje hennetjesgedrag; zoals elk project kan 100 procent succesvol zijn en 100 procent succes is een utopie.
Natuurlijk is er altijd iets wat beter kon. Maar hoe kom je tot bijna 100%? Wat zijn de bekende vaak weer terugkerende faalpunten? Stoeptegel management is één van de terugkerende faalpunten. Wie let op het geheel van projecten en de afstemming projecten en continuïteit? Stoeptegel management uit zich in executive misalignment en kan zelfs tot loskoppeling van ICT en continuous delivery leiden.
Vreemd genoeg wordt programmamanagement in deze discussie niet genoemd. Juist als je de overhead van (deel)projecten klein wilt houden, de doorlooptijd kort en je effectiviteit hoog, dan is goed programmamanagement belangrijk. Anders worden de problemen een beetje tussen projectmanagement en programmamanagement geschoven. Het gevolg is dan lage effectiviteit en lage efficiëntie.