De factoren die het succes of het falen van een ict-project bepalen, zijn bekend maar onbemind. Dit stelt Aart van Dijk. Hij promoveerde aan de Middlesex University in Engeland op onderzoek naar Nederlandse ict-projecten. 'Veel projecten zijn te ambitieus', concludeert de Doctor of Engineering (EngD). De oorzaak ligt volgens hem in een gebrek aan deskundigheid in het vakgebied.
'Project managers leren niet van de fouten die anderen eerder hebben gemaakt. In 1982 is een boekje uitgekomen van Jan Oonincx met de titel 'Waarom falen informatiesystemen nog steeds?'. Dit zou zo herdrukt kunnen worden. Het is een treurige zaak', zegt Van Dijk. Naast het werk van Oonincx analyseerde hij voor zijn promotieonderzoek talrijke andere publicaties en artikelen over geslaagde en minder geslaagde ict-projecten. Ook gebruikte hij zijn eigen ervaringen als IT auditor.
Op basis van zijn literatuurstudie en de audits die hij uitvoerde, stelde Van Dijk een checklijst samen. Wanneer een project manager deze lijst naloopt om te controleren of hij goed is voorbereid, zouden er volgens Van Dijk een hoop fouten kunnen worden voorkomen. 'Veel scenario's vragen al bij voorbaat om problemen. Als je honger hebt kun je ook niet een heel brood in één keer in je mond stoppen'.
Betrokkenheid
In zijn proefschrift stelt hij dat een klein project meestal nog wel is te overzien, maar dat het lastiger wordt naarmate de omvang toeneemt. 'Wanneer een project verdubbelt in grootte, betekent dit niet dat de moeilijkheidsgraad lineair toeneemt. Deze neemt kwadratisch toe. Het is daarom van belang een project vooral niet te groot te laten worden. Dan gaat het geheid fout.'
Maar naast de grootte van een project en het gebrek aan deskundige project manager bepalen ook andere factoren of een ict-project slaagt of juist gedoemd is te mislukken. 'Heel vaak blijkt de communicatie met de opdrachtgever slecht te zijn', licht Van Dijk toe. Maar ook onvoldoende betrokkenheid van de toekomstige gebruikers van een systeem en gebrek aan toewijding bij het senior management zijn bepalend voor het welslagen van een ict-project.
Sturing op tijd en geld? Randstadrail faalde voorspelbaar omdat er alleen op tijd en geld werd gestuurd. Heathrow T5 eindigde ook op tijd en binnen budget. Ook hier speelt weer het thema ‘leren’.
Al ongeveer twintig jaar geleden wees onderzoek in Australië uit dat alle projecten die op tijd en geld eindigden vijf jaar later werden gezien als falend.
Sturen op tijd en geld alleen is een variant op het thema van doel en middel verwarren.
De opdrachtgevers hebben vaak boter op hun hoofd. Lekker uitbesteden aan een derde partij. Dan zijn zij van de verantwoording af.
Die kunnen dat vaak zelfs niet met de beste wil van de wereld managen, maar het levert gelukkig wel een dikke boterham op.
Ik denk dat op de eerste plaats de fouten die de projectmanager heeft gemaakt door hem zelf zullen moeten worden onderkend. Zodra het besef er is kan hij deze in toekomstige situaties voorkomen. Een project manager is ook maar een mens…
Er is nog een verzachtende omstandigheid. Ieder project is uniek. Hoezeer is de projectmanager in staat om ook in een geheel andere situatie, setting, dezelfde optredende fouten tijdig te herkennen en te voorkomen, dan wel op te lossen? Niet dat het hem vrij pleit om niet te leren van zijn fouten, maar de kans bestaat…
Het niet leren van fouten kan op elk gebied geplaatst worden. De kop is dan ook niet bijzonder.
Kijkende naar de internationale certificering en de steeds zwaarder wordende competentie modellen voor de projectmanagers dan kan je niet zeggen dat ze het vak niet begrijpen of de deskundigheid missen. Als dat zo is dan moeten alle PRINCE2, IPMA en PMI opleidingen herzien worden.
Verder wordt niet duidelijk wat nu verstaan wordt wat nu een mislukt project is? Als het project vanaf start met een gedegen wijzigingsprocedure aan kan geven en verklaren dat zij uit de oorspronkelijke stuurmiddelen (Scope, Tijd, Budget of Kwaliteit) zijn gelopen, dan is dit voor mij geen mislukt project.
Ook is het logisch dat iets kleins overzichtelijker is. Daar heb ik geen onderzoek voor nodig. Grote projecten hoeven ook geen problemen om te leveren. Je kan een project indelen in meerdere fases en daarmee e.e.a onder controle en sturing te houden. Zie onder PRINCE2 2009 tailering projecten.
Tja, en wat is nu groot?
Waar ik het wel mee eens ben is de slechte communicatie met…(niet alleen opdrachtgevers),onvoldoende betrokkenheid van de toekomstige gebruikers en het gebrek aan toewijding bij het senior-management.
Kortom, op basis van het artikel ben ik niet van mijn stoel gevallen. Ik zal kijken of ik meer wetenschap kan vinden bij deze promovendus waar ik misschien wat aan heb en nieuw/bruikbaar is voor mij.
John Roos
06 81430098
Interessant artikel. De nieuwe lichting ict-projectmanagers leert niet van de fouten die anderen eerder hebben gemaakt. Dat klopt in het algemeen. Dit zegt veel over hoe het lijnmanagement (en accountmanagers van de detacheerders) nog steeds (deel)projectleiders door laten stromen naar de positie van projectmanager en over hun gebrekkige begeleiding.
De young potentials worden te vaak snel op een voetstuk gezet om ze daarna aan hun lot over te laten. Bij elke stap in je loopbaan kun je hulp gebruiken. Opdrachtgevers moeten niet alleen de juiste mensen kiezen, maar ze ook in staat stellen om te leren de opdracht goed uit te voeren. Veel zaken leer je pas goed door ervaring. Bij een cursus leer je vooral technieken, maar weinig hoe je als persoon om moet gaan met nieuwe uitdagingen.
De kaalslag onder de ervaren, te ‘dure’ projectleiders heeft vele kostbare flops opgeleverd. Die ervaren projectleiders zien veel eerder dat de projectsituatie niet klopt. Ze durven dit ook te zeggen omdat ze dit niet als hun eigen falen zien, maar als een gemeenschappelijk probleem.
Opdrachtgevers leren net zo min van de fouten bij ICT-projecten. Toch zijn zij niet alleen in formele zin de eindverantwoordelijke. Opdrachtgevers moeten er voor zorgen dat de startsituatie voldoet aan de eisen van het project, dat de verdere communicatie met de projectleden goed is, dat de gebruikers, beheerders, betrokken blijven bij het project, et cetera.
Ict-projecten zijn bedrijfsprojecten. Maar vooral ict-projecten zijn vaak slecht gefundeerd omdat ze niet tot de core business van de opdrachtgever horen. Veel ict-projecten zijn niet eens projecten, maar een nog uit te werken ict-programma, een ict-experiment, of slechts een opgeblazen illusie met een ict-component. Opdrachtgevers zouden in veel gevallen niet eens het startsein voor een project moeten geven omdat het geen echt project is, de business case niet deugt, enzovoorts.
Kortom:
– Projectleiders moeten niet te snel doorstromen omdat ze relatief goedkoop zijn, maar moeten de tijd krijgen om zich te ontwikkelen tot goede projectmanagers.
– Ervaren projectmanagers moeten voor de arbeidsmarkt behouden blijven.
– Opdrachtgevers moeten leren hoe een project met een ict-component te definiëren en hoe deze goed aan te sturen.
– Aankomende ict-projectmanagers moeten leren wat (= hoe weinig) het algemene management weet van projecten met een ict-component.
Een methodologie als Prince2 kan een mooie kapstok zijn om een project aan te hangen, maar het geeft geen houvast aan de projectmanager op cruciale aspecten zoals planning en communicatie. En het is juist bij deze aspecten dat de meeste projecten de mist in gaan.
Projectmanagement zal nooit een exacte wetenschap worden, maar is overgeleverd aan de mate waarin een PM in staat is de welbekende best practices op maat toe te passen. Daarbij zijn best practices niet eeuwig houdbaar, ook die zijn onderhavig aan voortschrijdend inzicht.
Dit artikel roept bij mij meer vragen op dan dat het antwoorden geeft.
Wie bepaalt of een project faalt? Welke objectieve criteria zijn daarvoor vast te stellen, onafhankelijk van het perspectief van de (be)oordeler? Hoe is eenduidig vast te stellen wie wanneer verantwoordelijk was voor de gemaakte “fouten”?
Nogal wiedes ook dat eenvoudige projecten (met minder activiteiten en kortere doorlooptijden) minder problemen met zich meebrengen dan complexere projecten (met meer mensenwerk, meer communicatiemomenten, meer omgevingsfactoren en langere doorlooptijden en dus meer kans op externe invloeden en wijzigende verwachtingen).
Ik geloof niet in checklists die proberen de toekomst te voorspellen of fouten te voorkomen (zie “The Black Swan” van Nicholas Taleb). Het is achteraf (met de wetenschap van vandaag…) makkelijk te verklaren waarom een bepaalde keuze niet juist heeft uitgepakt, en te concluderen dat we met een andere keuze een betere uitkomst zouden hebben gehad.
De checklist kan verworden tot een doel op zich, en dat heeft tot gevolg dat het resultaat/doel van het project ondersneeuwt. Of dat het project dan maar geannuleerd of uitgesteld wordt, wat dikwijls ook geen wenselijke conclusie is..(?)
Het is (en blijft) kortom de taak van de opdrachtgever en de opdrachtnemer om een evenwicht te vinden in pragmatisme en controle, en het gezamenlijk aanvaarden van de consequenties van gemaakte keuzes – inclusief de openheid van communicatie en de keuze voor de in te zetten project manager(s).
Het is (en blijft) de taak van de project manager om met de hem/haar ter beschikking staande kennis, ervaring en middelen (inclusief methodieken zoals Prince en PMBOK) het project te managen, en aan begin en eind van het project een kritisch (self-)assessment uit te voeren.
Kan je leren van een boekje? Leren doe je volgens mij door iets voorgedaan te krijgen, dan zelf te doen onder begeleiding en dan zelfstandig te doen. Neem als (te onervaren) projectmanager dus niet te veel hooi op je vork. Ambitieus zijn is niks mis mee, maar organiseer hulp als je dat nodig hebt.
Projectmanagers moeten inderdaad leren van hun fouten en sommige kunnen dat ongetwijfeld beter dan anderen…
Echter enige nuance is ook op zijn plaats; een projectmanager rapporteert altijd aan een stuurgroep en of directie van de uitvoerende kolom. Helaas heb ik bij diverse grote ICT bedrijven schrikbarende uitvoerende directeuren en verkoop directeuren meegemaakt; als deze types geen kaas gegeten hebben van projectmanagement, worden de PM-ers simpelweg overruled wanneer zij aan de bel trekken om zaken die niet goed lopen aan te kaarten (vaak moet dit in samenspraak met de klant) en oplossingen uitwerken. Als de directies hun kop maar lang genoeg in het zand steken (of alleen maar kunnen roepen dat het moet worden ‘af-gemanaged’), dan ontploft het project vanzelf, waarbij de projectmanager wordt aangewezen als boosdoener, alleen ben ik helaas in de werkelijkheid zowel bij klant als leverancier teveel directeur-tjes tegengekomen die domweg niet luisteren of ingaan op de wensen van de PM om de doelstellingen wel te halen.. dit frustreert alleen maar en maakt het vaak onmogelijk om grotere projecten succesvol af te ronden… Jammer maar zo werkt de IT markt in Nederland, de PM-ers verdwijnen, en de incompetente directeurtjes blijven zitten….