Inleiding

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 woningbouwproject. Ik vond het boeiend om te zien hoe zo’n 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 ging weer een partij stenen: het resultaat van een halve dag werken. Was dat verlies ingecalculeerd? Daar maakte ik mij nog niet druk over. Dat deed ik pas veel later. Hoe anders gaat het in de ICT! Daar kun je niet het aantal bakstenen tellen of het aantal geschilderde kozijnen. In de ICT hoor je vaak dat de voortgang en/of kwaliteit van een project moeilijk te meten zou zijn. Zo denken veel opdrachtgevers erover, al of niet ingegeven door specialisten op dit gebied, zoals consultants, projectmanagers en leveranciers. Is hier sprake van onwetendheid of van eigenbelang? U mag het zelf invullen.

Basisprincipes

Als opdrachtgever weet ik uit eigen ervaring dat – in tegenstelling tot de algemene overtuiging – 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. Ook goede onderlinge samenwerking, gebaseerd op wederzijds vertrouwen en respect, is een voorwaarde. Ontbreekt een van deze factoren, dan is het meetbaar maken een moeizaam, zo niet onmogelijk proces. Een opdrachtgever (de meest belanghebbende) zou beter op de hoogte moeten zijn van de mogelijkheden om een ICT-project meetbaar te maken. Het gaat hierbij om de volgende twee elementen. Ten eerste de voortgang van een project in relatie tot het eindresultaat. Ten tweede de kwaliteit van de opgeleverde (tussen) resultaten. Het meten van de voortgang is gebaseerd op twee principes: de Work Breakdown Structure (WBS) en de Earned Value Method (EVM). Dit zijn bekende technieken in het projectmanagement. Beide behandel ik hierna kort. 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 behandel ik kort. Beide elementen kennen een zekere mate van subjectiviteit. Het gaat erom 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 splitsen 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. Is dat gebeurd, dan wil een opdrachtgever niet anders meer.

Hiërarchie van een project

Een goed gedefinieerde Work Breakdown Structure (WBS) is de ruggengraat van elk project. Een WBS is niets anders dan een hiërarchische splitsing van het project in activiteiten volgens een bepaald patroon. Hij kent over het algemeen drie tot vier niveaus. Het aantal activiteiten per niveau kan sterk variëren, maar het is de kunst om dit beperkt te houden. Uiteraard hangt de splitsing 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 splitsen van een project in activiteiten. Op het laagste niveau is een voorwaarde dat elke activiteit een concreet resultaat¹ oplevert. Deze basisactiviteiten of werkpakketten moeten niet te groot en ook niet te klein zijn. Verder kent WBS aan elk van deze basisactiviteiten een budget toe. Is elk van deze activiteiten goed gedefinieerd, dan 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 ze bij het afronden van deze activiteit corrigeren. Hiermee wordt voorkomen dat een opdrachtgever voor verrassingen komt te staan halverwege of aan het einde van het project. Moet over te veel basisactiviteiten worden gecorrigeerd, dan is óf de WBS niet goed gedefinieerd óf heeft de projectmanager onvoldoende ervaring op dit punt. Bij het definiëren van een WBS zijn twee invalshoeken mogelijk: de beleving van het ICT-domein of van de opdrachtnemer; de beleving van het businessdomein of van de opdrachtgever. In het eerste geval is er vaak sprake van een meer technische benadering, 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 splitsing die te maken heeft met de processen in een project gezien vanuit het ICT-domein: opstellen specificaties, technisch ontwerp, realisatie, systeemtesten, etcetera. Het is een splitsing 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 erbij te betrekken. De voorkeur van een opdrachtgever gaat veel meer uit naar een splitsing 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 heeft over het algemeen een meer functionele splitsing. Het vinden van de juiste WBS is een intensieve dialoog tussen opdrachtgever en projectmanager vóórdat het project wordt gestart. Zij moeten gezamenlijk tot een passende oplossing komen. Een ervaren projectmanager kan een opdrachtgever hierin ondersteunen. Juist omdat het de ruggengraat van een project is, adviseer ik 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 hoger liggende niveaus zijn in feite aggregatieniveaus die worden gebruikt om de resultaten te kunnen samenvoegen 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 ‘management by exception’ in te zoomen op de lagere niveaus om de knelpunten binnen een project te traceren. Gezamenlijk kan dan naar oplossingen worden gezocht.

Meten van de voortgang

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 urenregistratie. Deze wordt vergeleken met het beschikbare budget. Het enige dat een opdrachtgever in dat geval weet, is hoeveel geld is verbruikt en hoeveel geld nog beschikbaar is voor het afronden van het project. Maar wat de exacte status van het project is, is niet te verklaren uit deze cijfers. Projectmanagement kent een techniek die zeer 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 dat de omvang is te overzien. Het vinden van een juiste indeling, om bureaucratie te voorkomen, is een lastige zaak, maar voor een ervaren projectmanager zou dit geen enkel probleem mogen opleveren. Overigens lenen grote projecten zich meer voor het toepassen van deze techniek dan kleine. Nadat meerdere resultaten bekend zijn, krijgt een opdrachtgever nu te maken met een grafiek waarin drie curven voorkomen (figuur 1): 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 aggregatieniveau, dat van het project, als op de tussenliggende niveaus. Uit een grafiek als die in figuur 1 valt namelijk veel af te leiden. In dit eenvoudige voorbeeld moge het duidelijk zijn dat het project behoorlijk achter ligt op het schema. In week 10 liggen de werkelijke kosten circa 90.000 euro boven het budget, terwijl het resultaat op het niveau ligt van drie weken terug. Het verschil tussen de terugverdiende waarde en de werkelijke kosten is bijna twee ton! Met andere woorden: er is voor circa 90.000 euro geleverd, maar de opdrachtgever heeft er meer dan 280.000 euro 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 tussenresultaat 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.000 euro. 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 het percentage gereed. Ook dit is een kwestie van ervaring hoe hiermee om te gaan. Een bijkomend voordeel van het gebruik van de EVM is de mogelijkheid om de betrouwbaarheid en de ervaring van een projectmanager te beoordelen.

Afgeleide kentallen

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 productieomgeving 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 voor- waarden kunnen worden afgeleid van eerder genoemde 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 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.

Meetbare kwaliteit

Het meten van de kwaliteit in een ICT-project is best lastig, maar niet onmogelijk. Het is vooral afhankelijk van de manier waarop een project wordt georganiseerd. Het gaat om de beoordeling van (deel-) systemen die een bepaald bedrijfsproces ondersteunt. Ook hierbij is de splitsing in deelactiviteiten volgens de WBS een hulpmiddel. Ook bij hardware is de kwaliteit moeilijk te bepalen. Wat is het kwaliteitsverschil tussen een laptop van een A-merk en een B-merk? 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 speelt de eigen ervaring mee. Objectiviteit is in dat geval ver weg. Toch is het ook bij een ICT-project mogelijk een redelijk betrouwbaar beeld te krijgen van de kwaliteit van een (deel)systeem. Het heeft vooral te maken met de vraag of aan de verwachtingen wordt voldaan. Zoals 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. Er is bijvoorbeeld een groep van ontwerpers die een functioneel ont- werp 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. Met dit laatste voorbeeld heeft een opdrachtgever zelf direct te maken. De belanghebbende is in dit geval de opdrachtnemer of projectmanager en die zal een belangrijke stem hebben in het bepalen van de kwaliteit van de businesscase. (Een 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, moet zowel het investeringstraject als het project zo georganiseerd 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 eerder genoemd principe en de verantwoordelijkheid van de projectmanager. Het eindresultaat van het project is onderdeel van een investeringstraject en moet beoordeeld worden in relatie tot de businesscase: de verant- woordelijkheid van de opdrachtgever. Te vaak gebeurt 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 de opdrachtgever van nut zijn.

Veel voordelen

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. 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 projectmanagementhandboek³. 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. 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 ervoor 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 voor- delen. 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. Een 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 kan een opdrachtgever beoordelen of zijn projectmanager de benodigde kennis en ervaring heeft een project goed te beheersen. Dat is zeker belangrijk als je weet dat uit onderzoeken blijkt dat slecht projectmanagement nog altijd in meer dan dertig procent van de projecten een van de belangrijkste oorzaken is van forse budgetoverschrijding. En dus is het de verantwoordelijkheid van een opdrachtgever om in te grijpen.

Literatuur

• ¹)  Prince2 kent het begrip Product Breakdown Structure. In feite is dit hetzelfde als een WBS onder de voorwaarde dat elke activiteit gekoppeld is aan een concreet resultaat. Zelf prefereer ik de term WBS.
• ²)  zie ook “Het voorkomen van onduidelijkheid in facturen IT-leverancier - 6 aanbevelingen” - Wortmann en Kremer - Financieel Management, 29 november 2013.
• ³) bijvoorbeeld “The Handbook of Project-Based Management” - J. Rodney Turner - McGraw-Hill, 1999