UNIVERSITEIT GENT FACULTEIT ECONOMIE EN BEDRIJFSKUNDE ACADEMIEJAAR 2010 – 2011
EEN CASE STUDIE VOOR MULTIPROJECTPLANNING
Masterproef voorgedragen tot het bekomen van de graad van Master in de Toegepaste Economische Wetenschappen: Handelsingenieur
Len Vandenheede onder leiding van Prof. Dr. Vanhoucke Mario
UNIVERSITEIT GENT FACULTEIT ECONOMIE EN BEDRIJFSKUNDE ACADEMIEJAAR 2010 – 2011
EEN CASE STUDIE VOOR MULTIPROJECTPLANNING
Masterproef voorgedragen tot het bekomen van de graad van Master in de Toegepaste Economische Wetenschappen: Handelsingenieur
Len Vandenheede onder leiding van Prof. Dr. Vanhoucke Mario
PERMISSION Ondergetekende verklaart dat de inhoud van deze masterproef mag geraadpleegd en/of gereproduceerd worden, mits bronvermelding. Len Vandenheede
Woord vooraf Als ik terugkijk op de voorbije vijf jaar die ik heb doorgebracht als student Handelsingenieur aan de Universiteit Gent, verschijnt er een glimlach op mijn gezicht. Hoewel begonnen met knikkende knieën, kan ik nu zeggen dat het een ervaring geweest is die mij gesterkt heeft, die mij gemaakt heeft tot iemand die trots op zichzelf kan zijn. Deze masterproef is het sluitstuk van deze fantastische ervaring; ik kan enkel hopen dat het lezen ervan een even mooie ervaring is als de voorbije vijf jaar voor mij geweest zijn. Vooreerst wens ik een aantal mensen te bedanken die mij enorm geholpen hebben tijdens het maken van deze masterproef: Johan De Vroe, bedrijfsleider van De Vroe Groep, en mijn promotor Prof. Dr. Mario Vanhoucke, respectievelijk voor het aanreiken van de nodige input voor de case studie, en voor het steeds ter beschikking staan en het beantwoorden van mijn vragen. Daarnaast een welgemeende dankjewel aan iedereen die deze masterproef heeft nagelezen of mij heeft geholpen met de praktische besognes rond deze masterproef. Tevens wens ik iedereen te bedanken die mij gedurende het schrijven van deze masterproef, maar eveneens gedurende de voorbije vijf jaar, gesteund heeft: mijn familie, mijn vrienden, mijn studiegenoten. Een speciaal dankwoord gaat uit naar diegenen die het allemaal iets intenser meegemaakt hebben, omdat ik bij hen terecht kon, niet enkel wanneer er iets te vieren viel, maar ook als ik nood had aan een paar troostende woorden of een omhelzing: mijn mama en mijn papa, mijn beste vriendin Céline De Rouck. Ik wil ook meegeven dat, hoewel deze masterproef in het Nederlands werd geschreven, sommige termen in het Engels zijn opgenomen. Dit komt doordat er van die termen geen correcte Nederlandse vertaling voor handen is. Ten slotte wens ik de lezer veel leesplezier. Len Vandenheede
I
Inhoudsopgave Woord vooraf..................................................................................................................................... I Gebruikte afkortingen....................................................................................................................... V Lijst van gebruikte figuren ............................................................................................................... VI Lijst van gebruikte tabellen............................................................................................................. VII Lijst van gebruikte grafieken ............................................................................................................ IX
Inleiding ............................................................................................................................................ 1
Deel I: Theoretisch kader .................................................................................................................. 3 Inleiding ...................................................................................................................................... 4 Hoofdstuk 1: Wat is multiprojectplanning? ............................................................................... 5 1.1. Wat is een project? ......................................................................................................... 5 1.2. Projecten in een multiprojectomgeving: algemeen overzicht ........................................ 6 1.3. Gelijkenissen tussen een singleproject- en een multiprojectomgeving........................ 11 1.4. Samenvattende tabel van hoofdstuk 1 ......................................................................... 15 Hoofdstuk 2: Complexiteit en onzekerheid.............................................................................. 16 2.1. Omgaan met complexiteit in een multiprojectomgeving ............................................. 17 2.2. Omgaan met onzekerheid in een multiprojectomgeving ............................................. 20 2.2.1.Proactieve aanpak ................................................................................................... 21 2.2.2.Reactieve aanpak .................................................................................................... 23 Hoofdstuk 3: Mathematische voorstelling van het probleem: exact algoritme ...................... 25 Hoofdstuk 4: Het inplannen van resources met behulp van heuristieken............................... 31 4.1. Prioriteitsregels ............................................................................................................. 32 4.2. Inplannen van de projecten .......................................................................................... 33 4.2.1.Het verkrijgen van een initiële oplossing ................................................................ 34 4.2.2.Het verbeteren van de initiële oplossing ................................................................ 34 II
4.3. Kwaliteitsparameters .................................................................................................... 39 4.4. Samenvattende tabel van hoofdstuk 4 ......................................................................... 42 Hoofdstuk 5: Werknemers in een multiprojectomgeving........................................................ 43
Deel II: Case studie.......................................................................................................................... 45 Inleiding .................................................................................................................................... 46 Hoofdstuk 6: Situering van het bedrijf ..................................................................................... 47 6.1. Geschiedenis van het bedrijf ......................................................................................... 47 6.2. Werkzaamheden binnen het bedrijf ............................................................................. 47 6.3. Schaarse resources ........................................................................................................ 49 6.4. Projectportfoliomanagement ........................................................................................ 51 6.5. Hoe de planning momenteel verloopt .......................................................................... 52 6.6. Complexiteit in het projectschema ............................................................................... 53 6.7. Onzekerheid in het projectschema ............................................................................... 55 6.8. Samenvatting: overeenkomsten en verschilpunten met de literatuurstudie ............... 57 Hoofdstuk 7: Methodologie van het empirisch onderzoek ..................................................... 59 7.1. Opzet van het onderzoek .............................................................................................. 59 7.2. Onderzoeksvragen......................................................................................................... 59 7.3. Gegevensverzameling en gegevensanalyse .................................................................. 62 7.4. Softwareprogramma ..................................................................................................... 64 7.4.1.Werking van het softwareprogramma .................................................................... 64 7.4.2.Wijze van schedulen in het programma.................................................................. 70 7.4.3.Invloeden vanuit de literatuur ................................................................................ 72 7.4.4.Gebruikte prioriteitsregels ...................................................................................... 74 7.4.5.Kwaliteitsparameters .............................................................................................. 75 Hoofdstuk 8: Resultaten en interpretatie ................................................................................ 76 8.1. Resultaten en interpretatie van onderzoeksvraag 1: Welke prioriteitsregel geeft het beste resultaat weer? .................................................................................................... 76 III
8.2. Resultaten en interpretatie van onderzoeksvraag 2: Wat doet onzekerheid met het projectschema? ............................................................................................................. 78 8.3. Resultaten en interpretatie van onderzoeksvraag 3: Wat is de invloed van een nauwer tijdsframe op de kwaliteit van het projectschema?...................................................... 82 8.4. Resultaten en interpretatie van onderzoeksvraag 4: Wat is de invloed van een gelijkmatige ploegverdeling op de kwaliteit van het projectschema? .......................... 85 8.5. Resultaten en interpretatie onderzoeksvraag 5: Wat is de invloed van een multiskilled projectteam op de kwaliteit van het projectschema? .................................................. 87 8.6. Besluit van de empirische studie ................................................................................... 91
Algemene conclusie en verder onderzoek ..................................................................................... 93
Lijst van geraadpleegde werken ..................................................................................................... 96
Bijlage 1:
Lijst van kritische incidenten
Bijlage 2:
Lijst van kritische incidenten in ondernemingen die nieuwe producten ontwikkelen
Bijlage 3:
Overzicht van de gebruikte symbolen in het mathematisch model
Bijlage 4:
Contactgegevens en overzicht van gesprekken met DVG
Bijlage 5:
Overzicht van de teams, werkzaam in DVG
Bijlage 6:
Database van de ter beschikking gestelde projecten
Bijlage 7:
Rapporten in verband met de statistische significantie
Bijlage 8:
Exacte resultaten voor de verschillende prioriteitsregels
Bijlage 9:
Basisschema
IV
Gebruikte afkortingen CB
Capaciteitbuffer
CC/BM
Critical chain & buffer management
CPM
Kritisch pad-methode
DVG
De Vroe Groep
FB
Feeding buffer
GA
Genetisch algoritme
KPF
Kritische projectfactor
MSA
Modified simulated annealing
MRCPSP
Multimode resource-constrained project scheduling problem
PB
Projectbuffer
PERT
Programme Evaluation and Review Technique
RCMPSP
Resource constrained multi-project scheduling problem
RCPSP
Resource constrained project scheduling problem
RCPSP
Resource constrained project scheduling problem
SA
Simulated annealing algoritme
SDP
Stochastisch dynamisch programmeren
SRA
Schedule Risk Analysis
TOC
Theory of Constraints
WBS
Work breakdown structure
V
Lijst van gebruikte figuren Figuur 1 - Indeling van verschillende niveaus met betrekking tot planning ...................................... 8 Figuur 2 - Projectmarketing cirkel (Cooper & Budd, 2006) ................................................................ 9 Figuur 3 - Super- en subsystemen .................................................................................................... 12 Figuur 4 - Beïnvloeding van de complexiteit .................................................................................... 18 Figuur 5 - Voorstelling van TOC in een multiprojectomgeving ........................................................ 22 Figuur 6 - Schematische voorstelling van een multiprojectomgeving ............................................. 26 Figuur 7 – Voorbeeld van een mutatie............................................................................................. 35 Figuur 8 – Schematische voorstelling van simulated annealing (Chen & Mohsen Shahandeshti, 2009) ................................................................................................................................................ 36 Figuur 9 - Voorstelling van crossover in een GA .............................................................................. 37 Figuur 10 - Schematische voorstelling van de hybride SA-GA (Chen & Mohsen Shahandeshti, 2009) .......................................................................................................................................................... 39 Figuur 11 - WBS van een project in DVG .......................................................................................... 48 Figuur 12 - Algemene WBS indien men eerst aanvangt met de werken aan het platte dak ........... 48 Figuur 13 - Algemene WBS indien men aanvangt met de werken aan het hellende dak................ 48 Figuur 14 – Welkomstscherm .......................................................................................................... 64 Figuur 15 - Tabblad 'Nieuw dossier toevoegen' ............................................................................... 65 Figuur 16 - Tabblad 'Reschedule' ..................................................................................................... 66 Figuur 17 - Voorbeeld van het opvragen van de planning op dag 1 ................................................ 67 Figuur 18 - Voorbeeld van herplannen op dag 200.......................................................................... 68 Figuur 19 - Voorbeeld van het inbrengen één regendag op dag 15 ................................................ 69 Figuur 20 - Tabblad 'Aanpassingen doorvoeren'.............................................................................. 69 Figuur 21 - Schematische voorstelling van de planningswijze in het softwareprogramma ............ 72 Figuur 22 - Schematische voorstelling van een multiprojectomgeving ........................................... 93
VI
Lijst van gebruikte tabellen Tabel 1 - Samenvattende tabel omtrent integratie verkoop en planning ...................................... 10 Tabel 2 - Samenvattende tabel omtrent capaciteitsplanning in een multiprojectomgeving ......... 11 Tabel 3 - Overall-Project-Leader-Role framework (Kaulio, 2008)................................................... 14 Tabel 4 - Samenvattende tabel van hoofdstuk 1 ............................................................................ 15 Tabel 5 - Framework met betrekking tot complexiteit en onzekerheid (Vanhoucke, 2009-2010) 16 Tabel 6 - Organisationeel design versus complexiteit (Geraldi, 2007) ........................................... 19 Tabel 7 - Samenvattende tabel omtrent complexiteit ................................................................... 20 Tabel 8 - Samenvattende tabel omtrent de proactieve aanpak ..................................................... 23 Tabel 9 - Samenvattende tabel omtrent de reactieve aanpak ....................................................... 24 Tabel 10 - Framework voor het klasseren van resources in een onderneming (Krüger & Scholl, 2009) ............................................................................................................................................... 29 Tabel 11 - Samenvattende tabel omtrent het mathematische model ........................................... 30 Tabel 12 - Samenvattende tabel van hoofdstuk 4 .......................................................................... 42 Tabel 13 - Samenvattende tabel in verband met de resources van DVG ....................................... 50 Tabel 14 - Samenvatting van de factoren waarom DVG een project prefereert boven een ander 52 Tabel 15 - Organisationeel design versus complexiteit (Geraldi, 2007), toegepast op DVG .......... 54 Tabel 16 - Samenvatting van de proactieve en reactieve aanpak in DVG ...................................... 56 Tabel 17 - Overeenkomsten tussen DVG en de literatuur .............................................................. 57 Tabel 18 - Verschilpunten tussen DVG en de literatuur ................................................................. 58 Tabel 19 - Overzicht van onzekerheden, onderzoeksvraag 2 ......................................................... 60 Tabel 20 - Kenmerken van een spoedproject ................................................................................. 60 Tabel 21 - Tijdskaders gebruikt in onderzoeksvraag 3.................................................................... 61 Tabel 22 - Aanpassing van ploeggroottes in onderzoeksvraag 3.................................................... 61 Tabel 23 - Voorbeeld van een project in DVG ................................................................................ 63 Tabel 24 - Overzicht van assumpties met betrekking tot vroegste begindatum en opleverdatum 63 Tabel 25 - Samenvattende tabel: invloeden uit de literatuur ........................................................ 74 Tabel 26 - Overzicht van geteste prioriteitsregels in het softwareprogramma ............................. 74 Tabel 27 - Overzicht van gebruikte kwaliteitsparameters in het softwareprogramma ................. 75 Tabel 28 - Correlatie tussen beide kwaliteitsparameters ............................................................... 77 Tabel 29 - Overzicht van de kwaliteitsparameters voor prioriteitsregel 'Maximale kost eerst'..... 77 Tabel 30 - Besluiten onderzoeksvraag 1 ......................................................................................... 77 Tabel 31 - Correlatie tussen de gebruikte kwaliteitsparameters in onderzoeksvraag 2 ................ 79 Tabel 32 - Besluiten onderzoeksvraag 2 ......................................................................................... 82 VII
Tabel 33 - Besluiten onderzoeksvraag 3 ......................................................................................... 84 Tabel 34 - Besluiten onderzoeksvraag 4 ......................................................................................... 87 Tabel 35 - Gemiddelde aantal werknemers voor één mandag ...................................................... 88 Tabel 36 - Besluiten onderzoeksvraag 5 ......................................................................................... 91
VIII
Lijst van gebruikte grafieken Grafiek 1 - Onderzoeksvraag 1........................................................................................................ 76 Grafiek 2 – Onderzoeksvraag 2: kwaliteitsparameter 'Totale tijd om het schema te vervolmaken' ........................................................................................................................................................ 78 Grafiek 3 – Onderzoeksvraag 2: kwaliteitsparameter 'Totale vertraging' ...................................... 79 Grafiek 4 – Onderzoeksvraag 2: factoren die het basisschema aantasten, kwaliteitsparameter 'Totale tijd om het schema te vervolmaken' .................................................................................. 80 Grafiek 5 – Onderzoeksvraag 2: factoren die het basisschema aantasten, kwaliteitsparameter 'Totale vertraging' ........................................................................................................................... 80 Grafiek 6 – Onderzoeksvraag 3 ....................................................................................................... 82 Grafiek 7 – Onderzoeksvraag 3: toevoegen van onzekerheid ........................................................ 83 Grafiek 8 - Onderzoeksvraag 3: totale vertraging met en zonder onzekerheid ............................. 84 Grafiek 10 - Onderzoeksvraag 4: invloed op het basisschema ....................................................... 85 Grafiek 11 - Onderzoeksvraag 3: wegvallen van een ploeg ............................................................ 86 Grafiek 12 - Onderzoeksvraag 3: neerslagperiode van 3 dagen ..................................................... 87 Grafiek 13 - Onderzoeksvraag 5: P-ploegen ................................................................................... 88 Grafiek 14 - Onderzoeksvraag 5: P5, totale vertraging................................................................... 89 Grafiek 15 - Onderzoeksvraag 5: P5, totale tijd om het schema te vervolmaken .......................... 89 Grafiek 16 - Onderzoeksvraag 5: H-ploegen, totale vertraging ...................................................... 90 Grafiek 17 - Onderzoeksvraag 5: H-ploegen, totale tijd om het schema te vervolmaken ............. 90
IX
Inleiding Het inplannen van verschillende projecten terzelfder tijd in één bedrijf, doorheen deze masterproef multiprojectplanning genoemd, wint steeds aan belangstelling. Logisch, aangezien 90% van alle projecten zich voordoen in een multiprojectomgeving (Banaszak, Muszynski, & Zaremba, 2007). Evenwel bevindt dit onderzoek zich veelal nog in een beginstadium. Deze masterproef tracht de bestaande onderzoeken te bundelen en aan te vullen door middel van een case studie. Een multiprojectomgeving vindt men zowel terug in de productiesector als in meer servicegerichte sectoren (Hans, Herroelen, Leus, & Wullink, 2005). Een voorbeeld uit de productiesector is een bouwbedrijf; voor de meer servicegerichte sectoren kan men denken aan de consultingsector. Andere voorbeelden zijn een multiprojectomgeving zijn de software-industrie en research & development. Al deze sectoren zetten resources in op verschillende projecten terzelfder tijd. Wanneer meer dan één project dezelfde resources op hetzelfde tijdstip vereist, ontstaan er problemen. Het spreekt vanzelf dat een goede planning van deze projecten essentieel is. Voorts kan ook een onderscheid gemaakt worden tussen multiprojectplanning, projectportfolio management en programmamanagement (Hans et al., 2005). Multiprojectplanning behelst vooral de allocatie van capaciteit en het inplannen an sich, terwijl projectportfoliomanagement zich vooral gaat richten op het selecteren van projecten. Programmamanagement, ten slotte, is een bijzonder geval van multiprojectmanagement, waarbij alle projecten een gemeenschappelijk doel hebben. Zoals
de
titel
aangeeft,
bestudeert
deze
masterproef
vooral
het
vakgebied
rond
multiprojectplanning, hoewel de andere domeinen ook aan bod komen. In het eerste deel van deze masterproef worden de conclusies uit de literatuurstudie op een rijtje gezet. Eerst worden een aantal algemene bevindingen rond multiprojectplanning op een rijtje gezet. Heel veel is immers nog niet gepubliceerd over deze materie en een grondig overzicht is hier op zijn plaats. Vervolgens wordt ingegaan op de complexiteit en de onzekerheid die eigen zijn aan een multiprojectomgeving. Daaropvolgend wordt een theoretisch wiskundig model gepresenteerd. Aangezien, zoals zal blijken, dit wiskundig model onmogelijk op te lossen valt, zal in een volgende sectie het gebruik van algoritmes bediscussieerd worden. Ten slotte wordt nog een kort hoofdstuk gewijd aan de kenmerken van werknemers in een multiprojectomgeving. Het tweede deel van deze masterproef bestaat uit een case studie die werd uitgevoerd in het bouwbedrijf De Vroe Groep. Door middel van deze case studie worden de bevindingen uit de
1
literatuur getoetst aan een realistische multiprojectomgeving. Vervolgens wordt met de gegevens verkregen in De Vroe Groep een empirische studie gedaan. Hoofdstuk 7 beschrijft hoe deze empirische studie zal worden uitgevoerd, hoofdstuk 8 beschrijft de resultaten. Ten slotte wordt ook nog een algemene conclusie getrokken en worden aanbeveling voor verder onderzoek gedaan.
2
Deel I: Theoretisch kader
3
Inleiding In dit eerste deel van de masterproef wordt een overzicht gegeven van de literatuur die rond het thema multiprojectplanning werd geschreven. Er werd getracht om de verschillende bronnen zoveel mogelijk met elkaar te vergelijken en te kaderen binnen eenzelfde onderwerp. In het eerste hoofdstuk wordt beschreven wat multiprojectplanning eigenlijk voorstelt. Onder andere het portfoliomanagement en gelijkenissen met singleprojectplanning worden hier uitvoerig beschreven. Vervolgens worden de complexiteit en onzekerheid besproken, die zo eigen zijn aan een multiprojectomgeving. Het derde hoofdstuk gaat dieper in op de mathematische achtergrond rond de multiprojectplanning. Vervolgens worden enkele heuristieken gegeven waarmee men projecten in een multiprojectomgeving efficiënt kan inplannen. Veel aandacht wordt besteed aan prioriteitsregels, waarmee men projecten kan rangschikken naar belangrijkheid, en aan kwaliteitsparameters, die het mogelijk maken om de kwaliteit van verschillende schema’s te vergelijken. Ten slotte handelt het laatste hoofdstuk over werknemers in een multiprojectomgeving. Hoewel resources doorheen alle hoofdstukken aan bod komen, worden hier specifiek de human resources benadrukt.
4
Hoofdstuk 1: Wat is multiprojectplanning? In een multiprojectomgeving maken een aantal projecten terzelfder tijd aanspraak op een beperkt aantal resources. De verschillende activiteiten hebben onderlinge relaties met elkaar, maar ook projecten kunnen onderling afhankelijk zijn. Elke activiteit heeft een gespecificeerde duurtijd, moet worden uitgevoerd in een vooraf vastgelegd tijdsframe en heeft nood aan een bepaald aantal resources (Kumanan, Jegan Jose, & Raja, 2006). In dit eerste hoofdstuk wordt overlopen wat multiprojectplanning inhoudt. De eerste paragraaf gaat nader in op wat een project precies behelst. Vervolgens wordt een overzicht gegeven van wat een multiprojectomgeving bevat. In deze paragraaf wordt ook dieper ingegaan op de meer strategische kant van multiprojectplanning. Ten slotte worden een aantal gelijkenissen tussen singleprojecten en multiprojecten opgelijst.
1.1.
Wat is een project?
Een project kan gedefinieerd worden als “een unieke onderneming, bestaande uit een complex geheel van onderling afhankelijke activiteiten, die moeten worden uitgevoerd door diverse en veelal schaarse resources” (Hans et al., 2005). De opdeling van een project in deze activiteiten noemt men de work-breakdown-structure (WBS) en deze activiteiten zijn op hun beurt ook apart beheersbaar. Het succes van een project kan beoordeeld worden aan de hand van drie dimensies: tijd, kost en kwaliteit (Ballestín & Blanco, 2011). Tijd houdt in dat het project voor een afgesproken deadline afgerond is. Met kost wordt bedoeld dat een vooraf bepaald budget niet mag worden overschreden. Algemeen kan gesteld worden dat de kosten dalen indien er een grotere speling is in het tijdsframe waarin kan worden gepland, indien projecten kleiner zijn en indien werknemers meerdere skills bezitten (Heimerl & Kolisch, 2010). Kwaliteit, ten slotte, betekent dat het project moet worden afgewerkt binnen bepaalde standaarden. Om deze dimensies in de hand te houden is een goed en realistisch projectschema nodig. Dit geldt zowel voor single- als multiprojectplanning. Sommige auteurs vernoemen daarom naast de voorgaande drie dimensies ook stabiliteit als een vierde dimensie (Cooper & Budd, 2006). Hiermee bedoelen ze dat een projectschema zo weinig mogelijk variabiliteit en onderbreking mag kennen. Elk project kent echter gedurende de uitvoering een zekere vorm van onzekerheid (Hans et al., 2005). Het vooropgesteld projectschema mag nog zo goed zijn, men kan de toekomst niet voorspellen. Het is dan ook belangrijk om op een degelijke manier om te gaan met deze onzekerheid.
5
Men kan een proactieve en een reactieve aanpak onderscheiden. Bij de proactieve aanpak gaat men op voorhand een zekere vorm van flexibiliteit in het projectschema verwerken. Dit kan bijvoorbeeld door middel van het inplannen van buffers, eventueel volgens de regels van TOC (Patrick, 1998). Een reactieve aanpak behelst het herplannen wanneer een verstoring van het oorspronkelijk plan zich voordoet. Daarnaast kent elk project een vorm van complexiteit. Activiteiten zijn met elkaar verbonden, schaarse resources moeten worden verdeeld, er is een overload aan informatie of er is net een tekort aan informatie, etc. Zowel complexiteit als onzekerheid worden in een later hoofdstuk uitvoerig besproken (zie infra Hoofdstuk 2: Complexiteit en onzekerheid).
1.2.
Projecten in een multiprojectomgeving: algemeen overzicht
Vele organisaties, en dan vooral KMO’s, moeten een verscheidenheid aan singleprojecten en een schaars aantal resources managen (Banaszak et al., 2007). Dit kadert in project-driven manufacturing, waarbij producten worden geproduceerd volgens het make-to-order of build-toorder principe. Zo’n strategie is één der belangrijkste voor een bedrijf in de hedendaagse omgeving om correct te kunnen reageren op de groeiende marktcomplexiteit en globalisatie. Andere redenen om projectmatig te gaan werken zijn kortere levenscyclussen van producten, een grotere variëteit aan producten en een stijgende invloed van klanten op de producten zelf (Wuliang & Chengen, 2009). In deze omgeving zijn resources schaars, doordat men de principes van lean manufacturing wil naleven (Lova, Tormos, Cervantes, & Barber, 2009). Auteurs spreken ook over het resource-constrained multi-project scheduling probleem (RCMPSP) (Cooper & Budd, 2006) (Gonçalves, Mendes, & Resende, 2008) waarmee ze bedoelen dat verscheidene projecten terzelfder tijd aanspraak maken op een beperkt aantal resources. Het is dan ook vaak nodig om bepaalde projecten te gaan uitstellen ten gunste van een meer winstgevend project. Dit zorgt er dan evenwel voor dat de uitgestelde projecten vaak negatief scoren op één of meerdere der drie dimensies (zie infra 2.2). Men moet echter steeds pogen om alle afspraken die met klanten zijn aangegaan, zo correct mogelijk na te leven. Zo niet, kan dit een nefaste invloed hebben op het imago en uiteindelijk op de winst van de onderneming (Tobis & Tobis, 2002). Anderzijds kan men stellen dat een multiprojectomgeving zorgt voor een efficiënter gebruik van de resources (Zika-Viktorsson, Sundström, & Engwall, 2006). In zo’n omgeving is het immers gemakkelijker om de resources steeds weer in te plannen, zeker als ze in hoge mate gespecialiseerd 6
zijn in een bepaald domein, dan in een singleprojectomgeving. Daarnaast wordt het overdragen van expertise tussen werknemers ook vereenvoudigd en werknemers kunnen hun opgedane kennis ook vlugger toepassen op andere projecten. Ondanks
deze realiteit is het onderzoek naar projectplanning vooral gericht op
singleprojectplanning (Aritua, Smith, & Bower, 2008). Er is momenteel weinig bekend over multiprojectplanning (Ash, 2009) (Gonçalves et al., 2008). Vele auteurs berichten echter dat het managen van een multiprojectomgeving niet mag beschouwd worden als een aggregaat van de singleprojectomgeving. Anderzijds zijn er wel enkele gelijkenissen tussen beide domeinen (zie infra 1.3) (Krüger & Scholl, 2009). Het onderzoek naar multiprojectplanning wordt vaak bemoeilijkt door de niet-eenduidige termen die aan dit vakgebied gegeven worden (Aritua et al., 2008). Multiproject, portfolio, programma, macroproject, megaproject, superproject, metaproject of combinaties van voorgaande termen worden door elkaar gebruikt, hoewel ze vaak verschillende betekenissen hebben. Om enige duidelijkheid te scheppen, worden vervolgens enkele definities vermeld. Programma’s kunnen gedefinieerd worden als “frameworks voor het groeperen van bestaande projecten of het definiëren van nieuwe projecten, met als doel het realiseren van een grote groep van voordelen. Deze projecten worden gemanaged in een gecoördineerde manier, zodat ofwel een gemeenschappelijk doel wordt bereikt, ofwel voordelen worden gerealiseerd die niet zouden gerealiseerd worden indien de projecten onafhankelijk werden gemanaged.” (Arituaet al., 2008, p. 75) Projectportfoliomanagement wordt gedefinieerd als “het gecentraliseerde management van één of meerdere portfolio’s, met als taak het identificeren, evalueren, toekennen van prioriteiten, bekrachtigen, managen en controleren van projecten, programma’s en andere gerelateerde activiteiten om specifieke, strategische objectieven te realiseren.” (Aritua et al., 2008, p. 75). Eenvoudigweg gezegd kan men dus stellen dat door middel van projectportfoliomanagement de juiste projecten worden gekozen en uitgevoerd, op zo’n manier dat ze in lijn liggen met de strategie van een onderneming. Zodoende wordt de langetermijnvisie niet uit het oog verloren (Elonen & Artto, 2003). Programmamanagement is een onderdeel van dit projectportfoliomanagement, net zoals het projectmanagement an sich ook een onderdeel vormt van het programmamanagement (Vanhoucke, 2009-2010).
7
Indien men naar de strategie van een onderneming gaat kijken, kan men portfoliomanagement en programmamanagement op het tactische niveau plaatsen. Portfoliomanagement vindt plaats op middellange termijn. Op het hoogste niveau wordt de strategie bepaald, en dit voor een lange termijn. Het pure plannen, dus (multi)projectplanning, plaatst men op het laagste niveau bij de operaties, die de korte termijn behelzen.
Figuur 1 - Indeling van verschillende niveaus met betrekking tot planning
In deze context geldt dan ook dat het projectmanagement en de andere bedrijfsfuncties op één lijn moeten staan. Zo kan men bijvoorbeeld speken over de integratie van de verkoop in de operaties: een onderneming moet wat het een klant beloofd heeft, foutloos kunnen uitvoeren (Cooper & Budd, 2006) (Tobis & Tobis, 2002). De onzekerheid en complexiteit binnen een multiprojectomgeving in acht genomen, is dit niet altijd even gemakkelijk. Wanneer men immers resources toewijst aan het ene project kunnen zij niet meer worden toegewezen aan andere projecten. Dit kan de deadlines van die andere projecten enorm in gevaar brengen en de kwaliteit van de planning in negatieve zin beïnvloeden. Het komt er dus op neer om de verkoopafdeling en de operationele afdelingen binnen een bedrijf succesvol te integreren. Op basis van vier case studies besluiten (Blomquist & Wilson, 2007) dat de integratie van verkoop en het operationele niveau op verschillende manieren kan verlopen, met andere woorden, zij besluiten dat er geen beste oplossing is, maar dat deze integratie wel moet plaatsvinden. Een goed hulpmiddel hierbij is de projectmarketing cirkel (Cooper & Budd, 2006), voorgesteld in figuur 2. Eenvoudigweg gezegd moet de verkoopafdeling van een onderneming de klant steeds correcte voorstellingen geven van hoe het resultaat van een project er uiteindelijk gaat uitzien, 8
terwijl het operationele gedeelte van de onderneming ervoor moet zorgen dat deze voorstelling uiteindelijk ook waargemaakt worden. Door steeds een feedbackloop tussen de verschillende afdelingen te hebben, zal de verkoopafdeling een steeds correctere voorstelling kunnen weergeven en zal het voor de operationele afdelingen gemakkelijker zijn om aan de wensen van de klant te voldoen.
Figuur 2 - Projectmarketing cirkel (Cooper & Budd, 2006)
In Herbots, Herroelen & Leus wordt geconcludeerd dat de beslissing om een project in het portfolio op te nemen afhangt van een directe beloning, zoals een voorschot, maar ook van beloningen in de toekomst, zoals extra inkomsten door aanname van dit project. Dit besluit vloeit voort uit een algoritme dat gebaseerd is op het stochastisch dynamisch programmeren en dat ze uitvoerig bespreken in bovenstaand vernoemd artikel (Herbots, Herroelen, & Leus). Cohen, Golany & Shtub laten slechts een maximaal aantal projecten in het portfolio toe (Cohen, Golany, & Shtub, 2007). De bevindingen omtrent de integratie van de verkoopsfunctie en de planningsfunctie zijn opgesomd in tabel 1.
9
Integratie verkoop en planning Nodig zodat afspraken met klanten zoveel mogelijk kunnen worden nageleefd, ondanks onzekerheid en complexiteit Hulpmiddel: projectmarketing cirkel door een continue feedbackloop worden verwachtingen steeds realistischer Aanbeveling 1: het totale winstplaatje niet uit het oog verliezen Aanbeveling 2: een maximaal aantal projecten terzelfder tijd toelaten in het portfolio Tabel 1 - Samenvattende tabel omtrent integratie verkoop en planning
Naast deze integratie van verkoop en operaties is er natuurlijk ook nood aan een goede beheersing van de resources (Herbots et al.). Het aantal beschikbare resources in een onderneming wordt de capaciteit van een onderneming genoemd en wordt typisch op middellange termijn bepaald. De capaciteitsplanning vindt men dus terug op tactisch niveau. Het aantal resources in een onderneming ligt vast voor een bepaalde periode en het is aan de dagelijkse leiding om die resources dan ook zo goed mogelijk in te plannen. Beide beslissingen zijn echter inherent met elkaar verbonden en daardoor argumenteren Heimerl en Kolisch dat beide problemen tezelfdertijd moeten beschouwd worden (Heimerl & Kolisch, 2010). Het inplannen van de resources wordt uitvoerig besproken in hoofdstuk 4: Het inplannen van resources met behulp van heuristieken (zie infra). Cohen, Golany en Shtub argumenteren waarom de capaciteit met betrekking tot het aantal werknemers per periode in plaats van op continue basis wordt bepaald. Zij zien twee redenen. Enerzijds neemt het proces van ontslaan en aannemen, training geven, etc. heel veel tijd in beslag. Anderzijds zouden frequente veranderingen onrust in de onderneming brengen (Cohen et al., 2007). Om te bepalen hoeveel resources een onderneming voor een bepaalde periode nodig heeft, converteren ze het probleem naar een stochastisch probleem. Ze bepalen eerst de stochastische parameters die het onderliggende probleem karakteriseren. Daarna genereren ze met behulp van deze parameters een initieel schema, waaraan ze de resources gaan toewijzen. Dit initieel schema wordt met behulp van smoothing technieken geïtereerd over een aantal tijdsperiodes. Deze methode bewees zijn nut al voor kleine en simpele problemen, maar zou voor grote problemen te veel tijd in beslag nemen. Herbots et al. geeft een goed overzicht weer van al gedane studies om het benodigde aantal resources te bepalen. Zij benadrukken eveneens het belang van de integratie van de verkoopafdeling met de capaciteitsplanning. 10
Bovenstaande conclusies werden samengevat in tabel 2. Capaciteitsplanning in een multiprojectomgeving Capaciteitsplanning gebeurt op middellange termijn Inplannen resources gebeurt best simultaan met projectplanning Capaciteitsplanning kan aan de hand van stochastische technieken Tabel 2 - Samenvattende tabel omtrent capaciteitsplanning in een multiprojectomgeving
Men kan ook nog een onderscheid maken tussen dynamische en statische omgevingen (Ash, 2009). In dynamische omgevingen worden er steeds nieuwe projecten geïntroduceerd en wordt de planning gewijzigd. In een statische omgeving daarentegen, is het aantal projecten en hun karakteristieken gekend. Eenmaal een planning gemaakt is, ligt die dan ook vast. Nadat het laatste project van de planning is afgrond, kan een nieuwe set van multiprojecten van start gaan (Krüger & Scholl, 2009). In die zin is een multiprojectomgeving niets meer dan een aggregaat van een singleprojectomgeving (Krüger & Scholl, 2010). Wanneer men vergelijkt met een pure productieomgeving, kan men stellen dat een statische omgeving meer een push-omgeving is, terwijl een dynamische omgeving meer een pull-omgeving is. Bij de eerste omgeving gaat men immers alle projecten doorheen een projectschema pushen, terwijl bij de tweede omgeving slechts een nieuw project in het schema komt als een ander is afgewerkt. In de realiteit heeft men natuurlijk vooral te maken met dynamische schema’s, hoewel men zich in de literatuur vooral concentreert op statische schema’s (Herbots et al.).
1.3.
Gelijkenissen tussen een singleproject- en een multiprojectomgeving
Zoals eerder vermeld, is het resource constrained project scheduling probleem (RCPSP), of eenvoudigweg gezegd, het plannen van singleprojecten, wijd bekend en uitvoerig bestudeerd. Het RCMPSP, of het plannen van projecten in een multiprojectomgeving, is hierop een uitbreiding, waardoor er tussen beide disciplines een aantal raakvlakken zijn. Deze worden in onderstaande paragraaf besproken. Net zoals bij activiteiten in een singleproject zijn er onderlinge relaties bij activiteiten in een multiproject. Een verschilpunt tussen beiden is evenwel dat er in een multiprojectomgeving ook onderlinge relaties tussen de verscheidene projecten kunnen ontstaan.
11
In beide omgevingen ontstaan kosten als hernieuwbare resources worden gebruikt of niethernieuwbare resources worden geconsumeerd. De grootste kosten bij projecten ontstaan wanneer hernieuwbare resources worden ingezet (Wuliang & Chengen, 2009). Wat betreft de loonkost, een groot deel van de kosten van hernieuwbare resources, kan men een onderscheid maken tussen directe kosten, zoals het betalen van overuren, en indirecte kosten, zoals de maandelijkse salarissen van de werknemers. Zowel singleprojecten als multiprojecten kunnen plaatsvinden in open en gesloten omgevingen (Aritua et al., 2008). In een open omgeving is er door middel van het project interactie met deze omgeving. Door plaats te vinden in een bepaalde omgeving, worden er bijvoorbeeld beperkingen opgelegd voor bepaalde resources. Deze beperkingen worden echter niet beïnvloed door de projecten zelf. In een gesloten systeem, daarentegen, treedt er geen interactie op en wordt het project uitgevoerd in een geïsoleerde omgeving. Het is voor de lezer duidelijk dat, in de huidige economie, de meeste projecten in een open systeem plaatsvinden, hetgeen de complexiteit verhoogt. Men kan opmerken dat, in een open omgeving, een project een subomgeving is van het bedrijf dat het project uitvoert, en dat dit bedrijf dan weer een subomgeving is van de economische sector waarin het bedrijf zich bevindt. In deze zin beïnvloeden veranderingen in een systeem ook de karakteristieken van hun subsystemen. Dit wordt voorgesteld in figuur 3. Ondernemingen moeten zich wapenen tegen deze veranderingen door te trachten hun activiteiten uit te voeren in relatief stabiele omgevingen op korte termijn, terwijl ze terzelfder tijd hun langetermijndoelstellingen bereiken. Zowel in een singleproject- als in een multiprojectomgeving is het dus belangrijk dat strategie en operaties aan elkaar zijn aangepast.
Figuur 3 - Super- en subsystemen
12
Ook geldig voor zowel een singleprojectomgeving als voor een multiprojectomgeving is de mogelijkheid tot onderbreken van activiteiten (Ash, 2009). Hierbij moet men steeds rekening houden dat werknemers, wanneer men een onderbroken activiteit heraanvat, opnieuw doorheen een leerproces moeten. Men moet de tijd van dit leerproces dan ook bijtellen bij de duur van de activiteit. Daarom is het belangrijk om enkel activiteiten te onderbreken die voldoende slack hebben of die nog maar net zijn aangevangen, waardoor er niet veel kennis verloren gaat, aangezien men nog niet veel kennis heeft opgedaan. Het is evenwel aangeraden om projecten niet te onderbreken. Eveneens is er in beide omgevingen nood aan projectmanagers. Zij leiden het project in goede banen. Vaak hanteert men hierbij een gecentraliseerde aanpak (Confessore, Giordani, & Rismondo, 2006). Hierbij gaat één projectmanager de resources toewijzen aan de set van projecten. Het spreekt hier voor zich dat in een singleprojectomgeving enkel een gecentraliseerde aanpak mogelijk is. Voor een multiprojectomgeving, kan men echter ook een gedecentraliseerde aanpak onderscheiden. In het ideale geval heeft elk project een eigen projectmanager die resources op een optimale manier gaat verdelen. Deze resources worden toegewezen door middel van een superschema of de projectmanagers kunnen optreden als agenten die zoveel mogelijk resources proberen toegewezen te krijgen. Een heuristiek rond deze laatste mogelijkheid werd uitgewerkt door (Confessore et al., 2006). Deze aanpak, gecombineerd met traditionele planningtechnieken, is het meest efficiënt voor een multiprojectomgeving waar de informatie niet gecentraliseerd is. Naarmate de resources meer gespecialiseerd zijn, is er minder verschil tussen een gecentraliseerde en een gedecentraliseerde planning (Heimerl & Kolisch, 2010). De aanpak van een projectmanager is determinerend voor het succes van een project (Mota, de Almeida, & Alencar, 2009). Aangezien een planning in een dynamische omgeving heel vaak verandert, is het echter zeer moeilijk om een overzicht te bewaren. De projectmanager moet immers tegelijkertijd verschillende aspecten van de projectomgeving in het oog houden: deadlines, kosten, etc. Studies wijzen uit dat een projectmanager gemiddeld met vier projecten terzelfder tijd bezig zijn (Browning & Yassine, 2010). Naast de projectmanagers, die zich vooral bezig houden met planning, budgettering en controlesystemen, kunnen we ook de projectleiders onderscheiden (Kaulio, 2008). Deze houden zich vooral bezig met de strategie, de visie achter projecten, hetgeen eerder werd omschreven als programma- en portfoliomanagement. Daarnaast kan men ook nog spreken over de interne en externe rol van projectmanagers en projectleiders. De interne rol heeft betrekking op alles wat binnen een project gebeurt, terwijl de externe rol betrekking heeft op alles wat in de omgeving van 13
de onderneming gebeurt, maar wat de projecten wel kan beïnvloeden. Het is mogelijk dat binnen één onderneming, de projectleiders en projectmanagers één en dezelfde persoon zijn, en zowel de interne als externe rol op zich nemen. Bovenstaande aspecten in acht genomen, kan men volgend framework opmaken:
Externe focus
Bv. Projectportfoliomanagement, planning van resources
Dit is het leiderschap rond ongeplande en informele activiteiten buiten de projecten, zoals netwerken, lobbyen, etc.
Interne focus
Bv. Projectplanning
Bv. De integratie van teams
Management
Leiderschap
Tabel 3 - Overall-Project-Leader-Role framework (Kaulio, 2008)
Door in de onderneming een strikt onderscheid te maken tussen enerzijds de management- en leiderschapsactiviteiten en anderzijds de externe en interne focus, zal dit de efficiënte werking van de onderneming ten goede komen. Het wordt dan mogelijk om zowel proactieve als reactieve maatregelen te treffen om de onzekerheid die projecten kenmerkt, te ondermijnen (zie infra 2.2).
14
1.4.
Samenvattende tabel van hoofdstuk 1
In deze paragraaf worden de conclusies die in de vorige paragrafen werden getrokken nog eens kort opgesomd in tabel 4. Project Unieke onderneming Aanspraak op schaarse resources Succes wordt afgemeten aan de hand van tijd, kost en kwaliteit Onzekerheid en complexiteit Multiprojectomgeving “Resource-constrained multi-projct scheduling problem” Zorgt voor een efficientere inplanning van resources Projectportfoliomanagement = het selecteren van de juiste projecten Multiprojectplanning = inplannen van de projecten Integratie verkoop en planning is nodig Goede capaciteitsplanning is onontbeerlijk Onderscheid tussen dynamische en statische schema’s Gelijkenissen met een singleprojectomgeving Onderlinge relaties tussen projectfases Hernieuwbare en niet-hernieuwbare resources Onderscheid tussen op en gesloten omgevingen Mogelijkheid tot onderbreken van projecten Nood aan projectmanagers: gecentraliseerde versus niet-gecentraliseerde aanpak Overall-project-leader-role framework Tabel 4 - Samenvattende tabel van hoofdstuk 1
15
Hoofdstuk 2: Complexiteit en onzekerheid Zoals eerder vermeld kennen projecten een zekere vorm van complexiteit en onzekerheid. In een multiprojectomgeving wordt dit nog eens versterkt doordat de gehele omgeving in acht moet worden genomen, en niet enkel moet worden gekeken naar de projecten afzonderlijk. Evenwel kan men alle projecten naargelang complexiteit en onzekerheid indelen op onderstaand framework
Laag
Complexiteit
Hoog
(Vanhoucke, 2009-2010): Bv. Zeer grote bouwprojecten: men weet hoe men het gebouw kan maken, maar het project bestaat uit zeer veel activiteiten die afhankelijk zijn van elkaar.
Bv. Het ontwikkelen van totaal nieuwe producten.
Techniek: RCP Bv. Projecten die in het verleden al werden uitgevoerd en een klein team behelzen.
Techniek: CC/BM Bv. Marketingcampagnes voor nieuwe producten: men weet hoe men een marketingcampagne moet opstellen, maar men weet niet hoe de klant zal reageren.
Techniek: PERT of CPM Laag
Techniek: SRA Hoog Onzekerheid
Tabel 5 - Framework met betrekking tot complexiteit en onzekerheid (Vanhoucke, 2009-2010)
In het singleprojectmanagement wordt voor elk kwadrant andere technieken gebruikt om zo tot een optimaal projectschema te komen. Een soortgelijk framework is te vinden in Hans et al. (2005). Deze auteurs merken echter op dat complexiteit en onzekerheid niet mutueel exclusief zijn. Volgens deze auteurs is complexiteit een veel breder begrip en bevat het onzekerheid. In plaats van complexiteit gebruiken zij in het framework dan ook afhankelijkheid, dat ze definiëren als de mate waarin een project afhankelijk is van invloeden uit de superomgeving van het project. In dit hoofdstuk wordt echt nog een onderscheid gemaakt tussen beide begrippen, dit om de overzichtelijkheid te bewaren. In de eerste paragraaf wordt complexiteit besproken en worden enkele adviezen meegegeven om beter met deze complexiteit om te gaan. In de tweede paragraaf wordt onzekerheid besproken en worden eveneens een aantal adviezen meegegeven.
16
2.1. Omgaan met complexiteit in een multiprojectomgeving Net zoals in de singleprojectomgeving, kent de multiprojectomgeving een mate van complexiteit. Hoe complexer een bepaald projectschema, hoe moeilijker het uit te voeren valt en hoe moeilijker het wordt om te voldoen aan de drie dimensies van een succesvol projectplan. Door de complexiteit is het ook zo dat, wanneer risico’s en onzekerheden zich voordoen, dit een enorme weerslag heeft op de andere projecten in de omgeving. Deze complexiteit wordt beïnvloed door volgende aspecten (Aritua et al., 2008): 1. Afhankelijkheid: in een omgeving zijn verscheidene projecten afhankelijk van elkaar. Ze beïnvloeden elkaar en de nodige activiteiten die moeten worden ondernomen om de projecten tot een goed einde te brengen. Dit geldt evenzeer voor de projectfases binnen één project. Specifiek voor multiprojectmanagement is het zaak om ervoor te zorgen dat de waarde van een onderneming gemaximaliseerd wordt door het correct simultaan managen van resources, projectschema’s en kosten en het daarmee gepaard gaande risico voor een bundel projecten. 2. Het vermogen tot aanpassen: in een open omgeving (zie supra 1.3) is er een constante flow aan informatie. Deze informatie zorgt ervoor dat een subomgeving zich aanpast aan gebeurtenissen binnen de superomgeving. Voor een multiprojectomgeving betekent dit dat men het risico van een veranderende omgeving en de daarmee gecorreleerde impact op de projecten zodanig moet managen dat de totale waarde van de projecten behouden blijft. Indien een onderneming zich vlot kan aanpassen, zal dit leiden tot een reductie van de complexiteit. 3. Zelforganisatie: wanneer individuen binnen een omgeving op eenzelfde manier reageren op bepaalde gebeurtenissen, kan de chaos binnen die omgeving verminderen. Dit noemt men zelforganisatie en heeft een negatieve invloed op de complexiteit van een omgeving. Voor multiprojectplanning dient men in acht te nemen dat er een goed strategisch kader moet zijn, waarin de operaties correct kunnen plaatsvinden. Op die manier kan de multiprojectomgeving voor een stuk als een aggregaat van de singleprojecten gezien worden, hetgeen de complexiteit van die omgeving sterk vermindert. 4. Het geheel is groter dan de som van de delen. Met
andere
woorden,
er
wordt
een
beter
resultaat
behaald
door
multiprojectmanagement, dan door het autonoom managen van singleprojecten.
17
5. Feedback: informatie verzonden vanuit een subomgeving, wordt door de omgeving opgenomen, veranderd en teruggezonden naar de subomgeving. Het zorgt ervoor dat een omgeving steeds verandert. Door middel van multiprojectmanagement dient men gepast te reageren op deze veranderende omgeving, door het algemene objectief op de voorgrond te plaatsen en een stabiele omgeving te bieden voor de individuele projecten. 6. Niet-lineariteit: kleine aanpassingen binnen een omgeving kunnen grote veranderingen teweegbrengen voor deze omgeving. Wanneer men bijvoorbeeld werknemers op een bepaalde manier aan projecten toewijst, heeft dit een invloed op hun verdere ontwikkeling en op de projecten die een onderneming daarna kan aannemen (Aggeri & Segrestin, 2007). Binnen multiprojectmanagement zijn dus verschillende technieken nodig om de impact van veranderingen op een accurate manier te proberen in te schatten. De verschillende aspecten van complexiteit werden visueel voorgesteld in figuur 4.
Figuur 4 - Beïnvloeding van de complexiteit
18
Uit deze zes aspecten blijkt dus eens te meer dat multiprojectmanagement een andere aanpak vereist dan singleprojectmanagement. Men moet steeds nagaan wat de verhouding van verschillende projecten met elkaar is en wat impact is van die verhouding (Olsson, 2008). Wanneer in ondernemingen de flexibiliteit van de bedrijfsorganisatie aangepast is aan de mate van complexiteit waaraan de projecten van de onderneming zijn blootgesteld, zal de onderneming succesvol zijn (Geraldi, 2007). Een flexibele bedrijfsorganisatie houdt verband met volgende aspecten: -
De mogelijkheid tot het definiëren en veranderen van de omvang en objectieven van de projecten.
-
De mogelijkheid tot het definiëren en aanpassen van de processen die gebruikt worden om projecten te realiseren.
-
De mogelijkheid om verschillende mensen toe te wijzen aan projecten.
-
De mogelijkheid om de planning te definiëren en aan te passen.
-
Budgetflexibiliteit.
-
De mogelijkheid om te bepalen waar projecten worden uitgevoerd.
Een onderneming kan zich met betrekking tot flexibiliteit en complexiteit op onderstaand
Door het ontbreken van informatie Door een overload aan informatie
Complexiteit
framework plaatsen: Bureaucratische onderneming:
Creatieve-reflectieve onderneming:
We wenst constant te werken met standaarden. Dit is evenwel niet mogelijk, wegens het ontbreken van de nodige informatie in deze omgeving. Hierdoor worden de standaarden steeds complexer Mechanisch-gestructureerde onderneming:
Er zijn geen cijfergegevens en causale relaties zijn niet duidelijk, de onderneming moet flexibel zijn om te overleven. Onderneming met onnodige chaos:
Een gedetailleerde planning is steeds Typische indicatoren van zo’n noodzakelijk. Men moet een holistisch onderneming zijn fouten die zich overzicht bewaren over alle projecten en herhalen, onnodig rework en het beslissingen moeten van de eerste maal opnieuw uitvinden van het wiel. goed zijn, zoniet leidt dit tot onzekerheid. Hoog Laag Flexibiliteit Tabel 6 - Organisationeel design versus complexiteit (Geraldi, 2007)
19
Een onderneming bereikt een gepaste verhouding als ze zich bevindt in de linkeronderhoek of de rechterbovenhoek. Het is in deze zones dat de onderneming succesvol zal zijn. Indien een onderneming niet succesvol is, is er een mogelijkheid dat dit komt door een onaangepaste flexibiliteit van de bedrijfsorganisatie. Men kan zich dan herpositioneren aan de hand van dit framework. Ook de strategie van zo’n onderneming kan onder de loep genomen worden aan de hand van dit framework. Alle bevindingen rond complexiteit worden nog eens op een rijtje gezet in tabel 7. Complexiteit Complexiteit en onzekerheid: niet mutueel exclusief Aspecten die de complexiteit beïnvloeden: - afhankelijkheid - aanpassingsvermogen - zelforganisatie - het geheel is meer dan de delen - feedback - niet-lineariteit Een onderneming is succesvol als de flexibiliteit is aangepast aan de complexiteit Framework organisationeel design versus complexiteit Tabel 7 - Samenvattende tabel omtrent complexiteit
2.2. Omgaan met onzekerheid in een multiprojectomgeving Aangezien een projectschema steeds een voorspelling is en men de toekomst vooralsnog niet kan voorspellen, heeft men in een multiprojectomgeving steeds te maken met onzekerheden. Wat als een deel van de werknemers ontslag neemt omdat het elders betere voorwaarden kan krijgen? Of wat als er plots een zeer winstgevend maar zeer dringend project opduikt dat indien het wordt uitgevoerd, een negatieve invloed heeft op de projectschema’s van andere projecten? In deze sectie zal besproken worden hoe men best omgaat met onzekerheid in een multiprojectomgeving. Hierbij moet men steeds rekening houden met het feit dat door de complexiteit van een multiprojectomgeving, verstoringen bij één enkel project hun weerslag kunnen hebben op alle andere projecten in de omgeving, waardoor de situatie nog meer onzeker wordt, dan voordien (ZikaViktorsson et al., 2006). Een belangrijk verschil met complexiteit is dat de onzekerheid een projectplan niet altijd in negatieve zin zal beïnvloeden; het is immers mogelijk dat een planning wordt bespoedigd doordat een project vroeger klaar is dan werd voorspeld (Olsson, 2008). De vrijgekomen resources kunnen hierdoor worden ingezet op projecten waarvan men vreest de deadline niet te halen, of op nieuwe projecten. Aangezien we te maken hebben met onzekerheid, mag men hierop echter niet rekenen wanneer men een projectplan opstelt. 20
Men kan een onderscheid maken tussen een proactieve aanpak en een reactieve aanpak. De beste resultaten vindt men als deze beide aanpakken met elkaar in relatie staan.
2.2.1. Proactieve aanpak Een onderneming moet trachten om de onzekerheid te bedwingen vooraleer men begint aan de uitvoering van een project. In die zin zal men de klant een beter voorstel kunnen doen en zal het ook gemakkelijker zijn om aan de verwachtingen van een klant te voldoen. De meest gekende manier om dit te doen, is door middel van het integreren van buffers in de planning. De alom bekende Theory of Constraints (TOC) kan hiervoor worden toegepast. (Patrick, 1998) geeft een goed overzicht van hoe men de TOC moet toepassen in een multiprojectomgeving. Net zoals in de TOC voor singleprojecten gaat men op zoek naar de bottleneck resource, dit is de resource die doorheen de verschillende projecten meer gebruikt wordt dan andere resources. De bottleneck resource wordt de synchronisator genoemd. De snelheid van deze synchronisator zal bepalen hoe vlug projecten worden gelanceerd. Het schema van deze synchronisator, gecombineerd met de kritische paden van de individuele projecten, in TOC de kritische keten genoemd, vormen de basis van een betrouwbaar projectschema. Om dit schema te verkrijgen, kent men eerst een prioriteit toe aan alle projecten (zie infra 4.1). Vervolgens worden de activiteiten die de synchronisator moet uitvoeren, aan hem toegewezen. Tussen de verschillende projecten wordt er een buffer geplaatst, deze buffer wordt capaciteitsbuffer (CB) genoemd. Deze buffer vangt niet enkel de onzekerheid van het projectschema op, maar hierdoor krijgt de synchronisator tijd om te recupereren en om niet-projectgerelateerde activiteiten uit te voeren (zie infra Hoofdstuk 5: Werknemers in een multiprojectomgeving). De activiteiten die niet moeten worden uitgevoerd door de synchronisator, worden rond deze activiteiten ingepland. Deze activiteiten worden aangevuld met een feedingbuffer (FB) en een projectbuffer (PB), volgens de alom bekende TOC-techniek. Een soortgelijke aanpak is te vinden in (Cooper & Budd, 2006). Een voorbeeld van deze aanpak is te vinden in figuur 5. Er werd aangeduid wanneer een bepaalde projectfase werd toegewezen aan de synchronisator. Andere projectfases werden gearceerd. Ook werden de verschillende buffers aangeduid op de figuur.
21
Figuur 5 - Voorstelling van TOC in een multiprojectomgeving
Een andere manier is om de onzekerheid van het hele projectportfolio in acht te nemen (Olsson, 2008). Zo is het bijvoorbeeld mogelijk dat een geheel portfolio bedreigd wordt door eenzelfde risico. Door een geconsolideerde aanpak van dit risico, kan het worden omgekeerd in een opportuniteit. Belangrijk hierbij is om zowel risico’s in de nabijheid van de projectomgeving, als tussen de projecten in het oog te houden. Eveneens is het van groot belang om trends te bestuderen in het portfolio. Zo kunnen onzekerheden tijdig in de kiem worden gesmoord. Dit wordt ook opgemerkt door Raiden, Dainty en Neale. Door middel van correcte systemen en controles, zal de omgeving van de projecten op een goede manier gecontroleerd kunnen worden. Voordelen van deze aanpak kunnen gevonden worden op niveau van de projecten zelf, doorheen het hele portfolio en op het niveau van het volledige bedrijf (Raiden, Dainty, & Neale, 2008). Het is evenzeer steeds belangrijk dat een onderneming slechts zoveel projecten aanneemt als het succesvol kan afleveren (zie supra 1.2). Dit zal de onzekerheid immers beperken. Een belangrijke conclusie hierbij is dat de snelheid van het sluiten van deals onderhevig moet zijn aan de snelheid van de productie (Cooper & Budd, 2006). Men kan dit afwegen aan de hand van de kritische projectfactor (KPF), voorgesteld door Cooper en Budd, en gelijkaardig aan de bottleneck in een productieomgeving. De KPF wordt gedefinieerd als de snelheid van de traagst werkende resource in een bepaald schema. Dit houdt in dat de KPF niet enkel zal bepalen hoe vlug een individueel project kan worden afgewerkt, maar ook de totale capaciteit van de onderneming. Indien men de keuze heeft tussen verschillende projecten, dan zal men kiezen voor het project dat de hoogste winst genereert per eenheid KPF.
22
Herbots et al. noemt de nieuwe projecten de grootste bron van onzekerheid in een dynamische omgeving. Wanneer een onderneming moet beslissen om een project aan te nemen of te negeren, kent zij enkel rudimentaire informatie over het project en is het zeer moeilijk om dan al een goede planning uit te werken (Herbots et al.). Een samenvatting van bovenstaande aanbevelingen is terug te vinden in tabel 8. Proactieve aanpak = onzekerheid bedwingen voor men een project start Door middel van integreren van buffers via de TOC Door middel van het bekijken van het gehele portfolio en proberen risico’s om te keren in een opportuniteit Door middel van de snelheid van het sluiten van deals onderhevig te maken aan de snelheid van projecten afwerken Tabel 8 - Samenvattende tabel omtrent de proactieve aanpak
2.2.2. Reactieve aanpak Bij een reactieve aanpak gaat men acties ondernemen terwijl het project wordt uitgevoerd. Hoe goed men het projectplan op voorhand ook plande, er kan altijd iets mislopen en dan is deze aanpak nodig. In een multiprojectomgeving is het aanpassen van schema’s naarmate de tijd verstrijkt eerder regel dan uitzondering (Kaulio, 2008). De bovenvernoemde auteur geeft een lijst weer van kritische incidenten, die vaak voorkomen in een multiprojectomgeving en aanleiding geven tot een verandering van de planning. Deze lijst is overgenomen in bijlage 1: Lijst van kritische incidenten. Elonen en Arrto geven ook een lijst weer van problemen die kunnen voorkomen in een multiprojectomgeving, zij het toegespitst op ondernemingen die nieuwe producten ontwikkelen. Ook deze lijst is opgenomen in bijlage 2: Lijst van kritische incidenten in ondernemingen die nieuwe producten ontwikkelen. Tussen beide lijsten bestaan geen echte gelijkenissen. Wanneer men een project in een multiprojectomgeving uitvoert moet men dus rekening houden met mogelijke problemen uit beide lijsten. Wat uit beide lijsten wel naar voor komt is dat er vaak slecht gecommuniceerd wordt. De communicatie tussen onderneming en klant verloopt stroef, waardoor er niet voldaan wordt aan de kwaliteitsvereisten; tussen het hoger management en het uitvoerend personeel is er geen communicatie, zodat er geen gerichte leiding kan gegeven worden. Dit zijn slechts enkele voorbeelden. Duidelijke feedback, zowel top-down als bottom-up, is dus zeker noodzakelijk in een multiprojectomgeving. Dit werd in de vorige paragraaf ook aangegeven als één van de aspecten om de complexiteit te bedwingen. 23
Verstoringen in het projectschema worden ook in de hand gewerkt door het ontbreken van recuperatieperiodes na een stresspiek, het onvoldoende aanwezig zijn van routines, het opleggen van een hoge tijdsdruk en een overload aan projecten in een portfolio (Zika et al., 2006). De controle van een multiprojectomgeving ligt meestal in de handen van een projectmanager, hij kan stappen ondernemen als iets fout loopt (Confessore et al., 2006). Zo kan hij bij huidige projecten de werknemers laten overwerken, indien een deadline mogelijks niet gehaald wordt. Eventueel kan hij ook de planning van latere projecten aanpassen, zoals bijvoorbeeld de start van een aantal projecten uitstellen tot een later tijdstip. De huidige situatie geldt immers als input voor toekomstige situaties. Er kan worden opgemerkt dat de projectmanager niet aan alle projecten of alle projectactiviteiten evenveel aandacht moet schenken. Het toezicht over minder belangrijke projecten kan hij overlaten aan een ondergeschikte. Om te bepalen welke projecten hij uit handen kan geven, kan hij zich laten leiden door allerhande prioriteitsregels (zie infra 4.1). Een mogelijke tool waarmee een projectmanager de controle over gedurende de implementatie van een projectschema kan bewaren is de earned value analysis (EVA) (Bagherpour, Zareei, Noori, & Heydari, 2009).
Doordat deze controlemechanisme een tijdige waarschuwing geven, wordt
vermeden dat er extra resources moeten worden toegewezen aan het productieproces. Indien het echter wel nodig is om extra resources toe te wijzen, laat EVA toe te berekenen hoeveel van deze extra resources nodig zijn. Later kan men de gegevens ook gebruiken voor soortgelijke projecten, waardoor steeds beter projectschema’s mogelijk worden. Evenwel is er vaak geen andere mogelijkheid dan de overblijvende projecten opnieuw in te plannen. Het is inherent aan een multiprojectomgeving dat de planning van resources wordt veranderd om zo tot een beter resultaat te komen (Cohen et al., 2007). Deze conclusies werden nog eens samengevat in tabel 9. Reactieve aanpak = bedwingen van onzekerheid tijdens het uitvoeren van een project Oorzaak van onzekerheid: vaak slechte communicatie Deze aanpak wordt georganiseerd door de projectmanager Doch, vaak slechts één mogelijkheid: opnieuw plannen Tabel 9 - Samenvattende tabel omtrent de reactieve aanpak
24
Hoofdstuk 3: Mathematische voorstelling van het probleem: exact algoritme Het probleem rond multiprojectplanning kan in een mathematisch model worden samengevat en in principe op die manier worden opgelost. In deze paragraaf wordt een voorstelling gegeven van zo’n model, dat gebaseerd is op Gonçalves et al. (2008) en Krüger en Scholl (2009). In de literatuur wordt dit het resource constrained multi-project scheduling probleem (RCMPSP) genoemd. Het probleem bestaat eruit dat een set van projecten P moet worden ingepland. Het aantal projecten binnen deze set bedraagt |P|. Elk project pi ε P bestaat uit een set van ni projectfases of activiteiten A, met A = {ai1, …, ain}. Elk van deze activiteiten heeft een bepaalde duurtijd dij en eindigt op fij. Deze waarde zal binnen het model berekend worden. Wel kan men een deadline Fi voor project pi vastleggen, alsook een datum waarop het project ten vroegste van start kan gaan, zijnde Ei. ai1 en ain vormen respectievelijk een start- en eindactiviteit. Dit zijn geen echte activiteiten, waardoor di1 en din beiden gelijk zijn aan nul; zij worden enkel gebruikt om respectievelijk het begin en het einde van een project aan te duiden. De onderneming beschikt over een set van resources R. De beschikbaarheid van een bepaalde resource r ε R wordt weergegeven voor sr. Om een activiteit aij van een project pi tot uitvoering te brengen heeft is er nood aan een hoeveelheid hrij van resource r. Een voorstelling van het RCMPSP wordt gegeven in figuur 6.
25
Figuur 6 - Schematische voorstelling van een multiprojectomgeving
Vervolgens zijn er voor de uitwerking van het model ook nog een aantal andere variabelen nodig. De binaire variabele xrijt wordt 1 indien een bepaalde resource r op tijdstip t gebruikt wordt in project pi voor activiteit aij en 0 indien deze resource niet wordt gebruikt voor deze specifieke activiteit. Hiermee verband houdend is de variabele qrijt, die het aantal resources van type r die op tijdstip t aan een activiteit aij van een project pi zijn toegewezen. De poel aan resources wordt bijgehouden door lrt en vertelt hoeveel resources van soort r nog beschikbaar zijn op tijdstip t. De voorwaarde hierbij is dat 0 ≤ lrt ≤ sr. De binaire variabele vijt wordt 1 indien de activiteit aij van project pi eindigt op tijdstip t. TIij stelt het tijdsinterval voor waarin een activiteit aij van project pi kan plaatsvinden. Indien men niet beschikt over specifieke cijfers met betrekking tot alle activiteiten, kan men voor de waarde van deze variabele gewoon kijken naar de vroegste begindatum Ei en de deadline Fi van het totale project. Een overzicht van de gebruikte symbolen wordt gegeven in bijlage 3: Overzicht van de gebruikte symbolen in het mathematisch model. Er zijn typisch twee manieren om met een multiprojectomgeving om te gaan: de singleprojectaanpak
en
de
multiprojectaanpak
(Browning
&
Yassine,
2010).
Bij
de
singleprojectaanpak aggregeert men alle projecten tot een zeer groot singleproject, terwijl men bij de multiprojectaanpak alle projecten individueel behandelt. Problemen binnen eenzelfde omgeving, 26
maar via een andere aanpak opgelost, kunnen verschillende resultaten opleveren. Aangezien een aggregaat enkel accuraat is voor een gesloten omgeving en de meeste omgevingen open zijn, zal de multiprojectaanpak het meest realistische resultaat geven. In het vervolg van dit hoofdstuk gaat men dan ook uit van een multiprojectaanpak. Onderstaand mathematisch model geeft het RCMPSP weer door middel van een doelfunctie en verscheidene relevante constraints. Doelfunctie:
Minimalisering van één of meerdere kwaliteitsparameters (zie infra 4.3)
Constraints:
(1)
fij + dij ≤ fi(j+1)
(2)
(3)
fi1 ≥ Ei
(4)
(5)
(6)
(7)
(8)
t=0 27
(9)
}
Constraint (1) houdt rekening met de relaties tussen de activiteiten van een project. Constraint (2) zorgt ervoor dat elke activiteit één en slechts één keer wordt uitgevoerd. Constraint (3) houdt rekening houdt met het feit dat een project slechts mag aanvangen vanaf zijn vroegste begindatum, terwijl constraint (4) zegt dat elke activiteit van een project gedaan moet zijn voor de deadline van deze activiteit. Door constraint (5) krijgt elke activiteit de nodige resources toegewezen. Constraint (6) beperkt het aantal keer dat er een resource wordt toegewezen aan een bepaalde activiteit tot de duur van die activiteit. De eigenschap dat activiteiten niet mogen worden onderbroken wordt weerspiegeld in constraint (7). Constraint (8) en (9), ten slotte, houden de stand bij van de poel per resource. Een assumptie die voor dit model wordt aangenomen is dat zowel de projecten als de activiteiten gerangschikt staan volgens een prioriteitslijst. Een opmerking bij constraint (4) is dat deze constraint niet altijd waar te maken is. Indien men te veel projecten aanneemt, dan het niet mogelijk zijn om deze allemaal voor hun deadline te laten eindigen. In dat geval wordt deze constraint beter weggelaten uit het model. Door constraints (5), (7) en (9) kan men hier niet meer spreken van een lineair model, aangezien verscheidene beslissingsvariabelen met elkaar vermenigvuldigd worden. Bovenstaand model is evenwel een abstractie van de werkelijkheid. Men kan het nog realistischer maken door het opnemen van setup tijden in de constraints (Krüger & Scholl, 2009). Indien men bijvoorbeeld in een bouwproject een hijskraan wil verplaatsen, neemt dit inderdaad een zekere tijd in beslag. In de literatuur wordt dit het resource constrained multi-project scheduling problem with transfer times (RCMPSPTT) genoemd. Voor een introductie van het RCMPSPTT in het mathematische model, zie Krüger en Scholl (2010). Met betrekking tot setup van resources werd onderstaand framework ontwikkeld (Krüger & Scholl, 2010). Een onderneming kan zichzelf, of een bepaald portfolio dat deze onderneming behandelt, op het framework plaatsen op drie verschillende niveaus: via management oogpunt, met 28
welke type van setup men te maken heeft en wat de rol van de resources zijn. Dit framework heeft
Rol van de resources in de onderneming
Type setup tijden
Management oogpunt
betrekking op alle mogelijke soorten resources: werknemers, geld, materieel, etc. Negerende aanpak
Reducerende aanpak
Opportunistische aanpak
Setup tijden zijn marginaal, hebben geen kost en worden bijgevolg niet beschouwd in de planning
Setups van resources worden zoveel mogelijk vermeden door het vastleggen van resources aan een bepaald project of projectfase, ook al worden deze resources niet gebruikt.
Setups van resources vinden plaats indien er een positieve payoff is tussen de kosten en de stijgende efficiëntie bij het project waarnaar ze verplaatst worden. Deze aanpak bevat dus zowel de negerende als de reducerende aanpak.
Tijd
Abstractie
Support
Vier subtypes kunnen hier onderscheiden worden, naargelang men te maken heeft met een setup naar het begin of het einde van een bepaalde job toe: - Einde naar start - Start naar einde - Start naar start - Einde naar einde
Hieronder zijn twee subtypes te onderscheiden: - Fysische setups, bv. het verplaatsen van een machine - Niet-fysische setups, bv. het instellen van een machines
Vrije resources
Toegewijde resources
Drie subtypes kunnen onderscheiden worden: - Eenzijdige setup: deze setup gebeurt zonder gebruik van resources - Setup waarbij hernieuwbare resources worden gebruikt - Setup waarbij niethernieuwbare resources worden gebruikt Setup resources
Resource setups zijn verwaarloosbaar en bijgevolg bewegen deze resources zich doorheen het projectschema zonder tijd en kost
Resources worden toegewezen aan een bepaald project, en blijven daar tot de uitvoering ten einde is
Resources zijn onderhevig aan setups, maar hiervoor betaalt een onderneming wel een zekere kostprijs
Tabel 10 - Framework voor het klasseren van resources in een onderneming (Krüger & Scholl, 2009)
Een andere mogelijke uitbreiding van dit model wordt vernoemd in het multimode resourceconstrained project scheduling probleem (MRCPSP). In dit probleem wordt de duurtijd van een activiteit bepaald door het gebruik van resources. Wanneer men in een bouwproject bijvoorbeeld
29
twee bouwvakkers inzet, neemt een activiteit tien dagen in beslag, indien men echter nog een bouwvakker bij dit team toevoegt, duurt de activiteit slechts zeven dagen. Daarnaast kunnen ook buffers worden voorzien, indien men wil gebruik maken van een proactieve aanpak (zie supra 2.2.1). Het probleem, zoals het hierboven wordt voorgesteld, is echter NP-hard en dus onmogelijk om op te lossen (Gonçalves et al., 2008). Het gebruik van heuristieken is de enige manier om het RCMPSP op te lossen (Krüger & Scholl, 2009). Een bewijs wordt hiervoor geleverd door Heimerl en Kolisch (2010) door een multiprojectomgeving te vergelijken met een productieomgeving met meerdere machines. Bovenstaand mathematisch model is evenwel bruikbaar om de werkelijkheid beter te begrijpen. Van dit hoofdstuk wordt in tabel 11 een samenvatting gegeven. Mathematisch model = een abstractie van de werkelijkheid Bestaat uit verschillende variabelen en verschillende constraints Singleprojectaanpak versus multiprojectaanpak NP-hard niet op te lossen Mogelijke uitbreiding: RCMPSPTT en MRCPSP Tabel 11 - Samenvattende tabel omtrent het mathematische model
30
Hoofdstuk 4: Het inplannen van resources met behulp van heuristieken Aangezien, zoals vermeld in hoofdstuk 3 (zie supra), het RCMPSP als NP-hard geclassificeerd wordt, is het gebruik van heuristieken om dit probleem op te lossen noodzakelijk. Het is enkel op deze manier dat planners een aanvaardbare oplossing krijgen voor het multiprojectprobleem. Evenwel moet hierbij worden opgemerkt dat niet alle heuristieken even efficiënt voor alle bedrijven. Een heuristiek werkt het best wanneer die voor een specifiek probleem is opgesteld (Chen & Mohsen Shahandeshti, 2009). Karakteristieken van een probleem hebben immers een enorm effect op de kwaliteit van de oplossing (Browning & Yassine, 2010). Eveneens belangrijk is dat de opvolging van activiteiten en de allocatie van resources aan projecten gezamenlijk geoptimaliseerd worden. Dit komt de kwaliteit van de oplossing ten goede (Lova et al., 2009). Het RCMPSP wordt in de literatuur vaak onderzocht door een softwareprogramma een willekeurig aantal projecten te laten genereren, zoals in (Browning & Yassine, 2010). Door specifieke karakteristieken aan deze gegenereerde projecten toe te voegen, kan men de complexiteit verhogen of specifieke problemen onderzoeken. Heuristieken worden niet enkel gebruikt om een planning op te maken, maar kunnen ook gebruikt worden om deadlines van projecten vast te leggen (Ash, 2009). Nieuwe projecten worden samen met de nog niet uitgevoerde activiteiten van bestaande projecten ingepland en zo wordt bepaald of een bepaalde deadline haalbaar is. Dit is een efficiënte manier om om te gaan met een dynamische omgeving en om het portfoliomanagement te organiseren. Echter moet hierbij opgemerkt worden dat een optimale oplossing met behulp van een heuristiek niet mogelijk is of enkel door toeval wordt bereikt (Cohen et al., 2007). Door het gebruik van heuristieken verkrijgt men evenwel een werkbare oplossing, die men eventueel nog kan verbeteren. Dit hoofdstuk beschrijft hoe men heuristieken toepast op een multiprojectomgeving. In de paragraaf rond prioriteitsregels wordt een overzicht gegeven van hoe men projecten naar belangrijkheid kan rangschikken. Vervolgens worden een aantal voorbeelden van heuristieken gegeven en er wordt afgesloten met enkele parameters om de kwaliteit van een schema te beoordelen.
31
Ook hier kan men gewagen van een singleprojectaanpak en een multiprojectaanpak (zie supra hoofdstuk 3: Mathematische voorstelling van het probleem: exact algoritme). Om de reeds aangehaalde redenen gaan we hier verder met de multiprojectaanpak.
4.1. Prioriteitsregels Door middel van bepaalde regels toe te passen, krijgen ‘belangrijkere’ projecten voorrang op ‘minder belangrijke’ projecten. In deze sectie wordt een niet-exhaustieve opsomming gemaakt van verschillende prioriteitlijsten. Binnen de projecten zelf kan dan eventueel ook nog eens een rangschikking gemaakt worden tussen de verschillende activiteiten volgens welgekende regels (Heimerl & Kolisch, 2010). Het toepassen van verschillende prioriteitsregels op eenzelfde projectportfolio kan verschillende resultaten opleveren. Belangrijk voor deze prioriteitsregels is dat de planning up-to-date wordt gehouden. In een dynamische omgeving arriveren immers steeds nieuwe projecten waardoor de rangschikking grondig kan wijzigen. Hierdoor zal men onderstaande prioriteitsregels steeds weer moeten toepassen (Krüger & Scholl, 2009). Een project dat in eerste instantie niet zo belangrijk lijkt, kan na verloop van tijd helemaal vooraan komen te staan in de prioriteitslijst (Tobis & Tobis, 2002). Prioriteitsregel 1: Earliest due date (Vanhoucke, 2010) (Lova et al., 2009) Volgens deze prioriteitsregel wordt voorrang gegeven aan projecten die dringend zijn. Om te vermijden dat ze slecht scoren op de dimensie tijd (zie supra 1.1), en dus te laat worden afgeleverd, zullen dringendere projecten eerder worden ingepland dan minder dringende projecten. Prioriteitsregel 2: Least slack (Ash, 2009) (Gonçalves et al., 2008) Slack wordt bepaald door de volgende formule: deadline – vroegste begindatum – totale duur van het project. Bij deze prioriteitsregel wordt aan projecten met een kleinere waarde aan slack voorrang gegeven bij het inplannen. Het is hierbij immers zo dat er voor deze projecten minder mogelijkheden zijn om in te plannen dan bij projecten die een grotere waarde aan slack bezitten. Prioriteitsregel 3: Maximale sanctie eerst (Gonçalves et al., 2008) Hierbij worden sancties toegewezen aan projecten indien deze te laat worden afgeleverd. In die zin is het logisch dat projecten met een grotere sanctie voorrang krijgen op projecten met een kleinere sanctie.
32
Prioriteitsregel 4: Kortste activiteit van een project eerst (Krüger & Scholl, 2009) Eerst wordt een rangschikking gemaakt van de kortste activiteiten van de projecten, waarbij de kortste projecten eerst worden gerangschikt. Indien er verscheidene activiteiten een even lange kortste duurtijd hebben, worden deze onderling nog eens gerangschikt naargelang de duur termijn van het kritisch pad, van kortste kritisch pad naar langste kritisch pad. Prioriteitsregel 5: Maximale projectduur eerst (Krüger & Scholl, 2009) Men kijkt naar het kritisch pad en rangschikt de projecten met een langer kritische pad eerst. Projecten die een langer kritisch pad hebben zijn door hun grootte immers minder flexibel in te plannen dan projecten met een minder lang kritisch pad. Prioriteitsregel 6: Maximaal aantal resources nodig eerst (Krüger & Scholl, 2009) De projecten die het meeste resources nodig hebben worden eerst gerangschikt. Deze regel wordt gehanteerd om redenen van flexibiliteit, net zoals bij prioriteitsregel 5. Prioriteitsregel 7: Maximale kost eerst (Heimerl & Kolisch, 2010) Bij deze prioriteitsregel worden de projecten die de grootste kost inhouden eerst ingepland, aangezien zij het meeste risico behelzen. Zij verdienen daarom het meeste aandacht. Deze prioriteitsregel is quasi gelijk aan prioriteitsregel 6, aangezien het de resources zijn die meestal de grootte van de kost van een project bepalen. Een andere mogelijke prioriteitsregel is het willekeurig inplannen van projecten (Krüger & Scholl, 2009). Deze regel wordt echter niet in acht genomen, omdat het altijd beter is een bepaalde redenering achter de prioriteitsregel te hebben en zodoende tot een beter schema te komen, dan dat men het gewoon overlaat aan het toeval.
4.2. Inplannen van de projecten In deze paragraaf wordt uitgelegd hoe men resources aan een project kan toewijzen. Aangezien deze resources de limiterend factor zijn, wordt hierdoor ook de uiteindelijke planning bepaald. Men kan, wanneer men onderzoek doet, een dynamische omgeving creëren door de projecten willekeurig te genereren. Op die manier wordt de onzekerheid, die zo kenmerkend is voor een multiprojecomgeving, binnen het schema ingelijfd (Cohen et al., 2007).
33
4.2.1. Het verkrijgen van een initiële oplossing In dit deel wordt besproken hoe men, door toepassing van een bepaalde prioriteitsregel, tot een initieel projectschema kan komen. Serieel inplannen van activiteiten (Krüger & Scholl, 2009) Bij serieplanning begint een planner met de prioriteitslijst. Het project dat eerst voorkomt in de prioriteitslijst wordt ingepland vanaf het tijdstip dat dit mogelijk is, er wordt dus gekeken naar de vroegste begindatum. Daarna gaat de planner over naar het volgende project in de prioriteitslijst. Dit project wordt weer ingepland, rekening houdend met de vroegste begindatum. Ook het aantal resources dat gebruikt wordt door het vorige project moet worden in acht genomen. Men voert deze handeling vervolgens uit tot alle projecten zijn ingepland. Een precieze uitwerking van deze methode is te vinden in (Krüger & Scholl, 2009). Parallel inplannen van activiteiten (Krüger & Scholl, 2009) Een parallelplanning begint bij het tijdstip nul. Het selecteert uit de prioriteitslijst alle projecten die vanaf dat tijdstip kunnen worden ingepland. Daarvan worden de projecten gekozen en ingepland die voldoen aan de opgelegde constraints met betrekking tot de resources. Vervolgens itereert men het tijdstip en voert men voorgaande handelingen uit, tot alle projecten zijn ingepland. Een precieze uitwerking van deze methode is opnieuw te vinden in (Krüger & Scholl, 2009). Dit algoritme wordt ook bestudeerd in Chen en Mohsen Shahandeshti (2009), hoewel het daar Next Time Frame algoritme genoemd wordt en men daar geen gehele projecten gaat inplannen, maar gaat plannen per projectfase.
4.2.2. Het verbeteren van de initiële oplossing Het verbeteren van deze initiële oplossing kan door toepassing van verbeteringsalgoritmes. In deze paragraaf worden drie mogelijke metaheuristieken voorgesteld en vergeleken: het simulated annealing algoritme (SA), het genetisch algoritme (GA) en een hybride vorm van SA en GA. Deze zijn specifiek voor de toepassing op een multiprojectomgeving. Onderstaande voorstelling is volledig gebaseerd op (Chen & Mohsen Shahandeshti, 2009), behalve waar anders aangeduid. Simulated annealing algoritme (SA) SA werkt met dalende temperaturen. Men begint bij een initiële oplossing. Deze kan willekeurig gekozen worden, of met behulp van bovenstaande algoritmes. Aan deze initiële oplossing kent men 34
een initiële temperatuur toe. Een kwaliteitsparameter wordt eveneens berekend. Vervolgens wordt een nieuwe oplossing gegenereerd die in de buurt ligt van de initiële oplossing. Dit wordt gedaan door het omwisselen van de volgorde van twee activiteiten en is vergelijkbaar met mutatie in het GA. Natuurlijk moeten onderlinge relaties hier in acht worden genomen. Figuur 7 geeft een voorbeeld van een wissel tussen twee activiteiten. In de figuur wordt de volgorde van plannen weergegeven door een opeenvolging van verschillende activiteiten. Deze activiteiten kunnen tot verschillende projecten behoren. De verbetering van het schema gebeurt eenvoudigweg door het omwisselen van activiteiten 2 en 5.
Figuur 7 – Voorbeeld van een mutatie
Indien de kwaliteitsparameter een betere waarde heeft dan bij de vorige oplossing wordt de nieuwe oplossing behouden. Deze methode wordt verschillende malen toegepast tot een bepaald criteria wordt behaald. Dit criteria kan eenvoudigweg een vooraf bepaald aantal iteraties zijn dat moet worden uitgevoerd. Daarna wordt de initiële temperatuur verlaagd en wordt er opnieuw een initiële oplossing aan deze temperatuur toegewezen. De hierboven beschreven methode wordt vervolgens weer toegepast. De temperatuur wordt herhaaldelijk verlaagd tot opnieuw een criteria met betrekking tot de temperatuur wordt behaald. De snelheid waarmee de temperatuur afneemt, wordt de cooling rate genoemd. De oplossing met de hoogste waarde voor de beschouwde kwaliteitsparameters wordt gekozen als eindoplossing. Bovenstaande werkwijze wordt schematisch voorgesteld in figuur 8.
35
Figuur 8 – Schematische voorstelling van simulated annealing (Chen & Mohsen Shahandeshti, 2009)
Bij deze oplossingsmethode bestaat het gevaar dat men dreigt vast te raken in een lokaal optimum. Om dit gevaar te vermijden, kan men gebruik maken van modified simulated annealing (MSA). Hierbij gaat men naarmate de temperatuur daalt, een minder aantal iteraties toepassen. Onderzoek wees immers uit dat bij een hoge temperatuur de beste oplossingen worden behaald bij de laatste iteraties, terwijl er bij een lagere temperatuur niet echt sprake is van zulke regels. Door het aantal iteraties naar het einde toe te verlagen, zal men vlugger tot een oplossing komen. Genetische algoritmes (GA) Deze techniek is gebaseerd op natuurlijke selectie en survival of the fittest. Er wordt begonnen met een aantal initiële oplossingen, hetgeen men de populatie noemt. Deze kunnen willekeurig gekozen zijn, of met behulp van de algoritmes uit sectie 4.2.1 (zie supra). Vervolgens gaat men door 36
bepaalde bewerkingen uit te voeren, combinaties maken van de initiële oplossingen. Deze bewerkingen bestaan uit selectie, crossover en mutatie. Eerst gaat men twee oplossingen selecteren, dit gebeurt op willekeurige wijze. Daarna wordt door middel van crossover een combinatie gemaakt van de twee gekozen oplossingen. Vervolgens kan de gegenereerde nieuwe oplossing nog verder worden aangepast, door middel van mutatie (zie ook SA). Regels met betrekking tot crossover en mutatie worden besproken in (Vanhoucke, 2010). De verkregen oplossing noemt men een nieuwe generatie. In figuur 9 wordt een crossover voorgesteld. De volgorde van planning is hier weer voorgesteld als een opeenvolging van activiteiten van verschillende projecten. De huidige populatie bestaat uit ouder 1 en ouder 2. Via de regel order crossover (Vanhoucke, 2010) wordt een nieuwe generatie gecreëerd.
Figuur 9 - Voorstelling van crossover in een GA
Door het steeds opnieuw toepassen van selectie, crossover en mutatie verkrijgt men alsmaar nieuwe populaties. De elementen van deze populaties worden steeds aan elkaar afgewogen door middel van kwaliteitsparameters, in het GA fitnesswaarden genoemd. Enkel de elementen met een hoge waarde voor de beschouwde parameters worden gebruikt om een nieuwe generatie te genereren. De procedure wordt gestopt wanneer men een vooraf bepaald criteria bereikt, bijvoorbeeld een beperkt aantal iteraties of een bepaalde waarde voor de kwaliteitsparameter. De oplossing met de beste kwaliteit, zal gebruikt worden in de planning. Lova et al. (2009) stelt dat de efficiëntie van het GA verhoogd kan worden door op voorhand inefficiënte en onmogelijke combinaties uit te sluiten. Indien een oplossing bereikt is, argumenteren zij dat door toepassing van een achterwaartse en voorwaartse controle. Bij achterwaartse controle begint men bij het einde van het schema en bekijkt men of men door middel van het naar voren in het projectschema verplaatsen van de activiteiten in het daartoe beschikbare tijdsframe een beter resultaat kan verkrijgen. Bij voorwaartse controle past men dezelfde procedure toe, maar begint men 37
aan het begin van het schema en gaat men de activiteiten naar achteren pogen te verschuiven. In beide methodes verplaatst men bij voorkeur activiteiten die een kortere tijdsduur hebben. He GA wordt ook besproken in Gonçalves et al. (2008) en Kumanan et al. (2006). SA-GA hybride Deze hybride vorm is een combinatie van de twee bovenstaande algoritmes. Eerst produceert men een pool aan initiële oplossing waaraan een begintemperatuur wordt toegewezen. Hieruit worden twee oplossingen geselecteerd die een dalende probabiliteit hebben op een mindere kwaliteit. Vervolgens worden crossover en mutatie op deze oplossingen toegepast. Naarmate het aantal iteraties stijgt, neemt de impact die een mutatie heeft af. Indien de kwaliteit van de verkregen oplossing beter is dan de kwaliteit van een andere oplossing in de populatie, wordt deze vervangen. Hierna wordt de temperatuur vermindert. Bovenstaande bewerkingen worden opnieuw uitgevoerd tot een vooraf bepaald criteria wordt behaald. Dit algoritme kan worden toegepast voor alle multiprojectproblemen en is niet beperkt tot een bepaald type probleem (Chen & Mohsen Shahandeshti, 2009). De werkwijze wordt schematisch voorgesteld in figuur 10.
38
Figuur 10 - Schematische voorstelling van de hybride SA-GA (Chen & Mohsen Shahandeshti, 2009)
4.3. Kwaliteitsparameters De kwaliteit van een bepaald schema kan worden gemeten aan de hand van een aantal parameters. Veelal hebben deze parameters betrekking op één of meerdere dimensies, besproken in sectie 1.1 (zie supra). Deze parameters kunnen ook gebruikt worden in een mathematisch model als doelfunctie. Net
zoals er verschillende
prioriteitsregels bestaan, bestaan er ook
verschillende
kwaliteitsparameters. Wanneer men de kwaliteit van verschillende schema’s met elkaar gaat vergelijken, kan het zijn dat de verschillende kwaliteitsparameters elkaar tegenspreken. Het is dan ook zaak om steeds verschillende parameters te gaan bekijken en te analyseren om zo tot het
39
schema te komen dat het meest accuraat is voor de onderneming waarvoor de projecten moeten gepland worden. Onderstaande opsomming is een niet-exhaustieve lijst. Kwaliteitsparameter 1: Totale tijd om het schema te vervolmaken (Vanhoucke, 2010) Bij deze kwaliteitsparameter gaat men de totale tijd, die nodig is om alle projecten af te werken, voor verschillende mogelijke schema’s gaan vergelijken. Het schema waarbij hier de minste tijd nodig is, zal het meest kwalitatieve schema zijn. Kwaliteitsparameter 2: Makespan (Vanhoucke, 2010) Hierbij gaat men de tijd nemen van het project dat het langst duurt en deze gaan vergelijken voor verschillende projectschema’s. Hierbij kan opgemerkt worden dat voor verschillende projectschema’s niet altijd hetzelfde project de langste duurtijd zal hebben. Opnieuw is het meest kwalitatieve schema het schema dat de laagste makespan bezit. Kwaliteitsparameter 3: Mean project set flow time (Ash, 2009) Deze kwaliteitsparameter beschouwt het gemiddelde van de duurtijd, zijnde einddatum – begindatum, van alle projecten binnen een projectschema. Het schema waarbij deze kwaliteitsparameter wordt geminimaliseerd is het meest kwalitatieve. Kwaliteitsparameter 4: Totale vertraging (Vanhoucke, 2010) Deze kwaliteitsparameter gaat van alle projecten die te laat worden afgeleverd, de duur waarmee ze hun deadline overschrijden samentellen. Het meest kwalitatieve schema is hier opnieuw waar deze kwaliteitsparameter wordt geminimaliseerd. Kwaliteitsparameter 5: Maximale vertraging (Vanhoucke, 2010) Hierbij wordt het project dat zijn deadline het meest overschrijdt, gekozen. Hier wordt dus verondersteld dat een minimale waarde van deze parameter leidt tot een betere kwaliteit. Net zoals bij kwaliteitsparameter 2 kan men hier opmerken dat de waarde van deze kwaliteitsparameter voor verschillende schema’s niet altijd bij hetzelfde project wordt gemeten.
40
Kwaliteitsparameter 6: Het aantal jobs dat hun deadline overschrijdt (Vanhoucke, 2010) Opnieuw wordt voor deze parameter gekeken naar de projecten die hun deadline overschrijden. Het meest kwalitatieve schema is datgene waar deze kwaliteitsparameter wordt geminimaliseerd. Kwaliteitsparameter 7: Gemiddelde vertraginga (Ash, 2009) (Confessore et al., 2006) Deze parameter berekent het gemiddelde van de tijdsduur waarmee projecten hun deadline overschrijden. Opnieuw wordt deze parameter best geminimaliseerd. Kwaliteitsparameter 8: Mean resource utilisation rate (Ash, 2009) Hierbij gaat men kijken in welke mate de schaarse resources tewerk worden gesteld. Deze kwaliteitsparameter benadert hierbij best de 100%, aangezien men dan het meest winstgevend is. Kwaliteitsparameter 9: Minimalisatie van de kosten met betrekking tot resources (Wuliang & Chengen, 2009) Hier worden de resources zodanig ingepland dat de totale kost geminimaliseerd wordt. Eenvoudig gezien kan men hier werken met de loonkosten voor de werknemers, verbonden aan het project, aangezien deze op voorhand gekend zijn. Hierbij kan men dan een onderscheid maken tussen het normale salaris en kosten voor overuren. Kwaliteitsparameter 10: Combinatie (Gonçalves et al., 2008) Hierbij wordt een combinatie gemaakt van de vertraging Ti, de vroegheid Ei en de afwijking van de flow time van een projectschema FDi. Volgende formule wordt gebruikt:
Met a, b en c parameters, gekozen door de planner Met
=
a
In de paper Ash (2009) wordt deze parameter mean project duration genoemd. Ik vond dat deze benaming echter niet paste bij de omschrijving en heb deze parameter, zoals in Confessore, Giordani en Rismondo (2006), gemiddelde vertraging genoemd, hetgeen meer aansluit bij de betekenis van deze parameter.
41
4.4. Samenvattende tabel van hoofdstuk 4 Alle aangewende technieken worden nog eens opgesomd in tabel 12. Prioriteitsregels Earliest due date Least slack Maximale sanctie eerst Kortste activiteit van een project eerst Maximale projectduur eerst Maximaal aantal resources nodig Maximale kost eerst Verkrijgen van een initiële oplossing Serieel inplannen van activiteiten Parallel inplannen van activiteiten Verbeteren van de initiële oplossing Simulated annealing Genetisch algoritmes SA-GA hybride Kwaliteitsparameters Totale tijd om een schema te vervolmaken Makespan Mean project set flow time Totale vertraging Het aantal jobs dat hun deadline overschrijft Gemiddelde vertraging Mean resource utilisation rate Minimalisatie van de kosten met betrekking tot resources Combinatie Tabel 12 - Samenvattende tabel van hoofdstuk 4
42
Hoofdstuk 5: Werknemers in een multiprojectomgeving In de vorige paragrafen werd het gebruik van resources al uitvoerig besproken. Werknemers behoren hier ook toe en alle conclusies die gemaakt werden ten opzichte van deze resources, gelden dan ook voor werknemers. In sommige paragrafen werd ook dieper ingegaan op heel specifieke werknemers, zoals projectmanagers in sectie 1.3 (zie supra), omdat het onderwerp van die paragraaf daarom vroeg. In deze paragraaf worden echter een aantal bevindingen die specifiek gelden voor werknemers op een rijtje gezet. Zoals eerder vermeld werd, bestaat er in een multiprojectomgeving een veel hogere kans dan in een singleprojectomgeving dat kennis tussen werknemers wordt overgedragen. Evenwel mag men niet uit het oog verliezen dat er steeds een nood is aan degelijke trainingen (Zika et al., 2006). Dit is belangrijk voor de langetermijnontwikkeling van de onderneming. Ook wordt gesteld dat in een multiprojectomgeving werknemers multiskilled zijn, hetgeen wil zeggen dat ze meerdere soorten activiteiten kunnen uitvoeren (Heimerl & Kolisch, 2010). Dit is een verschilpunt met een productiegerichte omgeving waar werknemers vaak worden ingezet om één taak te vervullen. In vele multiprojectomgevingen worden werknemers toegewezen door de projectmanager of projectleider aan een bepaald project, zoals in de voorbije paragrafen steeds werd aangenomen. Sommige auteurs, zoals Zika-Viktorsson et al. (2006), beschrijven het toewijzen van werknemers veeleer als een competitie, waarbij de werknemers zelf strijden om toegewezen te worden aan een bepaald project. Deze situatie komt voor wanneer er verschillende projectmanagers tegelijkertijd om werknemers vragen. Hierdoor zouden werknemers op te veel projecten terzelfder tijd worden ingezet en kan men spreken van projectoverload, waardoor deze werknemers niet meer efficiënt kunnen bezig zijn met hun opgelegde taken. Projectoverload wordt in de hand gewerkt door het ontbreken van recuperatieperiodes na een stresspiek, het onvoldoende aanwezig zijn van routines, het opleggen van een hoge tijdsdruk en het te veel aan projecten in een portfolio. Werknemers ervaren hierdoor meer stress en voeren toegewezen taken minder goed uit. Dit kan aanleiding geven tot verstoringen in het projectschema. Deze verstoringen aan de andere kant leiden dan op hun beurt weer tot meer projectoverload. Het probleem kan deels verholpen worden door prioriteiten beter kenbaar te maken. Ook Patrick (1998) geeft aan dat het tezelfdertijd inzetten van een werknemer op verschillende projecten, het zogenaamde multitasking, nefast is voor de tijdige uitvoering van een project,
43
aangezien prioriteiten elkaar kunnen overlappen. Men mag slechts beginnen aan een bepaalde taak wanneer men er zeker van is dat de vorige taak is afgewerkt. Daarnaast kan men ook spreken van een leerproces tijdens projecten. Meestal worden de zaken die geleerd worden meegenomen naar een volgend project. Zodoende kunnen volgende soortgelijke projecten vlugger worden uitgevoerd. Dit leerproces kan zich echter ook voltooien gedurende een project, vooral in geval van een zeer groot project (Aramo-Immonem & Vanharanta, 2009). In zo’n omgeving moet men steeds streven naar een continue verbetering van de werknemers hun skills. Sowieso neemt de kost binnen een multiprojectomgeving af, indien werknemers meerdere skills bezitten (Heimerl & Kolisch, 2010). Het leerproces is vooral relevant voor startende ondernemingen (Midler & Silberzahn, 2008).
44
Deel II: Case studie
45
Inleiding Door middel van een case studie wordt de opgedane kennis uit de literatuur getoetst aan de realiteit. In deze case studie wordt een bedrijf, werkzaam in een multiprojectomgeving, onder de loep genomen. Enerzijds wordt bekeken welke kenmerken die men in de literatuur toedicht aan een multiprojectomgeving, ook terugvindt in dit bedrijf. Anderzijds wordt voor dit bedrijf een projectschema opgemaakt, waarop een empirisch onderzoek wordt toegepast. Het bedrijf waarover deze case studie gemaakt wordt, is De Vroe Groep (DVG). Dit bedrijf, gevestigd te Merelbeke, is werkzaam in de bouwsector. Mijn contactpersoon in DVG is bedrijfsleider Johan De Vroe, van wie ik alle gegevens, nodig voor deze case studie, heb verkregen. Voor verdere contactgegevens en een overzicht van alle gesprekken die gevoerd zijn, zie bijlage 4: Contactgegevens en overzicht van de gesprekken met DVG. In het eerste hoofdstuk van deze case studie wordt de werking van het bedrijf vergeleken met de conclusies die getrokken werden uit de literatuur. Vervolgens wordt de methodologie van het empirisch onderzoek weergegeven. Daar wordt onder andere het softwareprogramma besproken dat speciaal voor dit empirisch onderzoek werd gemaakt. Het laatste hoofdstuk wordt gewijd aan de resultaten van de empirische studie.
46
Hoofdstuk 6: Situering van het bedrijf In dit hoofdstuk wordt DVG nader besproken. In de eerste paragraaf wordt zeer kort de geschiedenis van het bedrijf overlopen. Vervolgens wordt dieper ingegaan op de aard van de werkzaamheden in DVG. In de derde paragraaf worden de resources in DVG besproken. Er wordt veel nadruk gelegd op de schaarse resources en de projectmanagers in het bedrijf. Daaropvolgend wordt het projectportfoliomanagement bestudeerd. Nadien wordt de huidige manier van plannen behandeld. Ten slotte worden nog paragrafen gewijd aan hoe DVG de complexiteit en de onzekerheid tracht te bedwingen. Er worden zoveel mogelijk links gelegd met de opgedane kennis uit de literatuur. Wanneer een bepaald aspect geen raakvlakken heeft met deze theoretische kennis, wordt dit ook aangehaald. De laatste paragraaf is hiervan een samenvatting.
6.1. Geschiedenis van het bedrijf DVG is begonnen als een bedrijf dat zich specialiseerde in dakwerken. Naderhand heeft men zich dan ook gespecialiseerd in dakwerken die een grote technische kennis vragen. Na verloop van tijd werden ook ruwbouw, buiten- en binnenschrijnwerkerij, houtskeletbouw en het plaatsen van zonnepanelen aan het takenpakket toegevoegd.
6.2. Werkzaamheden binnen het bedrijf De projecten die worden uitgevoerd in DVG kunnen bestaan uit vijf verschillende fases: ruwbouw, timmerwerk, zinkwerk, dakwerk voor een hellend dak en dakwerk voor een platdak. In de laatste twee fases kan het plaatsen van zonnepanelen ook nog inbegrepen zijn, en wordt dus niet aanzien als een aparte projectfase. In figuur 11 wordt de work-breakdown-structure weergegeven. Hieruit blijkt dat de eerste drie fases steeds in de volgorde ruwbouw – timmerwerk – zinkwerk moeten worden uitgevoerd. Voor een bepaald project kan de dakbewerking niet worden uitgevoerd indien de ruwbouw, het timmerwerk en het zinkwerk nog niet zijn afgerond. Elke fase wordt vervaardigd door een ander team, naargelang de skills van dat team (zie infra 6.3). Men maakt een onderscheid tussen het bedekken van een plat dak en een hellend dak, omdat daarvoor andere vaardigheden nodig zijn.
47
Figuur 11 - WBS van een project in DVG
Bedrijfsleider Johan De Vroe vindt het echter niet bevorderlijk dat twee teams terzelfder tijd aan eenzelfde project werken. Het maakt niet uit of men eerst aanvangt met de werken aan het hellend gedeelte van het dak of het platte gedeelte van het dak. De algemene WBS ziet er dus veeleer uit zoals in figuur 12 en figuur 13, naargelang met welke fase men eerst begint.
Figuur 12 - Algemene WBS indien men eerst aanvangt met de werken aan het platte dak
Figuur 13 - Algemene WBS indien men aanvangt met de werken aan het hellende dak
Een ander aspect is dat binnen een project niet alle fases hoeven te doorlopen worden; men kan immers opteren om enkel de ruwbouw te laten uitvoeren door DVG; het is ook mogelijk om enkel dakwerken te laten uitvoeren, etc. Er zijn dus, met andere woorden, verschillende WBSs mogelijk. De duurtijd en de hieraan gekoppelde nood aan resources is voor elk project verschillend. Projecten kunnen een duurtijd hebben van één dag tot verschillende maanden. DVG is werkzaam in een multiprojectomgeving aangezien verschillende projecten terzelfder tijd door verschillende teams worden uitgevoerd (zie supra Hoofdstuk 1: Wat is multiprojectplanning?).
48
6.3. Schaarse resources De schaarse resources bestaan uit de arbeiders. DVG stelt momenteel 55 mensen tewerk die zorgen voor de uitvoering van de bouwprojecten. Deze zijn onderverdeeld in 23 teams. Elk team heeft zijn eigen specialiteit. Ruwbouw vereist bijvoorbeeld immers andere vaardigheden dan dakbedekking. In bijlage 5: Overzicht van de teams werkzaam in DVG, is een overzicht van de verschillende teams te vinden. Zoals men kan zien, zijn al deze werknemers single-skilled. Dit is in tegenspraak met de conclusie van Heimerl en Kolisch (2010), die uitgaat van het feit dat de meeste werknemers in een multiprojectomgeving multi-skilled zijn, besproken in hoofdstuk 5 (zie supra). Ook is er niet echt sprake van capaciteitsplanning (zie supra 1.2). Het aantal werknemers is veeleer historisch gegroeid door steeds meer en meer werk aan te nemen. Indien er op een bepaald ogenblik toch een groot tekort aan arbeiders zou zijn, kan men ook interims inschakelen, of kan men beroep doen op onderaannemers. Dit maakt het plannen iets flexibeler. Men kan natuurlijk nooit op voorhand zeggen of men interims of onderaannemers op een bepaald ogenblik ter beschikking zal hebben, en daardoor mag met nooit uit het oog verliezen dat dit slechts hulpmiddelen zijn. Omdat de teams verschillende groottes hebben, hangt de duurtijd van een project volledig af van het team dat aan dit project wordt toegekend. In de literatuur spreekt men dan van het multimode resource-constrained project scheduling probleem (MRCPSP), zoals dit besproken wordt in hoofdstuk 3 (zie supra). Een ander probleem dat in datzelfde hoofdstuk besproken wordt, is het RCMPSPTT. Men kan echter stellen dat dit probleem niet van toepassing is op DVG. Elke morgen verzamelen de arbeiders op de vestiging van DVG. Zij worden dan gebrieft en vertrekken naar hun bouwwerf. Aldus zijn setups van resources hier te verwaarlozen. Vanuit management oogpunt kan men dus een negerende aanpak hanteren (zie supra hoofdstuk 3: Mathematische voorstelling van het probleem: exact algoritme). De werknemers kan men vrije resources noemen, aangezien zij zich zonder kosten doorheen het projectschema bewegen. Dit aspect is zeer belangrijk voor de reactieve aanpak, die het bedrijf aanwendt (zie infra 6.7). In de empirische studie van deze case wordt geen rekening gehouden met andere werknemers. Er zijn in DVG ook nog magazijniers, vrachtwagenbestuurders, etc. aan de slag. Ook de bedienden die bestellingen doen, de planningen opmaken of offertes maken, worden niet beschouwd. De reden hiervoor is dat zij niet echt betrokken zijn bij het uitvoeren van een project en dus niet worden opgenomen in de planning. 49
Andere gebruikte resources door het bedrijf kunnen kranen, containers, etc. zijn. Omdat die echter gemakkelijk te verkrijgen zijn bij derden, worden deze niet als schaars verondersteld. Managers die specifiek aan één bepaald project worden toegewezen, zoals besproken in sectie 1.3 (zie supra), kent DVG niet. Daarvoor zijn de projecten van een te kleine schaal. Alle projecten worden dan ook gecoördineerd en opgevolgd door meneer De Vroe zelf, of één van zijn directe medewerkers. Zij zijn geen projectmanagers in de strikte zin van het woord, omdat ze ook nog andere taken vervullenb. Evenwel kunnen ze wel dit etiket worden opgekleefd. Door de kleinere schaal van de onderneming houden de projectmanagers zich dus met meer dan vier projecten tegelijkertijd bezig, hetgeen één van de bevindingen, besproken in sectie 1.3 (zie supra), tegenspreekt. Aangezien alle informatie centraal beschikbaar is, spreekt men hier dus van een gecentraliseerde aanpak. Door deze gecentraliseerde aanpak is het ook niet zo dat werknemers in competitie met elkaar treden om toegewezen te worden tot een bepaald project, zoals in hoofdstuk 5 (zie supra) besproken wordt. Nog een verschilpunt met de literatuur is dat er geen strikt onderscheid wordt gemaakt tussen projectmanagers en projectleiders. Dit is door de kleinere schaal van de onderneming niet mogelijk. Bedrijfsleider Johan De Vroe is zowel verantwoordelijk voor management als voor leiderschap, hij heeft zowel een interne als een externe focus. Het framework, besproken in sectie 1.3 (zie supra), is hier dus niet van toepassing. Ondanks het ontbreken van deze strikte scheiding, is het voor de DVG wel mogelijk om gepast op onzekerheden te reageren (zie infra 6.7). In tabel 13 worden de bevindingen uit deze paragraaf nog eens kort samengevat. Schaarse resources Vooral werknemers Single-skilled Vrije resources Opereren in een MRCPSP-omgeving Andere resources Bedienden, chauffeurs, materiaal, etc. Projectmanagers zijn verantwoordelijk voor een verscheidenheid aan projecten Geen onderscheid tussen projectmanagers en projectleiders Tabel 13 - Samenvattende tabel in verband met de resources van DVG
b
Meneer De Vroe houdt zich bijvoorbeeld ook nog bezig met klantenwerving.
50
6.4. Projectportfoliomanagement Een particulier die zijn bouwproject, of dit nu een simpele herstelling of een volledig huis is, wil laten uitvoeren door DVG, maakt dit kenbaar aan de hand van een telefoongesprek of een e-mail. DVG gaat de haalbaarheid van dit project onderzoeken en maakt een offerte op. De projecten die DVG tracht aan te nemen, zijn deze met hogere moeilijkheidsgraad. Zoals eerder vermeld werd, heeft de DVG zich immers gespecialiseerd in dakwerken die een hogere moeilijkheidsgraad betreffen. Dit is enigszins de strategie van het bedrijf en komt overeen met conclusies in sectie 1.2 (zie supra). Daarnaast gaat DVG kijken naar de afstand tussen de vestiging van DVG en het project. Aangezien DVG werkzaam is in een build-to-order omgeving, moet men immers steeds naar het project zelf toe gaan. Men opteert daarom voor projecten die in de omgeving van DVG liggen, met andere woorden in de Gentse regio. Dit wordt in de literatuur nergens besproken, hoewel het een belangrijk punt is om een project al dan niet te weigeren. Ook houdt men rekening met de planning die al is opgemaakt. Indien een project daarin past, kan een offerte worden opgemaakt. Indien het niet in de planning past, wordt het geweigerd, aangezien de afwerking van andere projecten hierdoor in het gedrang komt. Men ziet hierin een duidelijke integratie van de verkoop- en de planningsfunctie, zoals beschreven wordt in sectie 1.2 (zie supra). Eveneens is de reden waarom men dit doet, dezelfde als degene die beschreven wordt in de literatuur: het foutloos kunnen uitvoeren van andere, al ingeplande projecten. Ten slotte neemt men ook liefst zoveel mogelijk projecten aan die bestaan uit zowel ruwbouw, timmerwerk en dakwerk. Dit komt omdat deze projecten vaak het meest winstgevend zijn. Deze reden komt overeen met de conclusie van Herbots et al., eveneens beschreven in sectie 1.2 (zie supra). Indien aan alle factoren is voldaan, wordt een offerte opgemaakt, die wordt voorgelegd aan de klant. De klant kan dan nog verdere aanpassingen doen en beslissen om het project te laten uitvoeren door DVG. Het is duidelijk dat DVG opereert in een dynamische omgeving, zoals beschreven in sectie 1.2 (zie supra). Spoedprojecten kunnen immers ten allen tijde binnenkomen en de gehele planning wijzigen. Eveneens kan men stellen dat DVG zich in een open omgeving bevindt (zie supra 1.3). Door invloeden van buitenaf, zoals het weer of ziekte van een werknemer, kan het projectschema grondig verstoord worden. 51
Tabel 14 geeft een samenvatting weer van de factoren die in acht genomen worden bij het beslissen of een project wordt aangenomen of niet.
Integratie van operaties en strategie: moeilijkheidsgraad van een project hoe hoger het niveau, hoe gretiger DVG is om het aan te nemen Afstand: DVG prefereert projecten in de nabije omgeving van hun vestiging Integratie van verkoop- en planningsfunctie: een project wordt aangenomen indien het de huidige planning niet overhoop haalt Winst: projecten die doorheen zoveel mogelijk projectfases lopen, hebben een voorkeur, aangezien deze een hogere winstmarge hebben Tabel 14 - Samenvatting van de factoren waarom DVG een project prefereert boven een ander
6.5. Hoe de planning momenteel verloopt Wanneer een offerte is goedgekeurd, gebruikt men het softwareprogramma ‘Build’ om de precieze duurtijd van het project zo goed mogelijk in te schatten. Dit softwareprogramma houdt rekening met verscheidene parameters: welke oppervlakte moet bedekt worden bij een dakbedekking, wat is de moeilijkheidsgraad van een project, etc. Voor het echte inplannen wordt momenteel MS Excel gebruikt. Door middel van een kleurenschema en het gebruik van opmerkingen wordt er gepoogd een overzichtelijk schema te verkrijgen van de werken. Een project wordt ongeveer vier maanden voordat het moet worden uitgevoerd, opgenomen in deze planning. Zodoende tracht men een goed schema te verkrijgen en naarmate de uitvoeringsdatum nadert, een betrouwbare planning voor te leggen aan de klanten. Dit is vooral noodzakelijk voor die projecten waarbij een boeteclausule voor het overschrijden van de afgesproken termijn, wordt overschreden. Het excelbestand wordt momenteel up-to-date gehouden door de bedrijfsleider Johan De Vroe zelf. Hij is er dagelijks meerdere uren mee bezig. Aanpassingen doorvoeren is zeer complex, omdat hierdoor het hele schema wordt gewijzigd. Met andere woorden, het wijzigen van één project heeft implicaties voor het gehele schema, wat zo typisch is voor een multiprojectomgeving. Wanneer meneer De Vroe echter afwezig is, kunnen dringende wijzigingen niet worden doorgevoerd, omdat er niemand is die de logica achter het excelbestand snapt. 52
Eén van de redenen waarom meneer De Vroe wilde meewerken aan de verwezenlijking van deze masterproef is omdat hij het softwareprogramma dat gebruikt wordt om hypotheses uit de literatuur te testen, werkelijk zou willen gebruiken in zijn bedrijf. Naar eigen zeggen is er immers nog geen softwareprogramma dat het plannen van projecten in KMO’s uitvoert. Sommige collega’s gebruiken MS Projects, maar de specificaties van dit programma zijn te beperkt om te gebruiken in de realiteit.
6.6. Complexiteit in het projectschema De complexiteit in DVG wordt beperkt door toepassing van volgende aspecten, die eerder besproken werden in sectie 2.1: 1. Afhankelijkheid: alle projecten in DVG zijn afhankelijk van elkaar omdat ze aanspraak maken op alle of een deel van de resources. DVG probeert de projecten dan zoveel mogelijk simultaan te managen. Hierdoor kan de waarde van de onderneming gemaximaliseerd worden. 2. Het vermogen tot aanpassen: DVG probeert zich zoveel mogelijk aan te passen aan een veranderende omgeving. Zo is DVG bijvoorbeeld begonnen met het plaatsen van zonnepanelen. Door een gunstige subsidieklimaat zijn deze panelen immers enorm in opmars. 3. Zelforganisatie: alle werknemers weten aan welke regels ze zich moeten houden, indien men een project uitvoert. 4. Het geheel is groter dan de delen: alle projecten worden gezamenlijk bekeken. Er wordt niet geopereerd in een singleprojectomgeving. 5. Feedback: indien er een probleem op één van de werven opduikt, wordt dit direct gemeld aan DVG. Hierdoor kan de planning op een correcte wijze worden aangepast. Aangezien slechte weersomstandigheden een grote invloed kunnen hebben op de uitvoering van bouwwerken, wordt het weer ook zeer grondig in de gaten gehouden. De planning kan dan op een correcte manier worden aangepast door bijvoorbeeld enkele arbeiders gedurende een regendag tewerk te stellen in het magazijn. 6. Niet-lineairiteit: men tracht een overzicht te behouden over de invloeden die de verschillende projecten op elkaar hebben, door het projectschema in MS Excel met kleurencodes op te maken. Ondanks deze maatregels is de complexiteit van de planning nog steeds zeer hoog. DVG moet met heel veel factoren rekening houden: de grootte van de teams, de grootte van de werken, weersomstandigheden, problemen die opduiken op de werven, materiaal dat niet beschikbaar is, etc.
53
Men kan dus spreken van een teveel aan informatie, die op een correcte manier gemanaged moet worden. Wat betreft de flexibiliteit van DVG, kan men besluiten dat ze volgende vormen bezit: -
De mogelijkheid tot het definiëren en aanpassen van de processen die gebruikt worden om projecten te realiseren.
-
De mogelijkheid om verschillende mensen toe te wijzen aan projecten.
-
De mogelijkheid om de planning te definiëren en aan te passen, natuurlijk binnen het tijdsframe dat is afgesproken met de klant.
Al bij al kan men dus concluderen dat DVG, hoewel ze niet in alle vrijheid kan opereren, een redelijk flexibele onderneming is. Indien men DVG zou plaatsen op het framework, besproken in sectie 2.1 (zie supra) en hieronder in verkorte versie nog eens herhaald in tabel 15, dan kan dat in de linkeronderhoek. DVG wordt dan getypeerd als een mechanisch-gestructureerde onderneming. Het is inderdaad zo dat DVG door middel van een gedetailleerde planning een holistisch overzicht probeert te bewaren over alle
Door het Door een overload ontbreken van aan informatie informatie
Complexiteit
projecten. DVG bevindt zich volgens dit framework in een succesvolle zone.
Bureaucratische onderneming
Creatieve-reflectieve onderneming
Mechanisch-gestructureerde onderneming
Onderneming met onnodige chaos
Hoog
Laag
Flexibiliteit Tabel 15 - Organisationeel design versus complexiteit (Geraldi, 2007), toegepast op DVG
In verband met complexiteit is er dus een zeer groot raakvlak met de literatuur.
54
6.7. Onzekerheid in het projectschema Aangezien men de toekomst niet kan voorspellen, is ook voor DVG de perfecte planning opstellen een utopie. Een project kan door allerlei omstandigheden, zoals een regendag of ziekte van een arbeider, soms heel wat vertraging oplopen. Evenwel zijn er ook projecten waar de werken vlugger verlopen dan de planning had voorgeschreven. Bijgevolg kent DVG een hoge mate aan onzekerheid, wat betreft de uitvoering van de planning. Het is ook steeds het geval dat een verstoring bij het ene project, zijn weerslag zal hebben op de planning van andere projecten, hetgeen de kwaliteit van het projectschema nog eens verslechterd, zoals ook werd besproken in sectie 2.2 (zie supra). Wat betreft de proactieve aanpak, gaat men ook met buffers werken. Dit wordt echter niet gedaan volgens de regels van TOC, maar veeleer willekeurig. Wanneer een ploeg een aantal projecten heeft afgewerkt, kan DVG besluiten om een extra dag in de planning op te nemen. Deze extra dag dient dan als buffer voor als een project te laat wordt opgeleverd. Er zijn geen vaste regels met betrekking tot het inplannen van deze dag. Dit komt voornamelijk omdat alle ploegen normaal gezien voor 100% in het schema worden ingezet. Men kan hen dus allemaal een bottleneck resource noemen. Bijgevolg kan de extra dag een capaciteitsbuffer genoemd worden (zie supra 2.2.1). Daarnaast zal men bij het aannemen van projecten ook steeds rekening houden met de huidige planning. Indien een project deze planning volledig overhoop zou halen, dan wordt het niet aangenomen. Zoals besproken in 2.2.1 (zie supra), wordt hierdoor de onzekerheid voor een stuk bedwongen. Dit kan men ook de integratie van verkoop en planning noemen en werd eerder besproken in 6.4 (zie supra). DVG werkt eveneens met het softwarepakket ‘Build’. Wanneer een project wordt aanvaard, kan men door het ingeven van een aantal parameters heel goed berekenen hoeveel tijd met gaat spenderen aan dit project. Deze tijd wordt uitgedrukt in mandagen, of het aantal dagen dat één werknemer zou spenderen aan dit project. Deze accurate schatting is ook een vorm van een proactieve aanpak. Het gebruik van softwarepaketten wordt in de literatuurstudie echter nergens vermeld. De opgelegde planning wordt dagelijks zo goed mogelijk gevolgd. Door verstoringen bij de uitvoering van projecten is echter ook een degelijke reactieve aanpak nodig. Anders dan in de literatuur komt die onzekerheid niet door een minder goede communicatie tussen werknemers en
55
projectmanagement, maar veeleer door invloeden van buitenaf. Een onverwachte regendag, ziekte van een werknemer, het plots veranderen van de wensen van een klant, etc. Het zijn allemaal gebeurtenissen waar DVG geen invloed op heeft. De aanpassing van het projectschema is in handen van bedrijfsleider Johan De Vroe. Hij treedt hier dus op als projectmanager. Wanneer een probleem opduikt, moet dit aan hem gemeld worden en hij probeert de planning dan zo goed mogelijk aan te passen. Dit kan bijvoorbeeld door werknemers van ploegen waar de werken vlugger verlopen, toe te voegen aan ploegen waar de werken trager verlopen, de planning toch op te volgen. Men kan ook interims of onderaannemers in schakelen. De tool EVA wordt niet gebruikt in DVG. DVG noemt één van zijn troeven een correcte timing. Indien projecten niet tijdig kunnen worden opgeleverd, treedt een boeteclausule die van €25 tot €50 kan bedragen, in werking. Het is dus voor DVG nodig om de onzekerheid zoveel mogelijk te bedwingen. In tabel 16 worden de proactieve en de reactieve aanpak in DVG samengevat. Proactieve aanpak -
Buffers
-
Niet meer projecten mogelijk Softwarepakker ‘Build’
-
aannemen
dan -
Reactieve aanpak Wijzigen van de teams Inschakelen van interims
-
Inschakelen van onderaannemers
-
Aanpassing van het schema, indien andere maatregelen niet meer mogelijk zijn
Tabel 16 - Samenvatting van de proactieve en reactieve aanpak in DVG
56
6.8. Samenvatting: overeenkomsten en verschilpunten met de literatuurstudie In deze paragraaf worden alle overeenkomsten en verschilpunten tussen de literatuur op een rijtje gezet. In tabel 17 zijn de overeenkomsten terug te vinden, terwijl in tabel 18 de verschilpunten zijn opgelijst. Tabel 17 is als volgt opgesteld: in de eerste kolom wordt het domein weergegeven, zodat de overeenkomst duidelijk te plaatsen is in een bepaald domein van de literatuur; in de tweede kolom wordt de eigenlijke overeenkomst weergegeven; in de derde kolom wordt weergegeven waar de overeenkomst wordt besproken in deze masterproef. Aspect
Overeenkomst
Besproken in
MRCPSP Het opereren in een dynamische omgeving Het opereren in een open omgeving
Hoofdstuk 3 Sectie 1.2 Sectie 1.3
De keuze van projecten naargelang de strategie van de onderneming De integratie van de verkoopfunctie en de planningsfunctie Het bekijken van het totale winstplaatje
Sectie 1.2
Gecentraliseerde aanpak van projectmanagers Negerende aanpak ten opzichte van resource setups Kwalificatie van werknemers als vrije resources
Sectie 1.3 Hoofdstuk 3 Hoofdstuk 3
De aanwezigheid van complexiteit en onzekerheid Invloeden op de complexiteit Vormen van flexibiliteit, aanwezig in de onderneming Positionering als mechanisch-gestructureerde onderneming en de daarbij horende kenmerken Gebruik van buffers De integratie van de verkoopfunctie en de planningsfunctie
Hoofdstuk 2 Sectie 2.1 Sectie 2.1 Sectie 2.1
Omgeving van het bedrijf
Portfoliomanagement
Sectie 1.2 Sectie 1.2
Resources
Complexiteit en onzekerheid
Sectie 2.2.1 Sectie 2.2.1
Tabel 17 - Overeenkomsten tussen DVG en de literatuur
57
Tabel 18 geeft de verschilpunten weer. In de eerste kolom wordt het literatuurdomein weergegeven; in de tweede kolom wordt het eigenlijke verschilpunt besproken; de derde kolom geeft aan waar het schil met de literatuur zit. Aspect Portfoliomanagement
Verschilpunt
Verschil met literatuur
Het in acht nemen van de afstand tussen de onderneming en het project.
Wordt nergens vermeld.
Alle werknemers zijn single-skilled.
De meeste werknemers zijn multiskilled (zie hoofdstuk 5). De literatuur stelt een goede capaciteitsplanning voorop (zie sectie 1.2). In hoofdstuk 5 werd besproken dat projectmanagers zich met gemiddeld vier projecten tegelijkertijd bezighouden. Ondanks de afwezigheid van deze scheiding, kan DVG onzekerheden toch op een gepaste manier aanpakken (zie sectie 1.3). In hoofdstuk 5 werd geopperd dat deze competitie in bepaalde gevallen wel voorkomt.
Resources
Het aantal werknemers is historisch gegroeid. Projectmanagers houden zich met meer dan vier projecten tegelijkertijd bezig. Projectmanagement en projectleiderschap is niet strikt gescheiden, er is ook geen onderscheid tussen externe en interne focus. Werknemers treden niet in competitie met elkaar om toegewezen te worden aan een bepaald project. Onzekerheid en complexiteit De onzekerheid ontstaat vooral door invloeden van buitenaf.
Het gebruik van EVA. Het gebruik van software om de duurtijd van een project in te schatten en hierdoor de onzekerheid te bedwingen.
De onzekerheid ontstaat vooral door een slechte communicatie tussen projectmanager en arbeiders (zie 2.2.2) Deze tool wordt niet gebruikt in DVG. Wordt nergens vermeld.
Tabel 18 - Verschilpunten tussen DVG en de literatuur
58
Hoofdstuk 7: Methodologie van het empirisch onderzoek In dit hoofdstuk wordt de methodologie besproken die wordt aangewend om tot de resultaten van het empirisch onderzoek te komen. Eerst wordt kort het opzet van het onderzoek weergegeven, waarna de onderzoeksvragen die zullen worden onderzocht, worden opgesomd. In de daaropvolgende sectie worden de gegevens besproken die worden gebruikt in de empirische studie. In de sectie over het gebruikte softwareprogramma wordt overlopen hoe het programma werkt en wat de mogelijkheden zijn. Vervolgens wordt uitgelegd hoe men in het programma een projectschema kan genereren. Ook wordt de nodige aandacht besteed aan de invloeden uit de literatuur die het programma bevat.
7.1. Opzet van het onderzoek In het empirisch onderzoek worden een aantal onderzoeksvragen getest. Dit gebeurt door eerst een basisplanning te laten generen door een softwareprogramma dat voor deze masterproef werd ontwikkeld. De onderzoeksvragen worden getest door de data of het softwareprogramma aan te passen en dan te zien hoe het basisschema evolueert.
7.2. Onderzoeksvragen Deze paragraaf geeft een overzicht weer van alle onderzoeksvragen die zullen worden onderzocht. Eveneens wordt weergegeven op welke manier dit zal gebeuren. Onderzoeksvraag 1: Welke prioriteitsregel geeft het beste resultaat weer? Voor deze onderzoeksvraag wordt onderzocht welke prioriteitsregel het beste van toepassing is op het multiprojectomgeving van DVG. Zoals vermeld wordt in 4.1 (zie supra) geven verschillende prioriteitsregels een ander resultaat. Het resultaat van deze onderzoeksvraag zal de basis bieden voor het schema waarop alle andere onderzoeksvragen worden onderzocht. Voor een overzicht van alle geteste prioriteitsregels wordt verwezen naar sectie 7.4.4 (zie infra). Onderzoeksvraag 2: Wat doet onzekerheid met het projectschema? Tijdens het testen van deze onderzoeksvraag wordt onzekerheid in het schema gebracht. De oorzaak van deze onzekerheden, wordt in de realiteit ook vaak waargenomen. De onzekerheden worden voorgesteld in tabel 19.
59
Hypothese Ziekte van een teamlid (1 tot 5 dagen) Neerslag (1 tot 5 dagen) Werknemers worden ontslagen Spoedproject: een belangrijk project moet zo vlug mogelijk worden ingepland Een combinatie van bovenstaande gevallen Tabel 19 - Overzicht van onzekerheden, onderzoeksvraag 2
Voor ziekte van een teamlid wordt ad random een project geselecteerd. Aan één van de projectfases werd dan een dag ziekte bijgeteld. Bij het testen van de invloed van neerslag op het schema wordt willekeurig een dag gekozen, waarna bij alle projectfases die dan worden uitgevoerd het aantal dagen neerslag wordt bijgeteld. Bij wisselende teamgroottes worden alle mogelijke teams één maal bijgeteld. Voor een spoedproject werd ad random een dag gekozen waarop het project zo vlug mogelijk moest worden ingepland. Als spoedproject werd een gemiddeld project uit de database gekozen. De kenmerken hiervan zijn terug te vinden in tabel 20. Voor de combinatie werd random een combinatie gekozen van al eerder gedane testen. Alle oorzaken worden een aantal keer getest, per oorzaak wordt dan het gemiddelde bestudeerd. Ruwbouw Timmerwerk Dakwerken: Hellend dak Dakwerken: Plat dak Zinkwerk
0 7 12 4 3
Tabel 20 - Kenmerken van een spoedproject
Onderzoeksvraag 3: Wat is de invloed van een nauwer tijdsframe op de kwaliteit van het projectschema? Momenteel bedraagt het tijdframe van de projecten die geen specifieke begindatum of deadline werden toegedeeld, 160 dagen. Dit is echter zeer veel, aangezien de gemiddelde duurtijd van een project om en bij de 13 dagen bedraagt. In deze onderzoeksvraag zal het tijdskader dan ook gradueel
60
worden vernauwd tot het 15 dagen bedraagt, iets meer dus dan de gemiddelde duurtijd. De verschillende tijdskaders staan opgesomd in onderstaande tabel. Tijdskader 1 Tijdskader 2 Tijdskader 3 Tijdskader 4 Tijdskader 5 Tijdskader 6
160 80 60 40 20 15
Tabel 21 - Tijdskaders gebruikt in onderzoeksvraag 3
Bij deze onderzoeksvraag wordt eerst bestudeerd hoe deze verkorte tijdskaders het basisschema gaan veranderen. Daarna wordt ook bestudeerd of het inbrengen van onzekerheid in het schema dezelfde effecten zal hebben als degene die zijn waargenomen bij onderzoeksvraag 2. Onderzoeksvraag 4: Wat is de invloed van een gelijkmatige ploegverdeling op de kwaliteit van het projectschema? Wanneer men de gegevens momenteel bekijkt, dan valt op dat de ploegen geen gelijk aantal teamleden bevatten. In deze onderzoeksvraag wordt nagegaan wat er met de kwaliteit van het schema gebeurt indien dit wel het geval zou zijn. Gradueel worden alle ploegen herleid naar hun minimale grootte, volgens de volgorde van de activiteiten van het kritisch pad. Deze stappen worden voorgesteld in tabel 22. Men kan voorspellen dat door de kleinere groottes van de ploegen de kwaliteit van het projectschema sowieso zal verminderen. Het is hier dan ook weer vooral interessant om na te gaan hoe het inbrengen van onzekerheid de kwaliteit zal beïnvloeden.
Stap 1: ploegen ruwbouw Stap 2: ploegen zinkwerk Stap 3: ploegen dakwerk – hellend dak Stap 4: ploegen dakwerk – plat dak
Minimale ploeggrootte 2 1 2 2
Tabel 22 - Aanpassing van ploeggroottes in onderzoeksvraag 3
De ploegen die het timmerwerk uitvoeren, worden hier niet beschouwd. De reden hiervoor is dat al deze ploegen al gelijke ploeggroottes hebben.
61
Onderzoeksvraag 5: Wat is de invloed van een multiskilled projectteam op de kwaliteit van het projectschema? Zoals in hoofdstuk 5 werd vermeld, trekt men in de literatuur het besluit dat de meeste werknemers in multiprojectomgevingen multiskilled zijn. Hier is dit niet het geval. In deze onderzoeksvraag zal worden onderzocht of het projectschema door het multiskilled zijn van de werknemers kan verbeteren. Dit zal worden gedaan door aan verschillende teams meerdere vaardigheden toe te kennen en vervolgens een nieuw projectschema te laten genereren door het softwareprogramma. De ploegen die werkzaam zijn in de ruwbouw worden hier wel buiten beschouwing gelaten, aangezien het niet realistisch is om te veronderstellen dat deze arbeiders ook onderlegd zijn in de andere bouwwerken. Verder werd ook onderzocht wat er gebeurde met het schema indien er om de vijf of om de tien dagen een onzekerheid in het schema werd gebracht, of de impact verschillend was indien men onzekerheid in het schema brengt aan het begin van de werken of in het midden van de werken en wat er gebeurde indien de onzekerheid betrekking had op het langstdurende project en het project met de meeste vertraging. Deze testen leverden echter geen interessante resultaten op en werden dus niet opgenomen in deze studie.
7.3. Gegevensverzameling en gegevensanalyse Er werd een database van in totaal 120 projecten ter beschikking gesteld (zie bijlage 6: Database van de ter beschikking gestelde projecten). Deze projecten hebben een uitvoeringstermijn tussen september 2010 en december 2011. De gegevens van één project bestaan uit een dossiernummer (primaire sleutel), een dossiernaam, hoeveel tijd het kost om het project uit te voeren, een vroegste begindatum en een datum waartegen het project moeten worden afgeleverd. Onderstaande tabel is een voorbeeld van een project.
62
Dossiernummer: Dossiernaam: Loonkost in mandagenc d:
10/207 Fortis/Novo IB Ruwbouw (LR) Timmerwerk (LT) Dakwerk: Hellend dak (LO) Dakwerk: Plat dak (LA) Dakwerk: Zink (LZ)
Vroegste begindatum: Opleverdatum:
0 2.67 7.26 17.65 0.75 15/09/2010 15/10/2010
Tabel 23 - Voorbeeld van een project in DVG
Voor het gebruik van het softwareprogramma werden de data omgezet in numerieke gegevens, waarbij dag 0 gelijkgesteld werd aan 30/08/2010 en dag 305 gelijkgesteld werd aan 23/12/2011. Zo wordt het ook mogelijk om weekends, vakantiedagen en feestdagen uit de planning te weren. Voor sommige projecten werd geen exacte uitvoeringstermijn afgesproken. Deze kunnen dus met andere woorden vrij worden ingepland. Om ervoor te zorgen dat deze projecten in het schema konden worden opgenomen, werden volgende assumpties gemaakt:
Projecten 10/131 tot 10/350 10/350 tot 10/400 10/400 tot 10/462 11/002 tot 11/074 11/074 tot 11/122
Tijdskader (Vroegste begindatum – opleverdatum) 0 – 160 40 – 200 80 – 240 120 – 280 160 – 320
Tabel 24 - Overzicht van assumpties met betrekking tot vroegste begindatum en opleverdatum
Zoals men kan zien in tabel 24 is het tijdskader waarin de projecten kunnen worden gepland, zeer ruim genomen. Dit kadert geheel in het feit dat deze projecten vrij kunnen worden ingepland. Het is evenwel nodig om aan deze projecten een vroegste begindatum toe te wijzen, zo niet, worden zij niet opgenomen door bepaalde prioriteitsregels. Het is natuurlijk ook zo dat de projecten ooit eens van start moeten gaan, men kan ze niet blijven achteruit schuiven ten gunste van meer dringendere projecten. Dit kadert in de conclusie, die in het boek “Managing multiple project” (Tobis & Tobis, 2002) werd gemaakt. Deze gegevens worden vervolgens verwerkt in het softwareprogramma.
c
De loonkost wordt in mandagen voorgesteld. Dit houdt in dat als voor een bepaalde projectfase het aantal mandagen 6 bedraagt, één werknemer zes dagen nodig heeft om deze fase te voltooien; indien deze fase wordt uitgevoerd door twee werknemers, duurt het 3 dagen om deze fase te voltooien, etc. d De loonkost voor het plaatsen van zonnepanelen is opgenomen in Dakwerk: hellend dak of Dakwerk: plat dak.
63
7.4. Softwareprogramma Zoals eerder vermeld werd, zal de analyse van de gegevens gebeuren door middel van een softwareprogramma. Dit softwareprogramma werd ontwikkeld met behulp van Netbeans en de javacodetaal. Het softwareprogramma is specifiek toegespitst op de werking van DVG. Er hebben meerdere vergaderingen plaatsgevonden waarin de werking van het programma werd aangepast aan de werking van DVG. Enige verdere finetuning is nog nodig vooraleer het programma op dagelijkse basis kan worden gebruikt. Voor de middellange planning is het softwareprogramma evenwel al bruikbaar.
7.4.1. Werking van het softwareprogramma De werking van het programma werd zo eenvoudig mogelijk gehouden, dit om de werkbaarheid te verhogen. Deze paragraaf schetst hoe men het programma moet doorlopen indien men een nieuwe planning wil opmaken. Wanneer men het softwareprogramma opent, komt men terecht op onderstaand verwelkomingsscherm.
Figuur 14 – Welkomstscherm
Wil men een nieuw dossier toevoegen, dan klikt men op de bovenste button. Vervolgens komt men op de tabblad ‘Nieuw dossier toevoegen’, te zien in figuur 15. Dit tabblad is nodig aangezien DVG opereert in een dynamische omgeving (zie supra 1.3) en een nieuw project dus steeds de planning kan binnendringen. De gegevens die opgevraagd worden, zijn dezelfde als deze die werden meegegeven in tabel 23 (zie supra).
64
Figuur 15 - Tabblad 'Nieuw dossier toevoegen'
Wanneer men een nieuwe planning wil opstellen, dan klikt men in het welkomstscherm de onderste button ‘Reschedule’ aan. Vervolgens komt men op het tabblad dat is voorgesteld in figuur 16.
65
Figuur 16 - Tabblad 'Reschedule'
Indien men de planning die al in de database zit, voor een bepaalde dag wil bekijken, geeft men in de tekstbalk ‘Datum’ de dag waarvan men de planning wil bekijken. Vervolgens klikt men op de button ‘Enter datum’. In het veld worden daarna de projecten weergegeven die op die dag worden uitgevoerd. Tevens wordt de ploeg weergegeven en hoeveel procent van het project al is afgewerkt. In figuur 17 wordt als voorbeeld dag 1 van het basisschema weergegeven. De vooruitgang van alle projecten staat hier natuurlijk overal op 0% aangezien het de eerste dag van de planning is.
66
Figuur 17 - Voorbeeld van het opvragen van de planning op dag 1
Indien men de planning die in de database zit wil herinplannen, omdat er zich bijvoorbeeld een onzekerheid heeft voorgedaan bij één van de projecten, dan geeft men eerst de datum in vanaf het punt dat je wil herplannen. Vervolgens klikt men de button ‘Reschedule’ aan, waarop de planning zich vanzelf aanpast. Een voorbeeld wordt gegeven in onderstaande figuur.
67
Figuur 18 - Voorbeeld van herplannen op dag 200
Een neerslagdag, dit wil zeggen een dag waarop het gedurende de hele dag neerslag valt en er dus niet kan gewerkt worden, is een groot euvel voor een bedrijf actief in de bouwsector. Niet alleen betekent dit het verlies van opbrengsten, maar het betekent ook dat er één en ander in de planning moet verschoven worden. In dit softwareprogramma kan men ingeven hoeveel dagen het gaat regenen. Door vervolgens op de button ‘Neerslag inbrengen’ te klikken, wordt de planning hieraan aangepast. Figuur 19 geeft een voorbeeld weer.
68
Figuur 19 - Voorbeeld van het inbrengen één regendag op dag 15
Wanneer een teamlid ziek is of een bepaalde projectfase duurt langer dan verwacht, dan kan men de planning hieraan aanpassen door te klikken op de button ‘Aanpassingen aanbrengen’. Vervolgens komt men terecht op het tabblad ‘Aanpassingen doorvoeren’. Als men het dossiernummer ingeeft, komt de duurtijd van alle projectfases te voorschijn en hoeft men de extra er maar gewoon bij te tellen.
Figuur 20 - Tabblad 'Aanpassingen doorvoeren'
69
In dit tabblad is ook de button ‘Dossier verwijderen’ terug te vinden. Wanneer een nieuw project opduikt, kan men het dus eerst toevoegen, bekijken wat het doet met de huidige planning en dan beslissen of men het project gaat uitvoeren of niet. Op die manier kan men aan portfoliomanagement doen. Indien men beslist om het project niet aan te nemen, kan men het project gemakkelijk verwijderen via deze button.
7.4.2. Wijze van schedulen in het programma In het programma worden de projecten niet als dusdanig gepland, maar veeleer de verschillende fases van een project. De algemene begin- en einddatum volgt dan logischerwijze uit deze fases. Tijdens het inplannen van de gegevens wordt met volgende aspecten rekening gehouden: -
De verschillende kwalificaties van een bepaald team (zie bijlage 5: Overzicht van de teams in DVG).
-
De verschillende groottes van een bepaald team (zie bijlage 5: Overzicht van de teams in DVG).
-
De volgorde waarin projecten moeten worden ingepland (zie supra 6.2).
-
Projecten worden niet ingepland op weekends, feestdagen of tijdens de jaarlijkse vakanties.
-
Een project kan pas worden ingepland vanaf de vroegste begindatum.
-
Wanneer men wil herschedulen, worden projecten die op dat moment al worden uitgevoerd, eerst afgewerkt, alvorens er nieuwe projecten ingepland worden (geen onderbreking van projecten).
-
Er wordt gewerkt in een dynamische omgeving.
Het algoritme om de fases in te plannen is gebaseerd op het parallel inplannen van projecten (zie supra 4.2.1) en verloopt als volgt: 1. Men geeft een datum in vanaf wanneer men wil plannen. 2. Projectfases die nog niet zijn ingepland, worden gerangschikt naargelang een prioriteitsregel. 3. Er wordt gekeken of een fase die al was ingepland, is afgelopen. Indien dit het geval is, wordt de ploeg die deze fase heeft uitgevoerd, onthouden. 4. De datum wordt geïtereerd. 5. Indien er in de database ploegen beschikbaar zijn, met andere woorden, ploegen die zijn onthouden uit stap 3, wordt overgegaan naar stap 6. Indien er geen enkele ploeg beschikbaar is, wordt teruggekeerd naar stap 3. 70
6. Er wordt gezocht naar een fase die nog niet is ingepland en die kan worden uitgevoerd door de ploeg en vanaf de datum die onthouden werd uit stap 3. Deze projectfase wordt geselecteerd uit de prioriteitslijst, verkregen in stap 2. 7. Als begindatum voor deze fase wordt de datum, verkregen uit stap 4, gekozen. De ploeg uit stap 4 wordt ingepland om deze fase op te leveren. 8. De einddatum van deze fase wordt berekend. 9. Vervolgens worden stappen 3 tot en met 8 herhaald tot alle projectfases zijn ingepland. 10. Enkele kwaliteitsparameters worden berekend (zie infra 7.4.5). Deze manier van plannen wordt nog eens schematisch voorgesteld in figuur 21.
71
Figuur 21 - Schematische voorstelling van de planningswijze in het softwareprogramma
7.4.3. Invloeden vanuit de literatuur Zoals vermeld werd in sectie 7.4.2 (zie supra), is de planningswijze in het softwareprogramma gebaseerd op het parallel inplannen van projecten. Een verschil met de manier zoals die besproken
72
werd in sectie 4.2.1 (zie supra), is het feit dat hier projectfases worden ingepland, en niet zozeer gehele projecten. Dit is voor de situatie van DVG de beste oplossing, aangezien voor alle projectfases verschillende teams moeten worden ingeschakeld. Het serieel inplannen van activiteiten werd hier niet toegepast, noch het optimaliseren van de initiële oplossing aan de hand van SA en GA (zie supra 4.2.2). Voor een bedrijf als DVG is het niet nodig om zo gedetailleerd tewerk te gaan. Dat een planning nu automatisch verloopt en er dagelijks niet meer zoveel tijd aan besteed moet worden is op zich al een hele verbetering. Ook voor deze masterproef kunnen veel testen gedaan worden, zonder dat het nodig is deze verdere optimalisering toe te passen. Voor verder onderzoek zou het softwareprogramma wel verder kunnen aangepast worden. Wanneer er vergeleken naar het mathematische model, besproken in hoofdstuk 3 (zie supra), zijn er ook vele raakvlakken te vinden. Daar DVG opereert in een dynamische, open omgeving, werd gekozen voor een multiprojectaanpak. Vele constraints die zijn vermeld in het mathematisch model, worden voldaan tijdens de selectie van projectfases uit V3 (zie figuur 21). Dit is dus een hele belangrijke stap. Zo wordt constraint (1) door het softwareprogramma gerespecteerd door tijdens de selectie van een projectfase ook te gaan onderzoeken of voorgaande projectfases niet afgewerkt zijn. Door een projectfase steeds te verwijderen uit V3 wanneer het geselecteerd wordt (zie figuur 21), wordt ook constraint (2) gerespecteerd. Eveneens wordt constraint (3) tijdens deze selectiestap onderzocht. Door enkel projecten te selecteren waarvoor er een ploeg beschikbaar is, wordt constraint (5) in acht genomen. Constraint (6) wordt nageleefd door het berekenen van de einddatum. Een projectfase is pas af en stelt met andere woorden haar resources ter beschikking, indien deze datum bereikt wordt. Ook constraint (7) wordt hierdoor geëerbiedigd. De poel van resources betreft hier de ploegen die beschikbaar zijn om ingepland te worden. Ook dit wordt bijgehouden door het softwareprogramma, waardoor aan constraint (8) en (9) wordt voldaan. Constraint (4) wordt niet nageleefd. In de realiteit is dit heel vaak onmogelijk en omdat het gevaar bestaat dat het softwareprogramma in een oneindige loop terecht zou komen, werd deze beperking niet opgenomen.
73
Tabel 25 vat nog eens samen welke invloeden uit de literatuurstudie werden geïncorporeerd door het softwareprogramma. Heuristieken Parallel inplannen van projectfases Mathematisch model Multiprojectaanpak Constraint (1) Constraint (2) Constraint (3) Constraint (5) Constraint (6) Constraint (7) Constraint (8) Constraint (9) Tabel 25 - Samenvattende tabel: invloeden uit de literatuur
7.4.4. Gebruikte prioriteitsregels Zoals werd aangehaald in 4.1 (zie supra), kunnen verschillende prioriteitsregels een verschillende mogelijke planningen opleveren. In het softwareprogramma werden dus zoveel mogelijk prioriteitsregels toegepast als mogelijk. Echter, niet alle regels uit de lijst, opgesomd in 4.1, konden worden gebruikt. Zo werd de prioriteitsregel ‘Maximale sanctie’ niet gebruikt. Niet alleen waren de gegevens daarvoor confidentieel, ook is het voor DVG moeilijk om een sanctie vooraf te bepalen. Een boeteclausule treedt immers slechts in werking wanneer een planning wordt uitgevoerd. Daarnaast werd ook de regel ‘Maximaal aantal resources nodig’ niet gebruikt. Ook deze regel is niet toepasbaar in de context van DVG, aangezien men opereert in een MRCPSP-omgeving. Verder werden alle prioriteitsregels die werden opgenoemd in de literatuurstudie, wel toepasbaar bevonden en ingesloten in het softwareprogramma. In tabel 26 wordt hiervan een overzicht gegeven. Prioriteitsregel 1: Earliest due date Prioriteitsregel 2: Least slack Prioriteitsregel 3: Kortste activiteit van een project eerst Prioriteitsregel 4: Maximale projectduur eerst Prioriteitsregel 5: Maximale kost eerst Tabel 26 - Overzicht van geteste prioriteitsregels in het softwareprogramma
74
Hierbij moet wel worden opgemerkt dat, wanneer een kritisch pad moest berekend worden, de assumptie gemaakt werd dat alle ploegen uit twee teamleden bestaan.
7.4.5. Kwaliteitsparameters In hoofdstuk 4 werd al aangehaald dat verschillende parameters met elkaar vergeleken moeten worden, indien de kwaliteit van een bepaald schema moet worden beoordeeld. Opnieuw werden zoveel mogelijk parameters getest in het programma. Evenwel konden, net zoals bij de prioriteitsregels, niet alle kwaliteitsparameters die opgesomd zijn in sectie 4.3 worden toegepast op de omgeving van DVG. De ‘Mean resource utilisation rate’ werd uitgesloten. Aangezien we te maken hebben met een dynamisch schema, is het normaal dat naar het einde van de planning toe, niet alle ploegen meer worden ingeschakeld. De hantering van deze parameter zou dus een verkeerd beeld geven over de kwaliteit van het schema. Om dezelfde reden werd ook de parameter ‘Minimalisatie van de kosten met betrekking tot resources’ niet beschouwd. Deze parameter geeft ook geen accuraat beeld van de kwaliteit van het schema. Vervolgens werd ook de kwaliteitsparameter ‘Combinatie’ niet bestudeerd. Aangezien de beslissingnemer zelf een aantal parameters mag invullen, kan de objectiviteit in twijfel worden getrokken. Uitgezonderd van bovenvernoemde parameters, werden de rest van de parameters opgenomen in het softwareprogramma. Een overzicht van deze parameters is te vinden in tabel 27. Totale tijd om het schema te vervolmaken Makespan Mean project set flow time Totale vertraging Maximale vertraging Het aantal jobs dat hun deadline overschrijdt Gemiddelde vertraging Tabel 27 - Overzicht van gebruikte kwaliteitsparameters in het softwareprogramma
75
Hoofdstuk 8: Resultaten en interpretatie In totaal werd het programma ongeveer 750 keer gerund, telkens met aanpassing van één of meerdere aspecten. De meest interessante resultaten worden hier voorgesteld. In dit hoofdstuk worden de resultaten van de testen die zijn uitgevoerd omtrent de onderzoeksvragen overlopen en geïnterpreteerd. Er wordt telkens getracht om zo visueel mogelijk te werken. Aan het eind van de interpretatie wordt telkens een kort besluit geformuleerd. Rapporten in verband met statistische significantie van de gedane onderzoeken zijn terug te vinden in bijlage 7: Rapporten in verband met de statistische significantie.
8.1. Resultaten en interpretatie van onderzoeksvraag 1: Welke prioriteitsregel geeft het beste resultaat weer? Verschillende basisschema’s werden gegenereerd door toepassen van de prioriteitsregels die beschreven werden in sectie 7.4.4. Elke prioriteitsregel werd getest. De resultaten werden samengevat in grafiek 1. De kwaliteitsparameters die in deze grafiek zijn weergegeven, zijn ‘Totale tijd om het schema te vervolmaken’ en ‘Totale vertraging’. Deze parameters gaven de grootste verschillen weer en zijn dus het meest interessant om te bestuderen. Exacte cijfers en de resultaten van de andere prioriteitsregels zijn te vinden in bijlage 8: Exacte resultaten voor de verschillende prioriteitsregels. 1860
250
1.839
1840
1.821
1820 177
1800 1780
217
217
1.799
185
200
1.793
150
145 1.763
100
Totale tijd om het schema te vervolmaken
50
Totale vertraging
1760 1740 1720
0
Grafiek 1 - Onderzoeksvraag 1
76
Zoals verwacht werd, geven de verschillende prioriteitsregels een verschillend resultaat weer. Interessant om te zien is dat er een verband bestaat tussen beide kwaliteitsparameters. Daar waar de ene parameter een hoge waarde heeft, heeft de andere parameter een lagere waarde. Inderdaad, als de waarden voor beide parameters geanalyseerd worden, blijkt er een sterke correlatie van -0,85 tussen deze waarden te bestaan.
Kwaliteitsparameter A Kwaliteitsparameter B
Kwaliteitsparameter A Kwaliteitsparameter B 1 -0,856171105 1
Tabel 28 - Correlatie tussen beide kwaliteitsparameters
Het is in dit geval dan ook moeilijk om een prioriteitsregel te kiezen. Indien er wordt teruggeschakeld naar de realiteit, dan weten we dat een boeteclausule voor het te laat opleveren van een project €25 tot €50 kan bedragen. De gemiddelde loonkost van een arbeider bedraagt echter ongeveer €32 per uur. Gesteld dat een arbeider gemiddeld 8 uur per dag werkt, bedraagt deze loonkost per dag €256. In die zin is het economisch gezien beter om te kiezen voor het schema met prioriteitsregel 4 ‘Maximale projectduur eerst’. Dit schema is te vinden in bijlage 9: Basisschema. Voor de volgende onderzoeksvragen werd ook steeds dit schema gebruikt. De resultaten van de kwaliteitsparameter worden weergegeven in tabel 29. Prioriteitsregel Maximale projectduur eerst Totale tijd om het schema te vervolmaken 1763,0 Makespan 66,0 Mean project set flow time 14,962 Totale vertraging 217,0 Maximale vertraging 39,0 Aantal jobs dat hun deadline overschrijdt 16,0 Gemiddelde vertraging 13,563 Tabel 29 - Overzicht van de kwaliteitsparameters voor prioriteitsregel 'Maximale kost eerst'
Tevens werd onderzocht of een combinatie van verschillende prioriteitsregels tot een betere kwaliteit van het schema zou leiden. Dit was hier echter niet het geval, daarom werden de resultaten niet opgenomen in deze masterproef. De resultaten van deze onderzoeksvraag worden samengevat in tabel 30. Besluiten getrokken uit deze onderzoeksvraag Beste resultaat: prioriteitsregel ‘Maximale projectduur eerst’ Negatieve correlatie tussen kwaliteitsparameters ‘Totale vertraging’ en ‘Totale tijd om het schema af te werken’ Tabel 30 - Besluiten onderzoeksvraag 1
77
8.2. Resultaten en interpretatie van onderzoeksvraag 2: Wat doet onzekerheid met het projectschema? Voor deze onderzoeksvraag werd onzekerheid in het schema gebracht, zoals werd besproken in sectie 7.2 (zie supra). In totaal werden 230 testen uitgevoerd. De resultaten van deze 230 testen werden gebundeld in grafiek 2 en grafiek 3. Belangrijk hierbij is te weten dat enkel die effecten zijn getest waarvan men verwacht dat ze een negatieve invloed zullen hebben. In grafiek 2 wordt de kwaliteitsparameter ‘Totale tijd om het schema te vervolmaken’ onder de loep genomen. Het gemiddelde van deze testparameter bedraagt 1768 en ligt dus iets hoger dan de waarde voor het basisschema, zoals ook aangegeven wordt in de grafiek. De waarden verschillen van 1703, gevonden voor de onzekerheid 5 ziektedagen van een teamlid bij project 11/084, tot 1861, gevonden voor het effect als ploeg H4 wegvalt. Interessant om te zien is dat de steilte van de grafiek afneemt rond het gemiddelde. Men kan dus stellen dat het basisschema een zekere robuustheid bevat. 1880 1860 1840 Waarden test
1820 1800 1780
Testwaarden
1760
Waarde basisschema
1740
Gemiddelde testwaarden
1720 1700 1680 0
50
100
150
200
250
300
Aantal testen
Grafiek 2 – Onderzoeksvraag 2: kwaliteitsparameter 'Totale tijd om het schema te vervolmaken'
Dezelfde effecten zijn te vinden, wanneer men de kwaliteitsparameter ‘Totale vertraging’ bestudeert. Grafiek 3 heeft ongeveer dezelfde vorm als grafiek 2. Eveneens vindt men terug dat de onzekerheden zowel een positieve als negatieve invloed kunnen hebben. De robuustheid rond het gemiddelde is ook hier waar te nemen. De laagste waarde voor deze parameter bedraagt 135 en werd gevonden voor het effect als een extra ploeg S1 wordt aangenomen; de hoogste waarde 78
bedraagt 520 en werd gevonden voor drie regendagen, beginnende van dag 152 in het schema. In tegenstelling tot de eerder besproken parameter is de range hier dus veel groter. Ook is het verschil tussen de het gemiddelde van de testwaarden, zijnde 245,78, en de waarde van het basisschema, zijnde 217, groter.
Waarden kwaliteitsparameter
600 500 400 300
Testwaarden Waarde basisschema
200
Gemiddelde testwaarden
100 0 0
50
100
150
200
250
300
Aantal testen
Grafiek 3 – Onderzoeksvraag 2: kwaliteitsparameter 'Totale vertraging'
Men kan zich afvragen of de correlatie, gevonden bij de resultaten van de vorige onderzoeksvraag nog steeds zo sterk negatief is. Dit is hier niet meer het geval; de correlatie tussen beide parameters bedraagt hier -0,15, hetgeen betekent dat er geen echte relatie meer bestaat.
Kwaliteitsparameter A Kwaliteitsparameter B
Kwaliteitsparameter A Kwaliteitsparameter B 1 -0,15968 1
Tabel 31 - Correlatie tussen de gebruikte kwaliteitsparameters in onderzoeksvraag 2
Wanneer men wil bekijken door welke vorm van onzekerheid het schema het meest in de war raakt, dan zal men ook verschillende waarde aantreffen voor de verschillende kwaliteitsparameters. Voor de kwaliteitsparameter ‘Totale tijd om het schema te vervolmaken’ heeft het wegvallen van een team de meeste invloed. Vreemd genoeg wordt het basisschema verbeterd door de invloeden van vier en vijf ziektedagen, terwijl als een teamlid één, twee of drie dagen ziek is, het basisschema hierdoor een lagere kwaliteit krijgt. 79
1793,60
1779,50
1769,00 1772,82
1768,15
1768,10
1767,83
1767,75
1764,30
1762,13
1770,00
1760,65
1780,00
1757,75
1790,00
1767,75
1800,00
1760,00 1750,00
Totale tijd om het schema te vervolmaken
1740,00
Totale tijd in het basisschema Wegvallen van een team
Spoedproject
Neerslag (4 dagen)
Neerslag (1 dag)
Neerslag (5 dagen)
Ziekte (3 dagen)
Neerslag (2 dagen)
Neerslag (3 dagen)
Ziekte (1 dag)
Ziekte (2 dagen)
Combinatie
Ziekte (5 dagen)
Ziekte (4 dagen)
1730,00
Grafiek 4 – Onderzoeksvraag 2: factoren die het basisschema aantasten, kwaliteitsparameter 'Totale tijd om het schema te vervolmaken'
Indien we de kwaliteitsparameter ‘Totale vertraging’ onder de loep nemen, dan is een hele andere rangschikking van de oorzaken te zien. Ditmaal blijkt de ziekte van een teamlid gedurende één, twee en drie dagen het schema te verbeteren, terwijl een neerslagperiode van drie dagen de
200,00
287,10
275,93
271,60
253,95
242,67
241,60
223,18
216,00
220,00
215,65
240,00
213,85
260,00
227,25
280,00
252,80
300,00
269,45
meest negatieve invloed had.
Totale vertraging Waarde basisschema
Grafiek 5 – Onderzoeksvraag 2: factoren die het basisschema aantasten, kwaliteitsparameter 'Totale vertraging'
80
Wanneer beide parameters met elkaar vergeleken worden, dan valt op dat door de overgrote meerderheid van de oorzaken het basisschema wordt verslechterd. Bij de parameter ‘Totale vertraging’ is de negatieve invloed echter vaak sterker. Ook valt op dat wanneer een spoedproject de planning komt binnengeslopen, het meestal een negatieve invloed heeft. Met betrekking tot de kwaliteitsparameter ‘Totale tijd om het schema te vervolmaken’ moet echter de nodige aandacht besteed worden. Aangezien een project met een gemiddeld kritisch pad van 13 dagene aan de database wordt toegevoegd, is het zeer logisch dat de waarde van deze parameter verhoogd. Als de 13 dagen worden afgetrokken, dan bekomt deze kwaliteitsparameter een waarde van 1766,50 en zou men de oorzaak ‘Spoedproject’ veeleer in het begin van de rangschikking terugvinden. Men kan zich afvragen hoe het komt dat, wanneer onzekerheid in het basisschema wordt gebracht, dit niet altijd een negatieve invloed heeft. Hiervoor zijn twee oorzaken te vinden: 1. Doordat voor sommige projecten een assumptie moest worden gemaakt ten aanzien van het tijdsframe waarin ze konden worden uitgevoerd en dit tijdsframe vrij groot werd gekozen (zie supra 7.3), heeft het vertragen van deze activiteiten geen invloed op de parameter ‘Totale vertraging’. Op de parameter ‘Totale tijd om het schema te vervolmaken’ heeft dit natuurlijk wel nog een invloed. 2. Aangezien de ploegen geen gelijke grootte hebben, kan dit ook een invloed hebben. Aan de hand van een voorbeeld wordt dit duidelijker. Stel dat een project voor het zinkwerk een loonkost heeft van 20 mandagen. In het basisschema wordt deze fase toegewezen aan ploeg Z1, waardoor de duurtijd van deze fase 20 dagen zal bedragen. Echter, door het inbrengen van onzekerheid heeft deze fase een vertraging opgelopen, waardoor het pas 5 dagen later kan worden gestart. Op dit moment kan ploeg Z2 worden ingezet. Deze ploeg bestaat uit twee teamleden, waardoor de duurtijd maar 10 dagen bedraagt. Hierdoor kan de projectfase vijf dagen eerder dan de oorspronkelijke einddatum worden afgewerkt. De conclusie voor deze onderzoeksvraag is dat het inbrengen van onzekerheid in het projectschema vaak een negatieve invloed kan hebben op zowel de totale tijd waarin het schema kan vervolmaakt worden, als op de totale vertraging die het schema zal oplopen. Men kan stellen dat de onzekerheid vooral een invloed heeft op het uitstellen van de begindatum van een bepaald project, aangezien de totale vertraging een grotere afwijking van het basisschema vertoont. De
e
13 dagen = De totale loonkost in mandagen/gemiddelde grootte van een ploeg = (7 + 12 + 4 + 3)/2
81
invloed van onzekerheid heeft echter niet altijd een negatief effect. Het basisschema vertoont ook een zekere robuustheid. Deze conclusies werden samengevat in tabel 32. Besluiten getrokken uit deze onderzoeksvraag Inbrengen van onzekerheid meestal negatieve invloed op de kwaliteit van het schema De invloed kan ook positief zijn Invloed is vooral te merken bij de totale vertraging Basisschema vertoont een zekere robuustheid Tabel 32 - Besluiten onderzoeksvraag 2
8.3. Resultaten en interpretatie van onderzoeksvraag 3: Wat is de invloed van een nauwer tijdsframe op de kwaliteit van het projectschema? De kwaliteit van het basisschema met betrekking tot de totale tijd om het schema te vervolmaken verandert niet. Dit is logisch, aangezien de prioriteitsregel ‘Maximale vertraging’ enkel rekening houdt met het kritisch pad van een project. De effecten voor de parameter totale vertraging zijn echter beduidend anders. Zoals men kan zien in grafiek 6, stijgt de totale vertraging naarmate het tijdskader nauwer wordt. Echter, het aantal jobs dat over deadline gaat stijgt evenredig met de totale vertraging. Hierdoor blijft de gemiddelde vertraging per te laat afgeleverd project ongeveer gelijk. 700
50 43
45
600 593
40
36
500 400
35 470
30 21
300 200
16
16
16
214
217
217
274
25
Totale vertraging
20
Jobs over deadline
15
100
10 5
0
0 15 dagen 20 dagen 40 dagen 60 dagen 80 dagen 160 dagen
Grafiek 6 – Onderzoeksvraag 3
82
Aangezien de parameter ‘Totale vertraging’ hier de beste parameter blijkt om de kwaliteit van het schema te beoordelen, wordt de oorzaak ‘Neerslagperiode van drie dagen’ gebruikt om te bestuderen wat onzekerheid met het schema doet. Deze oorzaak werd bij de vorige onderzoeksvraag immers gevonden als aanleiding van de grootste verandering in kwaliteit. In grafiek 7 worden de onderzoeksresultaten samengevat. De totale vertraging in het schema waarbij de projecten een tijdskader hebben van 160 dagen ligt hoger dan de vertraging in het schema waarbij de projecten een tijdskader hebben van 80 dagen. Daarna kan men echter opnieuw stellen dat de totale vertraging oploopt naarmate het tijdskader nauwer wordt. Opnieuw is er een duidelijke relatie op te merken tussen de totale vertraging en het aantal jobs dat over hun deadline gaat. De gemiddelde vertraging blijft hier dan ook quasi gelijk. 700
641
600
46
500 400 300
50 45
579
40 35
38
30 324 286 23 19
200
255 17
287
18
25
Totale vertraging
20
Jobs over deadline
15 10
100
5
0
0 15 dagen 20 dagen 40 dagen 60 dagen 80 dagen 160 dagen
Grafiek 7 – Onderzoeksvraag 3: toevoegen van onzekerheid
De gecombineerde resultaten uit grafiek 6 en grafiek 7 tonen duidelijk aan dat ook hier onzekerheid zorgt voor een slechter niveau van het schema. Gemiddeld liggen de waarden van grafiek 7 64,63 dagen hoger dan de waarden in grafiek 6. Hiermee worden de resultaten uit onderzoeksvraag 2 dus bekrachtigd.
83
700
641,1 579,1
600 593 500 400
470 324,2 286,3
300
255
287,1
Totale vertraging zonder onzekerheid
274
200
214
217
Totale vertraging met onzekerheid
217
100 0 15 dagen 20 dagen 40 dagen 60 dagen 80 dagen 160 dagen
Grafiek 8 - Onderzoeksvraag 3: totale vertraging met en zonder onzekerheid
Men kan zich afvragen of deze resultaten ook terug te vinden zijn bij de andere factoren die onzekerheid veroorzaken. Eenzelfde trend is ook daar waar te nemen, doch minder beduidend dan bij de oorzaak ‘Neerslagperiode van drie dagen’. De conclusie voor deze onderzoeksvraag is dat een nauwer tijdsframe de kwaliteit van het schema met betrekking tot de totale vertraging gevoelig vermindert. Dit effect wordt versterkt indien men onzekerheid in het schema brengt. Wat betreft de totale tijd om het schema af te werken zijn geen afwijkingen waar te nemen. Dit heeft echter alles te maken met de prioriteitsregel die in deze case studie gebruikt werd. Voorts kan men ook stellen dat door de nauwe relatie tussen de totale vertraging en het aantal jobs dat hun deadline overschrijdt, de gemiddelde vertraging quasi gelijk blijft. Een aanbeveling voor managers in een soortgelijke multiprojectomgeving kan dus zijn om het tijdskader van hun projecten zo wijd mogelijk te maken, dit zal de kwaliteit van hun schema ten goede komen. Besluiten getrokken uit deze onderzoeksvraag Nauwer tijdframe negatieve impact op de totale vertraging en aantal jobs die hun deadline overschrijden Totale tijd om het schema af te werken en gemiddelde vertraging geen negatieve invloed Aanbeveling aan managers van bouwbedrijven: tijdsframe zo wijd mogelijk houden Tabel 33 - Besluiten onderzoeksvraag 3
84
8.4. Resultaten en interpretatie van onderzoeksvraag 4: Wat is de invloed van een gelijkmatige ploegverdeling op de kwaliteit van het projectschema? Zoals men kan waarnemen in grafiek 10 en zoals ook al werd voorspeld bij het oplijsten van de onderzoeksvragen, is er een stijgende trend te zien met betrekking tot de totale tijd om een schema te vervolmaken en de totale vertraging. Dit komt omdat de grootte van de teams werd geminimaliseerd. Zoals werd besproken in onderzoeksvraag 2, heeft het wegvallen van een ploeg een nefaste invloed op de kwaliteit van het projectschema. Dit kan door deze onderzoeksvraag aangevuld door te stellen dat als er groepsleden wegvallen uit een team, dit ook een negatieve invloed heeft op de kwaliteit van projectschema. Zeer interessant om op te merken is dat de invloed van gelijkmatige ploegen gematigd wordt naarmate het onderzoek vordert. Voor de parameter ‘Totale vertraging’ kan in de laatste stap van het onderzoek zelfs een verbetering worden opgetekend. Ook kan men stellen dat het gelijk maken van de ploegen vooral een invloed heeft op de totale tijd om het schema te vervolmaken, daar deze parameter het meest stijgt. 2076
2100
2045
400
2000
1900
313 217
271 226 1892
1800 1806 1700
500
1763
305 300 200 100
Totale tijd Totale vertraging
0
Grafiek 9 - Onderzoeksvraag 4: invloed op het basisschema
Wat betreft de onzekerheid in het schema, werd gekeken naar die factoren die het meeste invloed hadden de onderzocht kwaliteitsparameters. Deze werden gevonden in onderzoeksvraag 2 85
en zijn voor de totale tijd om het schema te vervolmaken en voor de totale vertraging respectievelijk het wegvallen van een ploeg en een neerslagperiode van 3 dagen. Deze factoren werden dan ook voor deze onderzoeksvraag onderzocht. Om de invloed van het wegvallen van een ploeg te bestuderen werden uit de resultaten van onderzoeksvraag 2 die ploegen gekozen waarvan het wegvallen de meeste invloed heeft. Dit waren ploegen H4, P1 en Z2. In grafiek 11 worden de gemiddelden van de verkregen resultaten getoond. Het s-vormig patroon 11 is in grafiek minder te vinden. Alle waarden liggen ook nu weer hoger dan voor de projectschema’s waarin geen onzekerheid werd ingebracht. Zoals echter in bijlage 7: Rapporten in verband met de statistische significantie te lezen valt, zijn de verschillen niet significant op een 5% significantieniveau. De kwaliteit van het schema met betrekking tot de totale tijd om dit schema te vervolmaken blijft hier dus dezelfde. Men kan dus stellen dat gelijkmatige ploegen de onzekerheid enigszins bedwingen. 2200 2.126 2100
2.055 2.076
2000
1.962
2.045
1.876
1900
Totale tijd Waarde basisschema
1.892 1800
1.763 1.806
1700
1.763 Basisschema
Stap 1: ruwbouw
Stap 2: zinkwerk
Stap 3: Stap 4: dakwerk - dakwerk hellend dak plat dak
Grafiek 10 - Onderzoeksvraag 3: wegvallen van een ploeg
Voor de factor ‘neerslagperiode van 3 dagen’ en de waarden voor de totale vertraging, zijn steeds hogere waarden terug te vinden dan in het basisschema. Naar het einde toe vlakt de grafiek ook een beetje af, maar een duidelijk s-vormig patroon is hier niet te vinden. Enkel voor stap 1 is een waarde te vinden die statistisch significant afwijkt van de waarde van het basisschema. Voor de daaropvolgende stappen wijkt de totale vertraging statistisch gezien niet af op een 5% significantieniveau. Opnieuw kan men dus stellen dat een gelijkmatige grootte van ploegen de onzekerheid kan bedwingen. 86
340
323 312
320 300 300 280
313
305
267
260
271
Totale vertraging Waarde basisschema
240 220 200
217 226 217 Basisschema
Stap 1: ruwbouw
Stap 2: zinkwerk
Stap 3: Stap 4: dakwerk - dakwerk hellend dak plat dak
Grafiek 11 - Onderzoeksvraag 3: neerslagperiode van 3 dagen
Het besluit dat uit deze onderzoeksvraag kan getrokken worden is dat onzekerheid projectschema’s waarin ploegen eenzelfde grootte hebben, minder negatief beïnvloedt. Zowel met betrekking tot de totale tijd om een projectschema af te werken als tot de totale vertraging vindt men een hogere waarden terug tussen het basisschema en de schema’s waarin onzekerheid is gebracht, naarmate alle ploegen van eenzelfde een gelijke grootte hebben. Deze waarden wijken echter niet van elkaar af voor een significantieniveau van 5 %. Deze conclusie werd samengevat in tabel 34. Besluiten getrokken uit deze onderzoeksvraag Onzekerheid heeft geen invloed op die schema’s waar ploegen een gelijke grootte hebben Tabel 34 - Besluiten onderzoeksvraag 4
8.5. Resultaten en interpretatie onderzoeksvraag 5: Wat is de invloed van een multiskilled projectteam op de kwaliteit van het projectschema? Wanneer een gemiddeld project wordt beschouwd, dan valt op dat vooral de ploegen die gekwalificeerd zijn om platte daken te leggen of te herstellen relatief in de meerderheid zijn. Voor deze werken zijn er ongeveer vier werknemers beschikbaar om één mandag werk uit te voeren, terwijl voor de andere werken de verhouding één werknemer per mandag quasi wordt gerespecteerd. De onderzoeksvraag zal zich dus in eerste instantie richten tot de P-ploegen. 87
Timmerwerk Zinkwerk Kenmerken gemiddeld project Totaal aantal werknemers gekwalificeerd Gemiddelde
Dakwerken: Dakwerken: hellend dak plat dak 12 3
7
4
8
6
14
12
1,14
1,50
1,17
4,00
Tabel 35 - Gemiddelde aantal werknemers voor één mandag
Indien alle P-ploegen een bepaalde activiteit kunnen uitvoeren, wordt de totale vertraging opmerkelijk gereduceerd. De grootste reductie is te vinden indien de P-ploegen ook bedreven zijn in timmerwerk, zoals grafiek 13 toont. Dit is dan ook de activiteit waar men het laagste gemiddelde vindt in tabel 35. Maar ook indien de P-ploegen de andere activiteiten kunnen uitvoeren, is een opmerkelijke reductie waar te nemen. Ook de totale tijd om het schema te vervolmaken vermindert, zij het niet zo spectaculair als de totale vertraging doet. 1759 1758 1757
250 195
189
1758
200
1756 1756
1755
150
1754 93
1753
Totale tijd 100
Totale vertraging
1752 1751
1752
50
1750 1749
0 P kan ook LO
P kan ook LZ
P kan ook LT
Grafiek 12 - Onderzoeksvraag 5: P-ploegen
Grafiek 14 toont de testresultaten voor de kwaliteitsparameter totale vertraging, indien slechts één ploeg van de P-ploegen multiskilled is. Hier werd gekozen voor P5. Opnieuw treden er grote reducties op. Ook hier worden de grootste reducties waargenomen indien P5 ook bedrijvig is in het timmerwerk. De totale tijd om het schema te vervolmaken schommelt rond de waarde uit het basisschema en is in sommige gevallen zelfs hoger, zoals waar te nemen valt in grafiek 15.
88
250
210
198
198
200
147
129
150
119
100 50 Totale vertraging P5 kan ook LT en LZ
P5 kan ook LT
P5 kan ook LT en LO
P5 kan ook LZ
P5 kan ook LO en LZ
P5 kan ook LO
0
Grafiek 13 - Onderzoeksvraag 5: P5, totale vertraging
1780 1775 1775
1770 1765
1769
1760 1761
1755 1755
1750 1745
1762
1749
Totale tijd
1740 P5 kan ook LT en LO
P5 kan ook LO
P5 kan ook LZ
P5 kan ook LT
P5 kan ook LO en LZ
P5 kan ook LT en LZ
1735
Grafiek 14 - Onderzoeksvraag 5: P5, totale tijd om het schema te vervolmaken
Waar de totale tijd dus schommelt rond de waarde van het basisschema, kan de totale vertraging opmerkelijk gereduceerd worden. Dit houdt in dat de projecten dus veel vroeger kunnen aanvatten dan in het basisschema, maar dat ze niet sneller worden uitgevoerd. Deze laatste conclusie is niet verwonderlijk aangezien aan de grootte van de teams niets werd veranderd.
89
Indien we dezelfde testen uitvoeren met de H-ploegen, die veel zwaarder beladen zijn, vinden we ook een reductie van de totale vertraging terug, echter niet voor alle testen. De grootste reducties zijn te bespeuren in het geval dat de H-ploegen ook het timmerwerk zouden kunnen uitvoeren. De resultaten van deze testen zijn terug te vinden in grafiek 16. 250
228
226
224
222 195
200
147 150
138
138 105
100 50
Totale vertraging
H kan ook LT
H6 kan ook LT
H6 kan ook LT en LA
H6 kan ook LT en LZ
H kan ook LZ
H6 kan ook LZ en LA
H6 kan ook LA
H6 kan ook LZ
H kan ook LA
0
Grafiek 15 - Onderzoeksvraag 5: H-ploegen, totale vertraging
Met betrekking tot de totale tijd om het schema te vervolmaken zijn dezelfde resultaten terug te vinden als bovenvernoemd. Zij zijn terug te vinden in grafiek 17. 1820 1792
1800
1798
1779
1780 1760
1794
1757 1740
1757
1764
1741
1740 1720 Totale tijd H kan ook LA
H6 kan ook LZ en LA
H6 kan ook LZ
H6 kan ook LA
H kan ook LT
H6 kan ook LT
H6 kan ook LT en LA
H6 kan ook LT en LZ
H kan ook LZ
1700
Grafiek 16 - Onderzoeksvraag 5: H-ploegen, totale tijd om het schema te vervolmaken
90
Als besluit kan men dus stellen dat in deze case studie het multiskilled zijn vooral een positieve invloed heeft, wanneer het betekent dat ploegleden ook die activiteit kunnen overnemen van ploegen die relatief gezien meer werk hebben. Vanuit managementoogpunt is het best om de teams meerdere skills aan te leren aan teams die minder zwaar beladen qua opdrachten zijn. Daar heeft het multiskilled zijn meestal een positieve invloed. De verbetering van de kwaliteit van een projectschema zit hem vooral in het feit dat projecten vroeger kunnen beginnen, waardoor er minder vertraging is. Besluiten getrokken uit deze onderzoeksvraag Onderscheid tussen zwaarder en minder zwaar beladen ploegen De invloed op het schema is vooral positief indien minder zwaar beladen ploegen multiskilled zijn Positieve invloed is vooral te merken bij de totale vertraging Tabel 36 - Besluiten onderzoeksvraag 5
8.6. Besluit van de empirische studie Voor de ter beschikking gestelde gegevens bleek de prioriteitsregel ‘Maximale projectduur eerst’ het beste schema te genereren, waardoor besloten werd om dit schema als basisschema te gebruiken. Het inbrengen van onzekerheid in het projectschema heeft vaak een negatieve invloed op de kwaliteit van het schema. Men kan stellen dat de onzekerheid vooral een invloed heeft op het verlaten van de begindatum van een bepaald project, aangezien de totale vertraging een grotere afwijking van het basisschema vertoont. De invloed van onzekerheid heeft echter niet altijd een negatief effect. Het basisschema vertoont ook een zekere robuustheid. Ook voor een schema waar ploegen een gelijke grootte hebben, is er minder invloed van onzekerheid. Een nauwer tijdsframe vermindert de kwaliteit van het schema met betrekking tot de totale vertraging. Dit effect wordt versterkt indien men onzekerheid in het schema brengt. Wat betreft de totale tijd om het schema af te werken zijn geen afwijkingen waar te nemen. Voorts kan blijft de gemiddelde vertraging quasi gelijk. De kwaliteit van een schema kan verbeterd worden indien ploegen die minder zwaar beladen zijn, meerdere skills aan te leren, waardoor zij activiteiten kunnen overnemen van ploegen die zwaarder beladen zijn. De verbetering van de kwaliteit is dan vooral terug te vinden in het reduceren van de totale vertraging.
91
Een aanbeveling aan managers in een soortgelijke multiprojectomgeving kan dus zijn om het tijdskader van hun projecten zo wijd mogelijk te maken, dit zal de kwaliteit van hun schema ten goede komen. Ook het aanleren van meerdere vaardigheden aan bepaalde ploegen kan de kwaliteit ten goede komen. Men moet echter wel veel aandacht besteden aan welke ploegen men multiskilled tracht te maken. De ploegen gelijke grootten meegeven zal ook helpen in het beheersen van onzekerheid en zal de kwaliteit van het schema ten goede komen. Een belangrijke opmerking bij deze conclusies is dat deze enkel geldig zijn voor het bedrijf DVG. Wel kan men opmerken dat ze veelal gelijklopend zijn met de conclusies gemaakt in de literatuur. Waar dit onderzoek bijdraagt tot de literatuur is dat er gepoogd is om de omgeving zo realistisch mogelijk te houden. Zo werd door het inbrengen van onzekerheid een dynamische omgeving gecreëerd.
92
Algemene conclusie en verder onderzoek Daar waar de meeste onderzoekers zich richten op een singleprojectomgeving, behandelt deze masterproef projecten in een multiprojectomgeving. Men kan stellen dat onderzoek in een multiprojectomgeving relevanter is, aangezien de meeste ondernemingen opereren in zo’n omgeving. In figuur 22 wordt de multiprojectomgeving schematisch voorgesteld.
Figuur 22 - Schematische voorstelling van een multiprojectomgeving
Een onderneming heeft meerdere resources, zoals arbeiders, materiaal en kennis, tot haar beschikking. Deze resources worden aangewend om projecten bij één of meerdere klanten uit te voeren. Een klant kan ook de onderneming zelf zijn, bijvoorbeeld wanneer een onderneming een nieuw ERP-systeem wil integreren. De projecten zelf kunnen onderling afhankelijk van elkaar zijn. Onder andere door de schaarsheid van de resources en de onderlinge afhankelijkheid van projectfases en projecten is er een grote mate aan complexiteit aanwezig in het multiprojectschema. Daarnaast wordt onzekerheid in het schema gebracht door invloeden van buiten uit. Doordat de meeste ondernemingen opereren in een open omgeving, voelen zij de invloed van de economische toestand van hun superomgeving, werknemers kunnen ten allen tijde ziek worden of ontslag nemen, 93
weersomstandigheden kunnen steeds roet in het eten gooien, etc. Ondanks al deze verstoringen moet een onderneming steeds trachten de gedane beloften aan een klant, met betrekking tot tijd, kost en kwaliteit, waar te maken. Zowel een goede proactieve als reactieve aanpak van deze onzekerheid is dus nodig. Hoe dan ook, is het steeds nodig om de controle te bewaren over welke projecten een onderneming uitvoert. Dit wordt gerealiseerd door het projectportfoliomanagement. Een goede integratie tussen de verkoopafdeling en de operationele afdelingen is daarvoor zeer belangrijk. Wat betreft het inplannen zelf, kan men stellen dat een multiprojectomgeving wel samen te vatten valt in een wiskundig model, maar dat men dit model niet kan oplossen, wegens te complex. Wel kan het model gebruikt worden om de werkelijkheid beter te begrijpen. Om een multiprojectplanning op te maken, kan men gebruik maken van heuristieken. In deze masterproef werden het serieel inplannen, het parallel inplannen, simulated annealing, genetische algoritmes en een hybride vorm van de laatste twee besproken. Voor deze masterproef werd een case studie gedaan rond het bedrijf De Vroe Groep (DVG), gevestigd te Merelbeke en actief in een multiprojectomgeving. DVG vertoont vele raakvlakken met de literatuur. Voorbeelden daarvan zijn dat DVG rekening houdt met de strategie van de onderneming als het projecten selecteert. Ook kan men DVG classificeren als een mechanischgestructureerde onderneming; de bijhorende kenmerken waren ook van toepassing op DVG. Naast de raakvlakken waren er ook een aantal verschilpunten. De arbeiders van DVG zijn bijvoorbeeld allemaal singleskilled, waar men in een multiprojectomgeving vooral werknemers verwacht die multiskilled zijn. Ook zijn er een aantal aspecten aangehaald die niet vermeld werden in de literatuur. Zo poogt men in DVG de onzekerheid te bedwingen met software en houdt men ook rekening met de afstand tussen de bouwwerf en DVG als men projecten gaat selecteren. Er werd ook een empirische studie gedaan. Hiervoor werd een eigen softwareprogramma ontwikkeld. Door middel van het softwareprogramma te laten lopen met data die verkregen werd bij DVG, werden verschillende hypotheses getest. Net zoals in de literatuur werd gesteld, gaven verschillende prioriteitsregels verschillende projectschema’s weer. Het selecteren van de prioriteitsregel en het daaruit resulterende schema werd gedaan door een link met de realiteit te leggen. De keuze viel uiteindelijk op de prioriteitsregel ‘Maximale projectduur eerst’.
94
Er werd ook onderzocht wat de invloed van onzekerheid op het projectschema is. Gelijkaardig met de literatuur was een negatieve invloed te bemerken, vooral wat betreft de totale vertraging. Doch, door het inbrengen van onzekerheid was het ook mogelijk dat de kwaliteit van het schema in positieve zin werd beïnvloed. Onzekerheid had vervolgens vaak een negatieve invloed op de kwaliteit van het schema indien men de tijdskaders ging vernauwen. De groottes van de teams gelijk maken had dan weer een matigende invloed op de onzekerheid. Een zeer interessante conclusie die werd getrokken is het feit dat multiskilled zijn niet altijd een positieve invloed heeft op het projectschema. Enkel ploegen die minder opdrachten hebben in vergelijking met de andere ploegen, hebben er baat bij meerdere skills aan te leren. De beste resultaten werden gevonden indien zij ook de vaardigheden leren van de zwaarst beladen ploeg. Men kan aan managers in een soortgelijke multiprojectomgeving aanbevelen dat ze bij het plannen alle projecten samen moeten beschouwen. Een singleprojectaanpak is hier minder efficiënt. Ook moeten ze bij klanten trachten een zo breed mogelijk tijdskader te onderhandelen. Het aanleren van meerdere skills is enkel gunstig voor die ploegen die minder opdrachten hebben in vergelijking met de andere ploegen. De ploegen gelijke groottes meegeven zal ook helpen in het beheersen van onzekerheid en zal de kwaliteit van het schema ten goede komen. Wat betreft verder onderzoek, kan worden aanbevolen om zich steeds te richten op dynamische en open omgevingen. Dit zijn de omgevingen die in de realiteit het vaakst voorkomen en onderzoek hieromtrent is dus zeker relevant. Ook kan men trachten een mathematisch model op te stellen dat alle uitbreidingen omvat. Zoals eerder gesteld, zal men dit model niet kunnen oplossen, maar het kan handig zijn bij het ontwikkelen van nieuwe heuristieken. Het softwareprogramma dat voor deze masterproef werd ontwikkeld, kan worden aangevuld met heuristieken om de initieel verkregen oplossing te verbeteren. Vervolgens kan worden getest of de gevonden onderzoeksresultaten nog steeds geldig zijn. Ten slotte kunnen onderzoekers ook nagaan of de onderzoeksresultaten ook geldig zijn voor andere bedrijven in de bouwsector of in andere sectoren.
95
Lijst van geraadpleegde werken Aggeri, F., & Segrestin, B. (2007). Innovation and project development: an impossible equation? Lessons from an innovative automobile project development. Ecole des Mines, Paris. Oxford, United Kingdom: Blackwell Publishing Ltd. Aramo-Immonem, H., & Vanharanta, H. (2009). Project Management: The Task of Holistic Systems Thinking. Human Factors and Ergonomics in Manufacturing, Vol. 19 (6) , 582-600. Aritua, B., Smith, N. J., & Bower, D. (2008). Construction client multi-projects – A complex adaptive systems perspective. University of Leeds, Leeds, United Kingdom: Elsevier Ltd. Ash, R. (2009). An examination of engineering personnel assignment policies in the multi-project, capacity constrained situation. Engineering Management Journal , 21 (4), 58-70. Bagherpour, M., Zareei, A., Noori, S., & Heydari, M. (2009). Designing a control mechanism using earned value analysis: an application to production environment. International Journal Advanced Manufacturing Technology . Ballestín, F., & Blanco, R. (2011). Theoretical and practical fundamentals for multi-objective optimisation in resource-constrained projct scheduling problems. Computers & Operations Research 38 , 51-62. Banaszak, Z., Muszynski, W., & Zaremba, M. (2007). Constraint programming for project-driven manufacturing. Technical University of Koszalin, Poland: Int. J. Production Economics. Blomquist, T., & Wilson, T. L. (2007). Project marketing in multi-project organizations: A comparison of IS/IT and engineering firms. Industrial MArketing Management 36 , 206-218. Browning, T. R., & Yassine, A. A. (2010). A random generator of resource-constrained multiproject network problems. J Sched 13 , 143-161. Chen, P.-H., & Mohsen Shahandeshti, S. (2009). Hybrid of genetic algorithm and simulated annealing for multiple project scheduling with multiple resource constraints. Automation in Construction (18), 434-443. Cohen, I., Golany, B., & Shtub, A. (2007). Resource allocation in stochastic, finite-capacity, multiproject systems through the cross entropy methodology. J. Sched. (10), 181-193.
96
Confessore, G., Giordani, S., & Rismondo, S. (2006). A market-based multi-agent system model for decentralized multi-project scheduling. Ann. Oper. Res. (150), 115-135. Cooper, M. J., & Budd, C. S. (2006). Tying the pieces together: A normative framework for integrating sales and project operations. Industrial Marketing Management (36), 173-182. Dawson, R. J. (2011, mei 18). Table of t-values. Retrieved mei 18, 2011, from Dept.of Math & Computing
Science,
St.
Mary’s
University,
Canada:
http://oak.snr.missouri.edu/nr3110/pdf/table1.pdf Elonen, S., & Artto, K. A. (2003). Problems in managing internal development projects in multiprojects environments. International Journal of Project Management (21), 395-402. Geraldi, J. G. (2007). The balance between order and chaos in multi-project firms: A conceptual model. International Journal of Project Management , 348-356. Gonçalves, J., Mendes, J., & Resende, M. (2008). A genetic algorithm for the resource constrained multi-project scheduling problem. European Journal of Operational Research (189), 1171-1190. Hans, E., Herroelen, W., Leus, R., & Wullink, G. (2005). A hierarchical approach to multi-project planning under uncertainty. University of Twente, The Netherlands: Elsevier Ltd. Heimerl, C., & Kolisch, R. (2010). Scheduling and staffing multiple projects with a multi-skilled workforce. OR Spectrum 32 , 343-368. Herbots, J., Herroelen, W., & Leus, R. (n.d.). Dynamic Order Acceptance and Capacity Planning on a Single Bottleneck Resource. Katholieke Universiteit Leuven, België: Departement van Beslissingswetenschappen en Informatiemanagement. Kaulio, M. A. (2008). Project leadership in multi-project settings: Findings from a critical incident study. International Journal of Project Management (26), 338-347. Krüger, D., & Scholl, A. (2009). A heuristic solution framework for the resource constrained (multi-)project scheduling problem with sequence-dependent transfer times. European Journal of Operational Research (197), 492-508. Krüger, D., & Scholl, A. (2010). Managing and modelling general resource transfers in (multi)project scheduling. OR Spectrum 32 , 369-394.
97
Kumanan, S., Jegan Jose, G., & Raja, K. (2006). Multi-project scheduling using a heuristic and a genetic algorithm. International Journal Advanced Manufacturing Technology 31 , 360-366. Lova, A., Tormos, P., Cervantes, M., & Barber, F. (2009). An efficient hybrid genetic algorithm for scheduling projects with resource constraints and multiple execution modes. Int. J. Production Economics 117 , 302-316. Midler, C., & Silberzahn, P. (2008). Managing robust development process for high-tech startups through multi-project learning: The case of two European startups. International Journal of Project Management 26 , 479-486. Mota, C. M., de Almeida, A. T., & Alencar, L. H. (2009). A multiple criteria decision model for assigning priorities to activities in project management. International Journal of Project Management (27), 175-181. Olsson, R. (2008). Risk management in a multi-project environment - An approach to manage portfolio risks. International Journal of Quality & Reliability Management , 25 (1), 60-71. Patrick, F. S. (1998). Turning many projects into few priorities with TOC. Focused Performance. Pellegrinelli, S. (1997). Programme Management: organising project based change. Int J Proj Manage . Raiden, A. B., Dainty, A. R., & Neale, R. H. (2008). Understanding employee resourcing in construction organizations. Construction Management and Economics (26), 1133-1143. Tobis, M., & Tobis, I. (2002). Managing multiple projects. United States of America: Mc Graw Hill. Vanhoucke, M. (2010). Applied Operations Research. Gent: Academia Press. Vanhoucke, M. (2009-2010). Project Management. Gent: Academia Press. Wuliang, P., & Chengen, W. (2009). A multi-mode resource-constrained discrete time-cost tradeoff problem and its genetic algorithm based solution. International Journal of Project Management (27), 600-609.
98
Zika-Viktorsson, A., Sundström, P., & Engwall, M. (2006). Project overload: An exploratory study of work and management in multi-project settings. International Journal of Project Management (24), 385-394.
99
Bijlage 1: Lijst van kritische incidenten Deze lijst is gerangschikt volgens de frequentie waarin deze incidenten voorkomen, zoals weergegeven in (Kaulio, 2008). 1. Technische moeilijkheden 2. Problemen met het overbrengen van leiderschap naar de ondergeschikten 3. Groepsdynamiek 4. Problemen rond relaties met consultants 5. Problemen rond relaties met klanten 6. Problemen rond relaties met gelijken 7. Aanpassingen van het project door invloeden van buiten uit 8. Aanpassingen van de prioriteiten 9. Gelinkte dyadische groepsprocessen 10. Problemen bij de vorming van het project 11. Beslissingen door een rechtbank 12. Afhankelijkheid van een derde partij 13. Het niet goed vooraf afspreken wat een bepaald project moet behelzen.
Bijlage 1.1
Bijlage 2: Lijst van kritische incidenten in ondernemingen die nieuwe producten ontwikkelen Deze lijst bezit geen specifieke rangschikking en is overgenomen uit (Elonen & Artto, 2003). 1. Geen link tussen de strategie en de projecten die de onderneming start 2. Het portfolio is van slechte kwaliteit: te veel projecten worden aan een zwakke tot middelmatige kwaliteit afgeleverd 3. Het niet kunnen stopzetten van een project, indien dit nodig blijkt 4. Geen focus, waardoor het gebruik van resources slecht gebalanceerd wordt 5. Het enkel selecteren van gemakkelijke en kortetermijnprojecten 6. Enerzijds een te veel aan informatie, anderzijds een inferieure kwaliteit van deze informatie 7. Politisering van beslissingen
Bijlage 2.1
Bijlage 3: Overzicht van de gebruikte symbolen in het mathematisch model Symbool P |P| aij dij fij t hrij xrijt sr lrt qrijt vijt TIij
Uitleg Set van projecten: {p1, …, pn} Aantal projecten die gepland moeten worden Activiteit j van project i Tijdsduur van activiteit j van project i Uiteindelijk eindtijd van activiteit j van project i Tijdseenheid Nood aan resource r van activiteit j van project i 1 als resource r door activiteit j van project i wordt gebruikt op tijdstip t 0 als anders Totale beschikbaarheid van resource r Staat van de poel Voorwaarde: 0 ≤ lrt ≤ sr Aantal resources van type r die op tijdstip t aan een activiteit j van een project i zijn toegewezen 1 als activiteit j van project i eindigt op tijdstip t 0 als anders Tijdsinterval: [vroegste eindtijd; laatste eindtijd] van activiteit j van project i
Bijlage 3.1
Bijlage 4: Contactgegevens en overzicht van gesprekken met DVG Contactgegevens: De Vroe Groep Poelstraat 137 9820 Merelbeke Telefoon: 09/230.82.83 Website: http://www.devroegroep.be/ E-mailadres:
[email protected]
Overzicht van de gevoerde gesprekken: Tijdstip 25 juni 2010, 10u 7 juli 2010, 13u30 12 april 2011, 10u 27 april 2011, 14u
Bijlage 4.1
Bijlage 5: Overzicht van de teams, werkzaam in DVG Ploegnummer
Aantal teamleden
Vaardigheden
B1
5
Ruwbouw
B2
5
Ruwbouw
B3
3
Ruwbouw
B4
2
Ruwbouw
H1
2
Hellend dak
H2
2
Hellend dak
H3
2
Hellend dak
H4
3
Hellend dak
H5
2
Hellend dak
H6
3
Hellend dak
P1
3
Plat dak
P2
2
Plat dak
P3
2
Plat dak
P4
3
Plat dak
P5
2
Plat dak
S1
2
Timmerwerk
S2
2
Timmerwerk
S3
2
Timmerwerk
S4
2
Timmerwerk
Z1
1
Zinkwerk
Z2
2
Zinkwerk
Z3
1
Zinkwerk
Z4
2
Zinkwerk
Bijlage 5.1
Bijlage 6: Database van de ter beschikking gestelde projecten Dossier
Dossiernaam
Duedate
LR
LO
LT
LA
LZ
Beekman – Gent
Vroegste begindatum 0
10/131
23
0
11
10
0
2
10/199
Paelinck – Destelbergen
0
160
0
20
2
5
4
10/203
0
160
0
3
0
6
0
52
61
0
26
0
0
8
10/207
Res De Vos/Immo Pannier - Gent Notte-Vanoverschelde Machelen Fortis/Novo IB – Halle
12
34
0
7
3
18
1
10/211
Van Oost – Wondelgem
45
63
0
23
10
0
4
10/213
Thibo – Wetteren
0
40
0
62
25
0
0
10/223
De Keyser – Merelbeke
0
20
0
18
0
2
2
10/225
Vanremoortel – Gent
0
160
0
7
13
5
0
10/230
Bruyneel – Heusden
0
160
0
0
0
5
0
10/232
12
23
0
16
0
2
6
10/233
Timmermans/Broens Wichelen Stevens – Zottegem
0
160
0
5
0
0
0
10/234
Kiebooms – Gent
0
20
0
15
0
6
4
10/244
Van Damme – Zwijnaarde
0
160
0
3
18
3
2
10/252
Cozyns - Groot-Bijgaarden
15
22
0
11
0
10
5
10/258
0
160
0
2
8
20
1
0
160
0
8
0
27
4
10/275
Swinnen/Bonapart - StAmandsberg Domus Nova Invest Ingelmunster Droesschaut – Baaigem
0
160
0
2
0
0
0
10/277
Van De Velde – Sleidinge
0
160
0
0
0
2
0
10/278
De Lobelle – Balegem
0
160
0
0
2
0
9
10/280
Van den Steen
45
63
0
12
0
3
12
10/283
Kielemoes - De Witte Oosterzele Locquet – Gent
40
51
0
0
0
5
0
0
160
0
1
0
9
0
10/204
10/269
10/301
Bijlage 6.1
10/304
10/311
VK Studio/vzw Zoete Nood Gods - Lede Beaucourt - StAmandsberg De Ganck – Destelbergen
0
101
0
3
18
41
0
0
160
2
0
0
5
1
24
61
0
14
0
8
1
10/320
Caufrier – Destelbergen
0
160
0
1
0
0
0
10/321
Arch Matthys – Gent
0
300
0
13
0
1
1
10/345
Van Reetingen Merelbeke Verbeke – Gent
0
160
0
1
0
0
0
0
160
0
30
0
0
4
81
101
0
0
0
0
8
10/355
LEFINVEST/Tea-Room Rigoletto - Gent Bogaert - St-Amandsberg
40
200
0
9
0
0
0
10/358
Quaghebeur – Ledeberg
122
159
0
4
11
0
2
10/362
Tack – Gentbrugge
40
200
0
8
18
2
1
10/364
34
61
0
6
18
6
1
40
200
0
19
0
2
0
10/370
Weustenrad-Gysbrecht Zwijnaarde Arch Verstraete Merelbeke De Maersschalck – Gent
40
200
0
6
0
0
1
10/372
Coppieters – Balegem
40
200
12
68
22
0
6
10/375
Bruggeman/Braeckman Heusden De Winne – Eke
102
121
0
10
0
3
8
40
200
0
4
5
0
4
Bourgois-Biesemen - StNiklaas Piens – Oostende
40
200
0
2
0
0
2
40
200
0
10
8
1
1
Quinet - Golsteyn Merelbeke Colpaert – Gent
40
200
0
17
1
0
3
40
200
0
5
0
0
2
132
147
0
0
0
9
1
40
200
0
4
0
5
3
10/396
De Visscher - Strombeek Bever Lapeirre-Martens Lovendegem Burvenich – Merelbeke
40
200
6
8
0
0
9
10/398
Kellens – Merelbeke
145
159
0
8
2
0
2
10/401
Tavernier – Gent
80
240
0
20
6
0
3
10/307
10/347 10/352
10/369
10/378 10/380 10/384 10/387 10/388 10/391 10/392
Bijlage 6.2
10/405
Van Parys – Merelbeke
80
240
0
14
3
0
2
10/408
Verheyen – Zwalm
145
159
0
20
10
0
4
10/417
Buyse - Sint-Laureins
181
205
9
31
38
5
11
10/424
Danneels – Gent
80
240
6
8
28
0
3
10/427
80
240
0
10
23
6
3
145
159
0
19
7
6
5
132
155
0
0
0
0
35
10/432
Arch Mariman - StAmandsberg Temmerman-Pollet Groot-Bijgaarden NV Van Maercke/NV Verguts - Wijnegem Dierick – Gentbrugge
80
240
1
11
0
0
2
10/436
Raman – Heusden
80
240
0
14
0
0
1
10/441
Jansen – Oosterzele
80
240
0
2
0
0
0
10/444
Dhaenens – Ledeberg
80
240
6
9
14
8
0
10/448
Vermeulen – Gent
80
240
0
0
31
0
2
10/449
Colman – Gent
80
240
0
2
0
0
0
10/454
Boel – Hamme
116
159
4
85
19
0
8
10/459
Goderis – Gent
174
204
0
5
22
0
2
10/460
VDK Spaarbank – Gent
74
80
0
2
0
0
1
10/461
De Roo/Willems Sleidinge De Roo/Henderickx Albiol - Drongen Hovaert – Gent
60
80
0
14
0
0
2
80
240
0
18
0
1
6
120
280
0
0
19
0
1
Baerdeman - Cottyn Gent IDEALAB – Gent
160
180
0
0
14
0
2
122
159
0
0
0
2
145
180
2
29
5
5
11/010
Van Beneden Gentbrugge De Ghesquiere – Astene
45 4 8
120
280
0
0
0
26
1
11/012
De Somere – Gent
174
204
0
0
0
0
4
11/014
Aksis/Danneels - StDenijs-Westrem De Graeve – Merelbeke
88
121
0
11
7
0
0
120
280
0
5
42
16
3
10/428 10/429
10/462 11/002 11/004 11/006 11/008
11/018
Bijlage 6.3
11/027
Arch Michiels - StAmandsberg arch Devreese/Ghekiere Zwijnaarde Arch Blondeel/Deman Lovendegem Vandeweghe – Gent
120
280
0
7
1
1
0
169
210
0
12
10
5
2
145
159
0
0
0
16
0
120
280
0
0
0
15
0
Arch De Keukelaere - Van Damme - Melsen Verhaegen - De Vroe Moortsele Ameels – Zottegem
120
280
0
0
0
13
1
120
280
18
0
35
13
0
120
194
0
24
10
0
3
120
280
0
0
1
0
0
11/045
Alg Ond De Reu/Garage Delabarre - Gent Van Baarle – Gijzenzele
160
199
0
16
0
0
0
11/046
Bulté - St-Amandsberg
206
227
0
10
0
0
0
11/048
Bulté - St-Amandsberg
206
227
0
12
4
4
2
11/051
Van De Putt – Lemberge
120
280
0
0
0
4
0
11/054
Van Sande – Munte
120
280
0
2
0
6
2
11/055
Rogiest - St-Amandsberg
120
280
0
8
0
0
0
11/057
bvba Phariseau & Mattelin - Gentbrugge R&S Projects - SintMartens-Latem VDK Spaarbenk/VDK 014 Destelbergen Vanheulenberghe – Asper
97
140
0
25
5
10
3
120
280
0
54
0
44
25
120
280
0
0
0
6
0
227
248
0
11
6
0
2
120
280
41
12
29
6
1
11/070
Arch Van Caimere/Bosschaert Moortsele Casaer - Chartier – Melle
132
144
0
0
49
0
0
11/071
Souvage – Gent
120
280
0
3
0
0
0
11/072
Bio Fresh – Gavere
120
280
0
0
0
4
0
11/074
155
168
0
15
15
0
5
11/076
Bouw & Immobiliën René Dhont - Melle Besard – Gent
160
320
0
5
23
0
3
11/078
Artea/Peeters – Kapellen
160
320
0
0
0
13
0
11/031 11/032 11/035 11/036 11/039 11/043 11/044
11/058 11/062 11/066 11/068
Bijlage 6.4
11/080
Ceelen - Mees – Merelbeke Blok - Ballegeer – Melle
116
126
0
2
0
0
0
160
320
22
0
18
3
0
Van Nieuwenhoven – Gentbrugge Verhaegen – Wetteren
160
320
0
19
0
0
0
215
248
0
44
7
0
5
122
168
0
63
5
1
7
11/093
Goffaert - De Roeck - De Pinte Martens - Scheldewindeke
129
135
0
0
1
0
0
11/094
Roels – Oosterzele
160
320
0
16
0
0
0
11/095
Rul – Gent
206
246
0
10
0
0
0
11/102
Goedertier – Balegem
160
320
0
19
0
0
2
11/107
160
320
0
0
0
30
0
11/108
St-Janscollege De Krekel St-Amandsberg Simoens – Gentbrugge
160
320
0
1
0
0
0
11/109
Kuipers – Ledeberg
160
320
0
0
0
3
0
11/112
156
206
0
24
0
21
7
11/115
Bouw & Immobiliën René Dhont - St-Amandsberg De Bock – Merelbeke
227
240
0
0
9
4
1
11/117
Verbeerst – Melle
239
299
0
62
0
0
9
11/118
Lauwers – Gent
203
226
0
7
3
0
2
11/120
Callier – Merelbeke
160
320
0
0
2
0
3
11/121
De Mey – Lemberge
237
297
0
13
55
2
5
11/122
NV De Ceuninck/De Mulder – Merelbeke De Somviele – Zarlardinge
160
320
0
30
0
0
0
120
280
0
27
8
0
3
11/084 11/089 11/091 11/092
11/053
Bijlage 6.5
Bijlage 7: Rapporten in verband met de statistische significantie Alle resultaten werden getest op een 5% significantie niveau en vergeleken met de t-waarden. Deze waarden werden gevonden op volgende website: (Dawson, 2011). Met betrekking tot onderzoeksvraag 2, alle testen omtrent onzekerheid: Kwaliteitsparameter
Aantal testen
Gemiddelde met onzekerheid
Waarde basisschema
Standaardafwijking
Teststatistiek
Kritische waarde
Totale tijd
230
1767,221
1763
23,317
2,745
1,984
Totale vertraging
230
245,780
217
55,685
7,838
1,984
Significant? significant op 5% significant op 5%
Bijlage 7.1
Met betrekking tot onderzoeksvraag 2, opsplitsing naar factoren die onzekerheid in het schema brengen, kwaliteitsparameter Totale tijd om het schema te vervolmaken:
Oorzaak onzekerheid Ziekte van een teamlid (1 dag) Ziekte van een teamlid (2 dagen) Ziekte van een teamlid (3 dagen) Ziekte van een teamlid (4 dagen) Ziekte van een teamlid (5 dagen) Neerslagperiode (1 dag) Neerslagperiode (2 dagen) Neerslagperiode (3 dagen) Neerslagperiode (4 dagen) Neerslagperiode (5 dagen) Wegvallen van een team Spoedproject Combinatie
Aantal testen
Gemiddelde met onzekerheid
Waarde basisschema
Standaardafwijking
Teststatistiek
Kritische waarde
20
1767,75
1763
11,192
1,898
2,086
20
1764,3
1763
3,294
1,764
2,086
20
1768,1
1763
7,048
3,236
2,086
20
1757,75
1763
14,913
1,574
2,086
20
1760,65
1763
33,143
0,317
2,086
10
1766,82
1763
19,172
0,630
2,228
10
1769,909
1763
18,447
1,184
2,228
20
1767,75
1763
25,567
0,831
2,086
10
1772,818
1763
23,012
1,349
2,228
20
1768,15
1763
17,058
1,350
2,086
10
1793,6
1763
43,372
2,231
2,228
significant op 5%
20
1779,5
1763
29,598
2,493
2,086
30
1762
1763
28,277
0,194
2,045
significant op 5% niet significant op 5%
Significant? niet significant op 5% niet significant op 5% significant op 5% niet significant op 5% niet significant op 5% niet significant op 5% niet significant op 5% niet significant op 5% niet significant op 5% niet significant op 5%
Bijlage 7.2
Met betrekking tot onderzoeksvraag 2, opsplitsing naar factoren die onzekerheid in het schema brengen, kwaliteitsparameter Totale vertraging:
Oorzaak onzekerheid Ziekte van een teamlid (1 dag) Ziekte van een teamlid (2 dagen) Ziekte van een teamlid (3 dagen) Ziekte van een teamlid (4 dagen) Ziekte van een teamlid (5 dagen) Neerslagperiode (1 dag) Neerslagperiode (2 dagen) Neerslagperiode (3 dagen) Neerslagperiode (4 dagen) Neerslagperiode (5 dagen) Wegvallen van een team Spoedproject Combinatie
Aantal testen
Gemiddelde met onzekerheid
Waarde basisschema
Standaardafwijking
Teststatistiek
Kritische waarde
20
215,65
217
4,344
1,390
2,086
20
216
217
5,487
0,815
2,086
20
213,85
217
7,271
1,937
2,086
20
253,95
217
52,349
3,157
2,086
significant op 5%
20
269,45
217
51,043
4,595
2,086
significant op 5%
10
252,636
217
42,474
2,653
2,228
significant op 5%
10
241,909
217
41,106
1,916
2,228
niet significant op 5%
20
287,1
217
90,292
3,472
2,086
significant op 5%
10
223,181
217
32,292
0,605
2,228
niet significant op 5%
20
227,25
217
15,944
2,875
2,086
significant op 5%
10
241,6
217
58,289
1,335
2,228
20 30
271,6 276
217 217
77,687 58,687
3,143 5,506
2,086 2,045
Significant? niet significant op 5% niet significant op 5% niet significant op 5%
niet significant op 5% significant op 5% significant op 5%
Bijlage 7.3
Met betrekking tot onderzoeksvraag 3, neerslagperiode van 3 dagen, kwaliteitsparameter Totale vertraging:
160 dagen 80 dagen
Aantal testen 10 10
Gemiddelde met onzekerheid 287 255
Waarde basisschema 217 217
60 dagen
10
286
40 dagen
10
20 dagen 15 dagen
10 10
Tijdskader
Standaardafwijking
Teststatistiek
90,292 42,641
3,472 2,373
Kritische waarde 2,167 2,167
214
114,134
0,028
2,167
324
270
65,953
1,774
2,167
579 641
470 593
106,285 34,164
8,688 32,767
2,167 2,167
Significant? significant op 5% significant op 5% niet significant op 5% niet significant op 5% significant op 5% significant op 5%
Bijlage 7.4
Met betrekking tot onderzoeksvraag 4, wegvallen, kwaliteitsparameter Totale tijd om het schema te vervolmaken: Stappen in het onderzoek
Aantal testen
Gemiddelde met onzekerheid
Waarde basisschema
Standaardafwijking
Teststatistiek
Kritische waarde
Stap 1: ruwbouw
3
1876
1806
65,38
1,854
4,303
Stap 2: zinkwerk
3
1962
1892
70,667
1,716
4,303
3
2055
2045
43,554
0,398
4,303
3
2126
2076
36,019
2,420
4,303
Stap 3: dakwerk hellend dak Stap 4: dakwerk - plat dak
Significant? niet significant op 5% niet significant op 5% niet significant op 5% niet significant op 5%
Bijlage 7.5
Met betrekking tot onderzoeksvraag 4, neerslagperiode van 3 dagen, kwaliteitsparameter Totale vertraging: Stappen in het onderzoek Stap 1: ruwbouw
Aantal testen 10
Gemiddelde met onzekerheid 266,6
Waarde basisschema 226
Stap 2: zinkwerk
10
299,6
10 10
Stap 3: dakwerk hellend dak Stap 4: dakwerk plat dak
Standaardafwijking
Teststatistiek
28,586
4,491
Kritische waarde 2,228
271
49,25
1,836
2,228
311,6
313
68,698
0,064
2,228
322,6
305
49,478
1,125
2,228
Significant? significant op 5% niet significant op 5% niet significant op 5% niet significant op 5%
Bijlage 7.6
Bijlage 8: Exacte resultaten voor de verschillende prioriteitsregels 1. Vroegste duedate Totale tijd om het schema te vervolmaken Makespan Mean project set flow time Totale vertraging Maximale vertraging Aantal jobs dat hun deadline overschrijdt Gemiddelde vertraging 2. Least slack Totale tijd om het schema te vervolmaken Makespan Mean project set flow time Totale vertraging Maximale vertraging Aantal jobs dat hun deadline overschrijdt Gemiddelde vertraging 3. Kortste activiteit van een project eerst Totale tijd om het schema te vervolmaken Makespan Mean project set flow time Totale vertraging Maximale vertraging Aantal jobs dat hun deadline overschrijdt Gemiddelde vertraging 4. Maximale projectduur eerst Totale tijd om het schema te vervolmaken Makespan Mean project set flow time Totale vertraging Maximale vertraging Aantal jobs dat hun deadline overschrijdt Gemiddelde vertraging 5. Maximale kost eerst Totale tijd om het schema te vervolmaken Makespan Mean project set flow time Totale vertraging Maximale vertraging Aantal jobs dat hun deadline overschrijdt Gemiddelde vertraging
1839.0 76.0 15.325 145.0 24.0 13.0 11.154 1821.0 62.0 15.175 177.0 26.0 16.0 11.063 1799.0 77.0 14.992 217.0 49.0 14.0 15.5 1763.0 66.0 14.962 217.0 39.0 16.0 13.563 1793.0 62.0 14.942 185.0 37.0 14.0 13.214
Bijlage 8.1
Bijlage 9: Basisschema Dossier
Deadline
Begindatum
Einddatum
Vertraging
Taak
10/131
23
11
24
1
10/199
160
3
22
0
10/203
160
1
7
0
10/204
61
52
74
13
10/207
34
15
34
0
10/211
63
46
63
0
10/213
40
1
46
6
10/223
20
4
20
0
10/225
160
7
21
0
10/230 10/232
160 23
1 12
3 26
0 3
10/233 10/234
160 20
1 2
4 13
0 0
10/244
160
6
21
0
10/252
22
15
33
11
LT LZ LO LT LZ LO LA LO LA LZ LO LT LZ LO LA LT LZ LO LT LO LZ LO LA LT LO LA LA LZ LO LA LO LZ LO LA LT LZ LO LA LZ LO
Duurtijd Ploeg 10 2 11 2 4 20 5 3 6 8 26 3 1 7 18 10 4 23 25 62 2 18 2 13 7 5 5 6 16 2 5 4 15 6 18 2 3 3 5 11
S3 Z3 H4 S4 Z4 H1 P3 H3 P5 Z1 H5 S1 Z4 H5 P5 S2 Z4 H6 S1 H2 Z2 H3 P5 S2 H6 P3 P1 Z4 H3 P5 H5 Z4 H4 P4 S4 Z2 H4 P1 Z1 H5
Begindatum taak 11 17 20 3 5 12 8 1 4 52 61 15 18 20 25 46 52 55 1 15 4 6 19 7 19 15 1 12 18 16 1 2 8 5 6 16 18 20 15 27
Einddatum taak 16 19 24 4 7 22 11 3 7 60 74 17 19 24 34 51 54 63 14 46 5 15 20 14 21 18 3 15 26 17 4 4 13 7 15 17 19 21 20 33 Bijlage 9.1
10/258
160
2
18
0
10/269
160
1
25
0
10/275 10/277 10/278
160 160 160
2 1 16
3 2 23
0 0 0
10/280
63
45
67
4
10/283 10/301
51 160
40 1
42 8
0 0
10/304
101
1
27
0
10/307
160
1
11
0
10/311
61
24
37
0
10/320 10/321
160 300
2 6
2 16
0 0
10/345 10/347
160 160
3 1
3 16
0 0
10/352 10/355 10/358
101 200 159
81 40 158
89 45 172
0 0 13
10/362
200
40
58
0
10/364
61
34
53
0
LA LT LZ LO LA LZ LO LA LO LA LT LZ LZ LO LA LA LO LA LT LO LA LZ LA LZ LO LA LO LZ LO LA LO LZ LO LZ LO LT LZ LO LT LZ LO LA LT LZ LO LA
10 8 1 2 20 4 8 27 2 2 2 9 12 12 3 5 1 9 18 3 41 1 5 1 14 8 1 1 13 1 1 4 30 8 9 11 2 4 18 1 8 2 18 1 6 6
P3 S2 Z3 H2 P1 Z1 H1 P2 H2 P3 S2 Z2 Z3 H3 P2 P4 H1 P2 S3 H6 P4 Z2 P5 Z3 H1 P1 H6 Z1 H5 P1 H4 Z3 H6 Z3 H3 S3 Z4 H4 S3 Z2 H1 P4 S4 Z1 H5 P3
21 2 7 9 11 1 6 11 2 1 16 18 45 61 58 40 1 3 1 26 11 6 8 24 26 34 2 6 9 8 3 1 6 81 40 158 165 171 40 50 54 52 34 44 50 46
26 6 8 10 18 5 10 25 3 2 17 23 57 67 60 42 2 8 10 27 25 7 11 25 33 37 2 7 16 8 3 5 16 89 45 164 166 172 49 51 58 53 43 45 53 49 Bijlage 9.2
10/369
200
40
48
0
10/370
200
40
44
0
10/372
200
40
83
0
10/375
121
102
115
0
10/378
200
42
52
0
10/380
200
40
44
0
10/384
200
41
54
0
10/387
200
40
51
0
10/388
200
40
45
0
10/391
147
134
141
0
10/392
200
40
49
0
10/396
200
40
54
0
10/398
159
166
181
22
10/401
240
80
97
0
10/405
240
80
91
0
10/408
159
146
167
8
10/417
205
181
231
26
LO LA LZ LO LR LT LZ LO LZ LO LA LT LZ LO LZ LO LT LZ LO LA LT LZ LO LZ LO LZ LA LZ LO LA LR LZ LO LT LZ LO LT LZ LO LT LZ LO LT LZ LO LR
19 2 1 6 12 22 6 68 8 10 3 5 4 4 2 2 8 1 10 1 1 3 17 2 5 1 9 3 4 5 6 9 8 2 2 8 6 3 20 3 2 14 10 4 20 9
H4 P5 Z1 H6 B2 S4 Z2 H4 Z2 H2 P2 S1 Z1 H4 Z3 H1 S2 Z2 H3 P1 S1 Z2 H6 Z2 H5 Z2 P3 Z4 H1 P2 B4 Z4 H2 S3 Z1 H6 S2 Z4 H2 S4 Z1 H6 S4 Z1 H1 B1
40 47 40 42 40 44 56 60 102 110 107 42 46 51 40 43 41 46 49 48 40 42 45 40 42 134 136 40 47 43 40 44 50 166 168 178 80 84 87 80 83 86 146 152 157 181
46 48 41 44 42 55 59 83 106 115 109 45 50 52 42 44 45 47 54 48 41 44 51 41 45 135 141 42 49 46 43 49 54 167 170 181 83 86 97 82 85 91 151 156 167 183 Bijlage 9.3
10/424
240
80
105
0
10/427
240
80
105
0
10/428
159
145
171
12
10/429 10/432
155 240
132 80
150 89
0 0
10/436
240
80
89
0
10/441 10/444
240 240
80 80
81 99
0 0
10/448
240
80
99
0
10/449 10/454
240 159
80 116
81 182
0 23
10/459
204
175
192
0
10/460
80
74
77
0
10/461
80
60
69
0
10/462
240
80
95
0
11/002
280
152
164
0
LT LZ LO LA LR LT LZ LO LT LZ LO LA LT LZ LO LA LZ LR LZ LO LZ LO LO LR LT LO LA LT LZ LO LR LT LZ LO LT LZ LO LZ LO LZ LO LZ LO LA LT LZ
38 11 31 5 6 28 3 8 23 3 10 6 7 5 19 6 35 1 2 11 1 14 2 6 14 9 8 31 2 2 4 19 8 85 22 2 5 1 2 2 14 6 18 1 19 1
S4 Z2 H2 P2 B3 S4 Z4 H1 S1 Z2 H5 P3 S1 Z2 H2 P2 Z4 B2 Z4 H5 Z1 H3 H6 B1 S2 H4 P1 S3 Z1 H2 B4 S3 Z1 H3 S3 Z4 H3 Z3 H1 Z4 H2 Z2 H1 P5 S4 Z2
184 204 215 211 80 83 98 101 80 93 100 96 145 150 154 168 132 80 81 83 80 82 80 80 84 96 92 80 97 80 116 119 130 139 175 187 189 74 76 60 62 80 86 84 152 163
203 210 231 214 82 97 100 105 92 95 105 99 149 153 164 171 150 80 82 89 81 89 81 81 91 99 95 96 99 81 118 129 138 182 186 188 192 75 77 61 69 83 95 85 162 164 Bijlage 9.4
11/004
180
164
173
0
11/006
159
130
159
0
11/008
180
145
177
0
11/010
280
121
136
0
11/012 11/014
204 121
174 92
178 103
0 0
11/018
280
120
157
0
11/027
280
168
183
0
11/031
210
170
188
0
11/032 11/035 11/036
159 280 280
145 120 121
153 128 127
0 0 0
11/039
280
120
149
0
11/043
194
120
137
0
11/044 11/045 11/046 11/048
280 199 227 227
171 174 206 206
172 179 209 221
0 0 0 0
11/051 11/053
280 280
120 120
122 143
0 0
LT LZ LT LZ LR LT LZ LO LA LZ LA LZ LT LO LT LZ LO LA LT LO LA LT LZ LO LA LA LA LZ LO LR LT LA LT LZ LO LT LO LO LT LZ LO LA LA LT LZ LO
14 2 54 2 2 8 5 29 5 1 26 4 7 11 42 3 5 16 1 7 1 10 2 12 5 16 15 1 13 18 35 13 10 3 24 1 16 10 4 2 12 4 4 8 3 27
S1 Z4 S3 Z2 B3 S1 Z3 H6 P2 Z1 P2 Z3 S2 H3 S2 Z2 H1 P2 S2 H5 P1 S2 Z2 H1 P4 P5 P5 Z4 P4 B1 S1 P4 S1 Z4 H6 S3 H4 H4 S1 Z1 H1 P5 P3 S4 Z1 H2
164 172 130 158 145 150 155 167 163 121 123 174 92 97 120 142 145 149 168 179 170 170 176 182 178 145 120 121 123 120 126 145 120 126 129 171 174 206 206 209 215 212 120 120 125 129
171 173 157 159 146 154 160 177 166 122 136 178 96 103 141 144 148 157 169 183 170 175 177 188 180 153 128 122 127 124 144 149 125 128 137 172 179 209 208 211 221 214 122 124 128 143 Bijlage 9.5
11/054
280
121
128
0
11/055 11/057
280 140
120 97
124 117
0 0
11/058
280
120
175
0
11/062 11/066
280 248
120 227
122 238
0 0
11/068
280
120
154
0
11/070 11/071 11/072 11/074
144 280 280 168
142 120 120 155
167 122 121 178
23 0 0 10
11/076
320
163
182
0
11/078 11/080 11/084
320 126 320
160 116 160
167 117 183
0 0 0
11/089 11/091
320 248
160 215
166 246
0 0
11/092
168
125
171
3
11/093 11/094 11/095 11/102
135 320 246 320
173 176 206 160
174 184 211 175
39 0 0 0
LZ LO LA LO LT LZ LO LA LZ LO LA LA LT LZ LO LR LT LZ LO LA LT LO LA LT LZ LO LT LZ LO LA LO LR LT LA LO LT LZ LO LT LZ LO LT LO LO LZ LO
2 2 6 8 5 3 25 10 25 54 44 6 6 2 11 41 29 1 12 6 49 3 4 15 5 15 23 3 5 13 2 22 18 3 19 7 5 44 5 7 63 1 16 10 2 19
Z3 H1 P1 H3 S1 Z3 H6 P4 Z2 H4 P3 P1 S3 Z3 H4 B2 S4 Z3 H6 P1 S2 H5 P4 S1 Z3 H5 S4 Z1 H4 P5 H4 B4 S1 P1 H6 S4 Z4 H3 S4 Z3 H5 S3 H2 H5 Z1 H2
121 124 126 120 97 101 109 105 120 134 153 120 227 231 234 120 129 145 150 147 142 120 120 155 164 170 163 176 180 160 116 160 172 182 160 215 220 224 125 129 137 173 176 206 160 165
123 125 128 124 100 104 117 108 133 152 175 122 230 233 238 128 144 146 154 149 167 122 121 163 169 178 175 179 182 167 117 171 181 183 166 219 223 246 128 136 169 174 184 211 162 175 Bijlage 9.6
11/107 11/108 11/109 11/112
320 320 320 206
160 182 160 156
170 182 162 181
0 0 0 0
11/115
240
227
237
0
11/117
299
239
280
0
11/118
226
203
211
0
11/120
320
168
172
0
11/121
297
237
276
0
11/122
320
160
170
0
LA LO LA LZ LO LA LT LZ LA LZ LO LT LZ LO LT LZ LT LZ LO LA LO
30 1 3 7 24 21 9 1 4 9 62 3 2 7 2 3 55 5 13 2 30
P4 H6 P2 Z4 H1 P1 S2 Z2 P3 Z1 H5 S2 Z3 H6 S3 Z2 S1 Z4 H6 P4 H4
160 182 160 156 169 161 227 233 235 239 249 203 206 209 168 170 237 266 272 270 160
170 182 162 160 181 168 232 234 237 248 280 205 208 211 169 172 265 269 276 271 170
Bijlage 9.7
