You must establish a project baseline, determine the points of management control, and formalize and authorize the Control Account Plans (CAPs) — je moet een projectbasislijn vaststellen, de punten van beheercontrole bepalen en de CAP's van het controlerekeningenplan formaliseren en autoriseren.

De Control Account Plan als bouwsteen

Een Control Account (CAP) is een generiek type prestatiecontroledocument dat wordt opgesteld, bewaakt en gemeten om het werk te beheersen. Het CAP is essentieel als deelproject — een controlepunt waarop de projectmanager zich tijdens de uitvoering richt. De CAP is in Earned Value de fundamentele bouwsteen die de meting van het project vormt. Elk CAP beheert een eigen WBS.

Dit is precies het punt waar de vorige pijlers samenkomen. We zagen dit eerder al bij Pijler 2 en Pijler 4: waar een WBS-element en een organisatie-eenheid elkaar kruisen, ontstaat een Control Account, gevuld met een budget en een tijdsbestek. Pijler 6 formaliseert dat punt — het legt vast dat dit controlepunt bestaat, wie het beheert en bevriest het als officieel onderdeel van de basislijn.

Praktijkvoorbeeld: een echte CAP

Onderstaand voorbeeld komt uit een project waar ik in 2014 aan heb gewerkt: een Control Account Plan voor de discipline piping-prefabricatie, met twaalf systemen als afzonderlijke werkpakketten binnen één

CAP

CAP.

Het totaal oogt mild: een CPI van 0,96 betekent een lichte onderprestatie, geen reden tot paniek. Maar daaronder schuilen werkpakketten die ernstig uit de hand liepen — System 23 (Potable Water) met een CPI van 0,45 en System 42 (Fire Protection) met 0,50 — terwijl andere systemen, zoals System 35 (MV Generator) met 1,89, juist ruim boven budget presteerden en het gemiddelde optrokken.

Dit is precies waar een CAP zijn waarde bewijst. Zonder deze onderverdeling zou het project op "0,96, lichte afwijking, geen actie nodig" zijn beoordeeld. Met deze onderverdeling wordt zichtbaar dat twee specifieke werkpakketten structureel verlieslatend zijn en gerichte aandacht nodig hebben — terwijl de rest van de discipline er prima voor staat. Een geaggregeerde CPI op projectniveau maskeert dit soort problemen stelselmatig; pas op het niveau van de CAP en de daarbinnenliggende werkpakketten wordt het stuurbaar.

Deze CAP trackt bovendien op het eerste, meest beperkte verantwoordingsniveau uit de lijst hierboven: alleen directe arbeidsuren (manuren), zonder kosten. Dat is een bewuste, legitieme keuze — maar wel een die vastligt vóórdat je de basislijn bevriest, niet iets wat je achteraf nog even aanpast.

Een absolute vereiste: consistente codering

Er schuilt in dit voorbeeld een vereiste die makkelijk over het hoofd wordt gezien, maar zonder welke geen enkele CAP betrouwbaar is: de coderingen die je gebruikt moeten identiek zijn aan alle andere coderingen in de rest van je systemen.

In de tabel hierboven komen PV en EV uit Primavera P6, maar de werkelijk bestede uren (AV) komen doorgaans uit een heel ander systeem — een ERP-pakket waarin de uren worden ingevoerd en geregistreerd. Zodra dat systeem andere werkpakket- of activiteitscodes hanteert dan P6, wordt het onmogelijk om AV correct te koppelen aan de juiste CAP. Je kunt dan nog wel drie keurige kolommen met getallen tonen, maar ze meten niet meer hetzelfde ding — en daarmee is betrouwbare Earned Value simpelweg niet meer mogelijk.

Voor veel bedrijven is dit een serieuze uitdaging. Planningsafdeling, kostenbeheersing en de financiële/ERP-administratie ontstaan vaak op verschillende momenten, met verschillende tools en coderingslogica, zonder dat vooraf is afgesproken dat deze moeten aansluiten. Tegen de tijd dat Earned Value wordt geïntroduceerd, blijkt het herstellen van die consistentie achteraf een project op zich — vaak ingrijpender dan het opzetten van de CAP's zelf.

Drie niveaus diep: van CAP tot vakgebied

"Dezelfde codering" is geen eenmalige afspraak op CAP-niveau — de eis loopt door tot het niveau waarop je daadwerkelijk uren registreert. In het voorbeeld hierboven betekent dit drie geneste niveaus:

1. De hoofd-CAP — in dit geval piping-prefabricatie als geheel.
2. De onderverdeling per werkpakket — de afzonderlijke systemen uit de tabel (System 02, System 09, enz.).
3. Het vakgebied binnen elk werkpakket — bijvoorbeeld branders, afkorters, pijpfitters en pijplassers.

Pas op dit derde niveau zijn de werkelijk bestede manuren betrouwbaar herleidbaar: niet alleen "hoeveel uur aan System 23", maar ook "ok hoeveel door pijpfitters aan System 23." Primavera P6 moet deze codering overnemen in zijn WBS, RBS (Resource Breakdown Structure) en OBS, en het kostenbeheersingssysteem moet dezelfde structuur aanhouden tot in het grootboek. Pas dan sluiten planning, uren en kosten op elk niveau naadloos op elkaar aan.

Eén vakgebied verdient een aparte vermelding omdat het zich niet laat bewaken als de andere: intern transport — het verplaatsen van materiaal tussen werkplekken. Dit is in de praktijk niet goed per activiteit te registreren en wordt daarom niet als apart vakgebied met eigen directe uren meegenomen, maar als vaste opslag over alle gewerkte uren heen — in dit type project doorgaans rond de 1,5%.

Je hoeft het wiel niet zelf uit te vinden

Dit coderingsprobleem is niet nieuw, en verschillende sectoren hebben er eigen formele standaarden voor ontwikkeld — het is de moeite waard om te weten dat ze bestaan, ook als je uiteindelijk je eigen structuur opzet:

1. NORSOK Z-014 (SCCS), uit de Noorse olie- en gasindustrie, splitst de codering op in drie samenhangende subsystemen: PBS (Physical Breakdown Structure, de fysieke indeling van de installatie), SAB (Standard Activity Breakdown) en COR (Code of Resources) — in de kern dezelfde drieslag als CAP, werkpakket en vakgebied in dit voorbeeld.
2. CROW/SSK, de Standaardsystematiek voor Kostenramingen, is de Nederlandse standaard voor kostenramingen in de GWW-sector (grond-, weg- en waterbouw), voorgeschreven door gemeenten en Rijkswaterstaat.
3. NL/SfB is een viercijferige elementcodering voor bouwonderdelen, afkomstig uit Zweden en in Nederland onder meer voorgeschreven in de BIM-standaard van het Rijksvastgoedbedrijf.
4. CSI MasterFormat, uit de Verenigde Staten en Canada, organiseert bestekken in (inmiddels) vijftig divisies per vakgebied of bouwonderdeel.

Geen van deze standaarden lost het probleem automatisch op — je moet ze nog altijd consequent doortrekken tot in P6, het ERP-systeem en het grootboek. Maar ze laten zien dat dit geen kwestie van bedrijfsspecifieke pech is: elke sector die met Earned Value serieus wil werken, is op hetzelfde fundamentele punt gestuit en heeft er een formele oplossing voor moeten bedenken.

Deze mate van detaillering kost moeite om op te zetten, maar levert meer op dan alleen betrouwbare EVM tijdens de uitvoering. Een consequent doorgevoerde codering tot op vakgebiedniveau bouwt gaandeweg een database op van werkelijke productiviteit per vakgebied, per type systeem — de basis voor een betrouwbare nacalculatie en voor scherpere ramingen op het volgende project.

De Performance Measurement Baseline

Een basislijn waartegen prestaties kunnen worden gemeten is een essentiële vereiste van Earned Value Project Management. De Performance Measurement Baseline (PMB) is het referentiepunt waaraan een project zijn daadwerkelijk volbrachte werk koppelt. Ze maakt bekend of het project zijn geplande planning volgt en hoeveel werk wordt verricht in verhouding tot het uitgekeerde geld.

Zonder PMB heb je wel cijfers — uren geschreven, facturen betaald, percentages ingeschat — maar niets om ze tegen af te zetten. De PMB zet die losse cijfers om in een oordeel: lopen we voor, achter, binnen budget of erboven.

Verantwoordingsniveaus: hoeveel kostenverantwoordelijkheid draagt de projectmanager?

Er zijn veel verschillende manieren waarop projectmanagers verantwoordelijk worden gehouden voor verschillende niveaus van kostenprestatie. De volgende gebieden worden onderscheiden, oplopend in reikwijdte:

1. Alleen directe arbeidsuren
2. Directe arbeidsuren binnen specifieke arbeidscategorieën
3. Directe arbeidskosten (uren én directe arbeid in totaal, via overheidstoepassingen)
4. Kosten voor materialen en onderaanneming
5. Overige directe kosten (zoals reiskosten)
6. Alle projectkosten (via algemene en administratieve toeslag)
7. Alle projectkosten inclusief winst — de volledige contractprijs

Veel projectmanagers dragen min of meer de verantwoordelijkheid voor het beheer van alle categorieën projectkosten. Daarom moet de prestatiebasislijn worden afgestemd op de bedrijfsorganisatie: een CAP die is ingericht op niveau 2 (arbeidscategorieën), terwijl de projectmanager feitelijk op niveau 6 wordt afgerekend, meet het verkeerde ding voor de verantwoordelijkheid die daadwerkelijk wordt gedragen.

De basislijn bijhouden: wijzigingen beheren

Het instellen van een vaste basislijn, gebaseerd op een overeengekomen werkomvang, is waarschijnlijk de belangrijkste actie die van elk projectteam wordt gevraagd. Daarmee is de noodzaak voor de projectmanager om een effectieve wijzigingsbeheerprocedure in te voeren, waarmee het project voorgestelde wijzigingen kan goedkeuren of afwijzen op basis van een weloverwogen besluit van het projectteam.

Om veranderingen effectief te beheren, moet een project alle druk bijhouden om — opzettelijk of onbedoeld — van richting te veranderen. Het beheren van een basislijn vereist zowel informatie als een systeem om die informatie op te halen. Elke actie die de goedgekeurde basislijn wijzigt of mogelijk kan wijzigen, moet zorgvuldig worden vastgelegd, zodat de projectmanager bewust kan beslissen om elke wijziging goed te keuren of af te wijzen.

Het beheren van alle wijzigingen in de projectomvang, op het moment dat ze zich voordoen, is essentieel om de goedgekeurde projectbasislijn te handhaven — en noodzakelijk om het concept van Earned Value überhaupt toe te passen. Een basislijn die ongemerkt meebeweegt met elke informele scopewijziging is geen basislijn meer; ze is dan een bewegend doel waartegen je niets zinnigs meer kunt meten.

De link met de voorgaande pijlers

Pijler 6 is de plek waar de eerste vijf pijlers formeel samenkomen tot één bevroren geheel:

1. Pijler 1 (scope/WBS) levert de werkpakketten die binnen elk CAP vallen.
2. Pijler 2 (organisatie) levert de verantwoordelijke voor elk CAP.
3. Pijler 3 (planning) bepaalt het tijdsbestek waarbinnen elk CAP wordt uitgevoerd.
4. Pijler 4 (budget) levert het geautoriseerde bedrag per CAP, zonder verborgen marge.
5. Pijler 5 (meetmethode) beschrijft hoe de voortgang binnen elk CAP wordt vastgesteld.
6. Pijler 6 (basislijn) bevriest dit alles tot de PMB en legt het wijzigingsproces vast waarmee die basislijn gecontroleerd — in plaats van ongemerkt — verandert.

Een zwakte in een van de eerdere pijlers wordt hier niet opgelost; ze wordt bevroren. Een CAP zonder realistische doorlooptijd (Pijler 3) of met een budget dat niet aansluit bij het juiste verantwoordingsniveau wordt bij het vaststellen van de basislijn niet automatisch gecorrigeerd — ze wordt onderdeel van het referentiepunt waartegen je de rest van het project meet.

Wat dit oplevert

Met een geformaliseerde PMB en een werkend wijzigingsbeheerproces heb je wat Earned Value nodig hebt om daadwerkelijk te functioneren: een stabiel referentiepunt, met een expliciete, gecontroleerde route voor elke wijziging die dat referentiepunt mag raken. Vanaf hier is de basislijn niet langer een momentopname bij de start van het project — het is het instrument waarmee je gedurende de hele looptijd beoordeelt of je nog op koers bent.