Félicitations ! Ton soutien à bien été envoyé à l’auteur
avatar
Pijler 2: Wie maakt wat — en waarom die keuze zwaarder weegt dan je denkt
Non-fiction
Technologie
calendar Publié le 8 sept. 2026
calendar Mis à jour le 8 sept. 2026
time 10 min
Label de transparence créative
Tous publics
Image / Image co-créée avec IA
Texte / Création hybride humain et IA

Pijler 2: Wie maakt wat — en waarom die keuze zwaarder weegt dan je denkt

Een project bestaat niet alleen uit werkpakketten en planningen — het bestaat ook uit mensen en organisaties die dat werk daadwerkelijk uitvoeren. Hoe de gedefinieerde werkzaamheden worden uitgevoerd, maakt echt verschil voor je project. Ervaren mensen werken doorgaans beter en sneller, maar kosten ook meer. En soms heeft je eigen organisatie simpelweg niet de ervaring in huis, of zit iedereen al vol met ander werk.


Dan staat je de make-or-buy-beslissing te wachten: doe je het zelf, of besteed je het uit? Dit lijkt een operationele vraag die je "onderweg wel oplost," maar in de praktijk is het een van de meest onderschatte strategische keuzes in een project. Veel projecten stellen die vraag te laat — pas wanneer een werkpakket op de rol staat om te starten en blijkt dat niemand de capaciteit of expertise heeft om het uit te voeren. Op dat moment is de druk hoog, de tijd kort en is de onderhandelingspositie zwak.


Het beste moment om deze vraag te beantwoorden ligt veel eerder: tijdens het opstellen van de WBS en het bepalen van de scope. Op dat moment ken je de aard van het werk al en kun je per werkpakket alvast inschatten of dit iets is dat je organisatie zelf beheerst of waarvoor je extern moet aankloppen.

De oplossing: organisatiestructuur als onderdeel van je scope-werk

Bij Pijler 2 hoort daarom het in kaart brengen van de volledige organisatiestructuur van je project: wie wat doet, inclusief de belangrijkste onderaannemers, en binnen welke organisatorische eenheden het werk straks wordt gepland en gecontroleerd.

Dit is meer dan een organogram tekenen. Het betekent dat je, werkpakket voor werkpakket, vastlegt:

  1. Wie de uitvoerende partij is (eigen team, specifieke afdeling, of externe partij)
  2. Welke expertise en capaciteit daarvoor nodig is
  3. Of die capaciteit intern beschikbaar is, of moet worden ingekocht
  4. Onder welke organisatorische eenheid de planning en controle van dat werkpakket komt te vallen


Dit werk je uit in je Project Procurement Management Plan — het document waarin je vastlegt welke producten, diensten of resultaten je van buiten je eigen team gaat betrekken, via welke contractvorm en volgens welk tijdpad.

De Procurement Matrix als hulpmiddel

De Procurement Matrix is daarbij het handigste hulpmiddel: in één overzicht is helder wie waarvoor verantwoordelijk is. In de eenvoudigste vorm koppel je per werkpakket (of WBS-element) de volgende kolommen aan elkaar:

  1. Werkpakket / WBS-code
  2. Make of buy
  3. Uitvoerende partij (interne afdeling of externe leverancier)
  4. Contractvorm (indien extern)
  5. Verantwoordelijke Control Account Manager
  6. Kritieke afhankelijkheden richting andere werkpakketten


Wat deze matrix oplevert, is niet alleen overzicht — het dwingt je vroeg in het project tot een expliciete keuze per werkpakket, in plaats van een impliciete aanname die pas zichtbaar wordt als het misgaat. Een werkpakket zonder duidelijke "make-or-buy"-beslissing is een risico dat je nog niet hebt benoemd.

Waarom dit zwaarder weegt dan je denkt

De verleiding is om make-or-buy te zien als een inkooptechnische kwestie — iets voor de procurement-afdeling, los van de planning. Dat is een vergissing. De organisatiestructuur die uit deze beslissingen voortvloeit, bepaalt direct:

  1. Wie de Control Account Manager is voor elk deel van je EVM-basislijn — je kunt geen EVA uitvoeren op een werkpakket zonder een aangewezen verantwoordelijke
  2. Welke doorlooptijden realistisch zijn — een externe partij inschakelen kost tijd voor aanbesteding, contractvorming en opstart, tijd die in je planning moet staan voordat het werk kan beginnen
  3. Waar je afhankelijkheidsrisico's zitten — een onderaannemer die ook voor andere opdrachtgevers werkt, introduceert een resource-afhankelijkheid die je eigen team niet heeft

Weet je dit vroeg, dan bouw je je project op een organisatiestructuur die past bij wat er echt nodig is — in plaats van achteraf te ontdekken dat de verkeerde mensen aan de verkeerde onderdelen werken, of dat een cruciaal werkpakket wacht op een aanbestedingstraject dat nooit in de planning was voorzien.

De link met Pijler 1

Pijler 2 bouwt direct voort op Pijler 1: pas als scope en WBS helder zijn, kun je zinvol bepalen wie welk onderdeel uitvoert. Andersom geldt ook: als je tijdens het uitwerken van de organisatiestructuur ontdekt dat een werkpakket niet realistisch is toe te wijzen — intern niet haalbaar, extern niet tijdig beschikbaar — is dat een signaal om terug te gaan naar je WBS en de scope opnieuw tegen het licht te houden. Deze twee pijlers zijn geen lineaire stappen, maar een iteratief proces.

Praktijkvoorbeeld: make-or-buy terugvinden in een echte WBS

Onderstaand voorbeeld komt uit een offshore-platformproject (activiteiten geëxporteerd vanuit Primavera P6). Iemand had hier al een poging gedaan om Pijler 1 — de WBS-scope — vast te leggen. Wat opvalt: de make-or-buy-beslissing zit er al in verwerkt, alleen nergens expliciet als zodanig benoemd. Ze zit verstopt in de activiteitnamen en -codes zelf.


"Make" — uitgevoerd door het eigen uitvoeringsteam

De installatieactiviteiten op de verschillende dekken (bijvoorbeeld "Install major pipe work sub-cellar deck", "Install & fix cellar deck") en het engineeringwerk ("Shop drawings & Production Engineering Jacket") vormen het "make"-deel: werk dat de eigen organisatie plant, uitvoert en controleert.


"Buy" — expliciet als subcontract benoemd

Een aantal activiteiten is letterlijk als uitbesteed werkpakket in de WBS opgenomen:

Activiteit Aard

Subcontract E&I, F&G, Telecomm uitbesteed werkpakket

Subcontract Piping Uitbesteed werkpakket

Subcontract HVAC Uitbesteed werkpakket

Subcontract Architectural Uitbesteed werkpakket

Subcontract Painting Uitbesteed werkpakket

Subcontract Scaffolding Uitbesteed werkpakket

Subcontract Load-out & major heavy handling Uitbesteed werkpakket


"Buy" — procurement van materialen en equipment.

Los van het uitbesteed uitvoeringswerk staat er een aparte reeks van ruim zestig procurement-activiteiten (herkenbaar aan de codeprefix in dit voorbeeld) voor de inkoop van materiaal en apparatuur: constructiestaal, pijpleidingmateriaal, kleppen, pompen, vaten, HVAC-units. Dit is de zuivere "buy"-kant: dingen die worden aangeschaft, niet werk dat wordt uitbesteed — een onderscheid dat in een Procurement Matrix apart verdient te worden opgenomen, omdat de risico's (levertijd, kwaliteitscontrole bij ontvangst) anders liggen dan bij een uitbesteed werkpakket.


Leverancier zichtbaar tot op activiteitniveau

Sommige activiteiten in deze WBS hebben de naam van de leverancier of onderaannemer er zelfs letterlijk bij staan — bijvoorbeeld bij de kleppen (herkenbaar aan de merknaam in de activiteitnaam) en bij een aantal specialistische hijs- en transportactiviteiten rond het laden en verschepen van de jacket (herkenbaar aan een terugkerende afkorting in die activiteitnamen). Dat is in feite een informele, ad hoc Procurement Matrix — verspreid over losse activiteitnamen in plaats van samengebracht in één overzicht.


Wat dit voorbeeld leert

Als doel om hiervan een echte planning te maken — met procurement en alle te kopen of te maken onderdelen scherp onderscheiden — is de eerste stap simpel: label iedere activiteit met "make" of "buy", en splits "buy" verder op in "uitbesteed werkpakket" versus "in te kopen materiaal/equipment". Doe je dat niet, dan blijft die informatie verstopt in vrije tekstvelden — bruikbaar voor wie de planning kent, maar onzichtbaar voor rapportage, resourceplanning of het EVM-basislijnwerk dat er straks op moet aansluiten.

Van identificatie naar een werkbare Procurement-WBS

Het labelen van make en buy is de eerste stap. De volgende stap — die ik in de praktijk vaak samen met inkopers heb doorlopen — is om die labels om te zetten in een echte WBS-structuur waarop je kunt sturen en rapporteren.


De tagcode vertelt je de categorie

Een nuttig inzicht hierbij: de tagnummers van getagde equipment-items volgen al een classificatiestandaard. P staat voor pomp, V voor vessel/vat, T voor tank, X voor veiligheidssysteem en Q voor overige skids en modules. Je hoeft dus niet te bedenken hoe je procurement-items groepeert — de tagcode geeft die indeling al aan. Door PS-activiteiten te groeperen per lettercode (X-items, T-items, Q-items, V-items, P-items) ontstaat een sub-WBS die direct aansluit bij hoe engineering en inkoop de installatie al benoemen.


Een aparte tak voor "Tagged items"

In plaats van make/buy alleen als kolom te labelen — zoals in het eerdere Excel-voorbeeld — kun je het ook als aparte WBS-tak structureren binnen je planningstool. Een knoop "Tagged items" met daaronder de subgroepen per lettercode geeft elke categorie een eigen plek voor mijlpalen, eigen rapportagemogelijkheden en een duidelijk aanspreekpunt om leverdatums per equipmentgroep te bewaken — precies waar inkopers behoefte aan hebben wanneer zij per categorie moeten rapporteren over bestel- en levertijden.


Het is een iteratief proces, geen eenmalige exercitie

Een procurement-WBS bouw je zelden in één keer goed. Naarmate scope en engineering vorderen, komen er nieuwe getagde items bij, verschuiven bestaande items van categorie, of blijkt een eerder als "make" bestempelde activiteit toch te moeten worden uitbesteed. Dat is geen falen van de eerste opzet — het is de reden waarom Pijler 2 iteratief blijft, ook nadat de eerste versie van je Procurement Matrix al in gebruik is.


Een blik op de formele kant

Wie deze structuur doortrekt, komt vanzelf uit bij een kernbegrip uit de formele EVM-literatuur: het snijpunt van je WBS en de organisatiestructuur (OBS) definieert het Control Account — de plek waar scope, planning en budget samenkomen onder één verantwoordelijke. De DCMA-richtlijnen (zie ook de eerdere sectie over EVMS) werken dit tot in detail uit. Voor nu is het voldoende om te weten dát dit snijpunt bestaat; hoe je Control Accounts precies inricht, is genoeg stof voor een aparte pilaar verderop in deze serie.

Jan van den Berg

Propriété intellectuelle et crédits
© Texte principal Jan Van Den Berg
Gestion des licences Creative Commons
cc_by_nc_nd
Crédit requis, pas de modifications, usage non commercial uniquement CC BY-NC-ND

Commentaire (0)

Tu dois être connecté pour pouvoir commenter Se connecter
Prolonger le voyage dans l'univers Technologie

donate Tu peux soutenir les auteurs qui te tiennent à coeur

promo

Télécharge l'application mobile Panodyssey