Projectinrichting en opdrachtbeheer

Inhoudsopgave

Inleiding
Verantwoordelijkheden en bevoegdheden
Projectorganisatiestructuur

1. Inleiding

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

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

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

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

2. Verantwoordelijkheden en bevoegdheden

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

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

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

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

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

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

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

2.1 Opdrachttypen en systeemontwikkeling

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

Een mogelijke opzet is weergegeven in de volgende afbeelding:

3. Projectorganisatiestructuur

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

Schematisch is de standaardprojectorganisatie als volgt weer te geven:

Enkele definities:

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

3.1 Kenmerken

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

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

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

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

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

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

3.2 De noodzaak van de verschillende functies

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

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

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

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

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

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

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

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

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

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

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

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

De hier beschreven aanpak is goed te combineren met bestaande projectmanagementmethodieken. Cruciaal is de rol van GPL. Meestal zonder adequate opleiding moet hij/zij ervoor zorgen, dat zowel de opdrachtgever, de gebruikers en de leveranciers tevreden zijn. Dit vergt een groot inlevingsvermogen in de behoefte van alle partijen. (Zie ook ‘Programma’s en complexe projecten niet op plan maar op visie sturen’).

Oorspronkelijke versie: 1 juli 1999, herziene versie: 22 april 2010

The post Projectinrichting en opdrachtbeheer appeared first on ZBC Kennisbank.