De eisen die tegenwoordig aan een projectmanager gesteld worden zijn niet meer beperkt tot zijn opleiding en werkervaring. Tegenwoordig zien we vaak dat de klant kennis van zijn sector ook als eis stelt! Waarom stelt de opdrachtgever deze kennis en ervaring als een eis? ? Is het hebben van sectorkennis altijd een voordeel voor de klant?
Parallel aan deze ontwikkeling verwachten de leveranciers ook dat hun projectmanagers iedere klant of ieder project moeten kunnen bedienen. Moet een projectmanager hierdoor een kameleon zijn om overal inzetbaar te kunnen zijn?
Projectmanagement is een vak. Uit een onderzoek op LinkedIn bleek dat projectmanagers minimaal drie expertises in hun bagage moeten hebben:
1. Een projectmanager moet verstand hebben van zaken zoals planning, cpm, resourcemanagement, wbs (Work breakdown structure), eva (earned value analysis), risicomanagement, coaching & soft skills etc cetera.
2. Projectmanagers moeten kennis hebben over de inhoud van het projectresultaat. Weliswaar is de algemene mening dat die kennis niet erg gedetailleerd hoeft te zijn, maar je moet voldoende inzicht hebben om opdrachtgevers en (inhoudelijke) teamleden te kunnen begrijpen en te weten waar de relevantie van het project ligt.
3. Zonder technische kennis is het moeilijk om goede beslissingen te nemen.
De klant dient bewust te zijn van hoe hij zijn eisen over deze drie schalen verspreidt om tot de juiste match te komen voor een projectmanager die van zijn opdracht en project een succes kan maken.
Klant 2.0
De business en hieraan gerelateerde processen zijn vandaag de dag anders en ingewikkelder dan tien jaar geleden. Tegelijkertijd is de verwevenheid van ict als hulpmiddel in business(processen) flink toegenomen. Dit zorgt voor een complexiteit die lijkt opgelost te kunnen worden als de projectmanager kennis van de klantsector heeft.
Het komt vaak voor dat de klant of de leverancier bij de aanvang van het project een onvolledig beeld heeft van wat er in het project gebeuren gaat, randvoorwaarden, risico`s, impact op aan het project gerelateerde zaken et cetera. Deze negatieve ontwikkeling zal zijn effecten op de drie bekende onderwerpen (tijd, geld, kwaliteit) zichtbaar maken en zorgen voor vervelende discussies. De klant zal zich begrepen voelen als de projectmanager in deze discussie dezelfde taal spreekt. Juist door dit gevoel kunnen veel problemen tijdens de uitvoering in een goede 'samenwerking' opgelost worden. Er ontstaat een synergie tussen klant en leverancier die beide partijen kan helpen om projectactiviteiten gestroomlijnd uit te voeren.
Sectorkennis als eis stellen kan ook nadelig zijn. Dit nadeel doet zich voor wanneer een projectmanager die genoeg ervaring en kennis met de realisatie van de projectresultaten heeft, gediskwalificeerd wordt omdat hij geen sectorkennis heeft. Beste klant, bent u zich hiervan bewust?
Betere wereld begint bij jezelf!
De resultaten van een haalbaarheidsonderzoek in fase-0, wat een onderdeel uitmaakt van de business case, kunnen veel (verborgen)zaken voor de klant zichtbaar maken. Met deze kennis kan de klant zelf voorbereidingen treffen en een roadmap voor het project opstellen. Dit is bewustwording! Deze informatie en aanpak kunnen de klant helpen bij het opstellen van een rfi (request for information), beoordelen van leveranciers en de overige zaken in de offertefase. Veel discussies en tegenslagen tijdens het project kunnen hierdoor vooraf uitgesloten worden.
Wanneer de opdracht uitgekristalliseerd i,s dan kan een projectmanager met voldoende kennis van het project en minder kennis van de klantsector, van het project ook een succes maken. Door een goed voorbereid project kan de leverancier van tevoren zien of hij de doelstellingen van het project kan laten slagen, iets wat ten goede komt aan beide partijen. Hierdoor heeft de opdrachtgever ook meer keuzes voor wat betreft de leveranciers (en de projectmanagers).
Conclusie
Een proactieve houding en betrokkenheid van de klant, kan de behoefte aan sectorkennis verminderen, de kans op succesvolle afronding verhogen en brede leverancierskeuzes opleveren.
De klant kan door een goede voorbereiding met een deugdelijke business case, zelf in belangrijke mate het succes van een project bepalen. Hierdoor wordt het makkelijker om de juiste keuze voor een projectmanager te maken
Wat blijft is dat een projectmanager zich moet kunnen inleven in de klant(situatie), hij moet soms meer doen dan het `gewone'. Zaken zoals tussentijdse audits en collegiale toetsing kunnen bijdragen aan synergie zonder dat hij sectorkennis heeft. Hij moet zoveel ervaring en inhoudelijke bagage hebben, dat hij in korte tijd en zelfs zonder sectorkennis op het niveau kan komen dat hij begrijpt waar het over gaat.
Zowel de klant als projectmanager wil samenwerken, maar in de praktijk wordt dat nog te weinig tot tevredenheid ingevuld. Er ligt nog een uitdaging. Beide partijen hebben een belangrijke rol in het succesvol uitvoeren en afronden van het project.
Reza,
Je hebt het over een weegschaal met 3 schalen maar ik herken er uiteindelijk maar twee. Eerste genoemde punt gaat namelijk over processen, tweede over de inhoud en derde is daar een herhaling van. Als dit een juiste conclusie is zijn er dus, afhankelijk van gewicht in de schalen dus 2 typen: procesmanagers en projectleiders.
Ewout,
Het eerste heeft te maken met kennis en kunde op het gebied van projectmanagement, tweede heeft te maken met kennis van de klant, haar business en behoefte om vervolgens zich in de projectresultaten in te kunnen leven (communicatie met verschillende rollen aan de kant van klantorganisatie)(let wel op: het projectresultaten van de klant kunnen anders zijn dan die van het project en PM) en derde (technische)kennis van wat er gaat gebeuren om de taal van techneuten te kunnen begrijpen (voor communicatie en interactie, besluitvorming etc op het gebied van techniek)
Deze zijn 3 verschillende punten.
Het artikel gaat om het tweede punt! De vraag is of je als PM deze kennis echt moet hebben en zo ja tot hoeverre? En wat gebeurt er als je dat niet hebt maar toch heel goed weet wat er binnen het project gerealiseerd moet worden! Wordt je door de klant afgewezen?
@ Reza, Ewout
de drie punten hangen erg af van het type project, gaat het om 15 krentenbollen in een dozijn dan is dat zeker niet nodig, is het drastisch minder dan 12 dan zeker wel, of te wel is het een renovatie of een innovatieproject, is het vernieuwend, bijzonder, weinig voorkomend ja en anders, is het meestal een commodity project en dan dus weer niet zo is de (mijn) praktijkervaring….
Reza,
Een projectmanager hoeft niet zelf de technische kennis te hebben, het ontbreken kan zelfs een plus zijn. Dit om te voorkomen dat een projectmanager zich gaat verliezen in de details en een tegenwerkend voorman wordt. Dit geldt ook voor alle interne en informele processen waardoor projectmanagement meer gaat lijken op een normale lijnafdeling en het project nooit afkomt. Het is niet voor niets dat gezegd wordt dat vreemde ogen dwingen.
@redactie: kunnen jullie er iets aan doen dat je niet je reactie kwijt bent als de pagina ververst? Net bezig met een uitgebreide reactie, en “floep”, alles weg.
Zeer vervelend!
@Maarten,
Ik ben het met je eens dat het type project effect heeft op deze drie punten. Ik ben ook van mening dat als de PM genoeg ervaring heeft met PM zaken (punt 1) en capabel is om zich in de situatie van klant in te leven (punt 2) dan hoeft hij de juiste technische adviseur naast zich te hebben om dit project dicht bij het succes te kunnen brengen. Maar de vraag is waarom legt de klant soms meer gewicht op punt 2?
@Ewout:
Het is waar wat je zegt. Deze drie punten komen uit dat onderzoek. Met punt 3 werd er opgemerkt, dat het handig is als PM wel technische “ kennis” heeft, maar dat hij niet hoeft te beschikken over technische “ vaardigheid”, op duidelijke voorwaarde dat hij als manager volwassen genoeg is om tijdig afstand te nemen en de oplossingen overlaat aan de specialisten.
@PaVaKe
Herkenbaar, ik heb dit al vaak meegemaakt 🙁 Daarom schrijf ik gerust mijn reactie in Word om dit vervolgens op de site te zetten. Ik hoop dat je ondanks dit, het nog een keer gaat proberen.
“klant 2.0″ … een heel interessante!
Want wat dien je nu als projectmanager (pm) nu te managen, je project of je klant?
Natuurlijk mogen er vragen gesteld worden over het technisch ontwerp of de implementatiestrategie. Er zijn voldoende klanten met kennis van zaken, die op dat gebied zinnige vragen kunnen stellen.
Maar dienen deze vragen niet gesteld te worden bij het reviewen van het technisch ontwerp? Hierbij heeft de klant overigens nog een andere rol: zorgen dat de juiste personen afgevaardigd worden naar dit soort technisch inhoudelijke discussies.
Als pm dien je mijns inziens duidelijk je communicatieplan af te bakenen. Als projectmanager communiceer ik met de klant/stuurgroep of wat dan ook over de voortgang van het project, eventuele risico’s, budget et cetera.
Wil de klant graag inhoudelijk betrokken zijn bij een aantal discussies, bijv. het technisch ontwerp, dan worden daar aparte afspraken voor gemaakt.
Overigens is dit ook vaak een kwestie van vertrouwen. Zeker bij projecten die je door een derde partij uit laat voeren, zal het wederzijds vertrouwen gewonnen moeten worden alvorens men uitspraken van elkaar aanneemt.
Voor interne projecten kan dit op een andere manier een dilemma zijn. Als je als pm een project moet verantwoorden waarbij architect X het ontwerp heeft gedaan, en de organisatie heeft zo haar bedenkingen bij de capaciteiten van architect X, dan kom je als pm in een zeer vervelend wespennest, wat eigenlijk niets meer met projectmanagement van doen heeft.
Dit brengt me bij een andere belangrijke factor, welke in het artikel niet genoemd wordt:”project-team 2.0”.
Je aanvaardt op een gegeven moment een opdracht, en dan moet je in de organisatie gaan winkelen voor de juiste proffesionals die invulling gaan geven aan de opdracht. Afhankelijk van wat er al in huis is komen daar nog eventueel ingehuurde krachten bij.
En dan komt de grote uitdaging. Immers, als pm ben je de spreekbuis namens dit team naar de opdrachtgever toe. Die ervaren teamleider die je in je team hebt, blijkt toch structureel te krap te plannen. Wie mag het gaan vertellen bij de opdrachtgever… inderdaad, de pm. Dus maar weer extra controleslagen inbouwen, je verdiepen in de materie om het werk van de teamleider juist op waarde te kunnen schatten enz.
Vervolgens komt de volgende uitdaging. Het ontwerp waarvan de architect je verzekerd had dat het de perfecte oplossing zou zijn blijkt bij de eerste set compleet te falen. Hè, vervelend; blijkt de architect toch iets minder netwerkkennis te hebben dat dat zijn businessmanager je deed geloven.
Mag je weer naar je opdrachtgever een vertraging aankondigen.
Op het moment dat dit je een paar keer overkomt, dan ga je ineens heel aanders aankijken tegen het al dan niet hebben van domein- en of technische kennis als projectmanager.
Ik heb het meegemaakt, dat de projectmanager (uit één van zijn vorige banen) meer kennis had van systeem- en netwerkontwerp dan de duurbetaalde consultant die de organisatie voor hem geregeld had. Je kunt dan wel stellen dat de pm zich niet met de techniek of inhoud moet bemoeien, maar als hij dat niet doet, en zijn eigen project daardoor de mist in ziet gaan, dan zal de gemiddelde pm toch eieren voor zijn geld kiezen en zijn kennis inbrengen.
Dit in acht nemende, is het misschien helemaal niet zo vreemd dat een klant eist dat de projectmanager vandaag de dag domeinkennis heeft. Ook opdrachtgevers zijn door schade en schande wijs geworden, en aan een projectmanager die alleen maar herhaalt wat z’n projectleden zeggen heb je als klant niet veel.
Iemand zal dit op waarde moeten kunnen schatten, en als je team niet net zo proffesioneel is als je projectmanager, dan ontkom je daar als pm denk ik ook niet aan.
De projectmanager 2.0 is meer een specialist aan het worden, daar waar 1.0 een generalist was.
Het is wat dat betreft soms net voetbal: als er veel verloren wordt, moet de trainer/coach het veld ruimen, niet de spelers.
Momenteel is het natuurlijk zo dat er een behoorlijke onbalans is tussen aanbod (hoog) van PL/PM en vraag (laag). Om het aantal reacties op een aanvraag enigszins in de perken te houden is het opschroeven van het aantal eisen zoals branchekennis en reisafstand opeens relevant.
Branchekennis heeft ontegenzeggelijk veel voordelen die over het algemeen behoorlijk evident zijn.
Ter voorkoming van tunnelvisie is vers bloed op zijn tijd ook wel een verfrissend.
@PaVaKe:
Gelet op de omvang van je reactie kan ik me best voorstellen dat je het zeer vervelend vond toen je reactie gisterenavond wegvloog 🙂 Dank voor je reactie.
Ik ben er zelf een voorstander van dat PM technische kennis moet hebben (dat hoeft zeker niet tot de laatste puntjes te zijn, daar heb je andere mensen voor). Ik hoef dat niet verder te beredeneren dat heb je hierboven uitgebreid, duidelijk en mooi gedaan. Toch wordt dit door veel mensen en organisaties tegen gehouden: je moet je als PM alleen met PM zaken bezig houden! Tja, als het project in problemen komt wie wordt eruit gestuurd? Ja projectmanager en niet het team zoals je zei!
@Kurt
Jij ook bedankt voor je reactie.
Het is wel waar dat er enorme onbalans is tussen vraag en aanbod. Maar is dit terecht en vooral wijs dat ik als opdrachtgever, kennis van mijn branche als filter ga mis/ge –bruiken om de CV-lawine te voorkomen?
Kennis van branche hebben is zeer handig. Maar veel gewicht op deze schaal leggen zal andere schalen (PM kennis en kennis van de uitvoering) uit balans halen, vind ik. Iets wat de opdrachtgever ook geen voordeel aan heeft.
@paveke en @reza
Er zijn ook PM-ers die eruit gaan omdat ze te lief zijn, de kool en de geit steeds proberen te sparen. Ik had het in mijn eerste reactie over leiders waarmee ik bedoel dat er ook nog wat te zeggen valt voor een vergeten discipline zoals leiding geven. Het lijkt wel of dat steeds minder gedaan wordt en ieder risico gemeden wordt.