SAFe Program Consultant certificatie

Het ene is het andere niet

Bij het bedrijf waar ik momenteel werk, wordt er met agile projecten gewerkt, maar ontbreekt er wel een framework om dit te schalen. Er wordt stiekem naar SAFe gekeken, maar eigenlijk wordt van dit framework bitter weinig gehanteerd. Dit plantte wel een kiem van nieuwsgierigheid bij mij aangezien ik niet zo bekend was met agile scaling frameworks. Niet gehinderd door enige kennis ter zake schreef ik me in voor een opleiding SAFe for Teams, maar deze opleiding werd in mei geannuleerd. In zeven haasten zocht ik een andere opleiding en kwam ik bij een opleiding SAFe Program Consultant (SPC) terecht. Een maand geleden wist ik amper wat het verschil tussen deze twee opleidingen was, maar uiteindelijk ben ik blij dat ik de SPC-opleiding heb gevolgd. 

Het verschil

SAFe is dus een framework om agile projecten op grotere schaal te implementeren in een organisaatie en past heel wat concepten toe van lean en agile. Het uitgangspunt is eenvoudig gezegd dat er met release trains worden gewerkt waarin teams aan eenzelfde oplossing werken in hetzelfde tempo en gezamenlijk plannen en itereren. Dit framework heeft ook zijn eigen rollen als scrum master en product owner die in SAFe op een net iets andere manier worden ingevuld en dat is ook de reden waarom er zoveel verschillende opleidingen zijn. SAFe for Teams is eigenlijk bedoeld voor teamleden van een agile team die met SAFe willen leren werken. De Safe Program Consultant-opleiding daarentegen duurt vier dagen (tegenover twee voor S4T) en is een train-de-trainer opleiding op expertniveau. Na deze opleiding (en het examen succesvol afgelegd te hebben) ben je gecertificeerd om te fungeren als change agent van het SAFe framework. 

De vierdaagse SPC-opleiding kost ongeveer 2700 euro zonder BTW en is dus niet goedkoop te noemen. Daar krijg je echter wel een heleboel voor terug. Je kunt namelijk het examen gratis afleggen tot dertig dagen na de laatste opleidingsdag. De intrinsieke waarde van een (her)examen is circa 250 dollar. Na het examen succesvol afgelegd te hebben, krijg je echter ook toegang tot het lesmateriaal van alle andere opleidingen die je mag geven en dat zijn er een heleboel :Scrum Master, Advanced Scrum Master, DevOps, Product Manager & Product Owner, SAFe for Teams, Agile Leaders. Bij elk van deze opleiding dien je een examen af te leggen waarna je geautoriseerd bent om les te geven in deze opleidingen. Voor het geïnvesteerde bedrag krijg je dus als het ware toegang tot het volledige cursusmateriaal over SAFe. 

Het nadeel is dan weer dat de certificatie slechts een jaar geldig blijft. Wil je gecertificeerd blijven, betaal je daarvoor een kleine vergoeding. Het is een business model dat wel meer opleidingsbedrijven hanteren, maar het vernieuwingsbedrag voor SPC is wel aan de erg stevige kant met 895 dollar per jaar. Daarvoor blijf je echter wel een jaartje langer gecertificeerd en blijf je toegang behouden tot al het lesmateriaal en de community. Als je lesgeeft in één van deze cursussen is het relatief betaalbaar, maar wanneer je er geen gebruik van maakt is hercertificatie misschien een trein die je wil missen. 

De toegevoegde waarde

Het niveau van de SPC-opleiding is uiteraard hoger dan de andere opleidingen in de familie, maar dat is uiteraard ook de bedoeling. Na deze opleiding mag je jezelf een specialist in SAFe noemen en worden SPC's geacht om de transformatie naar SAFe voor te bereiden, uit te voeren en te faciliteren. Dan is een grondige kennis van SAFe natuurlijk wel gewenst. 

SAFe is gestoeld op een aantal principes, maar in de praktijk zie je dat SAFe wordt gecombineerd met andere best practices en soms zelfs wordt gemengd met andere frameworks zoals LeSS en/of Spotify-model. Vervolgens krijg je dan een potpourri waar de voordelen van één model de nadelen van het andere model worden en zo ontstaat er onevenwicht in de organisatie. 

Met mijn project management-achtergrond en MBA op zak komt erg veel van het SAFe framework bekend voor, maar de lean gedachte wordt op een vlotte manier geïntegreerd in het framework. Op het vlak van governance is SAFe volgens mij één van de best uitgewerkte frameworks die ik tot dusver ben tegengekomen samen met Prince2. Prince2 steekt heel erg goed in elkaar, maar wordt eveneens beticht van te bureaucratisch en theoretisch te zijn. Op dat vlak zie ik wel gelijkenissen met SAFe. Ik zou SAFe naadloos kunnen toepassen bij mijn vorig project en het zou een significante meerwaarde betekenen in het identificeren van lacunes en terugkoppeling bezorgen over de kwaliteit van de geleverde software. SAFe stelt dan voor om de flow te optimaliseren, maar hoe je dat doet, gaat niet verder dan een regelboek met een aantal suggesties. Prince2-adepten zullen nu wel een kleine deja-vu beleven. 

En wat nu?

Ik ben nu dus SPC-gecertificeerd, maar de belangrijkste vraag is: wat ga ik ermee doen? Aangezien ik een organisatie werk die geen SAFe toepast, is het uiteraard moeilijk om SAFe te implementeren. De basisprincipes staan en vallen namelijk met een afstemming op bedrijfsniveau. Hoewel de lesgevers het zelf uitdrukkelijk afraden (omwille van het principe van system thinking), is het wel mogelijk om een aantal best practices er uit te pikken en te implementeren. Zaken die voor mij nuttig zijn, zijn onder andere een verwaterde versie van de PI-planning op teamniveau om commitment te hebben voor doelstelling van één kwartaal, het frequent integreren met andere teams door middel van demo's en uiteraard de rol van agile leader. Afspraak over één jaar om te zien hoeveel het wel of niet geholpen heeft!

Agile certificatie

Niet nieuw

Sinds de oprichting van het agile manifesto in 2001 stappen meer en meer ontwikkelingsteam over naar deze nieuwe manier van werken. Agile is niet alleen een nieuwe manier van werken, maar ook een nieuwe manier van denken. Het basisprincipe is dat zoveel mogelijk lagen van management worden weggeëbt ten voordele van zelforganiserende teams die in staat zijn om zelf beslissingen te nemen. Het is een principe dat stemt uit de jaren zeventig van vorige eeuw bij de Zweedse autoconstructeurs Saab en Volvo waar teams aan één volledige auto sleutelden. De reden van deze aanpak is dat bij jobdiversiteit de motivatie en productiviteit toeneemt. Dit kon echter niet op tegen de spectaculaire kostendalingen door specialisatie en standaaardisatie en deze aanpak van zelforganiserende teams stierf eind jaren zeventig een stille dood.

Een aantal decennia later zetten agile methodologieën zoals Scrum het thema van zelforganiserende teams terug in de kijker, maar de waarheid is dus dat dit oude wijn in nieuwe zakken is. Bij agile spreken we niet langer over managers die resultaten moeten boeken, maar wel over teams die worden geleid door een coach. Managerfuncties krijgen volgens deze theorie meer tijd voor zaken die nuttig zijn voor een bedrijf zoals het opvolgen en evalueren van werknemers, in contact staan met klanten, bijdragen aan de strategie van het bedrijf of de markt en/of concurrentie in de gaten houden. Ideaal toch?

Agile ontbijtgranen

Managementgoeroe Peter Drucker zei ooit de gevleugelde woorden: “Culture eats strategy for breakfast” en het is waarschijnlijk één van de meest gebezigde oneliners in de wereld van managers en CEO’s omdat het een waarheid als een koe is. Je mag dan Scrum introduceren in een bedrijf, maar als er in dat bewuste bedrijf een machtscultuur heerst in een silo-organisatie is de kans meer dan reëel dat Scrum niet zal werken. In Leavitt’s diamond wordt duidelijk gemaakt dat structuur, werknemers, taken en technologie onlosmakelijk met elkaar verbonden zijn en je kan dus niet zomaar de structuur van een organisatie veranderen in de hoop dat al de rest wel volgt.

Een agile methodologie zoals Scrum vergt zowel een top-down als bottom-up aanpak vooraleer het kan werken. Een top-down aanpak is nodig zodat topmanagement de tijd en middelen gunt aan het personeel om zich vertrouwd te maken met een nieuwe manier van werken én denken. Een bottom-up aanpak is dan weer aangeraden omdat methodologieën zoals Scrum de samenwerking tussen werknemers centraal plaatst en hiervoor heb je natuurlijk de medewerking van iedereen nodig.  Het is juist deze paradox die ervoor zorgt dat Scrum zelden volledig slaagt. Bovendien zijn meeste managers niet happig om hun beslissingen en controle af te staan aan zelforganiserende teams.

Het certificaatsparadox

Agile promoot dan ook nieuwe manieren van samenwerken en ideeën verzamelen zoals mind mapping, colocatie, serious games, rollenspellen en gamification. Concepten zoals mind mapping zijn vrij bekend en al redelijk oud, maar worden weinig toegepast in het courante bedrijfsleven. Door team meetings stijgt mind mapping in populariteit waar in team wordt nagedacht over zaken zoals planningen, estimaties en risicoanalyses. Aanhangers van agile hechten daarom veel belang aan ervaring en mentaliteit en daarom veel minder aan certificaten. Meer nog, veel aanhangers van agile zijn rabiate tegenstanders van certificaten wat zij zien als commercialisatie van kennis. Vreemd genoeg duiken er met de regelmaat van de klok certificaten in agile en Scrum op: Professional Scrum Master (PSM), Certified Scrum Master (CSM) en Agile Certified Practitioner (ACP) zijn hiervan de bekendste, maar er zijn nog een aantal tegenhangers voor product owners en tientallen andere certificaten van andere organisaties. Is dit dan geen nestbevuiling voor agile methodologieën?

Als we de redenering van supporters van agile doortrekken wel. Meeste certificaten toetsen namelijk je theoretische kennis, maar niet je praktische kennis. Het is vrij ironisch dat iemand zich Certified Scrum Master mag noemen na een tweedaagse opleiding en een vrij gemakkelijk examen. Het examen van Professional Scrum Master (PSM) op niveau één is dan weer een stuk moeilijker, maar toetst ook hier niet de praktische kant van Scrum. Als je dus veel ervaring hebt in Scrum of een andere agile methodologie heeft het ogenschijnlijk weinig waarde om zo’n certificaat te behalen.

Certificaten bestaan in de eerste plaats omdat ze geld opleveren, maar ze tonen ook aan dat iemand over (basis)kennis beschikt in een bepaald gebied. Het is dus een ideaal middel voor personen om aan te tonen dat ze over specifieke kennis beschikken, ook al werken ze bijvoorbeeld niet met agile. Maar ook voor ervaren mensen kan certifiëring nuttig zijn. Zoals gezegd werken veel organisaties met een geïmproviseerde en/of verkeerde versie van Scrum of een andere agile methodologie waardoor enkel de nadelen naar boven komen drijven en niet de voordelen. Zo blijkt het plots dat deadlines onrealistisch zijn, de workload explodeert en niemand durft nog beslissingen te nemen. In zo’n geval is het dus wel nuttig om een certificaat te hebben zodat je tenminste niet zondigt tegen de basisprincipes van agile of Scrum.

Change management: business voodoo of wetenschap in werking?

Jouw functie
De Senior Change & Business Transformation Consultant is verantwoordelijk voor alle aspecten van onze change management consulting services bij de klanten. Dit omvat het mogelijk maken van systeemimplementaties door change management, organisaties ondersteunen tijdens significante transformaties (fusies, overnames, shared services, herstructureringen …) en het creeëren van een change cultuur. Een greep uit het aanbod van verantwoordelijkheden:

• Het ontwikkelen, in nauwe samenwerking met de klant, van een op maat gemaakte change management strategie die rekening houdt met de specifieke situatie, de impact van de change en de gewenste resultaten
• Het implementeren van een sterk change management process met aandacht voor stakeholder management, leiderschap acties, ontwikkelingsplannen, communicatieplannen …
• Advies verlenen op het vlak van organisational redesign interventions die organisationele effectiviteit stimuleren
• Het trainen van business leaders die in staat zijn change en culturele transformatie te begeleiden
• Het organiseren van change consulting projecten van start tot finish

Bovenstaand stukje tekst komt van een jobaanbieding van een "senior change & business transformation consultant" van de firma Delaware. Het gaat dus om iemand die bedrijven helpt bij veranderingen. Dit kan dus gaan van kleinschalige projecten tot grootste transformaties op bedrijfsniveaus zoals bijvoorbeeld een fusie. De vraag is echter of veranderingen gestuurd kunnen worden. 

Size does matter

Het belangrijkste bij dit soort projecten is wellicht de omvang van de verandering die en bedrijf wil doorvoeren. Veel projecten hebben namelijk invloed op de werking van een bedrijf, maar deze verandering is vaak niet meer dan een verandering van gewoontes. Het gaat bijvoorbeeld om projecten waar bij een bedrijf nieuwe tools worden gebruikt. Zelf heb ik als business analyst aan een project meegewerkt bij Euroclear waar Changepoint werd geïntroduceerd. Changepoint is een project- en portfoliomanagement tool met verschillende functionaliteiten. De tool kan gebruikt worden om verschillende ideeën te rangschikken zodat het steering committee vervolgens de meest zinvolle (en winstgevende of kostenbesparende) projecten worden geconcretiseerd, maar het wordt ook gebruikt om projecten op te volgen à la Microsoft Project en door de gewone werknemers om hun tijd te registreren. Bij dit project was ook een change manager betrokken die alle betrokken partijen op één lijn moest krijgen om deze tool zo goed mogelijk te gebruiken. 

Dit is een interessante en uitdagende functie want het overschrijdt de grenzen van een klassiek project. Hier moet je namelijk rekening houden met de bestaande bedrijfscultuur, procedures die gebruikt worden, de algemene attitude van werknemers, eventueel verzet tegen het project en het luisteren naar behoeftes van betrokken partijen. Niet alle partijen zijn namelijk even hard geïmpacteerd door een project. Sommige partijen moeten hun volledige werkwijze herzien terwijl andere partijen een kleine procedure moeten veranderen. 

Bij Euroclear was de implementatie van deze verandering eigenlijk verrassend simpel. Niet omwille van de aard van de job - die is veeleisend en uitdagend - maar wel omdat de factoren die change management moeilijk of gemakkelijk maken de sterren gunstig gezind waren. De verandering kwam er namelijk op vraag van de PMO-dienst (project management office) die het beu was om met allerlei tools de gewenste informatie te bekomen. Met Changepoint was er één tool waar je (bijna) alles mee kon doen. Voor de werknemers van Euroclear betekende dit dat hun leven gemakkelijker werd gemaakt en was de bereidwilligheid om aan dit project mee te werken groot. Ze kenden de visie achter het project en begrepen waarom deze verandering nodig was. 

Een bijkomend hulpmiddel was de overheersende cultuur bij Euroclear. Euroclear is namelijk een dochteronderneming van JP Morgan en zoals algemeen geweten zijn deze bedrijven heel goed en duidelijk gestructureerd. Bij Euroclear is dit ook het geval met een uitgesproken matrixcultuur waar procedures erg belangrijk zijn. Dit stemt overeen met een task cultuur waar expertise en in mindere mater autoriteit belangrijk zijn. Door deze twee criteria te beïnvloeden is het mogelijk om de veranderingen die dit project teweeg brengt te beïnvloeden.

Diamant

Het hoeft geen betoog dat dit voor grotere veranderingen een stuk moeilijker is. De complexiteit zit namelijk in de talloze factoren waarmee je rekening moet houden. Verandering is immers niet wat gepland kan worden. Soms starten bedrijven bewust een veranderingsproject na bijvoorbeeld de aanstelling van een nieuwe bedrijfsleider, maar in verreweg de meeste gevallen zijn externe factoren de oorzaak van verandering. Leavitt heeft deze factoren schematisch voorgesteld in een diamantfiguur. 

Factoren die invloed hebben op veranderingen zijn gerelateerd aan structuur, technologie, mensen en taken wat direct een goed gevulde boterham is. Dit idee borduurt verder op de beroemde bewering van strategiegoeroe Mintzerg die stelt dat structuur en strategie onlosmakelijk met elkaar zijn verbonden. Voor change management is dus de structuur van een bedrijf, de strategie die het hanteert, de achterliggende technologieën en de mensen die ermee werken van belang. En dit beweegt veel academici ertoe om te beweren dat cultuur belangrijker is dan een bepaalde strategie van een bedrijf. Als je Leavitt's diamantvorm ziet, besef je onmiddellijk waarom veel academici dit zeggen.  d

Consultants hebben hier echter geen boodschap aan en hebben hun eigen agenda die ze moeten verkopen. Dat brengt ons dus bij consultancybedrijven zoals Delaware, McKinsey, Deloitte, KPMG en talloze andere. Zij beweren namelijk dat dit wel gaat met de juiste begeleiding. Maar om te toetsen of dit daadwerkelijk kan, is het belangrijk om eerst te definiëren wat cultuur eigenlijk is en inhoudt. 

De meest gebruikte (en simpelste) definitie van cultuur is dat het een verzameling van waardes, tradities, en gebruiken die in de organisatie gedeeld worden en het groepsgedrag in de organisatie bepalen. Zo kan een bedrijf een matrixstructuur hanteren waar er een task cultuur heerst, terwijl in KMO's we eerder een power cultuur terugvinden waar autoriteit erg belangrijk is en een persoonscultuur bij creatieve beroepen zoals bijvoorbeeld marketingbureaus. De structuur van zo'n organisatie brengt onmiddellijk een eigen cultuur met zich mee. Bij een task cultuur zal het makkelijker zijn om cultuur te beïnvloeden door bestaande processen en procedures aan te passen. Bij een persoon cultuur is dit veel minder evident. 

Kotter heeft zich opgeworpen als een vakgoeroe in change management en heeft acht stappen beschreven die een succesvol change management project moet bevatten: 1. creëer een gevoel van urgentie 2. vorm een coalitie dat het project leidt 3. creëer een visie 4. communiceer deze visie 5. geef mensen de autoriteit om binnen deze visie te handelen 6. creëer kleinschalige winsten 7. consolideer deze verbeteringen om meer verandering te genereren 8. internaliseer deze veranderingen. Deze aanpak wordt door een aantal academici bekritiseerd omdat het een stappenplan hanteert bij veranderingen, terwijl veranderingen iteratief zijn in plaats van lineair. Zo'n stappenplan zal bij een incrementele verandering in een task cultuur zoals het Changepoint project bij Euroclear werken, maar biedt te weinig voedingsbodem bij transformaties van organisaties. 

Organizational development

Voor transformaties van organisaties bestaat er een alternatief in de vorm van organizational development (OD). OD verschilt van klassiek change management in de zin dat het zich richt op de lange termijn en het bedrijf en niet zozeer het project an sich. Het probeert met andere woorden de onderliggende sociale, culturele en politieke factoren van een bedrijf te beïnvloeden. Dit is gemakkelijker gezegd dan gedaan want dit een werk van lange adem waar de effecten niet meteen meetbaar zijn en het is moeilijk om te zeggen of er significante veranderingen in een bedrijf plaatsvinden omdat veranderingen gestaag worden geïmplementeerd. Bij OD wordt er onderzoek gedaan naar de verbeteringen die in een bedrijf kunnen plaatsvinden en dit zijn dikwijls kleine interventies. dd

Bij een klassiek change management traject is dit bijvoorbeeld werken met een maandelijkse nieuwsbrief om betrokken partijen de voortgang van het project te laten bekijken. OD betrekt de partijen echter door bijvoorbeeld via team building activiteiten een grotere teamcohesie te creëren. Dit is dus met andere woorden een "softere" aanpak van change management en geniet daarom niet altijd de voorkeur van bedrijfsleiders omdat het zich moeilijk in doelen en indicatoren laat uitdrukken. De meeste academici zijn het er echter wel over eens dat deze aanpak efficiënter is om veranderingen te verankeren in een organisatie dan klassieke change management projecten en zeker als het gaat om het transformeren van een totale organisatie. 

De hamvraag blijft of change management - of het nu OD of een klassiek project is - werkt. Het antwoord is ambigu. Bij incrementele projecten met een geringe verandering zal de efficiëntie groter zijn dan bij grote transformaties. Mensen zijn namelijk gewoontedieren en het is verbazingwekkend hoe moeilijk het soms is om deze gewoontes te wijzigen. De realiteit leert dat de meeste projecten hun gewenste doel niet bereiken omdat de hoeveelheid van factoren waarmee je moet rekening houden niet meer te overzien is. Anderzijds is er een soort van veranderingsvermoeidheid bij veel bedrijven omdat het aantal grote transformatieprojecten om de drie, vier jaar opnieuw worden opgestart. De enige constante in verandering is dus dat het constant aanwezig is.  

De rol van kwaliteit bij de slaagkans van een project

Een vak apart
Eén van de meest uitdagende, maar ook minst gewaardeerde beroepen in het gebied van mangement is de discipline van project management. Het verschil tussen een project manager en een functionele manager is dat een project manager geen vast omlijnd team heeft. Een functionele manager, bijvoorbeeld het hoofd van een marketingafdeling, heeft altijd dezelfde mensen onder zich en het mag aangenomen dat hij een heleboel technische kennis heeft over marketing. Een project manager daarentegen werkt met mensen uit verscheidenene afdelingen: business, IT, compliance, marketing, finance, etc. Meestal heeft een project manager geen directe autoriteit over de mensen die aan een project werken en dat maakt van project management een moeilijke discipline als het aankomt op het managen van mensen. Een bijkomende moeilijkheid is dat project managers liefst over een brede kennis beschikken. Niet alleen business of IT, maar ook over de wetgeving waarin een project fungeert, de financiën van een project en andere factoren. De projecten zelf kunnen ook verschillen in complexiteit. Een project dat min of meer hetzelfde is als tien voorgaande projecten is een stuk simpeler dan een project dat op meerdere locaties wordt uitgevoerd over de organisatie heen.

In een organisatie worden project managers meestal in het middenkader geplaatst, net onder het niveau van de functionele managers. De reden hiervoor is omdat functionele managers een directe beslissingsbevoegdheid hebben over middelen, maar project managers niet. Een functionele manager kan bijvoorbeeld schuiven met mensen bij verscheidene projecten, terwijl de project manager leidzaam moet toezien. Zo beschikt een project manager ook niet over een direct budget. Zijn taak is om toe te zien dat de geraamde kosten niet worden overschreden. Het is dus als project manager niet zomaar mogelijk om extra middelen aan te wenden. Functionele managers groeien gemakkelijker door in de hiërarchie, terwijl project managers het glazen plafond van het topkader nauwelijks of niet kunnen doorbreken, tenzij ze eerst van functie verwisselen, bijvoorbeeld functioneel manager.

Kans op falen
Dat project management geen gemakkelijk vak is, bewijzen de cijfers uit onderzoek. Maar liefst zeventig procent van de projecten worden later als gefaald omschreven. Gefaald wil overigens niet zeggen dat een project totaal mislukt is. Een gefaald project kan talloze redenen hebben: de kosten zijn zo hoog opgelopen dat de voordelen dit niet meer kunnen dekken, het project heeft te lang geduurd waardoor de concurrentie eerder op de markt is, de beloofde voordelen van het project worden in de realiteit niet verwezenlijk, klanten zijn niet tevreden over het afgeleverde product, etc. Ontevreden klanten zijn misschien wel de ergste reden waarom een project mislukt. Dit komt omdat kwaliteit het allerbelangrijkste aspect van een project is, terwijl er in de praktijk relatief weinig aandacht aan wordt gespendeerd.

Een project wordt meestal gemanaged via de triple constraint. Deze drie beperkingen (tijd, kosten en scope) bepalen de omvang en grenzen van een project. Als een SAP-project vijf miljoen euro kost en één jaar duurt, worden de lopende resultaten altijd vergeleken met deze eindpunten. Het reeds gespendeerde budget wordt dus vergeleken met de geschatte kosten van vijf miljoen euro. Dit geldt evenzeer voor de tijdsduur. Aan de scope wordt minder aandacht geschonken. De scope komt enkel in beeld wanneer er geld- en/of tijdsnood is en besloten wordt om een deel van de scope links te laten liggen. De triple constraint wordt meestal in een driehoeksvorm weergegeven om aan te geven dat een beslissing op één aspect (bijvoorbeeld kosten) een invloed zal hebben op één of twee andere aspecten (in dit geval tijd en scope). Als een project manager beslist dat de kosten te hoog oplopen, kan hij besluiten om een deel van de scope niet uit te voeren, zodat er een deel van de tijd vrijkomt. Kwaliteit is verbonden aan deze drie aspecten en elke beslissing op tijd, kosten of scope heeft een impact op de kwaliteit. Helaas spenderen project managers weinig aandacht om kwaliteit omdat dit volgens de meesten onmeetbaar is.

Quality baseline
Het is inderdaad moeilijk om kwaliteit te meten omdat het nu eenmaal geen exacte wetenschap is. Voor persoon a kan kwaliteit synoniem zijn voor goed genoeg, terwijl persoon b totale perfectie eist. Aan deze subjectieve beoordeling van kwaliteit kan een organisatie niet onderuit en moet het rekening houden met wat klanten zeggen. Daarom zeggen zaken zoals enquetes over klantentevredenheid en aantal klachten veel over de kwaliteit van een bedrijf en bijgevolg ook de projecten. Bovendien kan kwaliteit gemeten worden aan de hand van het aantal defects. In een software project is dit bijvoorbeeld het aantal bugs dat wordt gevonden tijdens de testfase.

Al deze dingen kunnen beschreven worden in de quality baseline. Dit is een document waarin de gewenste kwaliteit staat beschreven en dit wordt vergeleken met de behaalde resultaten tijdens het project. Dit klinkt als een complex proces, maar er bestaan klant-en-klare oplossingen hiervoor. Denk maar aan het kwaliteitsproces dat Prince2 gebruikt. Dit beschrijft hoe je kwaliteit definieert, vaststelt, meet en vergelijkt. Het bevat het plannen en controleren van kwaliteit, maar je kan het ook gebruiken om kwaliteit te verbeteren in een organisatie.

Geen heilige graal
Prince2 staat gekend als een rigide procesmodel, maar niets weerhoudt een project manager ervan om de beste en meest relevante onderdelen hiervan uit te lichten en het toe te passen in een project. Het probleem hierbij is dat wanneer dit niet eerder werd gedaan, de kans bestaat dat het project gaat verdrinken in de goede bedoelingen als er te veel in één keer wordt geïmplementeerd. Bij een eerste implementatie kan een project manager zich beperken tot de absolute noodzakelijkheden zoals een quality strategy (of plan) en technieken om dit te meten. Dit hoeft zeker niet ingewikkeld zijn. In een software project kan worden beschreven hoeveel bugs er per deadline mogen aanwezig zijn en welke impact dit heeft op het project. Het is een erg eenvoudige aanpak met een verrassend sterk resultaat. Van hieruit kan men dan verder bouwen om het kwaliteitsaspect van een project te verbeteren. Het voorgaande voorbeeld is zo simpel dat verreweg de meeste organisaties dit al doen, maar hebben dan moeilijkheden om dit verder te verbeteren.

Het is aanlokkelijk om met een heleboel methodologieën af te komen zoals CMMi, maar dit garandeert niet altijd succes. Het is door een combinatie van ervaring opdoen, de juiste expertise in huis hebben, gezond verstand hebben en over het juiste proces beschikken dat de kwaliteit in een project verbeterd kan worden.

Risk management in een project

Een risico is geen issue en omgekeerd
Een factor die veel project managers stiefmoederlijk behandelen is het beheren van risico's. De meeste project managers weten dat het beheren van risico's een erg belangrijke taak is in een project, maar meestal wordt er weinig tijd en moeite aan gespendeerd. Constraints zoals tijd, scope en budget hebben een directe impact op een project en een risico niet. Toch is dit een verkeerde instelling, want zoals het bekende spreekwoord luidt: voorkomen is beter dan genezen.

Er bestaat veel onduidelijkheid over wat juist een issue en een risico is. Een issue is een probleem waarmee de project manager te kampen heeft in een project. Dit kan zijn dat een teamlid onverwacht ziek wegvalt, de infrastructuur het plots niet meer doet of een onderdeel dat niet meer in voorraad is. Praktisch alles kan een issue zijn en  hier komt het probleemoplossende vermogen van de project manager aan te pas. Een risico daarentegen is een gebeurtenis die niet vaststaat, maar kan gebeuren. Als een belangrijk teamlid al ettelijke dagen met een lopende neus rondwandelt, weet je dat die ziek kan vallen. Risk management gaat dus over het anticiperen op mogelijke gebeurtenissen en hoe je hier het best op reageert. Des te vroeger je kan anticiperen op een risico, des te groter het profijt. Een proactieve ingesteldheid is dus een onontbeerlijke kwaliteit van een project manager als het aankomt op risk management.

Niet enkel voor negativisten
Risico's hebben een negatieve bijklank en in de realiteit hebben de meeste risico's ook een negatief karakter. Zij worden threats (dreigingen) genoemd, maar er bestaan ook positieve risico's en die worden opportunities (opportuniteiten) genoemd. Een threat is bijvoorbeeld de duurder wordende olieprijzen en voor een project kan olie een erg belangrijke bron van input zijn. Een oplossing voor dit risico is bijvoorbeeld gebruik maken van hedging. Een opportuniteit kan zijn dat een project nood heeft aan een transportmiddel en wanneer het autosalon plaatsvindt, krijg je in die periode een fikse korting. Dit is dus ook een risico, maar dan één met een positief karakter.

Elk risico, of het nu een threat of opportunity is, wordt getaxeerd op twee kenmerken: probabiliteit en impact. De probabiliteit meet de kans in welke mate het risico zich zal voordoen en de impact meet de kracht van het risico wanneer het zich voordoet. Aan de hand van een vermenigvuldiging van deze twee factoren wordt de urgentie van een risico bepaald. De meest dringende risico's worden eerst behandeld en hiervoor wordt een actie geïmplementeerd. Het is echter belangrijk om te weten dat de meeste risico's niet volledig kunnen worden geëlimineerd. Aan het resterende deel van dit risico kan je weinig anders doen dan aanvaarden of je moet heel het gehele risico vermijden.

Strategie
Zodra een project begint, is het raadzaam een risk strategy of een risk plan op te stellen. In de praktijk wordt dit amper gedaan omdat risk management nog vrij onvolwassen is in meeste bedrijven. Wanneer een bedrijf of een programma al een risk strategy of plan heeft, kan dit worden overgenomen voor een project. Indien dit niet het geval is, loont het de moeite om op een bondige manier samen te vatten wat risico's precies zijn, hoe men er dient mee mee om te gaan, welke verantwoordelijkheden er zijn, in welke categorieën ze kunnen ingedeeld worden, de toleranties voor risico's en hoe risico's worden opgevolgd en gecommuniceerd. Dit lijkt op het eerste gezicht een nutteloze oefening van bladvulling, maar het maakt de leden van een projectteam wel bewust van hoe er met risico's dient om te gaan. Het is niet de bedoeling dat dit een dode letter blijft, maar de project manager dient het belang van risk management te onderstrepen bij de kick-off meeting.

Eén van de belangrijkste documenten bij een project is het risk register en dit dient bij de aanvang van een project te worden aangemaakt. Het risk register verzamelt alle risico's en geeft daarnaast nog andere informatie: wie het risico heeft ingevoerd, wanneer het was ingevoerd, risicocategorie, beschrijving van het risico, probabiliteit en impact, actie op het risico, status van het risico, wie beheert het risico en wie neemt actie op het risico. Het is van cruciaal belang dat alle teamleden gemachtigd zijn om het risk register te gebruiken. Enkel op deze manier kan gewaarborgd worden dat alle risico's worden geïdentificeerd en behandeld. Het risk register is zo belangrijk omdat dit document gebruikt wordt om risico's te identificeren, te behandelen, op te volgen en af te sluiten. Het is dus met andere woorden het kloppende hart van het risk management in een project.

Risico's identificeren
Wanneer een risk strategy of plan is gecreëerd, volgt er een continu proces van risico's identificeren, evalueren, acties bedenken, deze acties implementeren, de status van risico's opvolgen en alle acties communiceren. Dit klinkt als een goed gevulde boterham, maar in de praktijk gaat dit vliegensvlug. De eerste stap is dus het identificeren van risico's. Deze risico's kunnen van alle hoeken en kanten komen: van stakeholders over gebruikers tot de leden van het project zelf. Elk risico kan een divers karakter hebben, maar meestal zijn ze gelinkt aan de triple constraint: tijd, budget en scope. Documenten die handig zijn bij het bedenken van risico's zijn het projectplan en lessons learned van vorige projecten. Er kunnen ook risk workshops of brainstorm sessies worden geïdentificeerd om risico's te identificeren, hoewel dit niet vaak wordt gedaan. Belangrijker is om alle projectleden toe te laten een risico in te voeren in het risk register omwille van de eerder vermelde redenen.

Evalueren
De criteria probabiliteit en impact verdienen veel aandacht, want zij bepalen de urgentie van een risico. Het risk register wordt meestal periodiek besproken (tijdens de wekelijkse project meeting) en het is belangrijk dat de project manager de urgentie van nieuw geïntroduceerde risico's verifieert met andere projectleden. Zodoende worden risico's geprioriteerd. Andere, minder belangrijke risico's mogen echter niet uit het oog worden verloren, dus is het ook raadzaam om deze te overlopen, maar dan misschien minder courant (één keer om de twee weken bijvoorbeeld).

Een manier om te bepalen welke risico's eerst worden bepaald, is een probability and impact matrix. Op de horizontale as staat de impact en op de verticale as de probabiliteit. Een vermenigvuldiging van deze twee factoren, bepaalt de urgentie van een risico. Deze matrix bestaat voor zowel threats als opportunities. Aan de uitkomst van deze vermenigvuldiging kan een actieplan zijn gekoppeld. Wanneer een risico een heel erg grote probabiliteit en impact heeft, kan een project manager beslissen om dit risico te vermijden (in bovenstaande matrix zouden alle risico's die in het rode vlak komen, worden vermeden). Risico's met een lage urgentie (groene zone) kunnen ddan bijvoorbeeld tweewekelijks worden besproken

Reageren en implementeren
In deze fase wordt de aard van het risico onderzocht om hier een antwoord op te bedenken. Prince2 en PMBoK delen threats en opportunities in een aantal categorieën. Voor threats zijn dit avoid, reduce, transfer, share en accept. Voor opportunities zijn dit exploit, enhance, share en reject. Elke categorie heeft een andere strategie om te antwoorden op een risico. Avoid is het project wijzigen zodat het risico zich niet meer voordoet, reduce probeert om de impact of probabiliteit van een risico te verminderen, transfer beoogt het verhuizen van een risico naar een andere partij (gebeurt vooral bij financiële zaken, bv. een verzekering) en share deelt de verantwoordelijkheid van een risico over twee of meerdere partijen. Exploit zorgt ervoor dat het risico zich zeker zal voordoen, enhance verhoogt de probabiliteit of impact van het risico en reject is een besluit om het risico niet te nemen.

Fallback plans worden gebruikt wanneer het eerste antwoord op een risico niet lukt. Een bouwondernemer kan een verzekering nemen wanneer een werknemer schade berokkent bij een derde partij (het transfereren van een risico). Wanneer de schade niet wordt gedekt door de verzekering, kan de project manager een apart budget vrijmaken om dit soort risico's te dekken. Dit is dan een fallback plan. Een ander soort risico is een secundair risico dat ontstaat wanneer een antwoord op een risico wordt geïmplementeerd. Wanneer een bouwondernemer een verzekering afsluit, bestaat er het risico dat dit contract minder punten dekt dan bij andere verzekeraars. Het secundaire risico is dan dat minder schadegevallen door deze verzekering worden gedekt.

Het is nuttig om al deze manieren te kennen hoe je op een risico kan reageren, maar in de praktijk prevaleert vooral het gezond verstand. Meestal volstaat het om naar de oorzaak van een risico te kijken om te bedenken hoe je hier op kan reageren. Verreweg de meeste risico's zijn gerelateerd aan mogelijke ongemakken in een project of de beperkingen van de triple constraints (budget, scope en tijd). Er bestaat geen toverformule om een vlekkeloze implementatie van een antwoord op een risico te garanderen, maar een gestructureerde aanpak kan al veel helpen. Gebruik het risk register actief om een antwoord te formuleren, zodat iemand het antwoord ook daadwerkelijk kan implementeren. Achteraf kan het risk register worden gebruikt om te verifiëren of de persoon in kwestie daadwerkelijk actie heeft ondernomen. Dit neemt niet veel tijd in beslag, maar het is vooral een kwestie om een projectteam hier op te trainen, zodat het routine wordt.  

Communiceren en opvolging
Wanneer een antwoord op een risico is geïmplementeerd, betekent dit niet het einde van dit risico. Er moet immers gecontroleerd worden dat de actie daadwerkelijk heeft geholpen. Meten is weten en dat geldt zeker bij deze controles. Project managers zijn misschien iets te dol op metrieken, maar in dit geval is het wel een absolute noodzaak. Wanneer er geen metrieken worden gebruikt, bestaat er immers het gevaar dat een gevolg van een risico is weggenomen, maar niet de oorzaak. Metrieken kunnen niet altijd gebruikt worden, maar voor risico's gerelateerd aan de triple constraints is dit meer dan wenselijk wil je een project onder controle houden. Een veel gebruikte methode is de variatieanalyse die de baselines van een project vergelijkt met de huidige waarden (bv. huidige voortgang van een project vs geplande voortgang van een project).

Projectrisico's kunnen een grote impact hebben en daarom is het handig dat elk lid van het projectteam op de hoogte is van de risico's. Een risk register geeft iedereen transparantie over de status van risico's. Risico's worden ook wekelijks besproken op project meetings, maar deze vergaderingen hebben de neiging om lang aan te slepen. Daarom is het aangeraden om enkel de meest urgente risico's te behandelen en de minder belangrijke risico's bijvoorbeeld om de twee, drie of vier weken. In de voortgangsrapporten wordt beschreven hoe risico's zijn aangepakt en wat het effect is van een actie. Zo weet de executive en/of program manager of er nog grote risico's zijn in het project. Tot slot worden de belangrijkste risico's en de antwoorden erop beschreven in een lessons learned. Zo kunnen gelijkaardige risico's in de toekomst op een gelijkaardige manier worden behandeld en hoeft een project manager het wiel niet opnieuw heruit te vinden. Natuurlijk geldt het omgekeerde ook: een lessons learned kan een waardevolle bron van informatie zijn hoe je een bepaald risico aanpakt.

PMP vs Prince2

Belang van project management
Bedrijven kunnen talloze vormen aannemen. Dat is normaal als je de grootte en variërende graad van complexiteit in achting neemt. Toch kunnen bedrijven in slechts drie hokjes worden gestopt als we hun organisatievorm bestempelen: functionele organisatie, matrixorganisatie of projectorganisatie. De organisatievorm wordt bepaald door de mate van betrokkenheid van project management in de organisatie. Dat is niet verrassend want voor veel organisaties zijn projecten hun levensader. Denk maar aan het bouwen van een nieuw flatgebouw, het organiseren van de Olympische Spelen, de lancering van een nieuw product of de ontwikkeling van een nieuwe film. Het zijn allemaal voorbeelden van projecten die geld in het laatje moeten brengen.

Maar wat is een project nu eindelijk? Een project is een tijdelijke samenwerking tussen verschillende entiteiten (departementen in een firma, maar ook verschillende firma's) om een uniek product, dienst of resultaat te creëren. Een project werkt met een (geschatte) start- en einddatum, heeft als doel om verandering teweeg te brengen en heeft last van onzekerheid. De startdatum van een project kan immers vast staan, maar niemand zal kunnen garanderen dat de voorziene einddatum wordt gerespecteerd. Dit zien we bijvoorbeeld maar al te vaak aan wegenwerken die langer duren dan de borden aankondigen.

De prins en de pooier
In de wereld van project management zijn er twee dominerende methodologieën: PMP en Prince2. De PMI (Project Management Institute) is een Amerikaanse non-profit organisatie die het gebruik van project management evangeliseert en richtte daarom in 1984 het PMP (Project Management Professional) certificaat op. Met dit certificaat kunnen project managers zich onderscheiden door aan te tonen dat ze de (theoretische) basis van project management onder de knie hebben. Prince2 is een generieke project management methodologie die door het Office of Government Commerce werd ontwikkeld en met succes werd gebruikt bij de Britse overheid.

Hoewel PMP en Prince2 op het eerste gezicht nagenoeg hetzelfde lijken, is er nochtans een grondig verschil tussen de twee. PMP gebruikt de PMBoK (Project Management Body of Knowledge), het boek met daarin al de terminologie, als een verzameling van best practices die de project manager kan gebruiken om sturing  te geven aan een project. Stricto sensu is PMP zelfs geen methodologie omdat het niet voorschrijft welke methoden je moet gebruiken. Dat staat in schril contrast met Prince2 dat over een rigoreus procesmodel beschikt dat voorschrijft hoe een project moet worden ingericht.

Certifiëren
Beide projectmethodologieën houden er dus een ander uitgangspunt op na en dat merk je ook aan de voorwaarden om te certifiëren. Om het PMP certificaat te behalen moet je aan een aantal voorwaarden voldoen: je moet minstens 3500 uren ervaring hebben in het leiden van projecten in alle projectdomeinen wanneer je over een bachelordiploma of hoger beschikt  (indien niet stijgt dit aantal naar 7500 uren) en je moet 35 uren les hebben gevolgd bij een door het PMI erkende instelling. Kandidaten die zich willen certifiëren worden soms gecontroleerd en moeten kunnen bewijzen dat de vermelde ervaring daadwerkelijk klopt. Het PMI heeft ook een ander certificaat, CAPM (Certified Associate Project Managemer), dat minder strenge voorwaarden hanteert: 1500 uren (algemene) ervaring en 23 uren les volgen bij een erkende instelling. Dit certificaat geniet echter veel minder aanzien en bekendheid dan PMP en verreweg de meeste kandidaten gaan onmiddellijk voor het PMP certificaat.

Prince2 werkt met verscheidene certificatieniveaus: Foundation, Practitioner en binnenkomt komt daar ook Professional bij. Om één van deze certificaten te behalen, moet je je niet voldoen aan bepaalde voorwaarden. Je hebt dus geen ervaring nodig als project manager en je moet ook geen les volgen bij een erkende instelling. Dit zorgt er voor dat met name Prince2 Foundation een geliefkoosd certificaat om te behalen is, omdat je door middel van zelfstudie alles kan leren. Toch volgen de meeste kandidaten een driedaagse cursus om alles te leren. Om het Practitionercertificaat te behalen moet je ook het Foundationcertificaat hebben behaald, maar moet je verder niet aan andere voorwaarden voldoen. Daardoor zijn de Prince2 Foundation- en Practitionercertificaten erg populair geworden, ook bij mensen die geen project manager zijn, waardoor de waarde van de beide certificaten wordt uitgehold. Daarom wordt er binnenkort een derde niveau opgericht: Prince2 Professional. Kandidaten worden gedurende twee dagen en één avond getest op hun praktische kennis van Prince2. In plaats van theoretische kennis, gaat het hier om hoe je Prince2 in de praktijk gebruikt zoals het schrijven van een communicatieplan of het maken van een product breakdown structure.    

Het Prince2 Foundationcertificaat blijft levenslang geldig, maar de certificaten voor PMP en Prince2 Practitioner blijven slechts een tijd geldig. Het PMP-certificaat blijft drie jaar geldig en om het te verlengen moet je durende deze periode 60 PDU's opbouwen. PDU is een afkorting van Professional Development Unit en zo'n PDU bewijst dat je een uur (of meer) hebt gespendeerd aan het uitbreiden of uitoefenen van kennis in project management. Er zijn verscheidene manieren om PDU's te behalen: het beroep van project manager uitoefenen, het bijwonen van meetings van regionale chapters, opleidingen volgen, webinars volgen, presentaties geven, enzovoort. Het Prince2 Practitionercertificaat blijft vijf jaar geldig en om dit te verlengen moet je tussen drie en vijf jaar na het behalen van je certificaat een vernieuwingsexamen leggen. Als je hierin slaagt, behoud je terug vijf jaar de status van registered practitioner.

Examinering
Er zijn een heleboel mensen met een Prince2 Foundationcertificaat en dat is geen toeval. De slagingspercentages voor het Foundationexamen liggen boven negentig procent. Dit komt omdat het Foundationexamen relatief eenvoudig is om op te lossen. Het één uur durende multiple choice examen bestaat uit 75 vragen en je moet de helft of meer scoren om te slagen in het examen. Het Practitionerexamen is een stuk pittiger. Het is weliswaar open boek, maar de manier van examineren is een stuk complexer. Vooral de reason-assertionvragen kunnen een fikse uitdaging bieden. Ook is het erg belangrijk om de tijd in het oog te houden, want de 2,5 uur die je krijgt, zal je zeker nodig hebben. Het slagingspercentage voor het Practitionerexamen ligt rond de 65 à 70 procent.

Het PMP-examen is net zoals het Prince2 Foundationexamen multiple choice, maar bevat veel meer leerstof. Voor het Prince2 Foundationexamen volstaat het om een tien tot vijftien uren te leren. Voor het PMP-examen mag je echter rekenen op een veelvoud van dit aantal: 150 tot 200 uur. Het examen zelf duurt ook een stuk langer: je krijgt vier uur om tweehonderd vragen op te lossen. Het slagingspercentage wordt niet meegedeeld door het PMI, maar ligt vermoedelijk in de buurt van 65 procent.

Prince2
De structuur van Prince2 bestaat uit zeven principes, zeven thema's en zeven processen.

De basisfundamenten van Prince2 zitten in de zeven principes, want die laten toe om Prince2 op een universele manier toe te passen op elk project. Deze zeven principes zijn:

1. Continued business justification;
2. Learn from experience;
3. Defined roles and responsibilities;
4. Manage by stages;
5. Manage by exception;
6. Focus on products;
7. Tailor to suit the project environment.

Deze zeven principes moeten continu worden toegepast, want anders wordt het project Prince2 in name only (PINO) en dit is de reden waarom talloze projecten zijn gefaald. De zeven thema's zijn aspecten in project management die constant aandacht vragen. Dit zijn dus met andere woorden de deelgebieden van een project. Prince2 identificeert zeven thema's:

1. Business case;
2. Organization;
3. Quality;
4. Plans;
5. Risk;
6. Change;
7. Progress.

Deze zeven thema's lopen als een rode draad door het procesmodel van Prince2. Neem bijvoorbeeld de business case. De business case is een document dat in grote lijnen samenvat waarom een project wordt opgestart en wat het einddoel is. Volgens het Prince2 procesmodel wordt op het einde van elke stage de vraag gesteld of dat het project nog moet worden verdergezet of niet. Dit wordt gedaan om te verifiëren of dat de oorspronkelijke doelstellingen die zijn samengevat in de business case zullen worden gerealiseerd door het project. Zo wordt een thema (de business case) gelinkt met een principe (continued business justification) en het procesmodel (manage stage boundary). 

Wat Prince2 echter verschillend maakt met PMP is het procesmodel dat een generieke aanpak beschrijft hoe je een project moet inrichten. Dit procesmodel bestaat andermaal uit zeven processen:

1. Starting up a project;
2. Initiating a project;
3. Directing a project;
4. Manage a stage boundary;
5. Controlling a stage;
6. Managing product delivery;
7. Closing a project.

Deze zeven processen beschrijven hoe een project wordt gestart tot het moment waarop het wordt afgesloten. De kracht van dit procesmodel is dat het universeel op elk type project kan worden toegepast, of het nu gaat om het organiseren van een festival tot het introduceren van een nieuw type vliegtuig. Dit model schrijft exact voor wat je moet doen en daarom wekt Prince2 de indruk op dat het nogal bureaucratisch is. Dat is gedeeltelijk waar, want het aantal deliverables en documenten dat tijdens een project wordt gegenereerd is best veel. Daarom hebben project managers soms de neiging om stappen over te slaan wat kan leiden tot falen van het project. 

Als antwoord hierop benadrukt Prince2 het principe van tailoring. Het is belangrijk dat een project wordt aangepast aan de projectomgeving. Een kleiner project kan bijvoorbeeld de processen starting up a project and initiating a project in één keer uitvoeren, deliverables zoals een risk register, daily log en issue log kunnen worden samengesmolten tot één daily log en de manier waarop hoe change requests worden behandeld kan informeler worden ingericht. Dit is tegelijk de kracht en uitdaging in het gebruik van Prince2 op de werkvloer. 

PMP

Waar Prince2 voornamelijk een Brits feestje is, is PMP vooral populair in de VS. Dat mag geen wonder zijn, want het PMI is namelijk een Amerikaans instituut. Aangezien ze in de VS tuk zijn op afkortingen, is het wellicht nuttig om de drie reeds gebruikte afkortingen toe te lichten:

• PMI: Project Management Institute. Dit is het instituut dat het beroep van project management uitdraagt naar de buitenwereld. Het PMI houdt zich bezig met het inrichten en beheren van verscheidene certificaten en het beren van standaarden gebruikt in de wereld van project management.
• PMP: Project Management Professional. Dit is één van de certificaten die worden ingericht door het PMI. Het is verreweg het meest populaire certificaat onder de paraplu van PMI en geniet vooral in de VS aanzien. Andere certificaten zoals CAPM, PgMP, PMI-RMP zijn een stuk minder populair. 
• PMBoK: Project Management Body of Knowledge. Dit is het handboek van het PMI voor project management en hierin worden de standaarden voor project management beschreven. Veel examenvragen uit het PMP-examen komen uit dit boek, maar het bevat niet alle leerstof. Zaken zoals bijvoorbeeld conflict management en leiderschapsstijlen komen niet aan bod in dit boek, terwijl het wel gekend moet zijn voor het PMP-examen. 

Het grote verschil met Prince2 is dat PMBoK geen processen voorschrijft, maar een verzameling is van best practices. Het is aan de project manager om alles te integreren in de projectomgeving. De indeling van de processen gebeurt net iets anders dan bij Prince2. PMBoK kent vijf process groups: 

1. Initiating process group;
2. Planning process group;
3. Executing process group;
4. Monitoring and controlling process group;
5. Closing process group.

Het verschil tussen de vijf process groups van PMBoK en de zeven processen van Prince2 is dat de eerste een richtlijn is. Het schrijft niet precies voor wat je moet doen, terwijl de zeven processen van Prince2 dat wel doen. Een ander verschil is dat de vijf process groups continu in een project worden gebruikt. De iniating a project process group wordt ook tijdens het project gebruikt, terwijl de iniating a project proces van Prince2 slechts eenmalig bij het begin van een project plaatsvindt. 

Daarnaast kent PMBoK ook negen knowledge areas:

1. Project integration management;
2. Project scope management;
3. Project time management;
4. Project cost management;
5. Project quality management;
6. Project human resources management;
7. Project communication management;
8. Project risk management;
9. Project procurement management. 

Als je de knowledge areas van PMBoK vergelijkt met de thema's van Prince2 zie je opvallend veel gelijkenissen. Ze hebben beide quality en risk gemeenschappelijk en ook tussen de andere factoren zijn er gelijkenissen te noteren. Zo is bijvoorbeeld het change thema van Prince2 verwoven in de project integration management knowledge area van PMBoK. PMBoK gaat echter wel verder dan de thema's van Prince2, want het handelt ook over human resources en procurement. 

Het grote verschil tussen de twee is de praktische kant van project management. Prince2 legt de nadruk op wat je moet doen tijdens een project, terwijl PMBoK een verzameling van tools en technieken biedt dat uitlegt hoe je bepaalde dingen uitvoert. Tijdens de verplichte PMP-opleiding zie je zaken zoals het berekenen van earned value, het maken van een time schedule, budgetteren van een project en het beheren van risico's. De aard van de PMP en Prince2 certificaten is totaal verschillend en daarom zijn ze ook perfect complementair aan elkaar. 

Verschillen en gelijkenissen

Maar wat zijn juist de sterke en zwakke punten van beide methodologieën? Hier volgt een overzicht dat een antwoord probeert te bieden op deze vraag:

Thema	Prince2	PMBoK
Organization	Alle rollen en verantwoordelijkheden zijn duidelijk gedefinieerd en er wordt een nadruk gelegd op management by exception. Dit wil zeggen dat elke leidinggevende rol een budget krijgt met bijhorende toleranties. Wanneer deze toleranties dreigen te worden overschreden moet naar de hogere in hiërachie worden gestapt (bijvoorbeeld de project manager stapt naar de executive)  waarop de laatste een beslissing neemt.	De rol van project sponsor en project manager worden besproken, maar men gaat niet verder in op de relatie tussen de twee. Het verschil tussen portfolio management en project management office wordt ook verduidelijk, waar Prince2 deze zaken nauwelijks of niet vermeldt.
Business case	De business case staat centraal bij het project en bij elke belangrijke mijlpaal wordt getoetst of de business case al dan niet nog steeds zakelijk gerechtvaardigd is. Prince2 gaat ervan uit dat de project manager uit de kant van business komt en stelt het belang van de business voorop.	De business case wordt vermeld als één van de redenen waarom een project kan worden opgestart, maar geniet verder geen bijzondere interesse bij PMBoK. PMBoK richt zich ook meer op het perspectief van de supplier en houdt geen rekening met de zakelijke rechtvaardiging van een project.
Quality	Prince2 integreert quality control, quality assurance en quality planning tot één geheel en schrijft voor hoe je kwaliteit moet beheren tijdens het project.	PMBoK legt de nadruk op tools en technieken die uit Six Sigma komen die je kan gebruiken om kwaliteit te meten.
Risk	Prince2 heeft voornamelijk de mosterd gehaald bij PMBoK en er zijn weinig verschillen op dit vlak tussen de twee methodologieën. Prince2 heeft het concept wel verbeterd door meer mogelijkheden te bieden op hoe je een risico kan beantwoorden.	Hier wordt op een uitegebreide manier uitgelegd uit hoe risico’s kunnen worden gepland, geïdentificeerd, gemeten en behandeld. De nadruk ligt andermaal op de technieken en tools die kunnen gebruikt worden bij deze processen.
Change	Net zoals bij risk is er niet veel verschil tussen de twee methodologieën op dit vlak. Prince2 biedt wel een duidelijk proces hoe je change behandelt.	Perform integrated change control is het belangrijkste proces bij PMBoK en legt uit hoe je change behandelt. De samenhang met andere processen is echter een stuk onduidelijker dan bij Prince2.
Progress	Door de duidelijke rolverdeling en het werken met toleranties is het eenvoudig om de progress te meten, op te volgen en actie te ondernemen wanner toleranties dreigen te worden overschreden. Er wordt echter weinig aandacht geschonken aan hoe je de progress juist meet.	PMBoK is heel erg duidelijk hoe je de de vooruitgang van scope, kosten en tijd kan meten,  maar spendeert dan weer minder aandacht aan hoe je met toleranties moet werken.
Plans	Dit is de vreemde eend in de bijt bij Prince2, want het kan bezwaarlijk een apart thema worden genoemd. Prince2 legt uit hoe je met een project, stage en team plan kan werken. Tevens wordt hier het principe van product-based planning uitgelegd.	Er wordt bij PMBoK geen bijzondere aandacht besteed aan planning, maar maakt het deel uit van scope management. De creatie van een project management plan en subplannen wordt op een duidelijke manier uitgelegd.
Procurement	Wordt niet behandeld door Prince2.	Wordt op een uitvoerige manier behandeld door PMBoK. Het nadeel is wel dat het procurementproces enkel wordt bekeken vanuit het perspectief van de partij dat een project outsourcet.
Human resources	Wordt niet behandeld door Prince2.	PMBoK behandelt onderwerpen zoals het organiseren van het project team, motiveren van personen, oplossen van conflicten en het geven van beoordelingen.

Zoals uit dit tabeloverzicht blijkt, bestaat de kracht van Prince2 erin dat het een duidelijk, gestructureerd proces aanbiedt hoe je een project kan inrichten. PMBoK is hierop complementair met een praktisch overzicht van tools en technieken. Toch zijn er een aantal gebieden waarop de ene methodologie beter scoort dan de andere. Prince2 scoort bijvoorbeeld goede punten op de duidelijke rollen en verantwoordelijkheden in de projectomgeving, hoe change requests moeten worden behandeld en de manier waarop hoe met risico's wordt omgegaan. PMBoK daarentegen biedt een meerwaarde bij het opvolgen en beheren van de zogenaamde triple constraint (time, scope en cost), legt uit hoe je kwaliteit kan meten en beheren en behandelt ook procurement en human resources waar Prince2 deze onderwerpen niet behandelt.

Conclusie
Het is dus moeilijk om te zeggen welke methodologie beter is dan de andere, aangezien beide complementair zijn en ze verschillende uitgangspunten hebben. Toch ben ik geneigd te zeggen dat het PMP-certificaat meer waar voor je geld biedt dan het Prince2 Practitionercertificaat. De leerstof voor het PMP-certificaat is een stuk uitgebreider dan dat voor het Prince2 Practitionercertificaat en biedt zowel een verzameling van tools en technieken als een framework voor het inrichten van een project. Prince2 richt zich voornamelijk op dat laatste en het mag gezegd worden dat het dit ook beter doet. PMBoK biedt ook een procesmodel voor het inrichten van een project, enkel is het niet zo volledig en duidelijk als dat van zijn naaste concurrent.