ICT-project kent geen ideale methode

Tips om kansen op projectsucces te vergroten

Bijna dagelijks worden we geconfronteerd met mislukte ict-projecten en de vele miljoenen euro's die dat kost. Het lijkt er op dat ict-projecten helemaal niet kunnen slagen. Wanneer een project niet gestopt wordt, dan wordt het budget wel (enorm) overschreden. Eigenlijk zou er een ideale methode moeten zijn voor het realiseren van ict-projecten. Een utopie volgens de experts van de topics Beleid en ICT-branche, want de ideale methode voor een ict-project bestaat niet. Wel hebben zij tips om de kan op projectsucces te vergroten.

Arjen Droog, interim manager en adviseur, Aranea Interim

Ideale methodes bestaan alleen in de wereld van framework-fetisjisten. Een framework-fetisjist volgt de regeltjes van methoden als Prince 2, Ipma of andere projectmethodieken en beperkt zijn blik op de wereld tot de stapjes van die methodiek. Vaak ontleent de framework-fetisjist hier ook een groot genot aan. Projectmethodieken worden vaak verkeerd gebruikt, met een onterecht gevoel van grip op het project tot gevolg. Ideale methodes zijn er niet, ideale ingrediënten zijn er wel. Denk daarbij aan creativiteit, intelligentie, leiderschap en draagvlak. Framework-fetisjisten beschikken daar niet over en grijpen naar de enige houvast die ze nog zien: de projectmethode.

Leendert Hinds, applicatie- en databasespecialist, Hints Company

Naar mijn mening bestaat er niet een ideale methode, maar bestaan er diverse goede methoden om ict-projecten te draaien. Een goede methode is afhankelijk van een aantal factoren en of combinaties van factoren. Enkele factoren die hierbij een rol spelen zijn soort organisatie, soort project, type projectmanagement, doorlooptijd van het project, projectomgeving en faciliteiten, professionaliteit projectteamleden, projectmanagement methode, projectorganisatie en draagvlak van het management. Iedere factor afzonderlijk kan een project positief of negatief beïnvloeden, maar de combinatie van deze factoren bepaalt uiteindelijk het succes van een project.

Jos van Velzen, principal consultant, KZA

Eerst moet je kijken naar het soort project (innoverend tot en met bread&butter) en daar de noodzakelijke governance-structuur op af stemmen. Dan moet je kijken naar het aantal stakeholders (weinig partijen, veel partijen, onbekende partijen) en daar de noodzakelijke communicatie op afstemmen. Pas daarna moet je kijken naar de omvang van het project (klein, middel, groot) en daar de projectstructuur en de te gebruiken methode op af stemmen. Op deze manier kun je in iedere fase van het project bekijken wat er werkelijk moet gebeuren. Anders ga je met de bekende (oude) projectaanpak het extra werk voor bijvoorbeeld complexe projecten of veel stakeholders er even bij doen.

Mike Chung, manager IT Advisory, KPMG

Organisaties moeten ernstig overwegen om lopende ict-projecten te stoppen en nieuwe initiatieven tegen te houden. Het is nuchter beschouwd bizar dat ict, wat voor veel bedrijven geen core business is, zo verschrikkelijk complex is geworden dat zelfs het implementeren van simpele systemen een heus project vergt. En met elk project, dikwijls geleid door goedwillende dilettanten, neemt de complexiteit verder toe tot op het punt dat de ict de bedrijfsresultaten serieus onder druk zet. En dan heb ik het niet eens gehad over de overschrijding van kosten en doorlooptijd die de norm is geworden voor veel ict-projecten. De ideale methode is dus halt houden en tot bezinning komen.

Sjaak Laan, principal it-architect, Logica

Een ict-project kun je op allerlei manieren runnen, zoals bijvoorbeeld Prince2. De echte vraag zou echter moeten zijn waarom veel ict-projecten te duur worden, niet de verwachte oplossing leveren en waarom ze uitlopen. Wat mij betreft komt dit vooral door onrealistische planningen (vaak beïnvloed door externe krachtenvelden, zoals een door de klant vastgestelde einddatum) en onduidelijke requirements. Zo bevatten Europese aanbestedingen vaak globale requirements, waaraan partijen zich moeten committeren en waaraan ze een prijs moeten verbinden. Na het gunnen van de opdracht blijken de requirements veel genuanceerder te zijn, waardoor het project uit de hand kan lopen.

Frank van Valkenburg, infrastructuurarchitect, Ideas to Interconnect

De drie sleutelwoorden voor succes in ict-projecten zijn context-afhankelijkheid, pragmatiek en multi-disciplinair. Standaard project-methodieken werken nooit voor 100 procent in elke organisatie en binnen elke context. Omgevingsspecifieke omstandigheden moeten van grote invloed zijn op zowel de aanpak als de uitvoering van elk project. Een pragmatische aanpak betekent dat er flexibel wordt omgegaan met bureaucratie, regels en methoden. Dit houdt natuurlijk verband met context-afhankelijkheid. Wanneer een project in silo's wordt uitgevoerd en niet in nauwe samenwerking tussen de verschillende disciplines, is de kans groot op vertragingen en sub-optimale resultaten.

Marc Fleischeuers, architect en adviseur, Cerios IT Architecture

De beste methode voor een ict-project is om er geen ict-project van te maken. Echt, de grootste kans van slagen hebben projecten waarbij wijzigingen van ict een deel zijn van een gewenste wijziging in de bedrijfsvoering. Wat ict meebrengt om het project te laten slagen zijn projectmanagement, architectuur, ontwikkeling en deployment aansluitend op businesswensen. Wat ict van de opdrachtgevers mag verwachten is management van scope gedurende de ontwikkeling van een project en implementatie ervan in de organisatie. Business én ict conformeren zich aan de langetermijnvisie en betrachten budgettaire discipline. Met deze methode kan er echt niets meer fout gaan.

Jurgen van der Vlugt, senior manager audit en advies, Noordbeek

Ach, Prince2 of Agile of ... of ..., het maakt kennelijk allemaal niet zo uit. Het blijft maar misgaan met ‘projecten'. Kennelijk worden de lessons niet gelearned. Dat is niet zo vreemd; de lessons learned zijn wel erg ‘one size fits all'. Terwijl de eigen organisatie zo vaak een grote hiërarchische bureaucratie (eerlijk toegeven) is. En projecten gaan te hard: ze gaan niet mee met de traagheid van de organisatie en de scope van zelfverklaard heel belangrijke en nu trainerende ‘managers' is vaak heel veel groter dan oorspronkelijk voorzien. En in een bureaucratie is remmen het doel. Daar gaat geen Prince2, noch Pino of Nepino, noch Agile, iets aan verbeteren.

Bert Janssen, eigenaar, Maatoplossing

Een ideale methode voor een ict-project bestaat niet. Zaak is de aanpak aan te passen aan de klant. Klanten zijn zo verschillend dat een uniforme methode niet haalbaar is, een uniforme aanpak echter wel. Deze aanpak bestaat dan uit een probleemanalyse: wat wil de klant (opgelost) hebben? Welke producten en technieken zijn toegestaan (vaak afhankelijk van reeds gemaakte keuzes) en de meest variabele factor: met wat voor soort klant heb je te maken en welke personen binnen het bedrijf zijn je sparringpartners? Als al deze factoren duidelijk zijn, kan een 'proof of concept' indien haalbaar de aanpak en functionaliteit verduidelijken en misverstanden voorkomen.

Serge Stijnen, servicemanager, Cofely GDF Suez

De keuze voor een projectmethode moet afhangen van de bedrijfscultuur en passen bij de branche waarin het project uitgevoerd wordt. Organisaties moeten zich in elke fase van hun bestaan aanpassen aan interne en externe veranderingen, die niet als routine kunnen worden uitgevoerd. Deze veranderingen doen zich voor op strategisch, tactisch en operationeel niveau. De huidige methoden zijn voornamelijk gericht op operationeel niveau waardoor er te weinig focus op tactische en strategische doelstellingen is. Voor een grotere slagingskans van projecten is begrip voor de doelstelling, tweezijdig commitment en horizontale en verticale communicatie noodzakelijk.

John Roos, project-, programma- en projectkwaliteitsmanager, Projectadvies-Rotterdam

Het managen van projecten is in essentie gelijk, ongeacht de sector waarin het project wordt uitgevoerd. In de praktijk blijkt wel per sector dat projecten verschillend worden ingevuld. Maar in alle gevallen is echter het projectbasisproces gelijk. De oorzaak van projectfalen komt door een niet realistische en te maakbare business case, onvolwassen projectorganisaties, het ontbreken van veranderingsmanagement, niet methodisch werken of doelen stellen en het niet in staat zijn om een en ander te beheersen en samen te vatten in een waterdicht contract.

Tweederde van bedrijven of projectorganisaties werken niet methodisch. Dit verklaart waarschijnlijk waarom projecten mislukken. Er bestaat geen ideale methode voor een (ict)-project, je moet vooral begrijpen en inzien dat projecten veranderingen zijn en als zodanig benaderd dienen te worden. Een goede projectmanager heeft geen methode of certificaat nodig of het moet een echte vakman zijn. Deze zullen alleen een methode gebruiken als gereedschap en hulpmiddel. Het enige wat we nodig hebben zijn volwassen organisaties en dito managers met realiteitszin die in hun bedrijf projecten gaan leiden. Ik zie de beste projectplannen, maar mis een dergelijke voorbereiding, aanpak en realiteitszin. Ook zie ik maar te vaak gebeuren dat er een te korte opleveringsdatum wordt gehanteerd om maar nog in het budgetjaar te kunnen opleveren, ongeacht de grootte en complexiteit van het project.

Daniël Smits, management consultant, Sogeti Nederland

De ideale methode bestaat niet. Projecten zijn elke keer anders. Sommige zijn groot of klein, andere urgent of juist risicovol. Er is geen methode die past op elk van deze situaties. Het is ook niet de methode die het hem doet, maar de mensen. Belangrijker is bijvoorbeeld hoe betrokken de opdrachtgever en de gebruikers zijn. Ook belangrijk is hoe het project zich verhoudt tot de andere projecten in de organisatie en de bedrijfsdoelstellingen. Projecten worden vaak te individueel beoordeeld. De informatievoorziening moet niet worden gezien als een puzzel met losse puzzelstukjes, maar eerder als een Rubik's cube waarbij alles met elkaar samenhangt. Zo er al een ideale methode is, dient deze dus te beginnen buiten de projectcontext.

Een project moet een bijdrage leveren aan de realisatie van de gewenste informatievoorziening. Dit vereist richting, weten waar je naar toe wilt. Maar ook een adequate onderbouwing zodat bekend is wat de risico's zijn en of wat moet worden gerealiseerd ook haalbaar is. Haalbaar in technische maar zeker ook in financiële zin. Dit alles voorzien van een geïntegreerde besturing. Een utopie? Nee hoor, het behoort allemaal tot het standaardrepertoire van architectuur- en portfoliomanagement. De kunst is vooral ervoor te zorgen dat het ook werkt. Dat de elementen een geïntegreerd onderdeel uitmaken van de ict-besturing. Kortom, weet wat je (een project) vraagt. Problemen uitbesteden aan een project werkt niet. De ideale methode begint al voor de projectdefinitie.

Marcel van Wort, senior consultant, Orange Business Services

Elk succesvol ict-project begint met een gedetailleerde scope welke ten alle tijden te overzien blijft en voortdurend bewaakt wordt door het voltallige team. Belangrijk is dat bij het samenstellen van een projectteam kwaliteit altijd moet prevaleren boven kwantiteit. Met name in de definitiefase waarin belangrijke beslissingen moeten worden genomen, moeten de beste mensen ingezet worden. Veel projecten falen namelijk doordat teveel mensen in een project verstikt worden door onderlinge (mis)communicatie, politiek of verborgen agenda's. Liever twee kwalitatief goede en wellicht wat duurdere mensen die snel kunnen schakelen, elkaar goed begrijpen en een resultaatverplichting dan vijf middelmatige mensen die het overzicht ontberen en op basis van een contract zonder duidelijk einde betaald worden. Om belangenverstrengeling te voorkomen moet aansturing van deze mensen worden gedaan door personeel uit de eigen organisatie met excellent overzicht, inhoudelijke kennis en projectmanagementvaardigheden.

Het gemis in de huidige projectmanagement en ontwikkelingsmethoden is het ontbreken van de menselijke factor boven rigide processen. Zonder de kwaliteit en richting in gevaar te brengen kun je dit probleem alleen maar compenseren door het mandaat en de beloning van het team of leverancier duidelijk te koppelen aan de voorgenomen projectdoelstellingen. De ideale methode kan niet zonder de menselijke factor; motivatie, inzet, kwaliteit maar bovenal gezond boerenverstand.

Migiel Gloudemans, projectmanager, Twynstra Gudde Adviseurs en Managers

Naar mijn mening bestaat er geen ‘ideale projectmanagementmethode voor ict-projecten. Een methodiek is en blijft een hulpmiddel die kan helpen bepaalde resultaten te realiseren. Het goed gebruiken van een methode helpt, maar is niet zaligmakend. Het ligt voor de hand om bij dezelfde opgave dezelfde aanpak te hanteren. Echter, de ene implementatie lijkt wel op de andere, alleen zijn er specifieke kenmerken die deze toch uniek maken. Dit vraagt ook om een unieke aanpak.

Mijn overtuiging is dat de winst hem zit in de mix. De basis hierbij is een projectmanagementmethode zoals Project Matig Werken, Prince2 of PMBoK die veel van de ‘harde' beheersingsaspecten (TGKIO), producten, een business case, structureren faseren en beslissingen bevatten. De ‘zachte' aspecten zijn net zo belangrijk. Hoe acteer je als projectleider, welke ervaring is aanwezig in het projectteam waarmee je werkt of de omgeving van het project? Methoden als conflicthantering, ontwikkeling van teamrollen of strategisch omgevingsmanagement en Agile-projectmanagement zijn dan onmisbaar. Welke mix je kiest op welk moment is van veel factoren afhankelijk. Zo is er voor een SAP-implementatie bij organisatie 1 een ander aanpak gewenst dan voor de realisatie van een bijvoorbeeld een reizigersinformatiesysteem bij organisatie 2. Uiteindelijk begint het met de analyse van de situatie en de keuze welke aanpak je daarbij kiest op welk moment. Alleen dan kan er sprake zijn van een succesvol ict-project.

Abraham de Kruijf, oprichter en principal consultant, IDA Innovatie

De ideale methode omvat business- en ict-mensen samen en leidt tot meer kwaliteit en snelheid, en minder kosten en complexiteit. De ideale methode werkt lekker. ‘Voelt' voor mensen goed en logisch. Gewone mensen kunnen de geproduceerde modellen lezen. ‘De ideale methode doet het niet' maar reikt de mensen wel een manier van denken, brainstormen en structureren aan. Met de ideale methode kun je de leefwereld van je eindklanten (burgers, de uitvoering van wetten, van bedrijven - dit alles noemen we hier de business) modelleren, innoveren en ‘enablen'.

Ieder proces in de business orden je procesgericht: op process execution repetition, op event en op herhaalbaarheid: per dag, per week, per incident, per overschrijding van een norm, etc. Het ontwerp voor je ict-services komt er dan ook meteen uit tevoorschijn. Testen en projectmanagement zitten in de denk- en doewijze ingebouwd. De ontwikkelingsweg was om opnieuw te gaan kijken wat er nodig is om de wereld van de business zo effectief en praktisch te beschrijven dat je er op een directe wijze een informatiesysteem en -services uit kunt afleiden. De basis hiervoor is gelegd tijdens werken voor veel ‘gebruikers¬organisaties'. Business-mensen herkennen hun eigen werk erin. De aanpak werkt ook daar waar organisaties in ketens werken.

Maurice Siteur, managing consultant, Capgemini

De ideale methode bestaat niet. Als deze zou bestaan, dan zouden we toch als ict-medewerkers wereldwijd deze methode gebruiken. En dat zie ik niet gebeuren. En dan is er nog de INO-variant (in name only). Op de een of andere manier vinden we het erg moeilijk om goede ideeën ook zo over te nemen. En vreemd is dat ook niet, want elk project is toch net iets anders en dan moet er ook iets anders. Alleen net iets anders betekent niet dat een methode niet te gebruiken is en daar wringt de schoen nogal eens.

Grote projecten zijn minder goed te besturen, deelprojecten hebben de neiging binnen het eigen deel te optimaliseren. Zelf doe ik ook liever kleinere projecten, want dan heb je veel meer invloed op het eindresultaat. Maar kleinere projecten moeten nog steeds wel volgens een methode gedaan worden. Ik zeg altijd dat het niet erg is als er stappen overgeslagen worden, als dat maar overdacht is; dat laatste zie ik meestal niet. Sommige projecten kunnen niet anders dan groot aangepakt worden, maar er zijn genoeg projecten die in kleinere eenheden opgeleverd kunnen worden.

Jos Struik, directeur, Dataccent

De ideale aanpak is altijd een gecombineerde top down en bottom up benadering. Dat wil zeggen dat eerst in grote lijnen wordt vastgesteld waar we naar toe willen en welke weg daarvoor bewandeld moet worden. Uiteraard zo concreet als dat in de voorbereidingsfase mogelijk is, maar met in ieder geval kwantitatieve een kwalitatieve randvoorwaarden en criteria. Daarbinnen worden haalbare en meetbare stappen gedefinieerd die steeds weer worden getoetst aan het top down plan. Voor het top down deel is met name actieve betrokkenheid van het management nodig en voor het bottom up deel het ict-management en de uitvoerende gebruikers. Met name het steeds weer op elkaar afstemmen van lange en korte termijn is cruciaal. Te vaak wordt het ‘bestemmingsplan' initieel opgesteld, vertaald in een projectenplan en daarna ‘vergeten' of niet getoetst aan de veranderende bedrijfsomstandigheden.

Marjo van Bergen, sr. projectmanager, Capgemini

Stop acuut met zoeken naar de meest ideale methode voor projectmanagement. Stop met het besteden van tijd daarin, neem een (willekeurige) standaard en besteedt je creativiteit aan het oplossen van het probleem voor de klant of voor je opdrachtgever. De legio projectmanagementmethoden die er zijn, zijn goed en vaak goed genoeg. Dus beschouw dat als de standaard en doe gewoon je project. En lever een succesvol project op. De ideale projectmanagementmethode bestaat niet en gaat er ook niet komen. Stop met zoeken naar die heilige graal.

Gert Jan Timmerman, hoofd Kenniscentrum, Info Support

De ideale methode voor een ict-project bevat de juiste mix tussen structuur, flexibiliteit, focus en vakmanschap. Zo zorgt de structuur van het Essential Unified Process (een Agile-variant van Rup, ontwikkeld door Ivar Jacobson) voor herhaalbaarheid en voorspelbaarheid. Door een iteratieve aanpak kan flexibel worden omgegaan met wijzigende business requirements. De methode is sterk ‘use-case-driven' en maakt gebruik van korte iteraties. Hierdoor sluit het heel goed aan bij de sprints van Scrum.

Marinus den Hertog, manager finance, logistics & facilities, Qi ict

Er is geen ‘beste' methodiek voor ict-projecten, maar als ik dan toch moeten kiezen dan kies ik voor Prince2. Niet de gehele toolbox maar alleen de relevante onderdelen voor het betreffende project. Het belangrijkste in een project is communicatie en verslaglegging. Zo weet iedereen binnen een project waar het om gaat. Pragmatisch omgaan met situaties en de projectinvulling moeten voorop staan. Ict-projecten, zeker in infrastructuur, moeten in elk geval gerund worden door een projectmanager die ter zake kundig is. En dan niet alleen op projectmanagementvlak maar ook op technisch vlak. In infrastructuurprojecten heeft de projectmanager vaak te maken met zeer veel ‘externe' factoren, die allemaal hun invloed hebben op het welslagen van het project. Denk aan serveromgeving, applicaties, verbindingen, isp's en telco's, etc. Technische achtergrond om dit speelveld te kunnen doorgronden is essentieel.

Marcel Naumann, managing consultant, VLC

Voor het invoeren van BI-trajecten is het ideaal als de methode die je gebruikt de business gedurende het gehele traject centraal stelt. Vanaf het begin zal de nadruk moeten liggen op de toegevoegde waarde die het BI-traject gaat opleveren in relatie tot de bedrijfsdoelstellingen. De methode moet primair de aandacht hebben op het kunnen en willen gebruiken van de oplossing. Stel daarom in een vroegtijdig stadium vast welke gebruikersgroepen betrokken zijn bij het gebruik van het eindproduct. Per gebruikersgroep zal de vraag gesteld moeten worden wat er moet gebeuren om het product acceptabel te maken. Hierbij staan begrippen als adoptie, communicatie, participatie, educatie, organisatie en documentatie centraal. Als duidelijk is wat er op deze gebieden moet gebeuren, zal duidelijk zijn op welke manier het BI-traject zijn toegevoegde waarde aan de bedrijfsdoelstellingen kan leveren. Het focussen op de toegevoegde waarde voor een organisatie is het element dat in de meeste methoden onderbelicht blijft en is een reden waarom BI-trajecten vervallen tot ict-feestjes.

Steven van 't Veld, zelfstandig principal informatiekundige, A/I/M

Methodisch werken in ict-projecten is handig, maar is in de informatie- en it-sector volledig doorgeschoten. Essentie om dat echt te verbeteren is door als opdrachtgever geen opdrachten tot investeren via ict-projecten meer te geven als je niet goed genoeg weet wat zo'n ict-project moet opleveren. Dat betekent voor de huidige methoden dat de voorfasen uit ict-projecten gehaald zullen moeten worden, met als resultaat dat projecten veel korter zullen worden, beter gepland kunnen worden en ook nog een veel hogere kwaliteit zullen opleveren omdat je vooraf al wist wat opgeleverd moest worden.

Die eerste fasen van de methoden worden in de organisatie zelf uitgevoerd onder verantwoording van die organisatie voordat die organisatie opdrachtgever wordt. Dat is werk voor eigen informatiekundigen, niet voor ict'ers c.q. ict-leveranciers. En als die informatiekundigen dan ad interim ingehuurd moeten worden kunnen ze, wegens functiescheiding, niet gebonden zijn aan de organisaties die ict-projecten voor de organisatie als opdrachtgever uitvoeren. Methoden zullen dus drastisch ingekort moeten worden ten aanzien van de eerste fasen en ten aanzien van de testfasen aan het einde. Daarmee worden methoden voor ict-projecten zodanig veel kleiner dat we de kennis al lang hebben om ze echt goed uit te werken.

Door de huidige situatie gaat ontzettend veel fout en dat kost miljoenen zo niet miljarden. Immers, een niet goed opgezette ict-oplossing zal ook nog eens keer onderhouden moeten worden. Het bovenstaande betekent een enorme verandering in de informatie- en ict-sector, maar we kunnen niet verder op de huidige manier als we echt tot een goede inzet van ict willen komen. Ict is op dit moment eerder een blok aan het been van verandering dan dat het verandering mogelijk maakt, en dat kost extreem veel.

Robert Garskamp, sr. projectmanager, Everett

Voor een integratieproject is het bereiken van doelen vaak nog moeilijker dan voor een traditioneel ict-project. Een specifiek aspect van integratieprojecten is dat ze de neiging hebben zich te richten op de infrastructurele aspecten van middleware en niet op zichtbare functionaliteit. Hierdoor wordt het belang voor de business gemakkelijk uit het oog verloren. Het duurt lang voordat de toegevoegde waarde voor de business duidelijk wordt en dat tegen een aanzienlijke investering. Wanneer er al resultaten zijn is het vaak het geval dat ze niet meer voldoen aan de verwachtingen.

Kleine en/of grootschalige integratieprojecten waarin middleware een rol speelt, is het creëren van zichtbare toegevoegde waarde een uitdaging. Een toegepaste methode om dit te bereiken is het combineren van de iteratieve ontwikkelmethodiek Scrum met de vertrouwde en beproefde project methodiek Prince2. Scrum zorgt ervoor dat gedurende het project op iteratieve wijze zichtbaar toegevoegde waarde wordt opgeleverd. Prince2 biedt het kader voor controle en governance dat een project nodig heeft. De combinatie van Prince2 en Scrum geeft een krachtige aanpak die een toegevoegde (functionele) waarde levert, terwijl de risico's onder controle blijven.

Het basisidee achter deze methode is het vroeg betrekken van alle belanghebbenden en ze meenemen in de ontwikkeling naar het resultaat, door in korte iteraties tastbare functionaliteit op te leveren. Gedurende het project zorgt deze methode voor controle door het opdelen van functionaliteit in handelbare stukken zonder van tevoren alle details van de oplossing in te vullen. Het gebruik van deze methode op deze manier is een gedegen manier om integratieprojecten aan te pakken. Veel van de valkuilen van huidige integratieprojecten worden aangepakt door ervoor te zorgen dat het team zichtbare toegevoegde waarde levert gedurende het project, om te kunnen omgaan met veranderingen en grip houdt op de kosten, risico's en kwaliteit.

Alex Aalberts, managing consultant, Capgemini

De ideale methode om een ict-project te draaien is een methode die recht doet aan de verschillende partners in een project. Dat zit niet zozeer besloten in een feitelijke aanpak als Agile, Rup, Dsdm, iteratief, incrementeel, etc. De basis voor succes is de manier waarop de samenwerking tussen de opdrachtgever en het project is ingericht. Dit kun je ook zien als de balans tussen vraag en aanbod. Dat staat los van wat we vaak de methode noemen.

Wanneer de vragende partij en het leverende project op basis van wederzijds vertrouwen kunnen samenwerken, komen er vaak net iets betere oplossingen dan tevoren bedacht. Dat gebeurt dan wel binnen de beschikbare resources (meestal praktische zaken als tijd en geld). Dat kan dan wel redelijk efficiënt gemaakt worden en levert zo dus een hoge waarde voor de afnemers op. Wat er daarentegen gebeurt wanneer de focus van de partijen zich alleen maar richt op de discussie over de scope en wat er voor de afgesproken kosten geleverd moet worden, dan zijn in mijn beleving alle methoden toch echt gelijk. Dan hebben contract en angst de betere (of misschien wel ideale) oplossing in de weg gestaan.

Experts gezocht

Computable heeft op al zijn 26 topics een expertpanel. Wij zoeken echter altijd meer experts, op al onze topics, maar voor de komende tijd zoeken wij specifiek naar experts voor de topics Mobility, Development/Testing, Netwerken en Business Intelligence.

Ben jij expert op een van deze vakgebieden of een ander Computable-topic en wil je als vraagbaak van de redactie dienen, stuur dan een e-mail met je gegevens (naam, functie, bedrijf, werkzaamheden) naar experts@computable.nl.

x

Om te kunnen beoordelen moet u ingelogd zijn:

Dit artikel delen:

Reacties

Een aantal commentaren geeft aan waar de echte kneep zit in "ICT-projecten".
Er lijkt breed geen enkel besef aanwezig tussen een aanpak die vanuit de klant helpt te waken over verandering, misschien toevallig met ICT, en de daar uit voorvloeiende toegevoegde waarde (PRINCE2) en ICT ontwikkel aanpakken die vanuit de leverancier gestuurd te worden.
Er blijkt maar weer: a fool with a tool is still a fool.

Het zou niet verkeerd zijn als mensen het begrip "methode" eerst eens uiteenzetten.

In een woordenboek van encarta/winkler prins stond de volgende beschrijving van "methode":

“bepaalde, welbedachte manier van handelen om een bepaald doel te bereiken...".

Veel bekende "methoden" bieden geen zekerheid. Ze komen niet boven het niveau van een checklist uit. Het volgen van een checklist valt zeker niet onder de noemer methodisch werken. Een methode moet ook inhoudelijk aangeven hoe je je doel bereikt.

Er zijn drie hoofd-issues. Architectuur, Techniek en Organisatie.

ARCHITECTUUR

Het is bijzonder listig om voor de gehele organisatie de systemen onder één logische architectuur te ontwikkelen. Het werken met gestandaardiseerde interfaces, onafhankelijke subsystemen, stuur-laag, business-laag, datalaag, service-laag, loket-services met telkens één aanspreekpunt per subsysteem, geeft de plezierige mogelijkheid van ook binnen de subsystemen, verwisselbare modules. De standaard-interfaces bieden een simpele mogelijkheid voor SOA aanpak. De nieuwe systeemonderdelen zijn maanden voor het échte moment al in productie, tot dat moment echter slechts werkzaam voor de test-cluster. Single-points of faillure zijn verboden. Domino-effecten worden op voorhand geëlimineerd. Systemen onder architectuur draaien altijd, 24 x 7. Fouten worden gerapporteerd maar leiden niet tot het stoppen van een systeem. Services worden desnoods herleid. In plaats van schier oneindige spaghetti krijg je overzichtelijke lasagna-units.

Projectleiders zijn niet altijd gecharmeerd van architectuur. Het zou overhead geven en zo. Teveel rekening moeten houden met anderen. Niet dus. Stel een Architectuurteam aan en geef dat de mogelijkheid om zeg 40% van het totale ICT-budget toe te kennen aan de betere plannen. De projectleiders zullen met graagte hun plannen aan het A-team voorleggen om ook “subsidie” te verdienen. Het A-team zal door hergebruik van gemeenschappelijke componenten over de projecten heen, op voorhand veel besparingen realiseren. Uniformiteit van werken, leidt tot grote herkenbaarheid van elkaars werk. “I love it when a plan comes together”…

TECHNIEK

Bij de Jackson aanpak zijn er tijdens de ontwerpfase van een systeem verschillende momenten waarbij de eerdere stappen elkaar "ontmoeten" waarbij eventuele onmogelijkheden vroegtijdig worden onderkend. Dit geldt voor alle technische fasen van deze methode. Er wordt gewerkt met een model van de werkelijkheid dat zich uitstekend leent om met een gebruiker te bespreken. Als jouw team Jackson System Development (JSD) volgt, heeft jouw project alle kans om in technisch opzicht te slagen. JSD mag met recht een methode genoemd worden.

ORGANISATIE

Uiteraard zijn er ook organisatorische aspecten die van het grootste belang zijn voor succes. Het kan z’n charme hebben om een ervaren projectmanager van een groot softwarehouse of van een organisatie als IBM in te huren die als hoofd-aannemer voor garanties zorgt. Hij/zij zal na een globale verkenning, de harde, organisatorische- en financiële randvoorwaarden voor succes op papier zetten. Laat deze hoofdaannemer vervolgens het zelfopgestelde en door jou (de klant) goedgekeurde contract nakomen in combinatie met interne en/of externe partijen. Laat een eigen hoofdrolspeler als rechterhand functioneren.

Mijn ervaring is dat door een goede combinatie van architectuur, techniek en organisatie, het project een bijzonder grote kans van slagen heeft.

@Crox,

ik ken alleen prince2, die is populair en zeker geen checklist. Zekerheid wordt i.d.d. niet geboden, maar de mate ervan wordt beschreven in termen van risico's. Prince2 erkent juist dat 100% zekerheid niet geboden kan worden, maar dat de onzekerheid wel op papier gezet moet worden.

JDK is een ontwerpsoftwareontwikkelmethodiek. Dit artikel is veel generieker, het gaat over ICT project-methodieken. In tal van ICT-projecten wordt helemaal niet ontwikkeld. Bovendien wordt JSD volgens mij al 10 jaar als verouderd beschouwd en kiest het bedrijfsleven voor alternatieven, RUP, agile, Extreme Programming enzo.

prince2 maakt een stricte scheiding tussen wat het doel van het project is, de zg business case. Zo te lezen maak jij de randvoorwaarden zelf, das niet de taak van een projectleider/uitvoerder.

@chocoprins
In een JSD publicatie uit 1983 werd het begrip “entity” beschreven. In actuelere terminologie zou je het nu “object” met “lifecycle” noemen. Professor Verhelst beschreef ‘zijn’ “Merode”, verloor daarmee de aansluiting evenals de TU-Twente die een onzin syllabus hanteerde die zo vreselijk fout was...
JSD is doorlopend verder geëvolueerd maar daarbij wél een echte methode gebleven. Vooral de filosofie is essentieel. Die pak je niet uit een boek op. Daarvoor moet je gecoacht worden.

Iedere nieuwe “methode” heeft zijn eigen dictionary, suggererend dat het “oude” niet relevant is. ICT-ers lijden zwaar aan het gadget-syndroom. Alleen “nieuw” is goed. Voorbeeld: Word ’97 is zogenaamd zwaar verouderd maar… hoeveel relevanter is Word 2007 precies? Welke toegevoegde functionaliteit is essentieel? Ondertussen geven organisaties miljarden uit aan “vernieuwing”….

Mensen volgen graag “de mode” en veroordelen alles wat eerder kwam als niet van deze tijd en “dus” irrelevant. Onjuist en vooral gemakzuchtig. Zoveel verandert er niet. Lees voor de aardigheid eens het boekje “Project-management in de automatisering” van R. Scholten. Oud? Zeker! Maar wat is er precies veranderd? Precies! Weinig. Een beetje analoog aan de thema’s in ninja-klassiekers. De oude ninja-master loopt met zijn technieken mijlen ver voor op de newbees. Daar verandert de nieuwste dictionary in het geheel niets aan.

Prince2 beschouw ik als een beschrijving van vooral een project monitor met een pitsie pre-project beschrijving. Ik krijg er geen warm gevoel bij. Waar helpt het jou? Wat is de toegevoegde waarde ten opzichte van iedere andere so called “methode”?

Voorafgaand aan ieder project is het van belang dat er inzicht is in de bestaande bedrijfs-activiteiten, met of zonder interne danwel externe ICT-ondersteuning. Een globaal JSD-model werkt voor mij goed. In ieder geval een visuele vorm die zich laat afstemmen met de business. Ook een mindmap is denkbaar. De centrale ICT-sturing m.b.t. de systemen, zie ik graag in handen van het architectuur-team dat een totaal-overzicht heeft. Dat team ondersteunt bij het opstellen van de business-case zodat er geen losse eindjes ontstaan. Veranderingen in de werkwijze moet je niet willen verzinnen als je de bestaande nog lang niet kent: “Don’t change the rules before you have learned them”

Een goede projectleider probeert risico’s af te dekken en stelt dus de randvoorwaarden op voor zijn project. Dit zijn de noodzakelijke garanties m.b.t. beschikbaarheid van middelen, functionarissen, gebruikers, computers, ontwikkelaars, werkruimte, acceptatie, etc. etc. Zie Scholten.

Uiteraard staat mijn klant altijd centraal en is koning.

Een wijze man vertelde mij eens: "Alle projecten kunnen slagen". Mits de projectbewaker 3 factoren in het oog houdt: ambities, middelen en tijd. Zolang men kan blijven draaien aan deze knop, zorg je voor een wenselijk resultaat. Ik denk dat de theoreten en praktisanten mooie kloven teweeg kunnen brengen in het al dan niet slagen van een project. Ik vermoed dat in de praktijk de knop 'ambities' wat vaster zit....

@Crox,

ok, ene professor Verhelst heeft een ge-update versie van JSD uitgebracht en jij bent bent daar fan van. Inderdaad was hij er opmerkelijk vroeg bij met z'n object orientatie.

http://bit.ly/d3DNrW blijft echter een
http://bit.ly/dksVwp en geen
http://bit.ly/ahRTVS methode.

Volgens mij zijn bij Software Ontwikkeling, iteratieve methoden overigens wezenlijk anders dan de waterval.

Ik geloof verder best dat jij succes hebt met jouw aanpak en veel moderne projectmanagers met hun aanpak minder. Dat komt in mijn ogen, omdat de gezond verstand en ervaring veel belangrijker is dan de methode. En zo zijn we weer terug bij het oorspronkelijke artikel en laat ik het hierbij.

@chocoprins
Ik ben geen fan van Verhelst hoor. Hij verloor juist de aansluiting en heeft vooral zichzelf plezier bezorgd.

JSD is niet iteratief en ook geen waterval-methode.

Tussen de vooral zinnige gedachten en adviezen, staat ook verwarrende nonsens De één snapt niet dat er geen ICT-projecten zijn (goede correctie Nico Viergever). Anderen doen net alsof een methode niet op zich goed kan zijn omdat de projectmanager en/of de opdrachtgever niet goed functioneert. Weer anderen maken geen onderscheid tussen het niveaus van projectmanagement (sturen en besturen) en van ontwikkeling.

Als “specialisten” al dit soort verwarring scheppen, is het dan vreemd dat zo veel ICT-gerelateerde projecten en projectmatige activiteiten de mist in gaan?

Goed vind ik het overstatement “De ideale methode is dus halt houden en tot bezinning komen” van Mike Chung. De meeste onervaren projectmanagers tonen een overdreven “Yes We Can” houding. Ja je kan wel een nonsens opdracht oppakken, deze op een nonsens wijze uitvoeren en daarvoor een nonsens rekening voor indienen, maar wie heeft daar baat bij?

Nee zeggen, de behoefte onderzoeken en dan bekijken of er een goede businesscase gemaakt kan worden, is inderdaad vaak veel beter dan de zoveelste valse start maken of doormodderen met een fout project.

om een of andere reden zijn de hyperlinks naar wikipedia in mijn vorige reactie door Computable omgezet in zo'n bit.ly vorm. Dat is kennelijk niet altijd goed gelukt of gedaan.

Is er een ideale methode voor een ict-project?

Nearshore bedrijven, zoals Levi9, leveren hun ict diensten vanuit Oosteuropa met goed opgeleide ict professionals. Onze klanten willen aan de ene kant controle over het ontwikkelproces maar ook de flexibiteit houden die ze met lokale ict professionals hebben.

Daarom hebben wij veel geïnvesteerd in het opzetten van een ontwikkelmethodiek die hierbij past. We zijn uitgekomen bij Agile Development op basis van Scrum. Scrum is een iteratieve en incrementele ontwikkelmethodiek waarbij het team (de klant business experts en de nearshore ict professionals) samen in zogenaamde timeboxed sprints van twee tot vier weken een aantal functionaliteiten realiseert.

Onze klanten hebben volledige controle over het project omdat er dagelijks contact is met de ict professionals en onze klanten volledig inzicht hebben in de productiviteit van het project middels ondersteunende tooling die de productiviteit inzichtelijk maakt.

Daarnaast biedt deze ontwikkelmethodiek onze klanten de flexibiliteit om wijzigingen in functionaliteit gedurende het project door te voeren.
Voor ons is deze ontwikkelmethodiek ideaal omdat we onze ict diensten vanuit Oosteuropa kunnen leveren tegen lage kosten met goed opgeleide ict professionals en de controle en flexibiliteit die onze klanten wensen.

Wanneer draagt een methode bij aan het project succes?
Wordt er met de klant wel afgesproken wat de succescriteria zijn?
En een methode is toch ondersteunend aan het project proces?
Elk project heeft zijn eigen karakteristieken en heeft daarom ook zijn eigen dynamiek die gemanaged moet worden. Dit betekent ook dat je altijd tailored naar de behoefte.
Methode als doel betekent dat je er nog niets van snapt.

Als ik zo eens door de reacties van de deskundigen heen lees, wordt in mijn ogen het cultuur-aspect van de opdrachtgever onderbelicht.

Wat voorbeelden:
- je kunt als projectmanager wel roepen dat je een project teruggeeft aan de opdrachtgever, maar als je dat 3 keer doet, kun je je biezen pakken...
- een stuurgroep is best leuk bedacht, maar wat doe je als je stuurgroepleden geen ruggegraat hebben, en alles maar accepteren van bovenaf? Het project is de dupe...
- te vaak wordt er uitgegaan van het ideale scenario; de risico's worden onderkend, maar mogen niet uitkomen, anders gaat de hele planning aan de haal. Als projectmanager wordt je weliswaar geacht deze risico's te managen, maar dan moet je er ook de middellen voor krijgen
- het leukste is uiteraard een marketing afdeling, die een leverdatum van het product afgeeft, zonder met het project te overleggen, liefst met nieuwe mogelijkheden waarvan het project het bestaan nog niet kent
- bij teveel "heilige huisjes" binnen een organisatie, kan het zijn dat het ene huisje andere prioriteiten heeft dan het andere, waardoor je project behoorlijk in de squeeze kan komen te zitten. Als je geen management boven je hebt die hier iets aan kan/wil doen, wordt het heel lastig managen
- een "afreken-cultuur" helpt vaak ook niet; men durft slecht nieuws niet te brengen uit angst voor represailles, en tegen de tijd dat ze er echt niet meer onderuit kunnen het slechte nieuws te brengen, kan het project geen kant meer op


Mijn ervaring is dat hoe groter, hoe multi-disciplinairder, hoe multi-cultureler het project is, hoe groter de kans op uitloop.

Zeker wanneer het project naast software ook hardware / electronica / mechatronica bevat, met ontwikkeltijden van maanden, met prototypes een productie-aanlooptijden van enkele weken, dan gaat zelfs agile/scrum je niet meer helpen

Gezond boerenverstand blijven gebruiken, met eventueel een methode als hulpmiddel... De methode mag nooit het doel op zich worden, dat zie ik vaak bij Prince2. De methode staat in dienst van het doel; als dat niet meer het geval is moet je er direct afscheid van nemen.

Mij bekruipt het gevoel van "nog steeds de mythe...

Al vele decennia wordt er gesproken over dat een groot deel van ICT projecten dat mislukt.

Echter, wanneer een project als mislukt wordt beschouwd wordt er niet bij gezegd. En ook niet hoeveel en welke projecten men beschouwd heeft.

Soms denk ik wel eens dat ik voor hetzelfde geld kan beweren dat een groot deel van ICT projecten lukt. Er is toch niemand die het onderbouwd met feiten kan weerleggen.

Men conclusie is dat het belangrijker is te kijken wie beweert dat ICT projecten vaak mislukken. Vaak speelt er eigen belang mee.

@Bernhard van Oranje, leuke sluikreclame voor Levi9, maar we hebben het over projectmethoden, niet over ontwikkelmethoden. Dat laatste geldt ook voor Crox.

Wanneer
Software ontwikkelmethoden en –technieken moeten gebruikt worden bij een project waarbij software ontwikkeld wordt. Aan ontwikkelmethoden heb je niks als je voor het project niet gaat ontwikkelen. Je hebt verhuisprojecten, implementatieprojecten na koop van standaardsoftware, enzovoorts. Dan

Hoe lang
Een projectmethode kan je al gebruiken voordat het project gedefinieerd en goedgekeurd is. Met een goede projectmethode kan je een projectvoorstel ook bijtijds geheel afwijzen of qua opzet, scope en dergelijke aanpassen.
Ontwikkelmethoden gebruik je slechts voor één of meer fasen van een project en niet voor de duur van het gehele project.

Business en ICT
Een projectmethode gebruik je ook voor aspecten buiten de ICT. Richt je met de projectmethode alleen op de ICT, dan knip je een project in feite in een ICT- en in een niet-ICT-onderdeel zonder goede afstemming tussen ICT en business. De problemen worden over de schutting gegooid, de klant krijgt niet wat die nodig heeft, enzovoorts.
Door een projectmethode door een ontwikkelmethode te vervangen, ontstaat een dergelijke situatie automatisch. Een analyse- en ontwerpmethode zoals JSD zit veel te dicht tegen JSP aan om generiek als projectmethode ingezet te kunnen worden. Dat moet je niet eens proberen, ook al gebeurt het helaas nogal vaak.

Sorry, Crox en Bernhard, maar als jullie dit soort zaken niet van elkaar scheiden, dan vrees ik dat jullie klanten slecht bediend worden.

www.garansys.nl

Stuur dit artikel door

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

×
×
article 2010-10-12T09:03:00.000Z Sander Hulsman
Wilt u dagelijks op de hoogte worden gehouden van het laatste ict-nieuws, achtergronden en opinie?
Abonneer uzelf op onze gratis nieuwsbrief.