OVER DIT BOEK

Soms hebt u de indruk dat projectmanagers in een andere wereld leven. Snappen ze soms niet waar u mee bezig bent?

Als manager of ondernemer is uw zorg begrijpelijk, maar niet helemaal terecht. Goede projectmanagers concentreren zich op hun taken en proberen gewoon hun doelen te halen. Niets meer en niets minder. Als u wilt dat zij het grote plaatje begrijpen, dan zult u hun actief moeten begeleiden.

In dit boek leert u hoe u de voortgang van een project succesvol kunt bewaken en meer begrip kunt creëeren tussen projectmedewerkers en de rest van de organisatie. Door het stellen van de juiste vragen zullen meer projecten slagen, met beter bruikbare resultaten:

• Snappen jullie wat het doel is van dit project?

• Zijn jullie in staat om tijdig bij te sturen?

• Kunnen jullie aantonen dat het budget volstaat en de deadline wordt gehaald?

Jaap van Driel begeleidt bestuurders bij het realiseren van complexe projecten. Hij was hoofd van het Global Project Excellence Centre van Shell waar hij onderzoek deed naar de succesfactoren van projecten. Daarna is hij zijn expertise als consultant gaan inzetten voor bedrijven als Akzo-Nobel, Philips en NRGValue.

Inhoud

OVER DIT BOEK

Inleiding

Leeswijzer

VRAAG 1 • Is het wel een project?

Jaap van Driel

Waar is de projectmanager toch mee bezig?

Hoe u projectmanagers en hun teams succesvol begeleidt

Uitgeverij Haystack

www.haystack.nl

needle@haystack.nl

Auteur: Jaap van Driel

Corrector: Carolien van der Ven

Vormgeving omslag: Studio Haystack

Opmaak: Debbie Brok

Illustraties: Jille van der Veen

Figuren: Birgit van Driel

Proeflezers: Tesse van Dooren, Hedwig van Driel, Marijke Heijloo, Ruben Rammelt

ISBN: 9789461263261

NUR 800

© 2018 Jaap van Driel

Niets uit deze uitgave mag worden verveelvoudigd en/of openbaar gemaakt zonder schriftelijke toestemming van de uitgever. Hoewel dit boek met veel zorg is samengesteld, aanvaardt schrijver noch uitgever enige aansprakelijkheid voor schade ontstaan door eventuele fouten en/of onvolkomenheden in dit boek.

Inleiding

Dertig jaar geleden, toen ik als projectmanager begon, mislukten veel projecten. Sindsdien is er veel vooruitgang geboekt op het gebied van projectmanagement. Mits onder goede condities gestart en goed begeleid is er geen reden meer voor het mislukken van een project. Langzamerhand is er echter een kenniskloof ontstaan tussen enerzijds projectteams en anderzijds (business)mensen die projecten goedkeuren, aansturen en begeleiden (en die meestal de gebruikers zijn van de resultaten van een project). Dit boek is geschreven voor de mensen die niet in een projectteam zitten, maar er wel mee te maken hebben. Veel van deze mensen willen een project beter begrijpen en ook kunnen beoordelen of het goed gaat. Het feit dat over het algemeen mensen van buiten een projectteam niet begrijpen wat er in een project gebeurt, leidt vaak tot problemen, zoals projecten die niet opleveren wat verwacht wordt, projecten die niet op tijd voltooid zijn en/of projecten die duurder zijn dan verwacht.

Ik heb in mijn carrière bij zowel grote als kleine bedrijven gewerkt op het snijvlak van projectteams en businessorganisaties en ben daarbij ook verantwoordelijk geweest voor het succes van het projectportfolio binnen deze organisaties. Mijn conclusie is dat er op dit moment voldoende goede methoden en technieken zijn die projectteams kunnen gebruiken (Scrum, PMbok, Prince2), maar dat bij mensen buiten de projecten de juiste kennis ontbreekt om goed te begrijpen wat er gebeurt.

Bij een groot internationaal bedrijf heb ik meegewerkt aan de analyse van honderden projecten van zeer klein tot zeer groot. Het verschil tussen wel en niet zo goed lopende projecten was altijd terug te voeren op een aantal specifieke thema’s. Daarna heb ik bij grote en kleine bedrijven gewerkt en deze thema’s bleken universeel te zijn. Wat onder andere steeds naar voren kwam, was dat het nodig is om een project te beschouwen als onderdeel van een businessstrategie. Dat betekent dat de voorbereiding van een project, de beslissing welk project niet en welk project wel gedaan moet worden, de uitvoering van een project, het verhelpen van de kinderziekten van een project en het behalen van de benefits van een project als een samenhangend geheel moeten worden gezien.

Projectmanagementmethoden behandel ik nauwelijks in dit boek. Ze hebben meestal betrekking op (een deel van) de uitvoering van een project en er is niet één methode die voor alle typen projecten geschikt is, al doet de projectmanagementmarketing soms anders vermoeden.

Er zijn goede methoden en technieken voor het doen van projecten. Toch zijn projecten vaak minder succesvol dan verwacht. Dit komt niet alleen doordat ze slecht worden uitgevoerd, maar ook doordat er geen goede voorbereiding en selectie wordt gedaan. Gedurende het project zijn er veranderingen en verbeteringen nodig, die er weer voor zorgen dat het project langer duurt en duurder wordt. Als het project uitbesteed is, dan is dit een mooie gelegenheid om de leverancier de schuld te geven en voor je het weet, wordt de meeste energie besteed aan de schuldvraag in plaats van aan het goed laten lopen van het project. Als de deadlines dan niet kunnen worden verschoven, zullen vaak de deliverables niet zijn afgemaakt.

Bij de opening van de Cité de la Musique in 2015 in Parijs weigerde de architect (Jean Nouvel) aanwezig te zijn. Ik was er tijdens een concert in de zomer van 2015 en niet alleen lag het bouwgruis nog op de stoelen, maar op veel plekken was zichtbaar dat het gebouw niet af was. Zulke situaties zijn helaas niet ongebruikelijk.

Na afloop van het project, als de deliverables1 geaccepteerd zijn, wordt het projectteam ontbonden, maar zijn de baten nog niet gerealiseerd en de kinderziekten niet verholpen; bij grote projecten kan het wel jaren duren voordat de baten worden gerealiseerd.

Een van de hoofdoorzaken van het mislukken van projecten is de ‘we zetten wel een vinkje’-benadering. De projectmanager bereidt de antwoorden voor, op het eerste gezicht zien die er goed uit en zonder volledig begrip wordt er een vinkje gezet. Het resultaat is dat besluiten niet goed worden begrepen en dat het project (vaak) met heel andere resultaten komt dan aan het begin werd verwacht. Het is beter om een beperkt aantal onderwerpen goed te begrijpen dan om van alle aspecten een beetje te begrijpen.

De vijftien vragen

Mijn ervaringen met portfolio- en projectmanagement hebben geleid tot het opstellen van vijftien vragen. Met behulp van de antwoorden op deze vragen kunnen de beste projecten worden gekozen, worden projecten pas gestart als er aan de voorwaarden voor succes is voldaan en worden nadat de projecten zijn afgesloten, de baten gerealiseerd.

Als er een kundige projectmanager is die het project en het projectteam leidt, is het voor stakeholders – waaronder de stuurgroepleden – voldoende om de antwoorden op de vijftien vragen te begrijpen. Met deze antwoorden kunnen ze er dan voor zorgen dat het project succesvol verloopt. Daarom raad ik aan dat de stakeholders zich niet bemoeien met het hoe van het project, en zich beperken tot de onderwerpen die in de vijftien vragen aan de orde komen.

Ik heb mijn inspiratie voor de vijftien vragen gevonden in het gedicht ‘The elephant child’ van Rudyard Kipling, waarin hij laat zien dat er voor hem altijd zes essentiële vragen te beantwoorden zijn:

I keep six honest serving-men

(They taught me all I knew);

Their names are What and Why and When

And How and Where and Who.

I send them over land and sea,

I send them east and west;

But after they have worked for me,

I give them all a rest.

Deze manier van vragen wordt dan ook wel de Kiplingmethode of de 5W1H genoemd. Vertaald naar dit boek levert dat de vijftien vragen op. Stakeholders2 die een project (mede) aansturen, zoals de stuurgroepleden, kunnen via deze vragen het project in goede banen leiden. Het is niet nodig om alle details van een project te begrijpen of om kennis van projectmanagementmethoden te hebben. Wel is het nodig dat iedere stakeholder regelmatig kijkt of de antwoorden nog steeds acceptabel zijn en dat zij/hij de antwoorden pas accepteert als zij/hij ze goed begrijpt. Het gaat ook over de juiste gedragingen: de moeite nemen om het project echt te begrijpen, geen genoegen nemen met vage antwoorden, zorgen dat de rapportage een goede weergave van de realiteit is, niets goedkeuren zonder te weten wat je goedkeurt, de moed hebben onaangename zaken aan de orde te stellen en accepteren dat er onzekerheden zijn.

Als een organisatie de uitvoering van projecten serieus wil nemen, dan betekent dit dat ook mensen buiten het project er tijd aan moeten besteden. De invloed van stuurgroepleden en van toekomstige gebruikers is heel belangrijk voor het succes van een project. Bovendien brengt de organisatie van een project een zekere overhead mee (vijftien procent is een goede schatting). Om die reden is het verstandig om een activiteit niet te snel een ‘project’ te noemen. Kleinere verbeteractiviteiten of vaker voorkomende taken houden we buiten de projectenlijst. Zodra iets echter op de projectenlijst staat, moet het ook als zodanig behandeld worden. Vandaar mijn adagium: 'if it is not on the list, it does not exist'. Deze regel geldt trouwens niet alleen voor de lijst van projecten, maar ook voor alle andere projectactiviteiten, zoals de lijst met beslissingen. Alleen als de documentatie een goed beeld van de werkelijkheid geeft, is die te gebruiken om het project aan te sturen. Het lijkt een open deur dat de documentatie de werkelijkheid moet weerspiegelen, maar helaas is de realiteit vaak weerbarstig. Er bestaat namelijk altijd de neiging om in de rapportage een rooskleurig beeld te scheppen van de werkelijkheid. Iets wat bijna af is, wordt al als klaar gerapporteerd, problemen die spelen, worden weggelaten of gebagatelliseerd et cetera. Soms zeg ik ook wel: projectmanagement is niets anders dan lijstjes eerlijk en up-to-date houden.

Over dit boek

In dit boek probeer ik de kloof te dichten tussen projectteams en hun omgeving. Veel onderwerpen die bij projectmanagement horen, komen ook in dit boek aan de orde. Echter, ik behandel niet hoe deze taken moeten worden uitgevoerd (dat is projectmanagement), maar waarom ze moeten worden uitgevoerd, wat ze betekenen voor het succes van een project en hoe we kunnen weten of ze goed genoeg zijn uitgevoerd.

Op het eerste gezicht lijkt dit boek misschien gevuld met triviale vragen als: ‘Is er voor elk product van een project een helder criterium dat aangeeft dat het product af is?’ Als het project een gebouw moet opleveren, dan is er bijvoorbeeld een lijst met punten die de klant allemaal moet nalopen en accepteren voordat het gebouw kan worden overgedragen. Of als het project een nieuw IT-systeem oplevert en een van de vereisten is dat alle toekomstige gebruikers getraind zijn, dan is er een lijst met alle gebruikers die training hebben ontvangen als bewijs daarvan. Voor elke projectuitkomst moet er dus een acceptatiecriterium zijn dat gebruikt wordt om te bepalen of en wanneer het product is opgeleverd. Zo zijn er nog vele andere triviale zaken waarvan maar al te gemakkelijk wordt aangenomen dat die in orde zijn. Een aantal hiervan behandel ik bij de uitleg van de vragen. De realiteit is echter dat in de meerderheid van de projecten die ik heb gezien veel van deze simpele dingen niet aan de orde waren gekomen.

Ik wil hier nogmaals de nadruk leggen op het feit dat dit geen boek over projectmanagement is. Een aantal methoden en technieken die ik bespreek, maken deel uit van projectmanagementmethoden, maar projectmanagement houdt veel meer in. De onderwerpen die ik behandel, gaan over de informatie die vanuit een project naar buiten moet komen. Met behulp van deze informatie is te begrijpen wat er in het project gebeurt. Ook kan met die informatie worden vastgesteld of het project goed loopt en hoe het moet worden aangestuurd.

Het is de verantwoordelijkheid van de projectmanager om een projectmanagementmethode te kiezen die bij het project past. Als ik weer eens iemand vol enthousiasme over de meest recente projectmanagementhype hoor praten, moet ik altijd denken aan Haarlemmerolie: het geneest alle ziekten en als je niet geneest, heb je het verkeerd toegepast. Wel is het zo dat de projectmanagementtechnieken die ik in dit boek behandel, in meerdere projectmanagementmethoden worden gebruikt. Ze zijn universeel en daarom is het nuttig om ze te begrijpen. De vragen die ik aan het eind van elk hoofdstuk geef, zijn erop gericht te kijken of ze in het project zijn toegepast en of de resultaten genoeg kwaliteit hebben. Het zijn echter ook voorbeeldvragen in die zin dat elk project weer anders is en dus zijn eigen vragen opwerpt. Ook het kiezen van de vragen is niet een kwestie van vinkjes zetten; het vereist een vertaling naar de werkelijkheid van een project.

De vragen hebben een vaste structuur. Ik begin met een motto: dit vat de vraag en het beste antwoord op de vraag samen. Daarna geef ik een beschrijving van wat ik in de praktijk heb gezien. Ter illustratie van de bestaande praktijk geef ik een aantal voorbeelden. Deze voorbeelden zijn bekende openbare voorbeelden en geanonimiseerde voorbeelden die ik van dichtbij heb meegemaakt. Vervolgens leg ik het gebied waar de vraag over gaat nader uit.

Na deze inleiding en de leeswijzer volgen er vijftien hoofdstukken. In elk hoofdstuk behandel ik een vraag die belangrijk is voor projectsucces. De hoofdvraag staat al in de titel en aan het eind van het betreffende hoofdstuk wordt de hoofdvraag in een aantal deelvragen uitgewerkt.

1 Een deliverable van een project kan het best worden omschreven als alles wat een project oplevert waarvan kan worden vastgesteld of het ‘af’ is aan de hand van een acceptatiecriterium. Een deliverable kan van alles zijn: een product, een gebouw, een rapport, een IT-systeem, getrainde toekomstige gebruikers, een marketingcampagne en nog veel meer. Een acceptatiecriterium is dan een eis waaraan een deliverable moet voldoen, bijvoorbeeld een lijst met te trainen gebruikers of een lijst van gegevens die in een IT-systeem moeten zitten en up-to-date moeten zijn.

2 Een stakeholder is iedereen die iets met een project te maken heeft, zoals de leden van het projectteam, de leden van de stuurgroep, de toekomstige gebruikers, experts die advies aan het project geven, leveranciers van producten, klanten die met een andere manier van werken te maken krijgen, instanties die vergunningen moeten verlenen en nog veel meer.

Leeswijzer

Er zijn enkele gemeenschappelijke onderwerpen die een rol spelen bij alle vragen die in dit boek aan de orde komen:

•De verschillende fasen die elk project doorloopt: de setup-, execute-, aftercare- en benefitsfase.

•De verschillende domeinen van elk project uitgedrukt door middel van de projectdriehoek: time, resources en scope.

•De lijst van taken die een project moet uitvoeren: de Work Breakdown Structure.

•De casus die dient om de voorbeelden te illustreren.

Voor bepaalde begrippen die met projecten te maken hebben, zal ik Engelse termen gebruiken. Dit zijn standaardbegrippen die door projectteams worden gebruikt en als ik deze termen door Nederlandse termen zou vervangen, kan dit verwarring opleveren. Als er bij een motto geen referentie gegeven wordt is het een uitspraak die ik zelf veel gebruikt heb bij het managen en begelieden van projecten.

In dit hoofdstuk geef ik een korte introductie van deze vier onderwerpen.

Over de projectfasen

Een van de uitgangspunten van dit boek is dat het nodig is om een project te begeleiden van het idee van een project tot de realisatie van de benefits. Projectmanagementmethoden houden zich bijna uitsluitend bezig met een van deze vier fasen: de uitvoering. In dit boek zal ik vier fasen onderscheiden:

•De setupfase Deze gaat van het idee voor een project tot het besluit om het project te gaan uitvoeren.

•De executefase Dit is de traditionele uitvoering van een project en bevat zaken als het ontwerp, de bouw, het testen en het opleveren van het project.

•De aftercarefase Dit is een periode aansluitend op de executefase waarin een deel van het projectteam nog helpt met de transitie naar het normale gebruik van de projectdeliverables.

•De benefitsfase Deze begint gelijk met de aftercarefase en heeft als doel ervoor te zorgen dat de verwachte benefits ook gerealiseerd worden.

Over de projectdriehoek

Gedurende al deze fasen zijn er drie zaken die op elkaar inwerken. Deze zijn geïllustreerd in de projectdriehoek (zie figuur 0.1).

Figuur 0.1: De projectdriehoek

Een verandering in een van de drie heeft invloed op de andere twee en dus op het gehele project. De projectdomeinen zijn:

•De scope beschrijft alles wat een project doet, van concrete deliverables en trainingen tot het verzekeren van de kwaliteit.

•Time gaat over alle planningsaspecten: wanneer begint een project, wanneer moet het klaar zijn en alle details die hiermee te maken hebben.

•Het domein resources beschrijft alles wat een project nodig heeft. De hoofdonderdelen zijn mensen en geld, maar ook detailzaken als kantoorruimte en gereedschappen vallen eronder.

Over de Work Breakdown Structure (WBS)

Centraal in de projectdriehoek staat de lijst van taken die een projectteam moet doen. Dit heet de Work Breakdown Structure. Elke taak heeft een scope: wat levert de taak op, een time: wanneer begint en eindigt de taak, en een resources: wie gaat het doen en hoeveel gaat het kosten.

Over de casus

Ten slotte wil ik in deze inleiding het project introduceren dat we door het hele boek heen als voorbeeld zullen gebruiken. Dit voorbeeldproject speelt zich af in een keten van fietsenwinkels die het onderhoud van winkel- en werkplaatsapparatuur wil insourcen nadat de keten het een aantal jaren geleden heeft geoutsourcet. Het voorbeeldproject is fictief, maar gebaseerd op een project dat ik heb begeleid.

In mijn boek heeft de onderneming een honderdtal winkels/werkplaatsen en een hoofdkantoor met ongeveer honderd mensen. Elke winkel doet aan verkoop, onderhoud en reparatie van de producten en per winkel werken er tussen de vijf en vijftien mensen in de verkoop en reparatie. Het assortiment bestaat uit allerlei soorten tweewielers zoals (race)fietsen, elektrische fietsen, bakfietsen, brommers, scooters en elektrische scooters. Het zijn moderne en gezellige winkels met een koffiehoek waar op reparaties kan worden gewacht. Er staat behoorlijk wat apparatuur in elke winkel/werkplaats. Zo is er de apparatuur die nodig is voor onderhoud en reparatie, maar er zijn ook een koffiemachine en een oven. Het hoofdkantoor heeft een klassieke structuur met een directeur, een HR-manager, een financieel manager en een manager die verantwoordelijk is voor de operaties. Alle andere functies, zoals IT, juridisch advies en verkoop, vallen onder de financieel manager of de manager operaties.

Een paar jaar geleden is er besloten om het onderhoud van de apparatuur in de winkels en werkplaatsen uit te besteden aan een externe serviceorganisatie omdat er op dat moment geen interne medewerkers waren met de benodigde skills en omdat reparatie en onderhoud niet als corebusiness werden beschouwd. Het gaat om het volledige pakket van de verlichting in de winkels tot de motoranalyseapparatuur en van de koffiemachine tot de kassa. De huidige procedure is eenvoudig. Zodra er een probleem is in een winkel, wordt er een centraal nummer gebeld en vervolgens geeft de externe organisatie een reparatieopdracht aan een bedrijf. Per maand stuurt dit bedrijf een verzamelfactuur. Er is recentelijk gereviewd. Daaruit bleek dat er aardig wat nodeloos onderhoud wordt gedaan en dat er geen inzicht bestaat in het functioneren en de beschikbaarheid van de apparatuur in de winkels. Bij elke melding van een winkel/werkplaats wordt er iemand langs gestuurd zonder dat er voldoende is gekeken of dat wel nodig is. En met de bestaande procedure is het niet mogelijk om te controleren of dit wel echt nodig was. Ook hebben we geen inzicht in welke apparatuur betrouwbaar is en welke apparatuur vaak reparaties nodig heeft. Er is daarom besloten om het project Repin (Reparatie insourcing) te starten, dat het beheer van reparaties weer onder controle van het bedrijf brengt. Het project heeft impact op de hele organisatie: op het hoofdkantoor moeten mensen worden aangenomen om de reparaties te coördineren, de procedures in de winkels veranderen, er moeten nieuwe procedures komen om de leveranciers te betalen, er moeten nieuwe contracten worden afgesloten met reparatiebedrijven en er moet een IT-systeem komen om de reparatieaanvragen af te handelen.

Ik gebruik het project Repin als voorbeeld bij de vijftien vragen, zodat de vragen concreet worden. De meeste illustraties zijn voorbeelden uit het Repin-project. Voor de projectsponsor zijn alle vijftien vragen belangrijk en daarom zal ik de projectsponsor in de rest van dit boek als vragensteller gebruiken. Verder zal ik het bedrijf waaraan het beheer van de reparatiecontracten en de coördinatie van de reparaties is uitbesteed, de reparatieserviceprovider noemen.

Alle documenten in dit boek – project one pager, actielijst, besluitenlijst, risicomatrix, projectdashboard en readiness-radar – zijn voorbeelden die worden gebruikt om de inhoud te illustreren en hebben betrekking op het Repin-project. Ik heb ze gebruikt en voor mij werkten ze prima. Elke organisatie kan echter een eigen manier van werken bepalen, toegesneden op de specifieke eisen van de organisatie. Zolang de inhoud dezelfde elementen bevat, is er niets aan de hand.

VRAAG 1 • Is het wel een project?

'Als alles een project is, dan is niets een project.'

Projecten beginnen altijd met een idee, zoals:

•Het gaat nu goed met het bedrijf, we zitten op verschillende locaties, laten we alles samenbrengen op één locatie.

•We zijn succesvol met dit product in deze markt, laten we het eens op een andere markt proberen.

•We besteden als managementteam wel erg veel tijd aan zaken die niet onze corebusiness zijn en daardoor besteden we misschien te weinig tijd aan belangrijke zaken, laten we de niet-corebusiness maar outsourcen.

•Onze productiefaciliteiten zijn minder modern en flexibel dan die van de concurrenten, laten we ze moderniseren.

•We hebben onvoldoende gegevens over hoe het gaat met onze business, laten we kijken of we dat kunnen verbeteren.

Dit zijn allemaal grote projecten, maar er zijn natuurlijk ook kleinere projectideeën, zoals:

•We krijgen enorm veel reclamaties dat onze facturen fouten bevatten, laten we eens kijken of daar wat aan te doen is.

•Het contract met de leasemaatschappij loopt binnenkort af, laten we eens kijken of we een beter contract kunnen krijgen met meer aandacht voor verschillende vormen van vervoer.

Kortom, er is een enorme verscheidenheid aan redenen om een project te beginnen. Wel is er een eigenschap die alle projectvoorstellen verbindt, namelijk dat ze over eenmalige veranderingen gaan. Vaak begint men naar aanleiding van een projectidee ondoordacht aan een project, benoemt men een (vaak onervaren) projectmanager en kijkt men niet serieus naar de risico’s. Het gevolg is een woud van projecten waarbij je door de bomen het bos niet meer ziet.

Ik ben van mening dat het lang niet altijd nodig is een project op te zetten. Als er echter een project wordt opgezet, dan verdient het ook voldoende aandacht van alle stakeholders. De criteria die bepalen of we iets een project noemen, hangen erg van de business af, maar over het algemeen geldt: een project is eenmalig, een project heeft een begin en een eind, een project vereist extra resources, een project gaat over een verandering en er zijn meerdere groepen/afdelingen bij een project betrokken.

De definitie van een project

Het lijkt vreemd om je af te vragen wat nu precies een project is, maar dit is in vele opzichten de sleutel tot het goed begrijpen (en dus het succes) van projecten in een organisatie. Het is belangrijk om een (kleine) verbetering en/of verandering niet te snel een project te noemen. Twee overwegingen zijn hierbij belangrijk.

De eerste overweging is dat we ervoor moeten zorgen dat projecten voldoende aandacht krijgen van de stakeholders. Iedereen die bij een project betrokken is, op welke wijze dan ook, is een stakeholder van dat project. De groep stakeholders bestaat uit het projectteam, de projectstuurgroep, alle medewerkers (de interne stakeholders) en alle partijen buiten de organisatie die aan het project bijdragen of er de gevolgen van ondervinden (de externe stakeholders). Alle lezers van dit boek zijn waarschijnlijk stakeholder van een of meer projecten. Het is belangrijk dat stakeholders meedenken en op die manier een ‘stake’ (=belang) in het project hebben (meer details over stakeholdermanagement komen bij vraag 15 aan de orde). Stakeholders zijn echter ook maar mensen en hebben het druk met hun dagelijkse werk. Het is dus belangrijk dat ze weten hoeveel aandacht ze aan een project moeten geven en waar die aandacht naartoe moet gaan. De meeste stakeholders hebben namelijk ook nog gewoon een baan en dus beperkt tijd.

De tweede overweging om niet te gauw iets een project te noemen is dat een project een extra managementlaag introduceert. Een goede schatting is dat vijftien procent van de projectkosten nodig is voor projectmanagementtaken. We moeten ons dus elke keer afvragen of deze extra kosten te rechtvaardigen zijn. Die rechtvaardiging kan worden gevonden in het feit dat het werk zo complex is dat het niet zonder projectmanagement kan, of dat er grote bedrijfsrisico’s aan het project vastzitten, of dat we verwachten dat de kwaliteit beter wordt als we er een project van maken. Ik maak meestal een splitsing tussen projecten en verbeterinitiatieven. Verbeterinitiatieven hebben een minder grote impact op de organisatie en kunnen succesvol worden afgesloten zonder dat ze als een project worden gemanaged.

Een goed begrip van wat een project is (en soms zelfs de definitie van verschillende soorten projecten), zorgt er mede voor dat belangrijke projecten voldoende aandacht krijgen en een grotere kans hebben om succesvol te zijn. Het Project Management Institute (dat de PMBOK als projectmanagementmethode beheert) heeft als definitie van een project: ‘A project is a temporary endeavor undertaken to create a unique product, service or result.’ De eerste deelvraag die je moet stellen is dus: ‘Zijn de deliverables van het voorgestelde project uniek?’ Omdat het een eenmalige activiteit is, heeft deze een begin en een eind. Vaak wordt dit begrepen als een begindatum van het project en de datum waarop het project klaar is. Dat is echter een simplificatie. Een project start langzaam op en sluit ook langzaam af. Toch is het begrensd in de tijd. De tweede deelvraag is : ‘Is er een goede definitie van wanneer het project klaar is?’ Deze definitie sluit alle activiteiten uit die vaker dan één keer in een bedrijf worden ondernomen. Zaken als terugkerende marketingcampagnes, studies die regelmatig worden gedaan (bijvoorbeeld door middel van enquêtes) en maandafsluitingen moeten dus niet als een project worden gezien. Bij zulke zaken weten we na enige tijd hoe ze werken en is de uitvoering een kwestie van het correct volgen van een draaiboek. Het ontwikkelen van een goed draaiboek zou wel een project kunnen zijn.

De extra tijd en kosten die het managen van een project meebrengt, kunnen worden gerechtvaardigd door de complexiteit van het project. Die complexiteit wordt onder andere bepaald door het aantal interne en externe partijen die bij het project betrokken moeten zijn, door de wisselwerking en/of overlap met ander projecten, door de projectrisico’s (zie vraag 11), door de cash-out, en door de onzekerheid in de scope (zie vraag 7). De derde deelvraag is dus: ‘Is de complexiteit groot genoeg om het als project te managen of kunnen we het beter als een verbeteractiviteit organiseren?’

Ten slotte moeten we kijken naar de benefits. Als deze ruim na beëindiging van het potentiële project worden gerealiseerd, dan is het verstandig om echt een project op te zetten. In dat geval wordt namelijk ook ruim na beëindiging van het project gekeken of de baten echt gerealiseerd worden. Dus is de vierde deelvraag: ‘Wanneer worden de benefits gerealiseerd?’ Langs deze maatlat bezien is het verbeteren van een intern bedrijfsproces met bijvoorbeeld de Lean Six Sigma-methode geen project.

In veel bedrijven worden de woorden ‘project’ en ‘projectmanager’ vrij algemeen, te pas en te onpas, gebruikt. Elke keer als er een taak is die niet tot het dagelijks werk behoort, wordt er een project opgezet. In zo’n situatie zijn er ook heel veel projectmanagers, vaak met onduidelijke bevoegdheden, en heel veel projecten met onduidelijke aansturing en scope. Men ziet dan door de bomen het bos niet meer en chaos regeert.

Het maken van een duidelijk onderscheid tussen projecten en verbeterinitiatieven maakt het mogelijk om verschillende niveaus van projectmanagement te definiëren. Projecten worden centraal beheerd van portfolio tot benefitsrealisatie en verbeterinitiatieven worden lokaal (bijvoorbeeld door een afdelingsmanager) opgezet en uitgevoerd. In een grote organisatie is deze simpele tweedeling soms niet goed genoeg. Een verfijning van de opsplitsing in projecten en verbeterinitiatieven kan worden bereikt door de projecten verder op te splitsen in verschillende projecttypes, bijvoorbeeld onderzoeksprojecten, projecten die businessprocessen verbeteren en marketingprojecten. Alle projecten staan op de projectenlijst (if it is not on the list, it does not exist – zie hiervoor vraag 3), en per projecttype spreken we af op welke manier ze gemanaged gaan worden.

De organisatie die de lijst met projecten beheert, noem ik het Project Management Office (PMO). Het PMO is verantwoordelijk voor portfoliomanagement, zorgt ervoor dat er een minimum aan standaardisatie is en kiest projectteamleden die goed gekwalificeerd zijn en voldoende tijd voor het project beschikbaar hebben. Voor kleine organisaties is dit een parttimerol en voor grotere organisaties kan dit een taak van een aantal personen zijn. Het bestaan van een PMO dat toegang heeft tot alle stakeholders van alle projecten, helpt enorm bij het succesvol realiseren van het projectportfolio.

Figuur 1.1: De vier fasen van een project

In dit boek zal ik vier projectfasen onderscheiden (zie figuur 1.1). Ten eerste is er de setupfase, die wordt gebruikt om een project zó voor te bereiden dat de kans op succes het grootst is. In een organisatie zijn er altijd een aantal projecten die in de setupfase zijn en het is voor geen van deze projecten zeker dat ze ook worden uitgevoerd. De projecten concurreren om de beschikbare middelen, en een combinatie van verwachte baten, beschikbare middelen en kans op succes (risico’s) bepaalt de prioriteit.

Als een project wordt goedgekeurd, volgt de executefase waarin het project wordt uitgevoerd. In deze fase worden de deliverables door het projectteam gemaakt. De gebruikte projectmanagementmethode (Scrum, PMI, Prince2) is afhankelijk van het soort project.

Aan het eind van een project zijn de deliverables wel af, maar zijn er vaak nog kinderziekten op te lossen en moet de overdracht van de deliverables naar de uiteindelijke gebruikers nog worden gedaan. In het verleden werden de deliverables vaak ‘over de muur gegooid’ naar de gebruikersorganisatie en dit is geen succesvolle benadering gebleken. Het is verstandig een periode van gezamenlijk beheer te hebben. Dit noem ik de aftercarefase.

Het is belangrijk dat we ons realiseren dat een deliverable niet automatisch leidt tot de verwachte baten. Ik gebruik voor de te verwachten baten in het vervolg de engelse term: benefits. De benefits worden bijna altijd lang na het stoppen van het project gerealiseerd. Zo is na het introduceren van een nieuw IT-systeem de uitvoering in het begin vaak slechter dan voorheen, en na een verhuizing naar een nieuw kantoor is men vaak minder productief dan voorheen. Als er geen aandacht aan het realiseren van de benefits wordt besteed, worden ze vaak ook niet gerealiseerd. De fase waarin we ervoor zorgen dat de benefits daadwerkelijk worden gerealiseerd, noem ik de benefitsfase.

Naast de rol van de projectmanager (verantwoordelijk voor de uitvoering van een project) is er een speciale rol weggelegd voor de projectsponsor. De projectsponsor is iemand die verantwoordelijk is voor alle fasen van een project. Hij/zij begeleidt de setupfase, stuurt het project aan gedurende de execute- en aftercarefase en zorgt ervoor dat de benefits worden gerealiseerd. De projectsponsor heeft ook de eindverantwoordelijkheid bij de go/no-gobeslissingen. Er is een go/no-gobeslissing aan het eind van elke fase. Er wordt dan gekeken of de projectfase kan worden afgesloten en of er aan een volgende fase kan worden begonnen. Ik ga nu iets dieper in op de vier projectfasen.

Dit is het einde van de preview. Ga voor meer informatie over dit boek naar de website van Uitgeverij Haystack of bestel het boek bij uw favoriete boekhandel