Talen
Pages
Wettelijk
Product-based planning, Gewoon Doen!
Titel : Product-based planning, Gewoon Doen! Auteur : Reynier Pronk Eindredactie : Marianne ten Hoeve Uitgever : PMA Heemstede Druk : F&N Boekservice ISBN : 978949109847 5 Correspondentie : [email protected] herziene druk maart 2014 © Copyright 2012 PMA Heemstede Niets uit deze uitgave mag worden verveelvoudigd en/of openbaar gemaakt door middel van druk, fotokopie, microfilm, of op welke wijze dan 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.
Het werkboek met de uitwerking van de case: Festival ‘MaasValley’, ‘product-based planning’ in de praktijk, is te bestellen bij: [email protected]. of via de gebruikelijke web shops: ISBN 978949109848 2
Project Management Training & Consultancy
Product-based planning, Gewoon Doen!
Transformatie van PINO naar werkelijk toegepast, eenvoudig Prince2
Reynier Pronk
Voor een heipaal is een heimachine nodig. Voor een spijker: een hamer en voor een punaise: een duim.
Prince2 is alle drie, maar gebruik geen heimachine waar een duim volstaat.
Het veranderen van een organisatie doet denken aan het oplaten van een vlieger, voor iemand anders. Je wacht totdat er voldoende ‘hard’ strand is. Je rent langs de vloedlijn, tegen de wind in. Je moet uitkijken om niet te struikelen over zandkastelen of, in door kinderen gegraven, kanalen of slotgrachten te vallen. Het oplaten gaat moeizaam want er zijn veel turbulenties in de lagere luchtlagen. Ook moet je een paar keer stoppen om de vlieger te trimmen, de staart te verlengen of juist weer in te korten. Tot hij volmaakt in balans is… Dan lukt het je; de vlieger schiet omhoog! Je hoeft nu alleen nog maar meer touw te geven. Ter voorbereiding heb je thuis al een haspel gemaakt waaraan het vliegertouw stevig verankerd zit, zodat de vlieger niet kan ontglippen. Daar staat hij, hoog en stabiel in de lucht! Nu is het moment gekomen om de vlieger over te dragen. Zorgvuldig geef je de haspel af en je legt nog één keer uit wat er gedaan moet worden om de vlieger hoog te houden. “Je moet goed vasthouden, opletten dat de vlieger niet duikt of gaat tollen. Corrigeren kun je door het vliegertouw te vieren of in te halen.” Je checkt nog even of de ander het allemaal goed heeft begrepen en dan vertrek je. Na een tijdje begint er iets te knagen. Zou de vlieger nog steeds stabiel in de lucht staan? Zou de ander in staat zijn om ‘m zo nodig opnieuw op te laten? Moet je niet terug om even te kijken? Nee, niet doen! Hij moet vasthouden, maar jij moet loslaten!
Inhoud Proloog ........................................................................................................................ 8
Voorwoord ................................................................................................................. 10
Inleiding ..................................................................................................................... 12
Radicale beslissingen ............................................................................................... 21
Iets over de opdracht .......................................... Fout! Bladwijzer niet gedefinieerd.
Tactiek ................................................................ Fout! Bladwijzer niet gedefinieerd.
De mouwen opgestroopt…!................................. Fout! Bladwijzer niet gedefinieerd.
‘PM-verbetertraject’ ............................................. Fout! Bladwijzer niet gedefinieerd.
Nulmeting ............................................................ Fout! Bladwijzer niet gedefinieerd.
Beleidsnota (analyse & aanpak).......................... Fout! Bladwijzer niet gedefinieerd.
Hoe verder? ........................................................ Fout! Bladwijzer niet gedefinieerd.
Columns .............................................................. Fout! Bladwijzer niet gedefinieerd.
Wat is er zo spannend aan ‘product-based planning’?Fout! Bladwijzer niet gedefinieerd.
Voorbeeld Product-based planning ..................... Fout! Bladwijzer niet gedefinieerd.
Externe producten managen ............................... Fout! Bladwijzer niet gedefinieerd.
Product-based planning en scoping .................... Fout! Bladwijzer niet gedefinieerd.
Product analyse .................................................. Fout! Bladwijzer niet gedefinieerd.
Product flowdiagram en rapportering .................. Fout! Bladwijzer niet gedefinieerd.
Reacties uit de Services-Organisatie ................. Fout! Bladwijzer niet gedefinieerd.
Samenvatting ...................................................... Fout! Bladwijzer niet gedefinieerd.
Stellingen ............................................................ Fout! Bladwijzer niet gedefinieerd.
Afkortingen .......................................................... Fout! Bladwijzer niet gedefinieerd.
Literatuur ............................................................. Fout! Bladwijzer niet gedefinieerd.
Casus ‘MaasValley’ ............................................. Fout! Bladwijzer niet gedefinieerd.
Bijlagen ............................................................... Fout! Bladwijzer niet gedefinieerd.
1
Proloog
De afgelopen twaalf jaar heb ik enkele duizenden kandidaten opgeleid voor Prince2
Foundation- en Practitioner-certificaten. Wanneer ik hen later bij toeval of voor een
Practitioner training weer tegenkwam, heb ik gevraagd of Prince2 inmiddels
daadwerkelijk werd toegepast in hun bedrijf of instelling. Het antwoord varieerde van:
“eigenlijk niet” tot “ja, maar alleen die dingen die voor ons bruikbaar zijn.”
Sommigen zeiden zelfs Prince2 werkelijk toe te passen. Wanneer ik dan vervolgens
vroeg: “Wil je mij dan de ‘product breakdown structure’ en ‘product flow diagram’ van
één van je recente projecten laten zien?”, was steevast het antwoord: “Die maken ze bij
ons niet (!).” Dat is vreemd, want ‘product-based planning’ is het ‘kloppend hart’ van
Prince2; vrijwel alles is hierop gebaseerd.
De Project Brief, de PID en het Highlight Report worden vaak wel gebruikt, maar dat
kunnen dan alleen gemankeerde documenten zijn. Prince2 zonder productgerichte
planning is als een motorboot zonder motor.
Veel organisaties blijken hun bestaande aanpak te hebben ‘verprinced’ door
documentnamen aan te passen, maar een werkelijke overstap is vaak niet gemaakt. Ik
maak me daarom al jaren zorgen over het lot van Prince2. Deze methode krijgt nu al
vaak de schuld van het feit dat projecten nog steeds niet beter worden uitgevoerd. Sterker
nog: in toenemende mate wordt beweerd dat Prince2 niets anders toevoegt dan
bureaucratie.
De meeste Project Managers zijn door hun bedrijf naar Prince2-trainingen gestuurd,
waarschijnlijk in de verwachting dat daarmee tevens Prince2 in hun organisatie zou
worden ingevoerd of verbeterd. Dat is een misvatting; een organisatie zal wezenlijk
moeten veranderen om een nieuwe methode te kunnen toepassen. Dit is primair een
management-taak. Het vereist kennis en vaardigheden om het voortouw te kunnen nemen
in het veranderingstraject, om te transformeren naar een volwaardige Prince2-
projectomgeving.
Veranderingstrajecten zijn per definitie lastig. Het vereist leiderschap, een tactische
aanpak en vooral veel geduld om het tot een goed einde te brengen. Denk niet te snel dat
je er bent, terugval in oude gewoonten ligt op de loer.
Eigenlijk was ik me aan het voorbereiden op mijn pensionering, toen de telefoon ging en
mij de vraag werd gesteld: “Zou je er voor voelen om bij een grote organisatie
interimmanager Project Management Vakpool te worden, voor zes maanden, met de
opdracht om de Project Managers naar een hoger niveau te brengen?”. Mijn antwoord had
misschien ‘nee’ moeten zijn, maar werd ‘ja’ en het werden er geen zes maar zelfs negen
maanden…
Dit boekje is niet alleen een verslag van de weg die een organisatie gaat van PINO
(Prince In Name Only) naar werkelijk toegepast praktisch Prince2 (bureaucratie-vrij),
maar biedt vooral ook tal van tips: hoe dit
te bewerkstelligen.
Omdat ‘product-based planning’ de basis is voor vrijwel alle aspecten van een Prince2-
project, is er in dit boek tevens de casus ‘MaasValley’ opgenomen. De uitwerkingen
hiervan staan in een apart werkboek.
Dit boek is geschreven om te helpen bij een succesvolle implementatie.
Of het werkt hoeft niet te worden betwijfeld: Het is gelukt !
Henny Kerkvliet dank ik voor zijn waardevolle bijdragen, Hans Venis voor het
bemoedigende voorwoord. Harry Bril, Roelof Donker, Frank van Galen, René Houben,
Arnoud Kinderman, Frans Schneider, Luuc Sipkes en Jeroen Weerink, dank ik voor hun
feedback.
Mijn speciale dank gaat uit naar Michiel van der Molen, die niet alleen welkome
aanvullingen en verbeteringen heeft aangedragen, maar die mij tevens heeft gestimuleerd
dit boekje te schrijven.
Heemstede, december 2012
Reynier Pronk
2
Voorwoord
Tsja. Dan wordt je op een dag gevraagd om een voorwoord te schrijven voor een boek
over Prince2. Daar heb ik eigenlijk helemaal niets mee. Ik ben niet zo van de
methodieken. Die leiden voor mij te vaak af van de essentie. Veel te snel en te vaak gaat
het dan over de methodiek en niet meer over het gewenste resultaat.
Een middel tot doel verheffen. Daar krijg ik pukkeltjes van!
Reynier Pronk is de man geweest die voor mij precies de goede balans wist te brengen bij
het introduceren van Prince2, binnen de organisatie waar ik nu alweer zo’n tien jaar
werkzaam ben. Zijn manier van introduceren, van coachen en begeleiden, maakt dat het
investeren in een methodiek en het opleiden van al die mensen in deze ‘kunst’ een
waardevolle investering is.
Ik heb al ruim 25 jaar ervaring met ICT-projecten, in complexe omstandigheden en bij
allerlei verschillende organisaties. Of het nu bank-/beleggingsbedrijven zijn,
verzekeraars, een facilitair bedrijf of chemische industrie. Allen hebben ze hun eigen
dynamiek, hun eigen cultuur en hun eigen administratie/rapportage behoefte. Altijd heb ik
de rol van Senior Supplier gehad en altijd was ik daarbij dus verantwoordelijk voor het
eindresultaat. Succes of fiasco, project- of lijnwerkzaamheden, het is slechts het resultaat
dat telt. Logisch dat je dan op zoek bent naar een goed ROI bij het gebruik van
projectbesturing.
Heeft u zelf wel eens een ‘herijking’ van een Business Case binnen uw organisatie
gedaan?
Heeft u veel projecten die binnen een jaar resultaat leveren?
Heeft voor uw projecten wel eens de balans opgemaakt of ze de beloofde opbrengst
hebben opgeleverd?
En als u dat gedaan heeft was het antwoord dan positief?
Wanneer u één of meerdere van de bovenstaande vragen met ‘nee’ hebt beantwoord, raad
ik u aan dit boek ter harte te nemen. Ik heb van Reynier met heel veel plezier een aantal
(voor mijn ego pijnlijke) lessen geleerd.
Het resultaat mag er zijn.
Voor mij was project management niet meer dan een leidraad en ik ben geen organisaties
tegen gekomen, die een goede balans wisten te brengen in project- besturing/control en
het adequaat behalen van het beoogde resultaat.
Zeker tijdens het millenniumtijdperk en de overgang van de gulden naar de euro, waren
de methodieken niet van de lucht.
Ik heb zelf mogen ervaren, hoe Reynier Pronk in onze organisatie de methodiek van
Prince2 zodanig heeft geïntroduceerd, dat deze levensvatbaar werd.
Al mijn managers die vanuit onze Senior Supplier-kant betrokken zijn (niet alleen de
Project Managers maar ook het lijnmanagement), hebben de Prince2-methodieken
gevolg. Zij kunnen een ‘product breakdown structure’ lezen en maken. Zij weten hoe ze
hierop moeten plannen en sturen. Werkpakketten worden zorgvuldig samengesteld.
Vakmanschap wordt niet aan het papier toevertrouwd (niet teveel details), maar worden
van goede, werkbare kaders voorzien.
In 2011 is Reynier bij ons geweest om ons te helpen met onze uitdaging. Een jaar later
waren wij, beter dan ooit, in ‘control’ over onze project- portfolio’s.
Ik wens u veel leesplezier.
Hans Venis 2012
Manager Infrastructuur
Services Organisatie
3
Inleiding
Los van de te hanteren methode, hangt het welslagen van elk project sterk af van enkele
belangrijke pijlers, die vaak niet of onvoldoende worden onderkend:
Nut en noodzaak Met andere woorden, wat voegen de projectresultaten toe? Is het écht nodig? Waaróm
doen we dit project eigenlijk? … En waarom nú?
Dit lijkt een open deur, en dat zou het ook moeten zijn. De werkelijkheid is helaas vaak
anders. Er zijn voorbeelden van projecten te over, waarbij deze vragen niet of
onvoldoende tevoren zijn beantwoord:
de Betuwelijn (drie keer te duur; sluit niet aan op de Duitse infrastructuur;
veertien extra binnenschepen hadden de toegenomen, verwachte capaciteitsvraag
kunnen leveren).
de HSL (zou in 2002 gereed zijn, maar wordt slechts op halve kracht
geëxploiteerd met grote exploitatieverliezen tot gevolg).
de Amsterdamse Noord-Zuidlijn (een budgettaire ramp voor negen kilometer
spoor; het huidige vervoersaanbod kan de vraag nog gemakkelijk aan).
De Amsterdamse Westhaven. (Na jaren aanmodderen nu weer gesloten. Men
overweegt momenteel om een nieuwe hoofdsluis in IJmuiden aan te leggen,
omdat met denkt dan grotere schepen te kunnen aantrekken. Een vlucht
voorwaarts dus).
Blauwe Stad Groningen (slecht 10% van de percelen verkocht; grote verliezen).
Vul hier verder maar de projecten in, die bij je eigen organisatie fout zijn gegaan.
De kern van het probleem is natuurlijk: ‘Zijn wij voldoende toegerust om te voorzien of
er, tegen de tijd van oplevering van de projectresultaten, hieraan (nog) behoefte is?’ Dat is
ook vaak lastig, maar daarom hebben wij ook leiders aangesteld die dit zouden moeten
kunnen beoordelen. Daarnaast is het van het grootste belang dat ‘de trein’ nog kan
worden gestopt als blijkt dat dit niet zo is.
Recent heb ik een boeiend artikel gelezen, waarin als één van de oorzaken van falen, het
z.g. ‘locked-in’-mechanisme wordt toegepast. Dat werkt zo: Een bestuurder die iets graag
wil laat eerst een (duur) onderzoek uitvoeren en maakt op voorhand allerlei afspraken met
de bouwer (die vaak ook het ‘onderzoek’ uitvoert).
Niet voor niets is de Business Case leidend voor projecten. Voor veel projecten is het echter voldoende om te weten waartoe het project eigenlijk dient en waarom het NÚ moet worden uitgevoerd. Een substantieel deel van de projecten gaat over noodzakelijk onderhoud, of is voorwaarde om een ander project te kunnen uitvoeren. Om je in allerlei bochten te wringen, een lijst met (vaak niet meetbare) baten op te sommen, is dan zonde van de inspanning. Beperk je in dat geval tot het beantwoorden van de waarom (nu) vraag en breng wél de risico’s in kaart.
Dit soort projecten moeten natuurlijk wel zo ‘goedkoop’ mogelijk worden uitgevoerd, dus de ‘scope’ dient beperkt te blijven zodat het project niet onnodig complex en duur wordt.
Vervolgens, wanneer er een besluit moet worden genomen, is het argument: ‘Het
onderzoek toont aan dat het een verantwoorde investering is, die veel nut zal opleveren en
goed is voor de werkgelegenheid in de regio’ (logisch toch?) en (bij weerstand): ‘Er is al
zoveel uitgegeven, wij moeten wel doorgaan; wanneer we stoppen komt de leverancier
met een claim.’
Daarmee heeft de betreffende bestuurder zichzelf opgesloten (locked-in) en zet hij de
overige managers of de gemeenteraad (of voor mijn part de 2e kamer), voor het blok.
Tegen dit soort bestuurders werkt maar één remedie: ontslaan voordat ze nog meer schade
kunnen aanrichten. Ontslagen worden ze echter niet, ze komen altijd weg met het zinnetje
‘met de kennis van nu…..’ Feitelijk maken ze misbruik van de ongewisheid van de
toekomst en wanneer er weerstand ontstaat, toveren ze ons angstscenario’s voor.
Het is cruciaal, nut, noodzaak en urgentie te bepalen, zonder andere belangen dan die van
de opdrachtgever mee te wegen (en dan ook nog op een eerlijke, realistische manier).
Het beste kun je meerdere scenario’s tegen elkaar afwegen: Het slechtste, ‘worst case’-
scenario, het ‘best case’-scenario en iets daartussen in. Dit wordt ook wel aangeduid als
GAP-analyse (Good, Average, Poor). Zoals zo vaak, ligt de waarheid meestal in het
midden. Doe dit nooit alleen en zeker niet met de belanghebbenden. Onafhankelijke
collega’s of adviesbureaus (dus niet degenen die daarna wellicht de uitvoering gaan doen)
kunnen hier een prima rol in spelen. Bedenk dat een verkeerd gekozen project dubbel
verlies betekent: Je geeft je geld (middelen en inspanning) dan aan het verkeerde uit en je
kunt daardoor geen ander project uitvoeren dat wél noodzakelijk is!
Bij twijfel is het beter even op je handen te gaan zitten. Dit wordt ook wel de ‘do nothing’
optie genoemd. Als blijkt dat er toch iets moet gebeuren: ‘do minimum’ en als het echt
niet anders kan ‘do something’. Dat klinkt zuinig en dat is het natuurlijk ook. Vergeet
echter niet dat een project vaak een grote impact heeft op de organisatie waarvoor het
wordt uitgevoerd. Een project is daarom vergelijkbaar met een ziekenhuisingreep: we
snijden de patiënt pas open wanneer er geen andere remedie helpt. Beter is te bezien of
een pilletje, kuurtje of bedrust helpt. Zo niet, dan bij voorkeur een kijkoperatie. Alleen
wanneer het niet anders kan: dan pas echt
gaan opereren.
De rol van de Business Case is in deze prominent: Het gaat niet alleen om nut, noodzaak,
baten, timing en risico’s, maar ook over de ‘scope’. De (set van) op te leveren producten
moeten precies dekken wat nodig is om de baten te realiseren. Niet meer en niet minder.
Paradigma : Wanneer je een timmerman, een smid en een beurtschipper vraagt een oeververbinding te maken, dan zal de timmerman waarschijnlijk niet voorstellen om een ijzeren brug te bouwen en de smid geen houten. De beurtschipper zal je alle voordelen van een veerpont uitleggen. Mocht er voor een brug gekozen worden, is het af te raden om deze door een tandarts te laten plaatsen…
Projecten zien als investering en als zodanig managen Wanneer er moet worden geïnvesteerd in gebouwen, inrichting en apparatuur, wordt er
vaak gewikt en gewogen of:
deze investering wel loont,
het geld er voor is,
het niet beter even kan worden uitgesteld en of er geen urgentere investering is die
voorrang moet krijgen.
Vervolgens is er veel controle op bestelprocessen, aflevering en financiële afwikkeling.
Het merkwaardige is, dat dit vaak niet opgaat voor projecten. Hoewel er veel geld en
inspanning mee zijn gemoeid , worden projecten vaak via heel andere mechanismen
afgehandeld. Waarom eigenlijk? Waarschijnlijk is dit historisch gegroeid, mede omdat
men het eerder ziet als een veranderingsproces dan als investering.
Even terzijde: voor beiden geldt overigens dat we erg slecht zijn in het meten van baten.
Dat is ook vaak lastig: wie kan mij vertellen wat de directe, financiële baten van de
Erasmusbrug zijn? Toch zouden we veel kunnen leren van een eerlijke en complete
evaluatie na de investering of een project.
Het zou een geweldige stap voorwaarts zijn als de projecten in je eigen organisatie net zo
worden afgehandeld als investeringen. Daarmee bedoel ik het gehele project en niet
alleen het ‘out-of-pocket’-deel. Dat sluit ook naadloos aan op het volgende onderwerp:
Eigenaarschap.
Het doen van een investering behoort tot de taken van leidinggevenden en – mits
belangrijk genoeg- vindt de besluitvorming hierover plaats aan de directietafel of, bij
kleinere investeringen, in een lager gremium. Maar het zijn nog steeds
managers/bestuurders die de beslissing nemen en controle houden over de voortgang en
het succes van de investering. In ieder geval is het een ‘management-feestje…’
Een Business Case is helaas wel ‘fraudegevoelig’. Door het schetsen van bepaalde (ramp)scenario’s, het overdrijven van de baten, het te laag inschatten van kosten en het wegmoffelen van risico’s c.q. nadelige effecten (de z.g. ‘disbenefits’), worden projecten doorgedrukt. Dat gebeurt steevast door functionarissen die zelf nooit de negatieve gevolgen hiervan
ervaren. Door gebrek aan tegenwicht gaan de ‘beslissers’ er vaak mee akkoord. Beter is het om de Business Case onafhankelijk te laten toetsen, of een ‘tegen-Business Case’ te maken. Op z’n minst moet er worden geëist dat er een fatsoenlijke ‘best-case/ worst-case’ of GAP-analyse wordt gemaakt. Het allerbeste werkt natuurlijk: Eigenaarschap!
Eigenaarschap De belangrijkste pijler voor een succesvol project is daarom toegepast ‘ownership’. Ik
bedoel hiermee: niet ‘in name only’. Veel projecten vliegen uit de bocht omdat niemand
zich werkelijk verantwoordelijk voelt (zie ook de column ‘Een project als
natuurverschijnsel’ op pag. 125). Het is dus van het grootste belang dat iemand in de
organisatie dit eigenaarschap op zich neemt en hierover verantwoording aflegt en beloond
of bestraft wordt (bonus/malus) naar gelang dit eigenaarschap goed wordt uitgevoerd. Het
gaat er dan natuurlijk niet om, of het project exact op tijd en binnen budget wordt
opgeleverd. Dat is altijd moeilijk, omdat een project zich afspeelt in een gebied waarin
nog nooit iemand een stap heeft gezet: ‘De toekomst’. Wel gaat het om actief leiderschap:
sturen en bijsturen met de blik gericht op projectefficiëntie en de te behalen baten. (Is het
project nog steeds noodzakelijk en urgent? Zijn de op te leveren resultaten in de
gewijzigde omstandigheden nog immer nuttig?).
Wanneer je het eigenaarschap niet goed regelt krijg je soms merkwaardige uitwassen:
Veel te ambitieus aangepakte projecten, enorme kosten-overschrijdingen en als het
project al tot resultaat leidt, is dit meestal veel te laat. Bestuurders gaan vrijuit en de
kosten worden afgewenteld op de gemeenschap.
Je ziet maar al te vaak dat een project prioriteit krijgt, omdat een van de ‘stakeholders’ dit
doordrukt. Dat kan bijvoorbeeld zijn:
Een bestuurder die goede sier willen maken met een prestigeproject.
Gebruikers die iets doordrukken (ik kan mijn werk niet doen als…)
Leveranciers waarbij de vlag uitgaat wanneer ze hun producten of diensten
kunnen verkopen (en zich daartoe een slag in de rondte lobbyen).
In sommige gevallen zijn het andere partijen, zoals omwonenden, die iets afdwingen.”
Wij gaan alleen maar akkoord als er …….” (bijvoorbeeld bij de ondertunneling van het
groene hart voor de HSL).
Alleen krachtig leiderschap kan ons redden om te voorkomen dat we in bovengenoemde
valkuilen trappen.
Er is dus maar een conclusie mogelijk: Het welslagen van een project hangt in hoge mate
af van het actief toegepaste ‘ownership’ en is dus primair een leiderschapskwestie !
Zorgvuldigheids-paradox
Het bepalen van nut-en-noodzaak en het stellen van prioriteiten vraagt zorgvuldige
afwegingen. Dat is een primaire management-taak. Het probleem is echter vaak, dat dit te
complex wordt om direct aan de management- of directietafel te worden beslist, zeker als
er veel organisatieonderdelen bij betrokken zijn.
De oplossing wordt dan vaak gezocht in het oprichten van een of meer gremia waarin
deze beslissing wordt voorbereid. Er waren vier van dergelijke raden, in de betreffende
organisatie. Deze raden keken vanuit verschillende invalshoeken naar projecten:. Elk
project ging daarom dus ook door vier ‘filters’ alvorens het van start kon gaan.
Dit lijkt een zorgvuldig proces, maar dat is het niet. Deze gremia worden meestal bevolkt
door belanghebbenden uit de diverse organisatieonderdelen en die hebben elk hun (soms
verborgen) agenda. Het gevaar bestaat dat niet de, voor de totale organisatie, belangrijkste
projecten worden geselecteerd, maar de projecten die het best ‘gepusht’ zijn, door de
behendigste vergadertijgers. Ook wordt er naar hartenlust politiek bedreven.
De enige manier om dit enigszins in te dammen is om aan ‘programme management’ te
doen, gebaseerd op de strategie van de totale organisatie. Ook dit vraagt krachtig
leiderschap.
Een ander fnuikend bijeffect is, dat door al deze comités een soort
groepsverantwoordelijkheid ontstaat en deze wordt zelden als zodanig ‘beleefd’. In de
jaren 70 is er veel geëxperimenteerd met zelfsturende teams, zonder aanwijsbaar
leiderschap. Het feit dat dit niet verder is ingevoerd,
bewijst dat het kennelijk niet werkt. Groepsverantwoordelijkheid is gelijk aan: ‘iedereen
is verantwoordelijk, dus is niemand persoonlijk aansprakelijk’.
Het is dus opnieuw van het grootste belang om een persoon te vinden met voldoende
macht in de organisatie en bestuurskracht in het project, die de rol van Executive,
(gedelegeerd) eigenaar, het best op zich kan nemen.
Zouden de opdrachtgevers van ingenieur Lely, bij het aanleggen van de Afsluitdijk, zich voldoende rekenschap hebben gegeven van de gevolgen hiervan? Alle vissersdorpen langs de voormalige Zuiderzee leiden sindsdien een kwijnend bestaan. De havens van Amsterdam, Hoorn en Enkhuizen hebben hun betekenis zien afnemen of zelfs verloren zien gaan. Het Noordzeekanaal vormt een blijvende barrière tussen het noorden en zuiden van Noord-Holland, met als gevolg: dure tunnels om beide oevers met elkaar te verbinden. De belangrijkste reden voor de afsluiting was inpoldering mogelijk te maken voor landbouwdoeleinden. Wij waren in die tijd een agrarisch volk en men dacht toen, die grond hard nodig te hebben. Sinds enkele decennia wordt er juist steeds meer landbouwgrond aan de natuur teruggegeven... Jammer dat je nooit zult weten hoe Nederland zich had ontwikkeld indien besloten was de Afsluitdijk niet te bouwen. In ieder geval hadden we het zonder Lelystad en Almere moeten doen!
Betrokken distantie
Als je wel eens een soufflé hebt gebakken, dan weet je dat je tussendoor niet in de
oven moet kijken. Zodra je het ovendeurtje opendoet zakt de soufflé in. Het
eindresultaat is dan een sneue, platte koek die je niet meer aan je gasten wilt
voorzetten. Geduld en terughoudendheid zijn het devies. En natuurlijk moet je
voor ’back-up’ zorgen. Zet de mona-toetjes dus maar alvast koud voor het geval
dat de soufflé mislukt blijkt te zijn.
Wat is betrokken distantie?
Het volgende voorbeeld maakt dat heel duidelijk:
Het was vrijdagavond en er was visite in aantocht. Mijn vrouw en ik waren bezig met de
voorbereidingen. De telefoon ging, het was mijn directe chef: “Reynier, je moet NU naar
het bedrijf komen. Het ‘waarom’ leg ik je straks wel uit; ik moet nog veel meer mensen
bellen.”
Toen ik naar mijn auto liep kwam ik de visite tegen. Gelukkig toonden ze begrip voor de
situatie.
Het bedrijf was in diepe rust, alleen op de tweede etage, het computer centrum, was het
een drukte van belang. Alle ICT-managers en een aantal belangrijke specialisten bleken te
zijn opgeroepen.
Uit de eerste briefing bleek, dat het computer centrum volledig ‘plat’ lag omdat de
‘database catalog’*) van de centrale computer onherstelbaar beschadigd was. Daardoor
kon de computer niet meer ‘zien’ waar alle programma’s, data, indexen, etc. stonden. Om
de ramp compleet te maken, bleken alle back-ups (waarschijnlijk al langere tijd) niet
correct te zijn uitgevoerd en waren daardoor geheel onbruikbaar, hetgeen door slordig
handelend en kennelijk weinig gemotiveerd vloerpersoneel nooit was ontdekt…
Om alle schijven uit te lezen en van daaruit een nieuwe ‘catalog’ op te bouwen, was een
mega klus. Omdat het de dinsdag daarop Koninginnedag was en ook op maandag de zaak
gesloten bleef, waren er 5 dagen beschikbaar om de klus te klaren, maar dan moesten we
wel volledig ‘up and running’ zijn. Het hield tevens in, dat alle databases moesten zijn
bijgewerkt en geverifieerd. Hiervan was het bedrijf volkomen afhankelijk. Zou het langer
dan 5 dagen duren, dan zou er niet geproduceerd kunnen worden en zouden er mogelijk
miljoenen verlies worden geleden. Erger nog, onze naam als grote automatiseerder stond
op het spel; je moest er niet aan denken dat het in de krant zou komen!
Om e.e.a. in goede banen te leiden, werd besloten dat er ‘volcontinue’, in 4 shifts zou
worden gewerkt. Er werd razendsnel een plan in elkaar gesleuteld en elke denkbare,
technische dienst werd ingeschakeld en op scherp gezet. Managers werden in
leidinggevende rollen gezet en losten elkaar, na een nauwgezette briefing, elke 8 uur af.
Ieder uur kwam het operationele ad hoc-managementteam, samen met de specialisten
bijeen om de laatste status te evalueren en zo nodig bij te sturen.
Dit leek een goed georkestreerde aanpak, maar de specialisten begonnen al vrij snel te
klagen over het grote aantal meetings. Zij voelde zich te zeer op de vingers gekeken en
vonden dat ze veel kostbare tijd verloren door elke keer maar weer te moeten opdraven en
aan ‘leken’(in hun beleving) steeds opnieuw tekst en uitleg te moeten geven over de
gemaakte vorderingen.
Wat doe je dan als managementteam?
Doorgaan op de ingeslagen weg leverde wellicht meer informatie op, maar werkte als rem
op de voortgang. Meer ruimte geven betekende minder inzicht en minder mogelijkheden
tot bijsturing. Bovendien moesten wij, op gezette tijden, ook weer verantwoording
afleggen aan het hogere management.
Wij meldden ons bij onze ‘Grote baas’: de ICT-manager en legden dit dilemma aan hem
voor. Hij beschikte over grote managementkwaliteiten en was een wijs man. Hij hield het
hoofd koel. Hij stelde enkele vragen:
Hebben wij de juiste en beste specialisten aan het werk?
Wie van hen heeft het maximale, technische overzicht en kan dus het beste de
leiding op zich nemen?
Is er voldoende mankracht om het werk uit te voeren?
Is de technische ondersteuning in voldoende mate gemobiliseerd?
Toen deze vragen bevredigend beantwoord waren, maakte hij ons duidelijk dat onze rol
een dienende/faciliterende moest zijn, in plaats van een directieve.
Met andere woorden, als de specialisten maar iéts nodig hadden, dan werden wij geacht
dit voor ze te doen. Desnoods het regelen van maaltijden of hun kinderen uit de crèche
halen. Als zij zich maar volledig konden concentreren op die ene doelstelling: het
oplossen van het probleem. Wij mochten ze niet voor de voeten lopen.
De specialisten mochten zelf bepalen wanneer zij het van belang vonden iets aan ons te
rapporteren of aan ons te vragen.
De hogere ICT-manager bleef constant op z’n post en beschouwde het zijn taak om
voldoende tijd en ruimte creëren. Hij deed dit o.a. door een leugentje om bestwil te
verspreiden. Hoewel het probleem overduidelijk was veroorzaakt door menselijk falen,
meldde hij de ‘buitenwereld’ een ‘headcrash’ (dat is wanneer een of meer koppen een
schijf aantikken en beschadigen) de oorzaak was geweest van dit probleem. Technisch
falen dus. Hiermee voorkwam hij dat er (op dat moment) niet relevante en van het
probleem afleidende, discussies over de schuldvraag en de competentie van personeel en
management gevoerd zouden worden. Dat was een zorg voor later (en primair voor hem).
Ook beschouwde hij het tot zijn taak om, terwijl wij allen beheerst werden door de
‘gekte’ van het moment, op enige afstand te blijven, de grote lijnen uit te zetten en
mogelijke alternatieven (de ‘what-if’-vragen) uit te denken.
Is het goed afgelopen? Gelukkig wel. Op 1 mei, enkele uren voordat het bedrijf
ontwaakte, werkte alles weer naar behoren, waren alle databases bijgewerkt en
gecontroleerd. Het bedrijf kon gewoon opstarten en niemand heeft er verder iets van
gemerkt. Sommigen vroegen zich wél af waarom het ICT personeel er 10 jaar ouder
uitzag; zeker een wild weekend gehad…?
De directie was achteraf zeer in z’n nopjes met het verrichtte huzarenstukje. De
belangrijkste specialisten werden als helden behandeld en gedecoreerd.
En de schuldvraag? Zijn er nog koppen gerold? Nee; het betreffende personeel begreep
heel goed wat ze hadden veroorzaakt. Naast beloning en straf bestaat er gelukkig ook nog
zoiets als vakmanschap, beroepseer, voldoening en sociale controle. Dus deze wond
heelde zichzelf.
Dit voorbeeld illustreert dat, op het juiste moment, laten vieren van de teugels beter werkt
dan ze aan te trekken. Dat noemt men betrokken distantie.
Betrokken distantie blijkt dus, in bepaalde omstandigheden, een effectieve
managementstijl te zijn. Je moet het wel durven toe te passen; net als bij het alpineskiën
het onnatuurlijk aanvoelt om je gewicht te verplaatsen naar de dalski (dat hierbij
noodzakelijk is), moet je de natuurlijke neiging, om bij crises de bestuursdruk te
vergroten, onderdrukken.
Bij projecten is dat niet anders. Elk project kent zijn crisismomenten. Sterker nog: veel
projecten zijn een aaneenschakeling van crises. Ook dán is de eerste reflex het verhogen
van bestuursdruk, terwijl het creëren van ruimte, het wegnemen van ‘roadblocks’ en het
zich dienstbaar opstellen tegenover de uitvoerenden, vaak veel effectiever is.
Prince2 heeft het over het besturingsmodel ‘management by exception’, hetgeen lijkt aan
te sluiten bij ‘betrokken distantie’.
In het huidig tijdsgewricht van belonen (bonussen) en straffen is het voor veel managers
moeilijk de ruimte te creëren om deze effectieve managementstijl toe te kunnen passen.
Zij staan immers zelf onder grote bestuursdruk.
Stuurgroepmanagers kiezen helaas maar al te vaak voor een directieve bestuursstijl,
waarbij de projectmanager publiekelijk, in desnoods extra ingelaste
stuurgroepvergaderingen, de oren wordt gewassen.
De projectmanager voelt zich dan gedwongen om defensief te reageren en deze
managementstijl verder door te zetten naar de werkvloer; elk moment kijkt hij in de oven
en loopt kans dat de soufflé daarmee inzakt.
Zijn gedrag is begrijpelijk; hij tracht daarmee een volgende schrobbering te voorkomen of
te beteugelen. Dat lukt vaak niet, want ook de professionals zullen op hun beurt defensief
reageren.
Als je goed kijkt is deze flinkheid wel directief, maar feitelijk ook passief: je schuift het
probleem door naar de werkvloer en vergeet daarbij je rol als ‘facilitator’. Niet erg
‘productief’ dus.
Moet je dan nooit directief zijn? Natuurlijk wel. Deze managementstijl kan in bepaalde
omstandigheden zeer effectief zijn. In alle gevallen blijft het noodzakelijk je er van te
vergewissen dat de uitvoerenden voldoende gefaciliteerd zijn om hun werk te kunnen
doen.
Tenslotte: Over dit onderwerp zijn al meer dan genoeg boeken geschreven. Dit boek gaat
niet primair over managementstijlen en dus laat ik het hierbij.
*) Een ‘database catalog’ bestaat uit meta data waarin definities van database-objecten, zoals basistabellen,
views (virtual tables), synoniemen, waarden, indexen, gebruikers en gebruikersgroepen worden opgeslagen.
4
Radicale beslissingen
Je kunt niet trouwen met een nieuwe partner en ook getrouwd blijven met de oude,
althans in Nederland niet. Zelfs als het wel zou mogen, kun je oprecht de vraag stellen,
hoe succesvol en plezierig zo’n huwelijk zal zijn.
Datzelfde geldt voor de invoering van Prince2. Wanneer een organisatie nog geen
bepaalde methode hanteert, is de invoering van Prince2 vergelijkbaar met een eerste
huwelijk. En zelfs dan is het niet altijd gemakkelijk.
De meeste organisaties echter hebben vaak een, al-dan-niet zelf ontwikkelde, methode
ingevoerd. Deze is historisch gegroeid of afgeleid van een andere, reeds bestaande
methode. Het probleem is nu, dat de werkwijze en (vooral ook) de uitgangspunten en
principes radicaal anders zijn dan zoals die worden aangereikt in Prince2 (zie ook kader).
Het gevolg is dat men de eigen werkwijze gaat ‘verprincen’. Vaak betekent het dat men
reeds gehanteerde documenten Prince2-namen geeft (Project Brief, PID, e.d.) en soms
ook onderwerpen uit de ‘templates’ overneemt.
Veel van dit soort documenten heb ik langs zien komen en daarbij valt op, dat de
samenhang ontbreekt. Wanneer je geluk hebt zijn er wel ‘producten’ opgenomen, maar de
relatie met andere onderwerpen zoals het kostenplaatje, de risico’s en de Business Case
wordt niet gelegd. Veel onderwerpen worden niet (goed) begrepen en dat leidt dan tot
zinloze herhaling van teksten. Dan staat er bijvoorbeeld bij ‘doelstelling’ dezelfde tekst
als bij ‘producten’ en soms ook bij ‘baten’. Ook vallen er ‘gaten’ in het geheel omdat
sommige onderwerpen niet aan bod komen. Gelukkig is er meestal wel een ruime post
‘onvoorzien budget’ gedefinieerd…
Het wordt daardoor een onsamenhangend/weinig transparant geheel.
Merkwaardig is wel, dat ondanks dat, deze documenten wel worden goedgekeurd door
leidinggevenden en Assurance(-achtige) afdelingen of projectbureaus!
In het hoofdstuk (product) ‘1.1.1. Vakbekwame PM’s’ ga ik hier nog nader op in.
Het is dan ook niet zo vreemd dat leidinggevenden graag een beetje afstand van het
project houden, bang als ze zijn er hun vingers aan te branden. Ze delegeren het project zo
snel mogelijk naar een toevallig passerende Project Manager en draaien zich om. Met een
beetje geluk krijgt deze Project Manager wel een goede opdracht en is de opdrachtgever
bereid om
zo nu en dan, vragen te beantwoorden, maar verder moet hij het zelf maar uitzoeken. Het
ontbreekt dan aan actief opdrachtgeverschap !
In een grote internationale, industriële organisatie zijn door mij enkele honderden Project Managers, team- en lijnmanagers opgeleid in de methode Prince2. Een collega van mij heeft workshops ‘opdrachtgeverschap’ op vrijwel alle niveaus van leidinggevenden gegeven. Toch is het nog steeds niet gelukt om de bovengenoemde zeven basisprincipes van Prince2 goed ingevoerd te krijgen:
1 Voortdurende zakelijke rechtvaardiging 2 Leren van ervaringen 3 Gedefinieerde rollen en verantwoordelijkheden 4 Managen per fase 5 Manage by exception 6 Productgerichte aanpak 7 Op maat maken voor de projectomgeving
Dat komt doordat de organisatie al vele jaren gewend is om projecten te doen. Men gebruikt hiervoor een structuur, waardoor lijnmanagement-taken op het bordje komen van de Project Managers; zij schrijven alle documenten, waaronder de Business Case en zij moeten ‘handtekeningen jagen’ om budget te verkrijgen. Tijdens de uitvoering van het project , bemoeien de managers van de betreffende bedrijfseenheid zich daar zo min mogelijk mee. Men benoemt een contactpersoon om met name het technische deel te begeleiden en verder wil men zo min mogelijk ‘last’ hebben van het project. Toch wil men het projectmanagement-traject verbeteren met Prince2. Het mag echter niet botsen met de hierboven beschreven gang van zaken. Er zijn inderdaad verbeteringen doorgevoerd, zoals Project Boards voor projecten, waarbij men redelijk rolvast is. In een enkel geval wordt ‘product-based planning’ toegepast, maar dat is niet voorgeschreven . De werkelijke omslag is niet gemaakt. Daarmee mist deze organisatie helaas de ‘full benefits’ van de methode.
De boodschap is dus: van hoog tot laag moet de organisatie worden aangepast, opgeleid
en begeleid om de methode succesvol te kunnen toepassen. Er moet dus een plan
worden: gemaakt, uitgevoerd en stap voor stap in de praktijk worden begeleid om, van
de eerder gehanteerde methode, te komen tot de nieuwe. Wanneer het goed wordt
aangepakt, zul je zien dat er een soort ‘tipping-point’ komt en dan kun je de strategie
aanpassen van ‘push’ naar ‘pull’.
Mijn ervaring is dat een ‘top-down-/ bottom-up’-benadering het meest effectief is. In de
komende hoofdstukken wordt uitgelegd hoe zoiets kan worden aangepakt.
Het meest effectief is om de oude methode geheel vaarwel te zeggen.
Op z’n minst moet alles worden losgelaten, dat tegenstrijdig is met (de principes van)
Prince2.
Top Related