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.
Hele treffende reacties die ik hierboven lees. Mensen die denken dat een PM iemand is die de verantwoording overneemt van de opdrachtgever, dat de PM bepaalt wat er gaat gebeuren, dat hij/zij de oplossingen bedenkt. Terwijl de baan van PM eigenlijk simpel(?) is: manage het project zijnde het transitieproces door te structureren binnen een projectstructuur met de juiste personen, de juiste stakeholders, door voortdurende gerichte communicatie en beslissingen daar te leggen waar ze horen: bijde opdrachtgever. Simpel toch?
Nu nog even doen en het lef te hebben om opdrachtgever ook de verantwoording laten BLIJVEN dragen……
Als kleine aanvulling lijkt het me ook dat – naast de projectmanager en opdrachtgever – de betreffende ICT-onderneming niet lijkt te leren van eerdere fouten.
Het verbaast me zeer als ik constateer dat er nieuwe offertes gemaakt worden zonder een compleet afgewerkte checklist en het project kan dan de brokken opruimen, exeptions produceren etc.
Artikel dat de andere kant belicht maar dan vanuit beheer gezien:
https://www.computable.nl/artikel/ict_topics/beleid/3287121/2379250/beheer-heeft-goed-opdrachtgeverschap-nodig.html
Is dat proefschrift ergens digitaal te vinden? Ik ben namelijk beneiuwd naar wat daar instaat. Ik kan moeilijk een mening vormen aan de hand van dit korte Computable stukje.
Wat ik mis in dit artikel en alle reacties, is dat de projectmanager zelf maar een zeer beperkte invloed heeft op hoe hij zijn projecten bestuurt. Vaak staat de scope, de datum en het budget al vast en zijn de contractuele randvoorwaarden vastgezet. Daarna mag hij pas aan de slag.
Het is dus niet de projectmanager die het resultaat bepaalt want een belangrijk deel van het succes ligt in de handen van de organisaties zelf: de stuurgroepleden, de contractmanagers en de juristen.
Anko Tijman, een projectmanager bepaalt “scope, de datum en het budget” van de projecten die een (deel)projectleider mag uitvoeren.
Als je die rechten niet hebt, dan moet je de titel projectmanager niet aanmeten en ook niet de verantwoordelijkheid op je nemen.
Als je als (deel)projectleider niet met de GOKIT-factoren kan leven, dan ga je samen met de projectmanager naar een oplossing zoeken. De projectmanager moet er voor zorgen dat het (deel)project kan worden uitgevoerd. Nadat dit geregeld is, kan de deel)projectleider er alsnog voor zorgen dat het project goed uitgevoerd wordt.
Als je gedetacheerd wordt of projectleider van de leverancier bent, dan moet je eerst naar je accountmanager stappen en deze vertellen dat deze namens de opdrachtnemer een probleemopdracht heeft aangenomen. Dan kan daarna met z’n allen naar een redelijke oplossing gezocht worden. Als je accountmanager en diens baas hier niet aan willen meewerken, zoek dan een goede werkgever.
Niemand heeft baat bij het verzwijgen of ontkennen van een probleem en dus bij een valse start van een project.
Fantastisch die reacties. Nagenoeg alle reacties snijden hout. De meeste genoemde punten komen aan bod in het proefschrift. In dit artikel kan de journalist natuurlijk slechts een tipje van de sluier oplichten. Het proefschrift omvat 520 pag.
En natuurlijk zijn er ook veel succesvolle projecten!
Wat ik in de discussie nog mis, is het volgende. De projectmanager (PM) leert vaak wel degelijk “the hard way”, maar deze kennis, verpakt in een boodschap, wil iedereen lang niet iedereen altijd horen. Vaak komt de PM klem te zitten tussen OG en andere belanghebbenden bij het al of niet welslagen van het project en de wijze waarop deze volgens hem/haar tot stand moet komen. De PM wordt heel vaak niet gehoord in zijn boodschap hoe het wel te doen. Dit past niet, kost te veel (geld, tijd), dat resultaat leveren we later met een ander deelproject op, etc.
Neemt niet weg, dat de meeste projecten een evaluatiefase kennen (decharge), dit ook nog gedocumenteerd en ontsloten wordt, maar meestal niet ter kennis wordt genomen bij het opstarten van andere projecten door andere PM’ers. Een gemiste kans!
Project management is slechts nuttig indien het een bepaald doel dient; het doel van een IT project moet altijd zijn om uiterlijk (liever eerder) binnen 8 a 10 maanden (deels) in productie te gaan. De toets van IT projecten is niet het project management, maar het slagen van de applicatie in de praktijk. Overschrijding van de 8 a 10 maanden betekent: stoppen van het project.
Een project wordt gestuurd op meer dan alleen tijd en geld. Er zijn vier stuurelementen: tijd, geld, kwaliteit en scope. Een wijziging in 1 van deze 4 heeft invloed op 1 of alledrie van de overige. In dat spanningsveld moeten PM, opdrachtgever en leverancier blijven acteren. Dat er niet geleerd zou worden, vind ik een vrij baude uitspraak, maar dat het beter kan dan nu in het algemeen bij de uitvoering van projecten daar ben ik het wel mee eens. Projectmanagement wordt meer en meer een echt vak en daarin zie je ook een professionalisering van de PM’s. De lessen worden wel geleerd, maar we zijn er nog (lang?) niet.