Het gebrek aan kennis van ICT bij de manager die de rol van opdrachtgever vervult is niet de veroorzaker van de werkelijke kloof tussen een opdrachtgever en een opdrachtnemer. Maar wel de afzijdige houding in het gehele traject van een investering, waar een project onderdeel van is, is een belangrijke veroorzaker van de kloof.
Het hebben van ICT kennis is geen voorwaarde om de rol van opdrachtgever goed te kunnen vervullen. En kan dus ook geen oorzaak zijn voor de kloof. In dit artikel wordt ingegaan op het ontstaan van de kloof. Maar ook op de mogelijkheden om deze te overbruggen. Een kritische beschouwing over de rol van opdrachtgever en zijn benodigde kennis.
Inleiding
Projectmatig werken als middel wordt meer en meer gebruikt door organisaties om op een efficiënte manier een resultaat te bereiken binnen een bepaalde tijd en budget, waarbij gebruikt gemaakt wordt van expertise die verspreid is binnen de organisatie of daarbuiten. In de bouw wordt deze manier van werken al sinds lange tijd toegepast, maar de laatste decennia ook op andere vakgebieden. De automatisering is daar een sprekend voorbeeld van. Maar deze laatste is ook een voorbeeld van de vaak slechte resultaten die deze manier van werken met zich meebrengt. Onterecht wordt hiermee het middel van projectmatig werken geschaad.
Terwijl wij dit schrijven, is er een redelijke kans dat er weer een artikel in de dagbladen is verschenen over een mislukt project in de automatisering. De afgelopen decennia is, door verschillende partijen, veel onderzoek gedaan naar de oorzaken van de forse budget overschrijdingen. De conclusies die hieruit getrokken werden en de eventuele acties die hierop gevolgd zijn, hebben blijkbaar weinig effect. Doen we dan iets verkeerd? Het lijkt er wel op.
Uit de diverse publicaties en artikelen komen een aantal kenmerken van slecht presterende projecten steeds naar voren:
- een gebrek aan regie bij de realisatie van een project;
- een kloof1 tussen opdrachtgever en opdrachtnemer;
- een overkill aan control op de projectuitvoering.
Velen zullen dit herkennen. Maar de vraag is, wat doen we met dit gegeven? Hoewel slecht presterende projecten in meerdere omgevingen voorkomen, zullen we ons in dit artikel beperken tot het vakgebied van de automatisering. Echter, de door ons gesignaleerde problemen en aangedragen oplossingen zijn echter breder toepasbaar.
Probleemstelling
Ondanks de hooggespannen verwachtingen is projectmatig werken in veel gevallen nog niet de efficiënte aanpak die bestuurders en opdrachtgevers voor ogen hebben. Te vaak voldoet het resultaat niet aan de verwachtingen. En wordt bovendien niet binnen de afgesproken tijd en budget opgeleverd. De drie eerdergenoemde kenmerken, een gebrek aan regie, aanwezigheid van een kloof en een overkill aan control hebben met elkaar te maken. In de figuur is de onderlinge relatie van deze drie kenmerken schematisch weergegeven. Regie is vooral het (pro-actief) conditioneren van de stakeholders, Een gebrek aan regie leidt tot te weinig betrokkenheid en dus tot verschillende verwachtingspatronen. Hiermee wordt een kloof gecreëerd tussen enerzijds bestuurders en opdrachtgever en anderzijds tussen opdrachtnemer of projectmanager. De aanwezigheid van een kloof op zijn beurt verhindert dat er een goede vertrouwensbasis is tussen betrokken partijen. Dit gebrek aan vertrouwen leidt op zijn beurt weer tot de behoefte tot beheersen, wat al snel resulteert in een overkill aan control van de verantwoording over de uitvoering (re-actief). Dit laatste lijkt er meer op dat het een ritueel geworden is in plaats van dat het een stuurmiddel is. Het draagt al helemaal niets bij aan een effectieve regievoering. Betrokkenen zitten gevangen in een vicieuze cirkel:. De vraag is hoe deze te doorbreken. Maar ook wie de belanghebbenden zijn.
De resultaten van een klein onderzoek, gedaan door één van de auteurs2 geeft ook aan dat er sprake is van een kloof. Gevraagd naar de reden van (business) managers om de rol van opdrachtgever van een automatiseringsproject af te wijzen, gaf circa ⅓ aan geen verstand van automatisering te hebben en dus niet te weten hoe je een dergelijk project moet aansturen. Eenzelfde deel gaf aan geen tijd te hebben voor een goede invulling van deze rol. Dit laatste geeft te denken: is het werkelijk geen tijd of is er een andere reden? Deze elementen dragen wel bij aan een verwijdering tussen opdrachtgever en opdrachtnemer.
Interessant in dit kader is overigens ook de publicatie die is verschenen naar aanleiding van eerdergenoemd onderzoek van een drietal partijen (zie voetnoot 1). Daarin wordt eveneens gesteld dat er sprake is van een kloof tussen bestuurders enerzijds en projectmanagers anderzijds. Vaak voortkomend vanuit verschillende redenen. Maar ook concluderen zij dat er geen moeite wordt gedaan om deze kloof te overbruggen. De auteurs stellen op basis van hun onderzoek, dat de aanwezigheid van een dergelijke kloof het projectresultaat zonder meer negatief beïnvloedt.
Kenniskloof of een kloof tussen twee werelden, in beide gevallen heeft het mogelijk te maken met een onduidelijke rolverdeling tussen de verschillende partijen die bij het project zijn betrokken. Daarnaast spelen verschillende verwachtingspatronen van direct betrokkenen een rol bij het ontstaan van de kloof.
Eén ding is duidelijk: om deze kloof te dichten, worden er tot nu toe vooral maatregelen genomen aan de uitvoerende (lees opdrachtnemende) kant. Maatregelen die lijken op het compenseren van een gebrek een kennis bij de opdrachtgever. Maar om welke kennis gaat het dan? En waar moet je dan beginnen met het compenseren? En kun je dit van een opdrachtnemer vragen? Maar bovenal: is het perceptie of is er werkelijk sprake van een kloof? De hiervoor beschreven problematiek wordt dus veelal benaderd vanuit de invalshoek van de projectorganisatie. Logisch, want zij zijn de eerst verantwoordelijken voor het neerzetten van een goed resultaat.
In dit artikel willen wij deze problematiek benaderen vanuit de invalshoek van de opdrachtgever: lijnmanagement en bestuurders. Hiermee willen wij een bijdrage leveren aan het doorbreken van eerdergenoemde vicieuze cirkel, met de verschillende werelden van bestuur en management aan de ene kant en de opdrachtnemer/projectmanager aan de andere kant als uitgangspunt.
Analyse
In dit hoofdstuk wordt een korte analyse gegeven over de beleving en het ontstaan van de kloof.
Hoe kan dit probleem zijn ontstaan?
Enkele decennia geleden was het vakgebied van automatisering relatief nieuw en onbekend. Het was een gebied voor specialisten. Als manager wilde je daar niet te veel mee te maken hebben. De interesse was er niet en vaak had men ook geen tijd om zich in de materie te verdiepen. Misschien is hier wel de kiem gelegd voor de afzijdige houding van managers die de rol van opdrachtgever van een automatiseringsproject moeten gaan vervullen. Deze houding heeft zich verder gecultiveerd tot wat het nu is: ICT is een vak voor specialisten en zij weten wat goed is voor een organisatie.
In zekere zin geldt dit ook voor het projectmatig werken als zodanig. Een projectmatige aanpak is een andere manier van werken die voor veel leidinggevenden hun normale werkzaamheden doorkruist. Het begrip duaal management doet zijn intrede: het managen van continuïteit als lijnmanager én het managen van veranderingen als opdrachtgever. Met alle risico’s van dien. Het is onbekend terrein en veel lijnmanagers weten niet hoe hier mee om te gaan. Zij vinden dat ook projectmanagement een vakgebied is dat je het beste kunt overlaten aan specialisten die hier voor opgeleid zijn en over de nodige ervaring beschikken. Immers, zij weten hoe het moet.
Bovenstaande heeft de afgelopen jaren geleid tot een afzijdige en afhankelijke opstelling van de opdrachtgever en daarmee tot een vergroting van de kloof tussen beide partijen. Een kloof die vanuit opdrachtnemende kant vaak wordt geïnterpreteerd als een gebrek aan kennis bij de opdrachtgever. Deze afhankelijke opstelling is geleidelijk aan onderdeel van de cultuur geworden. En in die zin een hardnekkig fenomeen. Want een cultuur verander je niet van de ene op de andere dag.
Bestaat het probleem al lang?
Slecht presterende projecten in de automatisering zijn niet van de laatste tijd. Oudgedienden in het vak stellen dat het ‘van alle tijden’ is. Deze stelling wordt bevestigd door een citaat4 in de literatuur van de beginjaren negentig: "we do not seem to have time to plan the work adequately, but we seem have the time to do it twice...". Maar de laatste jaren wordt er in de media meer en meer aandacht aan geschonken. Bij de overheid wordt dit nog versterkt door de WOB5 en de aanwezigheid van een Algemene Rekenkamer. Maar ook opdrachtnemers en gebruikersgroepen worden kritischer: zij stellen meer eisen aan goed opdrachtgeverschap. En wordt daarmee de kloof zichtbaarder dan vroeger.
Alle media-aandacht ten spijt: het is blijkbaar nog onvoldoende om het probleem van de kloof prominent op de agenda van bestuurders te krijgen. Deze stelling wordt bevestigd door de auteurs van ‘De Kloof’. In zekere zin houden zij (de bestuurders) de kloof, die er al decennialang is, in stand. Vooral omdat zij de aanwezigheid van een kloof onvoldoende of niet erkennen. Met als gevolg dat de voorstellen ter verbetering vooral komen uit opdrachtnemende kant. En doordat zij amper worden gehoord, komen zij zelf met oplossingen. Met alle beperkingen van dien. Blijkbaar is er een gebrek aan kennis over het belang van goed opdrachtgeverschap bij betrokkenen aan de opdrachtgevende kant.
Daadwerkelijke oplossingen of schijnoplossing?
Opdrachtnemers, ongeacht of het nu de eigen ICT afdeling is of een externe ICT leverancier, hebben er alle belang bij om een project succesvol af te ronden. Gedachte daarbij is dat een tevreden opdrachtgever goed is voor het vertrouwen en dus voor eventuele vervolgopdrachten. En die opstelling is nu juist ook een valkuil: zeker als er sprake is van een opdrachtgever die zijn rol niet serieus neemt. In dat geval bestaat het gevaar dat de opdrachtnemer, overigens met de beste bedoelingen, verantwoordelijkheden naar zich toe trekt die hij in feite niet waar kan maken. Een opdrachtgever wordt naar de mond gepraat. Met het idee bij de opdrachtnemer, dat hij wel in staat is ‘om dat varkentje te wassen’ en aan de verwachtingen van de opdrachtgever kan voldoen. De praktijk laat echter een ander beeld zien.
Een valkuil kan ook schuilen in voorstellen voor oplossingen van gesignaleerde problemen die worden gedaan door een opdrachtnemer of andere externe adviseurs. Ervan uitgaande dat er sprake is van een constructieve opstelling, kan er in zekere zin sprake zijn van een tunnelvisie. Vanuit hun eigen belevingswereld worden de mogelijke oplossingen aangedragen: een ICT leverancier raadt bijvoorbeeld aan een business consultant toe te voegen om de ‘business alignment’ en dus de communicatie te verbeteren. Een accountantsbureau zal adviseren de controle te verbeteren of uit te breiden. Enigszins gechargeerd misschien, maar toch neigt het naar symptoombestrijding. Weinig opdrachtnemers zitten in dat geval in de positie om tegen de verantwoordelijke manager te zeggen dat hij zijn rol als opdrachtgever niet goed invult. Dit heeft alles te maken met de afhankelijke positie van de opdrachtnemer. Ook in het geval van een interne opdrachtnemer.
Ondanks dat een opdrachtgever omringd is door professionals, heeft hij, doordat hij ze niet begrijpt, steeds meer de neiging afstand te nemen tot het project: zeker als er geen vertrouwensrelatie is, gebaseerd op wederzijdse erkenning en respect. De ontstane afstand wordt nog vergroot als een opdrachtgever niet in staat is de adviezen op hun juiste waarde te beoordelen. Inhoudelijk is dat echter onbegonnen werk voor hem. Want waar moet je beginnen en hoe ver moet je gaan? Als het om strategisch of tactisch belangrijke projecten gaat, is het beter om gebruik te maken van contra-expertise. Maar in dat geval moet een opdrachtgever wel in staat zijn de juiste kennis op het juiste moment te mobiliseren. En zal hij mogelijk een onafhankelijke partij moeten inschakelen: een partij die niet bij de uitvoering betrokken is of gaat worden. Daar zit voor een deel het probleem: vrijwel alle zakelijke dienstverleners richten zich op de uitvoering want dat is commercieel aantrekkelijker. En in die zin staan een opdrachtgever én zijn bestuurders alleen. Dus dan toch maar inhoudelijk verdiepen? Het ontbreken van de nodige kennis over een de juiste aanpak van een investeringstraject zal schijnoplossingen dan ook in de hand blijven werken.
Is de kloof een gevolg van een gebrek aan kennis?
In de vorige alinea is al even aangestipt of een opdrachtgever over inhoudelijke kennis moet beschikken of juist niet. Er kan sprake zijn van twee uitersten: óf een opdrachtgever bemoeit zich inhoudelijke met het project, óf hij houdt zich verre van afzijdig. En zoals zo vaak, ligt de waarheid in het midden.
Input voor de black-box benadering is de doelstelling die de organisatie zichzelf heeft gesteld of opgelegd heeft gekregen. De output is het bereiken van de gewenste doelstelling. De opdrachtgever stelt een budget ter beschikking en benoemt een, liefst gecertificeerde, projectmanager. Deze is dan verantwoordelijk voor de realisatie van het traject om de beoogde doelstelling te bereiken. De rol van de opdrachtgever beperkt zicht tot het definiëren van de doelstelling en de acceptatie van het project resultaat. Met deze benadering zet een opdrachtgever zichzelf buiten spel. Hij is niet goed in staat het systeem van ‘checks and balances’ te hanteren waarmee hij kan bijsturen in zowel kwaliteit, tijd als geld. En hij mist dan ook de basis voor een goede regievoering: het conditioneren van de stakeholders.
Wil een opdrachtgever toch meer grip op een project hebben in een dergelijke black-box benadering, rest hem niets anders dan deels op de stoel van de projectmanager te gaan zitten. En daarmee loopt hij het risico inhoudelijk bij het project betrokken te raken. Een opdrachtgever die de inhoud moeilijk kan loslaten zal met open ogen in deze valkuil lopen. en is een nachtmerrie voor een projectmanager. De black-box benadering is een veel voorkomend verschijnsel bij opdrachtgevers: veelal gekozen in goed vertrouwen of omdat men de kennis ontbeert over hoe een dergelijk traject uit te voeren. Gebrek aan kennis vergroot juist het risico om in de valkuil te lopen van inhoudelijk bij het project betrokken te raken.
In een eerder artikel6 van de auteurs wordt aangegeven dat een project juist onderdeel is van een veel groter traject. Dit is schematisch7 weergegeven in de figuur.
In dit model is het project onderdeel van een veel groter traject:
het investeringstraject met daarin meerdere processtappen die voor een opdrachtgever van cruciaal belang zijn. Door het op de juiste manier doorlopen van deze processtappen en door het inschakelen van de juiste kennisgebieden, kan de opdrachtgever zich beperken tot een goede regievoering. En dat in een minimum van zijn tijd. Inhoudelijke kennis is dan niet of amper nodig. Maar door het gebrek aan aan ervaring met het juist doorlopen van een investeringstraject, staat de opdrachtgever voor een moeilijk dilemma: kiezen voor de black-box benadering of sturen op inhoud. Deze laatste is eigenlijk geen optie. Want nogmaals: waar moet je beginnen en hoever moet je gaan? Als een opdrachtgever hier niet goed uitkomt, is in veel gevallen het gevolg een minder betrokken, lees afstandelijke, opdrachtgever met alle problemen van dien. En is de weg vrij voor symptoombestrijding.
Wat is de rol van methoden en technieken?
Voor een opdrachtgever van een automatiseringsproject zijn er twee zekerheden: certificering van projectmanagers en het gebruik van methoden en technieken. Bij het benoemen van een externe projectmanager wordt vaak de eis gesteld dat hij of zij gecertificeerd moet zijn. Maar ook eigen projectmanagers wordt vaak de gelegenheid geboden zich te certificeren. Op zich een goede zaak. Maar dit alleen is niet voldoende.
Verder wordt er op grote schaal, zeker bij grote en middelgrote organisaties, gebruik gemaakt van methoden en technieken. Prince2™ is momenteel de meest gebruikte projectmanagement methodiek. Van der Molen8 noemt echter een aantal valkuilen bij de toepassing van Prince2™. Hij stelt dat de toegevoegde waarde van deze methodiek staat of valt met een goede toepassing van deze methodiek.
Een grote valkuil is de manager/opdrachtgever die alle vertrouwen heeft in dergelijke methodieken en denkt dat het met de toepassing hiervan als vanzelf goed komt met het project. Waarmee de kans van een black-box benadering wordt vergroot. En dus ook de afstand tussen opdrachtgever en -nemer. Voor een belangrijk deel ontneemt het blindelings toepassen van methodieken de opdrachtgever de middelen om een goede regievoering mogelijk te maken.
Menig opdrachtgever hoort van zijn opdrachtnemer dat van hem verwacht wordt dat hij bekend is met deze methodieken. Maar ook hier geldt, in hoeverre moet een opdrachtgever bekend en vertrouwd zijn met de in zijn organisatie gehanteerde methodieken? Het probleem is dat er teveel methoden zijn die ook nog eens te omvangrijk zijn9. Ook nu kun je je afvragen waar je moet beginnen met het opbouwen van de benodigde kennis.
Zoals door leveranciers zelf vaak al aangegeven, is het een projectmanagement methodiek. Het is dus primair bedoeld voor projectmanagers. En in die zin is de benodigde kennis van opdrachtgevers over deze methodiek beperkt. Als opdrachtgever moet je dat ook niet willen. Maar dit neemt niet weg dat een opdrachtgever zelf wel zicht moet hebben op de, voor hem, belangrijkste processtappen van het investeringstraject waar het project een onderdeel van is. Een kwestie van logisch nadenken. In sommige stappen kunnen elementen van deze methodieken overigens van toepassing zijn. Daarnaast is het belangrijk dat hij, voor een goede regievoering en uitvoering, zijn eisen stelt aan een project. En dit laatste heeft niets te maken met welke methodiek dan ook.
Is de cultuur van een organisatie van invloed?
De cultuur van een organisatie heeft een grote invloed op het projectmatig werken in de automatisering. En dus op de uiteindelijke resultaten. Het kan gaan om meerdere cultuuraspecten, maar hier beperken wij ons tot een viertal aspecten die een bijdrage leveren aan het veroorzaken of vergroten van de kloof tussen opdrachtgever en opdrachtnemer.
Een eerste aspect is de invloed van de Angelsaksische cultuur: het is geen toeval dat de hiervoor beschreven methodiek is ontstaan in deze cultuur10: er wordt vanuit gegaan dat al het handelen gericht moet zijn op het verbeteren van de efficiency, vastgelegd in bepaalde patronen. Er is sprake van het systematisch wegnemen van vrijheidsgraden bij de medewerkers binnen een project door een projectorganisatie in te richten volgens de principes van een methodiek. Als ondersteuning naar de professionals is dit een goede zaak, maar regels en procedures kunnen nooit hun plaats innemen. Het toekennen van verantwoordelijkheden en bevoegdheden worden aan mensen toegekend, niet aan systemen. Managers die gegroeid zijn in deze cultuur hebben de neiging een te groot vertrouwen in een systematiek te hebben. Een kritische en creatieve houding, gekoppeld aan de eigen verantwoordelijkheid, ontbreekt. Met alle gevolgen van dien.
Een tweede aspect is dat het belang van de rol van opdrachtgever in veel organisaties zwaar wordt onderschat. Men is de mening toegedaan dat het realiseren van een project een aangelegenheid is van de opdrachtnemer. Zeker als het om technische projecten gaat, zoals in de ICT. Het is op deze manier te veel een technische aangelegenheid geworden en er is te weinig aandacht voor de impact die een dergelijk project kan hebben op de organisatie. Er is duidelijk sprake van een ‘bottom-up’ benadering van de oplossing. Dat er voorstellen vanuit een ICT afdeling komen, is niets mis mee. Maar dat betekent wel dat de sturing vanuit de lijnorganisatie des te belangrijker wordt. Van hier uit zullen de mogelijke en gewenste veranderingen in gang moeten worden gezet én geregisseerd. Vanuit een heldere visie en met kennis van zaken van de organisatie. Dit kun je niet aan het project overlaten. Het probleem van deze onderschatting is niet het feit op zich, maar wel dat dit nagenoeg onbespreekbaar is. Vooral opdrachtnemers worden hier regelmatig mee geconfronteerd. En daarmee komen zij in conflict met hun eigen professionaliteit. De opdrachtgever wijzen op zijn tekortkomingen is ‘not done’. En dit laatste is een hardnekkig cultuuraspect. En vormt mede de basis voor een kloof. Of voor het vergroten ervan.
Een derde aspect heeft te maken met de houding van de overige stakeholders. Belangrijk is om deze in een vroegtijdig stadium te identificeren en na te gaan wat hun mogelijke invloed kan zijn. Invloedrijke stakeholders moeten op een juiste manier betrokken worden bij het investeringstraject. In een artikel11 over projectmanagement wordt gesteld dat machtige stakeholders sterk de neiging hebben het formele besluitvormings- en planningsproces te omzeilen. Blijkbaar krijgen zij deze ruimte. Maar het kan bijzonder schadelijk zijn voor een project. Het ligt vaak niet binnen het vermogen van een projectmanager om dit proces te keren. Hij voelt zich daarmee hoogst ongelukkig: hij ziet dingen mis gaan, maar wordt niet gehoord. Sterker nog, hij kan daardoor worden gezien als iemand die niet over de juiste competenties beschikt. Hij moet toch in staat zijn dit op te lossen? Ook dit onbegrip draagt ook bij aan de kloof tussen bestuurders en projectmanagers. Hier ligt juist de kern van een goede regievoering (zie definitie). en dus een belangrijke rol voor de opdrachtgever. Het overbruggen van de kloof heeft alles te maken met respect voor elkaars wereld en dus voor de onderlinge rolverdeling.
Een vierde aspect heeft meer te maken met de houding van de opdrachtgever zelf, met andere woorden. de lijnmanager die deze rol moet vervullen. Bij automatiseringsprojecten bestaat sterk de neiging om geen eigenaar/opdrachtgever van een dergelijk project te willen worden. Dit vanwege het risico dat zo’n project met zich meebrengt. Een risicovol project kan je imago schaden of zelfs je carrière. Maar de negatieve houding kan ook te maken hebben met het feit dat een lijnmanager niet weet hoe een dergelijk project als opdrachtgever aan te sturen. Beide aspecten kunnen elkaar uiteraard versterken. Het bestaan van een dergelijke houding bij lijnmanagers die zich ook inderdaad aan hun verantwoordelijkheid als opdrachtgever kunnen onttrekken, is volledig de bestuurders aan te rekenen. Zij accepteren blijkbaar een dergelijk gedrag, zijn niet in staat dit te veranderen of willen dat niet.
Des te zorgelijker wordt deze houding als de lijnmanager ten onrechte denkt dat hij prima in staat is om het er even bij te doen en over de voldoende kennis en vaardigheden beschikt. Niet beseffend dat het aansturen van een project als opdrachtgever wezenlijk anders is dan het managen van een afdeling. Ook hier geldt dat het feit op zich niet het probleem is. Immers met een beetje ondersteuning of coaching kan een opdrachtgever zijn professionaliteit verbeteren.
Het gevaar zit hem erin dat hij zich niet voldoende bewust is wat er, in alle redelijkheid, van hem wordt verwacht. Voor een opdrachtgever is het ‘not done’ om zich bloot te geven. In zijn omgeving wil hij gezien worden als een kundig en vaardig manager. Een opdrachtnemer zal voor een dergelijke houding weinig of geen respect kunnen opbrengen.
De cultuur binnen een organisatie heeft, ongemerkt, een grote invloed op het vervullen van de rol van opdrachtgever en dus op het succes van een project. De eerst aangewezenen die verandering in de houding van de potentiële opdrachtgevers kunnen aanbrengen zijn de bestuurders zelf. Het erkennen van deze cultuurinvloeden is dan een eerste stap. Het er naar handelen een tweede.
Er zijn enkele cultuuraspecten aan de orde geweest die van invloed kunnen zijn op de prestaties van een project. Een opdrachtgever moet zich bewust zijn van de invloeden van de verschillende cultuuraspecten en zal over de nodige kennis moeten beschikken van zijn eigen organisatie op dit punt. Maar hij zal ook voldoende inzicht moeten hebben in de mogelijke mechanismen om de cultuur op een gewenste manier te beïnvloeden. Ook dat inzicht kun je niet delegeren aan een projectmanager. Hooguit dat je dit met hem kunt delen als hij uit dezelfde organisatie komt. Het niet voldoende onderkennen van deze rolverdeling tussen opdrachtgever en opdrachtnemer, legt nog meer de nadruk op het verschil in de twee werelden en vergroot daarmee de kloof.
De structuur en de positie van de opdrachtgever hierin
Om een nog beter inzicht te krijgen in de kloof en het ontstaan hiervan, is het nuttig om te kijken naar de positie van een paar belangrijke spelers,: bestuurder, de lijnmanager/opdrachtgever en de opdrachtnemer/projectmanager. Maar niet alleen hun positie, maar ook hun onderlinge relatie. Daarvoor maken we gebruik van het borgingsmodel (zie de figuur) dat weergeeft hoe een project vanuit de hiërarchie ontstaat en verankerd is in de staande organisatie. In het borgingsmodel12 is er sprake van drie niveau’s: het doelstelling bepalend niveau, het bijdrage leverend niveau en het realiserend niveau. In zijn algemeenheid kan worden gesteld dat het eerste niveau het domein is van de bestuurders: in dit voorbeeld de directie. Maar het kan evengoed het domein van het management van een afdeling of business unit zijn. Het tweede niveau binnen de lijnorganisatie, is vaak het eerstvolgende echelon. Het derde en onderste niveau is het domein van de (interne) opdrachtnemer. Er zijn nu een aantal fasen te onderscheiden: ervan uitgaande dat de doelstellingen van de organisatie vastgesteld zijn, volgt een oriënterende fase. In deze fase gaat de directie na wie van het management denkt een bijdrage te kunnen leveren aan het behalen van de doelstelling. Het management wordt geactiveerd en gestimuleerd hierover constructief mee te denken. Het ligt voor de hand om de manager die in staat is de grootste bijdrage te leveren, te benoemen als opdrachtgever. Hij krijgt van de directie de vraag om zijn ideeën in een businesscase uit te werken. In dit stadium kunnen specialisten geraadpleegd worden. Zij hebben echter een adviserende rol op dat moment. Op basis van de businesscase kunnen de verantwoordelijke bestuurders een gefundeerde beslissing nemen over de investering. Op dat moment is de rol van opdrachtgever formeel en is hij de eigenaar van de businesscase. Een veel voorkomende valkuil bij de oriënterende fase is dat bestuurders de vraag direct neerleggen bij de eigen ICT afdeling. In dat geval komt de werkelijke opdrachtgever buitenspel te staan. In elk van deze fases is de houding van de bestuurders belangrijk.
Veel managers worden beoordeeld op het vervullen van hun managementtaken binnen de lijnorganisatie. Zij worden niet of nauwelijks beoordeeld op hun capaciteit of prestaties als opdrachtgever van een project. Eliyahu Goldratt13 stelt dat een mens dat gedrag vertoont waarop hij wordt beoordeeld. Dat betekent dat wanneer een opdrachtgever niet als zodanig wordt beoordeeld, hij zich ook niet als een opdrachtgever zal gedragen. Bestuurders moet zich dus beter bewust zijn van waar je een opdrachtgever op aan kunt spreken, maar ook waar je hem op kunt beoordelen en afrekenen. Het borgingsmodel kan hen daarbij helpen doordat het aangeeft dat de lijnmanager/opdrachtgever een centrale rol heeft bij het totstandkomen van een project.
De afspraak over de te leveren bijdrage is vastgelegd in de businesscase. Van hieruit kan een projectopdracht worden geformuleerd door de opdrachtgever. De afspraken over de realisatie van het project worden vervolgens vastgelegd in het projectplan. Het is duidelijk dat de opdrachtgever een centrale rol heeft bij het top-down ontstaan van een project, maar ook bij de borging ervan. Uit het borgingsmodel blijkt dat de manager/opdrachtgever op de scheiding functioneert van twee werelden: de staande organisatie (de continuïteit) en de wereld van het project (de verandering). Er ontstaan een aantal nieuwe, vaak tijdelijke spanningsvelden tussen beide werelden.
Het beschikbaar hebben van middelen, de onderlinge rolverdeling, duaal management, tegenstrijdige belangen, afdelingsbelangen, om enkele te noemen. Maar ook ontstaan er formele en informele groepen. Binnen een project, maar ook daarbuiten. Medewerkers die zich bedreigt of gestimuleerd voelen door komende veranderingen bijvoorbeeld. Keuning en Eppink14 stellen het volgende: “binnen groepen is in situaties van onderlinge rivaliteit veelal sprake van een waarneembaar hechter worden van de groep en van een grote mate van loyaliteit tussen groepsleden. De “rijen” worden als het ware gesloten en eventuele interne geschillen worden bijgelegd. Het gezamenlijk een prestatie leveren gaat de gevoelens beheersen, de groep organiseert zichzelf en men is in staat zo nodig een front te maken. Groepen zien elkaar niet langer als client of neutraal object, maar beginnen elkaar als vijand te zien. Communicatie wordt dan beperkt tot het strikt noodzakelijke.”
Menig project is op een dergelijk ontstane situatie gestrand. Het front kan buiten een project ontstaan, maar eveneens vanuit het project zelf. In geen van beide gevallen is de projectmanager de persoon die dit kan doorbreken. Een professionele opdrachtgever daarentegen, onderkent dit fenomeen en zal hierin sturend optreden. Bepalend voor succes is de mate van volwassenheid van een organisatie voor wat betreft haar ervaring met projectmatig werken en hoe zij omgaat met deze spanningsvelden.
Rodney Turner15 noemt deze mate van volwassenheid van een organisatie de ‘‘Projectivity’: het vermogen van een organisatie om de interface tussen staande- en projectorganisatie effectief te managen en daarmee haar doelen te bereiken.
Het herkennen en erkennen van deze werelden is de basis voor een goede rolverdeling en dus voor een goede regievoering over belangrijke en machtige stakeholders. Dit laatste is een taak van een opdrachtgever: een taak die hij nooit kan delegeren. Maar hij moet dan wel over de kennis beschikken over hoe je dit moet aanpakken.
Het niet of onvoldoende onderscheiden van de drie verschillende rollen van bestuurder, opdrachtgever en projectmanager kan de eerdergenoemde rolvermenging versterken. En zo houden bestuurders, opdrachtgevers en projectmanagers elkaar in een houdgreep. Het is geworden tot een ritueel en een belangrijke factor in het ontstaan of verwijderen van een kloof tussen bestuurders en projectmanagers. Terwijl juist de laatsten dit graag anders zien.
Visie
In onze visie zouden bestuurders een lijnmanager, in zijn rol van opdrachtgever, meer moeten afrekenen op de beoogde toegevoegde waarde van de gewenste verandering. Daarnaast mogen zij hem ook afrekenen op de mogelijke neveneffecten en het benutten van kansen en meerwaarden van de investering. Zij kunnen de gewenste verbetering in de resultaten van de investering daadwerkelijk in gang zetten door een opdrachtgever meer aan te spreken op zijn verantwoordelijkheden.
Maar het is niet alleen een kwestie van afrekenen: bestuurders hebben eveneens de plicht om de betreffende manager te faciliteren: geef hem de ruimte om zijn rol goed te kunnen vervullen, maar geef hem ook de mogelijkheid om zich te bekwamen in zijn rol.
De rol van opdrachtgever kan het beste worden ingevuld door een manager uit de eigen lijnorganisatie. Hij weet als geen ander wat de veranderingen zijn die kunnen bijdragen aan de gewenste doelstelling van de organisatie, maar hij kent ook als geen ander de mogelijkheden en beperkingen van zijn eigen organisatie om deze veranderingen door te voeren.
Elk project zou onderdeel moeten zijn van een investeringstraject welke geïnitieerd wordt vanuit de behoefte of noodzaak van de organisatie. Dan ontstaat als vanzelf de borging van het project binnen de staande organisatie en geeft het de opdrachtgever de mogelijkheden en de middelen om een goede regie te voeren. Bij een dergelijke benadering is het project slechts een afgeleide waarbij het resultaat centraal staat. Dat resultaat op zijn beurt, is het middel voor de opdrachtgever om de bijdrage te leveren aan de gewenste doelstelling.
In dit kader willen we wijzen op een stelling van Jim Collins16, auteur van diverse management boeken: “Een succesvolle organisatie onderkent het verschil tussen wat nooit mag veranderen en wat open kan staan voor verandering, tussen wat echt heilig is en wat niet. De zeldzame kunst om continuïteit en verandering te managen is nauw verbonden aan de bekwaamheid een heldere visie te ontwikkelen……..”.
Een opdrachtgever zou dit als geen ander dienen te weten: hij is de vertegenwoordiger van de organisatie die succesvol wil zijn. Hij bepaalt de doelmatigheid van de beoogde veranderingen. Een opdrachtnemer kan hem hier bij helpen, maar zal meer gericht zijn op de efficiency. Beiden zijn complementair aan elkaar en hebben elkaar nodig.
Welke kennis is nodig?
Als de rol van opdrachtgever wordt ingevuld door een lijnmanager uit de staande organisatie, is het project bijna automatisch goed geborgd in de organisatie en ligt het sponsorship vast. Echter, veel hangt af van de manier waarop de opdrachtgever rol wordt ingevuld. Wil een lijnmanager de rol van opdrachtgever goed vervullen, heeft hij aanvullende kennis en vaardigheden nodig.
Om een beter inzicht te krijgen in de benodigde kennis, een belangrijke randvoorwaarde voor het voorkomen of overbruggen van een kloof, maken we gebruik van een tweetal modellen. het eerdergenoemde borgingsmodel en het daaruit voortvloeiende regiemodel. Het borgingsmodel laat, naast het top-down ontstaan van een project, ook zien dat het projectresultaat een middel is om een bijdrage te leveren aan de doelstelling van de organisatie. Maar het borgingsmodel geeft ook inzicht in de kennis waarover de opdrachtgever moet beschikken om zijn sleutelrol goed te kunnen vervullen. Hij is als het ware een spin in het web. Om de businesscase te beoordelen, moet hij over voldoende kennis van zijn eigen organisatie beschikken. Maar hij moet ook enige conceptuele kennis hebben van de eventuele oplossingen die worden aangedragen in de vorm van scenario’s. In ieder geval voldoende om deze te kunnen beoordelen en dan vooral in relatie tot de impact die deze oplossingen hebben op zijn organisatie. Hij moet juist niet-functionele eisen of criteria kunnen beoordelen evenals de omgevingsfactoren die van invloed kunnen zijn op een project. In het proefschrift van Trienekens17 worden de niet-functionele eisen genoemd als de zogenaamde ‘ilities’. Het gaat bijvoorbeeld om de beschikbaarheid en de doelmatigheid. Maar ook om eisen op het gebied van de schaalbaarheid, de betrouwbaarheid en de haalbaarheid. Uiteraard zijn er nog meer niet-functionele eisen, maar we gaan daar verder niet op in18.
In de meeste gevallen zal een opdrachtgever niet zelf de businesscase opstellen. Hij zal dit delegeren. Maar delegeren moet op de juiste manier gebeuren en dus nooit aan de toekomstige opdrachtnemer, ook niet als dit de eigen ICT afdeling is. Dat is vragen om moeilijkheden en het ontneemt de opdrachtgever de kans op een goede regievoering op basis van checks and balances (verderop beschreven). Naast het beoordelen van de businesscase, zal een opdrachtgever ook in staat moeten zijn om het projectplan goed te kunnen beoordelen. Het gaat niet alleen om de niet-functionele criteria maar evenzeer om de realiteitszin van de beoogde uitvoering. Belangrijk in dit verband is natuurlijk de manier waarop het project wordt georganiseerd, welke mijlpalen zijn gedefinieerd en hoe concreet zijn deze, waarover en hoe wordt er gerapporteerd en wat de eventuele risico's zijn en welke maatregelen er worden er genomen om de risico’s te elimineren of te beperken. Dit zijn slechts enkele criteria. Maar inhoudelijke kennis over het bereiken van het resultaat is in principe niet nodig, behalve over hoe en wanneer het (tussen)resultaat gaat bijdragen aan de doelstelling van de organisatie. Een opdrachtgever kan overwegen, in voorkomende gevallen, gebruik te maken van contra-expertise. Door Det Norske Veritas wordt zelfs geadviseerd19 om er, vanuit het principe ‘trust but verify’, eventueel een onafhankelijke derde partij bij te halen. Zo’n partij kan een veelheid aan rollen krijgen. Maar betrek een dergelijke derde partij nooit in de uitvoering. Er ontstaan dan mogelijke dubbele belangen en objectiviteit richting opdrachtgever is dan niet meer aanwezig.
De deskundigheid waarmee een opdrachtgever de businesscase en het projectplan laat opstellen en in staat is om beide documenten op zijn juiste waarde te (laten) beoordelen, is belangrijk voor een eventuele vertrouwensbasis met zijn opdrachtnemer en met zijn bestuurders.
Vanuit het eerdergenoemde borgingsmodel kan een regiemodel worden afgeleid: een achttal stappen die onderdeel zijn van het totale investeringstraject. In onderstaand figuur zijn deze acht stappen weergegeven in het domein van de investering. Vanaf het definiëren van de doelstelling tot het bereiken hiervan20.
Daarnaast zijn er nog een tweetal andere domeinen getekend: het bovenste is het domein van de primaire processen van een organisatie: dat van de stakeholders, management, e,d. Het onderste is het domein van de specialisten: intern of extern. Beide laatstgenoemde domeinen hebben een belangrijke invloed op het verloop van het investeringstraject. In feite geeft dit model de processtappen van een investering weer die voor een opdrachtgever belangrijk zijn voor een goede regievoering en een maximale betrokkenheid met een minimum aan tijd. Maar ook op welk moment welke partijen een bijdrage moeten leveren aan het traject.
Zoals al eerder aangegeven gaat het om de deskundigheid van de opdrachtgever waarmee hij de verschillende stappen doorloopt en kan beoordelen. En dit steeds in relatie tot de kennis van zijn eigen organisatie. Op deze manier wordt het project primair benaderd vanuit de wereld van de opdrachtgever. Op de momenten die hij bepaalt, worden de deskundigen erbij gehaald. De ervaring van een opdrachtgever zal bepalend zijn voor het succes waarmee dit traject wordt doorlopen.
Concreet kan gesteld worden dat een professionele opdrachtgever in dat geval over de volgende expertise moet beschikken:
- kennis hebben van de eigen organisatie: niet alleen procesmatig, maar vooral ook het verandervermogen en de bereidheid hiertoe. Wat kan er wel veranderd worden en wat nog niet? De do’s en don’ts binnen zijn organisatie;
- inzicht hebben in en open staan voor de (technische) ontwikkelingen die van invloed zijn op de processen in zijn organisatie(onderdeel). Dit inzicht kunnen vertalen in een visie over welke bijdrage geleverd kan worden om de doelstellingen van een organisatie te bereiken. Welke bijdrage kan hij, als manager van een organisatieonderdeel hier aan leveren.
- kennis hebben van de belangrijks processtappen die bij een investeringsproject horen. Maar vooral goed kunnen inschatten welke kennisgebieden op welk moment nodig zijn. Hiervoor zal hij moeten beschikken over enige conceptuele kennis;
- kennis hebben van de eerder beschreven ‘ilities’: deze worden gebruikt voor het beoordelen van verschillende scenario’s, maar zij worden ook gebruikt gedurende de realisatie van een project en tussentijdse bijstelling van de scope;
- een goed inzicht hebben in de belangen van de verschillende stakeholders en welke rol zij kunnen spelen bij het succesvol maken en/of belemmeren van een investeringstraject: een opdrachtgever moet zich kunnen verplaatsen in hun wereld en hun belangen;
- voldoende kennis hebben om de professionaliteit van een projectmanager te kunnen beoordelen. Waar kun je de projectmanager op afrekenen en waar kun je hem faciliteren?
- kennis hebben van de dynamiek van een project organisatie. Wat voor wissel trekt dit op de organisatie waar hij voor verantwoordelijk is. Welke zijn de spanningsvelden die ontstaan en hoe gaat hij hier mee om?
- kennis hebben van de verschillende cultuuraspecten binnen zijn organisatie, maar ook over de mogelijke mechanismen om deze cultuur op een gewenste manier te beïnvloeden. Dit laatste vaak in samenwerking met zijn bestuurders.
Het hebben van deze expertise is een belangrijke voorwaarde om de rol van opdrachtgever goed te kunnen invullen en op die manier een bijdrage te kunnen leveren aan een succesvol project. Het aanwenden van deze expertise voor een goede regievoering is vooral een kwestie van ervaring. Naast het hebben van kennis, zijn factoren als motivatie en het in de gelegenheid worden gesteld om deze rol goed te kunnen vervullen, even belangrijk21.
Wat is effectief opdrachtgeverschap?
Hoe gebruikt een opdrachtgever zijn eigen kennis en ervaring om effectief te geven aan zijn rol met een minimum aan tijd en zonder zich in de inhoud te verdiepen?
De processtappen zoals genoemd in het voorgaande regiemodel kunnen hem hierbij helpen. Maar ook een speciaal voor dit doel, door de auteurs ontwikkeld model dat gebaseerd is op het principe van ‘checks & balances’ kan hem hierbij helpen. De achtergrond van het ‘checks & balances‘ model wordt gegeven door de Rekenkamer22 aan de hand van een voorbeeld.
In dit model gebruike we drie partijen die de gebruikers, en het management vertegenwoordigen. De laatste partij uiteraard in zijn rol van opdrachtgever. Als voorbeeld wordt hier gebruikt de processtap van het opstellen van de businesscase.
In de doelstelling van een organisatie wordt in feite vastgelegd wat een organisatie wil. Deze behoefte (of noodzaak) wordt, onder leiding van een eigen projectmanager, door de eigen medewerkers verder uitgewerkt in specifieke eisen en wensen. Op enig moment zal hierbij gebruik gemaakt gaan worden van de kennis en kunde van specialisten. Dit kan zijn de eigen ICT afdeling, maar ook een externe dienstverlener. Op dit niveau vindt in zekere zin een confrontatie plaats tussen het pakket aan eisen en wensen en wat de techniek eventueel kan bieden om dit te realiseren. Het gaat dan primair om de functionele eisen. Door deze confrontatie zal blijken welke mogelijkheden er zijn.
Deze worden gedefinieerd als een aantal mogelijke scenario’s. De rol van de opdrachtgever is op deze manier beperkt tot degene die het proces bewaakt en de voorwaarden stelt. Onderdeel van het opstellen van de scenario’s is het vaststellen van de mogelijke gevolgen van een aantal van de eerdergenoemde niet-functionele eisen en criteria (de’ ilities’) op de organisatie als geheel. Niet alleen wat betreft de investering, maar ook de haalbaarheid en de mogelijke risico’s. De uitkomsten van de scenario’s zijn bepalend voor de besluitvorming.
De eerdergenoemde omgevingsfactoren maken duidelijk welke eisen er aan een goede regievoering worden gesteld. Belangrijk is te weten wie de spelers zijn die het project positief of negatief kunnen beïnvloeden en welke acties vervolgens nodig blijken.
Tussen de mogelijke scenario’s kan vervolgens een afweging worden gemaakt door de belangrijkste stakeholders: dit kan een keuze zijn maar ook een bijstelling van wat een organisatie wil. In het laatste geval begint een volgende ronde. De opdrachtgever heeft in dit proces een centrale rol maar is minimaal betrokken bij de inhoud. Op enig moment zal er voor een scenario worden gekozen. Dit scenario vormt de basis voor de businesscase en daarmee voor de goedkeuring van het project. Maar het gekozen scenario vormt ook de basis voor een goede regievoering door de opdrachtgever richting overige stakeholders. De rol van opdrachtgever is zo beperkt tot degene die het proces bewaakt en de voorwaarden stelt.
Het principe van ‘checks & balances’ biedt de opdrachtgever een uitstekend middel om een centrale rol te spelen met een minimum aan tijd en kennis. Het principe is in het voorbeeld hierboven gebruikt voor het opstellen van een businesscase, maar het kan gebruikt worden in elke processtap van een investeringstraject, ook gedurende de realisatie van het project. De afweging ligt in het laatste geval op het niveau van de stuurgroep. De scope wordt voor een belangrijk deel bewaakt door wat de organisatie wil. Zoals gedefinieerd in de businesscase als een haalbare optie.
Terug naar de kenmerken van slecht presterende projecten zoals die in het begin van dit artikel zijn benoemd: gebrek aan regie, aanwezigheid van een kloof en een overkill aan controle. Op basis van onze visie en de rol van de opdrachtgever daarin, kunnen we het schema nu aanpassen: het begint bij het onderkennen van de verschillende werelden van bestuurders, opdrachtgever en opdrachtnemer en hun onderlinge rolverdeling. Als dit onderscheidt wordt gemaakt ontstaat de mogelijkheid om een brug te slaan tussen betrokkenen. Het slaan van deze brug is het begin van wederzijds respect en vertrouwen in elkaars competenties en vaardigheden. De aanwezigheid van een vertrouwensbasis maakt het gebruik van “management by exception” als middel mogelijk. Daarmee wordt een overkill aan control voorkomen, maar het geeft tevens de mogelijkheid om een bijdrage te leveren aan een goede sturing door de opdrachtgever. Een goede regievoering is nu mogelijk. Gaandeweg het traject kan een dergelijk mechanisme zich versterken met positieve gevolgen voor het verloop van een project. Dan is er sprake van een gesloten cyclus die op onderdelen zonodig bijgesteld kan worden.