Managed hosting door True

De weg naar succesvolle IT-projecten

Rondetafeldiscussie deel 1

Definitie van succes en voorbereidende maatregelen

 

Rondetafeldiscussie Computable

Met de klok mee de tafel rond: Ben Zwartveld, Leendert Hinds, Fred Bons, Steven van ‘t Veld, Bob van Zeist en Reza Sarshar.

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

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/5118320). © Jaarbeurs IT Media.

7,4


Lees meer over


 

Reacties

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

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

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×