Een veel voorkomend tafereel in de it-branche is een gesprek tussen de projectmanager en zijn leidinggevende na afloop van een niet geheel en al succesvol verlopen project. Onderwerp van gesprek is de reden voor het mislukken van het project. Uitkomst van het gesprek is de afspraak dat de projectmanager zijn vaardigheden gaat bijspijkeren door het volgen van een opfriscursus.
Een eveneens vertrouwd verschijnsel voor veel projectmanagers in de it-branche is de rituele bijeenkomst als de kwartaalcijfers tegenvallen. Tijdens deze ruim met powerpoint slides gelardeerde bijeenkomst komen allerlei ‘nieuwe' technieken en methodieken ter sprake die ons nog beter in staat zullen stellen succesvolle projecten te leiden. Na afloop van zo'n sessie is de professionaliteit van de projectmanager fors verbeterd en is hij nog beter in staat kwaliteit, risico's en mensen te managen. Helaas blijkt de werkelijkheid altijd weerbarstiger…
Het slagen – en vooral mislukken – van ict-projecten mag zich weer in warme belangstelling verheugen. Het recente promotieonderzoek van Aart van Dijk en vooral de enorme stroom van reacties hierop op het forum van Computable laten zien dat dit een onderwerp is dat nogal wat losmaakt.
Eén van de belangrijkste conclusies die Van Dijk n.a.v. onderzoek trekt is dat we, ondanks de overvloed van literatuur over projectmanagement en de opkomst van nieuwere en nog betere methoden, weinig tot niets leren. De faalfactoren uit begin jaren ‘80 (tot zover gaat het onderzoek terug) zijn blijkbaar onuitroeibaar en zorgen nog steeds voor mislukte ict-projecten. Mislukt wil zeggen dat het resultaat – if any – niet voldoet aan hetgeen vooraf is afgesproken, en dat het project de planning en de kosten met meer dan 50 procent overschrijdt.
Zeven faalfactoren
Van Dijk komt op basis van zijn onderzoek tot zeven faalfactoren die het meest voorkomen, zogenaamde Big Hitters. De zeven onuitroeibare factoren zijn:
1. Slecht projectmanagement
2. Onrealistische deadlines
3. Slechte communicatie
4. Onduidelijke vereisten
5. Onvoldoende betrokkenheid van toekomstige gebruikers
6. Gebrek aan betrokkenheid en toewijding van het verantwoordelijke management
7. Gebrek aan deskundigheid – bij uitvoerenden en(project)managers.
Opvallend aan het onderzoek van Van Dijk is de onuitroeibaarheid van de faalfactoren door de jaren heen. Wat Van Dijk verzuimt te doen is de oorzaak van deze onuitroeibare valkuilen en faalfactoren vast te stellen. Hij komt niet verder dan enkele tips aan – met name projectmanagers – hoe faalfactoren en valkuilen te vermijden. En, zoals te verwachten was, zijn deze tips over het algemeen niet meer dan het omgekeerde van de faalfactor. Bijvoorbeeld: neem geen project aan met onrealistische deadlines.
In de onderzoeken van Van Dijk en anderen naar het falen van ict-projecten is een grote rol weggelegd voor de projectmanager. Helaas voor die arme projectmanager is dat geen glansrol: de projectmanager is de grootste boosdoener van allemaal. Hij staat bovenaan de lijst van faalfactoren. Noordam (2007) beticht de projectmanager zelfs van onvolwassenheid.
Is het dan de projectmanager die er de oorzaak van is dat een groot deel van de ict-projecten mislukt? Is hij degene die ervoor heeft gezorgd dat ict-projecten synoniem zijn geworden met budget- en tijdsoverschrijding? Dat lijkt me iets teveel eer. Immers, een projectmanager heeft in een project een zeer bescheiden rol: het echte werk wordt gedaan door de specialisten.
Root of all evil
Als de projectmanager dan niet de root of all evil is, wie of wat is dat dan wel? Ondanks dat de projectmanager onterecht als hoofdschuldige wordt aangewezen, bevat deze valse beschuldiging wel een aanwijzing. Het is de te grote nadruk die op managementaspecten van een project wordt gelegd die leidt tot herhaaldelijke mislukking. In ons vakgebied grossieren we in methoden en technieken om werk gecontroleerd uit te voeren. Methoden en technieken die veeleer vaak een verkoopargument zijn, zonder dat de toegevoegde waarde voor de klant is aangetoond. De klant doet overigens net zo hard mee aan dit circus door steeds vaker om gecertificeerde projectmanagers te vragen. De ict-dienstverleners wapperen dan met de mooiste certificaten en methodieken. Soms is dit Prince2, Six Sigma of een andere de-facto standaard, soms zijn dit ook bedrijfseigen methodieken. Wat al deze methodieken gemeen hebben is een enorme ‘gestructureerde' berg templates, stroomdiagrammen, en toolboxes.
De wildgroei van ‘nieuwe' projectmanagement methodieken is een reactie op de veel geuite klacht dat projecten falen als gevolg van slecht projectmanagement. Op zich een logische reactie, maar heeft deze het gewenste effect gehad? Het antwoord op deze vraag luidt helaas: nee. Tientallen jaren worden er al nieuwe methodieken en toolboxes ontwikkeld, worden bestaande methodes herzien en nog steeds is slecht projectmanagement faalfactor nummer één. De voorlopige, voorzichtige conclusie die we uit deze constatering kunnen trekken is dat niet slecht projectmanagement de hoofdoorzaak is voor het mislukken van project, maar dat het veeleer een teveel aan aandacht voor projectmanagement is dat bijdraagt aan het mislukken van projecten.
Opvallend in de meeste onderzoeken is de aanname dat er überhaupt een verschijnsel is – projectmanagement – dat in zijn eentje verantwoordelijk is voor het falen van projecten. De term projectmanagement is echter een simplificatie van een groot aantal subfactoren die elk afzonderlijk verantwoordelijk kunnen zijn voor het mislukken van een project. Deze factoren zijn over het algemeen niet de unieke verantwoordelijkheid van de projectmanager, er zijn veel meer rollen betrokken bij het beheersen van deze factoren.
Tien klassieke fouten
Ryan Nelson komt in zijn artikel over beroemde mislukkingen tot een veel gedetailleerder opsommingen van faalfactoren. Hij beperkt zich niet tot de algemene constatering over falend projectmanagement, maar komt tot een veel specifieker uitwerking. Zijn top tien van Classic Mistakes ziet er dan ook heel anders uit dan bij andere onderzoekers:
1. Slechte inschatting
2. Onvoldoende betrekken van belanghebbenden
3. Onvoldoende risico management
4. Slechte planning
5. Onvoldoende kwaliteitsbeheersing
6. Gebrek aan deskundigheid in de uitvoering
7. Gebrek aan toewijding van het verantwoordelijke management
8. Slecht vooraf bepalen van de eisen en wensen
9. Onvoldoende aandacht voor interne en externe politieke processen
10. Onvoldoende betrokkenheid van eindgebruikers.
Dit lijstje beschouwend zien we dat de projectmanager wel degelijk een rol van betekenis zou kunnen spelen in enkele van de genoemde faalfactoren. Met name nummers 2, 3, 5 en 9 zijn (gedeeltelijk) de verantwoordelijkheid van de projectmanager. De overige zaken vallen m.i. buiten de invloedssfeer van de projectmanager en zijn bijna allemaal de verantwoordelijkheid van de personen die het project initiëren en sponsoren:
Ad 1. Inschattingen worden gemaakt door technisch specialisten. Als deze niet deskundig zijn (5), dan is een slechte inschatting en daaruit voortvloeiende slechte planning het resultaat
Ad 2.Het betrekken van belanghebbenden is in eerste instantie de taak van de opdrachtgever, die deze tot op zekere hoogte weer kan delegeren naar de projectmanager.
Ad 6. Het is de taak van de opdrachtgever om het project adequaat te bemensen. Als het projectteam slechts bestaat uit mensen die toevallig beschikbaar zijn, dan is het resultaat niet moeilijk te voorspellen.
Ad 8. Het is de taak van de opdrachtgever om pas een project te initiëren en budget beschikbaar te stellen als duidelijk is wat de doelstelling en eisen zijn en wat de verwachte kosten en baten zijn. Is dit niet vooraf gebeurd, dan kan het project alleen maar slagen. Immers, ieder resultaat dat bereikt wordt valt weer mee. Vanuit projectmanagement optiek is het project dan per definitie mislukt.
Ad 10. Het is aan de opdrachtgever om de projectmanager te sturen in het betrekken van de eindgebruikers. De projectmanager voert slechts zijn opdrachten uit. Krijgt hij geen opdracht om een taak uit te voeren, dan wordt er niets uitgevoerd.
Onoplosbaar
Nelson bevestigt mijn eerdere voorzichtige conclusie dat een teveel aan aandacht voor projectmanagement de nummer één oorzaak is voor falende projecten. De misvatting dat beter projectmanagement leidt tot betere projectresultaten leidt de aandacht af van de werkelijke oorzaken van mislukkende projecten. Het misplaatste vertrouwen in projectmanagement als panacee zorgt voor een overvloed aan nieuwe methodieken en instrumenten. De resultaten hiervan zijn niet meer dan dat: nieuwe methodieken en toolboxes en geen zichtbare verbeteringen in het projectresultaat. Bestaande en nieuwe projectmethodieken beloven beheersbaarheid en resultaat. Deze belofte is de afgelopen 30 jaar niet ingelost en zal dat de komende dertig jaar ook niet worden. Terwijl de projectmanager zich verdiept in rode boeken en template na template invult, verzuimt hij aandacht te geven aan de werkelijke faalfactoren en zal zijn project mislukken. Zijn mislukte project leidt tot meer en betere methodes die op hun beurt weer leiden tot mislukte projecten. Ad infinitum…
Paul Jansen, projectmanager ecm Atos Origin
Wanneer de z.g.n. projectmanager dat rode boek eens echt doorleest (de 2009 versie is trouwens niet meer rood), zal hij geen templates meer invullen. Want dat heeft namelijk weinig met project management volgens dat rode boek te maken. Lees de introductie en de principes (2009 versie) er maar eens op na.
Wanneer die zelfde “PM” het stuk over de Business Case bestudeert, zal de conclusie zijn dat IT projecten niet bestaan en dat een project over meer dan alleen “delivery” gaat. En dat het onderzoek van Van Dijk e.a. over sympotomen, niet over oorzaken gaat.
Tenslotte zal een “ICT PM”, zoals van ICT consultancies, na het lezen van het hoofdstuk over organisaties er tot zijn schrik achterkomen dat hij volgens het rode boek helemaal geen PM, maar slechts een technisch teammanager is.
Stil, niets tegen onze klanten zeggen! Dat scheelt in onze omzet! En er zou eens meer kans op succes kunnen zijn in onze projecten!
Methodes werken niet? Misschien wel als ze toegepast en niet door onbegrip of naar verkeerde behoefte en op verkeerde gronden aangepast worden. Want zo ontstaat o.a. PINO.
De projectmanager is altijd onschuldig en deskundig. Alle punten en reacties kunnen in de embryonale fase van project/programmamanagement bekeken worden of er een zekere mate van vermogen/volwassenheid op die punten bereikt zijn. Bij een volledige ‘ja’ dan pas kan je een besluit nemen om met een project/programma te starten.
Het gekke is dat we thuis bij verbouwingen, dure aankopen en/of vakantie (behalve als je avonturier bent)iedereen een controlelijst maakt en e.e.a zorgvuldig voorbereid en keuzes maakt.
In het bedrijfsleven vergeten we dit en laten we ons manipuleren en misleiden met kosten, baten en terugverdien modellen.
Stel nu de punten van mogelijke oorzaak eens als we een business case maken en beoordelen.
Hebben we een goede inschatting gemaakt en hoe weten we zeker dat het klopt?
Zijn de belanghebbenden betrokken?
Is er gekeken naar risico management? Heeft er een risicoworkshop plaatsgevonden? En wat was het resutaat?
Hoe is de planning gemaakt? Klopt deze? Hoe is de onderbouwing?
Hoe gaan we de kwaliteitsverwachting beheersen?
Zijn de kwaliteitscriteria opgesteld en helder voor iedereen?
Hoe staat het met de benodigde en beschikbare competenties voor het project? Zijn ze gereateerd aan de scope met haar activiteiten?
Hoe garandeert het management dat ze toegewijd zijn? Zijn ze geschikt voor hun rol? Kunnen zij de benodigde verantwoording invullen met de daaraan gerelateerde acties?
Wanneer is de klant blij?
Hoe goed kennen we onze omgeving rondom het project?
Hoe hebben we de participatie van de organisatie geregeld?
Zijn de rollen taken, verantwoordelijkheden en bevoegdheden voor iedereen duidelijk?
Kortom, op deze wijze kan ik doorgaan. In ieder geval kunnen de antwoorden op deze vragen en meer……tijdens of als onderdeel van de Business Case beoordeling het mandaat rechtvaardigen.
De geschetste problematiek is dan geen risico meer en kunnen met adequate en preventieve maatregelen zorgen voor beter projectmanagement en resultaten.
Je gaat toch ook niet op vakantie zonder je reiskoffer met reisbescheiden te controleren? Je gaat toch ook niet zonder overleg ineens vanavond langs de verf en behang winkel in om verf en behang kopen?
Elk huishouden zou te klein zijn als de ‘thuis-manager’ dergelijke projecten zou doen. Dit geldt ook financieel. Als de vrouw of zoon/dochter van elke verdiende euro 80 eurocent zou verspillen aan een gokkast?
Op dit moment is geen enkele CEO bewust dat zijn/haar projecten gokkasten zijn waar we 80 euro ingooien om 20 euro aan baten te ontvangen. M.a.w van elke euro investering hebben we een desinvestering van 80%.
doen bespaart veel en zou ons overheidstekort drastisch en snel terugverdienen.
Hoeven we niet langer te werken, hebben we weer pensioen en mogelijk geld over.
In de afgelopen jaren heb ik aardig wat projecten mogen meemaken als specialist.
Er is in mijn ogen een heel duidelijke factor welke zorgt voor slagen van een project: de organisatie.
Ik ken projectmanagers die graag nee zouden zeggen tegen een project, maar na 2 keer nee zeggen krijgen ze de opmerking vanuit hun management dat ze geen risico durven nemen. Gevolg is dat ze geen nee meer durven zeggen uit angst voor hun cariere, en dat ze daarmee ja gaan zeggen tegen projecten met bijv. een onrealistische planning
Ik heb projecten meegemaakt dat halverwege een aantal senior specialisten uit het project getrokken werden, omdat het management een ander project een hogere prioriteit had gegeven. Of de projectmanager even met een creatieve oplossing kom komen om het project alsnog te kunnen realiseren volgens de initiele opdracht
En uiteraard mogen reorganisaties het projectwerk niet beinvloeden. Een complete teststraat die naar het moederbedrijf in een ander land verdwijnt, dat is toch geen probleem? Die mensen daar hebben immers ook de kennis en expertise in huis. In theorie wel, maar de mentaliteit daar was wezenlijk anders; ieder probleem werd meteen gezien als “blocking” en men kon niet meer verder zogenaamd
En wat te denken van een bedrijf dat wereldwijd reorganisaties heeft aangekondigd. Vervolgens werk je in een project dat vanuit 5 plaatsen in Europa gerealiseerd moet worden. Doordat iedere vestiging bang is voor z’n eigen hachje (immers, er moeten vestigingen gesloten worden) ontstond er een heel erge wij-zij cultuur, met wijzen naar elkaar. In plaats van samen de problemen op te lossen, werd er constant naar elkaar gewezen. Vertraging gegarandeerd
En uiteraard hebben we het haantjesgedrag van sommige managers, die “hun” project kostte wat het kost gerealiseerd willen hebben, of het nu haalbaar is of niet. Vervolgens dreig je de projectmanager met ontslag als die het project niet aanneemt, en mislukt het project nu toch, dan geeft je toch gewoon de projectmanager de schuld.
Al heb je nog zo’n goede projectmanager, de beste specialisten in huis etc; als de organiatie je niet de goede omgeving biedt, wordt het heel lastig zo’n project tot een goed einde te brengen
Het genoemde “rode boek” en de verwijzing naar templates leiden voor mij tot de aanname dat de schrijver het had over de (oude versie van) PRINCE2.
Daar was ook mijn eerdere reactie op gebaseerd.
Dit is een heel goed artikel. Er zijn veel analyses van succes- en faalfactoren beschreven, maar zelden poogt men de invloed van de ICT-projectmanager te omschrijven. Soms is die invloed groot, maar vaak ook klein tot heel klein. De meeste ICT-projecten zijn immers bedrijfsprojecten met een ICT component. De ICT-projectmanager is niet de vuilververwerker van het bedrijf die wel even elk vuiltje verwijdert.
Het (meestal achteraf) teveel aandacht schenken aan projectmanagement is inderdaad een veel voorkomende fout. Te weinig commitment bij een stuurgroep of de opdrachtgever (“Gebrek aan toewijding van het verantwoordelijke management”) komt dan ook meestal ook voor. Dat kan ook gezegd worden van het “Slecht vooraf bepalen van de eisen en wensen”, de “Onvoldoende aandacht voor interne en externe politieke processen” en het “Onvoldoende betrekken van belanghebbenden”. Die factoren lijken mij de symptomen van een zelfde euvel.
Ik ken niet de getallen, maar het zou me niet verbazen als er een correlatie is tussen het voorkomen deze faalfactoren.
Natuurlijk zal de projectmanager templates moeten (laten) invullen, maar naast deze formele wijze van communiceren zal men in het bedrijf toch vooral oprecht met elkaar moeten praten, meedenken en samenwerken.
Ten opzicht van het punt “Slechte inschatting” heb ik twee opmerkingen. Ten eerste is het handig als projectmanager met de technisch specialisten te praten over hoe zij tot inschattingen komen. Zeker zo belangrijk is het om als projectmanager samen met de stuurgroep en opdrachtgever te bespreken of de organisatie wel het project in de voorgestelde vorm wel aankan en niet alleen of de businesscase wel goed is, et cetera.
Sommige projecten zijn gewoon te complex, zijn te groot of liggen nog te gevoelig.
Een project verdient het om goed ingebed te worden binnen de organisatie.
Ik ben het eens met wat Paul Jansen schrijft. En zou dit willen toevoegen:
Als je er vanuit gaat dat elk project een verandering betekent, en dan vanuit veranderperspectief kijkt, dan kom je op het klassieke artikel van John Kotter, “Leading Change: Why Transformation Efforts Fail (HBR)”.
Als ik bij een vastgelopen project bijspring of adviseer, blijkt altijd meer dan één van deze faalfactoren aan de orde te zijn, niet zelden allemaal.
Het draait dan ook om leiderschap, leiderschap en nog eens leiderschap. “Terwijl de projectmanager zich verdiept in rode boeken en template na template invult, verzuimt hij aandacht te geven aan de werkelijke faalfactoren en zal zijn project mislukken”.
Waarvan akte. Prince2 gaat over van alles, behalve leiderschap. Probleem en oplossing sluiten dus niet aan. Na tien cursussen projectadministratie: Tien keer nul is nog steeds nul. Dat geldt trouwens niet alleen voor Prince2.
Menigeen met het PRINCEx certificaat geeft toe, het alleen te hebben voor het CV, niet omdat betrokkene vertrouwen heeft in de methode. Zij zien het helemaal niet als onderscheidend instrument voor succes. Men houdt elkaar dus gewoon voor de mal. Geen wonder dat succes uitblijft. Overigens, voor de helderheid, ik vind Prince2 een prachtige methode. Alleen niet één, die vanzelfsprekend aangrijpt op het echte knelpunt.
Totdat men bij het projectleiderschap niet de administratie-certificaten, maar het leiderschap van het project als centrale eis aan de projectleider stelt, verandert er dus niets.
Niet omwille van onze omzet bij Mentaspex, maar een gedegen geschiktheidsonderzoek is echt geen luxe, zelfs niet voor tijdelijk aangetrokken PLs en PMs. Er hangt nogal wat af van dat leiderschap.
@Peter Ambagtsheer, je hebt een open deur ingetrapt (e die van je bedrijf) met de aandacht voor leiderschap. Maar over wiens leiderschap praat je (PD, PM, PL, opdrachtgever, directie, eigennaar, want die hebben verschillende t-b-v’s) en over wat voor een type leiderschap? Je weet ook wel dat de eisen aan het leiderschap van een bijvoorbeeld gevechtsofficier in het veld heel wat anders zijn dan die van een stafofficier op kantoor.
Als jij Prince2, PMI of zo hebt gevolgd, maar niet bezig bent geweest met knelpunten (uit een case of de realiteit), dan heb je een slechte cursus gekozen. Zelfs bij foundation geven ze daar ruime aandacht aan, ook al gaat het dan om de procedures en het begrippenkader.
Dit soort cursussen pretenderen overigens niet om van iemand een leider te maken. De inleidende cursussen zijn ook bedoeld voor projectassistenten en –medewerkers.
En dan nog een tip, test je website. De website komt een beetje vreemd over bij Opera, Firefox en Internet Explorer. ICT is niet jullie vakgebied, maar het is wel jammer.
@John
Het leiderschap moet zeker passen bij de rol (ook een open deur). Bij mijn LinkedIn account vind je er enkele docs over. Bel me anders gewoon even op, of mail mij, wel zo makkelijk. In elk geval bedankt voor je belangstelling, we zijn met tests van de website bezig. Hij is nog niet af. Prioriteiten en zo.
Prettig weekend,
Peter
Een project kent de vier aspecten HET-WIJ-IK-ZIJ. Logischerwijs liggen dan ook de oorzaken van het falen van een project bij deze vier aspecten.
Toch nog een toevoeging aan bovenstaande reacties. In mijn omgeving (six sigma projecten in de industrie) kom ik vooral een faalfactor tegen die ik niet in de genoemde onderzoeken tegen kom: onmacht.
Niet de onmacht vanuit onkunde, maar vanuit het feit dat de omgeving onstabiel is. Productiestoringen, klantenklachten e.d. zorgen er vaak voor dat lopende korte termijn problemen (vaak terecht) voorrang krijgen op structurele procesverbeteringen vanuit het project. Dit komt doordat er daar meestal gewerkt wordt met deeltijd projectmedewerkers die de rest binnen productie werken. Wellicht speelt dat niet binnen IT projecten.