De meest praktische WBS-gids voor digitale projectteams

Typen werkverdelingsstructuren

Het is goed om te weten dat er twee manieren zijn om een WBS te maken: meestal op basis van opleveringen of als alternatief op basis van projectfasen. 

• Opleveringsgerichte werkverdelingsstructuur: Ook bekend als entiteitsgerichte, zelfstandig-naamwoordgerichte of productgerichte structuur. Dit is de meest voorkomende variant.
• Fasegerichte werkverdelingsstructuur: Richt zich in plaats daarvan op de taken die nodig zijn om die opleveringen te voltooien. Andere benamingen die je hiervoor kunt tegenkomen zijn activiteitgericht, taakgericht, werkwoordgericht of procesgericht.

Voor de meeste digitale, software- en cross-functionele projecten is een opleveringsgerichte WBS meestal de betere keuze. Deze houdt teams gericht op resultaten in plaats van op losstaande activiteiten, waardoor het eenvoudiger wordt om de omvang te beheren, belanghebbenden op één lijn te brengen en de voortgang te volgen binnen product-, technische, ontwerp- en operationele teams.

Hoe ziet een werkverdelingsstructuur eruit?

Zo ziet deze er vaak uit:

Naarmate je verder afdaalt in de hiërarchie, wordt het werk specifieker en eenvoudiger in te schatten, toe te wijzen, in te plannen en te monitoren. Een goed gestructureerde WBS helpt teams ook om afhankelijkheden tussen taken vroegtijdig te identificeren, waardoor het risico op gemist werk, overlappende verantwoordelijkheden en onrealistische tijdlijnen kleiner wordt.

Belangrijke termen voor werkverdelingsstructuren

Voordat we dieper ingaan op het onderwerp, volgen hier enkele belangrijke termen die je in deze handleiding zult tegenkomen:

• Referentiepunt: De goedgekeurde versie van de omvang, planning of begroting van een project die wordt gebruikt om prestaties en voortgang te meten.
• Mijlpaal: Een belangrijk controle- of voltooiingspunt in de projectplanning, zoals goedkeuring door belanghebbenden of het einde van een belangrijke fase.
• Kritiek pad: De reeks afhankelijke taken die de kortst mogelijke doorlooptijd voor het voltooien van het project bepaalt. Vertragingen in activiteiten op het kritieke pad hebben rechtstreeks invloed op de opleverdatum van het project.

WBS versus projectplanning versus Gantt-diagram

Een werkverdelingsstructuur wordt vaak verward met een projectplanning of Gantt-diagram, maar ze hebben verschillende doelen. Een WBS bepaalt welk werk moet worden voltooid, terwijl een projectplanning bepaalt wanneer dat werk plaatsvindt en in welke volgorde. Gantt-diagrammen bouwen voort op de WBS door taken, doorlooptijden, mijlpalen en afhankelijkheden in een tijdlijn weer te geven.

Waarom is een werkverdelingsstructuur belangrijk?

Een WBS houdt je project stevig verankerd in de realiteit. Zonder WBS ontstaat al snel ongecontroleerde uitbreiding van de projectomvang—teams missen opleveringen, planningen lopen uit en niemand is het eens over hoe "klaar" eruitziet. Met een solide WBS kun je inspanningen nauwkeurig inschatten, verantwoordelijkheden duidelijk toewijzen en hiaten opsporen voordat ze blokkades worden. Voor technische en digitale teams die product-, engineering- en ontwerpwerk combineren, is dit vaak het verschil tussen een gecontroleerde oplevering en chaos.

Gebruik dit overzicht om te begrijpen wat je wint—en welke risico’s je loopt—bij het gebruik van een WBS:

Factor	Met een WBS	Zonder een WBS
Beheersing van de projectomvang	Duidelijke grenzen voorkomen ongepland werk	Ongecontroleerde uitbreiding van de projectomvang wordt pas opgemerkt wanneer het duur wordt
Inspanningsschatting	Taken zijn voldoende gedetailleerd om ze nauwkeurig in te schatten	Schattingen zijn vaag en worden regelmatig niet gehaald
Verantwoordelijkheid	Elke oplevering heeft een duidelijke eigenaar	Eigenaarschap is onduidelijk tussen teamleden
Afhankelijkheden bijhouden	Teams kunnen blokkades in kaart brengen voordat ze optreden	Afhankelijkheden komen pas aan het licht nadat vertragingen zijn ontstaan
Afstemming met belanghebbenden	Iedereen verwijst naar dezelfde projectstructuur	Belanghebbenden hebben tegenstrijdige opvattingen over de projectomvang

Voorbeelden van werkverdelingsstructuren

Door te zien hoe een werkverdelingsstructuur er in de praktijk uitziet, wordt duidelijker hoe je deze in je projecten kunt gebruiken. Hier zijn drie sterke WBS-voorbeelden om je aanpak te ondersteunen:

Uitsplitsing van de lancering van een softwareproduct

Verdeel het werk in planning, bouw, gebruikerstesten, lanceringsvoorbereiding en ondersteuning na de lancering. Elk niveau wordt verder uitgesplitst in taken zoals het verzamelen van vereisten, het programmeren van functies, het schrijven van testgevallen, het opstellen van release-opmerkingen en het plannen van ondersteunende documentatie.

Projectstructuur voor het vernieuwen van een website

Begin met belangrijke fasen zoals verkenning, ontwerp, ontwikkeling en implementatie. Werk de activiteiten onder elke fase uit: interviews met belanghebbenden, schetsen van de gebruikersinterface, updates van de gebruikersinterface, CMS-configuratie, gebruiksacceptatietesten en migratie van de website.

Implementatie van een leerbeheersysteem

Verdeel het project in behoeftenanalyses, systeemselectie, integratie, inhoudsmigratie, training en uitrol. Werk vervolgens stappen uit zoals goedkeuring door belanghebbenden, demonstraties van leveranciers, gegevenskoppeling, het plannen van trainingssessies en toezicht na de livegang.

Stay Ahead of What Deserves Your Attention

Get timely perspective on the shifts, decisions, and trade-offs shaping your role, plus practical resources you can put to work.

Get Free Access

Have an account? Log In

Hoe gedetailleerd moet een WBS zijn?

Een WBS splitst grotere onderdelen van projectwerk op in kleinere taken. Maar wat is het juiste detailniveau om aan te houden?

Net als Goudlokje wil je zoeken naar een gulden middenweg. Te veel detail maakt je WBS onhandelbaar en moeilijk te beheren. Te weinig detail betekent dat je WBS niet de informatie bevat die je nodig hebt om je project succesvol te beheren.

Een goede vuistregel: Als het beheren van het werkpakket meer inspanning kost dan het uitvoeren van het werk zelf, heb je je WBS waarschijnlijk te ver opgesplitst. Het doel is duidelijkheid en verantwoordelijkheid—niet het creëren van administratieve overhead die je team niet zal bijhouden.

Streef naar drie detailniveaus in je WBS, maar niet meer dan vier niveaus. Net als bij andere projectmanagementdocumentatie hangt de manier waarop je je WBS opstelt af van organisatorische best practices en van de vraag of je een complex project uitvoert.

Belangrijke onderdelen van een werkverdelingsstructuur

Als je de kernonderdelen van een werkverdelingsstructuur begrijpt, kun je een projectplan opstellen dat daadwerkelijk nuttig is tijdens de uitvoering—en niet alleen georganiseerd lijkt tijdens de startbijeenkomst. Elk element speelt een specifieke rol bij het definiëren van de projectomvang, het organiseren van het werk, het toewijzen van verantwoordelijkheden en het bewaken van de voortgang.

Op te leveren resultaten

Op te leveren resultaten zijn de tastbare uitkomsten die je project moet opleveren. Dit kunnen documenten, systemen, functies, goedkeuringen of voltooide werkfasen zijn. De meeste moderne projectteams structureren een WBS rond op te leveren resultaten in plaats van activiteiten, omdat de focus daardoor op uitkomsten blijft liggen in plaats van op losstaande taken.

Bijvoorbeeld: “Voltooide inwerkworkflow” is een sterker WBS-element dan “inwerkschermen ontwerpen”, omdat het de uiteindelijke uitkomst weerspiegelt waar het team naartoe werkt.

Werkpakketten

Werkpakketten vormen het laagste niveau van een WBS. Hier wordt het werk specifiek genoeg om toe te wijzen, in te plannen en te beheren. Een werkpakket groepeert gerelateerde activiteiten die bijdragen aan een op te leveren resultaat.

Voorbeelden van werkpakketten zijn:

• Inlog-API bouwen
• CRM-integratie configureren
• Tekst voor inwerkmails schrijven

Als werkpakketten te breed zijn, worden schattingen onbetrouwbaar en wordt het onduidelijk wie waarvoor verantwoordelijk is. Als ze te gedetailleerd zijn, wordt de WBS moeilijk te onderhouden.

Controleaccounts

Controleaccounts zijn managementpunten binnen de WBS waar projectomvang, planning en kosten gezamenlijk worden bijgehouden. Ze bevinden zich boven de werkpakketten en helpen projectmanagers de voortgang over grotere delen van het werk te bewaken.

Een software-implementatieproject kan bijvoorbeeld een controleaccount gebruiken voor “gebruikersauthenticatiesysteem”, met daaronder meerdere werkpakketten voor ontwerp, ontwikkeling, testen en implementatie.

Planningspakketten

Planningspakketten zijn tijdelijke aanduidingen die worden gebruikt om gerelateerd werk te groeperen dat nog niet volledig is gedefinieerd. Ze helpen teams rekening te houden met toekomstig werk en laten ruimte voor verdere planning en opsplitsing later in de levenscyclus van het project.

Planningspakketten zijn vooral nuttig in complexe of snel veranderende projecten waarin niet elke vereiste vooraf bekend is.

Hiërarchische structuur

Een WBS gebruikt een ouder-kindhiërarchie om het werk te ordenen, van resultaten op hoog niveau tot steeds gedetailleerdere onderdelen. Het hoogste niveau vertegenwoordigt het totale project, terwijl lagere niveaus het werk opdelen in fasen, op te leveren resultaten, controleaccounts en werkpakketten.

Deze structuur helpt teams te begrijpen hoe afzonderlijke taken samenhangen met bredere projectresultaten en maakt grote projecten eenvoudiger te beheren.

Opsplitsing

Opsplitsing is het proces waarbij resultaten op hoog niveau worden opgebroken in kleinere onderdelen. Projectmanagers blijven het werk opsplitsen totdat elk werkpakket duidelijk genoeg is om effectief te schatten, toe te wijzen en te volgen.

Een op te leveren resultaat als “Website herontwerpen” kan bijvoorbeeld worden opgesplitst in:

• UX-onderzoek
• Draadmodellen
• Frontendontwikkeling
• CMS-migratie
• QA-testen

Het doel is om het werk voldoende op te splitsen om duidelijkheid te creëren, zonder onnodige administratieve lasten te veroorzaken.

Projectomvang definiëren (100%-regel)

Een van de belangrijkste WBS-principes is de 100%-regel. Deze stelt dat de WBS 100% van de goedgekeurde projectomvang moet omvatten—niet meer en niet minder.

Elk op te leveren resultaat, werkpakket en elke taak moet zonder hiaten of overlappingen kunnen worden teruggevoerd naar de totale projectomvang. Als werk niet in de WBS is opgenomen, mag het niet als onderdeel van het project worden beschouwd.

Bijvoorbeeld: Als een lokalisatie-inspanning voor een mobiele app niet in de WBS is opgenomen, kunnen teams ten onrechte aannemen dat het vertaalwerk elders wordt afgedekt.

Deze regel helpt scope creep, dubbel werk en verwarring bij belanghebbenden te verminderen.

WBS-codes

WBS-codes zijn het nummeringssysteem dat wordt gebruikt om elk element binnen de structuur te identificeren. Codes zoals 1.0, 1.2 of 1.2.3 maken het eenvoudiger om werkpakketten te verwijzen in planningen, budgetten, statusrapporten en gesprekken met belanghebbenden.

Deze identificatiegegevens worden steeds waardevoller bij grote of functieoverschrijdende projecten, waarbij teams een consistente manier nodig hebben om gerelateerd werk te volgen.

Mijlpalen

Mijlpalen vertegenwoordigen belangrijke controle- of voltooiingspunten binnen het project. In tegenstelling tot werkpakketten bevatten mijlpalen zelf geen werk: ze geven aan dat een belangrijk resultaat of een belangrijke fase is voltooid.

Voorbeelden zijn:

• Goedkeuring door belanghebbenden voltooid
• Ontwerpgoedkeuring voltooid
• Lancering van het MVP voltooid

Door mijlpalen aan je WBS te koppelen, blijft de projectrapportage verbonden met daadwerkelijke resultaten en voortgang.

Afhankelijkheden

Afhankelijkheden definiëren de relaties tussen resultaten en werkpakketten. Ze geven aan welke activiteiten moeten zijn voltooid voordat ander werk kan beginnen.

Bijvoorbeeld: Front-endontwikkeling kan afhankelijk zijn van goedgekeurde UX-ontwerpen, contentmigratie kan afhankelijk zijn van de configuratie van het CMS, of voor een API-integratie kan goedkeuring van een beveiligingsbeoordeling vereist zijn voordat de implementatie kan beginnen.

Door afhankelijkheden vroeg in kaart te brengen, kunnen teams knelpunten identificeren, werk correct inplannen en later in het project planningsconflicten verminderen.

WBS-woordenboek

Een WBS-woordenboek is een ondersteunend document dat elk element in de WBS uitgebreider definieert. Het bevat doorgaans:

• Beschrijvingen
• Toegewezen verantwoordelijken
• Acceptatiecriteria (bijv. acceptatiecriteria volgens gegeven-wanneer-dan)
• Geschatte inspanning
• Afhankelijkheden
• Doorlooptijden
• Bijbehorende resultaten

Zonder een WBS-woordenboek is je WBS vaak niet meer dan een lijst met labels. Het woordenboek biedt de context die teams nodig hebben om het werk consistent uit te voeren.

Een WBS-woordenboek is vooral nuttig voor verspreid werkende of functieoverschrijdende teams, waar aannames en onduidelijk eigenaarschap gemakkelijk tot problemen bij de oplevering kunnen leiden.

Een werkverdelingsstructuur maken

Een sterke WBS ordent niet alleen taken, maar vormt ook de basis voor scopeplanning, planning, inzet van middelen, budgettering en het volgen van het project gedurende de hele uitvoering. Volg deze stappen om een glasheldere WBS te maken:

1. Bepaal de projectscope en resultaten

Bekijk voordat je je WBS opbouwt de fundamentele projectdocumenten, zoals het projecthandvest, de opdrachtomschrijving (SOW), documentatie van vereisten en goedkeuringen van belanghebbenden. Deze documenten helpen om scopegrenzen, resultaten en succescriteria vroegtijdig te definiëren.

Begin met het identificeren van de belangrijkste resultaten die je project moet opleveren. Deze moeten staan voor de uitkomsten, systemen, goedkeuringen of resultaten die nodig zijn om het project succesvol af te ronden.

Deze fase draait volledig om duidelijkheid over de scope. Zorg er voordat je je WBS opbouwt voor dat je overeenstemming hebt bereikt over:

• Wat binnen de scope valt
• Wat buiten de scope valt
• Wie verantwoordelijk is voor elk resultaat
• Hoe “voltooid” eruitziet
• Hoe scopewijzigingen worden beoordeeld en goedgekeurd

Als je scope in deze fase onduidelijk is, zal die onzekerheid doorwerken in je planning, budget en middelenplan.

Ik vind WBS-software vooral nuttig tijdens planningsworkshops, omdat functieoverschrijdende teams een visuele boomstructuur veel gemakkelijker kunnen beoordelen dan een spreadsheet kunnen doorgronden.

2. Deel resultaten op in kleinere werkpakketten

Zodra je opleveringen zijn gedefinieerd, splits je ze op in zogenaamde werkpakketten. Ga door met het opsplitsen van het werk totdat elk pakket specifiek genoeg is om het effectief te kunnen inschatten, toewijzen, plannen en uitvoeren.

Een oplevering als “Websiteherontwerp” kan bijvoorbeeld worden opgesplitst in:

• UX-onderzoek
• Wireframes
• Front-endontwikkeling
• CMS-migratie
• QA-testen

Als algemene regel geldt dat werkpakketten ten minste meerdere uren werk moeten vertegenwoordigen, maar niet zo gedetailleerd mogen worden dat de WBS moeilijk te onderhouden wordt.

3. Orden het werk en breng afhankelijkheden in kaart

Organiseer de taken nadat je het werk hebt opgesplitst in de volgorde waarin ze moeten worden uitgevoerd. Hier worden afhankelijkheden cruciaal.

Bijvoorbeeld:

• Front-endontwikkeling kan afhankelijk zijn van goedgekeurde wireframes
• Contentmigratie kan afhankelijk zijn van de CMS-configuratie
• QA-testen kan afhankelijk zijn van de voltooiing van functies

Door afhankelijkheden vroeg in kaart te brengen, kun je knelpunten identificeren, planningsconflicten verminderen en een realistischer opleveringstijdlijn opstellen.

4. Schat de inspanning in en wijs middelen toe

Zodra de structuur staat, schat je de benodigde inspanning voor elk werkpakket in. Werk waar mogelijk samen met de mensen die het werk uitvoeren—nauwkeurige inschattingen worden zelden in afzondering gemaakt.

In deze fase moet jij (of je middelenmanager) ook:

• De vereiste vaardigheden identificeren
• Verantwoordelijken toewijzen (rekening houdend met de beschikbaarheid van middelen)
• De capaciteit van het team beoordelen
• Mogelijke problemen met overtoewijzing signaleren

Een goed gestructureerde WBS maakt middelenbeheer en planning aanzienlijk eenvoudiger, omdat het werk al is georganiseerd in duidelijk gedefinieerde eenheden.

Gebruik deze tabel om te begrijpen hoe de WBS-structuur de beslissingen over middelen op elk niveau vormgeeft:

WBS-niveau	Voorbeeldelement	Activiteit voor middelenplanning
Niveau 1	Volledig project	Totale personeelsbezetting en budgettoewijzing
Niveau 2	Fase van functieontwikkeling	Teamtoewijzing per discipline
Niveau 3	Front-endontwikkeling	Geschat aantal uren van individuele medewerkers
Niveau 4	Navigatiecomponent bouwen	Specifieke ontwikkelaar toegewezen, inspanning bevestigd

5. Stel de projectplanning op

Je WBS vormt de basis van je projectplanning. Elk werkpakket kan nu worden vertaald naar geplande taken met doorlooptijden, afhankelijkheden, verantwoordelijken en deadlines.

Houd bij het opstellen van je planning rekening met het volgende:

• Wijs realistische doorlooptijden toe
• Orden taken logisch
• Identificeer het kritieke pad
• Valideer de timing van mijlpalen
• Bevestig de verwachtingen rond de oplevering met belanghebbenden

Een planning die is opgebouwd vanuit een gedetailleerde WBS is veel betrouwbaarder dan een planning die alleen is gebaseerd op aannames op hoofdlijnen.

6. Stel de projectreferentie vast

Zodra de scope, planning en het budget zijn goedgekeurd, stel je de projectreferentie vast. Dit wordt het referentiepunt dat je gedurende de hele levenscyclus van het project gebruikt om de prestaties te meten.

Je WBS ondersteunt rechtstreeks:

• De scope-baseline
• De planningsbaseline
• De kostenbaseline

Elke goedgekeurde wijziging in de projectscope moet eerst in de WBS worden verwerkt voordat planningen of budgetten worden bijgewerkt. Als belanghebbenden halverwege het project een nieuw rapportagedashboard goedkeuren, moeten zowel de WBS als de planningsbaseline worden bijgewerkt voordat het werk begint.

Gebruik deze tabel om te zien hoe de drie baselines met je WBS samenhangen:

Type baseline	Wat deze bijhoudt	Verbinding met de WBS
Scope-baseline	Goedgekeurde opleverproducten en werkpakketten	Rechtstreeks afgeleid van de WBS
Planningsbaseline	Goedgekeurde start- en einddatums	Opgebouwd uit werkpakketten en afhankelijkheden van de WBS
Kostenbaseline	Goedgekeurd budget per werkpakket	Opgeteld uit kostenramingen op WBS-niveau

7. Beoordeel het plan met belanghebbenden en het projectteam

Voordat de uitvoering begint, bespreek je de voltooide WBS en het projectplan met je team en belanghebbenden om overeenstemming te bevestigen en draagvlak te creëren.

Als je team het niet eens is met de taakramingen in de WBS, zul je er niet succesvol mee kunnen werken tijdens de uitvoering. Neem de tijd om de werkverdelingsstructuur met je team te bespreken, zodat je overeenstemming en verantwoordelijkheid bevordert.

Deze beoordeling helpt bij het valideren van:

• Volledigheid van de opleverproducten
• Logica van de volgorde
• Personeelsaannames
• Haalbaarheid van de planning
• Duidelijkheid over verantwoordelijkheden

Hiaten vroeg opsporen is aanzienlijk eenvoudiger dan ze tijdens de oplevering proberen te corrigeren.

Een werkverdelingsstructuur gebruiken

Een WBS levert alleen iets op als je deze na de startbijeenkomst blijft gebruiken. Gebruik de WBS voor deze zes taken:

1. Houd de WBS zichtbaar

Prik de weergave van één pagina (niveaus 1 en 2) in je projectomgeving, je statusformat en je startpresentatie. Bewaar de details van niveau 3 en 4 voor het team. Als mensen de WBS niet binnen tien seconden kunnen vinden, wordt deze niet gebruikt.

2. Gebruik de WBS als controle van je scope

Wanneer er een verzoek binnenkomt, stel je één vraag: staat het in de WBS? Zo ja, dan is het gepland werk. Zo nee, dan is het een wijzigingsverzoek, geen gunst. Leg het vast, maak een inschatting en laat zien wat er verschuift. “Ja, en dit komt ervoor in de plaats” wordt veel beter ontvangen dan een simpel nee.

3. Rapporteer per opleverproduct, niet per taak

Leidinggevenden willen niet horen dat er 47 tickets in behandeling zijn; ze willen weten of het afrekenproces klaar is. Rol de status op naar het niveau van het opleverproduct. Probeer de 0/100-regel om de gevreesde “90% klaar” die drie weken duurt te voorkomen: een werkpakket is 0% voltooid totdat het af is, en daarna 100%. Het is kort door de bocht, maar wel eerlijk.

4. Controleer de capaciteit per werkpakket

Elk werkpakket heeft een eigenaar, zodat je kunt zien wie overbelast raakt voordat dit een crisis wordt. Als één ontwikkelaar vijf werkpakketten heeft die in dezelfde week moeten worden opgeleverd, is dat een gesprek dat je nu moet voeren, niet op donderdagavond voordat de lancering plaatsvindt.

5. Werk de WBS bij vóór de planning

Wanneer een wijziging is goedgekeurd, pas je eerst de WBS aan en daarna de planning en het budget. Als je alleen de planning bijwerkt, is de WBS niet langer de bron van waarheid en wordt de 100%-regel stilletjes doorbroken.

6. Sluit de cirkel wanneer het project eindigt

Vergelijk de geschatte en werkelijke inspanning per werkpakket. De verschillen laten zien waar je ramingen te hoog of te laag uitvallen. Sla de opgeschoonde WBS vervolgens op als sjabloon voor het volgende vergelijkbare project, zodat je met een voorsprong begint in plaats van met een lege pagina.

Sjabloon voor een werkverdelingsstructuur

Om je op weg te helpen, vind je hier een gratis te downloaden WBS-sjabloon. Download het bestand als XLSX-bestand en gebruik het in Google Spreadsheets of Excel om het te bewerken. Het bestand bevat ook een voorbeeld-WBS die je als model kunt gebruiken.

Platforms voor projectmanagement

Platforms voor projectmanagement met ingebouwde ondersteuning voor hiërarchieën stellen je in staat om je WBS rechtstreeks om te zetten in een uitvoerbaar leveringsplan. Wanneer je werkpakketten zich in dezelfde tool bevinden die je team voor de uitvoering gebruikt, is het risico veel kleiner dat de WBS niet meer overeenkomt met het daadwerkelijke projectwerk.

Deze platforms zijn vooral nuttig voor:

• Het bijhouden van eigenaarschap
• Beheer van mijlpalen
• Het in kaart brengen van afhankelijkheden
• Resourceplanning
• Voortgangsrapportage

Veelgestelde vragen over werkuitsplitsingsstructuren

Dit zijn de vragen die ik het vaakst hoor van projectmanagers die hun eerste WBS opstellen of meer uit hun bestaande WBS willen halen:

Wie gebruikt een WBS?

Projectmanagers, PMO’s en projectteams gebruiken een werkuitsplitsingsstructuur om projectwerk te definiëren, toe te wijzen en bij te houden. Projectmanagers stellen deze op en onderhouden hem, terwijl technische teamleiders, ontwerpers en QA hem gebruiken om werkpakketten te bevestigen en ramingen op redelijkheid te controleren. Resourcemanagers gebruiken hem om capaciteit te plannen, financiële teams gebruiken hem om de kostenbaseline samen te voegen en leidinggevenden, klanten en leveranciers gebruiken de bovenste niveaus ervan om overeenstemming te bereiken over de scope en de opleveringen te volgen.

De WBS vindt zijn oorsprong in overheids- en defensieprogramma’s en is standaard in de bouw en engineering. Hij is net zo nuttig in software-, marketing- en bureauprojecten: overal waar het werk meerdere disciplines omvat.

Moet ik een werkuitsplitsingsstructuur of een Gantt-diagram gebruiken?

Zoals bij de meeste dingen luidt het antwoord: dat hangt ervan af.

Wanneer gebruik je een WBS?

Een WBS splitst wat je bouwt op in kleinere, beter beheersbare onderdelen. Hij laat zien wat je in een project doet. Daarom is de WBS nuttig voor scopebeheersing, waaronder verandermanagement.

Wanneer gebruik je een Gantt-diagram?

Een Gantt-diagram laat daarentegen zien wanneer je het werk doet. Gebruik je WBS als basis voor je Gantt-diagram om taken in de tijd te volgen. Het Gantt-diagram toont de start- en einddatum van elke taak, de afhankelijkheden en de onderlinge relaties. Je gebruikt een Gantt-diagram voor planningsbeheersing.

Zijn een WBS en de kritieke-pad-methode hetzelfde?

Het kritieke pad is de lijst met essentiële projectactiviteiten die moeten worden voltooid om het project binnen de drie randvoorwaarden (tijd, budget en scope) op te leveren. Als het kritieke pad vertraging oploopt, heeft je project daar nadelige gevolgen van in een van deze drie gebieden.

De WBS organiseert projectactiviteiten en opleveringen hiërarchisch, en niet alleen de activiteiten op het kritieke pad.

Wanneer in de projectlevenscyclus moet ik de WBS opstellen?

Het is belangrijk om de WBS tijdens de projectplanningsfase op te stellen, omdat deze je helpt inzicht te krijgen in het werk dat nodig is om het project uit te voeren. De WBS is ook een belangrijke input voor de projectplanning, het budget en het risicobeheerplan; deze zijn allemaal al eerder in de projectlevenscyclus nodig.

Kan ik een werkuitsplitsingsstructuur gebruiken voor agile projecten?

Ja, een WBS werkt goed naast agile oplevering als je hem op het juiste niveau gebruikt. Definieer je opleveringen en werkpakketten op hoofdlijnen in de WBS en laat sprintplanning de uitsplitsing op taakniveau afhandelen. Zo krijg je volledig zicht op de scope zonder je team onnodig te beperken. Veel teams die digitale producten ontwikkelen gebruiken deze hybride aanpak om te voldoen aan de rapportagebehoeften van belanghebbenden en tegelijkertijd de uitvoering flexibel te houden.

Hoe ga ik om met scopewijzigingen nadat de WBS als baseline is vastgesteld?

Elke goedgekeurde scopewijziging moet leiden tot een update van de WBS voordat het werk begint. Dat betekent dat je de getroffen werkpakketten herziet, het WBS-woordenboek bijwerkt en de baseline opnieuw vaststelt als de wijziging groot genoeg is. Deze stap overslaan is een van de snelste manieren om de controle over je project te verliezen. Ik raad aan om de WBS-update als een verplichte stap op te nemen in je checklist voor wijzigingsbeheer — niet als een optionele opvolging.

Wie moet worden betrokken bij het opstellen van een werkuitsplitsingsstructuur?

De projectmanager leidt doorgaans de ontwikkeling van de WBS, maar de beste resultaten ontstaan wanneer je de mensen betrekt die het werk daadwerkelijk gaan uitvoeren. Dat betekent dat je technische teamleiders, ontwerpers, QA en andere belangrijke medewerkers tijdens het uitsplitsingsproces erbij haalt. Bij een platformmigratieproject zal je infrastructuurteam bijvoorbeeld werkpakketten identificeren waar je PM nooit aan zou denken. Hun inbreng verandert een top-downoverzicht in een plan waar het hele team vertrouwen in heeft.

 

 

n

Verbeter je projectoplevering en WBS-vaardigheden

n

Als je toegang wilt tot exclusieve bronnen, praktische WBS-sjablonen en een wereldwijd netwerk om de werkstructuur in echte projecten te beheersen, word dan lid van The Digital Project Manager Community.