EEN CASE STUDIE VOOR MULTIPROJECTPLANNING

Transcriptie

1 UNIVERSITEIT GENT FACULTEIT ECONOMIE EN BEDRIJFSKUNDE ACADEMIEJAAR 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

2

3 UNIVERSITEIT GENT FACULTEIT ECONOMIE EN BEDRIJFSKUNDE ACADEMIEJAAR 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

4 PERMISSION Ondergetekende verklaart dat de inhoud van deze masterproef mag geraadpleegd en/of gereproduceerd worden, mits bronvermelding. Len Vandenheede

5 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

6 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? Wat is een project? Projecten in een multiprojectomgeving: algemeen overzicht Gelijkenissen tussen een singleproject- en een multiprojectomgeving Samenvattende tabel van hoofdstuk Hoofdstuk 2: Complexiteit en onzekerheid Omgaan met complexiteit in een multiprojectomgeving Omgaan met onzekerheid in een multiprojectomgeving Proactieve aanpak Reactieve aanpak Hoofdstuk 3: Mathematische voorstelling van het probleem: exact algoritme Hoofdstuk 4: Het inplannen van resources met behulp van heuristieken Prioriteitsregels Inplannen van de projecten Het verkrijgen van een initiële oplossing Het verbeteren van de initiële oplossing II

7 4.3. Kwaliteitsparameters Samenvattende tabel van hoofdstuk Hoofdstuk 5: Werknemers in een multiprojectomgeving Deel II: Case studie Inleiding Hoofdstuk 6: Situering van het bedrijf Geschiedenis van het bedrijf Werkzaamheden binnen het bedrijf Schaarse resources Projectportfoliomanagement Hoe de planning momenteel verloopt Complexiteit in het projectschema Onzekerheid in het projectschema Samenvatting: overeenkomsten en verschilpunten met de literatuurstudie Hoofdstuk 7: Methodologie van het empirisch onderzoek Opzet van het onderzoek Onderzoeksvragen Gegevensverzameling en gegevensanalyse Softwareprogramma Werking van het softwareprogramma Wijze van schedulen in het programma Invloeden vanuit de literatuur Gebruikte prioriteitsregels Kwaliteitsparameters Hoofdstuk 8: Resultaten en interpretatie Resultaten en interpretatie van onderzoeksvraag 1: Welke prioriteitsregel geeft het beste resultaat weer? III

8 8.2. Resultaten en interpretatie van onderzoeksvraag 2: Wat doet onzekerheid met het projectschema? Resultaten en interpretatie van onderzoeksvraag 3: Wat is de invloed van een nauwer tijdsframe op de kwaliteit van het projectschema? Resultaten en interpretatie van onderzoeksvraag 4: Wat is de invloed van een gelijkmatige ploegverdeling op de kwaliteit van het projectschema? Resultaten en interpretatie onderzoeksvraag 5: Wat is de invloed van een multiskilled projectteam op de kwaliteit van het projectschema? Besluit van de empirische studie Algemene conclusie en verder onderzoek Lijst van geraadpleegde werken Bijlage 1: Bijlage 2: Bijlage 3: Bijlage 4: Bijlage 5: Bijlage 6: Bijlage 7: Bijlage 8: Bijlage 9: Lijst van kritische incidenten Lijst van kritische incidenten in ondernemingen die nieuwe producten ontwikkelen Overzicht van de gebruikte symbolen in het mathematisch model Contactgegevens en overzicht van gesprekken met DVG Overzicht van de teams, werkzaam in DVG Database van de ter beschikking gestelde projecten Rapporten in verband met de statistische significantie Exacte resultaten voor de verschillende prioriteitsregels Basisschema IV

9 Gebruikte afkortingen CB CC/BM CPM DVG FB Capaciteitbuffer Critical chain & buffer management Kritisch pad-methode De Vroe Groep Feeding buffer GA KPF MSA MRCPSP PB PERT Genetisch algoritme Kritische projectfactor Modified simulated annealing Multimode resource-constrained project scheduling problem Projectbuffer Programme Evaluation and Review Technique RCMPSP RCPSP RCPSP SA SDP SRA Resource constrained multi-project scheduling problem Resource constrained project scheduling problem Resource constrained project scheduling problem Simulated annealing algoritme Stochastisch dynamisch programmeren Schedule Risk Analysis TOC WBS Theory of Constraints Work breakdown structure V

10 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 Figuur 4 - Beïnvloeding van de complexiteit Figuur 5 - Voorstelling van TOC in een multiprojectomgeving Figuur 6 - Schematische voorstelling van een multiprojectomgeving Figuur 7 Voorbeeld van een mutatie Figuur 8 Schematische voorstelling van simulated annealing (Chen & Mohsen Shahandeshti, 2009) Figuur 9 - Voorstelling van crossover in een GA Figuur 10 - Schematische voorstelling van de hybride SA-GA (Chen & Mohsen Shahandeshti, 2009) Figuur 11 - WBS van een project in DVG 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 Figuur 14 Welkomstscherm Figuur 15 - Tabblad 'Nieuw dossier toevoegen' Figuur 16 - Tabblad 'Reschedule' Figuur 17 - Voorbeeld van het opvragen van de planning op dag Figuur 18 - Voorbeeld van herplannen op dag Figuur 19 - Voorbeeld van het inbrengen één regendag op dag Figuur 20 - Tabblad 'Aanpassingen doorvoeren' Figuur 21 - Schematische voorstelling van de planningswijze in het softwareprogramma Figuur 22 - Schematische voorstelling van een multiprojectomgeving VI

11 Lijst van gebruikte tabellen Tabel 1 - Samenvattende tabel omtrent integratie verkoop en planning Tabel 2 - Samenvattende tabel omtrent capaciteitsplanning in een multiprojectomgeving Tabel 3 - Overall-Project-Leader-Role framework (Kaulio, 2008) Tabel 4 - Samenvattende tabel van hoofdstuk Tabel 5 - Framework met betrekking tot complexiteit en onzekerheid (Vanhoucke, ) 16 Tabel 6 - Organisationeel design versus complexiteit (Geraldi, 2007) Tabel 7 - Samenvattende tabel omtrent complexiteit Tabel 8 - Samenvattende tabel omtrent de proactieve aanpak Tabel 9 - Samenvattende tabel omtrent de reactieve aanpak Tabel 10 - Framework voor het klasseren van resources in een onderneming (Krüger & Scholl, 2009) Tabel 11 - Samenvattende tabel omtrent het mathematische model Tabel 12 - Samenvattende tabel van hoofdstuk Tabel 13 - Samenvattende tabel in verband met de resources van DVG 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 Tabel 16 - Samenvatting van de proactieve en reactieve aanpak in DVG Tabel 17 - Overeenkomsten tussen DVG en de literatuur Tabel 18 - Verschilpunten tussen DVG en de literatuur Tabel 19 - Overzicht van onzekerheden, onderzoeksvraag Tabel 20 - Kenmerken van een spoedproject Tabel 21 - Tijdskaders gebruikt in onderzoeksvraag Tabel 22 - Aanpassing van ploeggroottes in onderzoeksvraag Tabel 23 - Voorbeeld van een project in DVG Tabel 24 - Overzicht van assumpties met betrekking tot vroegste begindatum en opleverdatum 63 Tabel 25 - Samenvattende tabel: invloeden uit de literatuur Tabel 26 - Overzicht van geteste prioriteitsregels in het softwareprogramma Tabel 27 - Overzicht van gebruikte kwaliteitsparameters in het softwareprogramma Tabel 28 - Correlatie tussen beide kwaliteitsparameters Tabel 29 - Overzicht van de kwaliteitsparameters voor prioriteitsregel 'Maximale kost eerst' Tabel 30 - Besluiten onderzoeksvraag Tabel 31 - Correlatie tussen de gebruikte kwaliteitsparameters in onderzoeksvraag Tabel 32 - Besluiten onderzoeksvraag VII

12 Tabel 33 - Besluiten onderzoeksvraag Tabel 34 - Besluiten onderzoeksvraag Tabel 35 - Gemiddelde aantal werknemers voor één mandag Tabel 36 - Besluiten onderzoeksvraag VIII

13 Lijst van gebruikte grafieken Grafiek 1 - Onderzoeksvraag Grafiek 2 Onderzoeksvraag 2: kwaliteitsparameter 'Totale tijd om het schema te vervolmaken' Grafiek 3 Onderzoeksvraag 2: kwaliteitsparameter 'Totale vertraging' Grafiek 4 Onderzoeksvraag 2: factoren die het basisschema aantasten, kwaliteitsparameter 'Totale tijd om het schema te vervolmaken' Grafiek 5 Onderzoeksvraag 2: factoren die het basisschema aantasten, kwaliteitsparameter 'Totale vertraging' Grafiek 6 Onderzoeksvraag Grafiek 7 Onderzoeksvraag 3: toevoegen van onzekerheid Grafiek 8 - Onderzoeksvraag 3: totale vertraging met en zonder onzekerheid Grafiek 10 - Onderzoeksvraag 4: invloed op het basisschema Grafiek 11 - Onderzoeksvraag 3: wegvallen van een ploeg Grafiek 12 - Onderzoeksvraag 3: neerslagperiode van 3 dagen Grafiek 13 - Onderzoeksvraag 5: P-ploegen Grafiek 14 - Onderzoeksvraag 5: P5, totale vertraging Grafiek 15 - Onderzoeksvraag 5: P5, totale tijd om het schema te vervolmaken Grafiek 16 - Onderzoeksvraag 5: H-ploegen, totale vertraging Grafiek 17 - Onderzoeksvraag 5: H-ploegen, totale tijd om het schema te vervolmaken IX

14 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

15 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

16 Deel I: Theoretisch kader 3

17 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

18 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 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

19 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) 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

20 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, ). 7

21 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

22 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

23 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

24 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.) 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

25 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

26 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

27 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 Tabel 3 - Overall-Project-Leader-Role framework (Kaulio, 2008) Leiderschap 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

28 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 Multiprojectomgeving Gelijkenissen met een singleprojectomgeving Unieke onderneming Aanspraak op schaarse resources Succes wordt afgemeten aan de hand van tijd, kost en kwaliteit Onzekerheid en complexiteit 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 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

29 Laag Complexiteit Hoog 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 (Vanhoucke, ): 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 Techniek: SRA Laag Onzekerheid Tabel 5 - Framework met betrekking tot complexiteit en onzekerheid (Vanhoucke, ) Hoog 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

30 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

31 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

32 Door een overload aan informatie Complexiteit Door het ontbreken van informatie 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 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 noodzakelijk. Men moet een holistisch overzicht bewaren over alle projecten en beslissingen moeten van de eerste maal goed zijn, zoniet leidt dit tot onzekerheid. Hoog Flexibiliteit Typische indicatoren van zo n onderneming zijn fouten die zich herhalen, onnodig rework en het opnieuw uitvinden van het wiel. Tabel 6 - Organisationeel design versus complexiteit (Geraldi, 2007) Laag 19

33 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 (Zika- Viktorsson 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

34 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 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

35 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

36 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 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

37 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

38 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 p i ε P bestaat uit een set van n i projectfases of activiteiten A, met A = {a i1,, a in }. Elk van deze activiteiten heeft een bepaalde duurtijd d ij en eindigt op f ij. Deze waarde zal binnen het model berekend worden. Wel kan men een deadline F i voor project p i vastleggen, alsook een datum waarop het project ten vroegste van start kan gaan, zijnde E i. a i1 en a in vormen respectievelijk een start- en eindactiviteit. Dit zijn geen echte activiteiten, waardoor d i1 en d in 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 s r. Om een activiteit a ij van een project p i tot uitvoering te brengen heeft is er nood aan een hoeveelheid h rij van resource r. Een voorstelling van het RCMPSP wordt gegeven in figuur 6. 25

39 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 x rijt wordt 1 indien een bepaalde resource r op tijdstip t gebruikt wordt in project p i voor activiteit a ij en 0 indien deze resource niet wordt gebruikt voor deze specifieke activiteit. Hiermee verband houdend is de variabele q rijt, die het aantal resources van type r die op tijdstip t aan een activiteit a ij van een project p i zijn toegewezen. De poel aan resources wordt bijgehouden door l rt en vertelt hoeveel resources van soort r nog beschikbaar zijn op tijdstip t. De voorwaarde hierbij is dat 0 l rt s r. De binaire variabele v ijt wordt 1 indien de activiteit a ij van project p i eindigt op tijdstip t. TI ij stelt het tijdsinterval voor waarin een activiteit a ij van project p i 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 E i en de deadline F i 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

40 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) f ij + d ij f i(j+1) (2) (3) f i1 E i (4) (5) (6) (7) (8) t = 0 27

41 (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

42 Rol van de resources in de onderneming Type setup tijden Management oogpunt welke type van setup men te maken heeft en wat de rol van de resources zijn. Dit framework heeft 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 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 Vrije resources Toegewijde 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

43 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

44 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

45 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 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

46 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 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

47 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 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

48 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

49 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 (zie supra). Vervolgens gaat men door 36

50 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

51 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

52 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

53 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

54 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 vertraging a (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 T i, de vroegheid E i en de afwijking van de flow time van een projectschema FD i. 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

55 4.4. Samenvattende tabel van hoofdstuk 4 Alle aangewende technieken worden nog eens opgesomd in tabel 12. Prioriteitsregels Verkrijgen van een initiële oplossing Verbeteren van de initiële oplossing Kwaliteitsparameters Earliest due date Least slack Maximale sanctie eerst Kortste activiteit van een project eerst Maximale projectduur eerst Maximaal aantal resources nodig Maximale kost eerst Serieel inplannen van activiteiten Parallel inplannen van activiteiten Simulated annealing Genetisch algoritmes SA-GA hybride 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

56 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

57 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

58 Deel II: Case studie 45

59 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

60 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 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 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

61 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

62 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

63 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 vervullen b. 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 Andere resources Vooral werknemers Single-skilled Vrije resources Opereren in een MRCPSP-omgeving 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

64 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 . 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

65 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

66 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 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

67 Door een overload aan informatie Complexiteit Door het ontbreken van informatie 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 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

68 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 (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

69 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 Reactieve aanpak - Buffers - Wijzigen van de teams - Niet meer projecten aannemen dan - Inschakelen van interims mogelijk - Softwarepakker Build - 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

70 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 Omgeving van het bedrijf MRCPSP Hoofdstuk 3 Het opereren in een dynamische omgeving Sectie 1.2 Het opereren in een open omgeving Sectie 1.3 Portfoliomanagement De keuze van projecten naargelang de strategie van de Sectie 1.2 onderneming De integratie van de verkoopfunctie en de Sectie 1.2 planningsfunctie Het bekijken van het totale winstplaatje Sectie 1.2 Resources Complexiteit en onzekerheid Gecentraliseerde aanpak van projectmanagers Sectie 1.3 Negerende aanpak ten opzichte van resource setups Hoofdstuk 3 Kwalificatie van werknemers als vrije resources Hoofdstuk 3 De aanwezigheid van complexiteit en onzekerheid Hoofdstuk 2 Invloeden op de complexiteit Sectie 2.1 Vormen van flexibiliteit, aanwezig in de onderneming Sectie 2.1 Positionering als mechanisch-gestructureerde Sectie 2.1 onderneming en de daarbij horende kenmerken Gebruik van buffers Sectie De integratie van de verkoopfunctie en de Sectie planningsfunctie Tabel 17 - Overeenkomsten tussen DVG en de literatuur 57

71 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 Verschilpunt Verschil met literatuur Portfoliomanagement Het in acht nemen van de afstand Wordt nergens vermeld. tussen de onderneming en het project. Resources Alle werknemers zijn single-skilled. De meeste werknemers zijn multiskilled (zie hoofdstuk 5). Het aantal werknemers is historisch gegroeid. De literatuur stelt een goede capaciteitsplanning voorop (zie Onzekerheid en complexiteit 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. 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. Tabel 18 - Verschilpunten tussen DVG en de literatuur 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. 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. 58

72 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 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 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 (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

73 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 0 Timmerwerk 7 Dakwerken: Hellend dak 12 Dakwerken: Plat dak 4 Zinkwerk 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

74 worden vernauwd tot het 15 dagen bedraagt, iets meer dus dan de gemiddelde duurtijd. De verschillende tijdskaders staan opgesomd in onderstaande tabel. Tijdskader Tijdskader 2 80 Tijdskader 3 60 Tijdskader 4 40 Tijdskader 5 20 Tijdskader 6 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. Minimale ploeggrootte Stap 1: ploegen ruwbouw 2 Stap 2: ploegen zinkwerk 1 Stap 3: ploegen dakwerk hellend dak 2 Stap 4: ploegen dakwerk plat dak 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

75 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 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 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

76 Dossiernummer: 10/207 Dossiernaam: Fortis/Novo IB Loonkost in mandagen c d : Ruwbouw (LR) 0 Timmerwerk (LT) 2.67 Dakwerk: Hellend dak (LO) 7.26 Dakwerk: Plat dak (LA) Dakwerk: Zink (LZ) 0.75 Vroegste begindatum: 15/09/2010 Opleverdatum: 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 Tijdskader (Vroegste begindatum opleverdatum) 10/131 tot 10/ /350 tot 10/ /400 tot 10/ /002 tot 11/ /074 tot 11/ 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

77 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 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

78 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

79 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

80 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

81 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

82 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