Mag je als projectmanager over je mandaat heen gaan?

In projecten spreken opdrachtgever en projectmanager vaak af wat het projectbudget is, hoe lang het mag duren, welke producten opgeleverd moeten worden, de kwaliteit ervan, enzovoorts. Mag je dan als projectmanager over je mandaat heen gaan?

Voorstanders

Ja! zeggen de voorstanders. Zij vinden dat de projectmanager niet zo maar moet doen wat er gevraagd wordt, maar de ruimte moet pakken om ondernemend te zijn. Je moet snel kunnen handelen om de concurrentie voor te blijven en de klant voor je te winnen. Bovendien zijn opdrachtgevers altijd druk. En de decision latency die daaruit komt, is een belangrijke factor bij mislukkingen van projecten volgens de Standish Group. Bovendien hebben opdrachtgevers geen tijd om je hand vast te houden in elke stap. Het motto vertaalt vanuit het Engels: het is makkelijker om vergiffenis te vragen dan om toestemming.

Tegenstanders

Nee! zeggen de tegenstanders. Waarom zou je anders afspraken maken als je je er toch niet aan gaat houden? Stel dat je je huis laat verbouwen en de aannemer houdt zich niet aan de afspraken, bijvoorbeeld door een goedkopere tegel te gebruiken in een duidelijk andere stijl. Dat bespaart kosten, maar verandert daarmee ook de hele uitstraling van je nieuwe interieur. Ben je daar dan blij mee als je niet geraadpleegd bent hierover als opdrachtgever? Wat als je dit zorgvuldig hebt laten uitzoeken door een binnenhuisarchitect?

Managementgrip versus autonomie en snelheid

Voor- en tegenstanders dus. Het is niet zonder meer te zeggen wat het juiste standpunt is. Zoals een goed consultant doorgaans zegt: ‘dat ligt eraan’. Het gaat om keuzes met betrekking tot grip voor de opdrachtgever en diens verantwoordelijkheden voor de bijdrage van het project aan de strategische doelstellingen enerzijds en anderzijds de autonomie van de projectmanager en daarmee de snelheid waarmee deze met het team kan inspelen op veranderingen.

Doe het project zoals ik het zou doen

Als een opdrachtgever je vraagt om ondernemend te zijn en het project te managen zoals hij/zij dat zelf zou doen, dan is dat mooi verwoord en motiverend, toch? Tegelijkertijd roept het ook vragen op. Het is wat makkelijker om het project te managen op die manier als de projectmanager de betreffende opdrachtgever ook zo goed kent. En soms is dat het geval. Echter, wat als je je opdrachtgever net leert kennen en nog niet goed weet hoe deze ‘in de wedstrijd zit’?

Duidelijkheid in alle gevallen

Dus dan stel je precies dezelfde vragen aan de opdrachtgever over het project die je altijd stelt: wat vind je belangrijk? Wat moeten we bereiken? Hoe draagt dit bij aan de organisatie? En wat mag het kosten? Wanneer heb je het nodig? Wanneer is het goed genoeg? Onderdeel hiervan is de vraag wanneer mag ik gedurende het project een risico nemen, zoals een gokje wagen, zonder eerst akkoord te vragen? Dat kun je zien als de risicotolerantie. Om zeker te zijn dat je dit goed begrijpt, probeer je dit SMART te maken. En daarmee kom je dan toch op iets uit dat onder meer de richting maar ook de grenzen aan je opdracht helder maakt. Bovendien kun je met elkaar een noodprocedure afspreken als een snelle beslissing nodig is. Streef dus duidelijkheid na in alle gevallen. En als je die duidelijkheid hebt en de afspraken zo zorgvuldig hebt gemaakt, is er dan een reden om deze grenzen zonder overleg te overschrijden?

Hoe zien we elkaar en de omgeving?

De best passende werkwijze komt uiteindelijk voort uit de mindset: hoe kijken we in deze organisatie naar onze omgeving en elkaar?

Als opdrachtgever heb je kennis van het grotere plaatje, waarover de projectmanager doorgaans niet beschikt. Je weet bijvoorbeeld beter hoe de business – waarin de organisatie actief is – in elkaar steekt. Als de projectmanager je betrekt bij een probleem dat niet binnen de toleranties kan worden opgelost, dan kun je die kennis inbrengen en in een dialoog tot een goed en doordacht besluit komen.

Als de opdrachtgever de overtuiging heeft dat de projectmanager de situatie niet zo goed kan overzien als hij-/zijzelf dan zal de opdrachtgever grote beslissingen zelf willen nemen. Dat zal ook eerder gelden voor een omgeving die stabiel is en dus weinig of langzaam verandert. Het gevolg van deze insteek kan zijn dat de opdrachtgever teveel naar zich toe trekt. Daarmee kan deze een ‘bottle neck’ oftewel een vertragende factor worden voor het project. En dat kan weer een nadelig effect hebben voor het succes van het project.

Dynamisch

Indien de opdrachtgever de perceptie heeft dat de projectmanager de situatie prima kan overzien, zal de opdrachtgever eerder geneigd zijn om vrijheden toe te staan. De noodzaak hiertoe is ook groter wanneer de omgeving van het project meer dynamisch is. De opdrachtgever en projectmanager kunnen afspreken dat de projectmanager onvoorziene, noodzakelijke besluiten zelf neemt. Achteraf meldt de projectmanager de besluiten en de impact ervan. Waar nodig kunnen zij dan samen de beslissingen evalueren en er van leren.

Wanneer de opdrachtgever wil dat de projectmanager voortdurend oog houdt voor kansen en deze pakt wanneer ze zich voordoen, moet deze ook bereidt zijn om het leergeld te betalen als het niet goed uitpakt. Mogelijk moet de opdrachtgever dat ook verdedigen naar het hoger management.

Mag je fouten maken?

Tegelijkertijd kan een projectmanager veel en snel leren door zelf fouten te maken. Dan kom je uit op de vraag: mag je fouten maken in de organisatie? En hoe reageren de klanten van de organisatie hierop?

Anton Zandhuis, zeer gewaardeerd PMI-trainer zegt: is iets wel echt een fout? Een fout is als je weet hoe het moet en het anders doet. Als je nog niet weet hoe het moet, kun je alleen maar leren en dus ook weinig fout doen. De vraag is dan waar mogen, kunnen en moeten we leren omdat we de antwoorden nog niet voldoende kennen en waar kan de organisatie of medewerker zich dat niet permitteren omdat de negatieve consequenties te groot zijn? En waar moeten we risico’s nemen omdat we anders niets leren en dus niet beter worden?

Agile omarmt fouten maken?

Met de komst van Agile is het maken van fouten in een ander licht komen te staan. Tegelijkertijd zijn er ook allerlei mechanismen in Agile om het risico behapbaar te houden: deelproducten worden gemaakt in korte sprints, waarna er snel feedback komt van de gebruikers. En met het concept Minimum Viable Product ontwerp je bewust experimenten om met een minimale inspanning een hypothese te testen. Maar wat als het niet gaat over een Agile project? Wat als het gaat om een project dat niet agile wordt uitgevoerd maar waterval of hybride?

Henny Portman, auteur en toptrainer in o.a. SAFe zegt: het is niet zo dat je fouten móet maken volgens agile. Het heeft nog altijd de voorkeur om het in een keer goed te hebben. De agile mindset is dat je veel mag experimenteren. En daarbij zijn fouten ok, mits je er maar van leert.

Conclusie

Mag je dus over het mandaat heen gaan? Of als je dit anders noemt: over de toleranties of de grenzen van je project? Of je dat mag als projectmanager zonder overleg of een beslissing van de stuurgroep cq opdrachtgever vooraf, is afhankelijk van wat je afspreekt met elkaar. Het is goed om hierover duidelijk te zijn naar elkaar aan het begin van het project. En om de brug te slaan tussen wendbaarheid en grip kun je bijvoorbeeld de gebieden benoemen waarop een gokje wel of juist kan. Dus bijvoorbeeld wel een extra korting aan een klant om deze aan boord van het project te krijgen maar geen gokje met veiligheid van mensen en data. Daarbij kun je ook benoemen over wat de maximale impact hiervan mag zijn, bijvoorbeeld in termen van kosten en/of uitloop van het project. De juiste keuze kan het verschil uitmaken tussen succes en een flop.

Ook aan de slag?

Wil je meer weten een effectieve invulling van de samenwerking tussen projectmanagers en opdrachtgevers in jouw organisatie? Neem contact met ons op.

Contact opnemen

Credits

Voor deze blog een big thank you aan:
Anton Zandhuis 
Henny Portman 

voor hun inspiratie, bijdrage en feedback.