Projectmanager John Roos heeft flink wat toe te voegen aan wat er onlangs in Computable verschenen is over zijn vakgebied.
Hij geeft in deze compilatiereactie zowel positieve als negatieve kritiek op drie artikelen over dit onderwerp.
Klantgerichte bedrijfsprocessen (Computable 14/1/05):
De schrijver (Peter Siebbeles) begint zijn artikel met een aantal vragen over klantgerichte bedrijfsprocessen en vraagt zich af hoe dit zit met projectmanagement. Tevens vindt hij dat klantgerichte processen vaak onderbelicht zijn in projectmanagement. Zijn stelling is dan ook dat de projectmanager hieraan aandacht moet geven om zijn slaagkans te vergroten. Deze stelling onderschrijf ik van harte! Het is de ultieme taak van de projectmanager om zijn omgeving te managen. Maar hoe doe je dat? Het is makkelijker gezegd dan gedaan! Mogelijk kunnen de volgende onderwerpen uit de praktijk hierin duidelijkheid geven of helpen.
Ken je ‘stakeholders’ in het project of leer ze zo snel mogelijk kennen en maak een projectorganisatieanalyse en stem je aanpak daar waar mogelijk op af. Iedere stakeholder heeft een eigen recept van voeden, wensen en voorkeuren. Eigenlijk ben je als projectmanager in dit geval een kok die een aantal gevarieerde recepten moet kunnen klaarmaken voor zijn gasten.
Een internationaal programma is vanuit Nederland procesmatig opgestart, maar de binnen- of buitenlandse omgeving (met meer invloed) accepteert alleen de technisch georiënteerde aanpak met snel resultaat halen als gedachte. Als gecertificeerd proces projectmanager (pm) sta je in een dergelijk geval voor een voldongen feit omdat elk “voorbereidend proces, vergadering of stukje papier” als vertragend of niet praktisch wordt gezien. Om in een dergelijke omgeving je slaagkans als pm te vergroten dien je deze omgeving op tijd te herkennen (als je daar de tijd voor krijgt) en je aanpak daarop af te stemmen anders word je slaagkans als pm erg klein.
Let wel op dat je geen risico loopt bij een project audit. Een auditbureau vraagt vaak om een archief en zoekt dan naar een projectbrief, projectorganisatie, plan van aanpak, getekend projectcontract, faseplanning, voortgangsrapportage, issue log, risicolog, change management en configuratieprocessen, et cetera. Het niet kunnen beantwoorden van deze vragen maakt jou dan een gewillig slachtoffer. Iedereen kan zich dan verschuilen onder het motto dat de projectmanager zijn werk niet goed heeft gedaan. Jouw werkgever en opdrachtgever zullen je dan laten vallen als een baksteen om niet verantwoordelijk te willen zijn voor de eindafrekening. Tja…, je zit hier in de mangel en je zal moeten balanceren tussen opdrachtgever/omgeving en je eigen geweten op het gebied van professioneel projectmanagement. Anders slaag je niet!
Doe ook geen aannames dat je stakeholders weten wat je aan het doen bent in je project of dat men je e-mail leest, wat bij internationale projecten vaak het meest voorkomende communicatiekanaal is. Je kunt niet twaalf landen afreizen om te vertellen wat je aan het doen bent. Op zijn tijd moet je echt fysiek je project ‘verkopen’ als project manager. Je slaagkans wordt hiermee vergroot en de opkomende onrust in de projectomgeving wordt dan in de kiem gesmoord.
Denk als pm ook altijd aan het belang van je opdrachtgever. Jouw opdrachtgever moet ‘iets’ vertellen om zijn baas tevreden te stellen. Al is het project niet voor honderd procent voorbereid, start dan met ‘iets’ waar je niet al te veel risico’s mee loopt. Je opdrachtgever kan dan in ieder geval vertellen dat het project is gestart, wat weer even lucht geeft.
Specialisten zijn vaak druk en hebben niet altijd een belang om in een programmaomgeving bij ieder pm-werkoverleg of presentatie aanwezig te zijn. Hier kun je op je strepen staan en het een en ander via de projectboard afdwingen. Je kunt er ook voor zorgen dat hij of zij een belang ziet om er bij te zijn. Maak de specialist nieuwsgierig en geef hem of haar het gevoel dat het erg belangrijk is dat hij of zij aanwezig is.
Zorg ook dat de juiste projectmanager op deze projecten zit. In een subtiele organisatie moet je een projectmanager van het type ‘geen woorden maar daden’ plaatsen. Andersom idem dito.
Bij de aanvraag voor gecertificeerde projectmanagers (Prince2, IPMA of PMI) moet je je als projectmanager ook afvragen in hoeverre de aanvraag juist is. Hier en daar is het een hype of een cosmetische vraag zonder vakinhoud. Wie kent inmiddels de kreet PINO (Prince In Name Onley) niet? Een echte pm-vakman komt hier dan bedrogen uit.
Over beheeraspecten is op te merken dat we hier praten over stuurmiddelen van een project, die de pm inderdaad moet managen binnen de gegeven bandbreedte van handelen. De stuurmiddelen zijn dan ook geld, tijd, kwaliteit en scope. Dit is in het artikel over het hoofd gezien.
Het managen van de scope is een wezenlijk onderdeel van wat we wel of niet doen en heeft een directe relatie met change management. Vooral het laatste, ‘wat doen we niet’, is een belangrijk onderdeel van communicatie en het voorkomen van teleurstellingen. Ook hier geldt: manage de verwachting!
Softwareontwikkeling & PRINCE2 (Computable 28/1/2005)
De schrijver (Kees Broenink) begint goed en komt snel tot met het geven van een aantal valkuilen aan het begin van een project. Op zich heeft de schrijver gelijk dat veel valkuilen ontstaan door een gebrek aan voorbereiding van een project. Echter de verborgen krachten zorgen er niet voor dat de scope van het project ongemerkt verandert. De projectmanager die zijn vak verstaat zal dit signaleren en actie ondernemen. Wat wel kan gebeuren is dat de scope op drift raakt en te vergelijken is met een elastiekje dat telkens een stukje verder wordt opgerekt. Dit zijn inderdaad geniepige ontwikkelingen die elke beginnende projectmanager wel eens overkomt. De aangedragen oplossing draagt hier in ieder geval niet aan bij. Zeker niet het idee om aparte projecten te starten die per doelstelling een en ander nastreven. Vanuit kostenoogpunt, beheerbaarheid, begrijpelijkheid en toepasbaarheid lijkt me dit geen goed idee.
Projecten hoeven niet altijd in een bestaande organisatie te spelen. Er zijn ook organisaties die projectgestuurd ingericht zijn en lijndiensten leveren aan een project. Het project heeft dan baat met de wijze waarop projectmanagement in de projectorganisatie is ingebed. Een voorbeeld hiervan is de Deutsche Bank Bauspar (IPMA Award winner 2004). Deze organisatie heeft bewezen dat zij op basis van het ‘IPMA project excellence model’ op negen gebieden meetbare projectresultaten konden bereiken met een maximale score van duizend punten. Helaas wordt de inhoud van het artikel na dit punt verder onduidelijk. Bedoelt de schrijver het spanningsveld tussen lijnorganisatie en projectorganisatie (punt één)of beschrijft hij hier een tijdelijke projectorganisatie (punt twee)?
Punt een is een herkenbaar probleem dat eenvoudig opgelost kan worden door de lijnorganisatie te zien als een interne leverancier die haar diensten levert aan het project. De lijnorganisatie heeft dan een leveringsovereenkomst met een verplichting tot leveren binnen de (project)contractafspraken. Deze dienstverlening kan gefactureerd en betaald worden uit het projectbudget. Met andere woorden: er ontstaat een zakelijk belang (business case) voor de afdeling om een bijdrage te leveren aan het project. De problemen die dan worden opgelost zijn dat het afstaan van lijnmedewerkers aan het project niet lastig meer is, maar geld oplevert en dat de projecteigenaren de desbetreffende afdeling door de ‘zakelijke overeenkomst’ op wanprestatie kunnen aanspreken en zonodig disciplinaire maatregelen kunnen nemen. Dit geld ook bij off-specificaties van de geleverde diensten en / of ontwikkelde producten. Verder kan het functioneren van de desbetreffende afdelingen met ‘fout/goed-statistieken’ gemeten worden en gebruikt worden voor een einde-jaarbeoordeling
De stelling van de schrijver bij punt twee is juist. Een goede projectorganisatie met heldere taken, verantwoordelijkheden en bevoegdheden vormen de uitgangspunten voor het beheren van relaties. Dat gaat in hiërarchische culturen beter dan in Nederland. De Nederlander is in deze wat brutaler en voelt zich vaak minder verbonden aan regels dan mensen in andere culturen. Uit ervaring weet ik dat het heel anders werken is met medewerkers uit bijvoorbeeld België, Frankrijk of Duitsland.
Prince2 ontbeert communicatiestrategie? (Computable 28/1/2005)
Ook hier een schrijver (Theo Koster) die het belang van communicatie bij projecten belangrijk vindt en met de andere schrijver (Peter Siebbeles) een positieve bijdrage willen leveren aan het verbeteren van dit onderwerp. Bravo! Maar deze schrijver heeft het helaas mis. De projectmanager moet inderdaad (zoals eerder aangegeven) zijn omgeving managen. In het artikel wordt echter voorbij gegaan aan de rol, taken en bevoegdheden van de stuurgroep. Binnen een Prince2-project hoort een gebruikersvertegenwoordiger te zitten (senior user) die draagvlak moet realiseren. Bovendien is de Prince2-methodiek een integrale projectmanagement-methodiek die alle genoemde rollen binnen een veranderde omgeving vertegenwoordigt. De rol die de heer Koster aan de ict toekent is onjuist. Het uitleggen van een toegevoegde waarde hoort thuis in een business case die aangeeft wat de rechtvaardiging aangeeft voor de bedrijfsinvestering in projectvorm. De directeur of budgethouder zal dan in samenwerking moeten overtuigen.
Brrr… Ontdek ik template management (PINO) in het stukje? In de originele Prince2-sjablonen wordt communicatie binnen een projectteam genoemd? Tja, laten we kort zijn: de pm moet een communicatieplan maken en heeft een gedelegeerde bevoegdheid voor het dagelijks managen van het project. De stuurgroep is wel betrokken bij het project (zie bij Prince2 de DP-processen 1 tot en met 5). Zij zijn zelf projecteigenaar en opdrachtgever (afgeven mandaat)!
Maar is een project nu succesvol als de medewerkers van het project gelukkig zijn of is een project succesvol als de eindgebruiker gelukkig is met zijn veranderde omgeving? Ik denk, in tegenstelling tot de schrijver, het laatste. Ook de geschetste oplossing van rol van vertegenwoordigers is niet nieuw. In integraal projectmanagement worden juist die rollen in een project toegevoegd die op programma- of stuurgroepniveau de draagkracht kunnen realiseren.
Deze mensen moeten in goed overleg, in balans en zonder kippenhokgehalte de belangen vertegenwoordigen en commitment uitstralen. De projectmanager heeft in deze een gedelegeerde rol voor het managen van de dagelijkse leiding. Het idee of voorstel is niet realistisch als men een internationaal projectprogramma leidt over twaalf landen met een totale projectorganisatie van achthonderd medewerkers. In een dergelijke situatie helpt alleen een goede en gestandaardiseerde projectorganisatie met heldere communicatiestructuren (communicatieplan) en (voortgangs)rapporten. Tot slot: een projectmanager die people management beheerst en voldoende ervaring heeft, moet in staat zijn om de sfeer en communicatie ‘open en levendig’ te houden.
Conclusie:
De sterke punten ligt in het feit dat alle schrijvers een positieve bijdrage willen leveren aan het professionaliseren van projectmanagement en de moeite hebben genomen om hierover te schrijven. Ook hebben de schrijvers een overeenkomst van de gevonden problemen. Communicatie, projectorganisatie en het beheren van de stuurmiddelen (scope, tijd, geld en kwaliteit). Dit zijn inderdaad vaak punten die problemen opleveren, maar gemakkelijk opgelost kunnen worden.
Het zwakke en eveneens gemeenschappelijke is dat geen van de betrokkenen uitvoerend professional (leraar, ontwikkelaar, directeur) op het vakgebied projectmanagement en oplossingen en ideeën aanbieden voor onvolwassen projectmanagement. Eigenlijk probeert iedereen een positief resultaat te halen binnen het bereikbare. Het bereikbare kan alleen worden gehaald als organisaties op het gebied van projectmanagement volwassen worden en de opleidingsinvesteringen ook gaan inbedden in de organisatie. De professionele projectmanager kan zich dan uitleven in projectmanagement in plaats van in bedrijfsorganisatorische symptoombestrijding.< BR>
John Roos, Cerfified projectmanager & IPMA Award 2005 assessor