Redenen voor gestructureerd projectmanagement

PRINCE2 wordt beschreven als een methode voor projectmanagement die gebaseerd is op "best practice" ofwel toepassingen die zich in de praktijk hebben bewezen. Er is daarbij een grondige analyse gemaakt van problemen die zich in de praktijk rondom projectmanagement voordoen. Structurele oplossingen die aan deze problemen het hoofd bieden, zijn vervolgens in de methode verwerkt.

Hierbij moet ik opmerken dat ik de term methode te beperkt vind voor PRINCE2. Ik heb het liever over een manier van denken, een integrale aanpak. Dit is dan ook de reden waarom ik een tegenstander ben van de manier waarop veel organisaties PRINCE2 invoeren: als templates of als gemeenschappelijke taal. Hiermee wordt de kracht uit de aanpak gehaald en vervalt het geheel tot bureaucratische rompslomp.

Waarom falen projecten?

Vrijwel elke reden voor falende projecten is terug te voeren op de rechtvaardiging van het project of in (enigszins modieuze) PRINCE2 terminologie: de Business Case. Een aantal redenen is hieronder beschreven. Allemaal "open deuren" en voor de hand liggende, herkenbare redenen. Maar helaas wel de dagelijkse praktijk.

Gebrek aan rechtvaardiging en gebrekkige doelstelling

Tijdens een bezoek aan een grote bank, bleek dat na invoering van PRINCE2 werd nagedacht over de rechtvaardiging van projecten. Van elk project moest de Business Case bekend zijn. Het resultaat was dat 30% van de projectvoorstellen niet meer werd goedgekeurd. Een enorme besparing die waarschijnlijk nog groter zou kunnen uitvallen en die zeker in vrijwel elke organisatie te behalen is. Elke organisatie die ik van binnen heb mogen bekijken, spendeert enorme bedragen en heel veel tijd aan projecten die om politieke redenen of zelfs vanwege duidelijk onzinnige redenen worden gestart. Dit komt bij het opstellen van een expliciete Business Case snel aan het licht. En omdat PRINCE2 uitgaat van een herkenbare projecteigenaar die tijdens het project verantwoordelijk is voor de Business Case (en dus zijn / haar nek in de strop steekt bij onvoldoende rechtvaardiging), verkleint dit de kans op een slechte start.

Voordat het project feitelijk van start gaat, kent PRINCE2 een proces waarin Business Case en projectdoelstellingen beschreven worden. Hierbij is het van groot belang dat de doelstellingen ook beschreven worden (Project Brief) in termen van kwaliteitsverwachting en acceptatiecriteria. Kwaliteit is immers in drie simpele regeltjes te vatten:

  1. Beloof wat je gaat doen (planning);
  2. Doe wat je beloofd hebt (productie);
  3. Toon aan dat je gedaan hebt wat je beloofd hebt (verantwoording, rapportage).

Een tegenwerping is vaak dat je "pragmatisch" moet zijn, dus maar zonder duidelijke doelstellingen aan de slag. Tegelijkertijd wordt er wel om een planning gevraagd! De planning is dus nergens op gebaseerd en de situatie is erger dan werken zonder planning. De term "pragmatisch" is hier synoniem voor amateuristisch...

Wanneer een project op gang is, verandert de omgeving en daarmee de Business Case en de projectdoelstellingen (en dus de planning). Lastig, maar niet te vermijden. De Business Case kan dus geen "dood" document zijn, maar wordt tijdens een beheerst project bijgewerkt en getest op geldigheid. We kennen allemaal projecten die doorgaan omdat voortijdig stoppen gelijk zou zijn aan falen. Maar als een project ooit wel, maar nu niet meer te rechtvaardigen is, waarom zou je er dan nog tijd en geld in investeren?

Geen expliciete project eigenaar en projectorganisatie

Veel projecten lijden onder een matige organisatie. Meestal is er een stuurgroep bepaald maar de verantwoordelijkheden in de stuurgroep zijn vaak niet vastgesteld en er is ook niet bepaald wie uiteindelijk verantwoordelijk is. Dit heeft als gevolg dat de projectmanager dan maar verantwoordelijk wordt gesteld. Maar als een project tijdelijk en uniek is (twee belangrijke kenmerken van een project), is het dan wel zo verstandig om de projectmanager zo veel verantwoordelijk te geven? Het gaat tenslotte om de creatie van een verandering waarmee de lijnorganisatie verder kan. Dit vraagt dus om een projecteigenaar met verantwoordelijkheden die een sterke basis heeft in de lijnorganisatie.

Als ik tijdens een workshop of training voor een bureaucratische organisatie aan iemand vraag wie de projecteigenaar is, wordt vaak verwezen naar een afdeling. Een ernstige fout; om een project te laten slagen dient er een duidelijke verantwoordelijkheid aanwezig te zijn. Dus nooit een afdeling, maar een persoon als projecteigenaar.

Een andere valkuil is het werken met de verkeerde project eigenaar. Erg vaak wordt een financieel verantwoordelijke aangesteld. In een bedrijf waar ik veel training en consultancy heb verricht, bleek de controller de sponsor van elk project. Hier spelen twee fundamentele problemen.

  1. Wanneer iemand geen andere interesse in een project heeft dan een financiële, zal hij / zij zich niet opstellen als verantwoordelijke. Een controller als project eigenaar is dus prima, maar alleen voor projecten waar de controller verantwoordelijk gesteld kan worden voor- en geïnteresseerd is in het eindresultaat, een financieel project dus.
  2. De term sponsor is zeer gevaarlijk. Wie zijn de sponsors van Ajax of Feyenoord? Bepaalt de sponsor de opstelling? Laten de trainers van deze clubs zich aansturen door de sponsors? Het lijkt op het eerste gezicht semantiek, maar het is essentieel. Een sponsor zal niet snel de verantwoordelijkheid nemen die nodig is om een project goed aan te sturen. Er moet iemand zijn die het eigenaarschap van het project en de bijbehorende Business Case op zich neemt. De term sponsor moet worden afgeschaft.

Als variant op dit thema zie je ook vaak dat er wel een project eigenaar is, maar dat deze persoon nauwelijks of te weinig macht heeft. Voor elke beslissing moet hij / zij door een langdurig traject om toestemming te vragen voor het besteden van budget. En vaak moet deze discussie gevoerd worden met iemand zonder al te veel (inhoudelijke) belangstelling voor het project: meestal een financiële staffunctionaris. Dit leidt tot een onwerkbare situatie waardoor het project verlamd wordt en de focus niet op het resultaat maar op het budget gelegd wordt. In discussies over de Betuwelijn zag je dit punt ook verschijnen. Het Ministerie van Financiën had een grote mate van inbreng in discussies die ver buiten haar competentie lagen of zouden moeten liggen.

In veel projecten wordt ook de (interne) leverancier gezien als project eigenaar. In ICT projecten wordt vaak de ICT manager of CIO gezien als de project eigenaar en de verantwoordelijke voor het budget. Maar wanneer het gaat om een project dat de lijnorganisatie verandert, is het toch niet meer dan logisch dat daar ook de aansturing en budgetverantwoordelijkheid wordt belegd. Zij hebben het belang en zijn de enige die de rechtvaardiging voor het project kunnen bepalen.

In de PRINCE2 aanpak is het essentieel dat in de stuurgroep (Project Board) drie belangen zijn vertegenwoordigd.

  1. Eén persoon is verantwoordelijk voor de Business Case en is daarmee de eigenaar van het project: de Executive
  2. Ook de belangen van degenen die met het resultaat van het project aan de slag gaan, moet zijn vertegenwoordigd (Senior User). Is het resultaat wel werkbaar? Kan de verwachte toegevoegde waarde bereikt worden met de resultaten van het project? Hiermee is deze rol dan ook verantwoordelijk voor de uiteindelijke oplossing.
  3. Daarnaast is het ook van belang dat de leverancier (Senior Supplier) van het project bij beslissingen een stem heeft. Kan de leverancier het wel tegen de gestelde voorwaarden leveren? De Senior Supplier is daarmee binnen de Project Board verantwoordelijk voor de kwaliteit van de uiteindelijke oplossing.

Overigens zijn dit verenigbare rollen die ook door meerdere personen zijn in te vullen, zolang er maar één expliciete Executive is. Het is dus niet zo dat een Project Board uit minimaal drie personen moet bestaan. Een klein project kan een Project Board hebben waarin één of twee personen alle rollen bezetten terwijl in een groot project de rollen van Senior User en Senior Supplier door meerdere personen ingevuld worden. Balans is hierbij natuurlijk van belang. Een Project Board bestaande uit een Executive, twee Senior Users en negen Senior Suppliers kan onwerkbaar blijken. De leveranciers zullen de agenda gaan bepalen door hun numerieke overwicht. Binnen sommige vergaderculturen bestaat de neiging om vergaderingen met een groot aantal mensen te houden. Een grote Project Board heeft als risico dat de besluitvaardigheid wordt aangetast.

Een consequentie van het bovenstaande is dat een projectmanager bij voorkeur niet afkomstig is uit de organisatie van de (interne) leverancier. Klant en leverancier hebben tegengestelde belangen. Simplistisch gesteld bestaat de omzet van de (interne) leverancier uit de kosten van het project en daarmee hebben klant en leverancier tegenstrijdige Business Cases voor het project. Dit brengt de projectmanager, wanneer afkomstig uit de organisatie van de leverancier, onherroepelijk in problemen: wiens belangen behartigt hij / zij? De belangen van de klant of die van de werkgever of van de eigen lijnmanager?

Helaas wordt in de meeste projectaanpakken die zijn gebaseerd op het traditionele delivery model geen of nauwelijks aandacht besteed aan dit soort fundamentele, maar ook logische zaken. Ook consultancy firma's die zich voorstaan op hun professionele projectmanagement, gaan op het belang van een goede projectorganisatie nauwelijks in. Ook de PMBoK stelt op dit punt ernstig teleur. Het herkennen van het belang van een goede fundament voor een projectorganisatie is een eerste stap naar meer beheersbaarheid en effectiviteit.

Onvoldoende afbakening

Hierboven heb ik al de nodige aandacht besteed aan het belang van een goede rechtvaardiging, Business Case, voor een project. Afbakening is van groot belang. Maar ook zie je vaak dat in een project meerdere belangen spelen die in een project niet zijn te verenigen. En voorbeeld is de uitrol van een nieuwe hardware configuratie die binnen een groot internationaal concern is vastgesteld. Op lokaal niveau moesten bij elke lokale nationale divisie onder eigen verantwoordelijkheid werkzaamheden worden uitgevoerd waarbij het concern controle uitvoerde. Onder bovenstaande mechanismen valt een dergelijk project niet uit te voeren. Zo is er lokaal geen goede Business Case en dus Executive aan te wijzen. Het is immers een traject waaraan men lokaal weinig waarde maar globaal heel veel waarde toekent. Dit valt op te lossen door het geheel te zien als een programma dat de lokale projecten aanstuurt. Hiermee haal je de rechtvaardiging en verantwoordelijkheid voor lokale projecten weg bij de lijnorganisatie en wordt de aansturing aanmerkelijk verbeterd.

Onvoldoende kwaliteit en kwaliteitsborging

In veel projecten bepaalt de (interne) leverancier de kwaliteit. Testen worden uitgevoerd door hun eigen experts onder hun eigen testmethodes. En daarmee gaat het vaak mis. De klant is verantwoordelijk voor het eindresultaat en de leverancier stemt in met de gevraagde kwaliteit. Hiermee is uiteindelijk de klant verantwoordelijk voor de het testen en is de leverancier verantwoordelijk voor het aantonen van de kwaliteit aan de klant.

Testen vind vaak achteraf plaats waarbij er vooraf veel niet of onvoldoende is gespecificeerd wat de acceptatiecriteria zijn. Maar logica zegt dat wanneer je vooraf niet specificeert het onmogelijk is te testen en te plannen en dus te beloven wat je gaat produceren. Onder de hierboven gestelde regels lever je dus per definitie geen kwaliteit. Tenzij van te voren uitdrukkelijk is vastgelegd dat er voor het project hoge toleranties zijn in termen van tijd, geld en kwaliteit.

Kwaliteit is dus niet iets wat alleen achteraf valt te controleren. Kwaliteit wordt bepaald door specificatie vooraf.

Onvoldoende communicatie met de klant van het project

Een logisch resultaat van wat ik al beschreven heb onder projectorganisatie en kwaliteit. Projecten worden vaak gestuurd en uitgevoerd door specialisten en niet door en met inbreng van de klant. Werken volgens de filosofie van de Customer / Supplier omgeving vergroot de kans op een succesvol project aanmerkelijk. De focus van een project verschuift van intern naar de toegevoegde waarde van de klant.

In veel advertenties waarin men vraagt om een projectmanager, wordt de nadruk gelegd op de term "customer focus". Dat deze term gebruikt wordt en de hoeveelheid advertenties waarin deze term gebruikt wordt, tonen aan dat er een groot probleem juist in deze hoek schuilt. Overigens vind ik "customer focus" onvoldoende. Een goede projectmanager is "customer driven".

Overigens kreeg ik ooit bij een bekende consultancy firma de klacht dat ik onvoldoende aan "omgevingsmanagement" zou doen. Mijn visie is dat het "omgevingsmanagement" daar volledig was gebaseerd op toepassing van het traditionele delivery model. Daarmee was "omgevingsmanagement" nodig voor crisisbeheersing omdat er zoveel problemen in het project ontstonden die moeten worden recht gepraat. Ik doe liever aan het voorkomen van een crisis en hanteer daarvoor een afwijkende aanpak die toch ook voor veel problemen heeft gezorgd, maar dan met mijn werkgever.

Nadruk op aanbod, niet op vraag

Ook hier is, na het bovenstaande, weinig nieuws meer te melden. Helaas worden veel projecten uitgevoerd omdat het technisch een uitdagend project is, niet omdat de focus ligt op toegevoegde waarde.

Een aantal jaren geleden besloot een vooraanstaand ICT consultancy bedrijf om een nieuw CRM systeem in te voeren. Helaas werd de verantwoordelijkheid belegd bij een stafafdeling en niet bij de Business die belang zou kunnen hebben bij deze oplossing. Business Case en projectorganisatie werden totaal verwaarloosd en het project eindigde in een mislukking. Het geïnstalleerde systeem bleek technisch, maar vooral functioneel niet goed te werken en werd na korte tijd vervangen. Niet alleen is enorm veel tijd en geld verspild maar er vielen ook persoonlijke slachtoffers: een aantal onschuldige medewerkers werd gestraft, zoals dat zo vaak gaat bij dit soort projecten die uitlopen in politieke chaos. Overigens vertelde de leverancier (die niet betrokken was bij invoering) enige tijd na het tekenen van de contracten voor levering van de software tijdens een demonstratie dat zijn CRM software uitstekend was voor bedrijven die werkzaam waren in de industrie, maar dat de software niet geschikt zou zijn voor een ICT consultancy bedrijf. Het ICT bedrijf voerde de software in om politieke, financiële (goed contract, goedkope software) en vooral om technische (zag er mooi uit) redenen. Er lag geen goede Business Case aan ten grondslag en falen was voorspelbaar.

Vaak vraagt een klant om een projectmanager met veel kennis en ervaring op het technische vlak en van de materie waarmee het project te maken heeft. Materiekennis is ontegenzeggelijk nuttig, maar technische kennis blijkt in de praktijk vaak in de weg te staan van projectbeheersing. De projectmanager heeft de neiging om zich te gaan focussen op de inhoud en niet meer op de beheersing. Hoe vaak loopt een project fout omdat er onvoldoende technische kennis aanwezig is? Materiekennis is ook altijd in overvloed aanwezig maar wordt vaak verkeerd gebruikt. De bestaande praktijk heeft zich dus al in ruime mate bewezen: de meerderheid van projecten stelt teleur. Waarom niet eens een andere aanpak?

Onvoldoende planning en management van resources

Wanneer vooraf aan het project de doelstelling, omvang en gewenste kwaliteit niet goed worden vastgelegd, zal ook de planning binnen een project niet veel waard zijn. En daarmee is ook de planning van resources onzeker. Dit hoeft geen probleem te zijn zolang het maar expliciet gemaakt wordt en de verantwoordelijken het er mee eens zijn. Voor een deel is het principe van toegestane tolerantie hierop terug te voeren.

Wanneer dit probleem gaat spelen binnen diverse projecten, zal het toekennen en weghalen van resources veel op ad hoc basis gebeuren waardoor projecten nog meer in de problemen komen. Natuurlijk is dit probleem niet helemaal te vermijden, maar er is toch wel het nodige aan te doen. Naarmate projecten beter worden gepland zal resourceplanning op een hoger niveau beter uit te voeren zijn.

Ook de ideeën achter de Critical Chain theorie helpen hierbij.

Fixed project

Hoe vaak zie je niet een advertentie waarin wordt gevraagd om een project manager die het project zal opleveren binnen budget, tijd en kwaliteitsnormen? Dit is onmogelijk zonder tussentijdse beheerste bijstelling van deze drie aspecten. Een project is uniek en zal iets opleveren wat nog nooit eerder exact zo gedaan is. De planning is dus een voorspelling van de toekomst, al dan niet onderbouwd door ervaringscijfers die in een ander project zijn opgedaan. Helaas zijn er zeer weinig mensen die de toekomst exact kunnen voorspellen. In ieder project treden zaken op die de planning zullen verstoren. Wanneer er meer tijd en geld nodig blijkt om te corrigeren, zullen mogelijk concessies aan de kwaliteit gedaan worden om toch binnen tijd en geld te eindigen.

Het gaat er bij projectmanagement om dat ervoor wordt gezorgd dat de aspecten tijd, geld en kwaliteit (en andere aspecten) beheersbaar worden. Expliciete en tijdige beslissingen zijn van belang. Hiervoor is het noodzakelijk dat er toleranties worden toegepast: binnen welke grenzen mag de projectmanager optreden zonder escalatie naar de Project Board? Wanneer deze principes niet worden toegepast, zal de projectmanager voor elk minuscuul probleem bij de Project Board aankloppen of juist alle problemen voor zich houden met zeer grote onplezierige verrassingen tot gevolg, meestal voorzien van de nodige negatieve politiek.

Ontkennen van risico

Een bekende cabaretier heeft ooit de uitspraak gedaan: "Een optimist is een slecht geïnformeerde pessimist". Natuurlijk moet een projectmanager ervoor zorgen dat het project in gang komt en blijft, maar in veel projecten is de "can do" mentaliteit doorgeschoten. In veel projecten is het niet gewenst om over risico's te praten en wanneer dit toch gebeurt, wordt de aandrager als negatief betiteld. Een uitstekende manier om betrokken mensen te demotiveren en het project in een catastrofe te laten eindigen.

Elk project kent risico's en risico's moeten worden beheerst en niet worden ontkend. Risicobeheersing kost geld en het is niet leuk om te moeten nadenken over maatregelen die genomen moeten worden wanneer het probleem optreedt. Maar voorkomen is beter dan genezen.

Overigens ben ik er van overtuigd dat tijdens de Internet hype en de krediet crisis het ontkennen van risico's tot een kunst werd verheven. De standaardreactie in die tijd was: "doe niet zo negatief, we verdienen zo veel geld en het komt allemaal wel goed". De gevolgen voor de ICT branche en de financiële sector zijn bekend...

De oplossing voor alle problemen?

Lost toepassing van PRINCE2 al het bovenstaande op? Helaas niet. Projecten blijven door hun aard onvoorspelbaar. Maar toepassing van de beschreven principes verkleint wel de kans op falende projecten en zorgt er ook voor dat een falend project niet blijft doorsukkelen, maar op tijd gestopt wordt zodat tijd en geld niet nodeloos worden verspild.

Over de auteur

Specialist in effective change.

Accredited MSP™ and PRINCE2® trainer.

comments powered by Disqus