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