Waar is de projectmanager toch mee bezig?

HOE U PROJECT­ MANAGERS EN HUN TEAMS SUCCESVOL BEGELEIDT

Eerste druk oktober 2018 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: 9789461263018 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.

INHOUD

Inleiding Leeswijzer

8

16

Vraag 1

Is het wel een project?

23

Vraag 2

Past dit project binnen de strategie van de organisatie?

47

Vraag 3

Waarom doen we dit project en niet een ander?

63

Vraag 4

Weten we wie waarvoor verantwoordelijk is?

75

Vraag 5

Respecteren we de gedragsregels die projectsucces bevorderen?

99

Vraag 6

Begrijpen we het verschil tussen bier en champagne?

109

Vraag 7

Wat maakt het project?

123

Vraag 8

Hoeveel gaat het project kosten?

137

Vraag 9

Hoe lang gaat het project duren?

149

Vraag 10

Nemen we tijdig beslissingen?

163

Vraag 11

Kennen we de risico’s?

173

Vraag 12

Hebben we de goede projectbesturing?

185

Vraag 13

Hoe weten we of een project goed gaat?

199

Vraag 14

Hebben we goed nagedacht over de transitieperiode?

209

Vraag 15

Is er aan stakeholder­management gedacht?

215

Slotwoord

223

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 8 | WAAR IS DE PROJECTMANAGER TOCH MEE BEZIG?

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.

Inleiding | 9

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.

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.

10 | WAAR IS DE PROJECTMANAGER TOCH MEE BEZIG?

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 project­ team 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.

Inleiding | 11

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.

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.

12 | WAAR IS DE PROJECTMANAGER TOCH MEE BEZIG?

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 project­ activiteiten, 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 voorInleiding | 13

dat 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 project­ managementtechnieken die ik in dit boek behandel, in meerdere projectmanagementmethoden worden gebruikt. Ze zijn univer14 | WAAR IS DE PROJECTMANAGER TOCH MEE BEZIG?

seel 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.

Inleiding | 15

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 16 | WAAR IS DE PROJECTMANAGER TOCH MEE BEZIG?

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). 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.

Leeswijzer | 17

Figuur 0.1: De projectdriehoek

•• 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 18 | WAAR IS DE PROJECTMANAGER TOCH MEE BEZIG?

die het onderhoud van winkel- en werkplaatsapparatuur wil in­sourcen 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 numLeeswijzer | 19

mer 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, beslui20 | WAAR IS DE PROJECTMANAGER TOCH MEE BEZIG?

tenlijst, 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.

Leeswijzer | 21

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

22 | WAAR IS DE PROJECTMANAGER TOCH MEE BEZIG?

VRAAG 1

IS HET WEL 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.

VRAAG 1 • Is het wel een project? | 23

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 24 | WAAR IS DE PROJECTMANAGER TOCH MEE BEZIG?

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 stake­holders 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 ManageVRAAG 1 • Is het wel een project? | 25

ment 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?’

26 | WAAR IS DE PROJECTMANAGER TOCH MEE BEZIG?

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 verbeter­ initiatieven worden lokaal (bijvoorbeeld door een afdelings­ manager) 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.

VRAAG 1 • Is het wel een project? | 27

Figuur 1.1: De vier fasen van een project

28 | WAAR IS DE PROJECTMANAGER TOCH MEE BEZIG?