Projectmanagement voor opdrachtgevers 6de herziene druk E-Book

Michiel van der Molen

• Herausgeber: Van Haren Publishing
• Kategorie: Bildung
• Sprache: Niederländisch
• Veröffentlichungsjahr: 2019

Seitenzahl: 289

Beschreibung

Projectmanagement is meer dan het werk van de projectmanager: als opdrachtgever speel je een sleutelrol. Dit boek helpt je om als opdrachtgever effectief en efficiënt strategische sturing te geven aan projecten. Daarnaast geeft dit boek antwoorden op praktische vragen waar je als opdrachtgever mee geconfronteerd wordt. Dit boek is bestemd voor managers die in de rol van opdrachtgever verantwoordelijk zijn voor verschillende soorten projecten, zoals productontwikkeling, infrastructurele werken, woningbouw, bedrijfsverhuizingen of ICT-projecten. Daarnaast is het nuttig voor projectmanagers om door de bril van een opdrachtgever naar hun eigen rol te kijken. Veel grote organisaties bevinden zich in een overgang van een 'klassieke' naar een 'agile' aanpak van projecten, met ingrijpende gevolgen voor de wijze waarop managers bij projecten betrokken zijn. Deze zesde druk biedt managers hierbij ruime ondersteuning. Met meer dan 15.000 verkochte exemplaren is dit boek uitgegroeid tot hét standaardwerk over opdrachtgeverschap van projecten. Het boek is voorzien van illustraties van Johan van Zanten (Studio Noord, Amsterdam). “... levert op een zeer toegankelijke wijze uiterst bruikbare informatie voor iedere manager die geconfronteerd wordt met het besturen van projecten. Een aanrader dus.” (Manager & Literatuur) “... gaat in op ‘uit het leven gegrepen’ vragen waarmee opdrachtgevers worstelen. Helder en beknopt geschreven, zoals opdrachtgevers dat graag zien.” (Projectie) “… een overzichtelijk en vooral leesbaar boek…een goed voorbereide opdrachtgever is onontbeerlijk voor het succes van het project. Dit boek is daar een uitstekend middel voor.” (Projectmanager)

Leseprobe

Projectmanagement voor opdrachtgevers 6de druk

Andere uitgaven bij Van Haren Publishing

Van Haren Publishing (VHP) is gespecialiseerd in uitgaven over Best Practices, methodes en standaarden op het gebied van de volgende domeinen:

- IT en IT-management;

- Enterprise-architectuur;

- Projectmanagement, en

- Businessmanagement.

Deze uitgaven zijn beschikbaar in meerdere talen en maken deel uit van toonaangevende series, zoals Best Practice, The Open Group series, Project management en PM series.

Van Haren Publishing is tevens de uitgever voor toonaangevende instellingen en bedrijven, onder andere: Agile Consortium, ASL BiSL Foundation, CA, Centre Henri Tudor, Gaming Works, IACCM, IAOP, IPMA-NL, ITSqc, NAF, KNVI, PMI-NL, PON, The Open Group, The SOX Institute.

Onderwerpen per domein zijn:

IT and IT Management

ABC of ICT

ASL®

CATS CM®

CMMI®

COBIT®

e-CF

ISM

ISO/IEC 20000

ISO/IEC 27001/27002

ISPL

IT4IT®

IT-CMFTM

IT Service CMM

ITIL®

MOF

MSF

SABSA

SAF

SIAMTM

TRIM

VersiSMTM

Enterprise Architecture

ArchiMate®

BIAN

GEA®

Novius Architectuur Methode

TOGAF®

Business Management

BABOK® Guide

BiSL® and BiSL® Next

BRMBOKTM

BTF

EFQM

eSCM

FSM

IACCM

ISA-95

ISO 9000/9001

OPBOK

SixSigma

SOX

SqEME®

Project Management

A4-Projectmanagement

DSDM/Atern

ICB / NCB

ISO 21500

MINCE®

M_o_R®

MSP®

P3O®

PMBOK® Guide

Praxis®

PRINCE2®

Voor een compleet overzicht van alle uitgaven, ga naar onze website: www.vanharen.net

Colofon

Titel:

Projectmanagement voor opdrachtgevers

Ondertitel

Van klassiek tot agile

Auteur:

Michiel van der Molen

Uitgever:

Van Haren Publishing, ’s-Hertogenbosch, www.vanharen.net

ISBN Hard copy:

978 94 018 0448 6

ISBN eBook (pdf):

978 94 018 0449 3

ISBN eBook (ePUB):

978 94 018 0450 9

Druk:

Eerste druk (Hoe haal ik het beste uit mijn project?

Prince2 voor opdrachtgevers), 2003 (Lemma)

Tweede druk (Hoe haal ik het beste uit mijn project?

Prince2 voor opdrachtgevers), 2005 (Lemma)

Derde druk (Prince2 voor opdrachtgevers), 2007

(Van Haren Publishing)

Vierde druk (Prince2 voor opdrachtgevers), 2009

(Van Haren Publishing)

Vijfde druk (Projectmanagement voor opdrachtgevers), november 2013

Zesde druk (Projectmanagement voor opdrachtgevers), april 2019

Lay-out en ontwerp:

Coco Bookmedia, Amersfoort

Illustraties binnenwerk en omslag:

Johan van Zanten, Studio Noord – Amsterdam, www.studionoord.net

Copyright:

© Van Haren Publishing, 2013, 2019

Hoofdstuk 8 is met toestemming van de uitgever een bewerking van hoofdstuk 3 van: Molen, Michiel van der, Waarom doen we dit eigenlijk? De businesscase als succesfactor van projecten, 2de druk (Van Duuren Management, 2013).

Voor verdere informatie over Van Haren Publishing, e-mail naar: [email protected].

Niets uit deze uitgave mag worden verveelvoudigd en/of openbaar gemaakt door middel van druk, fotokopie, microfilm, of op welke wijze ook, zonder voorafgaande schriftelijke toestemming van de uitgever.

No part of this publication may be reproduced in any form by print, photo print, microfilm or any other means without written permission by the publisher.

Hoewel deze uitgave met veel zorg is samengesteld, aanvaarden auteur(s) noch uitgever enige aansprakelijkheid voor schade ontstaan door eventuele fouten en/of onvolkomenheden in deze uitgave.

Dankwoord

Ik ben veel mensen dank verschuldigd voor hun bijdrage aan de totstandkoming van dit boek.

Als eerste dank ik Ad van den Akker voor de professionele begeleiding en waardevolle advisering bij het opstellen van de eerste versie van dit boek in 2003.

Daarnaast gaat mijn grote dank uit naar al diegenen die conceptteksten van de opeenvolgende versies van dit boek van commentaar hebben voorzien en suggesties hebben gegeven. Bij de eerste tot en met de vijfde druk waren dat Ad van den Akker, Martin de Boer, Paul Bogerd, Pritam Chita, Jos Dams, Brigit Darlang, Peter Deadman, Stephen Edwards, Alette Faber, Alvin Gardiner, Ross Garland, Herman Hanekamp, Karen Harland, Dick La Haye, Wil Hendrickx, Arja Hilberdink, Sander Hoogendoorn, Peter Keneghan, Corien Kiel, Peter Koers, Eva van der Molen, Hans van der Molen, Andy Murray, Kim van Oorschot, Albert Peek, Eric Pieper, Henny Portman, Reynier Pronk, Sylvie Rath, Rob Schepens, Maarten Speet, Luc van Veggel, Wim Vleeskens, David EJ Wilson en Anton Zandhuis. Bij deze zesde opnieuw herziene druk heb ik onmisbare hulp gekregen van Hans van der Heide, Dido Meijer en Henny Portman.

Door het enthousiasme en de betrokkenheid van zo velen heb ik me bij het werken aan dit boek zeer gesteund gevoeld.

Voorwoord bij de zesde druk

‘Verandering is wat er gebeurt terwijl je een boek zit te schrijven’ (vrij naar John Lennon)

De manier waarop organisaties projecten doen verandert snel. Het geloof in maakbaarheid brokkelt steeds verder af. In sommige omgevingen, vooral daar waar je de projectresultaten niet kunt vastpakken zoals bij ICT of marketing, is agile werken de norm geworden en wordt het woord ‘project’ intussen door sommigen als old school beschouwd. In omgevingen waar je de projectresultaten wel kunt vastpakken, zoals bij de bouw van een bedrijfsinstallatie door een staalfabriek of het bestellen van nieuwe tramstellen door een openbaarvervoerbedrijf, wordt nog veel ‘klassiek projectmatig’ gewerkt.

Ik vind het moeilijk om deze veranderingen objectief te zien, omdat ik er zelf deel van uitmaak. Terwijl ik de neiging heb te geloven in controle, heb ik door ervaring geleerd dat ik met vertrouwen meestal meer bereik: betere samenwerking, betere resultaten, sneller, en het is nog leuker ook. En dat is misschien wel de essentie van de verandering in projectmatig werken in de afgelopen decennia. Ik ben blij dat ik met deze nieuwe druk opnieuw de gelegenheid heb mijn voortschrijdend inzicht te verwerken in een actuele versie.

De organisaties waar ik de afgelopen jaren het meeste voor gewerkt heb (zoals de Belastingdienst, het Kadaster, het UWV, GVB Amsterdam, Tata Steel) zijn permanent in transitie, ook wat betreft het omgaan met projecten. Hierbij ontstaat veelal een hybride aanpak met wisselende combinaties van klassiek en agile. Elk vraagstuk vraagt nu eenmaal zijn eigen benadering en verschillende delen van de organisatie zitten in verschillende stadia van verandering. En mensen hebben misschien wel meer dan ooit verschillende visies op wat de juiste aanpak is.

Ik heb dit boek aangepast om daarmee om te kunnen gaan. Dit boek bevat dan ook niet één aanpak, maar helpt je de verschillende talen van projectprofessionals te begrijpen, en van de verschillende benaderingen de voors en tegens te zien. En te zien dat er geen ideale aanpak bestaat, omdat de aanpak van je project ook zelf deel uitmaakt van een veranderingsproces. Ik hoop dat dit je helpt om keuzes te maken over hoe je sturing wilt geven aan dat unieke project dat uiteindelijk jouw project is.

Als je opmerkingen of suggesties hebt naar aanleiding van dit boek: ik sta er graag voor open. Ik hoop dat ook dit boek nog lang kan blijven veranderen.

Michiel van der Molen, januari 2019

[email protected]

Inhoud

Inleiding

De uitdaging

Is het wel een project?

Wat is een opdrachtgever?

Het lijnmanagement is verantwoordelijk

Meer sturing met minder moeite

Aansluiting op verschillende projectmanagementomgevingen

Leeswijzer

DEEL 1   DE ESSENTIE

Overzicht van de vier principes

1.   OPDRACHTGEVERSCHAP VAN KLASSIEK TOT AGILE

Preprofessioneel

Klassiek

Hybride

Agile

Continuous delivery

Gaan alle organisaties richting agile?

Samenvatting

Klassiek en agile in dit boek

2.   HET EERSTE PRINCIPE: DEEL HET WAAROM

Focus creëren

Basis voor communicatie

Framing

Soorten businesscases

Hoe komt een businesscase tot stand?

Wijziging van de businesscase

Maatstaf voor succes

Realisatie van baten

Samenvatting

3.   HET TWEEDE PRINCIPE: ORGANISEER EIGENAARSCHAP

Eigenaarschap

Interactie met belanghebbenden

De opdrachtgever: eigenaar van de businesscase

De stuurgroep

Seniorleverancier

Seniorgebruiker

Aansluiten op lijnverantwoordelijkheden

Houding en gedrag

Samenwerken

Houd het klein

Eigenaarschap van klassiek tot agile

Samenvatting

4.   HET DERDE PRINCIPE: RICHT JE OP RESULTATEN

Laat producten centraal stellen

Voorbeelden van producten

Projecten met een onduidelijk eindproduct

Draagvlak

Grip op kwaliteit

Grip op voortgang

Grip op budget

Consistentie

Richten op resultaten van klassiek tot agile

Samenvatting

5.   HET VIERDE PRINCIPE: GEEF VERANTWOORDELIJKHEID

Verantwoordelijkheid van de projectmanager

Mandaat per fase

Faseplan

Welke managementfasen?

Besluitvorming in twee stappen

Toetsing ten opzichte van de businesscase

Sturen op uitzonderingen

Voortgangsrapportage

Afwijkingsrapportage

Twee soorten beslismomenten

Minder vergaderen?

Verantwoordelijkheid geven van klassiek tot agile

Samenvatting

Samenvatting deel 1

DEEL 2   DE DETAILS

6.   DE STUURGROEP NADER BEZIEN

Wie vervult de opdrachtgeversrol?

Wie vertegenwoordigt de gebruikers?

Wie vertegenwoordigt de leveranciers?

Ook interne afstemming

De relatie tussen stuurgroepleden en belanghebbenden

Adviserende gremia

Wijzigingsautoriteit (wijzigingsberaad, change control board)

Projectborging

Scheiding van verantwoordelijkheden

Overige stuurgroeprollen: geen gratis ritjes

De besluiten van de stuurgroep

De stuurgroep van klassiek tot agile

Samenvatting

7.   HET AANSTUREN VAN DE PROJECTMANAGER

Hoe herken ik een goede projectmanager?

Wie levert de projectmanager?

Welke concrete bevoegdheden kan ik een projectmanager geven?

Hoe voorkom ik dat een projectmanager oncontroleerbaar wordt?

Hoe voorkom ik dat een externe projectmanager oncontroleerbaar wordt?

Aansturen van de projectmanager, van klassiek tot agile

Samenvatting

8.   HOE STUUR IK OP REALISATIE VAN DE BATEN?

Het benoemen van de baten

Het realiseren van de baten

De motiverende kracht van batenmanagement

De voordelen van batenmanagement

Batenmanagement, van klassiek tot agile

Samenvatting

9.   STUREN OP KWALITEIT

Wat is kwaliteit?

Wat zijn de verschillende rollen en verantwoordelijkheden voor kwaliteit?

Hoe kan de stuurgroep sturen op kwaliteit?

Hoe kan ik gebruikers efficiënt en effectief betrekken bij de realisatie van kwaliteit?

Sturen op kwaliteit, van klassiek tot agile

Samenvatting

10.   OMGAAN MET ONZEKERHEID EN VERANDERING

Hoe zorg ik dat risico’s goed beheerst worden?

Hoe ga ik om met wijzigingen in de specificaties?

Samenvatting

11.   WAAROM LOPEN PROJECTEN UIT EN WAT DOE IK DAARTEGEN?

Structureel optimisme

Voortschrijdend inzicht van gebruikers

Eenzijdige invloed van specialisten

Dynamiek in de projectomgeving

Onvoldoende projectbeheersing

Blinde vlekken in het plan

Technische problemen

Wet van Parkinson

Vertraging in de besluitvorming

Prijsopdrijving door een leverancier

Uitloop van projecten, van klassiek tot agile

Samenvatting

12.   HET INTERPRETEREN VAN INFORMATIE

Businesscasedocument

Project- of faseplan

Voortgangsrapportage

Wijzigingsvoorstel

Product backlog

Teambord

Burn down chart

Interpreteren van informatie, van klassiek tot agile

Samenvatting

Samenvatting deel 2

Tot slot

Over de auteur

Woordenlijst

Literatuurlijst

Index

Inleiding

▪ DE UITDAGING

Als manager heb je niet alleen je operationele verantwoordelijkheden. Door ontwikkelingen in de maatschappij, economie, markt, technologie of wetgeving ben je ook steeds vaker betrokken bij veranderingen. Soms vereist die verandering dat er zaken ontwikkeld worden die te veel omvatten om het zelf te doen: je besluit een projectmanager aan te stellen.

Je wilt dan de uitvoering graag zo veel mogelijk delegeren, maar je blijft eindverantwoordelijk voor het succes van het project. Hoe pak je dat nu aan? Daarover gaat dit boek.

▪ IS HET WEL EEN PROJECT?

Een project brengt gedoe met zich mee. Het betekent een scheiding van verantwoordelijkheden: je hebt in ieder geval een opdrachtgever en een projectmanager. De één neemt de strategische besluiten, de ander heeft de dagelijkse leiding. Dat loont alleen wanneer er voldoende complexiteit en risico is om deze overhead de moeite waard te maken. Soms is het handiger om iets gewoon te doen. Een vuistregel is: wanneer de staande organisatie in staat is om het zelf te doen, maak er dan geen project van.

Project

Een project is een tijdelijke onderneming gericht op het tot stand brengen van een uniek(e) product, dienst of resultaat. De opdrachtgevende organisatie start een project om een bedrijfsdoelstelling te bereiken: een positief effect voor zichzelf en/of haar belanghebbenden.

Ook bij complexe veranderingen is een projectmatige aanpak niet altijd passend. Een projectmatige aanpak is vooral geschikt om een tastbaar resultaat tot stand te brengen dat in hoofdlijnen voorspelbaar is, zodat een projectmanager dit conform verwachting kan opleveren. Denk bijvoorbeeld aan een nieuw gebouw, een nieuwe productie-installatie of een aangepast computersysteem. Als de grootste uitdaging schuilt in een verandering van cultuur of gedrag, in verandering in de manier van samenwerking tussen organisaties, of wanneer het succes van de verandering vooral afhangt van de steun van externe partijen met verschillende belangen, dan is het niet realistisch om uit te gaan van een voorspelbaar resultaat. Andere veranderkundige benaderingen zijn dan waarschijnlijk geschikter, bijvoorbeeld programmamanagement (Bekkers, 2017) of procesregie (Van Oosterhout, 2010).

▪ WAT IS EEN OPDRACHTGEVER?

De term ‘opdrachtgever’ wordt in onze taal op twee manieren gebruikt:

1. Als aanduiding van de persoon, in beginsel een lijnmanager, die de projectmanager aanstuurt bij de uitvoering van een project (projectopdrachtgever).

2. Als aanduiding van de organisatie die een opdracht uitbesteedt aan een leverancier (contractopdrachtgever).

In dit boek gebruik ik het woord in de eerste betekenis: een persoon die een projectmanager aanstuurt. Dit boek gaat dus niet over contract- of leveranciersmanagement, al komt de rol van leveranciers binnen de projectorganisatie wel aan de orde.

Wat is nu het wezenlijke verschil tussen een opdrachtgever en andere belang-hebbenden? Een opdrachtgever geeft namens de organisatie strategische sturing aan de projectmanager. Het verschil met andere belanghebbenden is dat een opdrachtgever een project beschouwt als een investering. Die investering kun je alleen rechtvaardigen als de baten (positieve financiële en/of niet-financiële effecten) opwegen tegen de kosten. Andere belanghebbenden zijn niet verantwoordelijk voor de investeringsbeslissing, maar hebben wel voordeel of nadeel ten gevolge van een project.

Een opdrachtgever is actief betrokken bij de projectbesturing en vormt het scharnierpunt tussen de permanente (lijn)organisatie en de tijdelijke (project) organisatie. Dit onderscheidt een opdrachtgever van een financier of sponsor, die een project wel als een investering beschouwt, maar zich niet actief met de besturing bezighoudt.

Opdrachtgever

Een opdrachtgever is de persoon die namens de (permanente) lijnorganisatie verantwoordelijk is om de (tijdelijke) projectorganisatie aan te sturen, als vertegenwoordiger van de zakelijke belangen in de aansturing van het project en verantwoordelijk voor het realiseren van de zakelijke doelen zoals verwoord in de businesscase van het project.

Wanneer je als opdrachtgever verantwoordelijkheid krijgt voor een project, dan word je met een aantal vragen geconfronteerd. Dit boek geeft daar antwoord op:

■ Wat is mijn verantwoordelijkheid als opdrachtgever? (zie de Inleiding en deel 1)

■ Hoe kan ik anderen zo veel mogelijk hun verantwoordelijkheid laten nemen en zelf sturen op hoofdlijnen? (deel 1)

■ Hoe kom ik tot een effectieve stuurgroep, waarin belanghebbenden zich samen inzetten voor het gemeenschappelijke doel? (hoofdstuk 6)

■ Hoe stuur ik de projectmanager aan? (hoofdstuk 7)

■ Hoe stuur ik vanaf het begin op realisatie van de beoogde baten? (hoofdstuk 8)

■ Hoe stuur ik op kwaliteit zonder zelf in alle details te verzanden? (hoofdstuk 9)

■ Hoe ga ik om met onzekerheden en verandering? (hoofdstuk 10)

■ Hoe hou ik de kosten in de hand? (hoofdstuk 11)

■ Hoe kan ik uit alle projectinformatie halen wat voor mij belangrijk is? (hoofdstuk 12)

▪ HET LIJNMANAGEMENT IS VERANTWOORDELIJK

Wanneer is een project succesvol? Als de projectmanager conform verwachtingen het projectresultaat oplevert? Dat is niet voldoende. Als het projectresultaat daarna niet naar verwachting wordt gebruikt (in de ruimste zin van het woord: in gebruik genomen, verkocht, verhuurd, beheerd, bewoond enzovoort), dan is het project geen succes. Is een project dan wel succesvol als het resultaat geaccepteerd en gebruikt wordt? Voor een opdrachtgever is dat nog steeds niet voldoende. Een project is een investering en die doe je om bepaalde baten (positieve effecten voor belanghebbenden, al dan niet financieel) te realiseren, bijvoorbeeld financieel rendement, maatschappelijke baten of het voldoen aan wetgeving. Dit is het bedrijfsdoel1. Pas wanneer je ook dit realiseert, is er sprake van een succes. Vaak kun je dit pas enige tijd na afronding van een project met zekerheid vaststellen.

De verantwoordelijkheid voor dit bedrijfsdoel – inclusief de realisatie van de baten, positieve effecten voor belanghebbenden binnen of buiten de organisatie – kan alleen liggen bij de opdrachtgever. De opdrachtgever is verantwoordelijk voor de investeringsbeslissing, voor het goedkeuren van het plan, voor het aanstellen van de projectmanager, voor de besluitvorming over eventuele wijzigingen van het plan en vooral voor het (doen) realiseren van de baten. Wanneer een project mislukt, dan is het in een organisatie uiteindelijk niet anders dan met andere missers, zoals fraude, milieuschandalen of ernstige kwaliteitsproblemen: het lijnmanagement is verantwoordelijk. De uitgangspunten van dit boek zijn dan ook:

1. Een project is pas een succes als het bedrijfsdoel gerealiseerd wordt.

2. De opdrachtgever, als vertegenwoordiger van het lijnmanagement, is eindverantwoordelijk voor het succes van een project.

Dit boek helpt je deze verantwoordelijkheid te dragen.

En de projectmanager dan?

De belangrijkste verantwoordelijkheid van de projectmanager is het opleveren van het overeengekomen projectresultaat conform afspraken over kosten, levertijd, scope en kwaliteit. Dit uiteraard onder de voorwaarde dat de opdrachtgever de afgesproken randvoorwaarden handhaaft, zoals de beschikbaarheid van informatie, hulpmiddelen en mensen, toegang tot gebouwen en installaties en tijdige besluitvorming.

Dit boek gaat over hoe je als opdrachtgever vanuit bedrijfsperspectief effectief sturing kunt geven aan een project, ervan uitgaande dat de dagelijkse leiding van het project in handen is van een bekwame projectmanager. Mocht je aan dat laatste twijfelen, los dat probleem dan eerst op. Dit boek is geen ‘samenvatting projectmanagement’ en gaat niet in op zaken als de samenstelling van project-teams of het aansturen van projectmedewerkers of onderaannemers: ik ga ervan uit dat de projectmanager daarin het voortouw heeft.

▪ MEER STURING MET MINDER MOEITE

Goede projectbesturing moet in de eerste plaats effectief zijn. Dat wil zeggen dat het project je optimaal ondersteunt om je bedrijfsdoel te realiseren. Omdat je verantwoordelijkheid als opdrachtgever waarschijnlijk bovenop je lijnverantwoordelijkheden komt, moet projectbesturing daarnaast efficiënt zijn. Efficiënt betekent dat je optimaal gebruikmaakt van de bronnen van de organisatie, zodat de projectbesturing je zo min mogelijk inspanning kost en je voldoende aandacht kunt blijven besteden aan je andere verantwoordelijkheden.

Wat je als opdrachtgever nodig hebt is dus effectiviteit én efficiency, of populair gezegd: meer sturing met minder moeite. Deel 1 van dit boek beschrijft in vier aparte hoofdstukken vier principes die hierop gericht zijn. Elk van deze hoofdstukken eindigt met een kort overzicht van de manier waarop het betreffende principe je als opdrachtgever helpt om effectief en efficiënt te sturen.

Het toepassen van deze vier principes is niet het enige wat je als opdrachtgever hoeft te doen. Opdrachtgeverschap is een vorm van management en dat betekent ook: je handelen afstemmen op de omstandigheden, niet volgens een boekje werken en gewoon doen wat er gedaan moet worden. De vier principes helpen je hierbij te focussen op wat belangrijk is.

▪ AANSLUITING OP VERSCHILLENDE PROJECTMANAGEMENTOMGEVINGEN

In Nederland zijn PRINCE2 (klassiek) en Scrum (agile) de bekendste manieren om projecten aan te pakken. Ik denk dat geen enkele aanpak het beste is voor alle projecten, en dat je sommige zaken überhaupt niet als project moet aanpakken. Veel organisaties volgen een hybride (gecombineerde) aanpak: in de praktijk een combinatie van klassieke besturing door een opdrachtgever met een stuurgroep en uitvoering door een agile team.

Dit boek is gericht op managers in omgevingen met een klassieke of hybride (klassiek/agile) aanpak van projecten. Hybride betekent in de praktijk veelal dat het uitvoerende projectteam een aantal agile werkwijzen hanteert, terwijl de organisatie daaromheen nog klassiek is ingericht met een opdrachtgever en een stuurgroep die betrokken afdelingen vertegenwoordigt. In een volledig agile omgeving met zelforganiserende agile teams zonder opdrachtgevers en stuurgroepen vervalt de relevantie van dit boek. Het eerste hoofdstuk van deel 1 gaat in op de verschillende ontwikkelingsstadia van projectmatig werken in organisaties en wat dit betekent voor de rol van de opdrachtgever: een rol die opkomt en soms uiteindelijk ook weer verdwijnt.

Dit boek geeft je generieke inzichten en beschrijft hoe je hier in verschillende klassieke en hybride omgevingen mee om kunt gaan. Steeds vanuit hetzelfde perspectief: je bent als lijnmanager eindverantwoordelijk voor een project en je wilt hiermee waarde creëren voor je organisatie.

Met de taal die ik gebruik sluit ik zo veel mogelijk aan op wat gangbaar is in grote organisaties in Nederland. De besturing van een project beschrijf ik daarom met termen die overwegend zijn ontleend aan PRINCE2 (zoals seniorgebruiker of senior user). De agile uitvoering beschrijf ik met termen overwegend ontleend aan Scrum (zoals product owner, sprint). Achterin dit boek vind je een verklarende woordenlijst.

▪ LEESWIJZER

Lees na deze inleiding in elk geval deel 1 De essentie. Dit bevat fundamentele inzichten in de plek die je als opdrachtgever inneemt en hoe je van daaruit effectief en efficiënt invloed kunt uitoefenen. Lees vervolgens naar behoefte en in willekeurige volgorde (delen van) deel 2 De details. Dit bevat verdieping en antwoorden op een aantal praktische vragen. Omdat deze hoofdstukken los van elkaar te lezen zijn bevatten ze enkele kleine overlaps.

Verspreid over de tekst vind je tips. Soms zijn dit algemene tips, soms zijn het specifieke, bijvoorbeeld tips voor de PRINCE2-omgeving of tips voor de hybride omgeving.

Alternatieve leesroute: als je goed bekend bent met het klassieke instrumenta-rium en vooral wilt weten wat er verandert wanneer projectteams meer agile gaan werken, lees dan hoofdstuk 1 plus van alle volgende hoofdstukken telkens de op één na laatste paragraaf van het hoofdstuk (steeds op lichtblauwe achtergrond) over de verandering in de beweging van klassiek naar agile.

_____________

1 Misschien ben je meer vertrouwd met termen als businessdoel, businessbelang, businessperspectief. Ik hou van Nederlands en gebruik liever termen als bedrijfsdoel et cetera. Ik weet dat het soms net iets anders overkomt maar ik bedoel hetzelfde.

Inleiding deel 1

De wereld verandert steeds sneller. De behoefte aan wendbaarheid en flexibiliteit wordt steeds groter en de manier waarop organisaties met projecten omgaan past zich aan. Voor de rol van de opdrachtgever heeft dit ingrijpende gevolgen. Het eerste hoofdstuk van dit deel van het boek gaat daarom over de grote beweging in projectmatig werken in deze tijd en wat deze betekent voor de rol van de opdrachtgever.

De overige vier hoofdstukken van dit deel zijn het resultaat van een jarenlang proces van trial-and-error: sinds het verschijnen van de eerste versie van dit boek heb ik in een grote verscheidenheid aan organisaties aan groepen managers trainingen opdrachtgeverschap gegeven. En steeds heb ik enkele maanden later gecheckt wat de deelnemers nu anders deden dan vóór de training en wat dat hun opleverde. Op basis daarvan heb ik telkens datgene uit de training (en uit de eerstvolgende druk van het boek) verwijderd wat geen aantoonbare toegevoegde waarde had, en geprobeerd datgene te versterken wat wel toegevoegde waarde had. Zo kwam ik geleidelijk uit op vier fundamentele principes waar opdrachtgevers werkelijk baat bij hebben en die in alle projectomgevingen werkzaam zijn.

▪ OVERZICHT VAN DE VIER PRINCIPES

Zoals je in de Inleiding van dit boek hebt kunnen lezen ben je als opdrachtgever verantwoordelijk voor het realiseren van het bedrijfsdoel van een project (bijvoorbeeld grotere burgerparticipatie of hogere omzet, dit is richtinggevend voor het project). Hierover gaan de eerste twee principes:

1e principe:

Deel het waarom

Dit principe helpt je om focus op het bedrijfsdoel te creëren. Het beschrijft hoe je samen met belanghebbenden komt tot een gedeeld beeld van het waarom en het belang van het project, zodat zij zich daarmee kunnen verbinden, en hoe je dit gebruikt als basis voor alle detailbeslissingen.

2e principe:

Organiseer eigenaarschap

Dit principe helpt je om in de staande organisatie eigenaarschap te creëren voor het bereiken van het bedrijfsdoel. Het beschrijft hoe je in de ‘horizontale’ relatie met belanghebbenden (bijvoorbeeld in rollen als stuurgroepleden of gebruikers) bereikt dat zij zich verantwoordelijk voelen om aan het gemeenschappelijke doel elk hun specifieke individuele bijdrage te leveren.

De projectmanager is verantwoordelijk voor de oplevering van het tastbare resultaat (bijvoorbeeld een aangepaste website of een nieuwe machine, dit is dienend aan het bedrijfsdoel). Hiervoor ben je als opdrachtgever eindverantwoordelijk. Hierover gaan de andere twee principes:

3e principe:

Richt je op resultaten

Dit principe helpt je om focus op het projectresultaat te creëren. Het beschrijft hoe je in de uitvoering resultaten (producten, deliverables) centraal kunt stellen, zodat de opdracht aan uitvoerenden duidelijk is en zij zich op díe tastbare resultaten richten die je nodig hebt om uiteindelijk je bedrijfsdoel te kunnen realiseren.

4e principe:

Geef verantwoordelijkheid

Dit principe helpt je om bij de uitvoerenden eigenaarschap te creëren voor het realiseren van het projectresultaat. Het beschrijft hoe je in de ‘verticale’ relatie met het uitvoerende projectteam kunt bereiken dat het team een helder mandaat heeft, dat je met beperkte inspanning zelf de eindverantwoordelijkheid kunt dragen en dat je waar nodig kunt bijsturen.

De hoofdstukken 2 tot en met 5 beschrijven steeds één van de vier principes, laten zien hoe je dit kunt toepassen in verschillende omgevingen en welke voordelen dit je oplevert.

De rol van de opdrachtgever is in beweging. In sommige organisaties heeft het opdrachtgeverschap – de opdrachtgever als eindverantwoordelijke in de aansturing van projecten – nog nauwelijks vorm gekregen. In een andere organisatie investeert men volop in het professionaliseren van opdrachtgeverschap. In weer een andere organisatie ziet men projectmatig werken als verouderd en is het opdrachtgeverschap aan het verdwijnen. In veel organisaties is opdrachtgeverschap tegelijk in verschillende gedaanten aanwezig. Om als opdrachtgever richting te geven aan je rol en te weten of je de teugels moet aanhalen of juist vieren, is het belangrijk je eigen positie te kunnen bepalen in het perspectief van deze beweging. Dit hoofdstuk beschrijft de ontwikkeling van het (niet) projectmatig werken in organisaties en de gevolgen daarvan voor de rollen van opdrachtgevers en stuurgroepleden. Vijf ontwikkelingsstadia2 passeren de revue:

■ Preprofessioneel

■ Klassiek

■ Hybride

■ Agile

■ Continuous delivery

Ik gebruik de term ‘ontwikkelingsstadium’ omdat er in veel organisaties een logische volgorde in zit. Dat betekent niet dat alle organisaties alle stadia (kunnen) doorlopen. Dat hangt af van het type projecten en de context, waarover later meer.

▪ PREPROFESSIONEEL

In een organisatie die nog weinig heeft geïnvesteerd in de professionalisering van projectmatig werken is de aanpak van een project sterk afhankelijk van de individuele voorkeur van de projectmanager. De inrichting van de projectorganisatie en de manier van rapporteren verschillen sterk van project tot project: niet alleen omdat elk project uniek is maar ook eenvoudigweg omdat de betrokken projectmanagers andere gewoonten en voorkeuren hebben. Voor betrokken lijnmanagers is het lastig hun eigen rol in te nemen: wat ze bij de ene projectmanager geleerd hebben blijkt bij de andere niet geldig te zijn. Voor het hoger management is het lastig om een overzicht over de gehele projectenportefeuille te hebben, want hoe moet je appels en peren vergelijken en optellen? Dit alles vormt een belemmering voor het lijnmanagement om zich werkelijk eigenaar te voelen van hun projecten en hun rol actief op te pakken. Een project is vooral iets van de projectmanager en het ligt voor de hand bij mislukkingen allereerst te wijzen naar de projectmanager. Het opdrachtgeverschap is weinig ontwikkeld en stuurgroeplidmaatschap is een vrijblijvende rol zonder heldere verantwoordelijkheden voor individuele stuurgroepleden.

▪ KLASSIEK

Op het preprofessionele niveau ontstaat ergernis over dit gebrek aan beheersing en controle en over het gebrek aan overzicht over een steeds grotere en complexere projectenportefeuille. De natuurlijke reactie is: streven naar een gemeenschappelijke aanpak om betere controle en sturing mogelijk te maken. Zo ontstaat draagvlak voor de professionalisering van projectmatig werken, gericht op invoering van een beproefde methodiek en een voor betrokken managers herkenbare aanpak. De behoefte aan versterking van controle en sturing door het lijnmanagement speelt hierbij een belangrijke rol. In Nederland is PRINCE2 de belangrijkste methodiek die aan deze behoefte beantwoordt.

Kenmerkend voor deze ontwikkeling is niet alleen een meer uniforme aanpak van projecten door de projectmanager op uitvoerend niveau, maar ook een meer expliciete scheiding van verantwoordelijkheden tussen opdrachtgever en projectmanager. De opdrachtgever is – samen met zijn stuurgroep – verantwoordelijk voor de besluitvorming, de projectmanager moet de besluiten uitvoeren en heeft de dagelijkse leiding. De projectmanager maakt een plan met een beschrijving van wat hij gaat leveren, de stuurgroep keurt dit goed en de projectmanager gaat aan de slag om het daadwerkelijk te leveren. Pas na formele vrijgave door de stuurgroep worden eindproducten in gebruik genomen. Dit is het principe van de scheiding van besturing en uitvoering. De eindverantwoordelijkheid van het lijnmanagement voor projecten krijgt meer nadruk, managers worden meer aangesproken op het succes (of falen) van hun projecten. De rol van de opdrachtgever, ondersteund door stuurgroepleden, krijgt steeds meer nadruk.

De invoering van een uniforme aanpak leidt niet vanzelf tot het beëindigen van preprofessionele omgangsvormen: daadwerkelijke betrokkenheid van alle belanghebbenden is nodig om hiermee een echte stap vooruit te zetten. Winstpunten van succesvolle professionalisering in dit stadium kunnen zijn het voorkomen van onnodige fouten, het spreken van een gemeenschappelijke taal als basis voor het leren van ervaringen, de betere herkenbaarheid van de projectaanpak voor alle betrokkenen en een beter overzicht over de gehele projectenportefeuille. Uiteindelijk moet dit leiden tot een meer effectieve sturing vanuit bedrijfsperspectief, de toetssteen voor effectieve professionalisering in dit stadium.

▪ HYBRIDE

De klassieke aanpak van projectmatig werken blijkt in de ogen van steeds meer betrokkenen ook beperkingen te hebben:

■ het maken van gedetailleerde planningen en begrotingen en de formele besluitvorming daarover kost veel tijd en geld, terwijl intussen de wereld verandert en de uitvoering toch anders loopt: de voorspelbaarheid van projecten valt steeds weer tegen;

■ voor gebruikers en beheerders (en voor opdrachtgevers) is het heel moeilijk om zich op basis van een plan of ontwerp een beeld te vormen van wat zij gaan krijgen, waardoor verwachtingen niet altijd juist zijn en er bij oplevering teleurstellingen en problemen zijn;

■ er ontstaat steeds meer behoefte aan sneller resultaten opleveren en sneller terugkoppeling krijgen om te leren van de buitenwereld;

■ de sterke gerichtheid op controle en beheersing door het management past wel goed bij een watervalaanpak van projecten (eerst alles ontwerpen, dan realiseren, dan invoeren), maar is minder geschikt voor de exploratieve en wendbare aanpak die een dynamische omgeving vraagt.

Gezond verstand

Eind jaren tachtig werkte ik als systeemontwikkelaar bij een ICT-bedrijf. Ik werd gedetacheerd bij het Havenbedrijf Rotterdam, dat een systeem had ontworpen dat hen zou ondersteunen bij het omgaan met gevaarlijke stoffen: welke regels gelden er, wat te doen bij incidenten, et cetera. Het systeem moest gebouwd worden in een nieuwe interactieve ontwikkelomgeving, waarin je heel snel nieuwe functies kon bouwen zolang je je maar binnen de mogelijkheden van die software bewoog. Ik merkte dat het ontwerp niet goed gebruik maakte van de mogelijkheden van de te gebruiken software. Ik stelde mijn opdrachtgever voor om het ontwerp gedeeltelijk los te laten en snel een eerste versie te maken, zodat de gebruikers konden ervaren wat er mogelijk was en konden meedenken over hoe het moest worden. Dat kon in een paar weken, en aldus geschiedde. De gebruikers werden enthousiast, ik maakte elke paar weken een betere versie en na een paar maanden hadden ze een resultaat dat ze graag wilde hebben, en dat ook nog binnen het budget omdat we een hoop bureaucratie hadden overgeslagen. De term agile kende ik nog niet, maar voor mij – en velen met mij in die periode – was het gewoon gezond verstand en ik vond het efficiënter en leuker dan eerst een gedetailleerd plan maken. Het gebeurde omdat het kon, en ongetwijfeld had ik het met de huidige kennis van agile werken nog veel beter kunnen doen.

De roep om een meer flexibele aanpak van projecten was het sterkst in de ICT-wereld. In 2001 leidde dit tot de opstelling van het beroemd geworden Manifesto for Agile Software Delevopment.

‘Wij laten zien dat er betere manieren zijn om software te ontwikkelen door in de praktijk aan te tonen dat dit werkt en door anderen ermee te helpen. Daarom verkiezen we

• mensen en hun onderlinge interactie boven processen en hulpmiddelen

• werkende software boven allesomvattende documentatie

• samenwerking met de klant boven contractonderhandelingen

• inspelen op verandering boven het volgen van een plan

Hoewel wij waardering hebben voor alles wat aan de rechterkant staat vermeld, hechten wij méér waarde aan wat aan de linkerzijde wordt genoemd.’

Vanaf dat moment was agile (wendbaar) een overkoepelend begrip voor een groot aantal flexibele, iteratieve ontwikkelwijzen. Deze agile benaderingen hebben als gemeenschappelijke kenmerken:

■ De behoeften van de gebruikers worden weergegeven in een lijst (backlog) met te realiseren stukjes functionaliteit (ook user stories genoemd) op volgorde van prioriteit.

■ Een in hoge mate zelforganiserend team realiseert in korte iteraties met een vaste doorlooptijd (sprints) telkens de bovenste items uit de backlog.

■ In beginsel omvat elke sprint ook het uitleveren van de nieuwe functionaliteiten aan de gebruikers, zodat er directe terugkoppeling mogelijk is en de inhoud van de product backlog kan worden bijgesteld.

■ Het zo snel mogelijk leren van fouten en direct bijsturen staan centraal.

Ook buiten de ICT (marketing, productontwikkeling, zakelijke dienstverlening) werd de agile aanpak steeds meer omarmd. De klassieke projectmanagementmethodes werden voortaan watervalmethodes genoemd: benaderingen waarin elke fase (bijvoorbeeld specificatie, ontwerp, realisatie, invoering) betrekking heeft op het volledige eindproduct, waardoor het heel lastig is om halverwege het project nog bij te sturen.

Als voordelen van een agile aanpak worden gezien:

■ betere kwaliteit, door directe afstemming tussen gebruikersbehoeften en technische mogelijkheden;

■ beperking van overhead;

■ minder risico, omdat je door de korte iteraties met terugkoppeling vanuit de praktijk nooit lang op de verkeerde weg kunt zitten;

■ lagere kosten, doordat fouten eerder boven water komen en eerder wordt bijgestuurd;

■ grotere toegevoegde waarde, door frequente invoering van deelresultaten en afstemming van keuzes op ervaring in het gebruik.

Agile werken is niet gericht op het streven binnen een bepaalde tijd een vooraf gedefinieerd resultaat te leveren, maar op het steeds opnieuw binnen een vaste periode (een timebox van bijvoorbeeld vier weken) opleveren van een resultaat met maximale toegevoegde waarde, het leren van ervaringen en het waar zinvol bijstellen van de koers. Het oude adagium ‘eerst denken dan doen’ verliest terrein ten gunste van ‘al doende leert men’ of ook wel ‘zo snel mogelijk fouten maken’. Dat vereist een hoge mate van professionaliteit van betrokkenen. Belangrijke rollen zijn weggelegd voor de product owner en het ontwikkelteam. ‘De product owner is verantwoordelijk voor het maximaliseren van de waarde van het product dat resulteert uit de werkzaamheden van het ontwikkelteam. (…) Om te kunnen slagen als product owner moet de gehele organisatie zijn of haar beslissingen respecteren. De beslissingen van de product owner zijn zichtbaar in de inhoud en de ordening van de product backlog. Niemand mag het ontwikkelteam forceren aan een andere set van requirements te werken. (…) Het ontwikkelteam … is zelforganiserend. Niemand … vertelt het ontwikkelteam hoe zij de product backlog moeten omzetten in incrementen van potentieel uitleverbare functionaliteit.’ (Schwaber, 2017).

In organisaties die een klassieke aanpak gewend zijn kunnen verschillende belanghebbenden moeite hebben met dit vergaande mandaat:

■ Sponsoren (aandeelhouders of overheid) en hoger management zijn gewend vooraf te horen wat het project gaat opleveren en tegen welke kosten. In de publieke sector heeft een politieke ambtsdrager zich verbonden om voor een gegeven bedrag een concreet resultaat te leveren. Ook al leert de praktijk dat deze uitspraken vaak niet kunnen worden nagekomen, toch is het lastig deze verwachting los te laten.

■ De staande organisatie is nog dezelfde. Verschillende afdelingen hebben elk hun eigen verantwoordelijkheid en willen – vanuit hun perspectief terecht – hun invloed op het project behouden.

Zo ontstaat behoefte aan een hybride aanpak:

■