Projectorganisatie

Projectorganisatie

Een organisatievorm dat essentieel is voor een project. Het uitgangspunt voor deze organisatievorm is de lijn- of de lijn-staforganisatie. Als de projectleider alle bevoegdheden heeft die noodzakelijk zijn om de projecten te beheersen, is er sprake van een theoretisch zuivere projectorganisatie.

Dened projectbeheersing

De structuur in bovenstaand figuur zie je vaak bij grote investerings- en/ of productieprojecten. De projectmanager is dan verantwoordelijk voor het resultaat van het project. Zowel technisch als financieel. De stuurgroep is eigenaar/ opdrachtgever.

Bij een aannemer en software ontwikkelaar zien we meestal een matrixorganisatie. Deze inrichting wordt vaak gekozen omdat er meerdere projecten tegelijk lopen en de vakspecialisten van de verschillende afdelingen op de projecten kunnen worden ingezet.

Dened projectbeheersing

Projectteam

Bovenstaande structuren zijn zo goed als de mensen die er deel in hebben. Een projectmanager heeft een team om zich heen nodig om de opdracht die hij heeft gekregen van de stuurgroep tot een goed einde te brengen. Uiteraard wil het projectteam dit het liefst doen binnen de tijd die daarvoor gegeven is en met het geld dat hij ervoor heeft gekregen. De projectleider en het projectteam willen daarbij de gevraagde kwaliteit niet uit het oog verliezen.

Belbin

Om de juiste mensen voor een project te selecteren kan er worden ingestoken vanuit de Belbin gedachte. Voorop staat het idee dat een team samengesteld moet worden vanuit de intrinsieke kwaliteiten van de teamleden. Belbin heeft daarin 9 teamrollen onderscheiden:

  1. Bedrijfsman
  2. Brononderzoeker
  3. De plant
  4. De monitor
  5. De vormer
  6. De voorzitter
  7. De zorgdrager
  8. De groepswerker
  9. De specialist

Bovenstaande rollen zijn niet de benamingen van de functies die ze bekleden. Dit zijn de “karakters” van de personen. De intrinsieke kwaliteiten. Zoals beknopt weergegeven in onderstaand figuur:

belbin-taart

Hoewel het een interessante theorie is, zullen weinig organisaties de luxe hebben om een team samen te stellen op deze karaktereigenschappen. Over het algemeen zullen de mensen met de benodigde technische kennis worden vrijgemaakt. Zoals bijvoorbeeld (bij een productie proces) een inkoper voor de vorming van raamcontracten, een engineer voor de technische inhoud, een hoofd productie voor de montage of projectleiders voor deelprojecten, enz.

In een matrix organisatie zullen de vrije mensen van de afdeling of, afhankelijk van de beoogde of gewenste kwaliteit, de hoger gekwalificeerde personen aan het project worden toegewezen.

Het is echter wel zeer belangrijk dat een projectmanager van zijn team op aan kan. Hij moet er vanuit kunnen gaan maar er ook voor zorgen dat de projectteamleden open en eerlijk kunnen zijn. Dit is niet alleen voor de werksfeer belangrijk maar ook voor het constateren van het werk dat buiten de scope valt. Binnen een projectteam moet men zich veilig voelen om andere teamleden aan te spreken op het werk dat is gedaan of gedaan moet worden. Engineers en werkvoorbereiders zijn net als de uitvoerende monteurs, vaak overijverig in het vinden van oplossingen. Soms ook van problemen die er nog niet zijn. Ook is de dienstbaarheid naar de klant toe zeer aanwezig. Dit is op zich een mooie eigenschap maar kan ook een sluipmoordenaar voor de projecten zijn. Het gevaar bestaat dat hierdoor werk wordt gedaan wat niet in de scope zit en onbetaald blijft.

Bezuinigen op winst

Een veel voorkomende valkuil bij aannemers is dat er vaak binnen een project wordt bezuinigd op de verkeerde zaken. Dit wordt gedreven door het zo laag mogelijk inschrijven op een project om zo het project te “scoren”. Door zo “scherp” mogelijk in te schrijven worden de marges dunner.

De zaken die over het algemeen als eerste in de prijs worden aangepast zijn de winstmarge en/ of de risico reserves. Soms zelfs wordt, als men het werk echt hard nodig heeft, in sommige gevallen het project, deels of geheel, zonder dekking voor de algemene kosten (AK) verkocht. Door het verlagen van de marges is het een uitdaging om het project positief af te sluiten. Door het niet berekenen van de AK dekking bij verkoop, zal het project zeker een negatief financieel resultaat hebben. Mijn ervaring is dat de financieel administratieve inrichting doorgaans niet wordt aangepast en zal de AK dekking wel worden doorbelast op het project. Hierdoor zal de projectmanager geconfronteerd worden met meer kosten dan hij in zijn werkbegroting heeft gekregen.

Mechanismen

Als de projecten groter en complexer worden is er meer behoefte aan control. De project controller zal samen met de projectmanager zorgen voor het geheel aan control. Op specifieke terreinen is soms extra control gewenst. Hierbij valt te denken aan contract- en document control. Ook de werkvoorbereider kan een prominente rol spelen binnen deelprocessen.

Uit interviews en uit eigen ervaring bestaat de indruk dat er vooral in de aannemerij, het eerst wordt bezuinigd op het projectmanagement. Projectmanagement bestaat uit meer dan alleen de projectmanager en zijn systeem. Zoals eerder gemeld zijn dat onder andere de werkvoorbereider, de uitvoerder, planner en een documentcontroller. Niet ieder project heeft altijd behoefte aan al deze functies. Men moet goed kijken waar de risico’s binnen de scope bewaking liggen en hierop het projectmanagement afstemmen.

Werkvoorbereider

De functie van werkvoorbereider is over het algemeen die van regelaar tussen uitvoering en planning. De werkvoorbereider zorgt onder andere voor de tekeningen en de dossiervorming hiervan. Ook een belangrijke taak is het voorbereiden van de montage. Dit gebeurt met werkomschrijvingen en tekeningen. Voordat de monteurs aan het werk kunnen zal hij er ook voor moeten zorgen dat het materiaal en eventueel materieel voorhanden is. Ook loopt in veel gevallen het prijzen van de aangevraagde meerwerken langs een werkvoorbereider. De control mechanismen die binnen deze functie liggen zijn niet gering.

  • juistheid, volledigheid en tijdigheid van de benodigde tekeningen;
  • signaalfunctie op het beschikbaar materiaal budget;
  • validatie van de planning i.v.m. de inzetbaarheid van de monteurs;
  • meer-, minderwerk registratie of signalering.

Uitvoerder

De uitvoerder bespreekt, aan de hand van de opdrachtspecificaties in het projectplan de benodigde capaciteit, materiaal en gereedschappen. De uitvoerder is de link van het management naar de werkvloer en geeft leiding aan de monteurs. De uitvoerder houdt de voortgang, efficiency, resultaat, richtlijnen, instructies en normen in de gaten. Een niet onbelangrijk onderdeel van deze functie is het melden en motiveren van wijzigingen en meer-, minderwerk, en de registratie van wijzigingen van tekeningen/ specificaties. Vaak is de uitvoerder ook het eerste aanspreekpunt voor een directievoerder/ opdrachtgever

In principe heeft deze functie de eerste control functie van de werkvloer. Zowel naar als van de werkvloer.

  • planning en capaciteit;
  • kwaliteit van het werk;
  • meer- minderwerk signalering;
  • klant contact op uitvoeringsniveau.

Document controller

Bij grote en complexe projecten is het verstandig om een document controller in te zetten. Deze functionaris zorgt voor de juistheid van alle opgeleverde documenten van de uitvoerders/ aannemers en de status van alle afnamen, documenten van inspectie in relatie tot het project. En hij beheert deze documenten. Ook ziet hij er op toe dat de kwaliteitseisen en de diverse werkwijzen besproken zijn met de opdrachtgever. Daarnaast zal hij het centrale aanspreekpunt zijn voor de opdrachtgever met betrekking tot de oplevering, de zogenaamde punchlijsten, afwikkeling documentatie en de kwaliteit-, inspectie-, en milieucontroles. De document controller zal afwijkingen in het project opmerken en als zodanig rapporteren aan de projectmanager.

Als deze functie goed wordt uitgevoerd zal hier een grote winst te behalen zijn ten aanzien van het beperken van ongewenst werk of claims door onduidelijkheden. Het is een belangrijke functie in het voorkomen van een scopecreep. Deze functie is ook uit te voeren in combinatie met contract control.

Zoals gezegd zal niet ieder project een zwaar projectmanagement nodig hebben. Dit hangt af van de grootte en complexiteit van het werk en de contractpartners. Van belang is dat de projectmanager zo vroeg mogelijk in het proces een idee krijgt van de complexiteit van het project. Zo kan hij op tijd aangeven wat zijn voorwaarden zijn voor de beheersing van het project. Samen met de projectcontroller kan er dan worden nagedacht over de control mechanismen en proces inrichting. De control zal moeten worden aangepast aan de specifieke eigenschappen van het project.

Projectcontroller

De projectcontroller zal in dit proces kunnen bepalen wat de meest ideale en praktische inrichting voor de financiële administratie zal zijn. Ook mag het proces niet het reguliere control proces van de organisatie verstoren. Het zal het voor de projectcontroller duidelijk worden waar de knelpunten en risico’s in het project zullen zitten. De knelpunten kunnen op veel vlakken liggen zoals bijvoorbeeld de planning (is deze realistisch), omgeving (wie zijn stake- en shareholders). Op veel van deze punten kan de projectcontroller de projectmanager zeer van dienst zijn. De kwaliteit van een projectcontroller zit in het kunnen overzien van het gehele proces van het project. Tegelijk heeft de projectcontroller zijn verantwoordelijkheid naar de lijn organisatie. Hij is immers verantwoordelijk voor de betrouwbaarheid van de financiële prognose. Hierdoor is de onafhankelijkheid en kritische houding van de projectcontroller geborgd.

projectbeheersing

projectbeheersing

Projectbeheersing of projectcontrol?

projectbeheersing

Inhoud van een businesscase

Investeringsprojecten

Een businesscase van een investeringsproject is binnen het projectmanagement een document waarin de zakelijke afweging om een project of taak te beginnen beschreven wordt. Het maakt het ‘onderbuikgevoel’ wat concreter. In de businesscase worden niet alleen de kosten tegen de baten afgewogen maar ook bijvoorbeeld de aansluiting op de eventueel strategische doelstellingen van een organisatie. En welke problemen er worden opgelost. Vaak wordt aan de hand van de businesscase besloten om wel of niet te starten en/ of verder te gaan met een project. Ook wordt er beschreven wie de opdrachtgever en de opdrachtnemer is.

Herstructurering en vastgoedprojecten

Een voorbeeld van de fasering en processtappen voor investeringsprojecten:

Proces fasering

De businesscase wordt tijdens de projectverkenning al wat concreter door de doelstellingen en eventuele opdrachtomschrijving te concretiseren. De businesscase krijgt hiermee vorm en zal bij voldoende draagvlak tijdens de haalbaarheids- en voorbereidingsfase vaste vorm krijgen. Hiermee is met het definitief ontwerp, zie figuur 1, ook de scope van het werk, waar de opdrachtnemer op inschrijft, bepaald.

Beslismomenten

Tussen de verschillende processtappen zijn er beslismomenten of het project wel of geen doorgang gaat vinden. Deze beslissing wordt doorgaans gedaan door een directeur en/ of stuurgroep. Per fase worden er resultaten gevraagd van de projectmanager. Hieronder staan enkele voorbeelden van documenten die per fase gevraagd kunnen worden:

  •   Initiatieffase
    – doelstelling project;
    – ontwikkeling visie;
    – markt visie;
    – voorstel projectteam.
  •  Haalbaarheidsfase
    – grondexploitatie (GREX);
    – risico analyse;
    – PvE en structuurontwerp;
    – voorstel aanbestedingsvorm;
    – globale planning.
  • Voorbereidingsfase
    – inventarisatie vergunningen;
    – selectie en contracteren architect;
    – definitief ontwerp en programma;
    – kostencalculatie en prijsstelling;
    – contractstukken, bestek en tekeningen;
    – financiering en subsidies.
  • Uitvoeringsfase
    – contracten aannemer;
    – voortgangsrapportage;
    – meer-, minderwerk overzicht;
    – financiële afrekening;
    – evaluatie.
  • Beheerfase
    – dossierafronding.

Ook is het gebruikelijk dat voor iedere fase een budget wordt aangevraagd, afgegeven, bewaakt en afgerekend middels een decharge.
De scope van het werk krijgt in de projectverkenning (initiatieffase) tot en met het definitief ontwerp (voorbereidingsfase) steeds concreter vorm. In de aanbestedingsfase wordt de scope verdeeld naar het technische gedeelte voor één of meer opdrachtnemers, aannemers. Deze scope is kleiner en voor het grotere geheel minder van belang dan voor de opdrachtgever. Die heeft voor het totaal van het programma een strategisch doel voor ogen.

Aannemerij

In een businesscase bij de aannemerij zie je dat deze voornamelijk bestaat uit een technische afweging en een financiële afweging.

  1. Is het technisch mogelijk om dit project te realiseren?
  2. Is het financiële rendement voldoende?

Indien de aannemer de technische mogelijkheden zelf niet in huis heeft kan hij besluiten om onderaannemers aan te nemen om zo toch het project te kunnen uitvoeren.
Hieronder een voorbeeld van het proces van een aannemer:

proces aannemer

Binnen dit proces wordt in de “verwerven opdracht” de scope bepaald. Als eerste wordt de offerte-aanvraag behandeld, geëngineerd, gecalculeerd en een offerte uitgebracht. In de offerte worden de aannames en uitsluitingen van het werk weergegeven. Het komt hierdoor ook regelmatig voor dat er in de aannemerij niet geheel volgens scope wordt gewerkt. Bij de uitvoering van het werk kan het zijn dat de klant de uitsluitingen niet in het vizier heeft, of stellig beweert dat het “extra werk” wel degelijk in de scope zit. Om de relatie goed te houden zal de aannemer in veel gevallen besluiten het extra werk niet, door middel van meerwerken, te verrekenen.

projectbeheersing

projectbeheersing

Projectbeheersing is…

projectbeheersing

Netwerken

Niet zo lang geleden besloot ik om wat meer te netwerken, contact houden met oude opdrachtgevers en via hen misschien wat nieuwe binnen te halen.  Mijn eerste afspraak was met een directeur (Cor) van een BAM Techniek vestiging. Eigenlijk is dit meer dan een vestiging, het is een apart bedrijf binnen BAM Techniek.

Nadat ik hem had benaderd om een afspraak te maken, was ik blij verrast dat hij enthousiast reageerde en met een voorstel kwam. Het is toch al wat jaartjes geleden. Bij aankomst voelde het meteen vertrouwd. Ik had er ook een ruime tijd gewerkt en altijd met veel plezier. Als je dan binnen komt en je de bekende gezichten van toen ziet is het altijd fijn dat ze verrast en enthousiast reageren. Cor, die zijn kantoor beneden heeft, hoorde mij praten met de bedrijfsleider en kwam mij halen. Het gesprek met Cor ging eerst over koetjes en kalfjes en ging zo langzaam over de organisatie en de voorbije ontwikkelingen van de jaren die ik er niet meer werk.

Eerst kwamen de personele wisselingen binnen zijn organisatie aan bod ‘heb jij die nog meegemaakt? Ken jij die nog?’ Al snel kwamen we op projectadministratie en projectcontrol. Want ja, dat is waar ik “verstand” van heb. Hij is trots. Hij is trots hoe hij dit onderwerp binnen zijn organisatie heeft geregeld. En hoe belangrijk het is. Hij vertelde mij dat veel collega’s maar ook partners vaak aan hem vragen hoe het binnen zijn organisatie geregeld is. En dat hij dan honderduit verteld hoe belangrijk het is en eigenlijk, hoe simpel.

Hij vertelde hoe de rapportages zijn verbeterd, hoe belangrijk het is om vooruit te kijken i.p.v. achteruit, Hoe de projectmanagers hun rol pakken en ook de overlegstructuur (plenair en individueel) en hoe de verantwoordelijkheid daarbij was ingeregeld. En hij benadrukte de rol van de projectadministrateur (die pakt een klein deel van de projectcontrol rol),  hoe belangrijk die is. Waar hij het meest trots op is, is hoe zij de termijnafspraken met de klant maken. Op datum. Geen gedoe met voortgang zoals; 25% bij start 25% bij montage enzovoort, dus achteraf. Nee. Vaste data en vaste bedragen, van te voren bepaald. Alles met het uitgangspunt dat “het werk” met het geld van de klant wordt gemaakt.

Tijdens dit gesprek heb ik mij ontzettend in moeten houden…. De reden hiervoor was dat hij mij vertelde hoe goed het geregeld was en dat het leek alsof ik er nog wat van kon leren. Begrijp mij niet verkeerd, ik heb er niets tegen om iets van iemand te leren. En ik besef ook heel goed dat 6 jaar en veel wisselingen binnen de administratie een lange tijd is. Zeker als je, zoals Cor al 32 jaar binnen een bedrijf werkt en dus veel veranderingen en personele wisselingen hebt meegemaakt.

Ja, ik kan wel zeggen dat ik er trots op ben dat ik toen iets heb neergezet waar iemand nu nog zo vol passie en trots over praat.

projectbeheersing

projectbeheersing

Projectcontrol en PRINCE2®

Hoe richt je projectcontrol in bij een organisatie, die m.b.t. projectcontrol en projectmanagement niets in de organisatie heeft ingeregeld?

Zo zijn er bij deze organisatie bijvoorbeeld veel conceptplannen en weinig concrete kaders met betrekking tot project management. Dit heeft zijn voordelen maar ook veel nadelen. De voordelen zijn uiteraard dat het allemaal nog kneedbaar is en veel ruimte biedt voor eigen inrichting. De nadelen worden pas zichtbaar als je jezelf de vraag durft te stellen: Waar begin ik en wat zijn mijn kaders?

Het projectmanagement heeft gelukkig wel enige richting gegeven; de PRINCE2® methode wordt gehanteerd. Omdat de Projectcontrol functie niet voorkomt binnen de PRINCE2® methode is er de ruimte om deze naar eigen inzicht goed binnen het proces te plaatsen. Aangezien de projectcontroller zowel de belangen van het project als de belangen van de business moet behartigen is het zinvol de projectcontroller door de afdeling Control of Finance in het project te laten plaatsen. Hierdoor zeker je de onafhankelijkheid van de projectcontroller. De projectcontroller toetst of producten volgens afspraak geleverd worden en processen volgens afspraak verlopen. De projectcontroller is onafhankelijk van de projectmanager en de projectondersteuning. De projectcontroller is wel onderdeel van de projectorganisatie. -Tot zover het abstracte gedeelte-

Bij de vraag ‘waar begin ik?’ kwam al redelijk snel naar voren dat ondanks de bekendheid  met PRINCE2®, het nog erg lastig is om te bepalen wat het belangrijkste proces is binnen PRINCE2® om projectcontrol goed in te richten.

In eerste gedachte gaat uit naar “Controlling a stage”. Dit proces beschrijft namelijk de dagelijkse werkzaamheden van de projectmanager, na goedkeuring door de stuurgroep van de PID (Project Initiatie Document). Ook de doelstellingen van het proces zijn helder:

  • Opleveren van het product zoals overeengekomen;
  • controle houden van de risico’s en de project issues;
  • toezien op de levensvatbaarheid van de businesscase;
  • oplevering van de geplande kwaliteitsstandaarden, kosten en tijd.

Na een tijdje naar de doelstellingen gekeken te hebben lijkt dit toch niet voldoende. Of liever gezegd, niet te doen. We praten dan over autoriseren van werkpakketten, beoordelen van de status van de werkpakketten, het in “ontvangst nemen” van de werkpakketten, verzamelen van de risico’s en issues. En zo nog een paar dagelijkse dingen. Als je als projectcontroller de  hele dag op de schoot van de projectmanager zit ben je eerder een controleur dan een controller. Het is ook niet de bedoeling dat de projectcontroller met de dag dagelijkse zaken van een project bezig is. Onwenselijk dus.

Hoe krijg je als projectcontroller grip en inzicht in een project volgens PRINCE2®? Laten we nogmaals kijken naar de 7 thema’s van PRINCE2®:

  1. Businesscase (de rechtvaardiging van het project)
  2. Organisatie (rollen en verantwoordelijkheden)
  3. Risk (lessons learned)
  4. Kwaliteit (borgen per fase, kwaliteitsverwachting en bedrijfsdoelstellingen)
  5. Wijziging (identificeren, beoordelen en beheersen van evt wijzigingen op vastgestelde producten)
  6. Plannen (geeft duidelijkheid over de te leveren producten)
  7. Voortgang (monitoren, plannen en evalueren behaalde prestaties)

Als het PID is ingediend en de stuurgroep heeft zijn zegen gegeven. Hoe beoordelen we dan of de businesscase en de (financiële) baseline gestand wordt gedaan?

Het ziet er bij nadere beschouwing uit dat het thema “5. wijziging” het wint. Een kleine beschrijving:

Het identificeren, beoordelen en het beheersen van potentiële en goedgekeurde wijzigingen. Dit kan voorkomen voor de overeengekomen parameters van kosten, tijd, kwaliteit, scope, doelstellingen en risico’s.

  • Beoordelen van het effect op de prognose
  • Beoordelen van het effect op de kwaliteit
  • Beoordelen van het effect op de planning
  • Beoordelen van het effect op de scope.

Dit is een belangrijk proces waar de projectcontroller een duidelijke rol in heeft. Het wijzigingsproces is binnen PRINCE2® ondergebracht binnen het Configuration Management Stragegy (CMS). Dit heeft het doel om potentiële en goedgekeurde wijzigingen op de vastgestelde producten te identificeren te beoordelen en te beheersen.

De impact van een wijziging is terug te vinden op de overeengekomen parameters van kosten, tijd, kwaliteit, scope, doelstellingen en risico’s.

De inrichting van het Configuration Management is weliswaar een verantwoordelijkheid van de projectmanager maar dit proces heeft een grote invloed op alle beheersmaatregelen waarbij de projectcontroller bij de inrichting een adviserende, misschien sturende, rol moet hebben. Het belang van de samenwerking tussen de projectcontroller en de projectmanager is terug te vinden in de procedure om wijzigingen af te handelen en zicht te houden op de status van de producten door middel van het configuration management.

De vraag wordt dus beantwoord door PRINCE2®. De methode geeft genoeg opties om te beginnen en ook genoeg kaders. Binnen deze organisatie lag het antwoord in het wijzigingsproces. Uiteraard is dit proces niet het enige proces waar de projectcontroller van afhankelijk is voor een goede beheersing. En ook is het afhankelijk van de grote van het project hoe zwaar dit proces wordt ingericht. Maar buiten de reguliere werkzaamheden en naast de vastgestelde baseline (PID), geeft dit proces binnen PRINCE2® de projectcontroller veel grip en inzicht op de belangrijke pijlers, Geld, Tijd, Kwaliteit en scopebewaking. Tevens heeft de projectcontroller binnen dit proces veel gelegenheid om een goed adviseur en businesspartner te zijn van de projectmanager. En kan het goed de belangen van de business in het oog houden.

Projectcontrol

projectbeheersing

Projectcontrol en Risicomanagement

Een projectrisico is een onzekere gebeurtenis die, als deze plaatsvindt, een positief of negatief effect heeft op de mogelijkheid om de projectdoelstellingen te realiseren”.

De vraag waarom risicomanagement binnen projecten zou moeten worden toegepast wordt vaak gesteld. Er kan worden aangenomen dat risicomanagement bijdraagt aan het beheersen van het project. Hierbij kan gedacht worden aan de volgende aspecten:

  • tijd (planning);
  • geld (raming);
  • kwaliteit;
  • informatie;
  • organisatie.

De bijdrage moet vooral gezocht worden in het feit dat er vooraf over deze aspecten wordt nagedacht. – Welke mogelijke situaties kunnen zich in de toekomst voordoen die een effect kunnen hebben op het project. Welke acties kunnen er vooraf genomen worden ter voorkoming of vermindering van deze ongewenste situaties of gebeurtenissen. –
Om de voortgang van een project in een continue proces te optimaliseren kan er gebruik worden gemaakt van risicomanagement. Het nemen van maatregelen ter voorkoming van elementen die dit proces zouden kunnen verstoren kan een grote bijdrage aan een project leveren.
Niet onbelangrijk is dat het door middel van een goed vooraf opgezette risico analyse, risicomanagement kan helpen bij het vertrouwen in het project. Zowel voor de projectteamleden als bij de omgeving. De voorspelbaarheid en bespreekbaarheid van de projectrisico’s en de controle erop kunnen leiden tot minder stress bij projectteamleden.
Aangenomen kan worden dat risicomanagement, zeker bij grote en kapitaalintensieve, projecten een zeer belangrijk deel is binnen de projectbeheersing. Toch komt het voor dat niet altijd risicomanagement wordt toegepast.
Daarvoor kunnen verschillende redenen zijn. Onbekendheid met risicomanagement en onbekendheid met de voordelen die dit biedt. Ook komt het voor dat men denkt dat risicomanagement een beoordelingsmiddel is voor het eigen functioneren. Het laat dan ook onverlet dat risicomanagement geld kost terwijl niet direct duidelijk is wat het opbrengt.

Risicomanagement volgens het RISMAN principe houdt in dat dit een cyclisch proces is en dat het gedurende het project regelmatig zal moeten worden doorlopen.

Risicomanagementcyclus

De risicomanagementcyclus  is de basis van de RISMAN methode. Hierbij wordt gesteld dat de risico analyse alleen, die inzicht geeft in de mogelijke risico’s binnen een project, niet voldoende is.
Projecten blijven in beweging en risico’s zullen wegvallen of zullen zijn weggenomen door mitigerende maatregelen en nieuwe risico’s kunnen zich voordoen. Om deze reden zou er periodiek een risico analyse gedaan moeten worden.

Het volgende plaatje laat zien dat wat de toegevoegde waarde van goed projectrisicomanagement kan zijn.

projectkosten

Het komt regelmatig voor dat een organisatie meerdere projecten tegelijk uitvoert. Risicomanagement helpt om de realisatie van alle projecten tot een succesvol einde te brengen. Binnen de aannemerij of software ontwikkelaars zou dit kunnen bijdragen tot het vergroten van de winstgevendheid van het bedrijf. Naarmate de volwassenheid van het risicomanagement groeit zou het de organisatie in staat kunnen stellen om meer innovatieve en complexere projecten uit te voeren.

In principe kan voor aanvang van iedere fase in het project een risico analyse worden uitgevoerd. De herkende en erkende risico’s zullen binnen de fase worden gemitigeerd. De fase waarin het project zich dan bevindt zal dan gedetailleerd worden bekeken met een doorkijk naar het eindresultaat van het project.

Een belangrijke vraag die vooraf gesteld dient te worden is of er gebruik gemaakt gaat worden van een kwantitatieve dan wel een kwalitatieve risicoanalyse.

Bij een kwalitatieve analyse worden over het algemeen aanduidingen gebruikt voor de orde van grootte om te bepalen wat de belangrijkste risico’s zijn. Bij een kwantitatieve analyse worden de risico’s aangeduid in termen van kansen en gevolgen. Kansen worden bijvoorbeeld uitgedrukt in een schaal (1 tot 5) en de gevolgen in euro’s, als het om kosten gaat en in bijvoorbeeld dagen of weken als het om de planning gaat. Deze gegevens kunnen worden gebruikt om een berekening uit te voeren om de totale kosten of doorlooptijd in belangrijkheid van onzekerheid te plaatsen.

kwalitatieve analyse

Ook is een semi-kwantitatieve gevolg analyse mogelijk. Deze is bedoeld om de orde van grootte in te kunnen schatten. Hierbij gaat het dan niet om de precieze getallen maar om de categorieën waarbinnen een gevolg valt zoals kwaliteit en doorlooptijd. Hierbij is te denken aan een kostenoverschrijding die kleiner is dan 5% van het projectbudget of een grote impact op het milieu. Deze methode kan helpen bij het prioriteren van de aanpak van de risico’s.

semi-kwantitatieve
Als risico’s zich onverhoopt voordoen kunnen deze een grote impact hebben op de scope. Tijdens de risico sessies kunnen zaken met betrekking tot de inrichting van de projectmanagement structuur en de daarbij behorende processen aan het licht komen. Een goede analyse methode die gebruikt kan worden voor het doorlichten van processen is de FMEA (Failure Mode & Effect Analysis). Deze methode richt zich vooral op het vinden van faalmogelijkheden van een product, systeem of proces. De technische oorsprong van deze methode hoeft geen belemmering te zijn voor het doorlichten voor productontwikkeling en/ of (productie)processen.
De samenstelling van een FMEA team bestaat uit de verschillende disciplines van het project aangevuld met vertegenwoordigers van de afdelingen, belangrijke leveranciers en de klant. De begeleider introduceert het beoogde systeem/ proces en ondersteunt dit met beschrijvingen, functies, schema’s, tekeningen of modellen.
Het negatieve denken bij dit proces staat centraal: Hoe laten we dit systeem/ proces falen? Hierbij valt te denken aan een technische oorzaak, het gebruik of het frustreren van het proces. Hoe meer faalwijzen er te vinden zijn in deze fase, hoe beter.

De stap die hierna volgt is om de gevonden faalwijzen te prioriteren. In deze methode is dit RPN genaamd. (Risk Priority Number). De berekening is als volgt:
RPN= P_o*P_d*S

P_o : Kans van optreden (Probability of occurence)
P_d : Kans van ontdekking (Probability of detection)
S : Ernst van de gevolgen (Severity)

Aan de variabelen worden punten toegekend op een schaal van 1 t/m 10. Met een maximum RPN score van 1000. Een vuistregel is dat er boven de 100 punten altijd actie wordt ondernomen door het projectteam. In andere gevallen beslist de projectleiding.

De gedachte achter de FMEA methode is dat risicomaatregelen bestaan uit het voorkomen van falen en het vergroten van de kans op ontdekking of het beperken van de gevolgen. Dit voordat het proces of product in gebruik wordt genomen.
Met het uitvoeren van deze methode wordt de kans op een onverwachte uitbreiding van de scope op basis van interne processen of systemen zeer beperkt. Dit wordt onder meer versterkt door het projectteam er later mee te confronteren. Het projectteam kan namelijk, door de druk van het project, bepaalde zaken niet zien of willen zien.
Actief projectrisico’s willen zien, managen en mitigeren kan het project geld besparen en het voorkomen dat er te veel tijd verloren gaat met het blussen van brandjes.

Het is zeer aan te bevelen om de projectcontroller te betrekken bij de risico sessies. De projectcontroller heeft belang bij zicht op de eventuele uitloop van de kosten, tijd en kwaliteit. Ook zal hij een positieve bijdrage kunnen leveren aan de discussies binnen de risicosessies. Dit komt met name omdat de projectcontroller geen last heeft van de inhoudelijke vakblindheid dat kan ontstaan en daardoor out of the box kan denken. Ook heeft hij zicht op het grotere geheel van het project en kan daardoor de raakvlakken van de verschillende vakdisciplines en processen overzien.

Risicomanagement is een zeer omvangrijk en belangrijk onderdeel van projectcontrol.

favicon

Projectcontrol

Wat is projectcontrol eigenlijk?

Onlangs had ik gereageerd op een aanvraag van een waterschap. Het betrof de functie Projectbeheerser volgens het IPM model van Rijkswaterstaat (RWS). Ik was zeer blij met deze uitnodiging want het is duidelijk dat dit een mooie opdrachtgever is met mooie en grote projecten.

Voor het gesprek zou beginnen nam ik de taken en verantwoordelijkheden nog eens door: Sparringpartner en adviseur voor manager projectbeheersing op tactisch en operationeel niveau op het terrein van integrale projectbeheersing; budget bewaking; advies inrichting administratieve organisatie; toetsen kaders voor kwaliteitsmanagement; scope bewaking; advisering programmacontroller AO/IC; risico’s; overzien, analyseren en beheersen van de GROTIK aspecten; enzovoort. Dit is een greep uit de totale lijst maar het geeft een aardig beeld van de functie. Het klinkt aardig als een projectcontrollers rol. Omdat ik daar al aardig wat ervaring in heb dacht ik “dat gesprek komt wel goed”. Beetje voorbarig, zo bleek.

Ik werd opgehaald door de projectmanager en we liepen ontspannen pratend naar het overlegkamertje waar de andere gesprekspartners al zaten te wachten, de manager projectbeheersing en de P&O adviseur. De sfeer was ontspannen en het gebruikelijke voorstel rondje verliep snel. Het beloofde een fijn gelijkwaardig gesprek te worden. Tot het gesprek begon. De eerste vraag was “Wat is projectbeheersing voor jou en wat is dit anders dan projectcontrol?” Ik beriep mij op het feit dat dit eigenlijk het zelfde is en dat dit al blijkt uit de vertaling van Control (wat beheersen betekent). Aan hun reactie, of eigenlijk het uitblijven daarvan, besefte ik mij dat dit niet een antwoord was waar ze op zaten te wachten. Of in ieder geval hadden verwacht.

Om kort te gaan liep het gesprek na dit moment voor geen meter meer. Mijn gevoel was dat ze te veel focuste op het woord “controller” en er daarmee een puur financiële rol van maakte. Ondanks mijn praktijk voorbeelden, verduidelijking en het theoretisch kader van de beheersaspecten benoemd in de taken en verantwoordelijkheden van de functie. Het mocht niet baten. De opdracht ging mijn neus voorbij.

Maar wat mij sinds dat gesprek bezig houdt is de vraag: wat is een projectcontroller eigenlijk?

Al ruim 15 jaar ben ik projectcontroller op grote en kleine projecten. In 2014 ben ik afgestudeerd “Registered Project Controller (RPC)” een Europees beschermde beroepstitel (SVPC curriculum Registered Project Controller, januari 2010). Mede hierdoor dacht ik te weten wat het zou inhouden. Waarom houdt die vraag mij dan zo bezig? Om een antwoord te vinden ben ik het Curriculum gaan lezen en verschillende artikelen.

In een mooi stuk over “De rol van de projectcontroller in grote projecten” proberen Bianca Hazelaar en Stanny Schapendonk, aan de hand van de theorie van Sathe, V te beschrijven of de projectcontroller een controlerende of ondersteunende rol heeft. Via de Type rollen volgens Sathe, V (Indipendent- Involved-, Split- en Strongcontroller) proberen de auteurs deze rol te plaatsen. Ze laten de beschrijvingen van de rollen van Sathe los op onder andere de complexiteit van het project, de organisatie en de onzekerheden binnen een project. Het is een mooi artikel en beschrijft de herkenbare complexiteit van de functie en positie van de projectcontroller. Maar de conclusie is wat teleurstellend maar niet onverwacht: dat een projectcontroller, om effectief te kunnen functioneren, meerdere rollen zou kunnen vervullen. Welke rol de projectcontroller moet vervullen in welke situatie is afhankelijk van een aantal factoren. Wordt hier nu gesuggereerd dat er verschillende typen projectcontrollers zijn? of dat ze het eigenlijk ook gewoon niet weten en het dus maar een alleskunner moet zijn?

In het artikel van Theo van Houten (FM.nl) “Projectcontrol: Bemoei jij je genoeg met projecten?” wordt verduidelijkt dat de (project)controller kan bijdragen om projecten tot een succes te maken en kan tonen waar de kansen en valkuilen liggen. Hierin noemt hij al redelijk snel dat de projectcontroller (soms) ook gezien kan worden als de “projectpolitie”. Letterlijk zegt hij “de rol van corporate policeman te vervullen…” Beetje kort door de bocht en niet erg bemoedigend. Verder is het artikel voor mij wat conceptueel en krijg meer het idee van een Financial controller dan van een projectcontroller.

Nog maar een artikel dan… Nog een van dhr van Houten. In dit artikel staat de vraag centraal of: een projectcontroller er aan kan bijdragen dat een project een succes wordt? En tevens: verwacht een organisatie dat een projectcontroller een dergelijke taak vervult? Voor deze vraag heeft hij naast literatuur zo’n 20 vacatureteksten geanalyseerd. Hieruit kwam vooral een salaris indicatie en dat de werkzaamheden vooral registrerend, informerend en adviserend zijn. Ook het opstellen van begrotingen en rapportages en een bijdrage leveren aan de business case. De rol van sparringpartner, gevraagd en ongevraagd adviseren en tot het taken pakket behoort vaak het bewaken van de projectrisico’s. Heej!… ik lees een deel van het takenpakket van de projectbeheerser! Ook in dit artikel wordt de theorie van Sathe aangehaald en zijn stelling: De controller moet evalueren van Sparring partner tot Business partner. Van Houten haakt hier op in door te er op te wijzen dat hier een kans ligt voor de projectcontrollers om actiever mee te denken en gebruik te maken van de vele economische instrumenten voor het project. De voorbeelden die hij dan noemt proces breakdown structures, product breakdown structures CPM etc.. als ook de project balanced scorecard, earned value etc.. Ik moet zeggen… mooi gezegd maar in mijn ogen gebeurt dit al. Is de projectcontroller dan al een businesspartner?

Dan als laatste toch maar het curriculum van de RPC opleiding erbij en de onderdelen waarop wordt getoetst:

Projectcontrol 2.0 – Omgevings- en stakeholdersmanagement; project skelet en dragende structuren; Teamwork en skills; projecteconomics; risico’s en onzekerheden; Project-, Programma- en portfoliomanagement en contracting.

Op sommige punten overstijgt dit misschien zelfs wel projectmanagement. Op z’n minst denk ik dat de projectcontroller al het niveau van businesspartner heeft behaald. Ja, ik denk zelfs dat mijn gesprekspartners bij het waterschap zelf niet precies wisten wat projectbeheersing precies inhoudt.

 

favicon

 

Hier de link naar een mooi antwoord van dhr Van Houten in het online-magazine Financieel-management op deze blog. Hoewel het een beetje voorbij gaat aan het punt wat ik probeer te maken (maar dat zal mijn onvermogen als schrijver zijn) is het een mooi stuk dat zeker de moeite waard is om te lezen. Zeker als je wilt solliciteren op een functie als projectcontroller!

 

projectbeheersing

Focus van projectcontrol

Trap niet in de grootste valkuil voor projectcontrollers

Tijd, informatie en kwaliteit en Risico. Voor Projectcontrol zijn dit de belangrijkste pijlers. Toch zijn niet al deze aspecten altijd even belangrijk voor het project en projectcontrol. Het sleutelwoord? Focus.

Tegelijkertijd is het zo dat niet al deze aspecten altijd even belangrijk zijn voor het project en projectcontrol. Zo kan het zijn dat bij sommige projecten de Kwaliteit het belangrijkste is. Dit kan zijn omdat bijvoorbeeld de veiligheid daardoor wordt gewaarborgd. Bij het project van een dochtermaatschappij van een groot vervoerdersmaatschappij, waar ik senior projectcontroller was, was ‘kwaliteit’ een heel belangrijk punt. Veiligheid Veiligheid en “reiservaring” van de klant stonden voor de opdrachtgever bovenaan. Door dit aspect zo hoog te waarderen ging dit ten koste van de planning (Tijd) en het budget (Geld).

Na een tijd was vertraging was goed te voorspellen. Maar dit gold niet voor het budget.

De planning werd in het begin vaak aangepast maar op het moment dat het productieproces goed was ingericht, na een paar treinen, was de vertraging goed te voorspellen. Dit gold echter niet voor het budget. Doordat het een bijzonder ingewikkeld project was, met een hoge politieke lading, was het lastig om een goede prognose te maken. Sommige onderdelen werden geproduceerd in het buitenland wat bij wijziging van het ontwerp, voor het logistieke proces bijzonder ingrijpend kon zijn.

Dus gebeurde er wat voor ieder project funest zou zijn.

Doordat de kwaliteit erg belangrijk was voor de opdrachtgever, gebeurde wat voor ieder project funest zou zijn. De engineeringsfase werd niet afgesloten. Halverwege de productie werden er nog steeds (kwaliteits-) ontwerpaanpassingen gedaan. Wat weer impact had op het logistieke proces in de productiehal, de aanpassing op het productieproces, het keuringsproces, de productie zelf en de logistiek en leveringsmomenten van de leverancier.

Het project is meer dan 150% over het budget heen gegaan. Maar is dit project mislukt?

Nee. De trein heeft een hoge veiligheid en nog belangrijker: De trein heeft een heel hoge klantwaardering. Deze werd alleen geëvenaard door de internationale ICE trein.

Dus buiten het voor projectcontrol frustrerende feit dat de prognose bijna niet stabiel te krijgen was door de snelle en vele ontwerpwijzigingen tijdens de productie, dat de planning voor de productie bijna altijd achterhaald was, is het project voor de opdrachtgever toch geslaagd.

Dened Projectbeheersing