Complexe rol opdrachtgever bij IT-project

In theorie is het allemaal glashelder. De opdrachtgever zorgt bij aanvang van een project voor een breed gedragen visie en het noodzakelijke draagvlak en houdt deze levend gedurende de doorlooptijd. De projectmanager heeft hieraan voldoende houvast om in het project ook de lastige keuzes te maken. In de praktijk daarentegen bestaat er doorgaans niet één duidelijke visie en ontbreekt het draagvlak. Dat is geen tekortkoming. Dat is de normale wereld van de directeur-opdrachtgever, die voortdurend in overleg is met zijn managers en collega’s en zo telkens visie en draagvlak creëert.

Waarom is dat dan zo lastig bij een IT-project van enige omvang? De volgende drie redenen spelen daarbij een rol:

De bestuurlijke verantwoordelijkheid van de opdrachtgever is groter dan het project alleen. De opdrachtgever heeft nooit het vereiste mandaat. De opdrachtgever mist de gebruikelijke signalen uit zijn organisatie waarop hij kan sturen.

De ‘opdrachtgever’ is één van de rollen bij projectmanagement. Hij is in de organisatie het hoogste aanspreekpunt voor het project. De meest betrokken bestuurder-directeur vervult vaak deze rol. Bij het implementeren van bijvoorbeeld een HRM-module van een ERP-systeem is dat de betreffende concernstafdirecteur. De opdrachtgevende HRM-directeur ziet echter een IT-project als onderdeel van een grotere veranderopgave. Vaak is het IT-project nog niet de helft van deze opgave en – hoewel lastig – ook niet het moeilijkste deel ervan. De directeur staat bijvoorbeeld tegelijkertijd voor het verbeteren van de HRM-dienstverlening, het professionaliseren van zijn management, het samenvoegen van afdelingen en het vereenvoudigen van personeelsregelingen.

Al deze verantwoordelijkheden van de directeur vallen om goede redenen buiten de scope van het IT-project maar kunnen daarop wel een grote en onvoorspelbare invloed hebben. Daarnaast zijn er allerlei mogelijke invloeden vanuit de rest van de organisatie: verscherpte aandacht vanuit de werkdivisies vanwege een aanstaande reorganisatie, een moeizame relatie met de ondernemingsraad, een ongelukkig getimede benchmark waaruit de HRM-functie als omvangrijk en duur naar voren komt. Houd je dan als opdrachtgever vast aan je uitgangspunten of kom je je interne klanten en de OR enigszins tegemoet?

Door deze omstandigheden kan de directeur als opdrachtgever van het IT-project op de projectmanager overkomen als inconsequent, visieloos of zelfs dom. Soms is dat ook zo, maar meestal beweegt de opdrachtgevende directeur dan mee met een relevante ontwikkeling net buiten het blikveld van de projectmanager. Met name de projectmanager die zijn blikveld geheel laat samenvallen met de scope van zijn project, kan hierdoor voor onaangename verrassingen komen te staan.

Risicosignalen voor projectmanager en opdrachtgever

• De opdrachtgever zegt tegen de projectmanager: ‘Dit project is zeer belangrijk. Je krijgt van mij alle ruimte en steun. Zeg maar wat ik moet doen.’

• De opdrachtgever denkt draagvlak in de organisatie te hebben vanwege de vermeende technische noodzaak van het project.

• De opdrachtgever verwacht dat het project de logica levert voor beslissingen die moeilijk liggen in de organisatie.

• De projectmanager denkt dat hij in zijn project werkt met ‘gemandateerde medewerkers’.

• Het geplande ‘verandermanagement’ krimpt van ‘cultuurverandering’ via ‘opleiden’ en ‘instructies voor de systeembediening’ naar ‘beschikbaar stellen van instructiemateriaal’.

• De projectmanager houdt tegen beter weten in vol dat de opdrachtgever namens de organisatie beslist.

• De projectmanager en de opdrachtgever denken beiden dat de ander hen zal redden als dat nodig is..

Mandaat

Een flink IT-project heeft organisatiebrede consequenties. Het mandaat van de opdrachtgever om namens de organisatie te beslissen over het project is dan ook de kern van de project-governance. Althans, dat is de theorie. In de praktijk heeft de opdrachtgever dat mandaat nooit echt.

Hiervoor is een aantal redenen. Ten eerste is de reikwijdte van de consequenties voor de organisatie op het moment van mandateren nog onduidelijk. Consequenties binnen het verantwoordelijkheidsgebied van collega-directeuren vereisen altijd aanvullend overleg met die collega’s, ongeacht wat daarover bij aanvang van het project is afgesproken. Het karakter van collegiaal overleg op directieniveau verschilt tussen organisaties en is historisch bepaald. Een collegiaal meningsverschil leidt echter vaak tot een impasse met onduidelijke afloop. Hierdoor ontstaan grote onzekerheden in de besluitvorming, mede omdat over organisatorische consequenties expliciet besloten moet worden wanneer zij niet logisch uit het IT-project voortvloeien.

Souffleurs

Directeuren zijn geen allesweters. Een goede directeur heeft in het dagelijkse werk een fijnmazig, vaak informeel netwerk van souffleurs binnen en buiten zijn organisatie. Hij weet heel precies voor welke onderwerpen hij bij wie moet zijn en hoe hij signalen op waarde moet schatten. Bij een flink IT-project ligt dat anders. De opdrachtgevende directeur wordt geconfronteerd met nieuwe onderwerpen, waarbij hij niet weet wie er in zijn organisatie verstand van heeft en wie er eigenlijk verantwoordelijk voor is.

Daarnaast – en dat is nog verwarrender – weet de directeur niet hoe hij de signalen moet interpreteren die hij spontaan uit zijn organisatie krijgt. Managers en medewerkers houden zich op de vlakte over de echte onderwerpen en geven ontwijkende antwoorden als de directeur doorvraagt: ‘Ze zijn druk bezig en ze zeggen zelf dat het goed gaat’ of ‘Ik heb kritisch gereageerd en ze zeggen dat ze mijn commentaar zullen verwerken’. De opdrachtgever merkt dat hij niet in control is maar beschikt over voldoende sociale vaardigheden om dat te verbergen. Hierin schuilen forse risico’s. De organisatie voelt zich niet echt verantwoordelijk voor de projectproducten en vinkt die af omdat er ‘geen reden is dat niet te doen’. De projectmanager voelt zich niet verantwoordelijk voor consequenties buiten de scope van zijn project en heeft daarvoor – als hij goed is – ook gewaarschuwd. En de opdrachtgever gelooft maar al te graag dat het project en zijn eigen organisatie het voorliggende beslisdocument grondig hebben doorgesproken en keurt dit dan ook met jaloersmakende joie de vivre goed. De rest zien we later wel.

Helpende hand

Veel projectmanagers herkennen in het bovenstaande falend opdrachtgeverschap. Veel opdrachtgevers herkennen hierin echter dat zij voor moeilijke en onverwachte beslissingen steeds weer visie en draagvlak moeten creëren en voelen zich daarbij niet gesteund door het projectmanagement. Hoe kan de projectmanager de opdrachtgever helpen, zonder op zijn stoel te gaan zitten?

Een paar concrete suggesties. Het is verstandig om niet tot het laatste moment te wachten met het opleiden van betrokken medewerkers. Begin het project met het opleiden van alle betrokkenen in de organisatie. Daardoor krijgen medewerkers en managers al in een vroeg stadium zicht op de mogelijke consequenties van het project en zijn zij gedurende het project geïnformeerde gesprekspartners. Dit is niet alleen goed voor het project en de organisatie. De opdrachtgever krijgt hiermee de mogelijkheid om zich adequaat te laten souffleren door deskundigen uit de eigen organisatie. Het is gebruikelijk om een IT-project te organiseren en te plannen in fases rond de productie van de deliverables. Hierbij is dan de besluitvorming door de opdrachtgever en stuurgroep gepland als gebeurtenissen die vrijwel geen tijd kosten.

Bij veel IT-projecten zit de complexiteit echter niet meer in de technische deliverables maar vooral in het aanpassen van de organisatie en de daarbij horende besluitvorming. Het helpt de opdrachtgever als de projectmanager zijn project primair inricht en plant rond de besluitvorming in de organisatie. Dat heeft te maken met de vorm, de volgorde en de timing van de op te leveren managementproducten. Een set standaardprocesbeschrijvingen heeft bijvoorbeeld voor het IT-project zelf weinig waarde maar kan goed de basis vormen voor besluitvorming over het aanpassen van de dienstverlening, het samenvoegen van afdelingen of andere verstrekkende organisatorische consequenties. Hierdoor oefent de organisatie in het nemen van lastige beslissingen en de projectmanager ziet in een vroeg stadium hoe de hazen lopen en wat de werkelijke ambities zijn. Het helpt de opdrachtgever als de projectmanager de besluitvorming in de organisatie ondersteunt zonder deze over te nemen. Bijvoorbeeld door ook voor de organisatorische issues die buiten de scope van het project vallen, een issue-log met adequate ondersteuning in te richten. En ook door medewerkers die een bijdrage leveren in het project, bij mijlpalen via de reguliere lijn aan de opdrachtgever te laten rapporteren over de kwaliteit van de (tussen)producten. Idealiter eist de opdrachtgever hierbij van de tussenliggende managementlagen dat zij snappen waar het over gaat. Hierdoor komt het onvermijdelijke gedoe in de organisatie veel eerder aan het licht en kan dit beter worden gemanaged.

Kortom, het helpt als de projectmanager zich realiseert dat de opdrachtgever niet de gedroomde alleswetende visionair is met onbegrensd mandaat, maar een ervaren bestuurder-directeur die gedurende het project visie en draagvlak moet ontwikkelen voor eerst nog onbekende consequenties in de organisatie. Als de projectmanager daar rekening mee houdt dan helpt dat bij het inrichten en plannen van het project. Want dan helpt hij de opdrachtgever daadwerkelijk bij het verbeteren van zijn organisatie. En dat is uiteindelijk altijd het doel van ieder IT-project.

Tag

Onderwerp



Niet gevonden? Vraag het de redactie!

Heeft u het antwoord op uw vraag niet gevonden, of bent u op zoek naar specifieke informatie? Laat het ons weten! Dan zorgen we ervoor dat deze content zo snel mogelijk wordt toegevoegd, of persoonlijk aan u wordt geleverd!

Stel uw vraag