Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

Gezocht: Projectmanager als kameleon

 

Computable Expert

Reza Sarshar
Projectleider/ Adviseur, Kaizen Projectmanagement. Expert van Computable voor de topics Management, Infrastructuur en Digital Workplace.

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.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/4551069). © Jaarbeurs IT Media.

?


Lees meer over


 

Reacties

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.

@Ewout

Graag verwijs ik naar de laatste zin van mijn reactie: als je afgerekend wordt omdat je een slecht team toegewezen krijgt, is het mijden van risico's één van de manieren om te voorkomen dat je project gaat falen.

Reza,

Ja we weten allemaal dat PM een echt vak is. En de ervaring leert ons dat je jezelf echt moet verdiepen in dat vak op theoretisch en praktisch gebied, ook wel ervaring genoemd.
Samen met het ontwikkelen van je gedragscompetenties is dat een leerproces van jaren, waar ook nog eens bijna niet te leren kwaliteiten als sterk leiderschap bij horen. Goed Project management is dus zeker niet voor iedereen weggelegd. Junior Project Manager is in mijn ogen dus een loze kreet. Door de PM in een lerende omgeving te plaatsen, waar ruimte is om ervaring en intervisie op te doen binnen verschillende metiers, bedrijfsculturen en bij bedrijven zoals bijvoorbeeld de luchtvaart waar de winstmarges al 100 jaar tussen 2 en 3 percent schommelen, leer je verschillen in organisaties, hun volwassenheidsgraad en procesbeheersing onderkennen. Allemaal nodig om een echt goede project manager te worden. Maar al te vaak heb ik gezien dat specialisten en/of ingenieurs gebombardeerd worden als projectleider over een project, dat gaat over hun specifieke kennisgebied. Gaat dat vaak goed, bij grote en complexe projecten en programma's. Niet echt. Een goede project/programma manager is eerder een heel goede generalist die wel een brede technische basis heeft. Je kunt haar of hem geen citroenen voor knollen verkopen, maar is vooral in staat om over de eigen schaduw heen te stappen en zo mensen op de juiste manier in beweging krijgt. Pas als je de materie kan loslaten onstaat er tijd en ruimte om drie belangrijke projectsuccesfactoren uit te voeren namelijk: Sturen op het PM proces, sturen op de kwaliteit van de PM producten en specialist producten, het inzetten van alle PM gedragscompetenties die vaak hard nodig zijn in complexe en uitdagende projectomgevingen. Dan pas is het project management vak erg leuk en geeft het je veel voldoening. Soms geef je leiding aan een ICT project en soms vind je het bouwen van een raket aantrekkelijk.

Robert,
Je hebt een aantal punten benoemd die stuk voor stuk terecht zijn, dank voor je reactie.
Het is wel waar dat het ontwikkelen van je gedragscompetenties sterk afhankelijk is van jezelf als mens (niet iedereen is geschikt om PM te worden), coaching en ondersteuning (b.v. van je werkgever) en de kans (opdracht) die je krijgt om dit toe te passen, leren en verder (nieuwe)ervaring op te doen . Ik denk dat met name de kans krijgen om in de praktijk ervaring op te doen is zeer essentieel. Met het afronden van IPMA of Princ2 ben je nog geen projectmanager.

Maar dit is een kant van het verhaal. De andere kant heeft met de klant te maken die kennis van zijn business belangrijk vindt en centraal zet voor het selecteren en gunnen van een project aan iemand. In dit artikel probeerde ik aan te geven dat deze ontwikkeling geen garantie zal bieden voor een succesvolle afronding van het project of tijdig het voorkomen van eventuele problemen. Naar mijn mening een project succesvol afronden is zeker ook afhankelijk van de (proactieve) houding van de opdrachtgever. In de praktijk zien we vaak, Wij/Jullie cultuur en situatie waarin veel zaken in de schoenen van projectmanager of het projectteam geschoven worden. Iets wat de oorzaak is van veel storingen tijdens het project. Moet je dan sectorkennis hebben om dit soort zaken op te kunnen lossen!

Ik vraag ik me af hoe deze ontwikkeling (sectorkennis als eis stellen) ontstaan is!

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×