10 praktische valkuilen van het PMO

Op basis van onze ervaring, hebben we een top tien pmo valkuilen samengesteld en uiteraard geven we graag advies over hoe deze te voorkomen zijn.

Gartner Research & PMI schat dat Project Management Offices (PMO) een slagingspercentage hebben van minder dan 50 procent als deze voor het eerst worden opgezet. Mojeo helpt projectorganisaties om ervoor te zorgen dat ze vanaf het begin succesvol zijn met het opzetten van hun PMO en helpt de valkuilen die leiden tot falen te voorkomen. Op basis van onze ervaring, hebben we een TOP TIEN PMO VALKUILEN samengesteld en uiteraard geven we graag advies over hoe deze te voorkomen zijn.

Valkuil 1: Het PMO speelt “methodiek politie”

Als er een gemeenschappelijke gemene deler is voor mislukte PMO’s, dan is het dit: Het PMO wordt de “Methodiek Politie” die vaak rigoureus hun methodiek proberen af te dwingen. In het beste geval leidt dit tot klachten en frustraties van projectmanagers; in het ergste geval leidt het tot opstand en volledig negeren van het PMO. In plaats van hulp te bieden aan projectmanagers door een samenhang in de projectmanagement methodiek te creëren, wordt het PMO de grootste vijand van de projectmanagers. Het PMO verliest het overzicht in het project portfolio en mislukt door gebrek aan steun.

Valkuil 2: Methode zonder framework

Sommige PMO’s proberen om een Software Development Life Cycle (SDLC) binnen hun organisatie te implementeren. Dit is geweldig voor software development teams, maar kan volledig ongeschikt zijn voor bijvoorbeeld infrastructuur teams en proces improvement teams. Een betere structuur is een overall projectmanagement framework, met alleen de elementaire fasen en gates en een aantal belangrijke projectmanagementproducten (business case, projectplanning, statusrapport, etc.). Dit is ook wel bekend als een PDLC (Project Development Life Cycle) en veel verschillende SDLCs passen in dit kader, afgestemd op de behoeften van de verschillende soorten projecten.

Valkuil 3: Niet implementeren van een methodiek

Spreken we onszelf nu tegen? Niet echt. Als het PMO niet een overkoepelend framework implementeert, kan het geen overzicht geven van de projecten. Er is een methode nodig om de consistentie van de uitvoering van het project te waarborgen en de risico’s die ontstaan door bijvoorbeeld onervaren projectmanagers te verminderen. Zo kan bijvoorbeeld een junior projectmanager vaak niet de juiste projectplanning maken, de toewijzing van het werk verkeerd inschalen, of risicobeoordelingen vergeten, die leiden tot problemen tijdens het project, waardoor er vaak heroïsche inspanningen nodig zijn om het project weer op de rails te krijgen. Een gevestigde methode is dus essentieel.

Valkuil 4: Niet afstemmen tussen vraag en beschikbaarheid

In vergaderingen van de stuurgroep ligt de focus bijna altijd op de prioritering. Dat is een goede zaak, want goede prioritering-processen resulteren in een goed begrip van de eisen van het project. Maar als het gaat om de beslissing hoeveel van de belangrijkste projecten daadwerkelijk kunnen worden uitgevoerd, dan wordt het vaak puur giswerk “Hoe overbelast is jouw afdeling, Roger?” Of “Als we de Top 10 projecten gaan uitvoeren, kunnen we dat aan qua belasting?” Zonder een aan eenheid gebonden begrip van de resource capaciteit is het onmogelijk om de feitelijke levering van resources op een goede manier te matchen met de behoefte vanuit de projecten.

Valkuil 5: Geen tijdsregistratie

Dit is eigenlijk de bron van PMO Valkuil 4. Zonder het bijhouden van de actuele uren die besteed zijn aan concrete projecten en ander werk, is het onmogelijk om de reële capaciteit van de projectorganisatie te weten. Het plannen, zelfs op het meest gedetailleerde niveau, wordt slechts giswerk als het niet wordt gekoppeld aan actuele uren.

Valkuil 6: Verzamelen van onnodige informatie

PMO’s zijn goed in het verzamelen van allerlei statistieken. Indien deze informatie niet wordt gebruikt in de besluitvorming, waarom verzamel je deze dan? Het creëert alleen maar extra belasting voor het projectteam zonder dat dit leidt tot een resultaat. Een voorbeeld hiervan is het verzamelen van tijdsgegevens op het detailniveau, met inbegrip van subtaken zoals “Reageren op e-mail,” en “Woon meeting bij.” Voor de planningsdoeleinden is het enkel nodig om te weten hoeveel tijd elke resource heeft besteed aan hoofdtaken en kunnen subtaken worden samengevat onder 1 noemer, bijvoorbeeld “Administratie”.

Valkuil 7: Bijhouden van een ad-hoc project request is onmogelijk

Het meest voorkomende proces voor het omgaan met nieuwe projectaanvragen is om ze te analyseren en steeds per aanvraag te beslissen of het daadwerkelijk een nieuw project is. Maar hoe doe je dat als er 100 projectaanvragen gedaan worden? Hoe prioriteer je dan? Het upgraden van het OS op de servers kan van belang zijn, maar is het belangrijker dan het nieuwe datacenter in EMEA? Als je alle nieuwe aanvragen steeds per aanvraag evalueert, dan overtroeft elke “belangrijke” projectaanvraag de reeds lopende projecten. Het resultaat is een complete omwenteling van de lopende projecten. De oplossing is om cyclisch om te gaan met aanvragen, zodat alle projectaanvragen naast elkaar worden geplaatst en zodoende de aanvragen die het belangrijkste zijn voor de organisatie voorop worden gesteld. Hoeveel projecten aanvragen moeten worden opgepakt? Zie valkuil 4: niet afstemmen tussen vraag en beschikbaarheid.

Valkuil 8: Gebrek aan executive support

Deze zou eigenlijk duidelijk moeten zijn, maar het gebeurt constant. Het executive team realiseert zich dat er een probleem is met projecten die niet naar behoren worden uitgevoerd, door bijvoorbeeld te weinig middelen of resources. Dus machtigen zij het PMO en hopen dat het probleem wordt opgelost. Maar vervolgens sturen ze lagere functionarissen naar de vergaderingen van de stuurgroep en geven hen geen beslissingsbevoegdheid. Of, erger nog, ze overrulen beslissingen van het PMO. Als projecten dan slecht performen, als gevolg van prioriteringsconflicten of gebrek aan de juiste resources, geven ze het PMO de schuld en ontbinden het.

Valkuil 9: Implementeren van een tool zonder een proces erachter

Een andere voor de hand liggende probleem. Of het nu gaat om de implementatie van een PPM-oplossing of een ERP- systeem, als er geen goede processen achter zitten dan vraag je om problemen! IT-afdelingen lijken vaak te denken dat de tool de oplossing is, maar het zal je verbazen hoeveel andere organisaties in dezelfde val stappen. Het gebruikelijke excuus is dat de tool al “best practices” heeft ingebed, dus waarom volgen we die niet gewoon? Onze ervaring is dat elke organisatie anders is en dat die dus een tailormade oplossing nodig hebben, gebaseerd op hun eigen “best practices”.

Valkuil 10: Implementeer een tool en het proces tegelijkertijd

Het standaard advies lijkt te zijn om de processen eerst helder te hebben, voordat je deze automatiseert met een tool. Dit kan voor het PMO grote problemen opleveren. Complexe processen draaien op spreadsheets en documenten worden zwaarder en zwaarder, als er geen juiste tool wordt gebruikt voor het proces. Ons advies is om het proces en de tool gelijktijdig te implementeren. Dit heeft de volgende voordelen; ten eerste kunt u het nieuwe proces ontwerpen op basis van de sterke punten van de gekozen software tool. Ten tweede leren de gebruikers de nieuwe werkwijze meteen met de nieuwe tool te gebruiken. Tot slot, de nieuwe werkwijze heeft de beste kans van acceptatie en dus slagen als de gebruikers het meteen met de nieuwe tool vanaf het begin kunnen gebruiken. Er is wel een nadeel aan deze aanpak. Als er iets mis gaat, moet je wel in staat zijn om te achterhalen of het aan het proces of aan de tool ligt. Want vaak is de tool dan de grote zondebok, terwijl dat niet altijd het echte probleem is.