1. Zo dicht mogelijk langs elkaar heen praten
2. HINBWJZ; HIBWDADDJZ
3. Risicoperceptie
4. De succesfactoren
5. Informatie inwinnen 
6. Meer succesfactoren
7. Informatie uitdragen
8. Meer over de Risman-methodiek

1. Zo dicht mogelijk langs elkaar heen praten

In deel 1 van ons vierluik over projectrisicomanagement volgens de Risman-methodiek zijn we ingegaan op de probleemstelling, de partijen en hun relaties. (Zie ‘Risman project risico management: de spelers en het spel’). Het tweede deel ging over de risico’s die onder het tapijt verdwijnen als projecten opgedeeld worden in deelprojecten en over de kloof die er vaak bestaat tussen de perceptie van het projectresultaat en het daadwerkelijke effect dat met het project gerealiseerd moet worden. (Zie ‘Risman projectrisicomanagement: projectinterne risico’s’).
Het derde deel handelde over de risico’s die ontstaan als de belangen van opdrachtgever, opdrachtnemers en het projectteam onvoldoende gesynchroniseerd worden. (Zie ook ‘Risman projectrisicomanagement: projectexterne risico’s’). Dit afsluitende deel gaat over succes-en faalfactoren bij de communicatie over risico’s.

Seth Gaaikema zei ooit: “Goed communiceren is zo dicht mogelijk langs elkaar heen praten” In veel projecten lijkt het alsof de intentie en/of competentie om goed te communiceren bij alle betrokkenen ontbreekt. Niet voor niets heeft de Risman-methodiek communicatie over projectrisico’s benoemd als belangrijkste succesfactor voor risicomanagement. In dit artikel gaan we daarom in op hoe miscommunicatie en verkeerde perceptie kunnen ontstaan en hoe u hier als projectmanager of als risk manager mee om moet gaan. Want als u er niet goed mee omgaat, dan zullen niet de projectrisico’s de grootste faalfactor voor het project zijn, maar de communicatie hierover.

2. HINBWJZ; HIBWDADDJZ

Eén van de ankerpunten die Tom Planken in zijn cursussen presenteerde, was: “Het is niet belangrijk wat je zegt; het is belangrijk wat de ander denkt dat je zegt”. Dit geldt zeker voor de communicatie over risico’s binnen een project. Het inventariseren van risico’s is uiteindelijk immers weinig meer dan speculeren met je gezond boerenverstand. Als de deelnemers aan de risicoanalyse na afloop een verschillend beeld hebben van de risico’s, dan wordt voorbij gegaan aan het doel van zo’n risicoanalyse. En dan moet de exercitie als mislukt beschouwd worden.
De perceptie van de risico’s, de wijze waarop de deelnemers aan de risicoanalyse de risico’s beleven en op waarde schatten, bepaalt voor een belangrijk deel de communicatie. De communicatie vindt plaats op basis van deze perceptie.

3. Risicoperceptie

Deelnemers aan een risicoanalyse hebben vaak een duidelijke mening over de risico’s binnen “hun” project. Niet alleen omdat ze veel kennis van zaken hebben, maar ook omdat ze een gevoel bij het project hebben. Dit gevoel kleurt dikwijls in sterke mate hun mening en heeft zo een grote impact op de communicatie over risico’s.
Als een opdrachtgever bijvoorbeeld wordt verteld dat hij bepaalde risico’s loopt in zijn project, zal hij pas in actie komen wanneer hij daadwerkelijk voelt dat hij deze risico’s loopt en dat deze risico’s zijn project kunnen bedreigen. Oftewel, zolang iemand niet gevoelsmatig is overtuigd, is er altijd een zekere mate van verzet tegen de boodschap. Communicatie over risico’s heeft zodoende vaak te maken met het overtuigen van andere mensen.
Psychologen hebben veel onderzoek gedaan naar de manier waarop mensen risico’s voelen en waarnemen, naar risicoperceptie. In deze onderzoeken is een aantal menselijke fenomenen naar voren gekomen dat sterk de perceptie van risico’s bepaalt. Mensen maken bij het praten over en het inschatten van risico’s gebruik van vuistregels, ook wel heuristiek genoemd. Deze heuristiek uit zich in de fenomenen beschikbaarheid, ankeren, controle en representativiteit. Tijdens een risicoanalyse moet een risk manager zich bewust zijn van het feit dat deze fenomenen zich voordoen, zodat hij hier handig op kan inspelen.
De genoemde fenomenen worden hierna beschreven. Vervolgens worden enkele succesfactoren benoemd, die een risk manager kan inzetten tijdens een risicoanalyse, om de genoemde fenomenen te onderdrukken.

3.1 Beschikbaarheid

Bij het schatten van risico’s maken deelnemers aan een risicoanalyse veelal gebruik van de eerste associatie die wordt opgeroepen door de gestelde vraag. Deze eerste associatie is gemakkelijk beschikbaar, maar meestal geen representatieve schatting van alle ervaringen.
Zo kunnen mensen zich bij het schetsen van een scenario (scenario- informatie) meer voorstellen (associëren) dan bij het noemen van een getal (frequentie-informatie). Een voorbeeld: De omstandigheden van een ongeval op plaats A worden op precieze wijze beschreven. Ook wordt verteld dat op plaats B 100 ongelukken per jaar plaatsvinden. Mensen zullen in dit geval geneigd zijn te denken dat plaats A gevaarlijker is dan plaats B. De reden is dat ze zich beter kunnen voorstellen wat op plaats A is gebeurd.

3.2 Ankeren

Deelnemers aan een risicoanalyse kiezen onbewust bepaalde uitgangswaarden bij het inschatten van bijvoorbeeld kansen. Sommige mensen kiezen 0,5, anderen 0 en weer anderen 1 als uitgangswaarde. Daarna blijft men te dicht verankerd aan deze uitgangswaarde. Deze eerste schatting blijkt vaak veel te sterk als waarheid te worden gezien. Men “ankert” alle volgende antwoorden rondom deze initiële schatting. Het resultaat is dat er veel te weinig onzekerheid wordt ingeschat.

3.3 Controle

Deelnemers aan een risicoanalyse maken andere schattingen wanneer ze denken meer controle over een situatie te hebben. Zo wordt door veel mensen autorijden veiliger geacht dan vliegen. Puur omdat mensen bij autorijden zelf achter het stuur zitten. Dit fenomeen treedt ook op als die controle er in werkelijkheid helemaal niet is. Hiermee wordt geen rekening gehouden. Verder blijkt dat beheersbare en controleerbare risico’s meer aanvaardbaar worden geacht.

3.4 Representativiteit

Deelnemers aan een risicoanalyse ervaren iets pas als een risico, als ze het representatief achten. Zo worden kleine risico’s vaak overschat en grote risico’s onderschat of soms zelfs vergeten. De reden hiervoor is dat deze laatste dan niet representatief worden geacht of dat mensen zich er geen voorstelling van willen maken.

De bovenstaande heuristiek heeft geleid tot een aantal onder psychologen bekende stellingen:

• De geschatte ernst van een risico wordt grotendeels bepaald door de geschatte omvang van mogelijke incidenten of calamiteiten (en niet door de kans erop).
• De getaxeerde kans op een ongeval wordt overwegend bepaald door de mate van persoonlijke controle dan wel georganiseerde beveiliging (en niet op feitelijke frequenties).
• De geschatte kans op verlies of ongeval is mede afhankelijk van de voorstelbaarheid van de gebeurtenis.
• De (cognitieve en emotionele) voorstelbaarheid van potentiële catastrofes is zeer beperkt.
• De aanvaardbaarheid van een potentiële activiteit wordt overwegend bepaald door zijn voordeligheid (en niet door zijn “risico-ernst”).

4. De succesfactoren

Gegeven de bovenstaande heuristiek en de stellingen luidt nu de vraag: hoe kan hiermee worden omgegaan tijdens een risicoanalyse? Hiervoor is een vijftal succesfactoren benoemd, die tijdens een risicoanalyse handvaten bieden en als richtlijn kunnen dienen.

• Ten eerste is het altijd van belang om mensen te wijzen op het bestaan van de heuristiek. Doel hiervan is om enige zelfreflectie op te roepen, waardoor mensen worden gedwongen om kritisch hun eigen interpretaties te overwegen. 
• Ten tweede kan het erg praktisch zijn om een vraag op meerdere manieren te stellen. Bij het inschatten van lengtes kunnen bijvoorbeeld de volgende twee vragen worden gesteld: “Hoeveel procent van de mensen is langer dan 1.80 m.?” én “Welke lengte hebben de mensen die tot de langste 10% behoren?”. De deelnemers hoeven uiteraard niet van mening te zijn dat op deze vragen hetzelfde antwoord dient te worden gegeven. Ze zullen echter wel de neiging hebben om de antwoorden onderling te vergelijken en eventueel hun antwoorden bij te stellen. 
• Ten derde is het goed om de deelnemers aan een risicoanalyse te laten oefenen met het inschatten van risico’s en ze te leren welke fouten ze kunnen maken door het gebruik van heuristische regels. Het blijkt dat experts die getraind zijn in het schatten van onzekerheden beter schatten dan experts die niet zijn getraind. Het schatten van onzekerheden en risico’s blijkt een vak apart, dat niet wordt gevormd door de inhoudelijke kennis van een discipline.
• Ten vierde is het presenteren van de resultaten van een analyse niet genoeg. Een risico is namelijk pas een risico als het ook zo wordt gevoeld: er is een wereld van verschil tussen rationele en emotionele herkenning van risico’s. Daarom worden sommige beheersmaatregelen als zeer afstandelijk ervaren: het risico wordt niet gevoeld. Het is van belang om hierin tijd te investeren en verantwoordelijkheden te delegeren, zodat de deelnemers voelen waar het om gaat. 
• Ten vijfde zou het kweken van de attitude “omgaan met risico’s” een belangrijk aandachtspunt kunnen zijn bij de opleiding en training van projectleiders. Selectie van risicobewuste projectmanagers door middel van bijvoorbeeld certificering kan ook een stap in de goede richting zijn.

Verder kan de risk manager gebruik maken van de “petten van de Bono”. Hiermee kan hij deelnemers aan de risicoanalyse vanuit een bepaald gevoel laten redeneren. Hij kan bijvoorbeeld een aantal mensen uit de groep emotioneel laten reageren of juist rationeel. Hij kan anderen als pessimisten tegen de risico’s aan laten kijken of juist als optimisten. Op deze manier worden de verschillende gevoelens die heersen expliciet gemaakt, waardoor ze gemakkelijker bespreekbaar worden.

5. Informatie inwinnen

De risk manager kan, gebruik makend van bovenstaande overwegingen over risicoperceptie, informatie inwinnen met als doel kennis te nemen van de risico’s die een rol spelen bij het project. Hiervoor kunnen de volgende instrumenten worden gebruikt:

• individuele interviews,
• een brainstorm sessie,
• een enquête.

Tijdens het inwinnen van informatie doet zich een aantal valkuilen voor, waarvoor de risk manager beducht moet zijn. Een aantal hiervan heeft te maken met “lastige” deelnemers aan een risicoanalyse. Profielschetsen van deze personen zijn bijvoorbeeld:

• de onwillige deelnemer, die eigenlijk helemaal niet mee wil doen, de risicoanalyse onzinnig vindt en de analist een betweter.
  De houding van deze deelnemer kan invloed hebben op de rest van de deelnemers. Zodoende moet zoveel mogelijk worden getracht deze deelnemer op een positieve manier te laten bijdragen. De projectleider is hiervoor de verantwoordelijke persoon.
• de optimist, die nergens risico’s ziet.
  Door deze deelnemer wordt een te rooskleurig beeld van het project geschetst. Dit kan worden ondervangen door gebruik van de “petten van de Bono”.
• De pessimist die overal risico’s ziet.
  Door deze deelnemer wordt een te negatief beeld van het project geschetst. Dit kan worden ondervangen door gebruik van de “petten van de Bono”.
• de ondeskundige die geen verstand heeft van de zaken waar hij uitspraken over doet.
  Door uitspraken van deze persoon kan onterecht een foutief beeld worden geschetst van het project. Deze deelnemer moet door de andere deelnemers tot de orde worden geroepen.

6. Meer succesfactoren

De opdrachtgever van de risicoanalyse kan beperkingen opleggen aan de analyse. Over bepaalde onderwerpen mag bijvoorbeeld niks aan de deelnemers worden gevraagd of bepaalde mensen mogen niet worden geïnterviewd. De risk manager moet de opdrachtgever er van overtuigen dat op deze wijze geen reëel beeld van de risico’s binnen het project kan worden verkregen en dat het project hierbij niet is gebaat (Zie ‘Risman projectrisicomanagement: projectinterne risico’s’).
Een risicoanalyse kan als bedreigend worden ervaren, bijvoorbeeld doordat deze wordt gezien als een toets op persoonlijk functioneren. Daardoor kan het gebeuren dat de risk manager soms weinig medewerking krijgt. Om dit te ondervangen moet de projectleider het doel van de risicoanalyse uitdragen en daadwerkelijk laten zien dat de risicoanalyse vertrouwelijk wordt behandeld. Bovendien moet hij dit vertrouwen niet beschamen.
Het is mogelijk dat de inschattingen van de projectteamleden structureel verschillen van die van de projectleider, bijvoorbeeld als de projectleider andere belangen heeft (dubbele agenda) dan de projectteamleden. Als de risk manager dit tijdens de risicoanalyse merkt, kan hij er actief op aansturen dat de projectteamleden en de projectleider dit bespreken of de dubbele agenda van de projectleider als een risico voor het project benoemen.
De deelnemers kunnen aan het begin van een project onzekerheden bewust te ruim inschatten om speelruimte in (deel-)ramingen of planningen te creëren. Om dit te voorkomen kunnen bijvoorbeeld weer de “petten van de Bono”  van pas komen. Door de werkelijke pessimisten als pessimisten en de werkelijke optimisten als optimisten de kansen in te laten schatten wordt een grote bandbreedte verkregen, die vanzelfsprekend moet worden besproken.
Tenslotte kunnen “techneuten” onwillig zijn om te praten over “softe” onderwerpen als organisatie en communicatie. Om deze personen mee te krijgen moet het doel van de risicoanalyse tot hen doordringen. De projectleider is de aangewezen persoon om dit te bewerkstelligen.

7. Informatie uitdragen

Informatie uitdragen door de risk manager kan verschillende doelen hebben. Het kan gericht zijn op:

• voorlichting en educatie: bijvoorbeeld over het doel en de aanpak van de risicoanalyse;
• gedragswijziging van een groep of individu: bijvoorbeeld bewustwording van risico’s of het bespreekbaar maken van risico’s;
• gezamenlijke besluitvorming en conflictoplossing: bijvoorbeeld prioritering van risico’s of keuze van beheersmaatregelen.

De risk manager kan hiervoor de volgende instrumenten gebruiken:

• presentatie aan een groep;
• schriftelijke rapportage;
• deelneming aan een vergadering als participant of als procesbegeleider.

Valkuilen waar de risk manager tijdens het uitdragen van informatie beducht voor moet zijn:

• de verwachtingen bij de deelnemers over het resultaat van de risicoanalyse; deze kunnen verschillen van de realiteit;
• de opdrachtgever van de risicoanalyse legt beperkingen op aan de analyse; bepaalde resultaten mogen niet gepresenteerd worden.

Het verschil tussen de realiteit en de verwachtingen bij de deelnemers kan worden beperkt door tijdens de risicoanalyse op een open wijze te communiceren. Zo worden de deelnemers optimaal op de hoogte gehouden, waardoor de uiteindelijke resultaten niet als een verrassing kunnen aankomen.

8. Meer over de Risman-methodiek

In dit artikel zijn we ingegaan op wat de Risman-methodiek zegt over de succes-en faalfactoren bij communicatoe over projectrisico’s. Andere artikelen in deze serie zijn:

• ‘Risman project risico management: de spelers en het spel’
  Dit artikel is te beschouwen als een overview van project risico management inclusief de probleemstelling (het spel) en een omgevingsanalyse met aandacht voor de partijen en hun relaties (de spelers).
• ‘Risman projectrisicomanagement: projectinterne risico’s’
  Dit artikel gaat in op de risico’s die onder het tapijt verdwijnen als projecten opgedeeld worden in deelprojecten en op de kloof die er vaak bestaat tussen de perceptie van het projectresultaat en het daadwerkelijke effect, dat met het project gerealiseerd moet worden.
• ‘Risman projectrisicomanagement: projectexterne risico’s’
  Dit artikel gaat in op de vaak conflicterende belangen van opdrachtgevers en opdrachtnemers, dreigende win-loose situaties en de angst dat men voor incompetent wordt versleten.

Natuurlijk is de Risman-methodiek geen ’silver bullet’- oplossing. Wel kan de methodiek u helpen uw projecten beter te beheersen onder Einsteins motto: “Maak de dingen zo simpel mogelijk, maar niet simpeler”.

Als u ook geïnteresseerd bent in het gebruik van de Risman methodiek voor project risico management, dan kunnen we u uiteraard verder helpen met de volgende diensten:

• ZBC treedt op als risk manager of als coach van de opdrachtgever of de projectmanager. Belt u gerust of gebruikt u het reactieformulier voor meer informatie.
• De ‘Groepstraining on the job: integratie functioneel en technisch beheer en applicatiebeheer’. Deze training wordt ook als open training aangeboden, mits hier voldoende belangstelling voor is. Bel gerust of gebruik het reactieformulier voor meer informatie.
• Verder biedt onze partner IMF een Schriftelijke cursus Project risicomanagement aan, die ook gebaseerd is op de Risman methodiek.

Download:         

Gerelateerde artikelen:

1. Risman project risico management: de spelers en het spel
2. Risman projectrisicomanagement: projectexterne risico’s
3. Risman projectrisicomanagement: projectinterne risico’s

1. Wie heeft ooit de stuurgroep verzonnen?
2. Hoe werken stuurgroepen?
3. Case: Elektronisch Patiënten Dossier (EPD)
4. De stuurgroep moet weten waarvoor zij staat 

1. Wie heeft ooit de stuurgroep verzonnen?

In het rijtje van uitgestorven dieren komt de stuurgroep helaas nog niet voor. Is dit terecht? Laten bedrijven in elk geval van de stuurgroep geen beschermde diersoort maken, want daarmee zouden zij zichzelf in de problemen kunnen brengen.
Stuurgroepen stammen vooral uit de tijd dat de ICT nog onvolwassen en onvoorspelbaar was en dat bedrijven er toch behoefte aan hadden om de ontwikkeling van ICT-systemen te beheersen. Het gezwel stuurgroep heeft zich vervolgens uitgezaaid naar andere gebieden, als innovatie, kwaliteit, kennismanagement en andere trendy ontwikkelingen, veelal met desastreuze gevolgen.
Laten we eerst even ingaan op het verschijnsel stuurgroep. Stuurgroepen komen voor op plekken in organisaties waar ontwikkelingen plaatsvinden, die het management niet doorgrondt en waarvoor de verantwoordelijke manager zich graag indekt. Door de verantwoordelijkheid te beleggen in een gremium waarin niemand een taakomschrijving heeft, wordt deze zo verdeeld, dat in de praktijk niemand meer verantwoordelijk is. Daarmee is de zaak voor de verantwoordelijke manager opgelost.
Natuurlijk ben ik me ervan bewust, dat dit een nogal cynische omschrijving is. Maar in de praktijk heb ik dit al heel vaak zo meegemaakt. Stuurgroepvorming is begrijpelijk, als een organisatie met nieuwe ontwikkelingen wordt geconfronteerd. Maar zorg er dan wel voor, dat de inzet van die ontwikkelingen de organisatie ten goede komt. En juist op dat gebied willen stuurgroepen nog wel eens uit de bocht vliegen.   

2. Hoe werken stuurgroepen?

Veel stuurgroepen laten zich vergiftigen door methodieken voor een projectaanpak. Als er eenmaal een projectplan ligt, dan nemen zij de bewaking op zich. Ze wensen gerapporteerd te worden over de voortgang en de bestedingen en constateren vervolgens dat het project niet op schema ligt. Alsof de projectmanager dat zelf al niet wist!
In feite gaat de stuurgroep hiermee op de stoel van de projectmanager zitten en opereert ze volledig op tactisch niveau. Impliciet verkrijgt de projectmanager hiermee decharge. En dan is er niemand meer, die erop blijft letten of de doelstellingen van het project wel bereikt worden en of daarop mogelijk tussentijds bijgestuurd moet worden. (Zie ook ‘Projectinrichting en opdrachtbeheer’.)
Juist daarvan heeft een stuurgroep verstand. Een stuurgroep is als geen ander in staat te beoordelen of de inzet van ‘wat dan ook’ aan innovatieve technologieën bijdraagt aan de huidige bedrijfsvoering. Daarover moet zij gerapporteerd worden en aan de hand van die rapportages moet zij keuzes maken of het project misschien bijgestuurd moet worden. (Zie ook ‘Risman projectrisicomanagement: projectinterne risico’s’.)
Overschrijdingen in tijd of geld zijn pas relevant, als de stuurgroep van mening is dat het risico bestaat dat de investeringen niet meer terugverdiend kunnen worden. Als de stuurgroep tot die conclusie komt, dient zij niet plaats te nemen op de stoel van de projectleider, maar moet zij zich afvragen: 

• Halen we de projectleider van de klus; functioneert hij onvoldoende?
• Stoppen we het project?
• Stellen we het ambitieniveau van het project bij?
• Herdefiniëren we de doelstellingen van het project?
• Huren we externe capaciteit in om te redden wat er te redden valt?

Over operationele zaken moet een stuurgroep niet eens iets willen weten.
Helaas zien we in de praktijk, dat de stuurgroep vaak plaatsneemt op de stoel van de projectmanager en dat de projectmanager gaat focussen op de operatie binnen het project. Niet voor niets gaan zoveel projecten de mist in. We noemen: 

• de Betuwelijn; een op zich fantastische infrastructuur, waar echter, gezien de overschrijding in de kosten, geen klanten voor zijn.
• de ERP-implementatie bij Defensie, waar de discussie ging over de vraag of het pakket 12 miljoen dan wel 20 miljoen per jaar mocht kosten, terwijl de implementatiekosten begroot werden op een half miljard.
• het project ‘opvolging Pim Fortuin’; voor de LPF zijn er intussen geen kiezers meer, veroorzaakt door een gebrek aan leiderschap na het wegvallen van Pim Fortuin.

In al deze gevallen geldt, dat er gestuurd is op het ‘hoe’ en niet op het ‘wat’ en helemaal niet op het ‘waarom’. (Zie ook ‘Bij projectmatig werken zijn afspraken beter dan procedures’.)  

3. Case: Elektronisch Patiënten Dossier (EPD)

Een ander voorbeeld is het Elektronisch Patiënten Dossier (EPD) in de Zorg. Dit project is nog wel niet op de klippen gelopen, maar het is zorgwekkend te zien, dat hierover, met name over de doelstellingen, geen publieke discussie komt.
Doel van het EPD is dat verzorgenden informatie kunnen uitwisselen over patiënten en hun historie. Hiermee wordt de efficiency van behandelingen verbeterd en wordt het risico op aansprakelijkheid vanwege strijdige behandelingen voor de zorgverleners kleiner. Ook wordt het mogelijk patiënten in hoog tempo door te schuiven naar goedkopere vormen van zorg.
Zoals ook blijkt uit onderstaande afbeelding, ontbreekt dus in het managementsysteem van het EPD de aansturing van zorgverlenersmiddelen, waarmee zorg verleend kan worden aan patiënten. Op deze wijze is de grote winnaar in het EPD- verhaal direct de zorgverzekeraar en indirect de overheid. 

Figuur 1: Elektronisch Patiënten Dossier, aangevuld met planningsaspecten

Jaarlijks sterven meer dan 500 patiënten die op de wachtlijst staan. Voor de zorgverzekeraars is dit niet nadelig. Ook is het niet nadelig voor de zorgverzekeraars dat mensen niet, zoals auto’s dat wel moeten, een APK-keuring hoeven ondergaan. Het bespaart in elk geval aanzienlijk in de kosten. Je moet er toch niet aan denken, dat al die gebreken van mensen behandeld moeten worden. Dat zou de zorgverzekeraars veel geld kosten. En het zou ook nog eens een additionele kostenpost tot gevolg hebben. Steeds meer mensen zouden dan later aan ouderdom sterven, wat ook weer aanzienlijke kosten met zich meebrengt.
Gelukkig voor de zorgverzekeraars en de overheid zijn er voor het EPD met betrekking tot deze zaken geen doelstellingen gedefinieerd. Het Elektronisch Patiënten Dossier wordt een volledig statisch systeem, niet gericht op een betere behandeling van patiënten, maar puur op de kostenefficiency van de Zorg. Niet de toekomstige bedreiging van de gezondheid staat centraal, maar uitsluitend de historie.
Het grootste problemen in deze case: Wie is de opdrachtgever en welk belang moet er gediend worden. Natuurlijk kun je uitgaan van het principe: ‘Wie betaalt, bepaalt’. Je loopt dan echter onmiddellijk aan tegen een ander probleem: de hele financiering van de overheid ligt bij burgers en bedrijven, of anders gezegd: bij de (potentiële) patiënten, die het betreft.
Natuurlijk kiezen we eens per vier jaar onze volksvertegenwoordigers, die namens ons spreken en onze belangen behartigen.  Maar heeft u in de afgelopen jaren een volksvertegenwoordiger gehoord over preventieve zorg? Zover ik weet, ging het alleen over kosten en eigen verantwoordelijkheid.
Even terug naar het EPD. Als dit de gezondheidszorg te goede moet komen, moet niet alleen geregistreerd worden wat de status is van een patiënt. Veel belangrijker is dat ook de dynamiek ondersteund wordt, die leidt tot een betere zorg in de vorm van behandelplannen en vooral in de vorm van planning van preventief onderhoud op u en mij.  

4. De stuurgroep moet weten waarvoor zij staat

In het voorbeeld van het EPD hebben we natuurlijk te maken met een ingewikkelde structuur. De Kamer zou moeten optreden als stuurgroep of als controleur van de stuurgroep, die ongetwijfeld op projectniveau bestaat. Maar wie dan de opdrachtgever van het project is, is onduidelijk.
Het is de keerzijde van ons veelgeroemde poldermodel. De collectieve verantwoordelijkheid, die voortvloeit uit het poldermodel, is voor beleidsvorming niet alleen acceptabel, maar kan er zelfs voor zorgen dat het resultaat meer wordt dan de som der delen. Een project echter wordt door de projectmanager op tactisch niveau bestuurd en het projectresultaat wordt ook op tactisch niveau tot stand gebracht, veelal met als doel een strategisch effect op de organisatie. Het is dit effect, dat de stuurgroep moet bewaken. Het is het effect dat moet renderen. Maar uiteraard moet dit effect wel vastgelegd worden in doelstellingen, tijd en geld, zodat daarop gestuurd kan worden; niet door in te grijpen in het project, maar door beslissingen te nemen over het project, beslissingen over waar de paaltjes staan en over wanneer de stekker uit het project gehaald moet worden, omdat het effect binnen de gedefinieerde randvoorwaarden niet bereikt gaat worden. Het nemen van die beslissingen is de taak van de stuurgroep. Het continu evalueren van de doelstellingen in termen van ‘de goede dingen doen’ in plaats van ‘de dingen goed doen’ is de verantwoordelijkheid van de stuurgroep. Daarbij moet duidelijk zijn wie welke verantwoordelijkheden heeft in welke fase van het project. (Zie ook ‘Opdrachttypen voor projecten’.)
Als het EPD inderdaad niet bedoeld is om de Zorg te verbeteren, dan heb ik niets gezegd. Dan zijn alleen de budgetoverschrijdingen van belang. Maar wie is eigenlijk de werkelijke probleemeigenaar en dus de opdrachtgever voor het EPD?
Voor projecten is het van belang, dat er een eenduidige probleemeigenaar is, die exact weet welk effect hij wil bereiken en die daarop stuurt. De overige leden van de stuurgroep zijn in feite niet meer dan een klankbordgroep voor de opdrachtgever. Hiërarchie is hierbij niet van belang. De opdrachtgever beslist en daarom moet per project een duidelijke opdrachtgever benoemd worden, die de projectmanager aanstuurt. Niet de projectmanager moet lastig gevallen worden met de meningen van de stuurgroep, maar de opdrachtgever kan daar zijn voordeel mee doen.
De opdrachtgever beslist over de meningen van de stuurgroep en niet de stuurgroep zelf. Het project is tenslotte de persoonlijke verantwoordelijkheid van de opdrachtgever. De stuurgroepleden zijn zijn klankbord.
De projectmanager heeft dus alleen te maken met de aansturing door de opdrachtgever. Niet de methode, maar de opdrachtgever bepaalt. (Zie ook ‘Prince 2 geeft de projectmanager vooraf al decharge’.) Hooguit kan hij deelnemen aan een stuurgroepvergadering voor toelichting op de issues van de opdrachtgever en om betere adviezen te verkrijgen. Maar de stuurgroep is niet zijn opdrachtgever. En natuurlijk is een project teamspel, mits wel duidelijk is, wie de kapitein is op strategisch niveau en op tactisch niveau. 

Herziene versie: 6 september 2010

Download:         

Gerelateerde artikelen:

1. Waarom veel organisaties niet met projecten kunnen omgaan
2. Waarom leveren projecten altijd resultaten die ik niet nodig heb
3. Nederlandse managers kunnen niet sturen en vernieuwen

1. Innovatie geeft per definitie onzekerheid
2. Over welke risico’s gaat het?
3. Fase 1: Portfolioanalyse
4. Fase 2: Technische risico’s managen
5. Fase 3: Scenariorisico
6. Je hebt leugens en statistiek

1. Innovatie geeft per definitie onzekerheid

Het innovatieproces verschilt van alle andere projectvormen, daar het doorgaans een hoger onzekerheidsniveau met zich brengt. Voor een beetje ondernemer is dit het intrappen van een open deur en is risico nemen een natuurlijk onderdeel van het ondernemen. De volgende kwestie is uiteraard, dat er goede en slechte ondernemers zijn of als u dit liever heeft: succesvolle en niet succesvolle ondernemers. Veelal zit dit niet in het hebben van goede ideeën voor innovatie, maar juist in het managen van deze innovatie met de bijbehorende onzekerheid, gebruik makend van lessen uit het verleden. (Zie ook ‘Innovatie is leren van het verleden voor een betere toekomst’.) Daarom moet het inschatten van de risico’s prioriteit van het management hebben. In essentie is innovatie de succesvolle commercialisering van een idee, of dat nu een efficiënter bedrijfsproces is, een nieuw product of een nieuwe dienst. Hoe innovatiever het project, hoe groter het risico. Bijgevolg vereist innovatie dat managers risico aanvaarden in plaats van het te verwerpen. (Zie ook ‘LEF, Moet je dat willen?’.)

Gedurende heel de ontwikkelingsfase van een nieuw product moeten de risico’s in het oog gehouden worden, dus zowel bij de oorspronkelijke keuze voor een innovatieproject als in het daaropvolgend beheer ervan. De eerste stap is de analyse van de portfolio, met andere woorden de selectie van een groep innovatieprojecten en, voor elk van hen, de evaluatie van de risico’s en mogelijke opbrengsten.

2. Over welke risico’s gaat het?

Voor elk innovatieproject moet een gedetailleerde evaluatie doorgevoerd worden aangaande zowel het technisch als het scenariorisico. Technisch risico, dat bestaat voor alle soorten projecten, betreft de vraag of het voorgenomen werk uitgevoerd kan worden binnen het vereiste tijdsbestek en binnen budget. Heel wat producten mislukken, omdat technische kwesties niet worden opgelost. Zo hebben banken ooit vele tientallen miljoenen geïnvesteerd in de ontwikkeling van multifunctionaliteit op de Chipknip, maar uiteindelijk is dit destijds niet gelukt, met als effect dat de belangrijkste klanten afhaakten en een tweede poging kansloos was.
Scenariorisico is de onzekerheid over de doelstellingen van een project, bijvoorbeeld of een bepaald nieuw product wel geschikt is voor de doelmarkt. Scenariorisico is belangrijk bij innovatie, maar niet bij andere types van projecten. Een project om bijvoorbeeld een brug te bouwen, houdt een technisch risico in, maar heeft geen last van scenariorisico.  De vraag of een brug nodig is, valt immers eenvoudiger te beantwoorden dan de vraag of een nieuw product succes zal kennen. In het voorbeeld van de Chipknip zagen we dat het technische probleem onmiddellijk leidde tot een scenario probleem, waardoor het direct einde oefening was. Het vertrouwen was verloren gegaan bij de doelgroep.

3. Fase 1: Portfolioanalyse

Managers moeten een keuze maken tussen verschillende projecten, die allemaal dingen naar de schaarse beschikbare middelen en ze moeten zorgen voor een evenwicht tussen projecten met een hoog en een laag risico. Het is niet eenvoudig om een volledige evaluatie te verkrijgen van de projectrisico’s. Het is dus belangrijk dat die procedure goed gestructureerd wordt. Zo moeten managers vermijden te vertrouwen op individuen, omdat kennis en ervaring waarschijnlijk verspreid zijn over een heleboel mensen. Bovendien heeft niet iedereen dezelfde aanleg om waarschijnlijkheden in te schatten. De beste schattingen zullen waarschijnlijk dan ook voortkomen uit een goed gekozen groep, die antwoorden geeft op een reeks vragen aangaande risico-evaluatie.

Werner Widman, een ervaren financieel directeur van Agilent Technologies, heeft een systematische benadering ontwikkeld voor het inschatten van de risico’s die gepaard gaan met de r&d-projecten van de onderneming. Ten eerste wordt een strategische analyse van de portfolio gemaakt om na te gaan of hij evenwichtig is op het gebied van risico en opbrengsten. Ten tweede zorgt een evaluatie van de onzekerheden op de markt voor zekerheid dat de onderneming een goed rendement kan halen tijdens oplevingen en geen schade lijdt tijdens minder periodes. Ten derde krijgen individuele projecten een score, waarbij gebruik gemaakt wordt van een raamwerk waarin zaken als verwachte rentabiliteit en de ontwikkeling van de concurrentiesituatie aan bod komen.

De keuze of gezien de risico’s en de potentiële baten een innovatie toch geïnitieerd wordt, blijft een keuze waarvoor geen regels bestaan. (Zie ook ‘Innovatie is een middel en geen doel‘.) Duidelijk is echter dat baanbrekende innovaties met het grootste potentieel uiteraard ook het hoogste risico met zich meebrengen.

4. Fase 2: Technische risico’s managen

‘Failure modes and effects analysis’ (FMEA) is een techniek waarbij de waarschijnlijkheid en mogelijke ernst van technische fouten in een project worden nagegaan. Elk aspect wordt tijdens de ontwikkeling gevolgd om na te gaan op welke wijze het kan mislukken. Elk type storing krijgt dan een score van 1 tot 10, naargelang de waarschijnlijkheid dat die storing zal voorkomen, en nog eens een score van 1 tot 10 naargelang de ernst van de mogelijke weerslag. Door beide getallen met elkaar te vermenigvuldigen wordt de risicoprioriteitsscore bepaald, een indicatie van het risico dat door die bepaalde falingsmodus geschapen wordt.

FMEA draagt bij tot de vermindering van technische risico’s, maar een ander belangrijk onderdeel is ervoor te zorgen dat fundamentele lessen getrokken worden aan het einde van elk project. Wipro Technologies, ’s werelds grootste leverancier van r&d-diensten, legt sterk de nadruk op een constante verbetering van zijn bekwaamheid om technisch risico in te schatten. ‘We voeren meer dan vijfhonderd projecten uit per jaar en na elk project analyseren we de technische en managementlessen die we eruit kunnen halen’, zegt A. Vasudevan, vice president van de onderneming.

5. Fase 3: Scenariorisico

Heel wat nieuwe ideeën mislukken, maar andere doen het dan weer beter dan verwacht of slagen op onverwachte markten. Hadden bijvoorbeeld de uitvinders van de Pokemon-kaarten er wel een idee van hoe succesvol hun vinding zou worden? Het feit dat onzekerheid, als ze behoorlijk beheerd wordt, zowel een bron van winst als van verlies kan zijn, is iets wat de financiële markten al lang begrepen hebben. Door een optie te kopen op een aandeel, in plaats van het aandeel zelf, kan iemand winst maken als de prijs stijgt, maar alleen maar een klein en gecontroleerd verlies als hij daalt. Hoe wispelturiger de prijs, hoe meer positieve kansen er zijn en hoe waardevoller dus de optie.
Dezelfde filosofie zou managers moeten leiden bij innovatieprojecten. De taak van het management is niet het project tot één of ander middelmatig resultaat brengen, maar de uitersten managen, meer bepaald ernaar streven om het slechtste geval te vermijden, maar ook erkennen dat er op elk moment een optie voor meer succes kan opduiken. Hoe onzekerder een project, hoe waardevoller de positieve kanten kunnen zijn. Elk project kan uiteenlopende uitkomsten opleveren en aan elke daarvan kan een waarschijnlijkheid gekoppeld worden. Statistisch gezien wordt de beste schatting van de resultaten van een project verkregen door elke uitkomst met haar waarschijnlijkheid te vermenigvuldigen en vervolgens het gemiddelde of te verwachten resultaat te berekenen. Neem bijvoorbeeld een nieuw product dat een onderzoeksfase heeft die 4 miljoen euro kost en een ontwikkelingsfase die voor de verwachte lancering 4 miljoen euro zal kosten. Stel vervolgens dat de managers schatten dat er een kans van 30 procent bestaat dat het project afgevoerd wordt na de onderzoeksfase en dat er een kans van 10 procent is dat het geschrapt wordt aan het einde van de ontwikkelingsfase. Dan blijft er nog een kans van 60 procent dat het uiteindelijk tot een commercialisering komt. Afhankelijk van hoe goed het technische werk vordert, is er bovendien 50 procent kans dat er 20 miljoen euro winst gemaakt wordt en 10 procent kans dat er 40 miljoen euro verdiend wordt. Dat wil dus zeggen:

Verwachte projectwaarde = – € 8m x 10% – € 4m x 30% + € 20m x 50% + € 40m x 10% = € 12 miljoen.

6.  Je hebt leugens en statistiek

De gevolgde logica is weliswaar onberispelijk, maar ze levert niet op wat verwacht kan worden op basis van de hiervoor vermelde cijfers. Dit specifieke project zal in feite slechts één van vier uitkomsten te zien geven: een verlies van 4 of 8 miljoen euro of een winst van 20 of 40 miljoen euro, maar nooit een winst van 12 miljoen!
Bijgevolg moeten managers van innovatieprojecten zich niet blind staren op een gemiddelde uitkomst. De identificatie van een reeks mogelijke uitkomsten maakt projectplanning realistischer. En dat heeft niet alleen te maken met het innovatieve karakter van het product, maar in Nederland als diensteneconomie ook met het innovatieve karakter van het proces. (Zie ook ‘Geen productinnovatie maar procesinnovatie’.) Het is dan ook de taak van het management om een zekere flexibiliteit te ontwikkelen in de organisatie, zodat die snel reageert als zich positieve mogelijkheden voordoen. Als je als bedrijf meerdere innovatieprojecten initieert, dan zul je gemiddeld op dergelijke cijfers uitkomen. Als het echter gaat om één project, dan is de kans fifty-fifty, dat het winstgevend wordt.
Innovatierisico managen vereist in veel bedrijven een verandering van aanpak. In plaats van zich te concentreren op een enkele ‘gemiddelde’ uitkomst die gebaseerd is op een beperkte en vaak al te optimistische visie op het project, moeten managers flexibiliteit ontwikkelen in hun organisatie om in te haken op veranderende omstandigheden. Een beslissing is goed en geldig tot we een betere beslissing nemen.

De belangrijkste variabelen, waarop gestuurd wordt zijn:

• financiën,
• risico,
• beschikbare middelen,
• flexibiliteit om de productie op te voeren of te verlagen. (zie ook ‘Hoe realiseren dienstverleners concurrentiekracht?’),
• het vertrouwen in de gemaakte veronderstellingen.

Omgaan met risico is geen exacte wetenschap en er bestaan geen onwrikbare vuistregels voor het niveau van risico dat aanvaardbaar is voor een bedrijf. Toch is een dergelijke benadering voor bedrijven, die Tabaksblat willen volgen een manier om ook innovatieve ontwikkelingen te kwantificeren. (Zie ook ‘Corporate governance in het MKB’.) Door echter gebruik te maken van een aantal instrumenten en technieken kan het management doeltreffender omgaan met risico en tegelijk de problemen verminderen en de geboden kansen grijpen. En als je niet kunt leven met onzekerheid en risico’s, dan kun je innovatie en ondernemerschap wel vergeten. Dan had je beter een eerlijk vak kunnen leren.

Download:         

Gerelateerde artikelen:

1. Innovatie is een middel en geen doel
2. Innovatie, business development of gewoon: Wie niet sterk is moet slim zijn
3. Risman project risico management: succesfactoren en valkuilen

1. Inleiding
2. Verantwoordelijkheden en bevoegdheden
3. Projectorganisatiestructuur 

1. Inleiding

In de afgelopen jaren heeft een duidelijke verschuiving plaatsgevonden in het denken over de functie van de automatisering en de informatievoorziening. Momenteel bezinnen veel organisaties zich op het rendement van de automatisering en de informatievoorziening (een zeer belangrijk, maar toch ondersteunend bedrijfsproces) voor de organisatie. In veel organisaties bestaat dan ook de behoefte om dit ondersteunende proces effectief en efficiënt te kunnen besturen, met andere woorden bestaat de behoefte bestaat om “grip te krijgen op de automatisering”. Ofschoon er de afgelopen jaren belangrijke vooruitgang is geboekt bij het rationaliseren van dit proces door onder andere het toepassen van methoden, technieken en hulpmiddelen en het opstellen van informatieplannen, is er nog geen sprake van echte “grip”. Ook de uitbesteding van automatisering (fixed price/fixed date projecten of outsourcing) blijkt zonder een adequaat opdrachtbeheer weinig meer te zijn dan het verschuiven van problemen. (Zie ook ‘Functioneel beheer en inkoop vaak bottlenecks in de ICT-leveringsketens’.)
In dit stuk wordt een aanzet gegeven om het begrip opdrachtbeheer nader uit te werken als een middel dat gebruikt kan worden door managers om grip te krijgen op de automatisering en de informatievoorziening. In het artikel ‘Blauwdruk processen IT-organisatie’ wordt het begrip opdrachtbeheer uitgewerkt en gepositioneerd in de IT-organisatie als geheel.

De essentie van opdrachtbeheer is het zorg dragen voor een balans in de verdeling van verantwoordelijkheden, bevoegdheden en risico’s met als belangrijkste doelstellingen:

• het optimaal benutten van de beschikbare kwaliteit van IT-medewerkers en materiedeskundigen;
• het creëren van een projectomgeving die het mogelijk maakt, dat de projectmedewerkers zich uitsluitend bezig houden met het bereiken van het projectresultaat binnen de gestelde randvoorwaarden;
• het maken en nakomen van afspraken;
• het creëren van een adequate rapportagestructuur, waardoor het project effectief bestuurd en bijgestuurd kan worden;
• het voorkomen van onderhandelingen tussen niet-gelijkwaardige partijen.

In hoofdstuk 2 wordt ingegaan op de verdeling van verantwoordelijkheden en bevoegdheden en wordt het begrip opdrachttype gedefinieerd, om flexibel met de verdeling van verantwoordelijkheden en bevoegdheden om te kunnen gaan. In hoofdstuk 3 tenslotte wordt de projectorganisatiestructuur onder de loep genomen en toegelicht aan de hand van praktijkvoorbeelden. 

2.  Verantwoordelijkheden en bevoegdheden

Door het realiseren van balans in verantwoordelijkheden, bevoegdheden en risico’s, zal de muur tussen de IT-medewerkers en de gebruikers geslecht kunnen worden en zullen er door een goede communicatie een vruchtbare samenwerking en een goede taakverdeling kunnen ontstaan. Pas dan kan optimaal gebruik gemaakt worden van de beschikbare expertise van zowel gebruikers als IT-medewerkers. Trefwoorden zijn: communicatie, begrip tonen en partnership. (Zie ook ‘ICT-service management: contact is belangrijker dan contract’.)
De gebruikers zijn globaal verantwoordelijk voor het definiëren van criteria, het aanleveren van specificaties, het tijdig maken van keuzes, het toetsen van producten op hun gebruikswaarde en het aanpassen van de systeemomgeving. Taken van de informatici zijn onder andere: analyseren van problemen en wensen, aanreiken van alternatieven en mogelijkheden aan de gebruikers, adviseren en ondersteunen van de gebruikers en het ontwikkelen van systemen conform de behoeften van de gebruiker en het testen van het systeem op zijn correctheid en consistentie. (Zie ook ‘BiSL maakt functioneel beheer wel erg ingewikkeld’.)

Figuur 1: Verantwoordelijkheden en bevoegdheden

Bij een dergelijke werkwijze kan ook een goede invulling gegeven worden aan het begrip kwaliteit, zoals dit in de ISO-normen (8402) is gedefinieerd:

Kwaliteit is het geheel van eigenschappen en kenmerken van een product of dienst, dat van belang is voor het voldoen aan vastgelegde of vanzelfsprekende behoeften.

Het begrip ” vanzelfsprekende behoeften” impliceert onder andere, dat het de taak van de IT-medewerker is om zaken die de gebruiker niet kan overzien, aan de orde te stellen en hem daarin te adviseren. Het belangrijkste aspect van deze definitie is echter, dat de behoefte van de afnemer centraal staat. Dit betekent onder andere dat randvoorwaarden als tijd en geld onderdeel worden van de productkwaliteit, omdat deze onderdeel zijn van de behoefte van de afnemer.
Als we bijvoorbeeld kijken naar de taken die tijdens de fasen van de systeemontwikkeling verdeeld worden tussen gebruikers en IT-medewerkers, dan is het duidelijk dat in het voortraject en het natraject de gebruikerstaken belangrijk zijn, terwijl tijdens het ontwerp en de bouw de taken van de IT-medewerkers centraal staan. Dus ook de verdeling van verantwoordelijkheden en bevoegdheden zal tijdens het traject moeten verschuiven.
Ook zullen verschillende ontwikkelingstrajecten verschillende accenten krijgen afhankelijk van onder andere de bedrijfscultuur, de functie van het systeem en de relatie tussen IT-medewerker en gebruikersorganisatie. Reeds eerder is de noodzaak aangegeven van de balans in de verdeling van verantwoordelijkheden, bevoegdheden en risico’s. Om dit hanteerbaar te maken definiëren we zogenaamde opdrachttypes. Door te kiezen voor een opdrachttype wordt gekozen voor een samenhangende set verantwoordelijkheden, bevoegdheden en risico’s, die per opdrachttype in balans zijn. Een opdrachttype is bijvoorbeeld de situatie waarin de gebruikersorganisatie alle bevoegdheden wil hebben, maar dan ook tegelijkertijd alle verantwoordelijkheden en risico’s draagt.
We definiëren hier een viertal opdrachttypes:

• Alle verantwoordelijkheden, bevoegdheden en risico’s zijn voor de gebruikersorganisatie (type 1).
• Alle verantwoordelijkheden, bevoegdheden en risico’s zijn voor de IT-organisatie (type 4).
• Er is sprake van gedeelde verantwoordelijkheden, bevoegdheden en risico’s, deze liggen echter in meerderheid aan de kant van de gebruikersorganisatie (type 2).
• Er is sprake van gedeelde verantwoordelijkheden, bevoegdheden en risico’s, deze liggen echter in meerderheid aan de kant van de IT-organisatie (type 3).

We kunnen deze typering illustreren aan de hand van de volgende afbeelding:

Figuur 2: Opdrachttypen

Het belangrijke voordeel van deze definitie van opdrachttypen is, dat er niet meer bij elk project “gevochten” hoeft te worden over de balans in de verdeling van verantwoordelijkheden, bevoegdheden en risico’s, maar alleen over welk type gewenst is, waarbij dan vervolgens de verantwoordelijkheden, bevoegdheden en risico’s al evenwichtig vastliggen. Een nadere uitwerking van deze opdrachttypen is in deze kennisbank beschreven in het artikel ‘Opdrachttypen’. Tevens ontstaat de mogelijkheid om tijdens het project het opdrachttype per fase adequaat te definiëren.

2.1 Opdrachttypen en systeemontwikkeling

In de praktijk zien we bij projecten vaak conflicten ontstaan over de verdeling van verantwoordelijkheden en bevoegdheden, ondanks toepassing van een methodiek als bijvoorbeeld SDM. Door toepassing van dit model kunnen veel van deze conflicten voorkomen worden.
In de fase definitiestudie moeten beslissingen worden genomen over afbakening, alternatieven en oplossingsrichtingen die een belangrijke impact op de organisatie hebben. Het is daarom van belang, dat de belangrijke bevoegdheden en de mogelijkheden tot bijsturing nadrukkelijk aan de gebruikerskant liggen. Wel kan van de IT-medewerkers verlangd worden, dat hun producten kwaliteit hebben, ook al is dat moeilijk aantoonbaar. Op grond hiervan ligt opdrachttype 2 voor de hand, terwijl type 1 ook mogelijk is.
Tijdens het functioneel ontwerp ligt de onzekerheid op het gebied van de specificaties en de ontwerpbeslissingen die nog genomen moeten worden. Procesmatig regisseert de IT-organisatie meestal deze fase, maar inhoudelijk de gebruikersorganisatie.
Omdat de IT-medewerkers verantwoordelijk zijn voor de oplevering van producten in deze fase, ligt opdrachttype 3 voor de hand.
We zien, dat het technisch ontwerp en de realisatie van het systeem vaak op basis van fixed-price/fixed-date worden uitbesteed, waarna vaak conflicten ontstaan over de bijvoorbeeld door SDM in deze fasen genoemde activiteiten die de gebruikers betreffen, zoals het opstellen van handmatige procedures, de voorbereiding en de uitvoering van de acceptatietest, de gebruikersdocumentatie, de invoering enzovoort. Om deze conflicten te vermijden, is het verstandig om bij de opdeling van het geheel in deelprojecten niet alleen te kijken naar technische criteria en prioriteiten, maar ook naar het opdrachttype. Op deze manier kunnen alle activiteiten die gericht zijn op de oplevering van het geautomatiseerde systeem op basis van type 4 uitgevoerd worden door de IT-organisatie, terwijl andere activiteiten op basis van type 1 parallel uitgevoerd worden.

Een mogelijke opzet is weergegeven in de volgende afbeelding:

Figuur 3: Opdrachttypen en systeemontwikkeling

3.  Projectorganisatiestructuur

Het belangrijkste verschil tussen de meestal gehanteerde beschrijvingen en de beschrijving van de projectinrichting in dit hoofdstuk, is dat de laatstgenoemde niet zozeer de hiërarchie beschrijft, maar de rolstructuur. De hiërarchische structuur is statisch van karakter en te beperkt om een project, dat veelal gekenmerkt wordt door dynamiek en afwijkingen waarop snel en adequaat gereageerd moet worden, beheersbaar te houden. In de rolstructuur kan de bijsturing veel adequater plaatsvinden.

Schematisch is de standaard projectorganisatie als volgt weer te geven:

Figuur 4: Projectorganisatiestructuur

Enkele definities:

• De opdrachtgever is een (vertegenwoordiger van een) gebruikersmanager, die als probleemeigenaar en grootste belanghebber bij het projectresultaat kan worden beschouwd. Hij treedt naar het project tevens op als budgethouder. In geval van een stuurgroep is er sprake van een gedelegeerd opdrachtgever.
• De opdrachtnemer is een vertegenwoordiger van het management van de IT-organisatie. Hij is bevoegd om overeenkomsten aan te gaan en om menscapaciteit van IT-medewerkers toe te wijzen.
• De gebruikers projectleider (GPL) is een (vertegenwoordiger) van de gebruikersorganisatie, die de andere gebruikers aanstuurt, contacten onderhoudt met de PL-IT en verantwoording aflegt aan de opdrachtgever.
• De projectleider van de IT-organisatie (PL-IT) is een medewerker van de IT-organisatie, die de andere IT-medewerkers aanstuurt, contacten onderhoudt met de GPL en verantwoording aflegt aan de opdrachtnemer.
• De gebruikersorganisatie is het bedrijfsonderdeel dat belang heeft bij en/of beïnvloed wordt door het projectresultaat.
• De IT-organisatie is een organisatie(deel), gespecialiseerd in het maken van producten en het verlenen van diensten op het gebied van automatisering en informatievoorziening.
• Een project is een samenwerkingsverband tussen de gebruikersorganisatie en de IT-organisatie, waarin op basis van een overeenkomst tussen opdrachtgever en opdrachtnemer (de projectopdracht) het in de projectopdracht overeengekomen resultaat binnen de randvoorwaarden op basis van een afgesproken opdrachttype wordt gerealiseerd.

3.1 Kenmerken

In deze structuur zijn duidelijk de drie niveaus herkenbaar, die voor de uitvoering en besturing van projecten nodig zijn:

• het uitvoerend niveau (systeem- en organisatieontwikkeling), om een werkend systeem in een werkende organisatie te realiseren;
• het projectmanagement niveau, om de voorwaarden te scheppen voor en de sturing te geven aan het uitvoerend niveau;
• het opdrachtbeheer niveau, dat het projectresultaat en de randvoorwaarden definieert en bewaakt en daarmee eindverantwoordelijk is voor de kwaliteit van het projectresultaat voor de lijnorganisatie.

Uitgangspunt is, dat alle medewerkers binnen het project uitsluitend tot taak hebben het resultaat binnen de randvoorwaarden te realiseren. Daarom worden projectgroepleden niet aangewezen om afdelingen of belangen te vertegenwoordigen, maar slechts op basis van hun bijdrage aan het projectresultaat.
Elke discussie over het waarom van het project en of het gedefinieerde resultaat ook het gewenste resultaat is, zal dus buiten het project moeten plaatsvinden, waarbij gedacht kan worden aan stuurgroepen, klankbordgroepen, acceptatiegroepen enzovoort. De opdrachtgever beslist of wensen en eisen van dergelijke groepen moeten leiden tot een wijziging van de projectopdracht.
Een ander belangrijk kenmerk van deze projectorganisatiestructuur is de scheiding tussen de projectmedewerkers van opdrachtgever en opdrachtnemer. Het probleem van twee kapiteins op één schip wordt opgelost per projecttype, waarbij één van de twee projectleiders leading wordt met betrekking tot de planning van de ander.
Een dergelijke structuur is noodzakelijk om de volgende redenen:

• Als er sprake is van hiërarchische relaties tussen medewerkers van verschillende organisaties of organisatiedelen, dan is ook een ander organisatiedeel verantwoordelijk voor het functioneren van de ondergeschikte medewerker. Daarom mag slechts een planningsrelatie bestaan tussen beide groepen.
• Bovendien geldt voor elk opdrachttype, dat de opdrachtgever en opdrachtnemer minimaal de verantwoordelijkheid hebben voor de kwaliteit van de eigen medewerkers en bij de meeste opdrachttypes ook verantwoordelijk zijn voor de kwaliteit van de door hun medewerkers op te leveren producten. Zonder een gescheiden structuur is dit niet mogelijk.
• Een totaal project is vaak opgesplitst in een aantal deelprojecten op basis van verschillende opdrachttypes. Als er geen splitsing plaatsvindt, dan kunnen opdrachtgever en opdrachtnemer hun verantwoordelijkheid per deelproject niet waarmaken.
• Conflicten die voortkomen uit onduidelijkheid over de projectopdracht kunnen naar het niveau van opdrachtgever en opdrachtnemer getild worden, zodat het soepele en resultaatgericht functioneren van de projectgroep niet in gevaar komt.

In de praktijk zien we, dat er in of rond projecten nog een aantal extra functies worden ingevuld. Deze kunnen als volgt in deze structuur worden opgenomen:

• Stuurgroepen zijn doorgaans gericht op de bedrijfsinformatievoorziening en dragen zorg voor het laten uitvoeren van dit beleid. In dit kader vallen verschillende projecten onder de stuurgroep. Daartoe benoemt de stuurgroep voor elk project een opdrachtgever, die als gebruikersmanager het meeste belang bij het projectresultaat heeft. Voorts kent de stuurgroep aan de opdrachtgever een maximaal budget toe om te besteden. (Zie ook ‘Waarom stuurgroepen vaak het roer niet kunnen vasthouden’.)
• Acceptatiegroepen en klankbordgroepen hebben een ondersteunende functie voor de opdrachtgever en maken geen deel uit van het project. Ze vallen in de totale structuur direct onder de opdrachtgever. Hun taak is, te beoordelen of het opgeleverde resultaat inderdaad aan de verwachtingen van de gebruikersorganisatie voldoet. Indien dit niet het geval is, kunnen wijzigingsvoorstellen ingediend worden.
• De projectinterne kwaliteitsborging is een staftaak die direct onder de projectleiders valt.
• De projectexterne kwaliteitsborging is een staftaak van de IT-organisatie en deze valt direct onder de opdrachtnemer.

3.2 De noodzaak van de verschillende functies

In de hier aangegeven structuur zijn een aantal functies genoemd, die in de praktijk vaak ontbreken of anders zijn ingevuld. We zullen nu vooral ingaan op problemen die in de praktijk vaak optreden bij een andere invulling.

De opdrachtgever is een lid of vertegenwoordiger van het gebruikersmanagement, dat als probleemeigenaar en grootste belanghebber bij het projectresultaat kan worden beschouwd. Hij treedt voor het project tevens op als budgethouder.

• In de praktijk zien we vaak, dat een stuurgroep zelf als opdrachtgever optreedt. Dit heeft een aantal belangrijke nadelen:
  • Omdat doorgaans zowel opdrachtgever als opdrachtnemer deel uitmaken van deze groep, die een gezamenlijke opdracht moet uitvoeren, zal er zelden sprake zijn van een overeenkomst die als duidelijke projectopdracht kan dienen en zal de verdeling van verantwoordelijkheden en bevoegdheden ook altijd vaag blijven. Ook van wederzijds commitment is vaak geen sprake.
  • Omdat de frequentie van de stuurgroepvergaderingen laag is en de scoop breed, zal de stuurgroep als opdrachtgever niet snel kunnen reageren op ontwikkelingen in het project, zodat problemen en wijzigingsvoorstellen meestal binnen het project opgelost moeten worden, hetgeen in strijd is met het uitgangspunt.
• Indien de opdrachtgever niet tevens budgethouder is voor het project, dan is het risico groot, dat er een systeem ontwikkeld wordt, dat veel te kostbaar is in ontwikkeling en beheer. Voorts zullen er mogelijk conflicten ontstaan tussen de opdrachtgever en de budgethouder, zeker als deze budgethouder deel uitmaakt van de organisatie van de opdrachtnemer.
• In de praktijk zien we vaak dat het management van de IT- organisatie optreedt als opdrachtgever. Dit betekent, dat het moet beslissen over prioriteitsstellingen van de gebruikersorganisatie, waarvoor het systeem gemaakt wordt. Als dit opgelost wordt door allerlei inspraakprocedures, zullen beslissingen te veel tijd in beslag nemen. Als dit opgelost wordt door bepalende gebruikers in het project op te nemen, dan leidt dit tot veel discussie en dus verlies van productiviteit in het project. Als het management zelf beslist, dan neemt het beslissingen over zaken waarvoor het niet bevoegd is. In al deze gevallen geldt, dat de verdeling van verantwoordelijkheden en bevoegdheden niet meer in balans is. Ook zal in deze situatie doorgaans geen evenwichtig projectcontract aanwezig zijn, dat als opdracht voor de projectleider kan dienen.

De opdrachtnemer is een vertegenwoordiger van het management van de IT-organisatie en is bevoegd om overeenkomsten aan te gaan en om menscapaciteit van IT-medewerkers toe te wijzen.

• Het ontbreken van de opdrachtnemer leidt ertoe, dat de opdrachtgever meestal direct met de PL-IT onderhandelt over de taakstelling voor het project. Dit is een ongelijke verhouding. Consequenties hiervan zijn vaak:
  • Er wordt regelmatig “ingebroken” op de lopende projecten, waardoor het onmogelijk wordt om het resultaat binnen de randvoorwaarden op te leveren. Denk onder andere aan het toevoegen van eisen, het tussentijds laten oplossen van een probleempje (vooral bij onderhoud) of het wijzigen van de projectbemanning.
  • Onrust en onderhandelingen in het project hebben negatieve gevolgen voor de motivatie, de kwaliteit en de productiviteit.
• De problemen die ontstaan als de opdrachtnemer tevens als opdrachtgever optreedt, staan reeds onder opdrachtgever vermeld.
• Bij het ontbreken van een opdrachtnemer als aanspreekpunt van de IT-organisatie, zal in de praktijk geen decharge plaatsvinden van de PL-IT en de IT-medewerkers, zodat ze vaak levenslang zijn veroordeeld tot het gerealiseerde systeem. Dit leidt er vaak weer toe, dat onderhoud niet projectmatig wordt aangepakt, met alle consequenties van dien.

De gebruikers projectleider (GPL) is een (vertegenwoordiger) van de gebruikersorganisatie, die de andere gebruikers aanstuurt, contacten onderhoudt met de PL-IT en verantwoording aflegt aan de opdrachtgever. De GPL kan optreden als meewerkend voorman.

• Het ontbreken van een GPL leidt ertoe, dat er in feite geen opdrachten op basis van type 1 en 2 mogelijk zijn.
• Het ontbreken van een gebruikersprojectleider leidt ertoe, dat de PL-IT doorgaans de gebruikers aanstuurt, zonder dat hij bevoegdheden heeft, die hem in staat stellen om problemen op te lossen. Berucht zijn de beschikbaarheidsproblemen.
• Het ontbreken van een GPL leidt er voorts toe, dat een noodzakelijk aanspreekpunt verdwijnt. Dit betreft met name de rapportage aan de opdrachtgever (die dan slechts eenzijdige informatie krijgt) en de communicatie met de PL-IT met betrekking tot probleemrapportages, wijzigingsvoorstellen, wederzijds opleveren van producten en beoordeling van producten.
• Het ontbreken van een GPL leidt er voorts toe, dat er nooit tegelijkertijd in een project deelopdrachten op basis van verschillende opdrachttypes uitgevoerd kunnen worden.

De projectleider van de IT-organisatie (PL-IT) is een medewerker van de IT-organisatie, die de andere IT-medewerkers aanstuurt, contacten onderhoudt met de GPL en verantwoording aflegt aan de opdrachtnemer. De PL-IT kan optreden als meewerkend voorman. In type 1 opdrachten bestaat zijn rol slechts uit het optreden als aanspreekpunt.

• Het ontbreken van een PL-IT komt in de praktijk zelden voor, maar indien dit het geval is, gelden dezelfde punten als onder de GPL.

De acceptatiegroep (in de praktijk ook soms klankbordgroep genoemd) heeft als taak, de opgeleverde producten namens de opdrachtgever te beoordelen. Enerzijds dient deze groep te verifiëren of de producten inderdaad voldoen aan de specificaties. Geconstateerde afwijkingen met betrekking tot dit punt leiden tot een probleemrapport. Anderzijds moet beoordeeld worden of het projectresultaat inderdaad voldoet aan de wensen van de gebruikersorganisatie. Zo niet, dan wordt een wijzigingsvoorstel ingediend.

• Indien de acceptatiegroep in het project wordt geplaatst, dan zullen er ook interne rapportage en discussie plaatsvinden. Dit zal ten koste gaan van de productiviteit. Wel kan de voorbereiding van de acceptatie en de test zelf binnen het project plaatsvinden. De interpretatie van de bevindingen dient buiten het project te gebeuren.

De projectexterne kwaliteitsborging heeft als taak, de door de IT-medewerkers opgeleverde producten te beoordelen namens de opdrachtnemer. Om de objectiviteit te waarborgen, wordt deze controle buiten het project uitgevoerd. De rapportage bestaat uit bevindingen, conclusies en aanbevelingen en vindt plaats aan de opdrachtnemer en de PL-IT. De opdrachtnemer beslist over de maatregelen, die naar aanleiding van het rapport genomen moeten worden.

De hier beschreven aanpak is goed te combineren met bestaande projectmanagementmethodieken. Denkt u, dat de combinatie met deze systematiek inderdaad voor u een oplossing biedt voor uw problemen, dan kunnen wij u helpen deze bij u pragmatisch te implementeren, zonodig in combinatie met functioneel beheer. Meer over deze aanpak leest u in ‘Groepstraining on the job: integratie functioneel en technisch beheer en applicatiebeheer’.

Herziene versie: 22 april 2010

Download:         

Gerelateerde artikelen:

1. Opdrachttypen voor projecten
2. Bij projectmatig werken zijn afspraken beter dan procedures
3. Waarom veel organisaties niet met projecten kunnen omgaan

1. Inleiding
2. Opdrachttype 1
3. Opdrachttype 2
4. Opdrachttype 3
5. Opdrachttype 4
6. Aandachtspunten bij de opdrachttypes 

1. Inleiding

Een gezond project wordt gekarakteriseerd door balans in de verdeling van verantwoordelijkheden, bevoegdheden en risico’s. Om dit hanteerbaar te maken definiëren we zogenaamde opdrachttypes. Kiezen voor een bepaald opdrachttype, betekent kiezen voor een samenhangende set van met elkaar in balans zijnde verantwoordelijkheden, bevoegdheden en risico’s. Het definiëren van opdrachttypes voorkomt bijvoorbeeld dat de gebruikersorganisatie wel alle bevoegdheden wil hebben, maar tegelijkertijd alle verantwoordelijkheden en risico’s afschuift op de IT-organisatie. Ook voorkomt het definiëren van opdrachttypes dat er allerlei ingewikkelde procedures gedefinieerd moeten worden, die in alle situaties houdbaar en bruikbaar zijn. Want dat gaat meestal toch niet werken. (Zie ook ‘Bij projectmatig werken zijn afspraken beter dan procedures’.) Het kan er zelfs toe leiden, dat de leverancier in het geheel niet meer verantwoordelijk gesteld kan worden voor het projectresultaat. De laatste jaren hebben we dat in diverse overheidsprojecten kunnen waarnemen. (Zie ook ‘Prince 2 geeft de projectmanager vooraf al decharge’.)   

We definiëren daarom een viertal opdrachttypes:    

• alle verantwoordelijkheden, bevoegdheden en risico’s zijn voor de gebruikersorganisatie (type 1);
• alle verantwoordelijkheden, bevoegdheden en risico’s zijn voor de IT-organisatie (type 4);
• er is sprake van gedeelde verantwoordelijkheden, bevoegdheden en risico’s, die echter in meerderheid aan de kant van de gebruikersorganisatie liggen (type 2);
• er is sprake van gedeelde verantwoordelijkheden, bevoegdheden en risico’s, die echter in meerderheid aan de kant van de IT-organisatie liggen (type 3).

We kunnen deze typering illustreren aan de hand van de volgende afbeelding:    

Figuur1: Opdrachttypen voor projecten

Het belangrijke voordeel van deze definitie van opdrachttypen is, dat er niet meer bij elk project gediscussieerd hoeft te worden over de balans in de verdeling van verantwoordelijkheden, bevoegdheden en risico’s, maar alleen over welk type gewenst is, waarbij dan vervolgens de verantwoordelijkheden, bevoegdheden en risico’s al evenwichtig vastliggen. De opdrachttypes worden hier beschreven vanuit de optiek van de IT-medewerkers, aangezien het initiatief voor een dergelijke ontwikkeling in de praktijk helaas nog moet worden genomen door de IT- organisatie. De gebruikersinvalshoek is natuurlijk complementair.
Elk hoger opdrachttype (vanuit het perspectief van de IT-medewerker) is inclusief de verantwoordelijkheden, bevoegdheden en risico’s van de voorgaande opdrachttypes. Bij de uitwerking van de opdrachttypen wordt uitgegaan van de volgende projectstructuur:    

Figuur2: Projectstructuur

 Definities:    

• De opdrachtgever is een (vertegenwoordiger van een) gebruikersmanager, die als probleemeigenaar en grootste belanghebber bij het projectresultaat kan worden beschouwd. Hij treedt naar het project tevens op als budgethouder.
• De opdrachtnemer is een vertegenwoordiger van het management van de IT-organisatie en is bevoegd om overeenkomsten aan te gaan en om menscapaciteit van IT-medewerkers toe te wijzen.
• De gebruikersprojectleider (GPL) is een (vertegenwoordiger) van de gebruikersorganisatie, die de andere gebruikers aanstuurt, contacten onderhoudt met de PL-IT en verantwoording aflegt aan de opdrachtgever.
• De projectleider van de IT-organisatie (PL-IT) is een medewerker van de IT-organisatie, die de andere IT-medewerkers aanstuurt, contacten onderhoudt met de GPL en verantwoording aflegt aan de opdrachtnemer.
• De gebruikersorganisatie is het bedrijfsonderdeel dat belang heeft bij en/of beïnvloed wordt door het projectresultaat.
• De IT-organisatie is een organisatie(deel) gespecialiseerd in het maken van producten en het verlenen van diensten op het gebied van automatisering en informatievoorziening.
• Een project is een samenwerkingsverband tussen de gebruikersorganisatie en de IT-organisatie, waarin op basis van een overeenkomst tussen opdrachtgever en opdrachtnemer (de projectopdracht) het in de projectopdracht overeengekomen resultaat binnen de randvoorwaarden op basis van een afgesproken opdrachttype wordt gerealiseerd. 

2.  Opdrachttype 1

Bij opdrachttype 1 liggen de verantwoordelijkheden, bevoegdheden en risico’s nagenoeg volledig aan de kant van de opdrachtgever.    

Figuur3: Opdrachttype 1

De opdrachtnemer is slechts verantwoordelijk voor de kwaliteit van zijn medewerker(s). In de overeenkomst kan dan ook meestal volstaan worden met een beschrijving van de gewenste kwaliteit van de door de IT-organisatie te leveren medewerkers voor een aantal uren in een bepaalde periode tegen een bepaald tarief op basis van nacalculatie. Over alle andere zaken beslist de opdrachtgever.    

• De opdrachtnemer heeft dus geen enkele verantwoordelijkheid voor de realisatie van het projectresultaat binnen de randvoorwaarden.
• De gebruikersprojectleider (GPL) is leading en hij is verantwoordelijk voor het realiseren van het projectresultaat binnen de gestelde randvoorwaarden.
• Het opstellen en bewaken van het projectplan en de planning kan de GPL delegeren, maar de verantwoordelijkheid ligt bij de GPL.
• De PL-IT heeft geen verantwoordelijkheid. Hij treedt slechts op als contactpersoon naar de GPL, IT-medewerkers en de opdrachtnemer.
• Omdat de opdrachtnemer niet verantwoordelijk is voor de productkwaliteit, zullen door hem geen standaard-audits worden uitgevoerd.

Dit opdrachttype is gewenst voor alle werkzaamheden waarbij de gebruikersorganisatie het resultaat vooraf niet kan of wil specificeren. De gebruikersprojectleider bepaalt, welke producten wanneer door de IT-medewerkers aan hem worden opgeleverd. De voortgangsrapportage en urenverantwoording van de IT-medewerkers is aan de GPL.    

• Probleemrapportages van de IT-medewerkers aan de opdrachtnemer kunnen slechts betrekking hebben op overschrijding van de contractueel overeengekomen inspanning of op het ingezet worden voor taken waarvoor men niet gekwalificeerd is.
• Probleemrapportages van de GPL kunnen betrekking hebben op alle aspecten van het project (projectresultaat, randvoorwaarden, kwaliteit van medewerkers etc.). 

 3.  Opdrachttype 2

Bij Opdrachttype 2 zijn de verantwoordelijkheden, bevoegdheden en risico’s verdeeld, maar ze liggen voor het grootste deel aan de kant van de opdrachtgever.    

Figuur4: Opdrachttype 2

De opdrachtnemer is verantwoordelijk voor de kwaliteit van het op te leveren product. De inspanning van medewerkers van de opdrachtnemer wordt vergoed op basis van nacalculatie.   

• In de overeenkomst wordt dan ook minimaal beschreven welke producten opgeleverd worden en aan welke eisen deze producten moeten voldoen (meestal via een verwijzing naar standaards of een handboek). Indien de gebruikersorganisatie niet beschikt over deze standaards, is de opdrachtnemer bevoegd om zijn productstandaards als projectstandaard te definiëren.
• Om het voor de opdrachtnemer mogelijk te maken om de vereiste kwaliteit te leveren, zal hij ook condities op laten nemen in de overeenkomst zoals de minimaal benodigde inspanning en doorlooptijd, een acceptatieprocedure en een wijzigingsprocedure.
• Wijzigingsvoorstellen met impact op de op te leveren producten, de eisen of de randvoorwaarden, zijn in feite aanpassingen van de overeenkomst, waarover beslist moet worden op basis van consensus tussen opdrachtgever en opdrachtnemer.

In de praktijk zien we, dat een aantal van deze zaken in het plan van aanpak pas geregeld wordt. Dit is uiteraard toegestaan, mits dit in de overeenkomst wordt beschreven en er consensus bereikt kan worden over het plan van aanpak tussen de opdrachtgever en opdrachtnemer. Voor zover er beslissingen genomen moeten worden, die niet in de overeenkomst zijn vastgelegd, bepaalt de opdrachtgever binnen de ruimte die de overeenkomst biedt. De gebruikersprojectleider (GPL) is leading en hij is verantwoordelijk voor het realiseren van het projectresultaat binnen de gestelde randvoorwaarden. Het opstellen en bewaken van het projectplan en de planning kan de GPL delegeren, maar de verantwoordelijkheid ligt bij de GPL.    

• Afwijking van de opdracht of het projectplan door de IT-medewerkers wordt gerapporteerd aan de gebruikersprojectleider en de opdrachtnemer. Als de gebruikersprojectleider het probleem kan oplossen binnen de randvoorwaarden van de opdracht, dan beslist deze. Anders zal er een wijzigingsvoorstel of probleemrapport ingediend moeten worden, waarover opdrachtgever en opdrachtnemer beslissen.
• Voorts verifieert de GPL of de aan hem opgeleverde producten voldoen aan de in de opdracht gestelde eisen en de gegeven specificaties (dit kan leiden tot het indienen van een probleemrapport) en of het product inderdaad voldoet aan de behoefte van de gebruikersorganisatie (dit kan leiden tot het indienen van een wijzigingsvoorstel). Deze laatste beoordeling vindt plaats door de acceptatiegroep, die buiten het project is geplaatst (zie hoofdstuk 4).
• Hierna kan de formele oplevering van mijlpaalproducten aan de opdrachtgever plaatsvinden. Acceptatie door de opdrachtgever kan niet gedelegeerd worden naar de gebruikersprojectleider.

De PL-IT is verantwoordelijk voor de productkwaliteit. Daartoe draagt hij zorg voor een projectinterne kwaliteitscontrole door de IT-medewerkers, om te beoordelen of de intern opgeleverde producten voldoen aan de in de opdracht gestelde eisen en de gegeven specificaties. Indien dit niet het geval is, draagt hij zorg voor herstel of kan hij een wijzigingsvoorstel indienen.    

• Na een eventuele onafhankelijke audit levert de PL-IT de producten op aan de GPL ter beoordeling.
• Voorts draagt de PL-IT zorg voor een controle op de door de gebruikers opgeleverde specificaties (o.a. consistentie, volledigheid, binnen de verstrekte opdracht). Bij tekortkomingen wordt een probleemrapport ingediend bij de GPL.
• De PL-IT is verder verantwoordelijk voor de urenverantwoording van de IT-medewerkers en de rapportage van (toekomstige) afwijkingen op het plan. Een kopie hiervan wordt verstrekt aan de opdrachtnemer.
• Omdat de opdrachtnemer verantwoordelijk is voor de productkwaliteit, zullen standaard door hem productaudits worden uitgevoerd op essentiële mijlpaalproducten. Formeel is de opdrachtnemer verantwoordelijk voor de oplevering van de mijlpaalproducten aan de opdrachtgever. In de praktijk wordt dit gedelegeerd. Voorts overlegt de opdrachtnemer met de opdrachtgever over alle wijzigingsvoorstellen en probleemrapporten, die aanpassing van de overeenkomst noodzakelijk maken.

Dit opdrachttype is gewenst in alle fasen waarin de gebruikersorganisatie het resultaat vooraf maar beperkt kan of wil specificeren, terwijl keuzes van de gebruikersorganisatie tijdens het traject nog in belangrijke mate bepalend zijn voor de inhoud van het eindresultaat. Wel moet het mogelijk zijn om productbeschrijvingen te geven.     

 4. Opdrachttype 3

Bij Opdrachttype 3 zijnverantwoordelijkheden, bevoegdheden en risico’s verdeeld, maar ze liggen voor het grootste deel aan de kant van de opdrachtnemer.    

Figuur5: Opdrachttype 3

De opdrachtnemer is projectverantwoordelijk, d.w.z. verantwoordelijk voor zowel de kwaliteit van het op te leveren product binnen de randvoorwaarden, als voor de kwaliteit van het proces. De inspanning van medewerkers van de opdrachtnemer wordt vergoed op basis van nacalculatie. In de overeenkomst wordt dan ook minimaal beschreven welke producten opgeleverd worden en aan welke eisen deze producten moeten voldoen (meestal via een verwijzing naar een uitgangsproduct samen met standaards of een handboek). Ook worden de producten incl. eisen en randvoorwaarden gedefinieerd, die de GPL aan de PL-IT dient op te leveren. De opdrachtgever stelt de randvoorwaarden zoals de maximale inspanning en doorlooptijd.   

Wijzigingsvoorstellen met impact voor de op te leveren producten, de eisen of de randvoorwaarden, zijn in feite aanpassingen van de overeenkomst, waarover beslist moet worden op basis van consensus tussen opdrachtgever en opdrachtnemer. In de praktijk zien we, dat een aantal van deze zaken in het plan van aanpak pas geregeld wordt. Dit is uiteraard toegestaan, mits dit in de overeenkomst wordt beschreven en er consensus bereikt kan worden over het plan van aanpak tussen de opdrachtgever en opdrachtnemer. Omdat de opdrachtnemer verantwoordelijk is voor de product- en de proceskwaliteit, heeft deze de bevoegdheid om zijn methode voor projectbeheersing als projectstandaard te definiëren. Voorts zullen standaard door hem de volgende audits worden uitgevoerd:    

• Voorafgaand aan de daadwerkelijke projectuitvoering zal een productaudit op het uitgangsmateriaal plaatsvinden en wordt er een projectdiagnose uitgevoerd. Op basis van deze bevindingen kunnen extra maatregelen of activiteiten in de overeenkomst gedefinieerd worden. Voorts wordt beoordeeld of de door de opdrachtgever gedefinieerde randvoorwaarden haalbaar zijn.
• Tijdens het traject zullen product- en projectmanagement-audits worden uitgevoerd.

Voor zover er beslissingen genomen moeten worden over zaken die niet in de overeenkomst zijn geregeld, bepaalt de opdrachtnemer binnen de ruimte die de overeenkomst biedt. Wel heeft de opdrachtgever te allen tijde het recht om wijzigingsvoorstellen te doen.
De PL-IT is leading en de projectopdracht met bijbehorende randvoorwaarden is dan ook taakstellend voor hem.    

• De PL-IT is dus verantwoordelijk voor de productkwaliteit. Daartoe draagt hij zorg voor een projectinterne kwaliteitscontrole door de IT-medewerkers om te beoordelen of de intern opgeleverde producten voldoen aan de in de opdracht gestelde eisen en de gegeven specificaties. Indien dit niet het geval is, draagt hij zorg voor herstel of kan hij een wijzigingsvoorstel indienen.
• Na een eventuele audit levert de PL-IT de producten ter beoordeling op aan de GPL, die op basis hiervan bij ‘niet akkoord’ een probleemrapport oplevert aan de PL-IT. Indien dit probleemrapport niet gehonoreerd wordt, vindt rapportage plaats aan opdrachtgever en opdrachtnemer.
• Voorts draagt de PL-IT zorg voor een controle op de door de gebruikers opgeleverde specs (o.a. consistentie, volledigheid, binnen de verstrekte opdracht). Bij tekortkomingen wordt een probleemrapport ingediend.
• Daarnaast is de PL-IT is verantwoordelijk voor het projectmanagement. Daartoe worden aan hem de urenverantwoording en de rapportage van (toekomstige) afwijkingen op het plan verstrekt.
• Als de PL-IT gerapporteerde problemen kan oplossen binnen de ruimte van de opdracht, dan beslist de PL-IT. Indien dit niet mogelijk is, zal er een probleemrapport of wijzigingsvoorstel ingediend moeten worden, waarover opdrachtgever en opdrachtnemer beslissen.

De gebruikersprojectleider (GPL) is verantwoordelijk voor de kwaliteit van de door de gebruikers uit te voeren activiteiten en op te leveren producten.    

• Voorts verifieert de GPL of de door de PL-IT aan hem opgeleverde producten voldoen aan de in de opdracht gestelde eisen en de gegeven specificaties (dit kan leiden tot het indienen van een probleemrapport) en of het product inderdaad voldoet aan de behoefte van de gebruikersorganisatie (dit kan leiden tot het indienen van een wijzigingsvoorstel). Deze laatste beoordeling vindt plaats door de acceptatiegroep, die buiten het project is geplaatst.
• Hierna kan de formele oplevering van mijlpaalproducten aan de opdrachtgever plaatsvinden. Acceptatie door de opdrachtgever kan niet gedelegeerd worden naar de gebruikersprojectleider.
• Voorts is de GLP verantwoordelijk voor de rapportage van voortgang en afwijkingen aan de PL-IT.

Dit opdrachttype is gewenst in alle fasen, waarin het resultaat vooraf nog maar beperkt is gespecificeerd, maar waarbij keuzes met een belangrijke impact voor de gebruikersorganisatie reeds genomen zijn.    

 5. Opdrachttype 4

Bij Opdrachttype 4 liggen verantwoordelijkheden, bevoegdheden en risico’s nagenoeg volledig aan de kant van de opdrachtnemer. Het bekendste voorbeeld hiervan is de fixed-price/fixed-date constructie.    

Figuur6: Opdrachttype 4

Dit opdrachttype komt m.b.t. de procedures sterk overeen met type drie, maar het verschil zit vooral in de overeenkomst.    

• De opdrachtnemer is nu ook budgetverantwoordelijk, d.w.z. het overeengekomen product, dat voldoet aan de gestelde eisen, wordt binnen de gestelde randvoorwaarden opgeleverd. Overschrijdingen van de begroting zijn voor rekening van de opdrachtnemer. Overschrijding van de fixed date wordt via een boete-clausule geregeld.
• De inspanning van medewerkers van de opdrachtnemer wordt dus vergoed op basis een vooraf vastgestelde prijs.
• Eventueel meerwerk n.a.v. wijzigingsvoorstellen wordt uitgevoerd op basis van nacalculatie en valt ook niet onder de fixed date.
• Als er beslissingen genomen moeten worden over zaken die niet in de overeenkomst zijn geregeld, bepaalt de opdrachtnemer.
• Wel heeft de opdrachtgever te allen tijde het recht om wijzigingsvoorstellen te doen.

Belangrijkste afwijkingen van de beschrijving van opdrachttype 3 zijn:    

• Het is nu niet mogelijk om onderdelen van de overeenkomst via het projectplan alsnog te regelen.
• Het aantal op te leveren producten blijft meestal beperkt tot het eindproduct met de bijbehorende documentatie.
• De oplevering van producten vindt plaats door de opdrachtnemer aan de opdrachtgever, die een vooraf vastgestelde periode krijgt om het product te accepteren. Geconstateerde afwijkingen van de overeenkomst leiden tot probleemrapporten aan de opdrachtnemer, die binnen de randvoorwaarden van het project opgelost dienen te worden. Alle andere gewenste afwijkingen leiden tot wijzigingsvoorstellen, die als meerwerk buiten de randvoorwaarden van de overeenkomst worden uitgevoerd.
• Probleemrapporten van de PL-IT m.b.t. afwijkingen van overeengekomen gebruikersinspanningen dienen door de GPL te worden opgelost of anders door de opdrachtgever als wijzigingsvoorstel te worden ingebracht.

Dit opdrachttype is gewenst in alle fasen waarin het resultaat vooraf volledig gespecificeerd is.
In de situatie waarin de IT-organisatie niet een zelfstandige organisatie of ‘profit centre’ is, zal type 4 niet of nauwelijks toegepast kunnen worden met de IT-organisatie als opdrachtnemer.    

 6.  Aandachtspunten bij de opdrachttypes

In dit hoofdstuk worden een aantal aandachtspunten en problemen uit de praktijk genoemd en de wijze waarop hiermee omgegaan kan worden.    

6.1 Algemeen

• In projecten is vaak sprake van een derde partij. Deze kan zowel ingeschakeld worden door de opdrachtgever als de opdrachtnemer. Omdat de andere partij gevrijwaard dient te worden van de gevolgen van het inschakelen van derden, moet dit beschouwd worden als een totaal nieuwe overeenkomst tussen de initiatiefnemer en de derde partij, die op zich weer volgens een opdrachttype afgesloten wordt.
• De wijzigingsprocedure moet zodanig zijn opgezet, dat de besluitvorming over belangrijke wijzigingsvoorstellen buiten het project plaatsvindt. Op deze manier hoeven er geen belangenvertegenwoordigers in het project plaats te nemen en hoeft er ook geen discussie of zelfs strijd gevoerd te worden over het waarom van het project. Men kan zich blijven richten op het realiseren van het resultaat binnen de randvoorwaarden, hetgeen de kwaliteit en de productiviteit in belangrijke mate bevordert.

6.2 Opdrachttype 1

• Type 1 leent zich uitstekend voor een budget-driven aanpak, d.w.z. het budget is een gegeven en het project is erop gericht om hierbinnen een zo optimaal mogelijk resultaat te verkrijgen. Het heeft als groot voordeel boven type 4, dat opslagpercentages voor risico’s en overhead van de IT-organisatie niet betaald hoeven te worden.
• Een groot probleem bij een budget-driven aanpak op basis van type 1 zijn de bijzonder hoge eisen (zowel inhoudelijk als procesmatig) die aan de GPL gesteld worden. Voorts zal de opdrachtgever zeer nauw betrokken moeten blijven bij het project om keuzes te maken en prioriteiten aan te geven.
• Een belangrijk nadeel van type 1 projecten is het ontbreken van een gedeelde verantwoordelijkheid. Daarom zullen voor type 1 projecten IT-medewerkers ingezet moeten worden, die meer zijn dan “domme” uitvoerders.
• Omdat de overeenkomst tussen opdrachtgever en opdrachtnemer geen bepalingen bevat over het projectresultaat en de randvoorwaarden, zullen deze in het door de GPL op te leveren projectplan nadrukkelijk omschreven moeten worden.
• Omdat de opdrachtgever nu zelf verantwoordelijk is voor de productkwaliteit en deze niet automatisch ook wordt bewaakt door de IT-organisatie, is het van belang, dat er parallel aan het projectplan een kwaliteitsplan wordt opgesteld, waarin dit geregeld is.
• Omdat de opdrachtnemer niet verantwoordelijk is voor de product- en projectkwaliteit en het dus onnodig is om zijn standaards in het project te hanteren, zal de gebruikersorganisatie zelf standaards m.b.t. tot productontwikkeling en projectmanagement ter beschikking moeten hebben, die als projectstandaard gebruikt kunnen worden en waarop men ingespeeld is.
• Als in een project van type 1 of 2 een GPL wordt ingehuurd op basis van detachering, dan is er in feite binnen de projectorganisatie niemand meer verantwoordelijk voor het opleveren van het projectresultaat binnen de gestelde voorwaarden. Daarom zal het inhuren van een GPL op basis van type 3 moeten plaatsvinden.

6.3 Opdrachttype 2

• Het is van groot belang, dat de kwaliteitsdefinitie ook door de IT-medewerkers goed gehanteerd wordt. Dus niet in de geest van “hoogste kwaliteit”, maar in de geest van vastgelegde en vanzelfsprekende behoeftes.
• De opdrachtgever kan geen rechten ontlenen aan de door de opdrachtnemer afgegeven schattingen over de minimaal benodigde inspanning en doorlooptijd, aangezien deze gebaseerd zijn op een inschatting van de werkzaamheden van de IT-medewerkers en niet van het totale project. Als de opdrachtgever dit wel wil, dient hij te kiezen voor minimaal type 3.
• Omdat de overeenkomst tussen opdrachtgever en opdrachtnemer geen bepalingen bevat over de randvoorwaarden van de opdrachtgever m.b.t. het projectresultaat, zal dit in het door de GPL op te leveren projectplan nadrukkelijk omschreven moeten worden.
• Vaak blijkt in de loop van het project, dat de hoeveelheid wensen groter is dan oorspronkelijk was ingeschat. Om te voorkomen, dat hierdoor de productkwaliteit in gevaar komt, zal de wijzigingsprocedure absoluut gehanteerd moeten worden. Dit heeft als extra voordeel, dat ook de opdrachtgever niet plotseling voor negatieve verrassingen komt te staan.
• Omdat de opdrachtnemer niet verantwoordelijk is voor de projectkwaliteit en het dus onnodig is om zijn standaards in het project te hanteren, zal de gebruikersorganisatie zelf standaards m.b.t. projectmanagement ter beschikking moeten hebben, die als projectstandaard gebruikt kunnen worden en waarop men ingespeeld is.

6.4 Opdrachttype 3

Dit projecttype draagt een lange historie met zich mee. Zeker in de periode waarin informatici nog vanuit hun ivoren toren werkten, hadden ze dezelfde bevoegdheden, maar droegen geen verantwoordelijkheden of risico’s. Hier komen we dan ook direct bij het grote probleem van dit opdrachttype, aangezien de opdrachtnemer geen budgetverantwoordelijkheid draagt en er dus formeel geen sprake kan zijn van boeteregelingen.
De oplossing van dit probleem is gelegen in het feit, dat de samenwerking dermate hecht is, dat bij problemen een voor beide partijen bevredigende oplossing gevonden wordt. Uiteraard is hiervoor een “drukmiddel” beschikbaar, waarbij we echter onderscheid moeten maken tussen de situatie met een externe opdrachtnemer en de situatie met een interne opdrachtnemer.    

In het geval van een externe opdrachtnemer zijn er twee drukmiddelen:    

• Het ontbinden van de overeenkomst door de opdrachtgever wegens wanprestatie en het zoeken van een nieuwe leverancier.
• Het inschakelen van de branche-organisatie indien de opdrachtnemer hierbij aangesloten is.

Bij een interne opdrachtnemer bestaat vaak niet de mogelijkheid om een andere leverancier te zoeken, maar zijn er andere mogelijke drukmiddelen:    

• Het gemeenschappelijk bedrijfsbelang, waaraan beide partijen een bijdrage moeten leveren.
• Het inschakelen van een hoger echelon om knopen door te hakken met als gevolg, dat minimaal één partij belangrijk gezichtsverlies lijdt.

Verdere aandachtspunten bij opdrachttype 3 zijn:    

• Omdat het resultaat vaak maar beperkt omschreven is en het initiatief bij de IT-medewerkers ligt en er meestal volgens de door hen ingebrachte standaards wordt gewerkt, worden gebruikers veelal ondergesneeuwd. Enkele belangrijke maatregelen kunnen zijn:
  • het in de opdracht definiëren van een hoeveelheid ruimte voor nieuwe specificaties; slechts bij overschrijding van deze ruimte geldt de wijzigingsprocedure;
  • het aanstellen van een IT-medewerker als begeleider van de gebruikersgeleding in het project; deze kan als staffunctionaris direct onder de GPL geplaatst worden;
  • een goede set van standaards die de gebruikersorganisatie zelfbeschikbaar heeft, en die als basis voor de projectstandaard gebruikt wordt.
• Ook komt het regelmatig voor, dat er in feite geen bestaande gebruikersorganisatie bestaat. Dit is o.m. het geval bij pakket- of productontwikkeling bestemd voor extern gebruik door nog (deels) onbekende afnemers. In dat geval is het van het grootste belang, dat er toch een opdrachtgever aangewezen wordt (in een systeemhuis b.v. een commercieel manager), die ervoor zorg draagt, dat de “gebruikerskant” van het project wordt ingevuld met een GPL (vaak een commercieel medewerker) en materiedeskundigen.

6.5 Opdrachttype 4

Tegenwoordig zien we een sterke toename van het aantal type 4 projecten. Dit komt m.n. voort uit de behoefte om de kosten te beheersen of om een deadline te halen. Vaak blijkt pas achteraf, dat men onvoldoende waar voor zijn geld heeft gekregen of dat de kosten via noodzakelijk meerwerk nog volledig uit de hand zijn gelopen. De oorzaak hiervan is meestal, dat de opdrachtgever een contract heeft afgesloten met de opdrachtnemer, zonder dat de opdrachtgever een exacte beschrijving van het resultaat kon geven. Als het resultaat niet van te voren nauwkeurig is gedefinieerd, dan koopt de opdrachtgever in feite alleen maar een aantal uren en niet een product dat getoetst kan worden op zijn kwaliteit. De opdrachtnemer heeft dan alle bevoegdheden, terwijl daar geen meetbare verplichtingen tegenover staan. Als het resultaat nog niet volledig gedefinieerd is, kan dus beter gekozen worden voor een budget-driven aanpak op basis van een ander opdrachttype.    

Enkele aandachtspunten:    

• Een fixed price/fixed date contract zonder boete-clausule op overschrijding van de fixed date staat gelijk aan uitsluitend een fixed price project.
• Omdat verkorting van de doorlooptijd een belangrijke kostenverhogende factor is, zal de opdrachtgever zorgvuldig moeten overwegen of het gehele projectresultaat wel noodzakelijk op de fixed date opgeleverd moet worden of slechts maar een deel. In dat geval kan voor het overige deel een tweede fixed date worden afgesproken.
• Een belangrijk nadeel van type 4 projecten is het ontbreken van een gedeelde verantwoordelijkheid. Dit kan leiden tot de ontwikkeling van de ’schitterende oplossing voor het verkeerde probleem’. Dit kan alleen voorkomen worden door uitsluitend type 4 te gebruiken voor trajecten waarbij alle keuzes die de gebruikersorganisatie moet maken, ook inderdaad gemaakt zijn.

Het gebruik van opdrachttypen kan gecombineerd worden met allerlei methodieken voor projectmanagement, mits opdrachtgever en opdrachtnemer allebei bereid zijn verantwoordelijkheid te nemen. In een opleidingssessie aan de betrokkenen kan de werkwijze eenvoudig ingevoerd worden, per project of organisatiebreed. (Zie ook ‘Groepstraining on the job: integratie functioneel en technisch beheer en applicatiebeheer’.) In projecten is het niet anders dan in de politiek: de bereidheid tot samenwerken, met een duidelijke verdeling van verantwoordelijkheden en bevoegdheden, is een absolute voorwaarde voor succes. 

Herziene versie: 29 maart 2010

Download:         

Gerelateerde artikelen:

1. Projectinrichting en opdrachtbeheer
2. Waarom veel organisaties niet met projecten kunnen omgaan
3. Bij projectmatig werken zijn afspraken beter dan procedures