Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

PRINCE2™ voor opdrachtgevers Management Guide

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net 00_PRINCE2_MG_v1.indd I

01-08-2007 15:44:06

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-management, - Architecture (Enterprise en IT), - Business management en - Projectmanagement. Deze uitgaven worden uitgegeven in verschillende talen in series, zoals ITSM Library, Best Practice, IT Management Topics en I-Tracks. VHP is tevens de uitgever voor toonaangevende instellingen en bedrijven, onder andere The Open Group, PMI-NL, IPMA-NL, CA, Getronics, Pink Elephant. Onderwerpen per domein zijn:

IT (Service) Management / IT Governance

Architecture (Enterprise en IT)

Project-, Programmaen Riskmanagement

ASL BiSL CATS CMMI COBIT ISO 17799 ISO 27001 ISO/IEC 20000 ISPL IT Service CMM ITIL® V2 ITIL® V3 ITSM MOF MSF

Archimate TOGAFTM

A4 Projectmanagement ICB / NCB MINCE® M_o_R® MSP NCB PMBoK PRINCE2®

Business Management EFQM ISA-95 ISO 9000 SixSigma SOX SqEME®

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


PRINCE2™ voor opdrachtgevers Management Guide 3de druk

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net 00_PRINCE2_MG_v1.indd III

01-08-2007 15:44:07

Colofon Titel:

PRINCE2™ voor opdrachtgevers – Management Guide

Auteur:

Michiel van der Molen

Redactie:

Inform-IT

Uitgever:

Van Haren Publishing ([email protected])

ISBN(13):

978 90 77212 99 8

Druk:

Derde druk, eerste oplage, oktober 2006 Derde druk, tweede oplage, augustus 2007 Derde druk, derde oplage, januari 2009

Vormgeving & opmaak:

CO2 Premedia bv, Amersfoort - NL

De eerste en tweede druk van dit boek zijn eerder verschenen onder de titel “Hoe haal ik het beste uit mijn project? Prince2 voor opdrachtgevers” (Lemma, 2003, 2005) Dit boek is ook verschenen in Engelse vertaling onder de titel “PRINCE2 for the Project Executive” (TSO, 2006)

© Crown copyright material taken from the Office of Government Commerce publication, Managing Succesful Projects with PRINCE2, is reproduced with the permission of the Controller of HMSO and Queen’s Printer for Scotland. © All rights reserved. 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. Niets uit deze uitgave mag worden verveelvoudigd en/of openbaar gemaakt door middel van druk, fotokopie, microfilm of op welke andere wijze ook, zonder voorafgaande schriftelijke toestemming van de uitgever. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Dankwoord De volgende personen hebben een bijdrage geleverd aan de totstandkoming van dit boek. Professionele begeleiding en waardevolle advisering bij het opstellen van de eerste versie van dit boek: Ad van den Akker (Lagant Management Consultants, Nederland) Vakinhoudelijke review: Ad van den Akker (Lagant Management Consultants, Nederland) Martin de Boer (UWV, Nederland) Paul Bogerd (Minase, Nederland) Pritam Chita (Napier University, Best Practice User Group, Groot Brittannië) Jos Dams (Dienst Stedebouw en Volshuisvesting Stad Rotterdam, Nederland) Brigit Darlang (Ordina, Nederland) Peter Deadman (Vodafone, Best Practice User Group, Groot Brittannië) Stephen Edwards (Project Angels Limited, Best Practice User Group, Groot Brittannië) Alvin Gardiner (PR-02, Best Practice User Group, Groot Brittannië) Herman Hanekamp (Gemeentelijk Havenbedrijf Rotterdam, Nederland) Karen Harland (Manchester City Council, Best Practice User Group, Groot Brittannië) Dick La Haye (Ministerie van Sociale Zaken en Werkgelegenheid, Nederland) Wil Hendrickx (Lagant Management Consultants, Nederland) Peter Keneghan (Keneghan Consulting Limited, Best Practice User Group, Groot Brittannië) Peter Koers (TNO, Nederland) Kim van Oorschot (INSEAD, Frankrijk) Albert Peek (Ventoux, Nederland / Prince User Group, Nederland) Sylvie Rath (WagenaarHoes Organisatieadvies, Nederland) Wim Vleeskens (Architectenbureau Wim Vleeskens BNA, Nederland) David EJ Wilson (Rouen International School, Frankrijk) Deelname aan een workshop met de auteur om meer inzicht te krijgen in projecten met meer dan één opdrachtgever: Paul Bogerd (Minase, Nederland) Jaap de Koning (Witteveen+Bos, Nederland) Ernst Molier (Witteveen+Bos, Nederland)


Inhoudsopgave 1 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8

Inleiding .............................................................................................1 Wat is een project? ..........................................................................................1 Wat is PRINCE2? ............................................................................................1 Waarom PRINCE2? ........................................................................................2 Wat is een opdrachtgever? ..............................................................................3 Waarom dit boek? ...........................................................................................3 Waar gaat dit boek over? .................................................................................4 Waar gaat dit boek niet over? ..........................................................................4 Leeswijzer .......................................................................................................5

2 2.1 2.2 2.3 2.4 2.5

Vijf best practices voor strategische projectbesturing .............................7 Sturen op basis van de Business Case .............................................................8 Betrekken van belanghebbenden in de projectbesturing .............................13 Verdelen van het project in managementfasen ............................................20 Sturen op uitzonderingen .............................................................................24 Sturen op producten .....................................................................................28

3 3.1 3.2 3.3

3.6

De Project Board nader bezien .......................................................... 31 Wie moeten zitting nemen in de Project Board?..........................................31 De Project Board in de context van de organisatie ......................................37 Hoe kan ik de opdrachtgeverrol efficiënter vervullen zonder grip te verliezen? ...........................................................................................39 Hoe kan ik de opdrachtgeverrol delegeren? .................................................45 Hoe kan ik gebruikers er optimaal bij betrekken en toch slagvaardig blijven? .......................................................................................49 Kan een project meer dan één opdrachtgever hebben?................................51

4 4.1 4.2 4.3 4.4 4.5

Het aansturen van de projectmanager ................................................ 55 Welke verantwoordelijkheden delegeer ik aan de projectmanager? ............ 55 Welke toleranties kan ik een projectmanager toestaan? ..............................58 Welke verantwoordelijkheden houdt de Project Board zelf ?.......................59 Hoe voorkom ik dat een projectmanager oncontroleerbaar wordt? ...........61 Hoe beoordeel ik de kwaliteit van een voortgangsrapportage? ...................65

3.4 3.5

VI Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

PRINCE 2 VOOR OPDRACHTGEVERS

- MANAGEMENT GUIDE

5 5.1 5.2

De rol van externe leveranciers .......................................................... 71 Moet ik een externe leverancier in de projectbesturing betrekken? .............71 Hoe voorkom ik dat een externe projectmanager oncontroleerbaar wordt? ..............................................................................74

6 6.1 6.2 6.3

Omgaan met onzekerheden ............................................................... 77 Hoe zorg ik dat risico’s goed beheerst worden? ...........................................77 Hoe houd ik controle als ik bij de start niet weet wat de specificaties zijn?.79 Hoe houd ik een project beheersbaar bij wijzigingen in de specificaties? ...80

7 7.1 7.2 7.3 7.4 7.5 7.6 7.7 7.8

Waarom eindigen projecten vaker boven dan beneden budget? Wat doe ik daartegen? ....................................................................... 83 Voortschrijdend inzicht van gebruikers ........................................................84 Eenzijdige invloed van specialisten...............................................................85 Dynamiek in de projectomgeving ................................................................85 Onvoldoende projectbeheersing...................................................................86 Blinde vlekken in de planning.......................................................................86 Wet van Parkinson ........................................................................................88 Vertraging in de besluitvorming...................................................................91 Prijsopdrijving door een leverancier .............................................................91

8 8.1 8.2 8.3 8.4

Valkuilen bij de toepassing van PRINCE2 .......................................... 93 Onterechte projectmatige aanpak ................................................................93 Te uitgebreide toepassing van PRINCE2......................................................93 Te formele toepassing van PRINCE2 ...........................................................95 PRINCE2 als wondermiddel.........................................................................98

9 9.1 9.2

Woordenlijst ................................................................................... 101 Verklarende woordenlijst............................................................................ 101 Vertaallijst Nederlands-Engels .................................................................... 107

10

Literatuurlijst ................................................................................. 109 Index .............................................................................................. 111


VII


- MANAGEMENT GUIDE

Voorwoord Als projectmanager ben ik betrokken geweest bij projecten in een veelheid van branches en in diverse landen. Het viel me daarbij steeds weer op, dat de manier waarop de opdrachtgever zijn rol vervult een grote invloed heeft op de kans van slagen van een project. Bij sommige opdrachtgevers is het een gespreid bedje, anderen lijken er een mission impossible van te maken. Net als veel projectmanagers heb ik wel eens in wanhoop verzucht: waarom nemen ze niet gewoon een besluit, zo moeilijk kan het toch niet zijn? Later in mijn loopbaan, toen ik als lijnmanager de rol van opdrachtgever vervulde, merkte ik dat dit toch niet zo eenvoudig was. Ik had voor mijn gevoel nooit voldoende tijd om het project goed te volgen. Veranderingen in de omgeving haalden mij telkens in. Tegelijk werd ik afgerekend op het projectsucces in de breedste zin. Goed opdracht geven aan projecten bleek minstens zo’n uitdaging als goed projectmanagement. Het is daarom verrassend dat er voor opdrachtgevers zo weinig informatie beschikbaar is over hoe zij hun rol optimaal kunnen vervullen. Het lijkt wel of het hele vakgebied projectmanagement zich richt op de rol van de projectmanager. Een van de redenen, waarom PRINCE2 mij direct aansprak toen ik het leerde kennen, was dan ook dat deze methode als geen andere ondersteuning bood aan de rol van de opdrachtgever. Sterker nog: de hele methode bleek vormgegeven vanuit de optiek en het belang van de opdrachtgever. Het leek daarom een goed idee een boek voor opdrachtgevers op PRINCE2 te baseren, en eerdere edities van dit boek bleken inderdaad in een grote vraag te voorzien. De workshops, die op basis van het boek in tal van organisaties gehouden zijn, hebben inmiddels bevestigd dat veel opdrachtgevers vergelijkbare behoeften hebben: meer grip op hun project met minder moeite, en beter omgaan met veranderingen. Dit boek biedt daarbij de helpende hand. Bij de professionalisering van projectmatig werken in organisaties is de aandacht vaak te eenzijdig gericht op de rol van projectmanagers. De ervaring leert dat wanneer tegelijk aandacht wordt besteed aan de rol van opdrachtgevers, een wezenlijke versnelling van het veranderingsproces bereikt kan worden. Moge dit boek daaraan bijdragen. Professionalisering van opdrachtgeverschap is nog steeds een nauwelijks ontgonnen gebied. Ik nodig dan ook een ieder uit, zijn vragen en commentaren met mij te delen, zodat het gezamenlijk inzicht kan groeien.

VIII Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


- MANAGEMENT GUIDE

Ik wil al diegenen die genoemd worden als adviseurs of reviewers hartelijk danken voor hun onmisbare bijdrage. Michiel van der Molen, oktober 2006 [email protected]

Ir. Michiel J. van der Molen studeerde bouwkunde en heeft een brede ervaring met projecten op het gebied van stadsvernieuwing, ICT en organisatieverandering. Hij was daarbij werkzaam voor de locale en centrale overheid, in de industrie, in de zakelijke en financiële dienstverlening en in de detailhandel. Hij vervulde rollen als project-, interim- en lijnmanager, adviseur en docent en was werkzaam in Nederland, Duitsland en België. Hij heeft een aantal jaren leiding gegeven aan projectmanagers. Hij is nu werkzaam bij Lagant Management Consultants en houdt zich als adviseur en trainer bezig met de inrichting van professioneel projectmanagement in organisaties.


IX


HOOFDSTUK 1

Inleiding 1.1 Wat is een project? Projectmatig werken is populair. De kans is groot dat u als manager vroeg of laat in de rol van opdrachtgever betrokken raakt bij een project. De aanleiding voor het starten van een project is altijd de behoefte aan - of de noodzaak tot - verandering. Het kan bijvoorbeeld gaan om veranderingen van organisatiestructuur, werkprocessen, productiemiddelen, huisvesting of computersystemen. Men start een project om dergelijke veranderingen op een doelgerichte manier aan te pakken.

Het begrip ‘project’ kent tal van definities. Elementen van de meeste definities zijn: • een tijdelijke organisatie • gericht op het tot stand brengen van een uniek en vooraf gedefinieerd resultaat • met beperkte middelen en binnen een beperkte tijd

1.2 Wat is PRINCE2? PRINCE (PRojects IN Controlled Environments) werd als methode voor effectief projectmanagement in 1989 ontwikkeld door de Britse Central Computer and Telecommunications Agency (CCTA) als standaard voor alle ICT-projecten van de Britse overheid. Het is samengesteld als een verzameling best practices voor projectmanagement en bijgesteld op basis van reviews door opdrachtgevers, gebruikers en projectmanagers. Later werd het beheer van de methode overgenomen door het Office of Government Commerce (OGC) en werd de methode ontdaan van alle ICT-gerelateerde zaken. Zo ontstond PRINCE2: een algemeen toepasbare projectmanagementmethode, in toenemende mate ook buiten de ICT-branche gebruikt. De methode is geschikt voor grote, complexe projecten. De methode kan naar eigen inzicht worden aangepast ten behoeve van kleine c.q. eenvoudige projecten.


1


- MANAGEMENT GUIDE

Meest gebruikt

PRINCE2 heeft zich als projectmanagementmethode de laatste jaren in een groeiend aantal Europese landen ontwikkeld tot een feitelijke standaard. In Engeland en Nederland is PRINCE2 de meest gebruikte projectmanagementmethode. In Frankrijk, Italië, Duitsland, Polen en de Scandinavische landen neemt het gebruik snel toe. Buiten Europa wordt de methode onder meer gebruikt in de Verenigde Staten, Australië, Hong Kong, Singapore en Indonesië.

1.3 Waarom PRINCE2? Methodes werken niet: alleen mensen werken. Dat is een waarheid als een koe, in die zin dat het gebruik van een methode niets garandeert. PRINCE2 is bovendien geen kanten-klaar bruikbare methode. Het is een samenhangend geheel van methoden en werkwijzen op basis waarvan voor iedere omgeving en voor ieder project een goede aanpak gekozen kan worden. Dat vereist vakkennis, ervaring en gezond verstand. PRINCE2 is dus geen eenvoudig ‘standaardrecept voor succes’, maar slechts een hulpmiddel dat - mits deskundig toegepast - uw organisatie kan ondersteunen in het realiseren van haar doelstellingen. In de praktijk noemen opdrachtgevers van projecten een aantal voordelen van het gebruik van de methode. PRINCE2: • is een krachtig hulpmiddel om tot een gestructureerde aanpak te komen; • geeft een goed inzicht in de voortgang van projecten; • geeft een heldere verdeling van verantwoordelijkheden tussen betrokkenen; • maakt een systematisch risicomanagement mogelijk; • biedt goede ondersteuning voor kwaliteitsbeheersing; • is efficiënt door hergebruik van technieken en templates (sjablonen); • biedt een gemeenschappelijke taal, waardoor informatie en mensen uitwisselbaar zijn tussen projecten; • is goed schaalbaar, afhankelijk van de grootte en complexiteit van een project; • en wellicht het belangrijkste voordeel: PRINCE2 helpt een business focus van projecten te creëren en te behouden. Dat wil zeggen: het helpt projecten in iedere fase af te stemmen op de doelstellingen van de organisatie, ook wanneer deze doelstellingen tijdens de uitvoering van het project veranderen. Maar nogmaals: realisatie van al deze voordelen is afhankelijk van een juiste toepassing van de methode. 2 Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


- MANAGEMENT GUIDE

1.4 Wat is een opdrachtgever? De term ‘opdrachtgever’ wordt op twee manieren gebruikt: • als aanduiding van de persoon, vaak een lijnmanager, die de projectmanager aanstuurt bij de uitvoering van een project ('projectopdrachtgever'); • als aanduiding van de organisatie die een opdracht uitbesteedt aan een leverancier ('contractopdrachtgever'). Dit boek gebruikt, tenzij anders vermeld, de term opdrachtgever in de eerste betekenis, die van een persoon die een projectmanager aanstuurt. Deze projectmanager kan afkomstig zijn uit de eigen organisatie of van een leverancier. In sommige omgevingen is het niet eenvoudig de opdrachtgever te onderscheiden van andere belanghebbenden. Een onderscheidend verschil met andere belanghebbenden is dat voor een opdrachtgever een project een investering is. Hij zal deze investering alleen doen indien (in de breedste zin) de kosten door de baten gerechtvaardigd worden. Andere belanghebbenden nemen geen investeringsbeslissing maar ondervinden wel voordeel of nadeel tengevolge van een project. Een opdrachtgever is actief betrokken bij de projectbesturing. Dit boek gebruikt de term ‘financier’ of ‘sponsor’ voor personen of partijen die wel geld in een project steken, maar zich niet actief met de besturing bezighouden.

1.5 Waarom dit boek? Wie wat wil weten over de projectmanagementmethode PRINCE2 kan uit verschillende inleidingen en handleidingen kiezen. Deze hebben over het algemeen gesproken één ding gemeen: ze hebben als belangrijkste doelgroep de projectmanagers die verantwoordelijk zijn voor de uitvoering van projecten. Deze projectmanagers kunnen daarmee leren met behulp van PRINCE2 op succesvolle wijze een project te leiden. Dit boek richt zich echter op opdrachtgevers van projecten omdat u als opdrachtgever andere informatie nodig hebt en omdat u niet precies hoeft te weten hoe de methode werkt. Vanuit dat perspectief zullen de volgende vragen voor u belangrijk zijn: • Hoe veranker ik de besturing van een project in de omgeving? • Hoe kan ik gebruikers optimaal betrekken en toch slagvaardig blijven? • Welke verantwoordelijkheden delegeer ik aan de projectmanager? • Hoe voorkom ik dat een projectmanager oncontroleerbaar wordt? • Hoe kan ik de opdrachtgeverrol efficiënter vervullen zonder mijn grip te verliezen? Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

3


• • • • •

- MANAGEMENT GUIDE

Hoe houd ik controle als ik bij de start nog niet precies weet wat de specificaties zijn? Hoe houd ik een project beheersbaar in geval van wijzigingen? Welke rol geef ik een externe leverancier in de projectbesturing? Waarom eindigen projecten vaker boven dan beneden budget? Wat kan ik daar als opdrachtgever tegen doen? Kortom: hoe kan ik PRINCE2 in mijn voordeel gebruiken?

1.6 Waar gaat dit boek over? Dit boek gaat over projectbesturing. Projectbesturing heeft betrekking op de activiteiten van de opdrachtgever die er onder andere op gericht zijn de projectmanager goed aan te sturen, en meer in het algemeen: op het scheppen van omstandigheden waaronder een project optimaal kan bijdragen aan de doelstellingen van de opdrachtgevende organisatie. Specifiek gaat dit boek over hoe de opdrachtgever PRINCE2 optimaal kan gebruiken in de projectbesturing. Dit boek gaat over de beginselen van projectbesturing met behulp van PRINCE2, ervan uitgaande dat u, waar nodig, voor detailkennis van de methode terecht kunt bij de projectmanager.

1.7 Waar gaat dit boek niet over? Dit boek gaat niet over het managen van een project. Het managen van een project heeft betrekking op de activiteiten van de projectmanager die verantwoordelijk is voor de operationele aansturing van de in het project ingezette medewerkers en/of leveranciers. Dit boek gaat ook niet over programmamanagement en portfoliomanagement. Programmamanagement heeft betrekking op het realiseren van een strategische doelstelling, in het kader waarvan een aantal projecten wordt bestuurd en organisatorische veranderingen worden gecoördineerd. Portfoliomanagement is gericht op het besturen van de totale projectportfolio van een organisatie, of, volgens een andere definitie, op het besturen van de projectportfolio binnen een programma. Contractmanagement komt ook niet aan de orde. Contractmanagement heeft betrekking op het beheersen van de zakelijke relatie tussen een klant en een leverancier. 4 Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


- MANAGEMENT GUIDE

1.8 Leeswijzer Hoofdstuk 2 behandelt de grondslagen van PRINCE2 die van belang zijn voor opdrachtgevers: vijf best practices voor strategische projectbesturing. Dit hoofdstuk verschaft de basiskennis die nodig is om de volgende hoofdstukken te kunnen begrijpen. De hoofdstukken 3 tot en met 8 gaan over de praktijk en zijn er op gericht u te helpen het beste uit uw project te halen. Een groot aantal praktische vragen wordt hier behandeld vanuit het perspectief van de opdrachtgever. U kunt iedere selectie van deze paragrafen in iedere gewenste volgorde lezen. Omschrijvingen van de gebruikte vaktermen vindt u in de verklarende woordenlijst in hoofdstuk 9. PRINCE2-termen zijn in de tekst met hoofdletters weergegeven.


5


- MANAGEMENT GUIDE

6 Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

HOOFDSTUK 2

Vijf best practices voor strategische projectbesturing Veel managers zien zich gesteld voor een veelzijdige uitdaging. Zij moeten de lopende zaken onder hun verantwoordelijkheid aansturen, vaak onder druk om meer te presteren tegen lagere kosten. Ze moeten een visie op de toekomst ontwikkelen. Zij moeten ad hoc problemen oplossen in een vaak turbulente omgeving. Soms dragen zij temidden van al die turbulentie ook nog de verantwoordelijkheid voor de resultaten van een of meer projecten. In dat geval is het nodig om deze projecten met relatief weinig inspanning goed onder controle te houden. Tegelijkertijd moet de aansluiting van de projectresultaten op de doelstellingen van opdrachtgevende organisatie verzekerd zijn. Kortom: wat u nodig hebt als opdrachtgever is een efficiënte en effectieve manier om projecten te besturen. Dit hoofdstuk beschrijft vijf best practices die er op gericht zijn aan deze eisen te kunnen voldoen: • sturen op basis van een Business Case1 (paragraaf 2.1) • betrekken van vertegenwoordigers van belanghebbenden in de projectbesturing (paragraaf 2.2) • verdelen van het project in managementfasen (paragraaf 2.3) • sturen op uitzonderingen (paragraaf 2.4) • sturen op producten (paragraaf 2.5)

1

In veel organisaties in Nederland waar PRINCE2 wordt toegepast, heeft men er in beginsel voor gekozen de Engelstalige PRINCE2- en aanverwante vaktermen te gebruiken. Dit boek sluit daar op aan. Voor diegenen die de Nederlandstalige termen gebruiken: excuus voor het ongemak. In de Verklarende Woordenlijst achterin dit boek staat achter iedere Engelstalige PRINCE2-term de Nederlandse vertaling en een omschrijving. Aansluitend is een vertaallijst Nederlands - Engels opgenomen. Overigens is dit boek - alweer: in navolging van wat in veel organisaties gebruikelijk is - niet consequent in het gebruik van de Engelstalige termen. Termen als Project Plan en Project Manager zijn gedefinieerde PRINCE2-termen, maar in dit boek wordt omwille van de leesbaarheid gebruik gemaakt van projectplan en projectmanager. Omwille van de leesbaarheid wordt ook in sommige gevallen naast de Engelstalige term de Nederlandstalige term gebruikt (bijvoorbeeld naast ‘Executive’ ook ‘opdrachtgever’).


7


- MANAGEMENT GUIDE

2.1 Sturen op basis van de Business Case De maatstaf voor succes van een project is de mate waarin de resultaten bijdragen aan de organisatiedoelstellingen Temidden van alle veranderingen zijn steeds meer opdrachtgevers gaan beseffen dat het succes van een project niet bepaald wordt door de vraag of de oorspronkelijke doelstelling exact gerealiseerd wordt. Het gaat er steeds meer om dat de koers tijdig wordt bijgesteld op basis van veranderde inzichten en veranderingen in de omgeving, de markt of de organisatie. Het referentiekader voor projectbesturing is daardoor veranderd. Het is niet meer voldoende de voortgang van een project te toetsen ten opzichte van de oorspronkelijke planning en doelstelling. Het is steeds belangrijker een project ook regelmatig te toetsen op de vraag of het de doelstellingen van de opdrachtgevende organisatie nog optimaal ondersteunt. Modern projectmanagement is schieten op bewegende doelen. Levenscyclus

Om deze laatste toetsing goed te kunnen uitvoeren baseert PRINCE2 de projectbesturing op de Business Case (zakelijke rechtvaardiging) van het project: een beschrijving van de manier waarop, en de mate waarin, het project zal bijdragen aan de algemene doelstellingen van de opdrachtgevende organisatie. Welbeschouwd gaat het natuurlijk niet om het project zelf: dit is doorgaans een investering, een noodzakelijk kwaad dat zijn baten pas opbrengt wanneer de resultaten in gebruik zijn genomen. Het gaat dus om de Business Case van de gehele levenscyclus van het te realiseren product, om het antwoord op de vraag: Waarom verwachten we dat de gehele levenscyclus van een product de organisatie meer zal opleveren dan kosten, en hoeveel is dat dan? Aan de kostenzijde van deze berekening kunnen we posten aantreffen als ontwikkelkosten, inkoopkosten, licentiekosten, omzetderving tijdens omstelling van een productieproces, invoeringskosten en onderhoudskosten. Aan de batenzijde kunnen we posten aantreffen zoals kostenreductie, lagere uitval in de productie, lager verzuim van het personeel, hogere omzet en imagoverbetering. In de publieke sector kunnen baten bijvoorbeeld bestaan uit verbetering van dienstverlening aan burgers, gezondheidszorg, milieuzorg of veiligheid.

In sommige gevallen is de Business Case gelegen in een wettelijke verplichting of andere externe noodzaak, bijvoorbeeld wanneer bedrijven hun bedrijfsbesturing (corporate governance) in overeenstemming moeten brengen met internationale wetgeving. Dit zijn doorgaans de sterkste Business Cases: bij het niet uitvoeren



- MANAGEMENT GUIDE

van zulke projecten is de continuïteit van de organisatie in het geding. Volgens onderzoek van Gartner2 bestaan de IT-projectportfolio’s van organisaties gemiddeld voor 67% uit diverse soorten ‘verplichte nummers’; slechts 33% van de IT-projecten leidt tot verbetering van de bedrijfsvoering. De ‘verplichte’ projecten moeten nauwkeurig op de Business Case gestuurd worden (dat wil in dit geval zeggen: alleen doen wat noodzakelijk is, en dat zo efficiënt mogelijk), omdat anders - gezien hun relatieve aandeel in de gehele portfolio - onvoldoende middelen overblijven voor de minderheid aan projecten die wel aanwijsbaar bijdraagt aan verbetering van de bedrijfsvoering en versterking van de positie van de organisatie.

Kwantitatief

Hoe concreter de Business Case van een project aansluit op de hoofddoelstellingen van de opdrachtgevende organisatie, des te sterker de positie van het project is. Om dit te bereiken, verdient het in ieder geval de voorkeur dat een Business Case kwantitatief is. Als de hoofddoelstelling van de organisatie financieel is, is de Business Case uiteraard het sterkste wanneer deze financieel gekwantificeerd is. Vaak zal de financiële waardering van de baten deels op veronderstellingen berusten. Welke financiële voordelen verwacht men bijvoorbeeld van imagoverbetering (meer klandizie? hogere omzet? minder prijsconcurrentie?) of hogere medewerkertevredenheid (lager ziekteverzuim? minder personeelsverloop? hogere kwaliteit en minder herstelkosten?). Door deze veronderstellingen expliciet te kwantificeren wordt de Business Case concreet bespreekbaar en kan deze aan kracht winnen. Wanneer daarentegen de hoofddoelstelling van de opdrachtgevende organisatie niet financieel van aard is, zal een financieel gekwantificeerde Business Case misschien minder indruk maken. Het is dan overtuigender de baten van het project te beschrijven in dezelfde termen als die waarin de organisatiedoelstelling geformuleerd is. Mocht het project toch alleen financiële baten hebben, dan is het zinvol om na te gaan hoe deze financiële baten ten goede komen aan de feitelijke doelstelling van de organisatie.

Woningcorporaties hebben over het algemeen een sociale doelstelling: het verschaffen van goede huisvesting aan mensen met lage inkomens. Tegenwoordig verkopen zij soms een deel van hun woningvoorraad met winst aan de bewoners,

2

Light, M., Rosser, B. & Hayward, S. (2005), Realizing the Benefits of Project and Portfolio Management. Gartner Strategic Analysis Report.


9


- MANAGEMENT GUIDE

iets wat op zichzelf hun doelstellingen niet ondersteunt. De rechtvaardiging van deze verkooptransacties is gelegen in het feit dat de te verkopen huizen bewoond worden door bewoners die niet meer tot de doelgroep van de woningcorporaties behoren, terwijl de winst gebruikt wordt voor het bouwen en onderhouden van andere woningen voor mensen die wel tot de doelgroep behoren. Een sterke Business Case zou in dit voorbeeld niet ophouden bij de berekening van de financiële winst op de verkoop, maar ook aangeven hoe de sociale doelstelling van de corporatie met de winst op deze transactie ondersteund wordt.

Zakelijke onderbouwing van besluiten

De Business Case wordt bij aanvang expliciet beschreven en vervolgens onderhouden. De aanpak en uitvoering van het project worden hier vervolgens volledig op afgestemd. De Business Case is voor alle betrokkenen het gemeenschappelijk referentiekader voor beslissingen over een project. Projectbesturing kan hierdoor gebaseerd worden op een zakelijke onderbouwing in plaats van op een subjectieve inschatting. Het schrijven van de Business Case is een taak die u als opdrachtgever zelf op u kunt nemen, maar die u in veel gevallen zult delegeren aan de projectmanager of aan een stafmedewerker. Toch kan het samenstellen van een Business Case niet geheel aan specialisten worden overgelaten. De belangrijkste input hiervoor - waarom doet u het project en welke baten verwacht u - zult u alleen zelf kunnen leveren. Hoe komt de Business Case tot stand?

In de initiële opdracht aan de projectmanager is het belangrijk de Business Case globaal te benoemen. Dit is uw verantwoordelijkheid als opdrachtgever. Het is belangrijk de projectmanager te informeren over de verschillende aspecten van de Business Case en deze in de Project Brief (projectvoorstel) globaal te laten beschrijven. Het is op basis van de Project Brief dat u toestemming geeft om de projectinrichting te starten. Dit betekent dat u de projectmanager op dat moment een budget ter beschikking stelt voor de eerste fase. Deze eerste fase heeft ten doel een plan uit te werken, zodat de opdrachtgever een gefundeerde beslissing kan nemen over de start van de uitvoering. In deze fase wordt de Business Case tot in detail uitgewerkt, of bij een klein project zover als nodig is om voortgangsbeslissingen op te baseren.

Om binnen een grote organisatie aan een budget te komen worden veelal alle mogelijke baten van een project opgesomd, zowel kwantitatief als kwalitatief. Er ontstaat dan een meervoudige Business Case, met als baten bijvoorbeeld



- MANAGEMENT GUIDE

kortere levertijden, efficiencyverbetering en imagoverbetering. Dit kan er toe leiden dat bij betrokkenen de werkelijke prioriteiten niet meer duidelijk zijn. Voor efficiënte besluitvorming kan dit een belemmering vormen. Ieder issue dat vraagt om een afweging tussen de verschillende soorten baten (bijvoorbeeld efficiency tegen imagoverbetering) kan dan aanleiding zijn tot een nieuwe discussie over prioriteiten. Om de energie van een stuurgroep en de projectgroep te focussen, is het daarom van groot belang om in het geval van een meervoudige Business Case een prioriteitenstelling aan te brengen. Bijvoorbeeld: ‘de drijvende kracht achter dit project is imagoverbetering, de overige baten zijn secundair.’ Een heldere Prioriteitenstelling is een voorwaarde voor actief leiderschap van de opdrachtgever.

Opdrachtgevers vinden het niet altijd noodzakelijk of wenselijk dat de projectmanager de Business Case kent, bijvoorbeeld wanneer het gaat om de projectmanager van een externe leverancier aan wie een project is uitbesteed. Wanneer u als opdrachtgever in staat bent de leverancier volstrekt heldere specificaties van de op te leveren producten ter beschikking te stellen en volledig zelf bewaakt of er aanleiding is tot bijstelling, dan is dit inderdaad niet noodzakelijk. Dit heeft gevolgen voor de inrichting van de projectorganisatie en de manier van besturen van het project. In paragraaf 5.1 wordt daar verder op ingegaan. Hoe wordt de Business Case onderhouden?

Gedurende de looptijd van het project wordt de Business Case in ieder geval getoetst aan het einde van iedere projectfase. De aannames wat betreft de kwantificering worden getoetst, want er kan sprake zijn van voortschrijdend inzicht waardoor de Business Case nauwkeuriger en met meer zekerheid geformuleerd kan worden. Daarnaast kunnen er andere aanleidingen zijn om de Business Case te toetsen en eventueel bij te stellen: nieuwe ontwikkelingen in de omgeving van het project, gewijzigde risico’s of onverwachte kosten. Het is een verantwoordelijkheid van de opdrachtgever om alert te blijven op relevante ontwikkelingen in de omgeving van het project die de Business Case zouden kunnen beïnvloeden.

‘De projectmanager stelde voor haar opdracht te wijzigen in de overtuiging dat zij ons op een andere manier beter van dienst kon zijn en nog wel tegen lagere kosten. Ze bleek gelijk te hebben. Hoewel zij daarmee strikt genomen niet binnen haar opdracht handelde, heeft ze juist daardoor een bijzondere bijdrage aan de organisatie geleverd. Een ons Business Case is meer waard dan een kilo besteld product.’ Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

11


- MANAGEMENT GUIDE

Toetsing op basis van de Business Case

Bij het besluit over het starten van een nieuwe fase van het project toetst u als opdrachtgever het project op basis van de actuele Business Case. U beoordeelt of het project nog bestaansrecht heeft en of eventueel bijstelling van de geplande projectresultaten of aanpak noodzakelijk is. Na afronding van het project is het van belang als opdrachtgevende organisatie te leren van het project. Het draait dan onder andere om de vraag of de geplande resultaten binnen de geldende voorwaarden (tijd, geld, kwaliteit) geleverd zijn. Antwoorden op deze vraag kunnen bijvoorbeeld leiden tot conclusies over de gevolgde aanpak of de kwaliteiten van een betrokken leverancier. Zeker zo belangrijk echter is een toetsing van de Business Case achteraf, ofwel: in welke mate is de beoogde bijdrage van de projectresultaten aan de organisatiedoelstellingen gerealiseerd? Dit kan men pas vaststellen wanneer de baten zichtbaar zijn, dus nadat het project al enige tijd is afgerond en het resultaat in gebruik is genomen. Antwoorden op deze vraag kunnen bijvoorbeeld leiden tot conclusies over de kwaliteit van de besluitvorming, tot een beter inzicht in de bedrijfsprocessen of tot inzicht in de behoefte aan nadere aanpassingen van de resultaten. En natuurlijk kan deze toetsing ook leiden tot conclusies over de kwaliteit van de Business Case zelf.

Veel ervaren projectmanagers kunnen verhalen vertellen over projecten die achteraf geen goede Business Case bleken te hebben: ‘Het project is volledig volgens plan verlopen. Toch is het eindresultaat nooit in gebruik genomen.’

‘In onze organisatie wordt sterk op kosten gestuurd en dat merk je ook bij projecten: voordat je het weet gaat ook daar alle aandacht naar de kosten. We weten tot achter de komma wat een project kost en slaan alarm bij vijf procent kostenoverschrijding. Tegelijk merken we het niet eens wanneer een project vijftig procent meer oplevert. Een expliciete Business Case helpt iedereen die bij het project betrokken is om de aandacht ook op de baten van het project te richten. Dan gaat het om de projectmanager, de leden van de Project Board (stuurgroep), maar ook om de bedrijfscontroller. Toch is het niet eenvoudig om op die manier naar de voortgang van een project te kijken.’



- MANAGEMENT GUIDE

Hoe men in een organisatie feitelijk omgaat met Business Cases kan in hoge mate bepaald zijn door het beleid ten aanzien van budgettering en de politieke verhoudingen. Bij een telecom provider werden jaarlijks volgens een bepaalde norm alleen de sterkste Business Cases geselecteerd voor realisatie. Business Cases werden door hun indieners, de opdrachtgevers, extreem positief geformuleerd om aan een budget te komen, temeer daar zij wisten dat zij toch niet werden afgerekend op de resultaten. Bij een zelfstandig bestuursorgaan werden de Business Cases juist zo vaag mogelijk geformuleerd. Bij voorkeur werd gerefereerd aan de ‘zachte’ doelstellingen van de organisatie. Het benoemen van concrete financiële baten werd in elk geval vermeden, omdat dit voor de opdrachtgevende lijnmanager direct leidde tot een budgetreductie in de periode na afloop van het project. Bij een financiële instelling koos men er bewust voor om 4 procent van het totale projectenbudget te besteden aan projecten zonder expliciete Business Case. Men had ingezien dat in sommige vernieuwende projecten het leren en innoveren belangrijker was dan het leveren van een voorspelbaar en meetbaar resultaat.

2.2 Betrekken van belanghebbenden in de projectbesturing Gerichte zeggenschap van belanghebbenden helpt belangrijke risico’s te voorkomen De uiteindelijke zeggenschap over een project ligt doorgaans bij de opdrachtgever: wanneer deze zijn financiële steun intrekt, betekent dat in het algemeen het einde van het project. Toch kan een opdrachtgever een project in de meeste gevallen niet realiseren zonder de medewerking van andere belanghebbenden. Een best practice om die medewerking te verkrijgen, is om een vertegenwoordiging van deze andere belanghebbenden in de projectbesturing te betrekken. Samen met hen wordt veelal een stuurgroep of Project Board (projectraad) gevormd om besluiten over het project te kunnen nemen.


13


- MANAGEMENT GUIDE

Belanghebbenden bij een project zijn al die personen of organisaties die een belang bij het project hebben en het vermogen hebben het project te beïnvloeden. Een project hoeft niet noodzakelijkerwijs de belangen van alle belanghebbenden te dienen, bijvoorbeeld wanneer het leidt tot gedwongen ontslagen of verhuizingen of tot ongewenste milieu-effecten. Het is de verantwoordelijkheid van de opdrachtgever te beslissen wie wel en wie niet in de projectbesturing betrokken wordt.

In een Project Board dienen drie basisrollen vertegenwoordigd te zijn: 1. De Executive of opdrachtgever: degene die het belang van de opdrachtgevende organisatie vertegenwoordigt en namens het hoger management de kosten tegen de baten kan afwegen, ofwel de eigenaar van de Business Case. Hij is eindverantwoordelijk voor het succes van het project en is verantwoordelijk voor communicatie met het lijnmanagement en andere belanghebbenden over de Business Case. De Executive is de voor de hand liggende voorzitter van de Project Board. 2. De Senior User of gebruikersvertegenwoordiger: degene die verantwoordelijk is voor de toepasbaarheid van de opgeleverde producten. De Senior User is verantwoordelijk voor de communicatie met alle gebruikers (dat wil zeggen al diegenen die het resultaat van het project zullen gebruiken, er mee zullen werken, er in zullen wonen, of er anderszins een belang bij hebben) en voor het namens hen verwoorden van een eenduidig standpunt. Dit kan betekenen dat de verantwoordelijkheid van de Senior User verder gaat dan die van zijn lijnfunctie: hij is verantwoordelijk voor alle gebruikers, niet alleen diegenen die tot zijn eigen afdeling behoren. De Senior Supplier bepaalt prioriteiten ten aanzien van functionaliteit en vertegenwoordigt de belangen van het gebruik in de Project Board.3 3. De Senior Supplier of leveranciersvertegenwoordiger: degene die verantwoordelijk is voor de (technische) kwaliteit van de geleverde producten. De Senior Supplier is verantwoordelijk voor de communicatie met interne en externe leveranciers en vertegenwoordigt de belangen van beiden in de Project Board. Hij vertegenwoordigt de belangen van zowel interne als externe leveranciers in de Project Board. Hij is aanspreekbaar op de technische kwaliteit van de geleverde producten. 3

Pas op voor verwarring: in de ICT-wereld komt ook de term Super User voor, welke een andere betekenis heeft. De term Super User wordt gebruikt bij de invoering van nieuwe softwarepakketten, bijvoorbeeld ERPpakketten. Het is een aanduiding van een ervaren gebruiker op uitvoerend niveau die op basis van diepgaande kennis van werkprocessen een inhoudelijke bijdrage levert aan het inrichten van het in te voeren softwarepakket. De term Senior User die binnen PRINCE2 gehanteerd wordt, heeft betrekking op een vertegenwoordiger op managementniveau van de belangen van gebruikers. Dit hoeft geen inhoudelijk deskundige te zijn.



- MANAGEMENT GUIDE

Een aldus samengestelde Project Board biedt een aanpak voor projectbesturing en projectorganisatie waarin de Business Case, de gebruikerseisen en de technische aspecten geïntegreerd zijn. De projectmanager woont de vergaderingen van de Project Board bij en faciliteert deze, maar is geen lid van de Project Board. De projectmanager is verantwoordelijk voor de dagelijkse leiding van het project, terwijl de Project Board verantwoordelijk is voor strategische sturing.

‘In onze organisatie is het van oudsher gebruikelijk dat managers in een stuurgroep gaan zitten om hun afdelingsbelangen te verdedigen tegen mogelijke negatieve effecten van een project. Een stuurgroeplid had rechten zonder plichten en een stuurgroepvergadering kon soms getypeerd worden als ‘een rondje schieten op de projectleider’. Wat we nu vragen - dat stuurgroepleden een concrete medeverantwoordelijkheid dragen voor het succes van een project - betekent een enorme cultuuromslag.’

Heldere kaders

Het is belangrijk steeds voor ogen te houden dat ieder lid van de Project Board een eigen rol en verantwoordelijkheid heeft. Een evenwichtige en efficiënte samenwerking is alleen mogelijk wanneer daar openheid en duidelijkheid over is. Het is daarom aan te bevelen dat de Executive bij het inrichten van de Project Board direct duidelijk maakt welke rol hij van de verschillende deelnemers verwacht en waar de grenzen van de beslissingsbevoegdheid liggen. Hij dient daarbij ook duidelijk te maken dat de uiteindelijke beslissingsbevoegdheid bij hemzelf ligt.

‘Binnen onze R&D-afdeling werd een kennismanagementsysteem ingevoerd. De schatting van het ‘aantal uren te gaan’ werd in de loop van het project juist groter in plaats van kleiner. De oorzaak lag in steeds nieuwe gebruikerswensen die steeds opnieuw enorm belangrijk werden gevonden. Als opdrachtgever begon ik me af te vragen of ik wel de juiste gebruikersvertegenwoordigers in de Project Board had gehaald. Uiteindelijk heb ik het harmoniemodel verlaten en de geldkraan dichtgedraaid: er moet nu eerst een resultaat opgeleverd worden op basis van de bestaande inzichten. Wie daarna nog aanvullende wensen heeft, kan een budget voor een nieuw project aanvragen.’


15


- MANAGEMENT GUIDE

Binnen een grote organisatie heeft de Executive overigens veelal ook zelf bepaalde grenzen meegekregen waar hij zich aan te houden heeft. Steeds als in dit boek sprake is van besluitvorming door de Project Board is het goed te bedenken dat deze plaats vindt binnen de door de Executive gestelde kaders, en indien van toepassing: binnen de kaders zoals die door de organisatie aan de Executive gesteld zijn. Valkuilen

Een van de valkuilen van zo’n stuurgroep is een te grote omvang, doordat iedere belanghebbende zelf vertegenwoordigd wil zijn. Dit kan een belemmering vormen voor efficiënte besluitvorming en er toe leiden dat geen van de leden zich persoonlijk verantwoordelijk voelt voor het project.

‘Het leek een veelbelovend project. Op de eerste stuurgroepbijeenkomst zaten we met zijn elven rond de tafel: ook de betrokken stafafdelingen hadden er elk op gestaan een vertegenwoordiger te mogen leveren. Vier maanden later, toen er inmiddels grote achterstanden waren opgetreden, zaten we er meestal nog maar met zijn vieren.’

Houd het klein

Om efficiënte besluitvorming mogelijk te maken dient een Project Board niet groter te zijn dan beslist noodzakelijk. De inbreng van belanghebbenden die niet direct in de Project Board vertegenwoordigd zijn kan op andere manieren geborgd worden. De paragrafen 3.1 en 3.5 gaan hier verder op in. Het benoemen van één persoon in elk van de drie rollen kan als praktische standaard beschouwd worden. Bij kleine projecten kan een persoon meerdere rollen vervullen. Complexe omgevingen daarentegen kunnen het noodzakelijk maken een rol over meerdere personen te verdelen. Naamgeving niet essentieel

Het is niet van belang of datgene wat PRINCE2 aanduidt als Project Board ook daadwerkelijk Project Board genoemd wordt. Alternatieve namen die men in de praktijk tegenkomt zijn bijvoorbeeld stuurgroep, transitieteam, fusieberaad, contractmanagementoverleg, bouwoverleg, wijkverbeteringscomité, enzovoort. Er is geen noodzaak om deze namen te veranderen. Soms is dit aantrekkelijk (als teken dat er ‘nu een andere aanpak gevolgd gaat worden’), soms roept dit alleen maar onnodige weerstand op. In plaats van de naamgeving van de groep te wijzigen, is het dan zinvoller de aandacht 16 Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


- MANAGEMENT GUIDE

te richten op de samenstelling, de relaties met belanghebbenden, de bevoegdheden en verantwoordelijkheden en de wijze van functioneren. Borging en de leden van de Project Board

Een van de meest wezenlijke - en vaak meest veronachtzaamde - verantwoordelijkheden van de leden van de Project Board is borging van de projectresultaten (Project Assurance).

Borging betekent zekerstelling. Wanneer er iets misgaat, is er een voorziening waardoor het toch nog goed komt. Een bergbeklimmer is geborgd door middel van een touw: wanneer hij met zijn handen en voeten (primair systeem) van de bergwand glijdt, dan hangt hij nog aan een touw (secundair systeem). Na eventuele corrigerende acties kan de besturing worden teruggegeven aan het primaire systeem. De bergbeklimmer is niet gevallen en kan verder klimmen. Uiteraard is een 100% garantie niet mogelijk, noch in bergbeklimmen, noch in projectmanagement.

Project Assurance wordt soms verward met Quality Assurance. Project Assurance is een verantwoordelijkheid van de leden van de Project Board om de resultaten van het project te borgen. Quality Assurance is de verantwoordelijkheid van de leiding van een organisatie om een kwaliteitssysteem vast te stellen en te onderhouden en er op toe te zien dat het gebruikt wordt, zodat bijgestuurd kan worden indien nodig. Onafhankelijkheid

De routinematige activiteiten van een organisatie zijn veelal goed geborgd. Denk aan de rol van de controller die onafhankelijk van de lijnmanager de integriteit van de financiële huishouding controleert en daarover rapporteert aan de directie en daarmee de directie in staat stelt corrigerend op te treden. De accountant vervult een vergelijkbare rol ten aanzien van het bedrijf als geheel en rapporteert daarover aan de aandeelhouders. Een wezenlijk vereiste voor borgingsrollen is dat zij onafhankelijk zijn van de uitvoerende verantwoordelijkheden.

De voorspelbaarheid en dus de beheersbaarheid van projectmatige activiteiten is door hun unieke karakter vrijwel per definitie lager dan die van routinematige activiteiten. Juist in projectmatige processen schuilen daarom relatief grote risico’s die onafhankelijke borging rechtvaardigen.


17


- MANAGEMENT GUIDE

Aan de borging van projectmatige activiteiten wordt verassenderwijs veelal juist minder zorg besteed dan aan de borging van routinematige activiteiten. De belangrijkste valkuilen schuilen in het combineren van rollen, bijvoorbeeld: • Project Board-leden die hun rol combineren met een uitvoerende rol in het project. • Een projectmanager die als lid van de Project Board beschouwd wordt in plaats van slechts deel te nemen aan de bijeenkomsten. • Een projectbureau dat verantwoordelijk is voor het rapporteren over de status van projecten aan het hoger management en tegelijk belast is met het ondersteunen van de projectmanagers bij het inrichten van hun projecten, het maken van planningen en het voeren van hun projectadministratie. In al deze voorbeelden wordt van mensen verwacht dat ze het resultaat borgen van wat deels hun eigen werk is, wat strijdig is met het beginsel van onafhankelijke borging. Binnen een lijnorganisatie worden dergelijke combinaties van borgende en uitvoerende rollen over het algemeen als onaanvaardbaar gezien.

Specifieke verantwoordelijkheden voor ieder lid van de Project Board

Effectieve Project Assurance vereist dat ieder lid van de Project Board zich bewust is van zijn individuele borgingsverantwoordelijkheid. Als een rol in de Project Board door meerdere personen vervuld wordt (bijvoorbeeld: er zijn twee Senior Users), dan dient er een duidelijke verdeling van verantwoordelijkheden tussen hen te zijn. ‘Als iedereen verantwoordelijk is, voelt niemand zich verantwoordelijk.’ In veel gevallen verdient het de voorkeur dat leden van de Project Board een deel van hun borgingsrol delegeren, omdat deze anders onvoldoende aandacht krijgt door de druk van hun dagelijkse bezigheden. De verantwoordelijkheid blijft echter bij de leden van de Project Board. De drie specifieke borgingsrollen in relatie tot de drie rollen in de Project Board zijn: • Business assurance • User assurance • Supplier assurance Business assurance

De Executive (opdrachtgever) is verantwoordelijk voor de borging van de Business Case. Zo moet hij controleren dat de berekende baten voldoende onderbouwd zijn en dat de projectadministratie een juist beeld geeft van de gemaakte kosten. Ook draagt hij verantwoordelijkheid voor de kwaliteit van het risicomanagement door de project18 Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


- MANAGEMENT GUIDE

manager en voor de betrouwbaarheid van zijn rapportages. De opdrachtgever kan een deel van zijn rol delegeren. Het periodiek controleren van de betrouwbaarheid van de administratie en rapportages van de projectmanager kan hij bijvoorbeeld beleggen bij een controller. De controle van de kwaliteit van het risicomanagement kan bij een risicomanagementexpert belegd worden. Ook kan hij een algemene audit op de kwaliteit van het projectmanagement laten uitvoeren. Veel grote organisaties kennen een staforgaan dat over de status van projecten rapporteert aan de betrokken Project Boards en aan de directie. Een dergelijk staforgaan kan bijvoorbeeld door het leven gaan als Project Assurance Office, Portfolio Management Office of Project Governance Office. In het geval projecten deel uitmaken van een programma kunnen deze taken belegd worden bij een Programme Office. User assurance

De Senior User is verantwoordelijk voor de borging van de functionele kwaliteit en de belangen van gebruikers en beheerders. Vanuit deze verantwoordelijkheid kan hij eisen stellen aan kwaliteitscontroles en aan review- en wijzigingsprocedures. Ook borgt hij de acceptatie van het projectresultaat door de gebruikers. Hij is er bijvoorbeeld verantwoordelijk voor dat de juiste gebruikers specificaties opstellen en controleren of de producten aan deze specificaties voldoen. Wanneer de projectmanager op dit vlak problemen heeft (er is bijvoorbeeld weerstand bij gebruikers die hij niet zelf kan overwinnen), dan moet hij de problemen kunnen escaleren naar de Senior User. In de meeste gevallen zal de Senior User niet zelf specificaties opstellen of functionele controles uitvoeren, maar dit delegeren aan vertegenwoordigers van gebruikers. Supplier assurance

De Senior Supplier is verantwoordelijk voor de borging van de technische kwaliteit, maar bijvoorbeeld ook voor de kwaliteit van planningen. Hij kan eisen stellen ten aanzien van het gebruik van standaarden en dient zeker te stellen dat deze daadwerkelijk gevolgd worden. Ook staat hij in voor de haalbaarheid van het project, waaronder de beschikbaarheid van de juiste specialisten. Wanneer de projectmanager er niet in slaagt de juiste medewerkers in zijn project te betrekken (bijvoorbeeld omdat een leverende lijnafdeling niet meewerkt), dan dient hij dit te kunnen escaleren naar de Senior Supplier. Het feitelijk controleren of volgens standaards gewerkt wordt kan de Senior Supplier delegeren aan specialisten.


19


- MANAGEMENT GUIDE

Volledige verantwoordelijkheid

Een ieder die een verantwoordelijkheid heeft voor Project Assurance dient onafhankelijk te zijn van uitvoerend verantwoordelijken binnen een project, en vooral van de projectmanager. En ongeacht hoe de borgende rollen en bevoegdheden zijn belegd, het blijft steeds de volledige verantwoordelijkheid van de leden van de Project Board om zeker te stellen dat de borging goed geregeld is.

2.3 Verdelen van het project in managementfasen Maak de fasering van een project ondergeschikt aan uw eigen behoefte aan besluitvorming ‘Hoe kan ik verantwoordelijkheid dragen voor een project als ik besluiten moet nemen op basis van documenten die ik niet begrijp?’

Wie stuurt er echt?

Sommige projecten hebben de neiging om, zodra men een fiat heeft gegeven om van start te gaan, een eigen leven te gaan leiden. Ze gaan een eigen taal spreken en leveren beslisdocumenten die niet tot de verbeelding spreken. De aanpak is gebaseerd op een eigen (technische) fasering, gebaseerd op de volgorde waarin activiteiten binnen een bepaald type projecten worden uitgevoerd, zoals vooronderzoek, analyse, ontwerp, realisatie, invoering, of gebaseerd op de kwalificaties en specialismen van de betrokken projectleden. Voor u als opdrachtgever zijn dergelijke faseovergangen niet automatisch de ideale momenten om belangrijke voortgangsbesluiten te nemen. Het kan dan lastig worden om een goede controle over het project te houden. PRINCE2 is er op gericht de opdrachtgever daadwerkelijk aan het stuur te houden en stelt de fasering van een project dan ook geheel ten dienste van de bestuurbaarheid door de opdrachtgever. De fasen heten daarom Management Stages. Bewuste besluitvorming ‘De planning van het project was permanent aan het glijden. In feite werden we geleefd. Ik heb het gevoel dat we nooit een bewust besluit hebben genomen om door te gaan, de koers te verleggen of te stoppen.’



- MANAGEMENT GUIDE

Iedere overgang naar een volgende Management Stage is afhankelijk van een bewust genomen voortgangsbesluit van de Project Board. Dit zijn vooraf geplande momenten waarop de Project Board toetst of de Business Case van het project nog steeds positief is en of de risico’s van het project nog steeds aanvaardbaar zijn. De Project Board kan besluiten ongewijzigd door te gaan, te stoppen of veranderingen in het project aan te brengen. Om dit besluit te onderbouwen moet de projectmanager een rapportage opstellen over de afgelopen fase, een plan voorleggen voor de volgende fase en waar nodig het projectplan hier op aanpassen. Als basis voor het te nemen besluit moet hij tevens de Business Case en de risicoanalyse controleren en indien nodig actualiseren. Welke fasering?

Het kiezen van de juiste managementfasering is voor de bestuurbaarheid van een project van strategisch belang. De keuze kan daarom niet zonder meer worden overgelaten aan de projectmanager of specialisten werkzaam in het project. Faseovergangen kunnen met de projectwerkzaamheden zelf te maken hebben, maar kunnen ook gerelateerd zijn aan belangrijke investeringsbeslissingen, momenten waarop nieuwe informatie over risico’s beschikbaar zal komen of aan andere ontwikkelingen binnen of buiten de organisatie.

‘In onze branche presenteert iedereen zijn nieuwe producten op de jaarlijkse beurs. Daar kunnen verrassingen bij zijn. Van de lopende R&D-projecten laat ik daarom direct na de beurs de balans opmaken: Waar staan we? Wat weten we inmiddels over wat anderen op de markt brengen? Willen we nog doorgaan? Zijn er bijstellingen nodig?’

‘In verband met de levertijden moet uiterlijk tien weken voordat we het nieuwe systeem in gebruik nemen de hardware besteld worden. We gaan dan een verplichting aan van enkele tonnen. Vlak voordat we dat doen wil ik een actueel inzicht in de verwachte kosten en baten, om op dat moment definitief te bepalen of we doorgaan.’

‘Begin november moet ik mijn budget voor het komend jaar inleveren. Ik wil daarom eind oktober - op basis van een actueel inzicht in de voortgang, de Business Case en de risico’s - voortgangsbesluiten nemen over de verschillende projecten en vaststellen welke reserveringen ik doe voor het komend jaar.’


21


- MANAGEMENT GUIDE

Bij een langlopend project kan het raadzaam zijn om de fasering niet alleen af te stemmen op het besluitvormingsproces van de opdrachtgever, maar ook op het leveren van tussentijdse resultaten aan de gebruiker, om zo draagvlak te behouden. Zo kan het verstandig zijn de uitvoering van een ingrijpend stadsvernieuwingsplan blok voor blok aan te pakken om de impact te beperken.

Tegenstrijdige eisen?

Opdrachtgevers willen twee schijnbaar tegenstrijdige dingen: zo lang mogelijk flexibiliteit behouden en toch zo snel mogelijk zekerheid hebben. Bij klassieke faseringen - definitiestudie, ontwerp, realisatie, invoering - kan de flexibiliteit snel verdwenen zijn: bij verandering van inzicht blijkt er veel werk voor niets gedaan. Toch is er pas laat zekerheid over haalbaarheid en acceptatie door de omgeving: dit wordt pas aan het einde duidelijk als de belanghebbenden met het resultaat geconfronteerd worden. Steeds vaker worden daarom andere faseringen gekozen. Een van de eerste fasen is dan bijvoorbeeld gericht op vervaardiging van een prototype of maquette om gebruikersreacties te evalueren. Ook kan men in een van de eerste fasen een proof of concept uitvoeren om mogelijke technische belemmeringen eerder vast te stellen. Invoering kan gefaseerd worden door bijvoorbeeld een nieuwe werkwijze eerst op kleine schaal in een afdeling of vestiging in te voeren en pas na gebleken succes over de rest van de organisatie uit te spreiden. Al deze faseringen hebben een ding gemeen: in theorie zijn ze niet de kortste weg naar het doel, maar in de praktijk - in een omgeving met onzekerheden en veranderingen - kunnen ze toch een beter resultaat leveren. Ze verbeteren de bestuurbaarheid en reduceren de risico’s doordat de opdrachtgever eerder zekerheid heeft over haalbaarheid en acceptatie en langer de flexibiliteit behoudt om met beperkte schade bij te sturen. Optimale controle

De verdeling van het project in Management Stages stelt de opdrachtgever in staat steeds besluiten te nemen op de juiste momenten en onderbouwd met de juiste informatie. Wanneer de opdrachtgever toestemming geeft voor de start van de volgende fase stelt hij budget ter beschikking voor die fase. De opdrachtgever hoeft bij aanvang dus geen budget ter beschikking te stellen voor het gehele project. Zo wordt een optimale budgettaire controle gehandhaafd. Het voor een fase toegekende budget in combinatie met de door de Project Board vastgestelde planning bepaalt het mandaat voor de projectmanager. Dit is waarmee de projectmanager in zijn rapportages steeds zijn realisatie vergelijkt. Wanneer de projectmanager signaleert dat hij de grenzen van zijn mandaat 22 Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


- MANAGEMENT GUIDE

te buiten zal gaan moet hij de Project Board direct alarmeren, zodat deze desgewenst kan bijsturen. Eén vaste fase

Eén fase moet volgens PRINCE2 in ieder project voorkomen: de initiatiefase. Het doel van deze fase is de opdrachtgever in staat te stellen om een startbeslissing over de uitvoering van het project te nemen. Het belangrijkste product van deze eerste fase is het Project Initiation Document (PID). Dit bevat naast een beschrijving van de Business Case onder andere: de afbakening, aanpak, projectdoelstellingen, fasering en globale planning van het project als geheel, projectorganisatie, risico-inventarisatie, kwaliteitsplan en communicatieplan. Kortom, alle informatie die nodig is om een verantwoord besluit te kunnen nemen over het daadwerkelijk starten van de uitvoering. Als dit besluit positief is betekent dat de start van een of meer uitvoerende fasen, ook wel specialistische fasen genaamd.

Het Project Initiation Document kan gezien worden als ‘contract’ tussen de Project Board en de organisatie, en als ‘contract’ tussen de Project Board en de projectmanager. Het is de basis voor communicatie over het project.

Het bekende adagium: ‘eerst denken, dan doen’ zal door de meeste mensen onderschreven worden. Toch zijn oorzaken van problemen in projecten vaak terug te voeren op factoren die te maken hebben met onvoldoende voorbereiding: men heeft bijvoorbeeld onvoldoende tijd genomen om de belanghebbenden bij het project te betrekken, om risico’s in te schatten of om het eens te worden over de specificaties. Bijna iedereen begrijpt dat dit loont, en toch doen we het vaak niet. De startbeslissing van een project is misschien wel de meest onderschatte voortgangsbeslissing. Herstellen wat hierbij over het hoofd gezien wordt, wordt in de loop van het project steeds kostbaarder.

‘In onze organisatie is de heersende cultuur: positief denken, vertrouwen op succes en er helemaal voor gaan. Wie een risicoanalyse wil doen, is al gauw iemand die beren op de weg ziet. Het vereist bij ons moed om genoeg tijd voor projectvoorbereiding te claimen.’


23


- MANAGEMENT GUIDE

Eenvoudigste fasering

Als er geen behoefte is aan tussentijdse besluitvorming, kan men kiezen voor de meest eenvoudige fasering. Na de eerste fase (initiatie) geeft u als opdrachtgever toestemming voor de start van de tweede en tevens laatste fase (uitvoering). Na afronding van deze laatste fase neemt de opdrachtgever een besluit over acceptatie van de resultaten en over decharge van de projectmanager. Tijdens de uitvoering hoeven voortgangsbeslissingen verder alleen nog te worden genomen in uitzonderingssituaties. Deze eenvoudigste fasering is alleen mogelijk als de afbakening, specificaties en kwaliteitseisen voldoende helder zijn om de projectmanager een mandaat te geven voor de gehele uitvoeringsfase. De projectmanager kan een managementfase verder opsplitsen in ‘technische fasen’, maar deze zullen niet verbonden worden met voortgangsbeslissingen van de Project Board. Balans

Een managementfasering die volledig los staat van de uitvoering kan ook nadelen hebben. Indien men bijvoorbeeld de fasering volledig laat bepalen door de budgettering (elk kwartaal een fase), dan wordt het erg lastig om objectieve voortgangsinformatie te krijgen bij de faseovergangen. Er is dan immers geen enkel verband meer met de oplevering van de producten waar het om gaat en het zal de projectmanager veel inspanning kosten de uitvoering zo te organiseren dat er bij iedere faseovergang afgeronde producten zijn. In de praktijk gaat het bij het kiezen van een effectieve fasering dan ook om het vinden van een balans tussen enerzijds de besluitvormingsbehoefte van de opdrachtgever en anderzijds de mogelijkheid om bij fase-overgangen betrouwbare statusinformatie te leveren op basis van afgeronde producten.

2.4 Sturen op uitzonderingen Optimale controle met beperkte inspanning Meer valkuilen

Laten we veronderstellen dat u de belanghebbenden in de besturing heeft betrokken door een juiste vertegenwoordiging in de Project Board en dat u voor hen op basis van de Business Case een duidelijk kader voor besluitvorming hebt gecreëerd. Laten we ook aannemen dat er in het project een fasering is aangebracht die besluitvorming op de juiste momenten mogelijk maakt. Ook dan schuilt er in het feitelijk functioneren van de Project Board nog een belangrijke valkuil: te veel betrokken raken bij operationele details. Dit leidt er toe, dat de projectbesturing minder efficiënt wordt (te veel en te lang vergaderen) en minder effectief (onvoldoende onafhankelijkheid voor strategische sturing en borging). 24 Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


- MANAGEMENT GUIDE

Veel voorkomende oorzaken waardoor Project Boards te veel bij details betrokken raken zijn: • Op vaste tijdstippen vergaderen, ook wanneer er geen besluiten genomen hoeven te worden. De beschikbare tijd zal onvermijdelijk gebruikt worden om minder belangrijke zaken te bespreken. • Onvoldoende vertrouwen in de kwaliteiten van de projectmanager. Dit leidt er toe dat, zodra er problemen in een project ontstaan, Project Board-leden operationele zaken zelf gaan regelen.

Als gebrek aan vertrouwen in de kwaliteiten van de projectmanager de oorzaak is waardoor de Project Board te veel bij operationele details betrokken raakt, dan is het zo snel mogelijk vervangen van de projectmanager de te verkiezen optie. Op de korte termijn kan dit pijnlijk zijn voor de betrokkene en weerstand oproepen in de organisatie. Over de duur van het project als geheel gerekend is het waarschijnlijk een lonende ingreep. Een projectorganisatie moet bij aanvang zo zijn ingericht dat deze ook tegen zwaar weer bestand is: dat is een preventieve maatregel om zwaar weer te voorkomen.

Zoals een ervaren opdrachtgever het zei: ‘Bij sommige projectmanagers lijkt het allemaal zo eenvoudig: dan ontstáán bepaalde problemen gewoon niet.’

Echte beslissers

De ideale - effectieve en efficiënte - Project Board is klein en bevoegd om besluiten te nemen. Deze komt alleen bijeen wanneer belangrijke besluiten genomen moeten worden. Tussen de bijeenkomsten worden de leden op de hoogte gehouden door middel van periodieke voortgangsrapportages (Highlight Reports). Goed getimede bijeenkomsten van de echte beslissers kunnen een belangrijke bijdrage leveren aan de voortgang van een project. Toleranties

Om bijeenkomsten van de Project Board te beperken tot die situaties waarin besluiten moeten worden genomen en te vermijden dat de Project Board zich met de geringste afwijkingen moet bezighouden, moet de projectmanager de bevoegdheid krijgen operationele beslissingen te nemen. Maar om te voorkomen dat de Project Board de controle verliest, moeten de bevoegdheden van de projectmanager duidelijk worden afgebakend. Dit is de rol van tolerantie (Tolerance): een toestemming om binnen bepaalde grenzen Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

25


- MANAGEMENT GUIDE

af te wijken van een plan. Toleranties zijn noodzakelijk aangezien het praktisch onmogelijk is een project in alle opzichten volgens plan uit te voeren. Uiteraard is het belangrijk de projectmanager een prikkel te geven om niet automatisch de gegeven marge te benutten. Hier wordt nader op ingegaan in paragraaf 7.6.

‘Toleranties zijn er impliciet altijd geweest. Vroeger stormde een projectmanager ook niet meteen mijn kamer binnen zodra hij een euro meer besteedde. Alleen, sinds we ze expliciet gemaakt hebben, weet hij hoe ver hij kan gaan en heb ik meer controle.’

Toleranties voor de projectmanager dienen betrekking te hebben op de lopende fase van een project: na iedere fase besluit de Project Board immers of en hoe het project wordt voortgezet. En als een projectmanager een tolerantie krijgt toegekend voor het hele project, welk deel daarvan mag hij dan gebruiken voor de lopende fase? De aan een projectmanager toegekende toleranties hebben meestal betrekking op tijd en geld. De Project Board geeft de projectmanager dan de bevoegdheid om binnen bepaalde grenzen te beslissen over afwijkingen ten opzichte van planning en budget: ‘Je kunt maximaal een week of vijftig duizend euro afwijken van het plan, zolang je het geplande product oplevert met de geplande kwaliteit.’ Paragraaf 4.2 gaat in op andere soorten toleranties. Highlight Reports en Exception Reports

Zolang de uitvoering van een fase binnen de vastgestelde toleranties blijft, mag de projectmanager zich achteraf verantwoorden middels periodieke Highlight Reports. Zodra de projectmanager verwacht dat de uitvoering van een fase de toleranties te buiten zal gaan, moet de Project Board direct geïnformeerd worden middels een Exception Report (afwijkingsrapport), zodat deze desgewenst een besluit kan nemen over correctieve maatregelen. Misverstand

Sommige opdrachtgevers durven het niet aan een projectmanager een financiële tolerantie toe te kennen. Het kan inderdaad zo lijken alsof u daarmee een projectmanager carte blanche geeft om extra geld te besteden. Dit is een misverstand. Een projectmanager die een ‘tolerantie van vijftigduizend euro’ heeft moet nog steeds iedere kostenoverschrijding en de door hem daarover genomen besluiten verantwoorden in zijn voortgangsrapportages. Op basis van deze verantwoording kan de Project Board nog steeds ingrijpen wanneer zij vindt dat er geen goede gronden zijn voor de kostenoverschrijding 26 Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


- MANAGEMENT GUIDE

of dat de projectmanager verkeerde besluiten neemt. Toleranties en sturen op uitzonderingen (management by exception) zijn dus nauw met elkaar verbonden als elementen van hetzelfde besturingsprincipe.

‘Onze controller heeft bezwaar tegen financiële toleranties: hij begrijpt niet dat dit de controle verbetert en ziet toleranties toekennen als ‘vooraf geld weggooien’. Ik laat ze nu alarmgrenzen noemen, het effect is voor mij hetzelfde. Een overschrijding beneden de alarmgrenzen kan een projectmanager gewoon in zijn voortgangsrapportage verantwoorden. Zodra hij verwacht dat hij boven de alarmgrenzen uit zal komen wil ik het meteen weten, zodat ik als ik wil meteen maatregelen kan nemen.’

Geen vuile handen maken

Door de projectmanager een expliciet mandaat te geven, hoeft de Project Board zich niet met uitvoeringsbeslissingen bezig te houden. Zo kan een duidelijke scheiding tussen besturing en uitvoering gehandhaafd blijven. De Project Board kan daardoor een onafhankelijke controlerende rol blijven spelen en zich zonder ‘vuile handen’ met de echte besturingsvragen bezig houden. Uitzondering

In een Exception Report verantwoordt de projectmanager de (dreigende) overschrijding van de toleranties en stelt hij opties voor waar de Project Board uit kan kiezen. De Project Board komt nu bijeen en kan verschillende besluiten nemen. De Project Board kan besluiten wijzigingen aan te brengen zoals aanvullend budget toekennen, het ambitieniveau aanpassen of de projectorganisatie veranderen. Om zulke aanpassingen te onderbouwen kan de Project Board de projectmanager opdracht geven eerst een Exception Plan te maken. De Project Board kan ook concluderen dat de Business Case van het project niet meer realiseerbaar is, bijvoorbeeld doordat de verwachte kosten te hoog zijn geworden in verhouding tot de baten. De Project Board zal dan moeten besluiten het project stop te zetten, tenzij de kosten van stoppen hoger zijn dan de kosten van doorgaan. Als de Project Board van mening is dat het project niet goed geleid wordt, kan de Project Board besluiten de projectmanager te vervangen. Inspiratie voor de projectmanager

In bijeenkomsten om een besluit te nemen over een uitzonderingssituatie of over de start van een nieuwe fase, baseert de Project Board haar beslissingen - binnen de context van de Business Case en aanvaarde risico’s - op rapportages en plannen van de projectmanager. Het is goed te bedenken dat de wijze van functioneren van de Project Board Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

27


- MANAGEMENT GUIDE

zelf een belangrijke invloed heeft op de wijze van functioneren van de projectmanager. Men kan van een projectmanager nauwelijks efficiëntie en doelgerichtheid verwachten wanneer de Project Board onnodig vaak en lang vergadert en zich bezighoudt met zaken die niet nodig zijn voor de besluitvorming. Omgekeerd is een efficiënte en doelgerichte Project Board waarin iedere deelnemer zich aan zijn eigen rol houdt en waar men zich samen richt op het tijdig nemen van de benodigde besluiten een bron van inspiratie voor de projectmanager. Sturen op uitzonderingen is een krachtig hulpmiddel om op deze manier te functioneren.

2.5 Sturen op producten Vooraf duidelijkheid over het resultaat: begin bij het einde Wat hoort er nu bij het project en wat niet?

Wanneer u reeds enkele projecten hebt meegemaakt, zult u het ongetwijfeld ervaren hebben dat er discussies ontstaan over wat er wel of niet tot een activiteit, een fase of het project als geheel behoort. Als de scope (afbakening) niet eenduidig is vastgelegd, is het moeilijk om objectief te bepalen of een hoeveelheid werk gereed is. Dit leidt tot onvoldoende onderbouwd inzicht in de status van het project tijdens de uitvoering en kan leiden tot conflicten bij oplevering. De oorzaak hiervan kan liggen in de manier waarop werkzaamheden worden omschreven. Wanneer er in een planning bijvoorbeeld activiteiten of fasen staan zoals ‘het uitvoeren van een analyse’ of ‘voorbereiden van de invoering’ dan is dat voor velerlei uitleg vatbaar. Wat hoort er wel bij en wat niet? Voor u als opdrachtgever is het moeilijk te beoordelen wat specialisten wel of niet tot de omschreven werkzaamheden rekenen. Begin bij het einde

PRINCE2 baseert planning daarom niet op activiteiten maar op producten, onder het motto: resultaatgericht werken = productgericht plannen. Om te beginnen wordt het gewenste eindresultaat beschreven als een product. Bijvoorbeeld: een werkend bedrijfsproces. Vervolgens wordt het zo gedefinieerde eindproduct verdeeld in deelproducten tot een dusdanig detailniveau, dat deze wat betreft omvang en complexiteit voldoende overzichtelijk en meetbaar zijn. Ieder deelproduct moet een herkenbaar onderdeel zijn van wat aan de opdrachtgever wordt opgeleverd. Zo ontstaat een onderverdeling in delen waarvan u als opdrachtgever de afbakening uitstekend kunt toetsen. Het is de realisatie van de deelproducten die uiteindelijk vertaald wordt in activiteiten die worden opgenomen in het projectplan. 28 Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


- MANAGEMENT GUIDE

In de meeste projecten is het niet mogelijk - en wenselijk - alle deelproducten bij het begin van een project exact te beschrijven. Het projectplan beschrijft de producten slechts in hoofdlijnen. Per fase vindt een nadere detaillering plaats. Productbeschrijvingen als basis van de planning

Vervolgens wordt van ieder product en deelproduct een productbeschrijving gemaakt, met onder andere de eisen waaraan het product moet voldoen en hoe en door wie deze eisen getoetst zullen worden. Voor iedere activiteit geldt dan, dat deze pas gereed is wanneer het bijbehorende product aantoonbaar aan de vooraf gedefinieerde eisen voldoet. Zo ontstaat een heldere focus op kwaliteit en een objectieve meting van de voortgang. Dit noemt men product-based planning. Alle testverslagen, reviewverslagen en andere verslagen van kwaliteitscontroles worden opgeslagen in het Quality Log, een vast onderdeel van het projectarchief. Hier kan de Project Board naar behoefte controleren (of door een auditor laten controleren) of de gereed gemelde producten inderdaad klaar zijn en of deze door de juiste personen aan de vastgelegde kwaliteitseisen getoetst zijn.

In plaats van concrete kwaliteitseisen te formuleren kan ook een acceptatieprotocol worden vastgelegd. Indien bijvoorbeeld het meubilair van een gebouw vernieuwd wordt, kunnen als kwaliteitseisen gelden: • ‘moet voldoen aan de ARBO-technische eisen zoals vastgelegd in document X, te controleren door instantie Y’ (een concrete eis); • ‘dient goedgekeurd te zijn door de architect van het gebouw’ (een acceptatieprotocol). Pas in de loop van het project zal in detail duidelijk worden welke voorwaarden de architect aan het resultaat stelt. Tussentijdse kwaliteitsreviews (bijvoorbeeld het ter beoordeling aan de architect voorleggen van een globaal ontwerp, een concept ontwerp, enzovoort) kunnen er toe bijdragen het beeld stap voor stap duidelijk te krijgen. Zijn uiteindelijke oordeel hoeft zo geen verrassing te zijn.

Grip op voortgang en kwaliteit

Deze resultaatgerichte manier van plannen levert, gezien vanuit het perspectief van de opdrachtgever, drie belangrijke voordelen op. 1. Discussies over wat er wel en niet bij het project hoort, komen nu eerder ter tafel. Het gaat immers niet meer over voor de opdrachtgever onherkenbare specialistiCopyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

29


- MANAGEMENT GUIDE

sche activiteiten: het gaat over tastbare resultaten, en gebruikers kunnen betrokken worden bij het beschrijven ervan. Door deze discussies bij het begin van het project te voeren, kan het project duidelijker worden afgebakend en de Business Case nauwkeuriger worden getoetst. Het helpt verwarring of teleurstelling in latere fasen te voorkomen; verwachtingen van betrokkenen kunnen hierdoor in goede banen worden geleid. 2. Door de verdeling in kleine objectief toetsbare tussenresultaten is het werk duidelijk af te bakenen. Het is hierdoor veel moeilijker om een te rooskleurig beeld van de voortgang te geven: een activiteit die tot een controleerbaar deelproduct leidt is klaar of niet klaar. Door de projectbesturing op resultaten te richten hebt u een objectiever beeld van de status van het project. 3. Doordat van alle onderdelen vastligt aan welke eisen deze moeten voldoen en hoe deze moeten worden getoetst, is er een degelijke basis voor een kwaliteitsplan. Dit betaalt zich terug in de vorm van betere afstemming op gebruikerseisen, minder klachten na oplevering van het projectresultaat en minder noodzakelijke herstelacties achteraf. Kortom: product-based planning levert een eenduidig fundament op voor scopebeschrijving, planning, voortgangsmeting en kwaliteitsbeheersing, waardoor consistentie ontstaat in de projectbesturing. Dit maakt een productgerichte besturing mogelijk: doordat de Project Board productbeschrijvingen vaststelt en toetst of de voorgeschreven controles door de juiste personen of instanties zijn uitgevoerd, heeft ze grip op voortgang en kwaliteit zonder zelf producten te hoeven controleren.

Tip voor het beoordelen van de kwaliteit van een plan: hebben de hoofdstukken over scope, te leveren resultaten, acceptatiecriteria en planning eenduidig betrekking op dezelfde producten?

‘Het klinkt als een moeilijke term, maar sinds we met product-based planning werken vind ik planningen juist eenvoudiger te begrijpen.’


Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see

Recommend Documents