Projectmanagement door Adri Platje
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.
Adri Platje is eigenaar van Applicon ProjectBased Management te Veldhoven en heeft zich gespecialiseerd in het implementeren van zakelijke verbeterprocessen 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.
yacht opgeleverd
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
bilge deck opgeleverd
lower deck opgeleverd
main deck opgeleverd
upper deck opgeleverd
sun deck opgeleverd
top deck opgeleverd
pool area opgeleverd
zijkant SB opgeleverd
zijkant BB opgeleverd
achterdek opgeleverd
deurtjes & luikjes opgeleverd
lockers & stores opgeleverd
jacuzzi opgeleverd
dek opgeleverd
klep bank SB opgeleverd
klep bank BB opgeleverd
deur dekwaskast SB opgeleverd
deur dekwaskast BB opgeleverd
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
scope
netwerk staafdiagram planning mijlpalen gateways
resources
contract mgt.
risico
logistiek
PBS S geïntegreerd S strategisch S detail
organisatie tijd
kwaliteit geld
CPA/CPM PERT
informatie
C/SPEC C/SCSC
stakeholders
belanghebbenden
TQM
conf. mgt.
kwaliteitsgarantie kwaliteitscontrole config. mgt. procedures handboeken audits CBS kosten-matrix
wijziging beheer
product support
project support
2
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. ProductBased 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
team building
Figuur 1: De projectmanagement beheersaspecten. Vrij naar “The Handbook of Project-Based Management” van R. Turner.
grills BB opgeleverd
Figuur 2: De PBS voor een deel van een jacht
doelstelling
OBS verantw.matrix
grills SB opgeleverd
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-
S C H I P & 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
S C H I P & WERF de ZEE
- MEI
2007
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-
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
Opdrachtgever
aggregaat planning
due-dates van hoofdmijlpalen
Project Manager
detail planning
start- en eindtijden van activiteiten
Project Team Figuur 3: De Project Manager als linking-pin tussen opdrachtgever en projectteam
3
PFD van product G
G aandachtsgebied 1
start aandachtsgebied 2
aandachtsgebied 2
A F
D
E C
A
B
C
D B
Randvoorwaarden in PBS niet zichtbaar: S Product C komt na product D S Product B komt na product C
Afhankelijkheids relaties zijn in een PBS taboe! Figuur 4a: Product Breakdown Structure
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
aandachtsgebied 1
E
F
bottom-up realisatie
top-down decompositie
PBS van product G
Work Package van product E E
mijlpaal: product E opgeleverd
G
Figuur 4b: Product Flow Diagram
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).
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”
S C H I P & 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-
sen de work packages op de lagere decompositieniveaus niet in te tekenen maar onder te brengen in een zogenaamde afhankelijkheidslijst.
plan, een overzicht van mijlpalen, benodigde resources, kostenoverzichten, enzovoort. Samenvatting
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-
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-
start A
D
aandachtsgebied 1 A1 A11
aandachtsgebied 2
A2 A12
A21
D1 A22
A
D
D11
D2 D12
C
B
E y
X
F G
PBS en PFD van alle brokjes werk in X detailplanning
S C H I P & WERF de ZEE
- APRIL
2007
aggregaat planning finish-start relatie afhankelijkheidslijst
PBS en PFD van alle brokken werk in work package D
PBS en PFD van alle brokken werk in work package A
PFD van product G
PBS en PFD van alle brokjes werk in Y
Figuur 5: De zichzelf herhalende structuur van decompositie (het Droste effect)
detailplanning
5
niveau 1 plan Workpackages gate ways en/of mijlpalen
Project Masternetwerk
niveau 2 plannen Activiteiten gate ways mijlpalen
Activiteitennetwerk
niveau 3 plannen taken
takennetwerk
Figuur 6: Een geneste structuur van netwerkplanningen.
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.
– 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
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 ProjectBased 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. Figuur 7 en 8: Het bijhouden van de projectvoortgang aan de hand van een PFD.
6
S C H I P & WERF de ZEE
- APRIL
2007
