product based planning in de maritieme sector (pdf) - Gert Jan Schop

Projectmanagement door Adri Platje
Adri Platje is eigenaar
van Applicon
Project-
Based Management
te Veldhoven
en heeft zich
gespecialiseerd
in het implementeren
van zakelijkeverbeterprocessen
in multiprojectorganisaties
en in het faciliteren
van programma
en project
start ups.
Ook geeft hij trainingen
en coacht
hij projectmanagers
tijdens het
uitvoeren van hun
job.
Product-Based Planning
Projectmanagement deel 3
Een beheersbare planning opstellen, kan dat? Jazeker wel. Alleen zul je dan met het opstellen van deze
planning gestructureerd te werk moeten gaan. Methodisch en integraal ontwerpen zijn de kritische
succesfactoren voor een beheersbare en robuuste planning.
Deze manier van werken lost de volgende
dagelijkse problemen op:
– U levert op tijd waardoor u een betrouwbare
partner in projecten wordt.
– U beheerst uw kosten en u zet uw resources
op een effectieve en efficiënte
manier in.
– U krijgt een betere afstemming met
de deelleveringen van toeleveranciers.
– Het kost u weinig tijd en moeite om
uw planningen aan te passen aan verstoringen,
vertragingen en dergelijke.
Onderzoek (2001) naar de best practices
in de Europese scheepsbouw benadrukt
het belang van methodisch en integraal
ontwerpen: “... the high performance
yards have de-centralized multi-level
planning systems with clearly defined
outputs on each level, a work package
approach to organization of work... The
below average yards are ineffective in
this area” [1]. De Product-Based Planning
aanpak voorziet hierin. Deze uit
2
resources
contract
mgt.
OBS
verantw.matrix
netwerk
staafdiagram
planning
mijlpalen
gateways
risico
logistiek
doelstelling
scope
organisatie
tijd kwaliteit
CPA/CPM
PERT
informatie
geld
stakeholders
C/SPEC
C/SCSC
Prince2 stammende aanpak heeft als
doel om gestructureerd een gelaagde
planning op te bouwen. Product Based
Planning biedt een fundament voor de
besturing en beheersing van de aspecten
tijd, geld en kwaliteit door een specifieke
invulling van scope management.
Aan de hand van voorbeelden wordt de
belanghebbenden
bilge deck
opgeleverd
deurtjes & luikjes
opgeleverd
klep bank SB
opgeleverd
TQM
conf.
mgt.
PBS
geïntegreerd
strategisch
detail
kwaliteitsgarantie
kwaliteitscontrole
config. mgt.
procedures
handboeken
audits
CBS
kosten-matrix
wijziging
beheer
lower deck
opgeleverd
lockers & stores
opgeleverd
klep bank BB
opgeleverd
product
support
project
support
main deck
opgeleverd
pool area
opgeleverd
jacuzzi
opgeleverd
deur dekwaskast
SB opgeleverd
Figuur 2: De PBS voor een deel van een jacht
team
building
Figuur 1: De projectmanagement beheersaspecten. Vrij naar “The Handbook of Project-Based
Management” van R. Turner.
yacht
opgeleverd
upper deck
opgeleverd
zijkant SB
opgeleverd
dek
opgeleverd
deur dekwaskast
BB opgeleverd
sun deck
opgeleverd
zijkant BB
opgeleverd
grills SB
opgeleverd
top deck
opgeleverd
achterdek
opgeleverd
grills BB
opgeleverd
meerwaarde van deze aanpak toegelicht.
Figuur 1 maakt duidelijk dat de besturing
en beheersing van de beheersaspecten
tijd, geld en kwaliteit afhangt van de
aspecten scope en organisatie. Een gestructureerde
decompositie van het project
in op te leveren producten bepaalt
de scope van het project. Het aspect organisatie
bepaalt de benodigde resources.
Scope en organisatie realiseren samen
toegevoegde waarde in de vorm
van op te leveren producten. Product-
Based Planning biedt ook houvast voor
de overige beheersaspecten maar deze
zijn in het kader van dit artikel niet belangrijk.
Het toepassen van deze techniek,
vanaf het eerste contact met een
klant, begint met scope management.
Scope management
Scope management is een proces dat
waarborgt dat de juiste hoeveelheid
werk wordt verricht, dus niet meer of
minder dan nodig, om het doel van het
project succesvol te verwezenlijken.
De techniek waarop scope management
is gebaseerd heet breakdown (decompositie).
Breakdown is een techniek waar-
SCHIP&WERF de ZEE - MEI 2007

mee een project, middels een top-down
decompositie, in steeds kleinere onderdelen
wordt opgedeeld. Een voorbeeld
van breakdown is de Product Breakdown
Structure (PBS). Een PBS is een
hiërarchische decompositie van het
eindproduct in de onderliggende
(deel)producten.
In figuur 2 is als voorbeeld het eindproduct
“yacht opgeleverd” opgedeeld in
dekken. In dit voorbeeld is het product
“sun deck opgeleverd” opgedeeld in zones
en is de zone “pool area opgeleverd”
verder uitgesplitst. Het deelproduct
“deurtjes & luikjes opgeleverd” is vervolgens
weer verder uitgesplitst in de
daaronder liggende deelproducten.
De voordelen van een dergelijke decompositie
zijn:
– Het zorgt voor een SMART definitie
van het werk dat moet worden uitgevoerd,
uitgedrukt in (deel)producten.
– Het zorgt voor duidelijk omschreven
werkpakketten die kunnen worden
gedelegeerd of uitbesteed.
– Het maakt het mogelijk om nauwkeuriger
inschattingen te doen over
de werkinhoud, de kosten en de benodigde
resources.
– Het maakt een betere besturing, beheersing
en rapportage van het project
mogelijk.
– Het zorgt ervoor dat risico’s beter
kunnen worden opgespoord en worden
beperkt.
– De breakdown sluit naadloos aan bij
het top-down specificatieproces.
Het werken met een op een PBS gebaseerde
planning heeft nog twee andere
belangrijke voordelen: voor de opdrachtgever
(klant) is het belangrijk te
weten wanneer hij bepaalde (deel)producten
opgeleverd krijgt, en voor de opdrachtnemer
kunnen aan de levermomenten
van (deel)producten factuurmomenten
worden gekoppeld.
Nadeel van de PBS is dat de logische
top-down decompositie van de PBS
geen tijdsafhankelijke relaties tussen de
(deel)producten onderling mag bevatten.
Later in dit artikel komen we hier
op terug.
Scope Management proces
Scope management begint tijdens het
eerste contact met de klant. Dit proces
heeft tot doel zo snel mogelijk inzicht te
krijgen in wat de klant precies wil. In dit
stadium is er nog geen eenduidige PBS
en de valkuil is om toch te proberen de
wens van de klant direct te vertalen in
een fysieke topologie (architectuur) van
een schip. In deze wat-bepalende fase
kan de traditionele scheepsbouw voordeel
halen door gebruik te maken van in
andere sectoren met betrekking tot
scope management opgebouwde kennis,
kunde en vaardigheden. Bijvoorbeeld
uit de professionele productontwikkeling
en ICT.
In deze sectoren verloopt het scope management
proces in drie elkaar opvolgende
stappen:
– Een functionele analyse van de functies
die moeten worden gerealiseerd
(de functionele requirements).
– De vertaling van deze functies in te
realiseren systemen en componenten
(het functioneel ontwerp).
– De technische allocatie van de te realiseren
systemen in de topologie van
het op te leveren product (het technisch
ontwerp).
Stap 1 levert de benodigde input voor
stap 2, stap 2 levert de benodigde input
voor stap 3.
Achtereenvolgens leveren deze drie
stappen de volgende drie breakdown
structuren op: de functionele breakdown
structure, de systeem breakdown
structure, en de product breakdown
structure (zie figuur 2).
De valkuil bestaat dat de specificatie
van functionele requirements wordt
overgeslagen, en dat direct een functioneel
ontwerp wordt gemaakt. Het func-
Opdrachtgever
aggregaat planning
Project Manager
detail planning
Project Team
tionele ontwerp legt vaak al voor een belangrijk
deel de (on)mogelijkheden van
het technisch ontwerp vast. Daarom is
het van wezenlijk belang om te denken
vanuit de requirements. Daar moet het
ontwerp ook steeds op getoetst worden
en daar kunnen alternatieven op worden
gebaseerd.
Zo wordt bijvoorbeeld de stuurfunctie
van een schip vertaald in een stuursysteem
en krijgen de componenten
stuurwiel en stuurmachine respectievelijk
hun plaats in de producten “stuurhuis
opgeleverd” en “stuurmachinekamer
opgeleverd”.
De voordelen van deze aanpak zijn:
– De functionele analyse borgt dat de te
realiseren systemen en componenten
daadwerkelijk de behoefte van de
klant dekken, niet meer en niet minder
dan dat;
– Er ontstaat vanaf het begin een transparante
structuur voor het opstellen
van het bestek en het contract;
– Er ontstaat een transparante topdown
structuur voor ontwikkeling en
engineering;
– Er ontstaan drie transparante topdown
structuren voor respectievelijk
de functionele specificatie, de
systeemspecificatie en de productspecificatie;
– De toenemende transparantie en
structuur maken steeds nauwkeuriger
due-dates van
hoofdmijlpalen
start- en eindtijden
van activiteiten
Figuur 3: De Project Manager als linking-pin tussen
opdrachtgever en projectteam
SCHIP&WERF de ZEE - MEI 2007 3

top-down decompositie
schattingen van benodigde resources,
tijd en geld mogelijk;
– In een vroeg stadium ontstaan er
structuren voor risicoanalyse;
– De drie breakdowns bieden transparante
structuren voor het bepalen van
kentallen.
De specifieke voordelen van de product
breakdown structure zelf zijn:
– Voor de Project Manager ontstaat er
een beheersbare en bestuurbare product
structuur (PBS) gebaseerd op de
topologie van het schip;
– Het biedt een transparantie structuur
voor de projectorganisatie;
– Het legt een solide en gestructureerde
basis voor de projectplanning;
– Het biedt een overzichtelijke structuur
voor het uitbesteden van werk
aan subcontractors;
– Er ontstaat een overzichtelijke structuur
voor testen, vrijgeven, afnemen
en commissioning.
De Project Manager
Eigenaar van de projectplanning is de
Project Manager. Hij is de linking-pin
tussen opdrachtgever en de leden van
zijn projectteam.
Tijdens de uitvoering van het project is
hij in dit spanningsveld verantwoordelijk
voor het verzorgen van de rapportage
aan de opdrachtgever op basis van
hoofdmijlpalen en het aansturen van
het projectteam met behulp van detailplanningen.
Om deze linking-pin functie mogelijk te
maken heeft de Project Manager een
4
PBS
van product G
G
aandachtsgebied 1 aandachtsgebied 2
A
F
B
Randvoorwaarden in PBS niet zichtbaar:
Product C komt na product D
Product B komt na product C
C
D
Afhankelijkheids relaties
zijn in een PBS taboe!
E
PFD
van product G
start
aandachtsgebied 1 aandachtsgebied 2
A D
Figuur 4a: Product Breakdown Structure Figuur 4b: Product Flow Diagram
F
planning nodig die hij naar believen tot
in details kan uitklappen en weer kan inklappen
tot hoofdmijlpalen.
Voor de rapportage aan de opdrachtgever
is een planning op hoofdlijnen nodig
met daarin de hoofdmijlpalen. Voorbeelden
van hoofdmijlpalen zijn: “top
deck opgeleverd”, “sun deck opgeleverd”,
zie figuur 2. Andere niet in figuur
2 genoemde hoofdmijlpalen zijn:
“launching succesvol”, “sea trials succesvol”,
“jacht overhandigd aan eigenaar”
enzovoort. Voor het besturen, beheersen
en opleveren van het project en
de communicatie met het projectteam
zijn uitgeklapte detailplanningen nodig.
Deze in- en uitklapfunctionaliteit kan
worden gerealiseerd door eerst een
planning op te zetten die gebaseerd is op
hoofdmijlpalen. Dit betekent dat de
ontwikkeling van de PBS in eerste instantie
beperkt kan blijven tot de hoofdproducten.
Deze platte PBS levert dus
het mijlpalenplan. Verdere decompositie
van de PBS tot het noodzakelijke niveau
van detaillering levert uiteindelijk
de detailplanningen.
Een PBS is een logische top-down decompositie
van het op te leveren product
in de onderliggende deelproducten.
Een PBS bevat dus geen tijdsafhankelijke
volgorderelaties. Een PBS kan
dus niet zondermeer omgezet worden in
een tijdsplanning met finish-start relaties.
Hiertoe dient de PBS eerst te worden
omgezet in een Product Flow Diagram
(PFD).
B
G
C
E
bottom-up realisatie
Work Package
van product E
Het Product Flow Diagram
Een Product Flow Diagram is de schematische
weergave van het bottom-up
engineering- en maakproces (figuur
4b), terwijl de PBS het top-down specificatieproces
omvat (figuur 4a).
In figuur 4a is een PBS gegeven waarbij
de hoofdproducten in eerste instantie
zijn geordend naar aandachtsgebieden
of naar een specifieke fasering.
Uit een analyse van deze PBS, gericht
op de realisatie, blijkt dat de start van de
ontwikkeling van product C afhankelijk
is van de oplevering van product D en is
de start van de ontwikkeling van product
B afhankelijk van de oplevering
van product C. Deze afhankelijkheden
zijn in een PBS taboe! Probeert men dit
toch dan krijgt de PBS de vorm van een
bord spaghetti.
In het PFD komen per definitie dezelfde
producten voor als in de PBS met
dien verstande dat de tekenwijze en de
betekenis daarvan in beide breakdowns
verschilt. Zo is de PBS opgebouwd uit
producten. Het PFD daarentegen is opgebouwd
uit work packages (fig 4b).
Voorbeeld: Work Package E (in het
PFD) is de hoeveelheid werk die moet
worden verzet om product E (in de
PBS) te realiseren. Wanneer deze hoeveelheid
werk is afgerond, en het product
wordt opgeleverd, passeert de aan
de work package gekoppelde mijlpaal.
Zowel het ontwikkelen van de PBS als
de omzetting naar PFD gebeurt in het
Project Start-Up Proces (zie het artikel
“Geef uw projecten een vliegende start”
E
mijlpaal:
product E
opgeleverd
SCHIP&WERF de ZEE - APRIL 2007

in SWZ van april 2007). Deze omzetting
is een iteratief proces en gebaseerd
op voortschrijdend inzicht van de betrokkenen.
Zo kan inzicht over het PFD
tot gevolg hebben dat de PBS moet worden
aangepast en verder uitgediept. De
eis dat het aantal (deel)producten in de
PBS gelijk moet zijn aan het aantal work
packages in het PFD blijft.
Detail decompositie
Structureren middels combinaties van
PBS èn PFD maakt een zichzelf herhalend
decompositieproces mogelijk. Dit
decompositieproces start op het hoogste
niveau (figuren 4a en 4b). De vraag welke
work packages in een PFD verder
moeten worden uitgewerkt kan worden
bepaald middels een risicoanalyse. In
het voorbeeld van figuur 5 zijn dit de
work packages A en D.
Voor zowel work package A als voor
work package D geldt dat zij op hun
beurt ook weer zijn opgebouwd uit kleine
brokken werk. Ook op de kleinere
brokken werk kan het principe van PBS
en PFD worden toegepast. Deze zich
herhalende detaillering (Droste effect)
kan men in principe herhalen voor zover
dat voor een praktische detaillering nodig
is.
Hier geldt het advies om de afhankelijkheidsrelaties
(finish-start-relaties) tus-
PBS en PFD van alle brokken werk
in work package A
A11
A1
A12
A
A21
A2
PBS en PFD
van alle
brokjes werk
in X
A22
sen de work packages op de lagere decompositieniveaus
niet in te tekenen
maar onder te brengen in een zogenaamde
afhankelijkheidslijst.
Netwerkplanning
Wanneer van iedere work package de
werkinhoud, de werkvorm, type resource,
kosten en de afhankelijkheden
(afhankelijkheidslijst) zijn bepaald kunnen
al deze gegevens in een netwerkplanningspakket
worden ingevoerd en kan
het totale project worden doorgerekend.
Iedere PFD is in principe een zelfstandig
activiteitennetwerk en krijgt een eigen
unieke projectnaam. Door nu een
bepaalde activiteit in het netwerk van
project X de naam van een ander project
Y te geven, worden bij het doorrekenen
van project X automatisch alle gegevens
van project Y betrokken. Alle onderliggende
gegevens worden als het ware
naar het bovenste niveau, het hoofdproject
getrokken. Dit betekent dat bij het
doorrekenen van het hoofdproject alle
onderliggende detailplanningen automatisch
worden meegenomen, zie figuur
6.
Dit naar boven trekken maakt het mogelijk
om zowel totaaloverzichten als
gedetailleerde specifieke overzichten te
maken. Door een druk op de knop genereert
het planningspakket een balken-
PFD
van product G
plan, een overzicht van mijlpalen, benodigde
resources, kostenoverzichten, enzovoort.
Samenvatting
Het toepassen van de Product-Based
Planning aanpak maakt het mogelijk
meer methodisch, integraal te ontwerpen
waardoor veel dagelijkse problemen
worden opgelost. De belangrijkste
voordelen hiervan zijn:
– Het aanpassen bij verstoringen of
veranderingen in de planning wordt
eenvoudig en is minder tijdrovend.
– De structuur van de PBS is de blauwdruk
voor de structuur van de Organisatie
Breakdown Structure (OBS),
de Cost Breakdown Structure (CBS),
van het bestek, het contract, etcetera.
– Het planningsproces is volledig geïntegreerd
en transparant met het ontwerp-
en engineeringproces.
– Het top-down specificatie- en ontwerpproces
(PBS) wordt gevolgd
door een bottom-up realisatie- en
testproces. Hiermee volgt dit proces
het beproefde V-model uit de softwareontwikkeling
[2].
– Voortgangsbijeenkomsten en de verslaglegging
daarvan kunnen overeenkomstig
de structuur van de PBS
worden gehouden en opgesteld.
– Specialistische teams krijgen hun ei-
SCHIP&WERF de ZEE - APRIL 2007 5
start
aandachtsgebied 1 aandachtsgebied 2
A D
F
B
X y
G
C
aggregaat
planning
E
finish-start relatie
afhankelijkheidslijst
D11
D12
D
D1 D2
PBS en PFD
van alle
brokjes werk
in Y
detailplanning detailplanning
PBS en PFD van alle brokken werk
in work package D
Figuur 5: De zichzelf
herhalende structuur
van decompositie (het
Droste effect)

takennetwerk
gen (detail)planning en worden niet
belast met overzichten die buiten hun
invloedsfeer liggen en voor hen niet
relevant zijn.
– De gefaseerdheid van het proces
maakt dat de fout bij het doen van
schattingen steeds kleiner wordt (proposal
50%, budget 20%, sanction 10%,
control 5% en tender 2%) [3]. Ook de
robuustheid en betrouwbaarheid van
de planningen neemt toe met het
doorlopen van het planningsproces.
6
Project Masternetwerk
Activiteitennetwerk
Figuur 6: Een geneste structuur van netwerkplanningen.
Figuur 7 en 8: Het bijhouden van de projectvoortgang aan de hand van een PFD.
– De PBS en het PFD biedt een transparante
structuur voor het opbouwen
van kentallen.
– Het Product-Based Planning proces
sluit naadloos aan bij de uitgangspunten
van de Project Start-Up.
– Product-Based Planning ondersteunt
het proces van kenniscreatie en methodisch
innoveren.
Met dank aan Jorien Enning van Jorien
Enning Communicatie Management te
niveau 1 plan
Workpackages
gate ways en/of mijlpalen
niveau 2 plannen
Activiteiten
gate ways
mijlpalen
niveau 3 plannen
taken
Hunsel voor haar ondersteuning om
van deze techniek een begrijpelijk verhaal
te maken.
Literatuur
[1] NSRP ASE, Benchmarking of European
shipyards, Industry Report, National
Shipbuilding Research Program -
Advanced Shipbuilding Enterprise,
First Marine International Limited
(2001).
[2] Bennatan, E.M., Software Project
management, McGrawHill, (1995).
[3] Turner, R., Handbook of Project-
Based Management, McGrawHill,
1999.
Dit artikel “Product Based Planning”
is het derde in een serie van
vijf artikelen over projectmanagement
in de maritieme sector.
Het volgende artikel in deze serie
gaat over multi-projectmanagement,
waarbij wordt stilgestaan bij
het probleem wanneer meerdere
projecten gebruikmaken van dezelfde
hulpbronnen. Portfolio Management
en Resource Management
staan in dit artikel centraal.
Als laatste in de serie wordt het implementeren
van (multi)projectmanagement
uitgewerkt.
SCHIP&WERF de ZEE - APRIL 2007