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

Transcriptie

1

2 PRINCE2 voor opdrachtgevers Management Guide

3 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 ASL BiSL CATS CMMI COBIT ISO ISO ISO/IEC ISPL IT Service CMM ITIL V2 ITIL V3 ITSM MOF MSF Architecture (Enterprise en IT) Archimate TOGAF TM Business Management EFQM ISA-95 ISO 9000 SixSigma SOX SqEME Project-, Programmaen Riskmanagement A4 Projectmanagement ICB / NCB MINCE M_o_R MSP NCB PMBoK PRINCE2 Voor een compleet overzicht van alle uitgaven, ga naar onze website:

4 PRINCE2 voor opdrachtgevers Management Guide 3de druk

5 Colofon Titel: Auteur: Redactie: Uitgever: PRINCE2 voor opdrachtgevers Management Guide Michiel van der Molen Inform-IT Van Haren Publishing ISBN(13): 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.

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

7 Inhoudsopgave 1 Inleiding Wat is een project? Wat is PRINCE2? Waarom PRINCE2? Wat is een opdrachtgever? Waarom dit boek? Waar gaat dit boek over? Waar gaat dit boek niet over? Leeswijzer Vijf best practices voor strategische projectbesturing Sturen op basis van de Business Case Betrekken van belanghebbenden in de projectbesturing Verdelen van het project in managementfasen Sturen op uitzonderingen Sturen op producten De Project Board nader bezien Wie moeten zitting nemen in de Project Board? De Project Board in de context van de organisatie Hoe kan ik de opdrachtgeverrol efficiënter vervullen zonder grip te verliezen? Hoe kan ik de opdrachtgeverrol delegeren? Hoe kan ik gebruikers er optimaal bij betrekken en toch slagvaardig blijven? Kan een project meer dan één opdrachtgever hebben? Het aansturen van de projectmanager Welke verantwoordelijkheden delegeer ik aan de projectmanager? Welke toleranties kan ik een projectmanager toestaan? Welke verantwoordelijkheden houdt de Project Board zelf? Hoe voorkom ik dat een projectmanager oncontroleerbaar wordt? Hoe beoordeel ik de kwaliteit van een voortgangsrapportage?...65 VI

8 5 De rol van externe leveranciers Moet ik een externe leverancier in de projectbesturing betrekken? Hoe voorkom ik dat een externe projectmanager oncontroleerbaar wordt? Omgaan met onzekerheden Hoe zorg ik dat risico s goed beheerst worden? Hoe houd ik controle als ik bij de start niet weet wat de specificaties zijn? Hoe houd ik een project beheersbaar bij wijzigingen in de specificaties? Waarom eindigen projecten vaker boven dan beneden budget? Wat doe ik daartegen? Voortschrijdend inzicht van gebruikers Eenzijdige invloed van specialisten Dynamiek in de projectomgeving Onvoldoende projectbeheersing Blinde vlekken in de planning Wet van Parkinson Vertraging in de besluitvorming Prijsopdrijving door een leverancier Valkuilen bij de toepassing van PRINCE Onterechte projectmatige aanpak Te uitgebreide toepassing van PRINCE Te formele toepassing van PRINCE PRINCE2 als wondermiddel Woordenlijst Verklarende woordenlijst Vertaallijst Nederlands-Engels Literatuurlijst Index VII

9 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

10 Ik wil al diegenen die genoemd worden als adviseurs of reviewers hartelijk danken voor hun onmisbare bijdrage. Michiel van der Molen, oktober 2006 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

11

12 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

13 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

14 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? 3

15 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

16 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

17 6

18 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 Case 1 (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

19 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 8

20 van zulke projecten is de continuïteit van de organisatie in het geding. Volgens onderzoek van Gartner 2 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

21 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 10

22 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. 11

23 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. 12

24 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

25 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 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. 14

26 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

27 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

28 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

29 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 project- 18

30 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

31 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. 20