Waarom wordt de projectmanager de zondebok als projecten falen?
Wanneer een project vastloopt, ontstaat al snel de behoefte om een schuldige aan te wijzen. De opdrachtgever vindt dat de projectmanager eerder had moeten escaleren. De projectmanager wijst op ontbrekende besluiten, onvoldoende capaciteit of een leverancier die afspraken niet nakomt. Het management wil vooral weten wie verantwoordelijk is en hoe het project weer op de rails komt.
Tijdens de afgelopen kennissessie ging het over waarom projecten falen, 4 voorbeelden waar de projectmanager de schuld kreeg en wat jij kan doen als projectmanager om succesvol projecten af te ronden.
Projectfalen is meestal een gedeeld probleem
De projectmanager is het zichtbare middelpunt van een project. Daardoor lijkt het logisch om deze persoon aan te spreken als resultaten uitblijven. Maar zichtbaarheid is niet hetzelfde als volledige verantwoordelijkheid.
David Whitemyer beschrijft in het artikel 'The Blame Game' 29 veelgenoemde oorzaken van projectfalen. Slechts 7 daarvan vallen uitsluitend binnen het domein van de projectmanager. De overige 76% ligt voornamelijk bij de bredere organisatie en het management.
Dat ontslaat de projectmanager niet van verantwoordelijkheid. Een goede projectmanager moet signalen herkennen, realistisch plannen, de samenhang bewaken, afspraken vastleggen en tijdig escaleren. Maar zelfs een sterke projectmanager kan niet zelfstandig compenseren voor een afwezige sponsor, structureel trage besluitvorming of een leverancier die niet levert.
Case 1: De ongeschreven regels van governance
In een datacentercentralisatieproject rapporteerde de projectmanager aan een vp, die op diens beurt rapporteerde aan de directie. Toen de directie per e-mail vragen stelde over het project aan de vp, werd de projectmanager meegenomen in de cc.
De projectmanager wilde snel en transparant handelen en gaf rechtstreeks antwoord aan de directie. Inhoudelijk leek dat logisch. Organisatorisch pakte het anders uit. De vicepresident voelde zich gepasseerd en uiteindelijk werd de projectmanager ontslagen.
De les: ken ook de informele governance
Governance gaat niet alleen over functies en verantwoordelijkheden. Het gaat ook over informatiestromen, mandaten, escalatielijnen en ongeschreven regels.
In deze case was het antwoord van de projectmanager inhoudelijk niet noodzakelijk verkeerd. Het probleem was dat onvoldoende rekening werd gehouden met de politieke en culturele betekenis van de rapportagelijn. In de ene organisatie wordt rechtstreeks contact met de directie gewaardeerd, terwijl dit in een andere organisatie wordt gezien als het passeren van de leidinggevende.
Een RACI-matrix helpt om verantwoordelijkheden vast te leggen, maar is niet voldoende. Bespreek bij de start ook expliciet:
wie met directie en bestuur communiceert;
welke antwoorden vooraf met de sponsor worden afgestemd;
wanneer de projectmanager rechtstreeks mag reageren;
via welke route escalaties verlopen.
Voor projectmanagers betekent organisatiesensitiviteit dat ze begrijpen hoe ze problemen effectief binnen de organisatie bespreekbaar maken.
Case 2: De planning die (nog) niet gemaakt kon worden
Bij een groot telecom bedrijf werd een externe projectmanager ingehuurd voor de selectie van een ERP-systeem. Na het selectietraject koos de organisatie voor een andere oplossing dan geadviseerd door het projectteam. Vervolgens werd dezelfde projectmanager gevraagd om de implementatie te leiden.
Terwijl de ERP-leverancier nog bezig was met de opstart, vroeg de sponsor van de klant om een gedetailleerde weekplanning. Daarin moest precies staan wanneer medewerkers uit de operatie nodig waren. De projectmanager kon deze planning nog niet betrouwbaar opleveren, omdat daarvoor informatie van de leverancier nodig was.
Toen de gevraagde planning uitbleef, werd de projectmanager ontslagen en vervangen door een seniorere collega. Tegen de tijd dat deze opvolger begon, was de leverancier wel opgestart. De nieuwe projectmanager kon de planning daardoor snel opleveren.
De les: manage verwachtingen over rollen en verantwoordelijkheden
Een projectmanager wordt geacht een integrale planning te maken. Hierin wordt de planning van de leverancier, inzet van medewerkers uit de operatie, besluitvorming, testen etcetera samengebracht. Een van de inputs is de planning van de leverancier en welke resources nodig zijn.
Maak aan het begin duidelijk aan de klant wat jij nodig hebt als projectmanager om je werk goed te kunnen doen. Hierdoor zijn verwachtingen duidelijk en haalbaar. Wat nodig is kan per project veel verschillen waardoor eerder makkelijke deliverables opeens meer tijd en moeite kosten, zonder dat de klant dit doorheeft.
Deze case laat ook zien dat timing belangrijk is. De opvolger deed niet per se iets beter of anders, maar kon wel door vanwege betere timing. Soms zit het mee en soms zit het tegen, maar met goede verwachtingsmanagement kan je wel je functie behouden.
Case 3: Één organisatie, twee culturen
Na het samengaan van twee grote IT en netwerk leveranciers, moesten medewerkers met verschillende werkstijlen binnen één project samenwerken. Beide bedrijven leverden vergelijkbare diensten, maar de cultuurverschillen waren groot. De ene groep waren denkers, de andere doeners.
Tijdens het project bleken verkochte functionaliteiten wel afzonderlijk binnen de bedrijven aanwezig te zijn, maar nog niet gezamenlijk in één softwarepakket. Ook vertraagden cultuurverschillen diverse deliverables, waardoor het project niet lekker liep.
De projectmanager escaleerde en een een belangrijk besluit was nodig. Deze moest gemaakt worden door een bevoegde directeur. Eerst werd er een week overnagedacht en daarna is de directeur op vakantie gegaan zonder antwoord te geven. Het project bleef drie weken hangen in onzekerheid. Uiteindelijk werd de projectmanager ontslagen omdat er uitloop was op de planning.
De les: cultuur is een operationeel risico
Cultuur wordt in projecten soms gezien als een zacht onderwerp. Deze case laat zien dat cultuurverschillen directe gevolgen hebben voor besluitvorming, kwaliteit, samenwerking en doorlooptijd.
Een tegenstelling tussen “doeners” en “denkers” hoeft niet verkeerd te zijn. Beide perspectieven kunnen elkaar versterken. Het wordt een probleem als niet duidelijk is:
hoeveel analyse nodig is voordat een besluit wordt genomen
wat een toezegging precies betekent
wanneer iets af is
wie bij afwezigheid een besluit mag nemen
In deze case kwam daar een governanceprobleem bij. Een kritisch besluit was afhankelijk van één directeur en er was geen werkende vervangingsroute.
Bij fusies en samenwerkingen is daarom naast een stakeholderanalyse ook een korte cultuurscan nodig. Leg bovendien voor kritieke besluiten een maximale beslistermijn en een vervanger vast. Een project mag niet stilvallen omdat één besluitvormer op vakantie is.
Case 4: De leverancier die bleef beloven zonder te leveren
Bij een sociale zorginstelling werd een selectietraject uitgevoerd vanwege ontevredenheid over de bestaande ICT-leverancier. Ook de huidige leverancier mocht deelnemen. Hoewel het advies uitkwam op een andere partij, koos de organisatie vanwege de lagere prijs opnieuw voor de bestaande leverancier.
In een volgend project moest de citrix omgeving worden vervangen door een cloudoplossing en laptops voor medewerkers. De leverancier beheerde de citrix omgeving en had ook zelf een alternatief systeem als oplossing waarbij vanuit the cloud gewerkt kon worden. De leverancier deed herhaaldelijk toezeggingen, maar kwam deze niet na. Het project werd uiteindelijk afgerond met ongeveer een halfjaar vertraging.
De les: vertaal beloftes naar toetsbare resultaten
De organisatie wist dat er problemen waren met de leverancier, maar liet de prijs uiteindelijk de doorslag geven. Daarmee werd feitelijk een bekend uitvoeringsrisico geaccepteerd. Als dat risico zich vervolgens voordoet, kan de verantwoordelijkheid niet uitsluitend bij de projectmanager worden gelegd.
Commerciële toezeggingen moeten worden vertaald naar concrete projectafspraken. Iedere belangrijke deliverable heeft minstens het volgende nodig:
een eigenaar;
een afgesproken datum;
een heldere definitie van gereed;
een acceptatietest of bewijsstuk;
een escalatiemoment bij afwijking.
“De cloudomgeving is in juni gereed” is bijvoorbeeld te vaag. Gereed voor technisch testen, gereed voor gebruikersacceptatie en gereed voor productie zijn verschillende mijlpalen.
De projectmanager kan een slechte leveranciersprestatie niet altijd voorkomen. Wel moet deze tijdig zichtbaar maken wat de afwijking is, wat de gevolgen zijn en welke managementbeslissing nodig is.
Waarom een nieuwe projectmanager soms toch helpt
Het vervangen van een projectmanager kan organisatorisch aantrekkelijk zijn. Het geeft een zichtbaar signaal dat er wordt ingegrepen. Een nieuwe projectmanager krijgt bovendien vaak ruimte om eerdere keuzes ter discussie te stellen, de scope te herijken of nieuwe afspraken te maken. Bij beursgenoteerde bedrijven geeft het aantellen van een nieuuwe CEO in slechte tijden koerswinst, terwijl dit uitstellen of een interim aanstellen verlies opleverd (Gangloff & Connelly, 2015)
Dat betekent echter niet automatisch dat de vorige projectmanager de oorzaak van het probleem was. De Blame Game Theory van Roulet en Pichler beschrijft hoe organisaties en individuen na problemen proberen verantwoordelijkheid te verschuiven. Wanneer onduidelijk is wat er precies fout ging en wie waarvoor verantwoordelijk was, ontstaat ruimte voor scapegoating. Het is dan soms als organisatie fijn om alles op één persoon af te schuiven en die te ontslaan. Meestal is daarmee alleen niet het probleem ook opgelost.
Voorkomen is beter dan achteraf verklaren
Na een lastig project wordt vaak een post-mortem uitgevoerd. Minstens zo waardevol is een pre-mortem. Daarbij stelt het team zich voor de start voor dat het project volledig is mislukt en beantwoordt iedereen de vraag:
“Het is een jaar later en dit project is mislukt. Waardoor is dat gekomen?”
De antwoorden worden vertaald naar risico’s, beheersmaatregelen, eigenaren en vroege waarschuwingssignalen.
De vier cases leveren direct bruikbare aandachtspunten op:
Leg communicatie- en escalatielijnen expliciet vast
Maak planningsaannames en onzekerheden zichtbaar
Behandel cultuurverschillen als een echt projectrisico
Organiseer vervanging voor cruciale besluitvormers
Vertaal leveranciersbeloftes naar meetbare acceptatiecriteria
Leg besluiten, afwijkingen en escalaties schriftelijk vast
Jezelf beschermen als projectmanager betekent niet dat je een dossier tegen anderen opbouwt. Het betekent dat er een gedeeld en controleerbaar beeld bestaat van verwachtingen, risico’s, besluiten en verantwoordelijkheden.
Tot slot
Projectmanagers maken fouten. Soms schieten leiderschap, planning, rapportage of stakeholdermanagement daadwerkelijk tekort. Dan is correctie nodig en kan vervanging gerechtvaardigd zijn.
Maar de vier cases laten zien dat projectfalen meestal ontstaat op het snijvlak van individu en organisatie: onduidelijke governance, onrealistische verwachtingen, botsende culturen, trage besluitvorming of onvoldoende leverancierssturing.
De volwassen reactie op projectfalen is daarom niet om onmiddellijk een schuldige aan te wijzen. Onderzoek eerst welk gedrag, welke besluiten en welke systeemcondities aan het probleem hebben bijgedragen.
Want soms is de projectmanager onderdeel van het probleem. Maar als sponsorschap, mandaat en besluitvorming niet op orde zijn, kan zelfs de beste projectmanager het project niet alleen redden.