Opdrachtgevers en de meetbaarheid van een ICT project

Als klein jongetje ging ik af en toe met mijn vader mee die aan het einde van de dag de voortgang moest controleren van een woningbouw project. Ik vond het boeiend om te zien hoe een dergelijk project vorderde. Per dag kon je de resultaten zien. Maar ook de kwaliteit kwam aan de orde: het gebeurde niet zelden dat een gemetselde muur of een ander onderdeel werd afgekeurd. Dat maakte indruk op mij. Vooral als mijn vader met zijn voet een deel van het metselwerk omver drukte. Daar gingen weer een partij stenen: het resultaat van een halve dag werken. Ingecalculeerd of niet? Dat laatste maakte ik mij toen nog niet druk over. Dat kwam pas veel later.  

Hoe anders gaat het in de ICT: daar kun je niet het aantal bakstenen tellen of het aantal kozijnen dat geschilderd is. Binnen de ICT wordt vaak gesteld dat de voortgang en/of kwaliteit van een project moeilijk te meten zou zijn. Een stellingname die door veel opdrachtgevers wordt gevolgd. Al of niet ingegeven door specialisten op dit gebied: consultants, projectmanagers, leveranciers, etc. Maar is het onwetendheid of is het eigenbelang? U mag het zelf invullen. 

In tegenstelling tot wat algemeen de overtuiging is, weet ik uit eigen ervaring, vanuit de rol van opdrachtgever, dat ook de voortgang van een ICT project wel degelijk is te meten. Sterker nog, in principe is elk type project meetbaar te maken. Voorwaarde is een professionele opstelling van zowel de opdrachtgever als de projectmanager. Maar ook de onderlinge samenwerking, gebaseerd op wederzijds vertrouwen en respect, is een voorwaarde. Mist één van deze factoren, zal het meetbaar maken een moeizaam proces zijn, zo niet onmogelijk. 

Een opdrachtgever, als meest belanghebbende, zou beter op de hoogte moeten zijn van de mogelijkheden een ICT project meetbaar te maken. Het gaat hierbij om de volgende twee elementen:

? de voortgang van een project in relatie tot het eindresultaat;

? de kwaliteit van de opgeleverde (tussen)resultaten. 

Het meten van de voortgang is gebaseerd op een tweetal principes, namelijk de Work Breakdown Structure (WBS) en de Earned Value Method (EVM). Bekende technieken voor projectmanagement. Beiden zullen kort behandeld worden in de volgende paragrafen. Een opdrachtgever mag ervan uitgaan dat elke projectmanager deze technieken als geen ander beheerst en weet toe te passen. 

Het meten van de kwaliteit van de (tussen)resultaten is iets ingewikkelder. Hiervoor bestaan geen technieken. Het is een kwestie van het toepassen van een aantal organisatorische principes. Ook deze zullen kort worden behandeld.

Beide elementen kennen een zekere mate van subjectiviteit. Het gaat er om de invloed van de subjectiviteit tot een minimum terug te brengen. Niet in één keer het totale werk onder handen proberen in te schatten, maar opsplitsen in kleine eenheden of werkpakketten. Daardoor is de invloed van eventuele inschattingsfouten per werkpakket op het totale projectresultaat relatief gering.

Van een opdrachtgever mag verwacht worden dat deze bekend is met de mogelijkheden die het toepassen van deze principes hem bieden. Het is een kwestie van even door de zure appel heen bijten. Maar als dat is gebeurd, wil een opdrachtgever niet anders meer.

Een goed gedefinieerde Work Breakdown Structure (WBS) is de ruggengraat van elk project.  Een WBS is niets anders dan een hiërarchische opsplitsing van het project in activiteiten volgens een bepaald patroon. Het kent over het algemeen drie tot vier niveaus. Het aantal activiteiten per niveau kan sterk variëren maar het is de kunst om ook deze beperkt te houden. Uiteraard hangt de uiteindelijke opsplitsing af van meerdere factoren. Bijvoorbeeld de omvang van het project, de complexiteit of het type project. Het is een kwestie van ervaring om een optimum te vinden in het opsplitsen van een project in activiteiten.

Op het laagste niveau is het een voorwaarde dat elke activiteit een concreet resultaat oplevert. Deze basisactiviteiten of werkpakketten zullen niet te groot en ook niet te klein moeten zijn. Verder wordt aan elk van deze basisactiviteiten een budget toegekend. Indien elk van deze activiteiten goed gedefinieerd is, is het voor een projectmanager en zijn medewerkers relatief eenvoudig om de voortgang van de betreffende activiteit in te schatten, evenals het beoordelen van de kwaliteit. Eventuele inschattingsfouten zullen bij het afronden van deze activiteit worden gecorrigeerd. Hiermee wordt voorkomen dat een opdrachtgever voor verrassingen komt te staan aan halverwege of aan het einde van het project. Indien over te veel basisactiviteiten moet worden gecorrigeerd is óf de WBS niet goed gedefinieerd óf de projectmanager heeft onvoldoende ervaring op dit punt.  

Bij het definiëren van een WBS zijn een tweetal invalshoeken mogelijk:

? gezien vanuit de beleving van het ICT domein of dat van de opdrachtnemer;

? gezien vanuit de beleving van het business-domein of dat van de opdrachtgever.

In het eerste geval is vaak een meer technische insteek, afhankelijk van het type project. Is het een ERP implementatie of is het de ontwikkeling van een eigen systeem. Vanuit deze invalshoek wordt vaak gekozen voor een opsplitsing die te maken heeft met de processen in een project gezien vanuit het ICT domein: opstellen specificaties, technisch ontwerp, realisatie, systeemtesten, etc. Het is een opsplitsing die weinig of niet aansluit bij de belevingswereld van een opdrachtgever. Maar voor een opdrachtnemer veel voordelen oplevert, bijvoorbeeld voor het inplannen van eigen resources of om externe leveranciers er bij te betrekken. 

De voorkeur van een opdrachtgever gaat veel meer uit naar een opsplitsing die aansluit bij het businessdomein. Dit heeft te maken met eventuele tussentijdse opleveringen per afdeling, minimale verstoring van de reguliere bedrijfsprocessen, het aanpassen van de organisatie, het accepteren van de (tussen)resultaten of het trainen van afdelingen. 

Een dergelijke WBS zal over het algemeen een meer functionele opsplitsing hebben. 

Het vinden van de juiste WBS is een intensieve dialoog tussen opdrachtgever en projectmanager vóórdat het project wordt gestart. Zij zullen gezamenlijk tot een passende oplossing moeten komen. Een ervaren projectmanager kan een opdrachtgever hierin ondersteunen. Juist omdat het de ruggengraat van een project is, wordt geadviseerd hier de tijd voor te nemen. 

Een WBS is niet alleen belangrijk voor het meten van de voortgang en de kwaliteit maar ook voor een betere inschatting van de risico’s, het kunnen maken van ‘what-if’ scenario’s en het beter kunnen delegeren van werkzaamheden. Zoals al aangegeven zijn de activiteiten op het laagste niveau bepalend voor de voortgang. De hogerliggende niveaus zijn in feite aggregatie niveaus die worden gebruikt om de resultaten samen te kunnen te voegen tot op het hoogste niveau van het project. Het geeft de opdrachtgever en de stuurgroep de mogelijkheid om, als zij gebruik maakt van het principe van ‘management by exception’, in te zoomen in de lagere niveaus om de knelpunten binnen een project te traceren. Gezamenlijk kan dan naar oplossingen worden gezocht. 

Het meten van tijd en geld alleen is niet voldoende om de voortgang van een project te bepalen. Toch is er menig project waar sprake is van een uitgebreide uren registratie. Deze wordt dan vergeleken met het beschikbare budget. Het enige dat een opdrachtgever in dat geval weet, is de hoeveelheid geld dat is verbruikt en dat nog beschikbaar is voor het afronden van het project. Maar waar de exacte status van het project is, is niet te verklaren uit deze cijfers. 

Projectmanagement kent een techniek dat uitermate geschikt is voor het meten van de voortgang van een project. Deze techniek is gebaseerd op de Earned Value Method (EVM) of Terugverdiende Waarde Methode (TWM). Een techniek die in de bouw en engineering veelvuldig wordt toegepast maar in de ICT nog amper. Tot mijn verbazing is het een techniek die lang niet in alle boeken over projectmanagement wordt genoemd. Het zegt voldoende over de kwaliteit van deze boeken.

Het principe van de EVM is even eenvoudig als voor de hand liggend. Per basisactiviteit of werkpakket onder handen wordt wekelijks een inschatting gemaakt van het percentage gereed. Deze activiteiten liggen op het laagste niveau van de WBS. Het percentage gereed wordt gebruikt om het budget behorende bij deze activiteit om te zetten in een ‘terugverdiende waarde’. 

Hiermee kan het resultaat in geld worden vergeleken met de werkelijke kosten en het beschikbare budget. Om de mogelijke inschattingsfouten te relativeren is het belangrijk dat concrete resultaten van de activiteiten op het laagste niveau voor iedere betrokkene duidelijk gedefinieerd zijn en de omvang is te overzien. Om bureaucratie te voorkomen is het vinden van een juiste indeling een lastige zaak, maar voor een ervaren projectmanager zou dit geen enkel probleem mogen opleveren. Overigens, grote projecten lenen zich meer voor het toepassen van deze techniek dan hele kleine projecten. 

Nadat meerdere resultaten bekend zijn, krijgt een opdrachtgever nu te maken met een grafiek waarin 3 curven voorkomen: het oorspronkelijk afgesproken budget (BC), de werkelijke kosten (AC) en de ‘terugverdiende waarde’ (EV). Hoewel een opdrachtgever niet vertrouwd hoeft te zijn met het toepassen van deze techniek, dat ligt vooral op het terrein van de projectmanager, is het voor een opdrachtgever wel belangrijk vertrouwd te zijn met de interpretatie van een dergelijke grafiek.  

Zowel op het hoogste aggregatie niveau, dat van het project, als op de tussenliggende niveaus. Uit een dergelijke grafiek valt namelijk veel af te leiden. In dit eenvoudige voorbeeld moge het duidelijk zijn dat het project behoorlijk achter ligt op het schema. Het blijkt dat in week 10 de werkelijke kosten circa 90 k€ boven het budget liggen, terwijl het resultaat op het niveau ligt van drie weken terug. 

Het verschil in tussen de terugverdiende waarde en de werkelijke kosten is bijna twee ton! Met andere woorden: er is voor circa 90 k€ geleverd, maar de opdrachtgever heeft er meer dan 280 k€ voor betaald. Een fors verschil. Een dergelijke ontwikkeling had al eerder geconstateerd kunnen worden: in week 4 was al duidelijk dat er iets mis was met het project. Toen had al beter onderzocht moeten worden wat er aan de hand is: ligt het aan de kwaliteit van de projectmanager, is het budget verkeerd ingeschat of zijn er andere factoren geweest die dit negatief tussen resultaat tot gevolg hebben. Ook bij een dergelijke analyse kan inzoomen volgens de principes van de WBS nuttig zijn. 

Een ervaren opdrachtgever kan in week 10 ook een reële inschatting maken van de uiteindelijke opleverdatum en de bijbehorende, werkelijke kosten. Respectievelijk week 40 en 1.250 k€. Helaas een al te reële afspiegeling van het gros van de tegenwoordige projecten. 

Belangrijk om nog even te noemen is dat het oorspronkelijk budget in principe tot het einde van het project moet zijn gefixeerd. Tussentijdse wijzigingen zijn mogelijk, maar hebben consequenties voor de verdeling van het resterende budget en voor de het uiteindelijke percentage gereed. Ook dit is een kwestie van ervaring hoe hier mee om te gaan. Bijkomend voordeel van het gebruik van de EVM is de mogelijkheid om de betrouwbaarheid en de ervaring van een projectmanager te beoordelen.   

Een project is in feite een tijdelijke productie eenheid. Ongeacht of het nu in de bouw, de engineering of de ICT is. Het is een tijdelijke organisatie waarin input wordt geleverd in de vorm van resources en de output is een concreet resultaat. In een productie omgeving zijn een aantal kentallen bekend die zonder meer ook van toepassing zijn op een project. Het gaat in dit geval om de volgende grootheden:

? de productiviteit;

? de bezettingsgraad;

? de leverbetrouwbaarheid.

Het zijn grootheden die, onder een aantal voorwaarden, kunnen worden afgeleid van eerdergenoemde stuurmiddelen als budget, percentage gereed en werkelijke uren. Maar ook zijn het grootheden waar een opdrachtgever werkelijk iets mee kan en waar hij invloed op kan uitoefenen. Bijvoorbeeld de bezettingsgraad: een project is vaak sterk afhankelijk van het beschikbaar stellen van de kennis van medewerkers uit zowel het ICT domein als dat van de business. 

Dit laatste ligt vaak onder de directe invloedssfeer van een opdrachtgever. Daarentegen is de productiviteit vooral afhankelijk van de kennis en ervaring van de ter beschikking gestelde medewerkers van een project. De leverbetrouwbaarheid zegt veel over de kwaliteit van de planning en de ervaring van de projectmanager in het afronden van de basisactiviteiten. 

Het meten van de kwaliteit in een ICT project is best lastig, maar niet onmogelijk. Het is vooral sterk afhankelijk van de manier waarop een project wordt georganiseerd. Het gaat om de beoordeling van (deel)systemen die een bepaald bedrijfsproces ondersteund. Ook hierbij is de opsplitsing in deelactiviteiten volgens de WBS een hulpmiddel.

Ook bij hardware is de kwaliteit moeilijk te bepalen. Bijvoorbeeld een laptop van een A-merk versus dat van een B-merk. Wat is het kwaliteitsverschil tussen beide. Een objectieve maat zou kunnen zijn de gemiddelde levensduur en de gemiddelde onderhoudskosten over deze periode. Maar deze kentallen zijn niet altijd beschikbaar. In dat geval gaat de eigen ervaring meespelen. Objectiviteit is in dat geval ver weg. 

Toch is het ook bij een ICT project mogelijk een redelijk betrouwbaar beeld te krijgen over de kwaliteit van een (deel)systeem. Het heeft vooral te maken met de verwachtingen waar al of niet aan wordt voldaan. Zoals al eerder aangegeven gaat het bij het bepalen van de kwaliteit (van een deel) van een ICT project vooral om een organisatorisch principe. Dit is gebaseerd op het feit dat er sprake is van een leverende partij en een ontvangende partij. 

Bijvoorbeeld een groep van ontwerpers die een functioneel ontwerp leveren (proces A). ICT engineers maken op basis hiervan een technisch ontwerp (proces B). De verantwoordelijke voor proces B keurt de kwaliteit van proces A. Gezamenlijk komen ze tot overeenstemming. Binnen de afgesproken tijd (!) is aan de verwachtingen van B voldaan en dus mag je aannemen dat de kwaliteit voldoende is. 

Dit principe kan overal worden toegepast: of het nu om het produceren van een handleiding gaat, het maken van een procedure of het schrijven van een businesscase. Het laatste voorbeeld is waar een opdrachtgever zelf direct mee te maken heeft. De belanghebbende is in dit geval de opdrachtnemer of projectmanager en zal een belangrijke stem hebben in het bepalen van de kwaliteit van de businesscase. 

Eén van de redenen overigens waarom een businesscase nooit door de opdrachtnemer of projectmanager zelf kan worden opgesteld. De slager keurt zijn eigen vlees. Om tot een goed eindresultaat te komen, zal zowel het investeringstraject als het project op een dusdanige manier georganiseerd moeten worden dat een dergelijke kwaliteitsbeoordeling mogelijk is. 

Het is vaak een kwestie van een goede rolverdeling en het vastleggen van bijbehorende verantwoordelijkheden. Binnen een project kennen we het proces van systeem- en acceptatietesten. In feite is dit een toepassing van eerdergenoemd principe en de verantwoordelijkheid van de projectmanager. 

Het eindresultaat van het project is onderdeel van een investeringstraject en zal beoordeeld moeten worden in relatie tot de businesscase: de verantwoordelijkheid van de opdrachtgever. Te vaak gebeurd het dat het systeem van testen en evalueren een sluitpost is binnen een project. Dit is zeker niet in het belang van de opdrachtgever en zijn gebruikers. Een opdrachtgever heeft er daarom alle belang bij dat deze processen binnen een project goed zijn geborgd en gebudgetteerd. Ook hierin kan een Work Breakdown Structure een opdrachtgever van nut zijn. 

Het toepassen van genoemde principes biedt een opdrachtgever de mogelijkheid elk ICT project meetbaar te maken. Uit eigen ervaring weet ik dat de voorbereiding op dit punt een lastig traject is. Het is een middel en mag nooit een doel op zich zijn. Veel hangt af van de vakbekwaamheid van de projectmanager om hier mee om te gaan. 

Voor een ervaren projectmanager is het geen enkel probleem om zijn of haar opdrachtgever hierin te begeleiden. Er moet dan wel een basis van wederzijds vertrouwen zijn. Het resultaat van de afspraken over de WBS en de EVM zijn een vast onderdeel van het projectplan. Opdrachtgevers die zich toch meer in deze materie willen verdiepen, verwijs ik naar een goed projectmanagement handboek . 

Ook de projectmanager zelf zou belanghebbende moeten zijn in het vergroten van de meetbaarheid van een ICT project door het toepassen van de WBS en daaraan gekoppelde EVM. Echter, in de praktijk blijkt de meetbaarheid vaak slecht geregeld. Deels omdat er een stroming is die van mening is dat het niet mogelijk is een ICT project te meten. Deels omdat een opdrachtgever er geen belang aan hecht of onbekend is met de mogelijkheden. Het ligt in dat geval voor de hand dat een projectmanager er voor kiest om het goed meten van de voortgang en de kwaliteit achterwege te laten. Het wordt gezien als te veel overhead en te veel bureaucratische rompslomp. Waarom moeilijk doen als het eenvoudig kan?

Voor een opdrachtgever biedt het meetbaar maken van een project op deze manier veel voordelen. Je komt minder voor verrassingen te staan en kunt betere voorspellingen doen. Knelpunten kunnen in een vroegtijdig stadium zichtbaar gemaakt worden zodat er gezamenlijk naar een goede oplossing gezocht kan worden. 

Bijkomend voordeel is bovendien dat het toepassen van de WBS en de EVM een groot beroep doet op de vakbekwaamheid van een projectmanager. Al snel zal een opdrachtgever kunnen beoordelen of zijn projectmanager de benodigde kennis en ervaring heeft een project goed te beheersen. Zeker belangrijk als je bedenkt dat uit onderzoeken blijkt dat slecht projectmanagement nog altijd voor meer dan 30% één van de belangrijkste oorzaken is van de forse budgetoverschrijding van een project. En de verantwoordelijkheid van een opdrachtgever overigens om al of niet in te grijpen. 

Ir. Derk Kremer 

goed opdrachtgeverschap | onderzoeker | publicist | gastspreker | klankbord 

twitter: @derk_kremer

email: derk.kremer@eestum.eu