Een studie naar het toepassen van correctieve acties in het kader van projectcontrole

Transcriptie

1 UNIVERSITEIT GENT FACULTEIT ECONOMIE EN BEDRIJFSKUNDE ACADEMIEJAAR Een studie naar het toepassen van correctieve acties in het kader van projectcontrole Masterproef voorgedragen tot het bekomen van de graad van Master of Science in de Toegepaste Economische Wetenschappen: Handelsingenieur Frederick Dobbelaere Eline Van Lombeek onder leiding van Prof. Mario Vanhoucke Mathieu Wauters

2

3 UNIVERSITEIT GENT FACULTEIT ECONOMIE EN BEDRIJFSKUNDE ACADEMIEJAAR Een studie naar het toepassen van correctieve acties in het kader van projectcontrole Masterproef voorgedragen tot het bekomen van de graad van Master of Science in de Toegepaste Economische Wetenschappen: Handelsingenieur Frederick Dobbelaere Eline Van Lombeek onder leiding van Prof. Mario Vanhoucke Mathieu Wauters

4 Ondergetekenden verklaren dat de inhoud van deze masterproef mag geraadpleegd en/of gereproduceerd worden, mits bronvermelding. Frederick Dobbelaere & Eline Van Lombeek, mei 2014 i

5 Inhoudsopgave Lijst van figuren Lijst van tabellen iv v 1 Inleiding 2 2 Probleemsituering 4 3 Onderzoeksaanpak Topologie: Basisdataset Trackingproces Top-down trackingproces Bottom-up trackingproces Correctieve acties Verschillende scenario s Methodologie P2 Engine Verloop van de simulatie: C++ programma Uitvoering simuleren Berekening earliest start Berekening kritisch pad Berekening van SPI(t) Correctieve Acties Bepalen maximum hoeveelheid correctie Bepalen optimale activiteit Resultaatsanalyse Output measures Algemene bevindingen EVM-bevindingen SRA-bevindingen ii

6 5.3 Vergelijking EVM met SRA Total contribution Ratio Totale kost en Total contribution Tracking efficiency Vergelijking fasttracken met crashen: basisscenario s Kost van correctieve actie per eenheid correctie Total contribution Ratio totale kost en total contribution (TK/TC) Tracking efficiency Andere topologische factoren Topologische factor AD Topologische factor LA Topologische factor TF Uitdiepend scenario 1: Effect niet-lineaire kosten op crashen Uitdiepend scenario 2: Rework Uitdiepend scenario 2 bij EVM Uitdiepend scenario 2 bij SRA Algemeen Besluit Belangrijkste conclusies Beperkingen van het onderzoek Verder onderzoek Bibliografie vii A Appendix x A.1 Total contribution SPI(t) 0,95 en 0, x A.2 Total contribution SSI 0,37 en 0, xi A.3 Total contribution xii A.4 Ratio totale kost en total contribution xiii A.5 Totale kost per eenheid correctie xiv A.6 Tracking efficiencies: drempelwaarden xv A.7 Tracking efficiencies: aantal ingrepen xvi iii

7 Lijst van figuren 4.1 Flowchart programma Voorbeeld earliest start bij crashen stap Voorbeeld earliest start bij crashen stap Voorbeeld earliest start bij fasttracken stap Voorbeeld earliest start bij fasttracken stap Voorbeeld earliest start bij fasttracken stap Voorbeeld kritisch pad Voorbeeld kritisch pad bij crashen Voorbeeld kritisch pad bij fasttracken Voorbeeld netwerk voor correctieve actie crashen Voorbeeld netwerk na correctieve actie crashen Voorbeeld netwerk voor correctieve actie fasttracken Voorbeeld netwerk na correctieve actie fasttracken Voorbeeld effect duurtijd activiteit op zijn maximum hoeveelheid fasttracking Voorbeeld effect duurtijd voorgangers op maximum hoeveelheid fasttracking Voorbeeld effect van slack op maximum hoeveelheid fasttracking Voorbeeld effect van rework op maximum hoeveelheid fasttracking Voorbeeld effect van rework op maximum hoeveelheid fasttracking Voorbeeld parallel kritisch pad Voorbeeld kritisch pad na correctieve actie Voorbeeld dubbel parallel kritisch pad, verder gesplitst Voorbeeld drievoudig parallel kritisch pad Vergelijking total contribution bij EVM met 50% overlap en 50% rework Vergelijking total contribution bij SRA met 35% overlap en 25% rework Vergelijking total contribution met 50% overlap en 50% rework Vergelijking ratio totale kost en total contribution met 35% overlap en 25% rework Vergelijking ratio totale kost en total contribution met 35% overlap en 25% rework Vergelijking kost per eenheid correctie bij EVM Vergelijking total contribution bij EVM Vergelijking total contribution bij SRA met SSI-drempelwaarde 0, iv

8 5.9 Vergelijking ratio totale kost en total contribution bij EVM Vergelijking ratio totale kost en total contribution bij SRA met SSI-drempelwaarde 0, Vergelijking total contribution voor topologische factor AD bij SRA met SSIdrempelwaarde 0, Vergelijking total contribution voor topologische factor AD bij EVM Vergelijking total contribution voor topologische factor LA bij SRA met SSIdrempelwaarde 0, Vergelijking total contribution voor topologische factor LA bij EVM Vergelijking total contribution voor topologische factor TF bij SRA met SSIdrempelwaarde 0, Vergelijking total contribution voor topologische factor TF bij SRA met SSIdrempelwaarde 0, Vergelijking total contribution voor topologische factor TF bij EVM Lijst van tabellen 3.1 Overzicht basisscenario s fasttracken Overzicht basisscenario s crashen Overzicht uitdiepende scenario s fasttracken Overzicht uitdiepende scenario s crashen Mogelijke opties projectmanager Baseline schedule Planned values Rework in functie van aantal eenheden fasttracking Voorbeeld selectie activiteiten bij SRA Kosten voor netwerk met parallel pad Berekening samengestelde kost Berekening samengestelde kost Selectie optimale activiteit Werkelijke kosten per eenheid Berekening samengestelde kost Berekening samengestelde kost v

9 4.13 Selectie optimale activiteiten Werkelijke kosten per eenheid Berekening samengestelde kost Berekening samengestelde kost Samengestelde kost per eenheid Overzicht SP-waarden Overzicht vergelijkende scenario s fasttracken Overzicht vergelijkende scenario s crashen Overzicht total contribution fasstracking 50% overlap - 50% rework Overzicht ratio totale kost en total contribution fasttracking 50% overlap - 50% rework Overzicht tracking efficiencies fasttracking 50% overlap - 50% rework Overzicht vergelijkende scenario s Overzicht kost per eenheid correctie bij EVM Overzicht total contribution bij EVM Overzicht total contribution bij SRA Overzicht ratio totale kost en total contribution bij EVM Overzicht tracking efficiencies Overzicht total contribution bij niet-lineaire kosten en EVM Overzicht ratio totale kost en total contribution bij niet-lineaire kosten en EVM Overzicht total contribution bij niet-lineaire kosten en SRA met SSI 0, Overzicht ratio totale kost en total contribution bij niet-lineaire kosten en SRA met SSI 0, Overzicht total contribution bij EVM bij uitdiepend scenario Overzicht ratio totale kost en total contribution bij EVM bij uitdiepend scenario Overzicht total contribution bij SRA met SSI-drempelwaarde 0,37 bij uitdiepend scenario Overzicht ratio totale kost en total contribution bij SRA met SSI-drempelwaarde 0,37 bij uitdiepend scenario vi

10 Woord vooraf Deze scriptie is het sluitstuk van onze vijfjarige opleiding handelsingenieur. In dit verkennend onderzoek bouwen we mee aan de academische basis omtrent correctieve acties in het kader van projectcontrole. Deze scriptie simuleert de voortgang van projecten en de bijhorende correctieve acties die een projectmanager in de praktijk zou nemen. Dit stelt ons in staat om conclusies te trekken omtrent deze correctieve acties alsook omtrent hun verband met verschillende topologische factoren en andere invloeden op het project. Maar voor we deze resultaten uitgebreid bespreken, willen we eerst een moment nemen om iedereen te bedanken die deze scriptie mogelijk hebben gemaakt. Eerst en vooral willen we Prof. dr. Mario Vanhoucke en Mathieu Wauters bedanken om ons de kans en de mogelijkheid te geven om rond dit uitermate interessant onderwerp te werken. Hun advies omtrent de theoretische en de praktische aspecten was zeer waardevol en stuurde onze scriptie de juiste richting uit. Dit stelde ons in staat om ten volle te genieten van deze zeer uitdagende en leerrijke ervaring. We willen ook graag de leden van het congres EVM Europe 2013 bedanken voor de feedback tijdens de presentatie van ons voorlopig onderzoek. Deze feedback heeft ons zonder twijfel gestimuleerd om enkele belangrijke elementen mee in beschouwing te nemen. Verder willen wij onze ouders, familie en vrienden bedanken voor de steun tijdens het uitwerken en schrijven van dit werk en in het bijzonder Jana, wiens computer wij enkele weken mochten gebruiken voor het uitvoeren van de simulaties. Wij willen ook Marijn bedanken om ons te helpen met Latex. Alsook Daisy, Paul en Jonas om ons werk na te lezen en te controleren op schrijffouten. Tenslotte willen we onze dankbaarheid betuigen aan elkaar voor de vele uren dat wij in een aangename samenwerking hebben gewerkt aan deze scriptie en we willen elkaar in het bijzonder danken voor de niet aflatende motivatie, steun en vriendschap. Frederick Dobbelaere & Eline Van Lombeek, mei

11 Hoofdstuk 1 Inleiding In deze scriptie hebben wij als doel het bestuderen van de toepassing van correctieve acties in het kader van projectcontrole. Gaandeweg hebben wij onze onderzoeksvraag steeds verder moeten verfijnen, voornamelijk door de omvang van dit onderwerp en de vele elementen die een impact kunnen hebben op de doeltreffendheid van correctieve acties. De zoektocht naar concrete richtlijnen die aangeven in welke gevallen welk type correctieve actie het meest wordt aangeraden is daardoor met deze scriptie nog niet ten einde. Wij hebben er met deze studie naar gestreefd om een eerste verkennend onderzoek uit te voeren, waarbij wij een antwoord trachten te geven op een aantal prangende vragen: Is de doeltreffendheid van het trackingproces, naast het al dan niet serieel zijn van het projectnetwerk, ook afhankelijk van het type correctieve actie dat zal worden toegepast? In welke van de door ons gesimuleerde trackingprocessen genereert fasttracken betere resultaten dan crashen en omgekeerd? Wat is de impact van de andere topologische factoren AD, LA, TF op de doeltreffendheid van een top-down trackingproces dan wel een bottom-up trackingproces? Wij zullen eerst en vooral in hoofdstuk 2 het probleem situeren en daarbij expliciet beschrijven wat het belang is van een goede projectcontrole en waarop de beslissing omtrent het nemen van correctieve acties tegenwoordig wordt gebaseerd. Vervolgens zullen wij in hoofdstuk 3 concreet beschrijven welke elementen wij in rekening hebben gebracht bij het opbouwen van dit onderzoek en hoe onze simulatiestudie als dusdanig stap voor stap vorm heeft gekregen. Er zal in eerste instantie een bespreking worden gegeven van de verschillende topologische factoren die in dit onderzoek worden beschouwd. Ook zullen wij in detail uit de doeken doen hoe wij zowel het top-down trackingproces op basis van de EVM-methode als het bottom-up trackingproces op basis van de SRA-methode hebben opgesteld. Vervolgens wordt er nog een deel gewijd aan de bespreking van zowel de correctieve actie crashen als fasttracken om tenslotte dit hoofdstuk te beëindigen met een samenvatting van de scenario s die tijdens het onderzoek zullen worden 2

12 geanalyseerd. Vervolgens zal in hoofdstuk 4 worden toegelicht hoe de simulatiestudie concreet werd geïmplementeerd via het C++ programma, waarbij de belangrijkste algoritmes kort worden besproken. In hoofdstuk 5 zullen we eerst de verschillende maatstaven omschrijven die bij de analyse van de resultaten zullen worden gebruikt. Daarna zullen we in functie van deze maatstaven de belangrijkste resultaten en bevindingen toelichten. Tenslotte zullen in hoofdstuk 6 de algemene conclusies worden vermeld, waarna nog de beperkingen van onze studie worden opgesomd alsook de richtlijnen voor toekomstig onderzoek. 3

13 Hoofdstuk 2 Probleemsituering Het beheren van een project is een dynamisch proces en omvat zowel projectplanning, risicoanalyse als projectcontrole (Vanhoucke, 2012b). Projectcontrole is minstens even belangrijk als de twee andere dimensies van projectmanagement, voornamelijk door het feit dat het project en zijn omgeving voortdurend onderhevig zijn aan verandering (Perminova, Gustafsson & Wikström, 2008). De baseline schedule, verkregen tijdens de projectplanning, houdt niet expliciet rekening met de onzekerheid die gepaard gaat met de werkelijke uitvoering van het project. De baseline schedule wordt opgesteld in de planningsfase, wanneer het project nog niet in uitvoering is. Het is dus louter en alleen een referentiepunt en de informatie vervat in deze baseline schedule is noodzakelijk, maar niet voldoende om een projectcontrole uit te voeren (Vanhoucke, 2012b). Tijdens de projectcontrole wordt de informatie vervat in de baseline schedule zowel als de informatie die voortvloeit uit de risicoanalyse samen met de informatie gerelateerd aan de werkelijke uitvoering van het project gebruikt en geanalyseerd opdat er tijdig kan worden gereageerd indien het project problemen zou ondervinden (Vanhoucke, 2012b). Een goed systeem voor projectcontrole zal onder meer de vooruitgang van het project meten in relatie met datgene wat vooropgesteld is in de projectplanning, alsook deze beiden op een effectieve wijze communiceren aan alle stakeholders gelinkt aan het project (Wideman, 1989). In dit onderzoek zullen wij ons focussen op dit proces betreffende het controleren en opvolgen van een project in uitvoering. Wij zullen de vooruitgang van verschillende projecten simuleren, elk project op twee verschillende manieren opvolgen en tenslotte de beslissing met betrekking tot de te ondernemen acties, om het project terug op schema te brengen, analyseren en optimaliseren. Perminova et al. (2008) definiëren onzekerheid als een gebeurtenis of situatie, dewelke niet verwacht werd te gebeuren, ongeacht of het al dan niet mogelijk was het op voorhand in beschouwing te nemen (p. 77). In de praktijk bestaan er verschillende vormen van onzekerheid en elk daarvan kan een fundamentele impact hebben op het project. Deze impact kan ofwel positief zijn door het ontstaan van nieuwe opportuniteiten voor het project, ofwel negatief zijn door het in gevaar brengen van de doelstellingen van het project (Perminova et al., 2008). In 4

14 dit onderzoek zullen wij ons focussen op de onzekerheid die een negatief gevolg kan hebben voor de vooropgestelde duurtijd, waardoor tijdens de projectcontrole correctieve acties noodzakelijk zullen zijn. In dit opzicht is er al de onzekerheid omtrent de gemaakte schattingen, bijvoorbeeld met betrekking tot de duurtijd en de kost van de activiteiten. Deze vorm van onzekerheid is vaak te wijten aan een gebrek aan ervaring en het zich voordoen van bepaalde gebeurtenissen, die onmogelijk bij het begin van het project konden worden voorzien (Atkinson, Crawford & Ward, 2006). Vervolgens bestaat er ook de onzekerheid geassocieerd met de verschillende partijen die deel uitmaken van een project. Er kan in dit geval onzekerheid bestaan over de betrouwbaarheid en de belangen van elke partij alsook over de capaciteiten en de kwaliteit van het werk dat door een specifieke partij wordt uitgevoerd (Atkinson et al., 2006). Gedurende ons onderzoek zullen wij de inaccurate schattingen van de duurtijden van de activiteiten als voornaamste bron van onzekerheid beschouwen. Rekening houdend met deze bron van onzekerheid kan het bijgevolg gebeuren dat er tijdens de uitvoering van het project zodanig wordt afgeweken van de baseline schedule dat er moet worden ingegrepen via correctieve acties om het project terug op schema te brengen en/of om de negatieve impact op de doelstellingen van het project zoveel mogelijk te beperken. In de literatuur worden in het kader van projectcontrole verschillende soorten correctieve acties besproken; namelijk crashen, fasttracken en re-baselining (Vanhoucke, 2012b). In deze scriptie zullen wij ons focussen op crashen en fasttracken, aangezien re-baselining eerder een fundamentele correctie betreft waarbij bepaalde delen van de baseline schedule zullen worden aangepast als gevolg van een verandering in de project scope (Vanhoucke, 2012b). In ons onderzoek zullen wij enkel trachten het project zo nauwgezet mogelijk de planning te laten volgen zonder deze planning zelf aan te passen. Crashen houdt in dat de duurtijd van een activiteit gereduceerd wordt door extra resources toe te wijzen aan de activiteit in kwestie, met een verhoogde kost als gevolg (Vanhoucke, 2012b). In het geval van fasttracken worden activiteiten die volgens de prioriteitsregels serieel zijn voor een deel in parallel uitgevoerd (Vanhoucke, 2012b). Dit kan op zijn beurt leiden tot een bepaalde hoeveelheid rework, waardoor de nettoreductie van de duurtijd van het project lager zal uitvallen (Vanhoucke, 2012b). Projectmanagers zijn op de hoogte van het bestaan van deze acties, maar de beslissing betreffende welke acties in welke situaties het voordeligst zijn, wordt nog niet voldoende ondersteund door eenduidigheid. Deze scriptie heeft dan ook als specifiek doel het onderzoeken van de toepasbaarheid van deze reeds bestaande correctieve acties. Wanneer is fasttracken of crashen het meest aan te raden, rekening houdend met de specifieke kenmerken en de topologie van het project? De dag van vandaag zijn de projectmanagers voornamelijk aangewezen op best practices. Zo wordt er bijvoorbeeld gesteld om in eerste instantie de duurtijd van het project te reduceren aan de hand van fasttracken, aangezien deze optie niet onmiddellijk gepaard gaat met een verhoogde kost, 5

15 maar uiteraard wel substantieel het risico tot rework verhoogt (Fremouw, 2011). Wanneer men in tegenstelling activiteiten wil crashen, worden er extra resources toegekend aan de te crashen activiteit, wat onmiddellijk een verhoogde kost tot gevolg heeft (Fremouw, 2011). Deze regel is echter zeker niet van het one-size-fits-all kaliber. Alvorens een keuze te maken, is het aan te raden om ook de karakteristieken van het specifieke project in beschouwing te nemen. Zo kan men verwachten dat projecten die relatief nieuw zijn, alsook projecten waar er voor een groot deel interactie is tussen verschillende ontwerpdisciplines, in mindere mate in aanmerking komen om te fasttracken (Kohler, n.d.). Als proef op de som hebben wij Kris Jennes, een projectmanager in hart en nieren, gevraagd om ons de toepassing van correctieve acties in de praktijk nader toe te lichten. Op deze manier konden we vergelijken hoe zijn aanpak overeenkomt met wat wij terugvonden in de literatuur en wat als dusdanig beschreven werd in voorgaande paragraaf. Vanuit zijn ervaring kon hij ons verzekeren dat wanneer een project terug op schema moet worden gebracht, zowel het fasttracken als crashen van activiteiten gelijktijdig als oplossingen naar voor worden geschoven. Het is echter wel belangrijk de specifieke karakteristieken van beide types correctieve acties in beschouwing te nemen. Aangezien een projectteam meestal beperkt is en het meestal dezelfde resources zijn die aan de verschillende activiteiten worden toegewezen, is het vaak niet mogelijk om bepaalde activiteiten in parallel uit te voeren en ze met andere woorden te fasttracken. Indien het gebrek aan resources echter geen probleem vormt, dan is volgens hem het fasttracken van activiteiten zeker een goede optie om het project terug op schema te brengen. Het crashen van activiteiten door additionele resources toe te kennen aan deze activiteiten is volgens Kris Jennes een slechte optie. Hij argumenteert dat resources zelden vanaf de eerste dag productief kunnen zijn. De extra resources die men wil toewijzen aan het project moeten getraind en gecoacht worden alvorens ze de hen toegewezen taken op een correcte manier kunnen uitvoeren. Bijkomend zullen de resources, die initieel aan het project werden toegewezen, een deel van hun tijd opofferen om de nieuwe resources in te werken. Als gevolg zal men op korte termijn de performantie van de originele resources zien dalen. Volgens Kris Jennes is het crashen van activiteiten bijgevolg een optie die slechts op lange termijn resultaat zal opleveren. Hij besloot zijn argumentatie met een gezegde van Warren Buffet: Het is niet omdat je negen zwangere vrouwen hebt, dat er binnen één maand tijd een baby ter wereld zal gebracht worden. Daarmee stelt hij duidelijk dat sommige activiteiten nu eenmaal tijd vragen en/of dat ze niet door meerdere personen kunnen worden uitgevoerd. In dit opzicht benadrukte hij het belang van scope management. Daarbij moet men trachten om zo snel mogelijk de onderdelen van de scope te bepalen die van prioritair belang zijn, alsook de onderdelen die op een later tijdstip kunnen worden opgeleverd. In het geval dat het project achter raakt op schema is het dan belangrijk om te focussen op deze prioritaire zaken, zonder de kwaliteit van het project in het gedrang te brengen. 6

16 Wanneer de vooruitgang van het project aldus afwijkt van wat vooropgesteld werd in de baseline schedule en de projectmanager een beslissing moet nemen met betrekking tot de meest aangewezen correctieve acties, dan bestaan er steeds een aantal vuistregels die iedere projectmanager in zijn achterhoofd houdt. Met het onderzoek verricht in deze scriptie hebben wij als voornaamste doel deze best practices aan te vullen. Uiteindelijk streven wij ernaar om enkele concrete richtlijnen te ontwikkelen, die de topologie van een project expliciet in rekening zullen brengen. Deze richtlijnen kunnen dan door de projectmanager worden gehanteerd bij het nemen van een beslissing met betrekking tot het toepassen van correctieve acties gedurende het trackingproces. 7

17 Hoofdstuk 3 Onderzoeksaanpak In dit onderzoek trachten we na te gaan of er een relatie bestaat tussen de topologische karakteristieken van een project en de toepasbaarheid van de correctieve acties: crashen en fasttracken. Voor een hele reeks projecten, die topologisch gezien onderling van elkaar verschillen, zullen wij het trackingproces als onderdeel van de projectcontrole simuleren. Elk project zullen we op twee verschillende manieren opvolgen. Enerzijds zullen wij een puur top-down trackingproces simuleren, waarbij aan de hand van de Earned Value Management-maatstaven informatie wordt verschaft over de toestand van het project (Vanhoucke, 2009). Anderzijds zullen wij een puur bottom-up trackingproces simuleren, waarbij door het uitvoeren van een Schedule Risk Analysis per activiteit informatie wordt bekomen over de sensitiviteit (Vanhoucke, 2009). Op basis van deze informatie kan er vervolgens een subset van activiteiten worden gedefinieerd, dewelke nauwgezet zullen worden opgevolgd tijdens de projectcontrole. Wanneer tijdens eender trackingproces de vooraf gespecificeerde drempelwaarden worden overschreden en er een signaal wordt gegeven tot het uitvoeren van correctieve acties, dan zullen we voor elk type trackingproces het project eens fasttracken en eens crashen. Uiteindelijk zullen we dan kunnen nagaan wat het effect is van de fasttrack-optie en de crash-optie op elk type project en gedurende elk type trackingproces door de op voorhand gedefinieerde output measures te berekenen en te vergelijken. Op deze manier zullen wij de doeltreffendheid en toepasbaarheid van beide correctieve acties kunnen bespreken en vergelijken in functie van de topologische karakteristieken van een projectnetwerk. 3.1 Topologie: Basisdataset Elk project dat beheerd dient te worden, kan men onder andere visualiseren aan de hand van een activity-on-the-node netwerk. Een projectnetwerk is één van de basisconcepten in de projectmanagement discipline. Elk projectnetwerk bestaat typisch uit een set van activiteiten, die in het geval van een activity-on-the-node diagram telkens worden voorgesteld door de knooppunten en die op basis van de projectspecifieke voorrangsregels met elkaar verbonden worden door pijlen (Vanhoucke, 2009). Bijkomend worden er ook voor elke activiteit bepaalde karakteristieken 8

18 weergegeven zoals de duurtijd en de kost (Tavares, Ferreira & Coelho, 1999). Deze definitie van een projectnetwerk is heel breed geformuleerd, waardoor er naast de set van activiteiten, de voorrangsregels en de karakteristieken nog een grote variëteit aan verschillende netwerkvormen kunnen voorkomen. Tavares et al. (1999) onderzochten verscheidene netwerkvormen en concludeerden dat de specifieke vorm van het netwerk in grote mate de problemen en risico s bepaalt bij het beheren van het project. Zij ondervonden namelijk dat de topologische structuur van een projectnetwerk een grote invloed heeft op het al dan niet voorkomen van vertragingen (Vanhoucke, 2012b). In een andere latere studie van Tavares, Ferreira & Coelho (2004) gaan zij hier dieper op in en kwamen zij tot de conclusie dat de topologische structuur van een projectnetwerk een belangrijke invloed heeft op het kritieke karakter van het netwerk zelf. Ook de doeltreffendheid van de technieken om aan projectcontrole te doen, wordt sterk bepaald door de topologische karakteristieken van het desbetreffende netwerk zoals geconcludeerd in de studie van Vanhoucke (2012b). De topologie van het projectnetwerk is bijgevolg een belangrijke factor in projectmanagement en is reeds enkele jaren onderwerp van verscheidene onderzoeken en studies. In deze scriptie willen wij deze topologische factoren ook expliciet beschouwen en op deze manier nader onderzoeken of de topologische structuur van een netwerk ook een invloed kan hebben op de doeltreffendheid van de correctieve acties: crashen en fasttracken. Veel onderzoek werd verricht naar bepaalde indicatoren om de vorm en structuur van verschillende projectnetwerken te meten en op deze manier te kwantificeren (Vanhoucke & Vandevoorde, 2009). Verschillende indicatoren werden doorheen de jaren gedefinieerd in de literatuur, waarvan er sommige aangepast en aangevuld werden na bijkomend onderzoek (Vanhoucke, Coelho, Debels, Maenhout & Tavares, 2008). Op basis van deze indicatoren werden vervolgens programma s ontwikkeld voor het genereren van netwerken met bepaalde topologische karakteristieken. Deze netwerken kunnen dan voor verscheidene onderzoeksdoeleinden worden gebruikt. Rangen en Rangen2 zijn enkele van de jongste programma s om netwerken te genereren. Ze worden verondersteld de andere, alternatieve programma s voor het genereren van projectnetwerken te overtreffen op verschillende vlakken (Demeulemeester, Vanhoucke & Herroelen, 2003). Zo argumenteert men dat Rangen2 voor de generatie van de netwerken vertrekt van een grotere verzameling aan parameters, die door de gebruiker kan worden gespecifieerd. Deze verzameling van vier parameters werd zodanig gecreëerd dat het die exacte parameters bevat, voor dewelke in voorgaand onderzoek bewezen werd dat zij een betrouwbare set zijn en duidelijk gerelateerd kunnen worden aan de complexiteit van verschillende projectproblemen (Demeulemeester et al., 2003). Zoals gezegd maakt de Rangen-software gebruik van vier verschillende indicatoren bij het genereren van een testset bestaande uit één of meerdere netwerken. Door het feit dat de gebruiker de mogelijkheid heeft om vier parameters te specificeren, zal er een grotere verscheidenheid aan 9

19 projectnetwerken kunnen worden gegenereerd. Indien men bijvoorbeeld slechts één parameter zou kunnen bepalen, dan zouden de gegenereerde projectnetwerken in mindere mate substantieel van elkaar verschillen. De vier indicatoren door Rangen gedefinieerd zijn achtereenvolgens de Serie/Parallel indicator (SP), de Activity Distribution indicator (AD), de Length of Arcs indicator (LA) en de Total Float indicator (TF) (Vanhoucke, 2009). Elk van deze indicatoren kan een waarde hebben, die varieert tussen 0 en 1. De Serie/Parallel indicator is een maatstaf voor de mate waarin een projectnetwerk eerder serieel dan wel parallel is. Wanneer een projectnetwerk een SP-waarde heeft van 0, dan bevinden alle activiteiten zich in parallel. In het andere extreme geval, wanneer een projectnetwerk een SP-waarde heeft van 1, dan is het netwerk volkomen serieel (Vanhoucke, 2009). Bijgevolg geeft de SP-maatstaf een indicatie met betrekking tot het aantal kritieke activiteiten (Vanhoucke & Vandevoorde, 2009). Het aantal kritieke activiteiten van een eerder serieel projectnetwerk, bestaande uit een dertigtal activiteiten, zal beduidend hoger zijn dan het aantal kritieke activiteiten aanwezig in een eerder parallel projectnetwerk van dezelfde grootte. De Activity Distribution indicator geeft weer op welke wijze de activiteiten verdeeld zijn binnen het projectnetwerk. De activiteiten kunnen, in de extreme gevallen, volledig uniform verdeeld zijn (AD=0) of op een zodanige wijze gerangschikt zijn dat er zich in het begin van het project een maximaal aantal aan activiteiten bevindt terwijl naar het einde toe nog slechts één activiteit wordt waargenomen (AD=1) (Vanhoucke, 2009). Op deze manier is de AD-indicator een maatstaf voor de verdeling van de werklast over het project in zijn geheel (Vanhoucke & Vandevoorde, 2009). De Length of Arcs indicator meet op zijn beurt de lengte van de voorrangsrelaties tussen de verschillende activiteiten (Vanhoucke, 2009). Hoe kleiner de afstand is tussen de opeenvolgende activiteiten, hoe meer voorrangsrelaties een lengte hebben van één (LA= 1). Aan de andere kant, des te verder de activiteiten van elkaar verwijderd zijn, des te groter de lengte wordt van de verschillende voorrangsrelaties gedefinieerd doorheen het netwerk (LA=0) (Vanhoucke, 2009). Tenslotte geeft de Total Float indicator weer in welke mate de activiteiten verschoven kunnen worden in het projectnetwerk zonder dat de totale duurtijd van het project zal worden aangetast (Vanhoucke, 2009). Activiteiten zullen enkel op deze manier kunnen worden verschoven indien ze over voldoende slack beschikken. In het extreme geval dat geen enkele activiteit kan worden verschoven, heeft de TF-indicator een waarde van 0. Wanneer echter de activiteiten maximaal kunnen worden verschoven, met uitzondering van één keten aan activiteiten, dan is de waarde van de TF-indicator gelijk aan 1 (Vanhoucke, 2009). Zowel de Serie/Parallel indicator als de Length of Arcs indicator werden integraal ontleend aan Tavares et al. (1999). De Activity Distribution indicator werd aangepast door Vanhoucke et al. (2008) zodat die in zekere mate afwijkt van wat gedefinieerd was in het werk van Tavares et al. (1999). De Total Float indicator werd in het leven geroepen door Vanhoucke et al. (2008) en is aldus een relatief nieuwe indicator om de topologie van een projectnetwerk te karakteriseren. Voor ons onderzoek zullen wij gebruik maken van een verzameling projectnetwerken die gege- 10

20 nereerd werden aan de hand van de Rangen2-software en reeds in vorige studies omtrent de planning en controle van projecten werden gebruikt. Deze testset bestaat in totaal uit netwerken, dewelke onderverdeeld worden in vier subsets. Elke subset bestaat uit een verzameling van minstens 800 netwerken, die op een karakteristieke manier werden gegenereerd door het al dan niet specificeren van de vier topologische factoren (Vanhoucke, 2009). Wij zullen gebruik maken van de eerste set netwerken als input voor het uitvoeren van onze simulaties. In deze set van netwerken wordt er voornamelijk gefocust op de Serie/Parallel indicator. De waarden voor deze indicator worden gespecificeerd gaande van 0,1 tot 0,9 in stappen van 0,1. Voor elk van deze waarden worden er 100 netwerken gegenereerd waarbij de waarden voor de andere drie topologische indicatoren ad random gekozen worden uit het interval zowel tussen als inclusief 0 en 1. Op deze manier zullen wij in staat zijn een grote diversiteit aan topologische structuren op te nemen in ons onderzoek, zodat onze conclusies uiteindelijk van toepassing zullen zijn op een groot aantal verschillende projecttypes in plaats van een geïsoleerd onderdeel. We zijn er immers van overtuigd dat de lezer er meer baat bij zal hebben indien de conclusies zo algemeen mogelijk kunnen worden geformuleerd. Indien in toekomstig onderzoek ook de impact van de andere topologische indicatoren op een gecontroleerde wijze wenst bekeken te worden, dan raden wij aan de netwerken uit de andere subsets te gebruiken, aangezien in subset 2, subset 3 en subset 4 naast de SP-indicator ook respectievelijk, de AD-indicator, LA-indicator en TF-indicator worden gespecificeerd. 3.2 Trackingproces In projectmanagement is het opvolgen en monitoren van een project, waarvan de effectieve uitvoering reeds gestart is, even cruciaal als het op voorhand opstellen van de baseline schedule en het nadien uitvoeren van een risicoanalyse voor alle activiteiten die deel uitmaken van het project. De manier waarop het trackingproces wordt georganiseerd en geïmplementeerd zal aldus een belangrijke invloed hebben op het al dan niet halen van de projectdoelstellingen (Vanhoucke, 2011). Zoals reeds eerder vermeld is het belang van het monitoren en controleren van een project in uitvoering te wijten aan het dynamisch karakter van zowel het project als zijn omgeving (de Falco & Macchiaroli, 1998). De dynamiek waargenomen voor het project zelf vloeit voornamelijk voort uit een onderschatting van de duurtijden van de activiteiten, waardoor deze in werkelijkheid vaak langer uitvallen dan wat initieel gepostuleerd werd tijdens de planning (de Falco & Macchiaroli, 1998). Met betrekking tot de veranderingen in de omgeving zijn projectmanagers in de praktijk algemeen vertrouwd met de beruchte Wet van Murphy, waarin wordt gesteld dat alles wat fout kan gaan uiteindelijk ook fout zal gaan. Het te laat leveren van resources fundamenteel aan het project wordt beschouwd als één van de belangrijkste factoren, die een negatief effect kunnen hebben op de uitvoering van het plan (de Falco & Macchiaroli, 1998). De kans is dus reëel dat tijdens de uitvoering het project zal afwijken van wat initieel 11

21 vooropgesteld was in de planningsfase waardoor het halen van de projectdoelstellingen ernstig in het gedrang kan komen. Het werk van een projectmanager stopt dus met andere woorden niet nadat het project gepland werd aan de hand van schattingen en voorspellingen, maar er zal nog voldoende tijd moeten worden geïnvesteerd en inspanningen geleverd bij het opvolgen van het project in de uitvoeringsfase. Het opvolgen van een project tijdens de uitvoeringsfase kan een uitermate tijdrovend proces zijn voor de projectmanager. Aangezien de meeste projecten gekarakteriseerd worden door een zekere mate van complexiteit, voornamelijk door het aantal activiteiten, de voorrangsrelaties en de topologie van het netwerk, is het onmogelijk voor de projectmanager om elk onderdeel van het project in detail op te volgen en te controleren. Om het trackingproces zo effectief en efficiënt mogelijk te laten verlopen moet daarom in eerste instantie de juiste balans gevonden worden tussen het gemak van de projectmanager, waarmee hij het project op een doeltreffende manier kan opvolgen en de mate waarin hij de verschillende onderdelen van het project controleert. Hoe meer onderdelen hij wenst te controleren, hoe groter zijn inspanning zal zijn en omgekeerd. Een manier om het te controleren aantal activiteiten op een juiste wijze te beperken is om de inspanningen van de projectmanager te concentreren op die activiteiten die daadwerkelijk een invloed hebben op de uiteindelijke duurtijd van het project in kwestie, waardoor men veel gerichter correctieve acties kan toepassen (Vanhoucke, 2011). Aan de hand van informatie omtrent de huidige status van het project en informatie over de sensitiviteit van de verscheidene activiteiten, verkregen door het uitvoeren van een risicoanalyse, kan de inspanning op een dergelijke wijze worden geconcentreerd (Vanhoucke, 2011). Informatie omtrent de sensitiviteit van de activiteiten kan men bekomen door een Schedule Risk Analysis (SRA) uit te voeren. Aan de andere kant kan men via de Earned Value Management (EVM) techniek informatie genereren omtrent de mate waarin het project reeds voltooid is en de werkelijke zowel als de voorspelde waarden voor de duurtijden en de kosten. Het verkrijgen van deze informatie in real-time moet de projectmanager in staat stellen om zich een beter beeld te vormen van de werkelijke status van het project en om sneller de verschillende mogelijkheden voor verbetering te identificeren (Vanhoucke, 2011). In de literatuur worden beide technieken alom besproken en geprezen in het kader van projectcontrole, maar toch is er een fundamenteel verschil tussen beide wat tevens een belangrijk gevolg heeft voor het gemak waarmee het trackingproces kan worden uitgevoerd. Het uitvoeren van een Schedule Risk Analysis wordt beschouwd als een bottom-up trackingproces, waarbij de informatie verzameld wordt op het niveau van de individuele activiteiten. De Earned Value Management techniek daarentegen genereert informatie op het niveau van het project in zijn geheel, waarbij enkel bij het overschrijden van een bepaalde drempelwaarde naar het niveau van de individuele activiteiten zal worden gekeken (Vanhoucke, 2011). Beide technieken focussen dus op een compleet ander niveau van de Work Breakdown Structure (WBS). In een Work Breakdown Structure wordt het project op een hiërarchische wijze opgesplitst waarbij op 12

22 elk niveau meer en meer details worden toegevoegd, opdat men uiteindelijk op het laatste niveau enkel de individuele activiteiten overhoudt (Vanhoucke, 2012c). De Schedule Risk Analysis techniek focust op dit laatste niveau, wat de inspanning van de projectmanager bij het monitoren aanzienlijk verhoogt. Hierdoor wordt geargumenteerd dat de Earned Value Management techniek de enige is die mogelijk is voor mensen in de praktijk (Vanhoucke, 2009). We kunnen deze paragraaf besluiten door te stellen dat bij het organiseren en implementeren van het trackingproces een keuze dient gemaakt te worden omtrent welke niveaus van de Work Breakdown Structure in beschouwing zullen worden genomen en dit zal op zijn beurt een invloed hebben op de inspanning vereist van de projectmanager en de activiteiten die deel zullen uitmaken van de focus van de projectmanager. In de secties en zullen wij nader specificeren welke activiteiten in elk type trackingproces zullen worden beschouwd. In de volgende twee onderdelen van deze scriptie zullen wij iets dieper ingaan op zowel het top-down trackingproces als het bottom-up trackingproces zoals reeds kort aangehaald in voorgaande paragraaf. Wij zullen namelijk in het kader van dit onderzoek beide manieren om een projectcontrole uit te voeren, simuleren. In plaats van de trackingmethode aan te passen aan het al dan niet serieel of parallel zijn van het beschouwde netwerk, zoals dit in de praktijk wordt gedaan, kiezen we ervoor beide trackingmethoden voor elk projectnetwerk te bekijken. Op deze manier kan de scriptie eveneens als bevestiging dienen van eerder onderzoek, waarin men stelt dat de efficiëntie van EVM- en SRA-analyses afhangt van de mate waarin men te maken heeft met een serieel of eerder parallel netwerk (Vanhoucke, 2012b) Top-down trackingproces Zoals zijn naam reeds doet vermoeden is de Earned Value Management trackingmethode gebaseerd op het concept van de earned value ofwel de verworven waarde. Hiermee bedoelt men de waarde die men op een bepaald moment effectief verworven heeft door het reeds uitgevoerde werk op een zeker tijdstip (Vanhoucke, 2009). In de jaren 70 werd de Earned Value Management techniek door het Amerikaanse Departement voor Defensie voor het eerst op grote schaal toegepast, voornamelijk voor het opvolgen van de kosten gerelateerd aan een project door de earned value te vergelijken met de werkelijke kosten (Fleming & Koppelman, 2003). Hoewel aan de hand van de Earned Value Management techniek ook de vooruitgang van het project in de tijd kan worden opgevolgd door de earned value te vergelijken met de geplande waarde op verschillende tijdstippen, werd dit in mindere mate besproken in de literatuur (Vanhoucke, 2009). Echter, met de ontwikkeling van de Earned Schedule methode als bijkomend onderdeel van de Earned Value Management techniek, waarbij het vanaf nu mogelijk was om in termen van tijdseenheden te redeneren in plaats van in termen van monetaire eenheden, werd de top-down trackingmethode alsnog beschouwd als een belangrijke en intuïtieve manier om de vooruitgang van een project op te volgen en aldus aan projectcontrole te doen (Lipke, 2003). Bijkomend 13

23 werd er ook vastgesteld dat de maatstaven gebruikt in de Earned Schedule methode, namelijk de SV(t) en de SPI(t), een betrouwbaarder signaal geven naar het einde van het project toe in tegenstelling tot de overeenkomstige SV- en SPI-maatstaven, uitgedrukt in monetaire eenheden (Vanhoucke, 2009). Wij zullen daarom in ons onderzoek gebruik maken van de SPI(t) maatstaf om aan de hand van een top-down trackingmethode het project op te volgen. Hetgeen beschreven in deze paragraaf dient louter en alleen als korte inleiding en voor een meer uitgebreide bespreking van de vermelde concepten wordt de lezer doorverwezen naar de literatuur. Zoals reeds eerder vermeld worden de verschillende maatstaven aan de hand van de Earned Value Management techniek gegenereerd op het niveau van het project in zijn geheel en wordt er aldus geen rekening gehouden met de afzonderlijke activiteiten en hoe deze gerelateerd zijn ten opzichte van elkaar. Dit heeft ervoor gezorgd dat er sommige onderzoekers, zoals Jacob en Kane, beweren dat de maatstaven gebruikt in Earned Value Management wel degelijk het potentieel hebben om de vooruitgang van een project te voorspellen, maar enkel en alleen als zij op het niveau van de individuele activiteiten worden gebruikt (Vanhoucke, 2011). In hun onderzoek argumenteren zij dat het onmogelijk is voor de indicatoren, berekend op het hoogste WBS-niveau, om tevens rekening te houden met de voorrangsrelaties tussen de activiteiten en de slack waarover deze laatste zouden kunnen beschikken (Vanhoucke, 2011). De Earned Value Management maatstaven zullen een signaal geven, onafhankelijk van het feit of er een vertraging optreedt in een kritieke activiteit dan wel in een activiteit, die zich niet op het kritische pad bevindt (Vanhoucke, 2011). Indien er zich een vertraging voordoet in een activiteit die zich niet op het kriitische pad bevindt, dan zal er ofwel als enige gevolg een deel van de slack geconsumeerd worden, waardoor het signaleren van een probleem aan de hand van de Earned Value Management maatstaven overbodig is. Ofwel zal de vertraging in absolute waarde groter zijn dan de slack die hoort bij de activiteit en dan zal de activiteit kritisch worden, waardoor het signaleren van het probleem wel correct is. Jacob en Kane focussen zich in hun argumentatie voornamelijk op het voorkomen van het eerstgenoemde geval. Bijkomend kan het ook voorvallen dat, aangezien we enkel het hoogste WBS-niveau beschouwen, vertragingen in sommige activiteiten worden goedgemaakt door activiteiten die minder lang duren dan gepland en de indicatoren op deze manier niet op een accurate wijze de werkelijke problemen van het project zullen voorstellen (Vanhoucke, 2009). Hoewel beide auteurs in dit opzicht zeker geen ongelijk hebben, mogen zij de Earned Value Management methode echter niet zien als een substituut voor de trackingmethoden waarbij het project aan de hand van informatie omtrent de individuele activiteiten wordt opgevolgd (Vanhoucke, 2012a). Hoewel EVM effectief minder accuraat is doordat zij op een hoger niveau van de Work Breakdown Structure is gebaseerd, stelt het de projectmanager toch in staat om op een snelle en efficiënte manier zowel problemen als opportuniteiten gerelateerd aan het project te identificeren (Vanhoucke, 2012a). De Earned Value Management maatstaven zullen aangeven wanneer het noodzakelijk is om dieper te graven in de Work Breakdown Structure 14

24 en aldus ook de lagere niveaus in beschouwing te nemen (Vanhoucke, 2012a). Op deze manier stelt de Earned Value Management techniek de projectmanager in staat om zijn aandacht te beperken en enkel als het echt nodig is de individuele activiteiten te bekijken. Hierbij zal hij zich dan in eerste instantie focussen op de kritieke activiteiten, daar deze een fundamentele impact op de duurtijd van het project kunnen hebben. Indien het nodig wordt geacht, zal hij overgaan tot het nemen van correctieve acties om het project terug op schema te brengen (Vanhoucke, 2011). Samen met de mogelijkheid tot het incorrect signaleren van problemen bestaat er nog een belangrijk gevolg van een trackingmethode die zich toespitst op het niveau van het project in zijn geheel. Zoals ook in een studie van Vanhoucke (2012b) werd vastgesteld, zal de Earned Value Management methode voornamelijk geschikt zijn voor netwerken die eerder serieel zijn. Hoe meer parallelle activiteiten aanwezig zijn in het projectnetwerk, des te minder activiteiten er op het kritische pad zullen liggen en bijgevolg een werkelijke impact zullen hebben op de finale duurtijd van het project (Vanhoucke, 2012b). De Earned Value Management maatstaven zullen in deze gevallen minder betrouwbaar zijn en er minder vaak in slagen om een correct signaal te genereren waardoor de doeltreffendheid waarmee de projectcontrole wordt uitgevoerd beduidend lager zal zijn dan in het geval dat er projectnetwerken zullen worden beschouwd met een hogere SP-waarde als één van zijn topologische karakteristieken (Vanhoucke, 2012b). Tenslotte concludeerde dezelfde studie van Vanhoucke (2012b) dat de doeltreffendheid van de projectcontrole nog significant kon toenemen indien de top-down en bottom-up trackingmethoden met elkaar zouden worden gecombineerd. Wij zullen dit geval echter niet opnemen in deze scriptie, daar wij in dit verkennend onderzoek voornamelijk en in eerste instantie de individuele impact van beide soorten trackingmethoden op het proces van het toepassen van correctieve acties wensen te kennen en te onderzoeken. Het top-down trackingproces dat wij als onderdeel van dit onderzoek zullen simuleren, is volledig gebaseerd op de karakteristieken van de Earned Value Management methode als dusdanig gepubliceerd in de literatuur en in het kort beschreven in bovenstaande paragrafen. Zoals reeds eerder vermeld, zullen wij elk project opvolgen aan de hand van de Schedule Performance Index berekend aan de hand van de Earned Schedule methode (SPI(t)). Zoals weergegeven in formule 3.1 zal deze maatstaf tijdens elke trackingperiode de relatie weergeven tussen de earned schedule (ES) en het tijdstip waarop het project zich op het moment van tracken bevindt (AT) (Vanhoucke, 2009). SP I(t) = ES AT (3.1) De earned schedule geeft op zijn beurt weer wanneer de earned value, die hoort bij het tijdstip van tracken, volgens het plan gerealiseerd diende te worden (Vanhoucke, 2009). Om de earned 15

25 schedule te berekenen, moeten eerst en vooral de geplande waarden P V t en P V t+1 geïdentificeerd worden, voor dewelke geldt dat P V t EV < P V t+1, waarna formule 3.2 kan worden toegepast (Vanhoucke, 2009). ES = t + EV AT P V t P V t+1 P V t (3.2) Gedurende het trackingproces zullen wij de SPI(t)-indicator keer op keer berekenen voor elke trackingperiode. In ons geval betekent dit dat wij voor elke tien tijdseenheden de berekening zullen uitvoeren. Wij simuleren een vooruitgang van tien tijdseenheden omdat wij ook de duurtijden van alle activiteiten vermenigvuldigd hebben met een factor tien om op deze manier een nauwkeurigheid van 0,1 te realiseren. Voor een praktisch voorbeeld verwijzen wij de lezer naar sectie Per tien tijdseenheden zullen wij dus via deze SPI(t)-indicator een eerste indicatie verkrijgen over de status van het project. Deze indicatie wordt bekomen aan de hand van informatie op het niveau van het project in zijn geheel en dit zal een invloed hebben op de manier waarop wij praktisch dit top-down trackingproces zullen implementeren, wat wij nader zullen toelichten in volgende paragrafen. Vervolgens zullen wij een beslissing moeten nemen omtrent het al dan niet nemen van correctieve acties. In de praktijk zal de projectmanager beslissen over het uitvoeren van correctieve acties van zodra de Earned Value Management indicatoren een waarde aangeven die kleiner is dan een vooropgestelde grenswaarde (Vanhoucke, 2011). Wanneer de SPI(t)-indicator een waarde heeft die kleiner is dan één, betekent dit dat de earned schedule kleiner is dan het tijdstip waarop men zich nu bevindt; dit is het tijdstip van tracken. Dit impliceert dat volgens wat vooraf werd vastgelegd in het plan, de waarde die men nu pas verwezenlijkt heeft, in principe reeds vroeger moest worden gerealiseerd. Volgens de SPI(t)-indicator heeft het project aldus een vertraging opgelopen (Vanhoucke, 2012c). Hoewel het project potentieel heeft om achter te geraken op schema van zodra de SPI(t)-indicator kleiner is dan één, zal in de praktijk toch de grenswaarde nooit als dusdanig worden gespecificeerd. Dit zou immers betekenen dat bij de minste vertraging bij één of meerdere activiteiten onmiddellijk correctieve acties zullen worden toegepast. Dit zou niet alleen de projectkosten aanzienlijk doen stijgen, maar er zou ook geen rekening worden gehouden met de kans dat de vertraging nu eventueel later nog kan worden goedgemaakt. Dit laatste geval kan voorkomen wanneer voor het project de earned value volgens een andere trend wordt geaccumuleerd dan wat voor de geplande waarde werd meegegeven in de planningsfase, zonder dat de earned value en de geplande waarde op het einde van het project van elkaar zouden moeten verschillen (Vanhoucke, 2009). Om deze redenen opteren wij in dit onderzoek voor het hanteren van minder strikte grenswaarden. We zullen het trackingproces simuleren voor de waarden 0,95 en 0,80, die louter en alleen voor illustratieve doeleinden werden gekozen. 16

26 In de realiteit zullen deze grenswaarden in functie van de specifieke context worden gekozen en dermate worden aangepast (Hillson, 2004). Bijkomend kiezen wij ervoor om in dit onderzoek de grenswaarden constant te houden over alle fases van het project. In ons onderzoek maken we aldus geen onderscheid tussen begin- of eindfase van het project en is elke fase bijgevolg even belangrijk. Voor sommige projecten kan het echter wel voorvallen dat de beginfase belangrijker is dan de eindfases en dat daardoor de grenswaarden in het begin van het project strikter zullen worden gedefinieerd dan naar het einde toe of omgekeerd, maar dit zal geen onderwerp uitmaken van deze scriptie. Echter in het kader van toekomstig onderzoek kan het wel interessant zijn om ook het effect van variërende grenswaarden te onderzoeken. Zoals reeds vermeld in een voorgaande paragraaf kan het bij het toepassen van de Earned Value Management methode voorvallen dat de SPI(t)-indicator een waarde geeft die lager is dan de grenswaarde zonder dat er op dat moment een gevaar op vertraging bestaat. Aangezien wij het top-down trackingproces niet enkel zullen simuleren voor seriële netwerken en er dus een reële kans bestaat dat deze situatie zich voordoet, zullen wij bijkomende controles uitvoeren. Wij zullen toetsen of de werkelijke duurtijd, op het moment van tracken, werkelijk groter is dan wat door de geplande duurtijd wordt aangegeven en er dus één of meerdere activiteiten op het kritische pad een vertraging hebben. Enkel indien dit het geval is, zullen wij overgaan tot het nemen van een correctieve actie. Op deze manier willen we de gevallen waarbij onnodig correctieve acties worden genomen uit dit onderzoek filteren. In de praktijk zal de projectmanager namelijk, na het signaal gegeven door de Earned Value Management maatstaven, een analyse uitvoeren op het activiteitniveau en de activiteiten corrigeren die het project in gevaar brengen (Vanhoucke, 2011). Wij zullen daarom, indien de grenswaarden worden overschreden én de werkelijke duurtijd groter is dan de geplande duurtijd, de activiteit op het kritische pad met de laagste kost per eenheid, één eenheid crashen in het ene scenario en één eenheid fasttracken in het andere scenario. Het top-down trackingproces omvat aldus de volgende stappen: het berekenen van de SPI(t)- indicator, het vergelijken van de werkelijke duurtijd met de geplande duurtijd en het eventueel selecteren van de kritische activiteit met de laagste kost per gecorrigeerde eenheid, waarvan het nog mogelijk is om een eenheid te crashen of te fasttracken zoals in sectie verder zal worden uitgelegd. Nadat één trackingproces voltooid is, begint er na 10 tijdseenheden een nieuwe trackingperiode waarin het gehele proces opnieuw begint. Deze cycli blijven zich herhalen totdat het tijdstip van tracken samenvalt met de werkelijke duurtijd van het project en bijgevolg het trackingproces is afgelopen. 17

27 3.2.2 Bottom-up trackingproces Aan de basis van een bottom-up trackingproces ligt de Schedule Risk Analysis (SRA). De Schedule Risk Analysis werd toegevoegd aan de projectmanagement discipline als noodzakelijke aanvulling van de Critical Path Method (CPM), waarbij aan de hand van het kritische pad de totale duurtijd van het project kan worden voorspeld (Vanhoucke, 2010). Aangezien deze a-priorische analyse van het kritische pad in sterke mate afhankelijk is van de gemaakte schattingen van de duurtijden van de verschillende activiteiten, zal deze methode voor het voorspellen van de totale duurtijd van het project vaak een te optimistische kijk werpen op de zaak (Hulett, 2007). Bijkomend kan het ook voorkomen dat het kritische pad, dat geïdenificeerd wordt tijdens zo n analyse, niet het kritische pad betreft dat uiteindelijk een vertraging van de totale duurtijd van het project in de hand zal werken (Hulett, 2007). Door de tendens dat de werkelijke duurtijden van de verschillende activiteiten vaak niet in overeenstemming zijn met wat initieel werd geschat, wordt de Critical Path Method voornamelijk beschouwd als een referentiepunt in plaats van een accurate voorspelling van wat waarschijnlijk zal gebeuren en zal zij dus nog moeten worden aangevuld met een andere techniek om op een effectieve wijze aan projectcontrole te doen. Door het definiëren en kwantificeren van verschillende maatstaven, die een indicatie geven omtrent de sensitiviteit van de individuele activiteiten relatief ten opzichte van de uiteindelijke totale duurtijd van het project, kan er belangrijke informatie bekomen worden die in combinatie met een analyse van het kritische pad gebruikt kan worden om het project tijdens zijn uitvoering op te volgen (Vanhoucke, 2009). De maatstaven omtrent de sensitiviteit van elke activiteit worden berekend aan de hand van Monte Carlo simulaties en zullen door de projectmanager kunnen worden gebruikt om zijn aandacht te focussen op de activiteiten die het potentieel hebben om de totale duurtijd van het project in sterke mate te beïnvloeden. In de literatuur worden verschillende maatstaven beschreven, die elk op hun eigen manier uitspraak doen over de sensitiviteit van elke activiteit afzonderlijk (Vanhoucke, 2010). In een studie van Vanhoucke (2010) werd er voor vier verschillende maatstaven onderzocht in welke mate zij bijdragen tot het trackingproces en als dusdanig op een efficiënte en effectieve manier het project zoveel mogelijk op schema houden. Daaruit bleek in eerste instantie dat de Schedule Sensitivity Index (SSI) één van de maatstaven is die het best een subset van activiteiten met een hoge sensitiviteit kan definiëren en aldus op een effectieve wijze het onderscheid kan maken tussen activiteiten met een lage, medium en hoge sensitiviteit (Vanhoucke, 2010). Bijkomend concludeerde deze studie dat de SSI in dit opzicht ook goed presteert naarmate de drempelwaarden groter en groter worden en dit in vergelijking met de andere maatstaven (Vanhoucke, 2010). Des te groter de drempelwaarden, des te moeilijker het wordt om een kleine subset van activiteiten met een hoge sensitiviteit te selecteren. Aangezien hogere drempelwaarden leiden tot een lagere inspanning van de projectmanager om de projectcontrole uit te voeren, wordt de SSI als bijzonder relevant beschouwd in het kader van het opvolgen en monitoren van projecten. 18

28 Net zoals we reeds beschreven voor de Earned Value Management methode heeft ook het toepassen van een Schedule Risk Analysis zijn voordelen en zijn beperkingen. Zo maakt een bottom-up trackingmethode aan de hand van een Schedule Risk Analysis gebruik van informatie op het niveau van de individuele activiteiten (Vanhoucke, 2011). Deze informatie bevindt zich helemaal onderaan in de Work Breakdown Structure en zal aldus een grotere inspanning vragen van de projectmanager. Vergeleken met de snelle controle die mogelijk wordt gemaakt aan de hand van de Earned Value Management methode, zal via een Schedule Risk Analysis een grotere subset aan activiteiten continu van dichtbij moeten worden opgevolgd (Vanhoucke, 2011). Aangezien er via deze methode geen abstractie gemaakt wordt van bepaalde niveaus in de Work Breakdown Structure, wordt de Schedule Risk Analysis dan weer wel verondersteld om met een grotere accuraatheid informatie te verschaffen die tijdens het proces van het opvolgen van het project zal kunnen worden gebruikt. Vervolgens werd er ook aangetoond dat het al dan niet parallel of serieel zijn van een netwerk, zoals gekwantificeerd via de SP-indicator, een invloed heeft op het vermogen van de SRA-maatstaven om een correcte subset aan activiteiten te selecteren, dewelke tijdens de projectcontrole van naderbij zullen worden opgevolgd en indien het nodig wordt geacht, gecorrigeerd zullen worden (Vanhoucke, 2010). De SRA-maatstaven zullen in dit opzicht beter presteren naarmate het projectnetwerk eerder parallel is van structuur (Vanhoucke, 2010). Voor seriële netwerken zullen de waarden voor de SRA-maatstaven relatief hoger liggen en zullen zij voor de verschillende activiteiten in mindere mate verschillen van elkaar (Vanhoucke, 2010). Op deze manier zal het veel moeilijker worden om de activiteiten met een hoge sensitiviteit te onderscheiden van de activiteiten met een lagere sensitiviteit en aldus de juiste activiteiten te selecteren, die deel zullen uitmaken van de subset (Vanhoucke, 2010). Dit heeft tot gevolg dat de projectmanager in mindere mate invloed kan uitoefenen op het percentage van activiteiten die zullen worden opgevolgd, aangezien zij praktisch allemaal als vrij gevoelig zullen worden aangeduid. Aangezien wij in ons onderzoek de trackingmethode niet aanpassen aan de topologische karakteristieken van het netwerk, kunnen wij uit onze ervaring bevestigen dat bij een Schedule Risk Analysis van seriële netwerken het selecteren van de juiste subset geen sinecure is. Hoe wij dit praktisch hebben aangepakt kan worden gelezen in één van de volgende paragrafen. Daar kan ook worden gelezen dat wij de Schedule Sensitivity Index hebben gekozen als onderdeel van de Schedule Risk Analysis. Hoewel uit voorgaande bespreking bleek dat het niet altijd makkelijk is om de activiteiten met een hoge sensitiviteit en een lage sensitiviteit van elkaar te onderscheiden en dit voornamelijk bemoeilijkt wordt wanneer de drempelwaarden toenemen en het netwerk eerder een seriële structuur aanneemt, toch zal de SSI in al deze gevallen steeds de mogelijkheid bieden om een kleine subset van gevoelige activiteiten te selecteren, waardoor bij het nemen van correctieve acties de impact op de totale duurtijd van het project uitermate groot zal zijn (Vanhoucke, 2009). Dit zal bijgevolg onze grootste motivatie zijn om deze SRA-maatstaf op te nemen in ons onderzoek. 19

29 Alvorens het bottom-up trackingproces te simuleren, moeten wij in eerste instantie de Schedule Risk Analysis uitvoeren. De Schedule Risk Analysis zal op zijn beurt informatie verschaffen die belangrijk zal zijn voor het halen van de projectdoelstellingen en deze informatie kan al beschikbaar worden gesteld alvorens het project van start is gegaan (Hulett, 2007). Via P2 Engine waren wij in staat om, op basis van een voorgeprogrammeerd scenario, voor elke activiteit een kansverdeling te definiëren met betrekking tot de duurtijd. Dit scenario werd reeds gebruikt in een studie van Vanhoucke en zal bij de bespreking van de verschillende scenario s in sectie 3.3 nader worden toegelicht (Vanhoucke, 2009). Vervolgens hebben wij een Monte Carlo simulatie uitgevoerd, waarbij voor elk project de uitvoering 100 keer werd gesimuleerd. Wij hebben ondervonden dat wanneer tijdens de Monte Carlo simulatie de uitvoering van het project keer werd gesimuleerd, er geen significante verschillen optraden in de SSI-waarden. Hierdoor hebben wij ervoor gekozen om te werken met de 100 simulatieruns om de computertijd in zekere mate te beperken. Op basis van deze Monte Carlo simulaties kon de SSI voor elke individuele activiteit berekend worden via de P2 Engine tool. De Schedule Sensitivity Index kan praktisch berekend worden volgens onderstaande formule, waarbij σ di de standaardafwijking van de duurtijd van activiteit i betreft en σ RD de standaardafwijking van de totale duurtijd van het project voorstelt (Vanhoucke, 2009). SSI = σ d i CI σ RD (3.3) De SSI combineert aldus de standaardafwijkingen met de Criticality Index (CI), die weergeeft wat de kans is dat de desbetreffende activiteit op het kritische pad ligt. Op deze manier kan de SSI uitspraak doen over het relatieve belang van een activiteit in het beïnvloeden van de uiteindelijke duurtijd van het project. Om vervolgens gedurende de simulaties te weten waarop er correctieve acties kunnen worden toegepast indien er problemen worden vastgesteld, moet er in de eerste plaats een drempelwaarde worden gedefinieerd. In dit geval van bottom-up tracking worden de drempelwaarden gekozen aan de hand van de uitkomst van de Schedule Risk Analysis en worden zij gelijkgesteld aan een welbepaald X ste percentiel van alle SSI-waarden in een projectnetwerk. De drempelwaarde is dan de SSI-waarde waarvoor X% van de activiteiten lager is dan de drempelwaarde en bijgevolg (100-X)% gecontroleerd zal moeten worden. In ons onderzoek kiezen wij ervoor om twee scenario s te beschouwen waarbij wij in het ene scenario de drempelwaarde definiëren als het 63 ste percentiel en in het andere scenario werken met het 83 ste percentiel. Deze waarden voor de drempelwaarden werden gekozen op basis van een studie uitgevoerd door Vanhoucke (2010), waarbij ook deze percentielen als onderdeel van een bottom-up trackingproces werden 20

30 opgenomen in het onderzoek. Daarbij achten wij dit niveau van controle en aldus inspanning aanvaardbaar voor de projectmanager in de praktijk, zeker in het licht van voorgaande discussie omtrent het tijdrovende karakter van zulks een bottom-up trackingmethode. Het X ste percentiel betekent namelijk dat wij (100-X)% van het totaal aantal activiteiten in een netwerk zullen opnemen in de subset en aldus onderwerpen aan de controle van de projectmanager. In de praktijk is het niet altijd mogelijk om een X ste percentiel exact te laten overeenstemmen met een controle van (100-X)% van de activiteiten. Voornamelijk wanneer vele activiteiten dezelfde waarde hebben voor de SSI zal het moeilijk zijn om een SSI-waarde te specificeren als drempelwaarde waarvoor een subset van bepaalde grootte zal worden gecreëerd. Zo zal het gebeuren dat wanneer meerdere activiteiten een SSI-waarde hebben die overeenkomt met de gekozen percentielwaarde, het percentage aan te controleren activiteiten uiteindelijk lager zal uitvallen dan wat aan de hand van het percentiel werd gepostuleerd (Vanhoucke, 2010). Aangezien het voor ons onderzoek nefast zou zijn om voor de verschillende netwerken en over de verschillende scenario s voor de bottom-up trackingmethode een verschillend aantal activiteiten in de subset op te nemen, zullen wij bijkomend nog een andere parameter beschouwen om tot de gewenste subset te komen. Een verschillend percentage te controleren activiteiten zou namelijk ondermeer onze tracking efficiency maatstaven, zoals gedefinieerd in sectie 5.1 omtrent de output measures, dermate manipuleren en op deze manier een correcte vergelijking van de verschillende netwerken en de verschillende scenario s onmogelijk maken. Daarom zullen wij in eerste instantie per netwerk de activiteiten rangschikken volgens aflopende SSI-waarde en de activiteiten waarvoor een zelfde SSI-waarde wordt waargenomen, zullen nog eens gerangschikt worden volgens oplopende kost per gecorrigeerde eenheid. Op deze manier zal er telkens een controle van exact 37% en 17% van de activiteiten worden gegarandeerd. Eenmaal we weten welke activiteiten de focus zullen uitmaken van ons trackingproces, rest er ons enkel en alleen nog te definiëren wanneer en welke activiteit(en) zullen worden gecorrigeerd. Elke trackingperiode zal er worden geverifieerd of de werkelijke duurtijd van het project op het moment van tracken de geplande duurtijd van het project overstijgt. Indien dit het geval is dan zal de activiteit met de hoogste absolute SSI-waarde en de laagste kost uit de subset, voor dewelke het nog mogelijk is om te corrigeren, met één eenheid worden gecrasht in het ene scenario en met één eenheid worden gefasttrackt in het andere scenario. Dit proces zal zich herhalen zolang de werkelijke duurtijd groter blijkt dan de geplande duurtijd. Wanneer het project via de correctieve acties terug op schema is gebracht, gaan we tien tijdseenheden verder in de tijd waarna er zich een nieuw proces van controleren en corrigeren zal voordoen, totdat het einde van het project is bereikt. Het bottom-up trackingproces omvat aldus de volgende stappen: het definiëren van de kansverdelingen met betrekking tot de duurtijden van de activiteiten, het uitvoeren van een Monte Carlo simulatie bestaande uit een significant aantal iteraties of runs, het berekenen van de SRA-maatstaven aan de hand van de software. Daarna wordt er een drempelwaarde bepaald, die 21

31 een invloed zal hebben op de mate waarin de projectmanager de projectcontrole zal uitvoeren. Op basis van deze drempelwaarde wordt een subset aan activiteiten gedefinieerd met een hoge sensitiviteit relatief ten opzichte van de duurtijd van het project. Indien het project lijkt af te wijken van de vooropgestelde deadline zullen er correctieve acties worden uitgevoerd op één of meerdere van de activiteiten uit de subset. Dit alles wordt herhaald tot het einde van het project en aldus het einde van het trackingproces is bereikt Correctieve acties In voorgaande paragrafen hebben we voornamelijk gefocust op de eerste fase in het uitvoeren van een projectcontrole, namelijk het definiëren en het meten en monitoren van verschillende parameters. Indien de informatie vervat in deze parameters aangeeft dat het halen van de projectdoelstellingen in gevaar is, dan zal de tweede fase van de projectcontrole worden geactiveerd waarbij idealiter de potentiële oorzaken van de vertraging zullen worden geanalyseerd en in overeenstemming daarmee de verschillende mogelijkheden inzake correctieve acties zullen worden overlopen. In ons onderzoek veronderstellen we deze stap als gegeven. Wij zullen namelijk een scenario definiëren waarin we enkel en alleen de crash-optie zullen beschouwen en in een ander scenario zullen wij louter naar de fasttrack-optie kijken om uiteindelijk een duidelijke vergelijking te kunnen maken tussen beide alternatieven. In dit opzicht is het ook belangrijk te vermelden dat we er in dit onderzoek niet naar streven om een gecombineerde aanpak van crashen en fasttracken te onderzoeken. Wij wensen duidelijk te kennen wat de impact is van elke optie afzonderlijk en zullen crashen en fasttracken daarom ook afzonderlijk van elkaar beschouwen. De studie van een eventuele gecombineerde aanpak laten wij over aan toekomstig onderzoek waarbij men gebruik zal kunnen maken van de inzichten die in dit onderzoek worden verworven. Dit brengt ons naadloos bij de derde en laatste fase van de projectcontrole, waarbij de desbetreffende correctieve actie zal worden uitgevoerd, zodat het project opnieuw op schema komt en de vooropgestelde doelstellingen gevrijwaard blijven. Zowel het crashen van activiteiten als het fasttracken van activiteiten hebben als doel om de totale duurtijd van het project te reduceren zodat het project opnieuw volgens schema kan verlopen. Zij zullen beiden echter dit doel op een verschillende manier nastreven. In wat volgt zullen de karakteristieken van deze correctieve acties worden toegelicht alsook de consequenties die ze met zich meebrengen. Uiteindelijk zullen wij dan ook bespreken hoe wij deze correctieve acties hebben geïmplementeerd in ons simulatieprogramma en welke belangrijke punten wij daarbij in rekening hebben genomen alsook de verschillende assumpties die wij hebben moeten maken om het programma werkbaar te houden. 22

32 Crashen Crashen is één van de opties waarbij wordt getracht de totale duurtijd van het project te reduceren zonder dat de scope van het project drastisch moet veranderen, opdat zowel aan de restricties als de vooropgestelde mijlpalen en andere doelstellingen gerelateerd aan het project kan worden voldaan (Terrell, 2012). De Project Management Body of Knowledge (PMBOK) definieert crashen als een techniek om de totale duurtijd van een project te reduceren, waarbij een trade-off wordt gemaakt tussen tijd en kost, opdat op deze manier de grootste reductie kan worden gerealiseerd aan een zo laag mogelijk additionele kost (Terrell, 2012). Volgens de PMBOK kan men één of meerdere activiteiten crashen door overuren uit te betalen, extra resources toe te wijzen aan de activiteiten of de leveranciers extra te vergoeden opdat de leveringen, noodzakelijk voor de uitvoering van de activiteiten, bespoedigd worden (Terrell, 2012). Men geeft echter wel als terechte opmerking dat het crashen van een activiteit enkel effectief zal zijn indien de duurtijd van de activiteit(en) wel degelijk kan worden gereduceerd door het toevoegen van additionele resources, een element dat zeker in de praktijk bijzonder relevant blijkt te zijn (Terrell, 2012). Indien dit namelijk niet het geval is zal de enige impact van de correctieve actie een verhoogd risico en/of een verhoogde kost zijn zonder dat de duurtijd gereduceerd werd (Terrell, 2012). Zoals ook reeds kon worden gelezen in de getuigenis van Kris Jennes zijn er verschillende elementen die voor de crash-optie het risico en de kost onnodig de hoogte kunnen injagen. In software engineering is het probleem zo expliciet aanwezig dat er zelfs een wet uit voorkwam, namelijk de wet van Brooks (Levine & Novak, 2009). De wet stelt dat wanneer er extra resources worden toegewezen aan een softwareproject dat achter zit op schema, het project alleen nog meer vertragingen zal oplopen (Levine & Novak, 2009). Zoals reeds aangehaald door Kris Jennes, zijn het in dit geval ook voornamelijk de onervarenheid van de additionele resources en de verhoogde nood aan communicatie, die de productiviteit van alle resources gezamenlijk doen dalen (Levine & Novak, 2009). Deze elementen, ons aangereikt uit de praktijk, wijzen voornamelijk op het feit dat hoewel het crashen van activiteiten in theorie zeer duidelijk wordt gedefinieerd en omkaderd, de praktijk toch veel complexer zal blijken. De projectmanager zal met andere woorden op voorhand duidelijk moeten evalueren of het crashen van een activiteit wel degelijk de projectdoelstellingen ten goede zal komen. Aangezien deze kwalitatieve evaluatie van de crash-optie buiten de scope van ons onderzoek valt, zullen wij ze hier louter en alleen vermelden zonder deze elementen ook effectief op te nemen in onze simulaties. Wij zullen dus voor het programmeren van onze simulaties enkel rekening houden met een bepaalde kost van crashen, zonder al de bijkomende elementen expliciet in beschouwing te nemen. Hoe wij deze simulatie van het proces praktisch zullen ontwikkelen en opbouwen kan worden gelezen in de volgende paragrafen. 23

33 Zoals reeds eerder vermeld kan men een activiteit crashen door de huidige resources overuren uit te betalen, door het team uit te breiden met additionele werkkrachten of door extra materiaal toe te wijzen aan de activiteit. Ook kan men de leverancier vergoeden om de leveringen van het benodigde materiaal te bespoedigen indien een gebrek aan werkmiddelen de hoofdoorzaak is van de vertraging van het project. In al deze gevallen zal er aldus een extra kost moeten betaald worden, die we vanaf nu algemeen als de kost van crashen zullen aanduiden. Wij zullen de kost van crashen berekenen op basis van de kost van de activiteit omdat wij veronderstellen dat er een logisch verband bestaat tussen de kostprijs van de activiteit en de kostprijs om diezelfde activiteit sneller af te werken. De kostprijs van de activiteit werd door ons geïnitialiseerd door ad random voor elke activiteit een kost per tijdseenheid te specificeren tussen 0 en 10. Via de geplande duurtijden kan dan de geplande totale kost per activiteit worden berekend terwijl aan de hand van de werkelijke duurtijden, gegenereerd aan de hand van de Monte Carlo simulaties, de werkelijke totale kost van iedere activiteit kan worden berekend. De formule die wij zullen gebruiken bij de berekening van deze kost van crashen is als volgt: k correctief = Aantal eenheden gecrasht k activiteit Duurtijd activiteit (3.4) In deze formule betreft k correctief de kost van crashen voor een welbepaalde activiteit en wordt berekend aan de hand van het aantal eenheden gecrasht en de kost per tijdseenheid van de activiteit die we zullen crashen, namelijk k activiteit Duurtijd activiteit waarbij k activiteit de totale kost van de activiteit betreft. Aangezien we steeds per eenheid crashen kan de formule vereenvoudigd worden door het weglaten van de eerste term. Deze formule zal steeds de juiste kost per eenheid gecrasht geven onafhankelijk van het feit of deze berekend wordt aan de hand van de werkelijke duurtijd van de activiteit of de geplande duurtijd. Door het toepassen van formule 3.4 veronderstellen wij dat de kost van crashen lineair toeneemt met het aantal eenheden die gecorrigeerd worden. In één van onze uitbreidende scenario s zullen wij ook analyseren wat het effect is van een niet-lineaire kost van crashen. In deze uitbreidende scenario s zal de kost per eenheid gecrasht toenemen naarmate er additionele eenheden van de activiteit worden gecorrigeerd. Hierbij maken wij gebruik van formule 3.5. k correctief = (Aantal eenheden gecrasht + Hoeveelheid reeds gecrasht Duurtijd activiteit ) k activiteit Duurtijd activiteit (3.5) Aangezien wij steeds corrigeren per tijdseenheid zal Aantal eenheden gecrasht telkens gelijk zijn aan 1. Hoeveelheid reeds gecrasht Duurtijd activiteit zal groter worden telkens wanneer er additionele eenheden worden gecorrigeerd waardoor k correctief niet lineair zal toenemen. In dit opzicht is het nog belangrijk om op te merken dat door deze niet-lineaire kost per eenheid gecrasht het selecteren van de 24

34 meest optimale activiteit in het geval van een top-down trackingproces aan de hand van de EVM-methode op een andere manier zal gebeuren. Er zal veel meer worden afgewisseld tussen de verschillende activiteiten in plaats van continu dezelfde activiteit te corrigeren totdat zijn limiet is bereikt of totdat het niet meer mogelijk is om deze activiteit te corrigeren. In het geval van een bottom-up trackingproces aan de hand van de SRA-methode zal het proces om de meest optimale activiteit te selecteren niet veranderen aangezien het definiëren van de subset op voorhand gebeurt en er dus enkel rekening wordt gehouden met de kost om de eerste eenheid te crashen. Op deze manier zal deze subset identiek zijn aan de subset die zal worden gedefinieerd wanneer gebruik wordt gemaakt van lineaire kosten. Elke tien tijdseenheden zullen wij het project monitoren en aldus de parameters, gegenereerd aan de hand van de EVM- en SRA-analyse, evalueren. Aan de hand van de earliest start van elke activiteit weten wij op ieder moment van tracken welke activiteiten reeds gestart zijn en welke niet. Afhankelijk hiervan zullen wij de geplande duurtijd gebruiken voor de activiteit, zoals gespecificeerd in de baseline schedule, dan wel de werkelijke duurtijd, resulterend uit de Monte Carlo simulaties. Wij hebben voorzien dat de projectmanager de werkelijke duurtijd van de activiteit nog niet correct kan inschatten vanaf het moment dat zijn earliest start gelijk is aan het moment van tracken. Bij het begin van een activiteit is het voor de projectmanager namelijk nog niet altijd geheel duidelijk hoelang de activiteit nu werkelijk zal duren. Daarom zal pas vanaf het tijdstip dat de activiteit reeds voor 50% voltooid is, de werkelijke duurtijd gekend worden. Aangezien het crashen van een activiteit een invloed heeft op de earliest start van de activiteiten die er op volgen, zullen na elke correctie alle earliest starts opnieuw berekend worden. Voor het trackingproces gebaseerd op de Earned Value Management-analyse is deze stap samen met het herberekenen van het kritische pad uitermate belangrijk voor het identificeren van de kritische activiteiten, die het onderwerp van de focus zullen uitmaken. Wanneer een activiteit met één eenheid gecrasht wordt, dan kan het immers voorvallen dat het kritische pad verandert en deze activiteit zich na de correctie niet meer op het kritische pad bevindt. Aangezien wij steeds zullen corrigeren totdat de werkelijke duurtijd gelijk is aan de geplande duurtijd, zal er voor de volgende correctie met één eenheid een andere kritische activiteit worden geselecteerd. Het selecteren van de optimale activiteit om te crashen is een proces dat voor elke trackingperiode en na elke eenheid gecorrigeerd wordt herhaald en het omvat de volgende stappen. In eerste instantie zal er gekeken worden naar de activiteiten die nog niet volledig voltooid zijn en naar de activiteiten die nog niet gestart zijn. Voor het top-down trackingproces zullen uit deze verzameling aan activiteiten enkel degene op het kritische pad beschouwd worden. Het corrigeren van een kritische activiteit zal namelijk de grootste impact hebben op de totale duurtijd van het project en bij gebrek aan informatie specifiek voor de individuele activiteiten, zijn de kritische activiteiten de meest voor de hand liggende keuze om aan een correctieve actie te 25

35 onderwerpen. Voor het bottom-up trackingproces daarentegen zal men uit deze verzameling enkel die activiteiten beschouwen waarvoor de SSI de drempelwaarde overschrijdt, daar deze een hoge sensitiviteit hebben ten opzichte van de totale duurtijd van het project. Vervolgens zullen wij het toepassen van correctieve acties limiteren. Voor het crashen van een activiteit betekent dit dat de duurtijd slechts voor een beperkt percentage kan worden gereduceerd. Wij veronderstellen hierbij twee scenario s, namelijk dat de duurtijd van een activiteit slechts voor 35% kan worden ingekort en dat de duurtijd van de activiteit slechts voor 50% kan worden ingekort. Aan de hand hiervan maken we impliciet de assumptie dat de activiteit niet oneindig kan worden gereduceerd en dat het blijven toevoegen van additionele resources bijgevolg geen impact zal blijven hebben onder meer door de communicatie- en coördinatieproblemen, die eerder nog werden vermeld. Telkenmale zullen we dus ook nagaan of de activiteit zijn limiet nog niet bereikt heeft en nog voldoende capaciteit heeft om gecorrigeerd te worden. Indien dit niet het geval is dan zullen wij de desbetreffende activiteit niet meer in beschouwing nemen. Uiteindelijk zullen wij alle activiteiten die voldoen aan de voorgaande vereisten evalueren op basis van hun kost van crashen. Aangezien de projectmanager steeds de afweging zal moeten maken tussen tijd en kost, zal hij streven naar de grootste tijdsreductie die gerealiseerd kan worden aan de laagste kost. Bijgevolg zullen wij in deze laatste stap de activiteit selecteren met de laagste kost van crashen. Deze activiteit zal dan voor één eenheid worden gecrasht, waarna het volledige proces zich zal herhalen opdat steeds de meest geschikte activiteit zal beschouwd worden totdat de werkelijke totale duurtijd gelijk is aan de geplande totale duurtijd. Nadat alle netwerken uit de dataset zijn onderworpen aan een top-down trackingproces en een bottom-up trackingproces waarbij telkens gecorrigeerd werd aan de hand van het crashen van de activiteiten, dan zal men uiteindelijk verschillende maatstaven kunnen berekenen die de prestatie van het corrigeren aan de hand van crashen zullen evalueren. Een gedetailleerde beschrijving van deze maatstaven en de bijhorende resultaatsanalyse kan men vinden in hoofdstuk 5. Alvorens deze resultaatsanalyse uit te voeren, bespreken we eerst het corrigeren aan de hand van fasttracken, waarna we in staat zullen zijn een duidelijke vergelijking te maken tussen beiden. Fasttracken Fasttracken is net zoals crashen een techniek om de totale duurtijd van een project te reduceren zonder dat daarbij de scope of andere karakteristieken van het project drastisch moeten veranderen (Terrell, 2012). Bij het fasttracken van activiteiten worden enkel en alleen de voorrangsrelaties tussen de activiteiten aangepast. De Project Management Body of Knowledge definieert fasttracken als een techniek om de totale duurtijd van een project te reduceren, waarbij activiteiten die normaliter volgens hun voorrangsrelaties in serie moeten worden uitgevoerd, vanaf nu in parallel zullen worden uitgevoerd (Terrell, 2012). De activiteiten zullen aldus gedeeltelijk of geheel met elkaar overlappen en de finish-start relatie zal op deze manier 26

36 niet meer van toepassing zijn. Een voorbeeld hiervan kan zijn dat men reeds het werk opstart voor het leggen van de funderingen van een gebouw alvorens alle bouwschetsen vervolledigd en goedgekeurd zijn (Terrell, 2012). Indien de ontwerpfase en de productie voor een deel met elkaar overlappen, dan loopt men het risico dat de informatie die doorgegeven wordt van de ontwerpers naar de fabrikanten onvolledig en zelfs soms onjuist zal zijn, waardoor de kans bestaat dat een deel van het werk opnieuw zal moeten worden uitgevoerd. Gedurende de ontwerpfase kan men nog beslissen om bepaalde zaken te wijzigen of op een andere manier te ontwerpen dan dat men initieel had voorzien. Op deze manier zal het werk in de productiefase, dat gebaseerd was op onvolledige of onjuiste informatie opnieuw moeten worden uitgevoerd waardoor er niet alleen extra tijd maar ook extra geld zal moeten worden gespendeerd. Dit impliceert enerzijds dat de reductie in tijd, als resultaat van het fasttracken van de activiteit, niet volledig zal worden verwezenlijkt aangezien er nog een bepaalde portie van het werk zal moeten worden herdaan en anderzijds dat het fasttracken van een activiteit niet geheel kosteloos kan gebeuren. Volgens een studie van Palaneeswaran (2006) zouden de kosten van het heruitvoeren van het werk de totale kosten van het project met 10% kunnen doen stijgen. Dit percentage werd gedefinieerd na de analyse van een aantal grote bouwprojecten. Het werk dat moet worden herdaan zullen we vanaf nu aanduiden met de term rework. De PMBOK wijst er ook in dit geval op dat het fasttracken van een activiteit enkel het gewenste resultaat zal hebben, wanneer de duurtijd effectief kan worden gereduceerd door activiteiten met elkaar te laten overlappen (Terrell, 2012). Zoals Kris Jennes reeds opmerkte kan het voorvallen dat dezelfde resources toegewezen werden aan de opeenvolgende activiteiten, waardoor het werken aan de ene activiteit verhindert dat er tegelijkertijd aan de andere activiteit kan worden gewerkt. Op deze manier zal het in parallel uitvoeren van de activiteiten geen winst in tijd betekenen. De beslissing omtrent het al dan niet reduceren van de totale duurtijd van het project aan de hand van fasttracken zal in sterke mate afhangen van de risico s die de projectmanager in zijn specifieke geval zal identificeren. Zo zal het niet ongebruikelijk zijn dat bij het fasttracken van nieuwe projecten, die geen gelijkenissen vertonen met reeds eerder uitgevoerde projecten, er een significante hoeveelheid rework zal optreden (Kohler, n.d.). In dit geval zal men geen beroep kunnen doen op eerdere ervaringen bij het identificeren van de activiteiten die het meest geschikt zijn om te fasttracken en zal men aldus minder makkelijk de risico s kunnen evalueren die verbonden zijn met de fasttrack-optie. Ook projecten waarbij er in grote mate interactie is tussen de verschillende activiteiten zullen doorgaans voor het fasttracken grotere risico s met zich meebrengen (Kohler, n.d.). In beide gevallen wordt er aldus niet aangeraden om tijdens het trackingproces de correctieve acties te baseren op het fasttracken van activiteiten. Indien de projectmanager de risico s om het project te fasttracken niet significant acht, dan zal hij wel nog moeten rekening houden met het feit dat de administratieve taken en de communicatie in grote mate zullen toenemen, in het bijzonder voor complexe projecten (Kohler, n.d.). Dit 27

37 alles illustreert opnieuw dat het louter aanpassen van de voorrangsrelaties tussen activiteiten in theorie makkelijker lijkt te implementeren dan dat het in de werkelijkheid het geval is. In de realiteit zal er met veel meer bijkomende elementen rekening moeten worden gehouden. In ons onderzoek zullen wij deze elementen niet expliciet opnemen bij het simuleren van de fasttrackoptie. Deze kwalitatieve aspecten werden hier enkel en alleen maar vermeld ter volledigheid. Telkens wanneer een activiteit met één eenheid zal worden gefasttrackt, dan zullen wij daarvoor een bepaalde portie rework definiëren, die de totale duurtijd van de activiteit zal doen toenemen alsook de totale kost van de activiteit. Wij zullen dus louter en alleen de kwantitatieve impact van het fasttracken van het project evalueren. In wat volgt zullen wij meer in detail toelichten op welke manier het fasttrackproces werd opgesteld en geïmplementeerd, waar we de focus hebben gelegd en wat onze assumpties zijn. Daarvoor hebben wij zoveel mogelijk, hetgeen beschreven staat in deze paragraaf, als referentiepunt genomen. In eerste instantie zullen wij definiëren wat de hoeveelheid rework zal bedragen telkens wanneer men een activiteit zal fasttracken. Wij zullen hiervoor twee basisscenario s definiëren, waarbij we zullen onderzoeken wat de effecten zijn van 25% rework en 50% rework. In deze twee scenario s zullen we afhankelijk van het percentage rework dat we definiëren de duurtijd van de activiteit, die we zullen fasttracken, vermeerderen met de hoeveelheid rework en op basis daarvan ook de kost van fasttracken berekenen. 25% en 50% rework betekent dat er voor elke unit dat er wordt gefasttrackt respectievelijk 0,25 en 0,50 eenheden rework zullen worden gerealiseerd. Vervolgens hebben wij ook nog enkele uitdiepende scenario s gedefinieerd waarbij wij de hoeveelheid rework zullen laten variëren tussen 0% en 10%. Het scenario met 0% rework is het ideale geval waarbij het fasttracken volledig kosteloos en zonder een toename in de totale duurtijd van de activiteit kan plaatsvinden. De kost van fasttracken kan worden berekend aan de hand van formule 3.6. k correctief = Aantal eenheden gefasttrackt p rework k activiteit Duurtijd activiteit (3.6) In deze formule geeft k correctief de kost van fasttracken weer voor een welbepaalde activiteit en deze kost wordt berekend aan de hand van het aantal eenheden gefasttrackt, het percentage rework, namelijk p rework en de kost per tijdseenheid van de activiteit die we zullen fasttracken, namelijk k activiteit Duurtijd activiteit waarbij k activiteit de totale kost van de activiteit betreft. Aangezien we steeds per eenheid fasttracken kan de formule vereenvoudigd worden door het weglaten van de eerste term. Ook hier geldt dat steeds de juiste kost zal worden bekomen, of men nu werkt met de geplande duurtijden dan wel met de werkelijke duurtijden. Het feit of we de werkelijke duurtijden dan wel de geplande duurtijden zullen gebruiken hangt in dit geval ook weer in sterke mate af van de earliest start van elke activiteit. De activiteiten 28

38 zullen ook hier weer pas gekend worden en aldus gekarakteriseerd worden door hun werkelijke duurtijden als, op het moment van tracken, reeds 50% van de activiteit werd afgewerkt. Het fasttracken van een activiteit betekent dat de activiteit voor een deel zal overlappen met zijn voorganger en aldus naar voren zal geschoven worden in het project. Dit zal niet alleen een rechtstreeks effect hebben op de earliest start van de activiteiten die op de gefasttrackte activiteit volgen, maar ook op de earliest start van de gefasttrackte activiteit zelf. In het geval van fasttracken moet er op basis hiervan extra aandacht worden besteed opdat het kritische pad nog op een juiste manier berekend wordt. Indien dit niet het geval is dan zal het programma ons een verkeerde waarde meegeven voor de totale werkelijke duurtijd van het project en dan zal het er ook niet in slagen om de activiteiten die liggen op het kritische pad te identificeren. Zoals reeds eerder vermeld is het voornamelijk voor het top-down trackingproces uitermate belangrijk dat, na elke correctie met één eenheid, het kritische pad correct wordt herberekend en aldus de kritische activiteiten worden geïdentificeerd. Het telkens selecteren van de meest optimale activiteit om te fasttracken is in dit geval ook een proces dat meerdere stappen omvat en zal in grote mate gelijklopen met het selectieproces dat reeds beschreven werd in het deel omtrent crashen. Toch zullen bepaalde zaken op een andere manier benaderd moeten worden. Zo zal men eerst en vooral enkel de activiteiten beschouwen die nog niet reeds gestart zijn. Indien het werk voor het uitvoeren van een activiteit reeds is aangevat, dan verliest deze activiteit het potentieel om het werk vroeger te laten beginnen dan hetgeen in de baseline schedule werd vooropgesteld en zal het aldus niet meer mogelijk zijn om deze activiteit te fasttracken. Dit impliceert dat de mogelijkheden voor het fasttracken van activiteiten kleiner zijn dan in het geval van crashen. Zeker wanneer het project bestaat uit activiteiten met een lange duurtijd. Uit de verzameling van activiteiten die nog niet gestart zijn, zullen dan voor het top-down trackingproces aan de hand van de EVM-analyse de kritischee activiteiten geselecteerd worden. Het fasttracken van kritische activiteiten zal immers leiden tot de grootste bijdrage in het reduceren van de totale duurtijd van het project. Voor het bottom-up proces aan de hand van een SRA-analyse daarentegen zal men focussen op activiteiten die niet reeds gestart zijn en waarvoor tegelijkertijd de waarde van de SSI de gespecificeerde drempelwaarde zal overschrijden. Vervolgens zullen we ook het fasttracken van activiteiten limiteren. Wij zullen een scenario definiëren waarbij we 50% overlap toelaten en een scenario waarbij we 35% overlap toelaten. In vergelijking met de scenario s gebaseerd op het corrigeren aan de hand van crashen zullen wij hier dus ook onderzoeken wat het effect is van een correctie met 50% en een correctie met 35%. Belangrijk om op te merken is, dat een overlap met X% betekent dat zowel de te fasttracken activiteit als zijn onmiddellijke voorganger(s) slechts voor X% deel mogen uitmaken van de overlap. Dit wil zeggen dat we bij het berekenen van de maximum toegestane overlap het minimum zullen nemen van X% van de duurtijd van de te fasttracken activiteit en X% van de duurtijd van zijn onmiddellijke voorganger(s). Bij het berekenen van de 29

39 toegestane overlap moet er nog rekening worden gehouden met drie belangrijke elementen. Het moment van tracken zal een belangrijke invloed hebben op het aantal eenheden dat nog toegestaan is te fasttracken. Het kan immers voorvallen dat het tijdstip van monitoren zodanig is dat de toegestane overlap, berekend aan de hand van hetgeen eerder beschreven werd, niet meer mogelijk is. Indien dit het geval is, zullen wij de activiteiten laten overlappen totdat de earliest start van de gefasttrackte activiteit gelijk is aan het tijdstip van monitoring. Op deze manier zullen we voorkomen dat een activiteit gefasttrackt wordt naar een tijdstip in het verleden. Ook kan het voorvallen dat er zich een bepaalde hoeveelheid slack tussen twee activiteiten bevindt. Deze slack dient echter niet in rekening te worden gebracht bij het berekenen van de maximaal toegestane overlap. Tenslotte zal het al dan niet in rekening brengen van de hoeveelheid rework afhangen van de activiteit die wordt beschouwd. De hoeveelheid rework van de activiteiten die onmiddellijk voorafgaan aan de gefasttrackte activiteit zullen in de berekening van de maximaal toegestane overlap wel expliciet in rekening worden gebracht. De hoeveelheid rework van de gefasttrackte activiteit zelf zal echter niet opgenomen worden in de berekening. Indien dit wel het geval zou zijn, dan zou de reeds gerealiseerde rework er immers voor zorgen dat er nog meer kan worden gefasttrackt, wat dan weer zou leiden tot nog meer rework. Uiteindelijk na het maken van alle berekeningen, zullen wij in deze stap erin slagen die activiteiten te identificeren die nog voor minstens één eenheid kunnen worden gefasttrackt. In de derde en laatste stap zullen wij dan ook in dit geval de activiteit selecteren met de laagste kost van fasttracken. Op deze manier zal men steeds streven naar de zo groot mogelijke reductie in tijd tegen een zo laag mogelijke kost, een balans die elke projectmanager telkens opnieuw zal trachten te optimaliseren. Wij zullen elk netwerk uit de dataset ook hier eens onderwerpen aan een top-down zowel als een bottom-up trackingproces waarbij deze keer de correctieve acties zullen worden gebaseerd op het fasttracken van de activiteiten zoals beschreven in voorgaande paragraaf. Ook hiervoor zullen we de verschillende maatstaven kunnen berekenen en deze dan vergelijken met degene bekomen voor het crashen van activiteiten. Alvorens we de opzet van en de inzichten verkregen door de data-analyse zullen bespreken, zullen we eerst nog een overzicht geven van de verschillende onderzochte scenario s. Op deze manier zal de lezer, alvorens zich te storten in de resultaten van de data-analyse, een duidelijk beeld hebben van wat er nu juist allemaal met elkaar zal worden vergeleken. 3.3 Verschillende scenario s Zoals reeds eerder vermeld zullen wij de eerste subset uit de dataset van netwerken, gedefinieerd door Vanhoucke (2009), gebruiken als input voor de verschillende scenario s. Wij zullen steeds 50 netwerken selecteren uit drie verschillende SP-intervallen, namelijk ]0,1;0,2[, ]0,4;0,5[en ]0,7;0,8[. De voortgang van de projectnetwerken zullen we simuleren via P2 Engine door gebruik 30

40 te maken van het voorgeprogrammeerde scenario 8, dat ontwikkeld was voor en gebruikt werd in een studie van Vanhoucke (2009).Volgens dit scenario zal de voortgang van de verschillende projecten zodanig worden gesimuleerd dat het project gemiddeld genomen een vertraging zal oplopen, waarbij deze vertraging bij het begin van het project op een correcte manier zal gesignaleerd worden door de SPI(t)-maatstaf tijdens de EVM-methode (Vanhoucke, 2009). Bij het begin van het trackingproces kan men er dus zeker van zijn dat de totale werkelijke duurtijd van het project effectief groter is dan de totale geplande duurtijd van het project. Het onderzoeken van projecten waarbij de SPI(t)-maatstaf bij het begin van het trackingproces aangeeft dat het project achter zit op schema zonder dat dit het geval is, valt op deze manier buiten de scope van dit onderzoek en kan eventueel in de toekomst verder worden uitgediept. Men zou dan kunnen nagaan welke correctieve acties het minst negatieve effect zouden hebben op de tijds- en kostdimensie van het project. Scenario 8 zorgt er ook voor dat initieel de vertragingen zich voordoen in de kritische activiteiten en dat de niet-kritische activiteiten alvorens het uitvoeren van correctieve acties volgens het plan verlopen (Vanhoucke, 2009). Uiteraard, door het uitvoeren van ons trackingproces en de correctieve acties die daarmee gepaard gaan, kunnen deze elementen veranderen. Het kan dan namelijk voorvallen dat de SPI(t)-maatstaf niet meer correct de status van het project voorspelt en dat door het veranderen van het kritische pad, nu ook niet-kritische activiteiten vertragingen oplopen. Elk van deze gesimuleerde netwerken zullen wij onderwerpen aan 24 verschillende scenario s door het variëren van onderstaande parameters: Het percentage dat we toelaten te crashen en te fasttracken: 35% en 50% De grenswaarden voor de SPI(t)-maatstaf: 0,8 en 0,95 De grenswaarden voor de SSI-maatstaf: 0,17 en 0,37 Het percentage rework als gevolg van het fasttracken van een activiteit: 0%, 25% en 50% Door de verschillende waarden van deze parameters met elkaar te combineren bekomen we de 24 scenario s zoals weergegeven in onderstaande tabellen 3.1 en

41 Max fasttrack Rework SPI(t) Max fasttrack Rework SSI 50% 0,95 0,37 50% 50% 0,80 0,17 50% 0,95 0,37 25% 25% 0,80 0,17 35% 0,95 0,37 50% 50% 0,80 0,17 35% 0,95 0,17 25% 25% 0,80 0,17 Tabel 3.1: Overzicht basisscenario s fasttracken Max crash SPI(t) Max crash SSI 50% 0,95 0,37 50% 0,80 0,17 35% 0,95 0,37 35% 0,80 0,17 Tabel 3.2: Overzicht basisscenario s crashen Dit hebben we dan uitgebreid met een aantal uitdiepende scenario s. In deze scenario s hebben we additioneel gefocust op andere percentages rework zoals voorgesteld in tabel 3.3 en het voorkomen van niet-lineaire kosten bij crashen zoals voorgesteld in tabel 3.4. Max fasttrack Rework SPI(t) Max fasttrack Rework SSI 10% 10% 50% 8% 4% 0,95 50% 4% 2% 0,37 0% 0% Tabel 3.3: Overzicht uitdiepende scenario s fasttracken Max crash SPI(t) Opmerkingen Max crash SSI Opmerkingen 50% 50% 0,95 niet-lineaire kost 0,37 niet-lineaire kost 35% 35% Tabel 3.4: Overzicht uitdiepende scenario s crashen Op deze manier zullen wij dan de resultaten van het fasttracken en crashen voor de verschillende scenario s met elkaar kunnen vergelijken alsook de scenario s die horen bij crashen en fasttracken onderling. Wij zullen aan de hand hiervan een antwoord kunnen formuleren op vragen zoals: In welke gevallen is crashen beter dan fasttracken of omgekeerd? 32

42 Wat is het effect van de grenswaarden voor de maatstaven, gebruikt tijdens het trackingproces? Wat is het effect van rework en het maximaal toegestane percentage om te crashen en te fasttracken? De antwoorden op al deze vragen vindt men in hoofdstuk 5 waarin de resultaatsanalyse wordt toegelicht. Vooraleer we echter deze data-analyse in detail bespreken, zullen we eerst nog een hoofdstuk wijden aan het toelichten van de verschillende algoritmes die door ons gebruikt werden voor de ontwikkeling van het simulatieprogramma. 33

43 Hoofdstuk 4 Methodologie Voor deze scriptie hebben wij gebruik gemaakt van een simulatiestudie aan de hand van fictieve projecten. Hiervoor hadden wij eerst en vooral nood aan data om de vooruitgang van onze projecten te simuleren. Deze data werd gegenereerd door gebruik te maken van de P2 Engine tool. Vervolgens hebben wij gesimuleerd hoe een projectmanager zou reageren wanneer er vertragingen optreden tijdens het trackingproces en er aldus correctieve acties moeten worden genomen. Hiervoor hebben wij een eigen programma ontwikkeld in C++ dat we in sectie 4.2 uitgebreid zullen bespreken. 4.1 P2 Engine Als input voor het onderzoek werd gebruik gemaakt van de dataset DataSetEvms Patterson. Deze dataset werd reeds gedefinieerd en gebruikt in een studie van Vanhoucke (2009) en bestaat uit gegenereerde netwerken van projecten. Voor elk project wordt er per activiteit telkens meegegeven wat de vervolgactiviteiten zijn en hoelang elke activiteit duurt. Dit vormt dan ook de basis voor ons baseline schedule of theoretisch netwerk. Vertrekkende van deze dataset hebben we P2 Engine gebruikt om te simuleren hoelang een bepaalde activiteit in werkelijkheid zou duren indien er geen correctieve acties zouden worden toegepast. Door gebruik te maken van een functionaliteit in P2 Engine waren wij immers in staat om per netwerk 100 Monte Carlo simulaties te genereren. Op deze manier werd het mogelijk om een accuraat beeld te verkrijgen van hoe de werkelijke uitvoering van een project zou kunnen verlopen. Daarnaast was het noodzakelijk om voor elke activiteit een kost per eenheid te specificeren. De waarde voor de kost van elke activiteit in het projectnetwerk werd gegenereerd met behulp van een random functie. Verder hebben wij ook gebruik gemaakt van de Monte Carlo simulaties in P2 Engine om de SSI-indicatoren van de activiteiten van een netwerk te bepalen. Alsook om de topologische 34

44 factoren zoals SP, AD, LA en TF op te vragen voor elk netwerk afzonderlijk opdat deze in het simuleringsprogramma en bij de analyse van de resultaten kunnen worden gebruikt. 4.2 Verloop van de simulatie: C++ programma In dit gedeelte beschrijven we de werking van het programma waarmee de acties van de projectmanager op een logische wijze worden gesimuleerd door een proces van monitoren en corrigeren. Hierbij maken we een onderscheid tussen twee verschillende trackingmethodes en twee verschillende correctieve acties. Dit geeft ons vier unieke manieren om het gedrag en de reactie van de projectmanager te simuleren. Deze verschillende mogelijkheden om het trackingproces te organiseren, zijn weergegeven in tabel 4.1. Tracking methode EVM SRA Correctieve actie Crashen Fasttracken Crashen Fasttracken Tabel 4.1: Mogelijke opties projectmanager De projectmanager zal bij het opvolgen van een project een reeks van logische stappen doorlopen. Deze stappen zijn terug te vinden in figuur 4.1 en vormen de basis van de simulatiestudie. Op deze figuur wordt er weergegeven welke verschillende acties de projectmanager zal ondernemen en welke beslissingen gepaard gaan met het uitvoeren van een projectcontrole. Hierbij is het belangrijk om op te merken dat een activiteit in ons geval steeds optimaal is als deze activiteit, gegeven zijn karakteristieken zoals het kostprofiel, het meest in aanmerking komt om een correctieve actie op toe te passen. Voor elk van deze stappen zal er nadien uitgebreid besproken worden hoe wij ze geïmplementeerd hebben in ons simuleringsprogramma. 35

45 Figuur 4.1: Flowchart programma 36

46 4.2.1 Uitvoering simuleren Met deze functie wordt er gesimuleerd hoe een projectmanager de opvolging van zijn project zou aanpakken. Alvorens het trackingproces effectief aan te vatten, moet er eerst nog enig voorbereidend werk worden verricht. Zo moet de projectmanager op de hoogte zijn van wat het kritische pad precies is en hoeveel de geplande duurtijd van het project bedraagt. De geplande duurtijd geeft immers aan hoelang het project verondersteld wordt te duren en aldus welke deadline moet worden nagestreefd. De projectmanager zal daarom deze geplande duurtijd tijdens het trackingproces als referentiepunt gebruiken. Indien de projectmanager gebruik wenst te maken van de Earned Value Management methode dan moet hij tevens op de hoogte zijn van wat de planned value (PV) is per keer dat hij een controle uitvoert. Alleen op deze manier kan de earned schedule op een correcte wijze worden berekend zoals weergegeven in formule 3.2. Vervolgens gaat de effectieve opvolging van de uitvoering van het project van start. De oorspronkelijke schaal van het project was 1, maar we hebben ervoor geopteerd om dit te herschalen naar een schaal van 0,1 door alle duurtijden te vermenigvuldigen met 10. We doen dit zodat we kunnen corrigeren met een nauwkeurigheid van 0,1. Concreet betekent deze aanpassing het volgende: stel een activiteit die een duurtijd heeft van 5 en een earliest start van 10 dan herschalen we dit naar een duurtijd van 50 en een earliest start van 100. Indien we dan corrigeren met 1 eenheid, dan corrigeren we volgens onze originele schaal eigenlijk met 0,1. Merk op dat we voor de eenvoud bij alle toekomstige voorbeelden geen rekening houden met deze herschaling. We gaan uit van een projectmanager die op simuleringstijd t de voortgang van zijn project controleert op de volgende manier en daarbij de onderstaande stappen doorloopt: Stap 1: Worden er nieuwe activiteiten gekend? In deze stap wordt er gecontroleerd of er activiteiten zijn die een earliest start hebben die kleiner is dan de huidige simuleringstijd t. Indien de earliest start kleiner is dan t en de activiteit nog niet gekend is, dan zouden we kunnen veronderstellen dat de projectmanager op dat moment kan inschatten hoelang de activiteit werkelijk zal duren. Hij zou dus met andere woorden een correcte inschatting kunnen maken omtrent de mogelijke vertraging van de activiteit. Wij hebben er echter voor gekozen deze assumptie ietwat strenger te definiëren. Zoals reeds eerder vermeld in hoofdstuk 3 zullen we bij onze simulaties veronderstellen dat een projectmanager de werkelijke duurtijd van een activiteit pas correct kan inschatten nadat 50% van de geplande duurtijd van die activiteit reeds is verstreken. Neem als voorbeeld een activiteit met een geplande duurtijd van 10 en een earliest start van 10. Stel echter dat deze activiteit een werkelijke duurtijd heeft van 20. Vanaf het moment dat 37

47 het simuleringstijdstip gelijk is aan 15, zou de projectmanager in staat moeten zijn om te weten of deze activiteit langer zal duren dan initieel gepland en hoe groot de eventuele vertraging is. Vanaf stimuleringstijdstip 15 wordt de duurtijd van de activiteit aldus gelijk aan 20 in plaats van 10. Merk wel op dat dit enkel geldig is indien de geplande duurtijd van alle activiteiten kleiner of gelijk is aan de werkelijke duurtijd van diezelfde activiteiten. In ons geval zal dit altijd waar zijn. Indien het project ten einde is, gaat de projectmanager naar stap 6. Stap 2: Moet de projectmanager het netwerk opnieuw evalueren? Indien er een nieuwe activiteit is die gekend wordt en zijn theoretische duurtijd is verschillend van zijn werkelijke duurtijd, dan gaat de projectmanager evalueren welke gevolgen dit heeft op het project. In dit geval zal de earliest start van de activiteiten en het kritische pad opnieuw worden berekend. De methode om de earliest start te berekenen, wordt grondig besproken in sectie De methode om het kritisch pad te berekenen, wordt besproken in sectie Stap 3: Is het project in gevaar? Op dit moment zal de projectmanager controleren of het project in gevaar is door ofwel een top-down controle uit te voeren met behulp van de EVM-methode (stap 3a) of een bottom-up controle uit te voeren met behulp van de SRA-methode (stap 3b). Stap 3a: Geeft het top-down trackingproces een waarschuwing? In deze stap berekent de projectmanager de SPI(t)-waarde. De gebruikte methode hiervoor wordt uitgebreid beschreven in sectie Indien deze waarde onder de vooraf gespecificeerde drempelwaarde valt, dan krijgt de projectmanager een waarschuwing. Indien hij een waarschuwing krijgt, gaat hij naar stap 4. Anders onderneemt hij geen actie en gaat hij terug naar stap 1. Stap 3b: Geeft het bottom-up trackingproces een waarschuwing? Indien de werkelijke duurtijd van het project groter wordt dan de theoretisch verwachte duurtijd, dan zal de projectmanager overgaan naar stap 5. In deze stap wordt er gecorrigeerd om het project terug op schema te brengen. Indien er echter geen waarschuwing wordt gegenereerd tijdens het bottom-up trackingproces dan onderneemt hij geen actie en gaat hij terug naar stap 1. Stap 4: Moet er actie ondernomen worden? In deze stap controleert de projectmanager of de duurtijd van het project op het moment van tracken effectief groter is dan wat volgens het plan werd vooropgesteld. Enkel wanneer dit het geval is, gaat hij correctieve acties ondernemen waarbij hij de mogelijkheid heeft om de activiteit ofwel te crashen (stap 5a) ofwel te fasttracken (stap 5b). Indien de werkelijke duurtijd nog altijd aangeeft dat het project op tijd is, zal de projectmanager niet ingrijpen en gaat hij terug naar 38

48 stap 1. Stap 5: Correctieve actie toepassen In deze stap zal de projectmanager een correctieve actie toepassen op één van de activiteiten. Het selecteren van de activiteiten die in aanmerking komen om te corrigeren hangt in sterke mate af van welk type trackingproces er zal worden gebruikt, namelijk een top-down of een bottom-up trackingproces. Dit wordt verder uitgelegd in sectie Nadat de optimale activiteit geselecteerd is, kan de projectmanager kiezen uit twee correctieve acties; namelijk crashen of fasttracken. Stap 5a: Correctieve actie crashen toepassen In deze stap heeft de projectmanager beslist om de activiteit te crashen zodat de duurtijd van de geselecteerde activiteit wordt gereduceerd. De projectmanager blijft activiteiten selecteren en crashen, totdat er geen meer zijn of totdat de totale werkelijke duurtijd van het project kleiner of gelijk is aan de totale geplande duurtijd van het project. Deze methode van crashen wordt uitgebreid beschreven in sectie Nadat deze stap is uitgevoerd, wordt er teruggegaan naar stap 1. Stap 5b: Correctieve actie fasttracken toepassen In deze stap heeft de projectmanager beslist om de activiteit te fasttracken. In dit geval zullen twee seriële activiteiten gedeeltelijk met elkaar overlappen met als doel de totale werkelijke duurtijd van het project te verminderen totdat deze weer kleiner is of gelijk aan de geplande duurtijd. De projectmanager blijft dit doen totdat er geen opties meer zijn om te fasttracken of zijn doel bereikt is en het project weer op tijd is. Deze methode wordt uitgebreid beschreven in sectie Nadat deze stap is uitgevoerd, wordt er terguggegaan naar stap 1. Stap 6: Einde van project Het volledige project is ten einde en de projectmanager besluit om de resultaten bij te houden voor toekomstige analyse. 39

49 4.2.2 Berekening earliest start Algoritme 1 earliest start 1: Algmeen: ES i = max (ES i ; ES voorganger + Duurtijd voorganger ) 2: if Crashen then 3: ES i = max (ES i ; ES voorganger + Duurtijd voorganger #Crash voorganger ) 4: if Fasttracken then 5: ES i = max (ES i ; ES voorganger + Duurtijd voorganger + #Rework voorganger #F asttrack i ) In deze methode wordt voor elke activiteit de earliest start (ES) berekend. Hierbij gebruiken we formule 4.1, formule 4.2 of formule 4.3, waarbij i de activiteit voorstelt waarvan we de ES wensen te berekenen en voorganger alle activiteiten voorstelt, die rechtsreeks voorafgaan aan activiteit i. Verder stelt #Crash en #Fasttrack het aantal eenheden voor dat de activiteit gecrasht dan wel gefasttrackt is en in het geval dat de activiteit werd gefasttrackt stelt #Rework het aantal eenheden rework voor horende bij deze specifieke activiteit. Algemeen algoritme: ES i = max (ES i ; ES voorganger + Duurtijd voorganger ) (4.1) Algoritme bij correctieve actie crashen: ES i = max (ES i ; ES voorganger + Duurtijd voorganger #Crash voorganger ) (4.2) Voorbeeld: Veronderstel volgende gegevens: activiteit 29 heeft een duurtijd van 4, een ES van 25 en deze activiteit werd reeds voor één eenheid gecrasht. Activiteit 29 wordt beschouwd als de enige directe voorganger van activiteit 30. Voor activiteit 30 wensen we nu de ES te berekenen. Deze gegevens worden voorgesteld in figuur 4.2. Deze figuur toont de originele status van het projectnetwerk waarbij de correctieve actie crashen in het rood is aangeduid. Deze correctieve actie werd echter nog niet in rekening gebracht bij de berekening van de ES van activiteit 30. Figuur 4.2: Voorbeeld earliest start bij crashen stap 1 40

50 Figuur 4.3 toont het effect op de ES van activiteit 30 indien we de correctieve actie crashen wel in rekening brengen. Het crashen van activiteit 29 zal immers tot gevolg hebben dat activiteit 30 één eenheid vroeger kan starten en de ES aldus gelijk is aan 28 in plaats van 29. Figuur 4.3: Voorbeeld earliest start bij crashen stap 2 Algoritme bij correctieve actie fasttracken: ES i = max (ES i ; ES voorganger + Duurtijd voorganger + #Rework voorganger #F asttrack i ) (4.3) Voorbeeld: Veronderstel activiteit 29 die een duurtijd heeft van 3 en die reeds werd gefasttrackt waardoor in dit geval de hoeveelheid rework gelijk is aan 1. We wensen voor activiteit 30 de ES te berekenen en deze activiteit is tevens gefasttrackt voor 1 eenheid. We stellen de gegevens voor aan de hand van figuur 4.4. Hierbij is de rework (groen) van activiteit 29 aangeduid op de figuur, maar nog niet in rekening gebracht bij de berekening van de ES van activiteit 30. Verder is er ook nog geen rekening gehouden met de hoeveelheid fasttracking van activiteit 30. Figuur 4.4: Voorbeeld earliest start bij fasttracken stap 1 Vanaf het moment dat we rework in rekening brengen krijgen we volgend netwerk en is de ES van activiteit 30 gelijk aan 29 in plaats van

51 Figuur 4.5: Voorbeeld earliest start bij fasttracken stap 2 In het geval dat we activiteit 30 fasttracken met bijvoorbeeld 1 eenheid, geldt de finish-start relatie niet meer en wordt de ES van activiteit 30 terug gelijk aan 28. Dit zien we in figuur 4.6 Figuur 4.6: Voorbeeld earliest start bij fasttracken stap 3 Dit resultaat kan ook worden bekomen aan de hand van formule Berekening kritisch pad Algoritme 2 kritische pad 1: Voorwaartse stap: zie algoritme 1 2: Achterwaartse stap: 3: Start 4: Algemeen: LS i = LS j Duurtijd i 5: if Crashen then 6: LS i = LS j (Duurtijd i #Crash i ) 7: if Fasttracken then 8: LS i = LS j (Duurtijd i + #Rework i ) 9: Stop 10: Bepalen kritische activiteit: 11: Start 12: if ES=LS then 13: Activiteit is kritisch 14: else Activiteit is niet kritisch 15: Stop Bij deze methode om het kritische pad te berekenen maken we gebruik van het algoritme dat beschreven wordt in een studie van Guerriero & Talarico (2010). Deze methode is gebaseerd op het feit dat een activiteit kritisch is als en slechts als de earliest start (ES) van de activiteit gelijk is aan de latest start (LS) van die activiteit en bijgevolg de slack gelijk is aan nul. De ES 42

52 van een activiteit is het moment waarop een activiteit ten vroegste kan starten. De LS van een activiteit is het laatst mogelijke tijdstip dat een activiteit van start kan gaan zonder dat dit een impact heeft op de werkelijke duurtijd van het project. We berekenen de ES in een voorwaartse stap en de LS in een achterwaartse stap. Voorwaartse stap: In deze stap berekenen we de ES van de activiteiten. Het algoritme dat we hiervoor gebruiken, werd reeds beschreven in sectie Achterwaartse stap: In de achterwaartse stap is het de bedoeling om de latest start van elke activiteit te achterhalen. We gebruiken hiervoor het volgende algoritme: Stap 1: Berekening earliest finish van het project In deze stap trachten we de earliest finish van het project te achterhalen. Hiervoor worden eerst de activiteiten zonder directe opvolgers bekeken. De earliest finish van deze activiteiten wordt berekend door de duurtijd op te tellen bij de earliest start. Het maximum van deze waarden is gelijk aan de earliest finish van het totale project. Hierdoor weten we wanneer het project op zijn vroegst gedaan kan zijn alsook de latest finish van alle activiteiten zonder directe opvolgers. Stap 2: Berekening latest start van de activiteiten In deze stap vertrekken we van de latest finish uit stap 1. Aan de hand van deze latest finish en de duurtijd van elke activiteit zullen wij in staat zijn om de latest start van elke activiteit te achterhalen. De latest start van de beschouwde activiteit dient dan weer als latest finish van zijn voorgangers en zo worden de berekeningen herhaald totdat de latest start van elke activiteit bekend is. Stel dat activiteit j volgt op activiteit i, dan maken we gebruik van onderstaande formules 4.4, 4.5 en 4.6 waarbij #crash i staat voor het aantal eenheden dat we activiteit i gecrasht hebben en #rework i staat voor het aantal eenheden rework ten gevolge van de correctieve actie fasttracken toegepast op activiteit i. Algemeen: Crashen: LS i = LS j Duurtijd i (4.4) LS i = LS j (Duurtijd i #Crash i ) (4.5) 43

53 Fasttracken: LS i = LS j (Duurtijd i + #Rework i ) (4.6) Voorbeeld: Algemeen Veronderstel een netwerk zoals afgebeeld in figuur 4.7. In dit netwerk heeft activiteit 30 een ES van 27. Indien we de LS berekenen dan bekomen we voor activiteit 30 een LS van 28. Omdat voor activiteit 30 de LS niet gelijk is aan de ES betekent dit dat activiteit 30 niet kritisch is. We zien dit duidelijk op de figuur, namelijk indien we activiteit 30 zouden starten op tijdstip 28 zal dit geen impact hebben op de ES van activiteit 31 en aldus op de totale duurtijd van het project. Figuur 4.7: Voorbeeld kritisch pad Voorbeeld: Crashen Veronderstel een netwerk zoals afgebeeld in figuur 4.8. Hierbij is gegeven dat activiteit 31 een LS heeft van 30 en verder werd activiteit 30 voor één eenheid gecrasht. Deze hoeveelheid crashing is aangeduid in het rood en werd in figuur 4.8 dus nog niet in rekening gebracht. De totale duurtijd voor het toepassen van de correctieve actie was gelijk aan 3 en zal na het toepassen van de correctieve actie gereduceerd worden tot 2. Figuur 4.8: Voorbeeld kritisch pad bij crashen Indien we nu willen weten of activiteit 30 al dan niet kritisch is, dan zal er eerst en vooral moeten worden berekend wat de ES is voor deze activiteit. De ES van activiteit 30 is gelijk aan 27. Door vervolgens gebruik te maken van formule 4.5 om de LS te berekenen dan krijgen we volgende oplossing: 44

54 LS act30 = 30 (3 1) = 28 (4.7) Bijgevolg kunnen we concluderen dat activiteit 30 niet kritisch is aangezien de ES verschillend is van de LS en aldus de slack niet gelijk is aan nul. Voorbeeld: Fasttracken Veronderstel een netwerk zoals voorgesteld in figuur 4.9. Hierbij werd activiteit 30 reeds gefasttrackt waardoor deze activiteit ook 1 eenheid rework heeft. Verder is uit voorgaande berekeningen gebleken dat de earliest start van activiteit 31 gelijk is aan 30. De hoeveelheid rework werd in de figuur aangeduid in het groen en op deze manier werd de rework al in rekening gebracht als onderdeel van de totale duurtijd van activiteit 30. Figuur 4.9: Voorbeeld kritisch pad bij fasttracken Indien we nu willen weten of activiteit 30 kritisch is, dan zal er eerst moeten worden berekend hoeveel de ES bedraagt. De ES van activiteit 29 is gelijk aan 25. Door vervolgens gebruik te maken van formule 4.6 om de latest start te berekenen, krijgen we volgende oplossing: LS act30 = 30 (2 + 1) = 27 (4.8) We kunnen dus concluderen dat activiteit 30 niet kritisch is aangezien de earliest start verschillend is van de LS en aldus de slack niet gelijk is aan nul Berekening van SPI(t) De SPI(t)-waarde zal worden berekend en gebruikt als onderdeel van het top-down trackingproces. Voor de berekening van de SPI(t) hebben we gebruik gemaakt van de formules 3.1 en 3.2 zoals beschreven in sectie Aangezien bij de berekening van de earned schedule moet worden voldaan aan P V t EV < P V t+1 zal op voorhand de planned value worden berekend voor verschillende tijdstippen. Vervolgens zal, gedurende elke trackingperiode, de earned value worden berekend en op basis hiervan de juiste planned values worden geselecteerd om de earned schedule te berekenen. De earned value op tijdstip t wordt berekend aan de hand van formule 45

55 4.9, waarbij er gesommeerd wordt over alle activiteiten en het Percentage gedaan i,t gelijk is aan het percentage van activiteit i dat op tijdstip t reeds is voltooid en kost i gelijk is aan de totale kost van de activiteit i. Voorbeeld Earned value t = Σ(P ercentage gedaan i,t kost i ) (4.9) Veronderstel een netwerk gekarakteriseerd door volgende waarden: Activiteit Earliest start Duurtijd Totale kost Tabel 4.2: Baseline schedule Indien we op basis hiervan de planned values berekenen voor dit project krijgen we volgende tabel: Tijdstip PV Tabel 4.3: Planned values Aan de hand van deze tabel PV-waarden kan er dan voor elke EV-waarde de juiste twee PV-waarden worden geselecteerd, namelijk P V t en P V t+1, waarvoor geldt dat: EV P V t en EV< P V t+1. Veronderstel nu een bepaald simuleringstijdstip, waarbij de EV gelijk is aan 8. Dan vinden we voor P V t de waarde 8 op tijdstip 4 en voor P V t+1 de waarde 10 op tijdstip 5. Hiermee kunnen we dan de ES berekenen: ES = 4 + (8 8) (10 8) = 4 (4.10) Dit geeft dan een SPI(t) van: SP I(t) = 4 4 = 1 (4.11) Wanneer de SPI(t) een waarde heeft gelijk aan 1, dan betekent dit dat het project verondersteld wordt op tijd te eindigen. In het geval dat het project echter een vertraging heeft opgelopen en op tijdstip 4 de EV slechts 7 bedraagt dan wordt P V t 6 en P V t+1 8 waarbij t gelijk is aan 3 en bijgevolg t+1 gelijk is aan 4. 46

56 Hiermee kunnen we dan de ES berekenen: ES = 3 + (7 6) = 3, 5 (4.12) (8 6) Dit geeft dan een SPI(t) van: Correctieve Acties SP I(t) = 3, 5 4 = 0, 875 (4.13) Algoritme 3 toepassing correctieve acties 1: if Crash then 2: W erkelijke Duurtijd i = Duurtijd i #Crash i 3: if Fasttrack then 4: #Rework i = #F asttrack i P ercentage Rework 5: ES i = ES i #F asttrack i 6: W erkelijke Duurtijd i = Duurtijd i + #Rework i In dit onderdeel worden de algoritmes beschreven die zullen worden gebruikt voor het toepassen van de correctieve acties: crashen en fasttracken. Vooraleer we de correcties kunnen uitvoeren, moeten er eerst een aantal zaken in rekening worden gebracht. Aangezien we het corrigeren van een activiteit hebben gelimiteerd zoals besproken in sectie 3.2.3, moet er in eerste instantie worden bijgehouden hoeveel we elke activiteit mogen crashen of fasttracken. De gebruikte algoritmes hiervoor worden uitgebreid besproken in sectie Hierna dient er worden te achterhaald welke activiteit de optimale is om een correctie op toe te passen. Hiervoor moeten een aantal stappen worden doorlopen zoals vermeld in sectie De algoritmes die we hiervoor zullen gebruiken, worden uitgebreid besproken in sectie Wanneer de optimale activiteit werd geïdentificeerd, zal deze activiteit eenmaal worden gecrasht in het ene scenario en eenmaal worden gefasttrackt in het andere scenario. Telkens wanneer een activiteit gecorrigeerd is met één eenheid moet er worden geanalyseerd welk effect dit heeft op het netwerk. Wij zullen telkens de earliest start van alle activiteiten en het kritische pad herberekenen. Hiervoor gebruiken we de reeds behandelde methoden zoals besproken in sectie en Correctieve actie crashen Deze correctieve actie zorgt ervoor dat de duurtijd van een activiteit wordt gereduceerd. Het reduceren van de duurtijd van een activiteit kan een impact hebben op de earliest start van sommige activiteiten in het netwerk. Het veranderen van de earliest start van sommige activiteiten (voornamelijk deze op het kritische pad) zal dan weer een impact hebben op de totale duurtijd 47

57 van het netwerk. We berekenen de werkelijke duurtijd van een activiteit i op de volgende manier: W erkelijke Duurtijd i = Duurtijd i #Crash i (4.14) Voorbeeld Veronderstel een netwerk bestaande uit drie activiteiten en waarbij uit voorgaande berekeningen is gebleken dat activiteit 2 moet moet worden gecrasht met 1 eenheid. De situatie voor het toepassen van de correctieve actie is zoals afgebeeld in figuur Figuur 4.10: Voorbeeld netwerk voor correctieve actie crashen Wanneer we de correctieve actie toepassen, krijgen we volgend netwerk: Figuur 4.11: Voorbeeld netwerk na correctieve actie crashen Aan de hand van formule 4.14 bekomen we een werkelijke duurtijd voor activiteit 2 van: W erkelijke Duurtijd act2 = 3 1 = 2 (4.15) Correctieve actie fasttracken Bij dit type correctieve actie wordt de duurtijd van een activiteit niet aangepast, maar er verandert wel iets aan de earliest start van de activiteit zelf en de activiteiten die erop volgen. Het fasttracken van een activiteit kan eveneens tot gevolg hebben dat er een bepaalde hoeveelheid rework optreedt. In ons voorbeeld zullen we werken met 50% rework. Hier is het wel belangrijk op te merken dat er een assumptie wordt gemaakt met betrekking tot de berekening van de hoeveelheid rework. We laten de hoeveelheid rework immers niet lineair 48

58 toenemen maar hebben ervoor gekozen om met een getrapte functie te werken zoals weergegeven in formule Voorbeeld #Rework i = #F asttrack i P ercentage Rework (4.16) Indien er een percentage rework van 50% wordt gedefinieerd, dan zullen de volgende waarden worden bekomen voor een bepaalde hoeveelheid fasttracking. #Fasttrack #Rework Tabel 4.4: Rework in functie van aantal eenheden fasttracking Indien we activiteit i fasttracken voor #F asttrack i eenheden, dan zal deze activiteit zoveel eenheden naar voren worden geschoven in het project en zal bijgevolg de ES van de activiteit wijzigen. We berekenen deze ES op de volgende manier: ES i = ES i #F asttrack i (4.17) De werkelijke duurtijd van die activiteit verandert ook en wordt op de volgende manier berekend: W erkelijke Duurtijd i = Duurtijd i + #Rework i (4.18) Voorbeeld In figuur 4.12 staat een netwerk afgebeeld waar nog geen correctieve actie op werd toegepast. In dit voorbeeld zullen we activiteit 2 fasttracken voor 2 eenheden. Figuur 4.12: Voorbeeld netwerk voor correctieve actie fasttracken Indien we activiteit 2 met 2 eenheden wensen te fasttracken dan zal er door het percentage rework van 50% 1 eenheid rework worden gerealiseerd. De earliest start van activiteit 2 wijzigt 49

59 op onderstaande manier: ES act2 = 4 2 = 2 (4.19) De werkelijke duurtijd wordt dan: W erkelijke Duurtijd act2 = = 5 (4.20) Dit geeft dan het resultaat zoals afgebeeld in 4.14, waarbij de rework in het groen werd aangeduid: Figuur 4.13: Voorbeeld netwerk na correctieve actie fasttracken Bepalen maximum hoeveelheid correctie Algoritme 4 maximum hoeveelheid correctie 1: if Crash then 2: Geval 1: Activiteit niet gekend en niet begonnen 3: Maximum Crash i = Duurtijd i CrashP ercentage 4: Geval 2: Activiteit is gekend maar nog niet gedaan 5: Maximum Crash i = (ES i + Duurtijd i Simuleringstijdstip) CrashP ercentage 6: if Fasttrack then 7: Stap 1: 8: Maximum Overlap i = Duurtijd i P ercentageoverlap 9: Stap 2: 10: Maximum Overlap voorganger = (Duurtijd voorganger + #Rework voorganger ) 11: P ercentageoverlap + Slack voorganger 12: Slack voorganger = LatestStart voorganger EarliestStart voorganger 13: Stap 3: 14: if Earliest Start i Maximum Hoeveelheid Overlap i T ijdstip > 0 then 15: Maximum Hoeveelheid Overlap i = min (Maximum Overlap stap1, Maximum Overlap stap2) 16: else Maximum Hoeveelheid Overlap i = Earliest Start i T ijdstip Maximum hoeveelheid crashen De maximum hoeveelheid waarvoor een activiteit kan worden gecrasht, wordt op voorhand vastgelegd via een bepaald crash-percentage en is hetzelfde voor alle activiteiten ongeacht hun duurtijd. In de volgende voorbeelden zullen we een crash-percentage van 50% veronderstellen. 50

60 De maximum hoeveelheid waarvoor we een activiteit kunnen crashen, kan echter toch nog verschillen in twee gevallen: Geval 1: Activiteit is nog niet gekend en nog niet begonnen In het eerste geval is de activiteit nog niet gekend en wordt de geplande duurtijd van de activiteit vermenigvuldigd met het crash-percentage om te berekenen hoeveel eenheden er maximaal kunnen worden gecrasht. Maximum Crash i = Duurtijd i Crash P ercentage (4.21) Voorbeeld Stel we hebben een activiteit met duurtijd 10. Voor deze activiteit zullen er in totaal maximaal 5 eenheden kunnen worden gecrasht. Geval 2: Activiteit is gekend en al begonnen maar nog niet gedaan In het tweede geval is de activiteit reeds gestart. We laten echter nog steeds toe dat de activiteit kan worden gecrasht, maar enkel voor het stuk dat nog niet is uitgevoerd. Om te berekenen voor hoeveel eenheden de activiteit nog mag worden gecorrigeerd, moeten er nog een paar gegevens in rekening worden gebracht zoals het huidige simuleringstijdstip, de earliest start van de activiteit en de duurtijd. Aan de hand hiervan kan de maximum hoeveelheid berekend worden met behulp van formule 4.22 : Maximum Crash i = (ES i + Duurtijd i Simuleringstijdstip) Crash P ercentage (4.22) Voorbeeld Veronderstel een activiteit met duurtijd 10, een ES van 10 en op dit moment is de simuleringstijd gelijk aan 12. Via het toepassen van formule 4.22, zal er in dit geval nog maximum voor 4 eenheden worden gecrasht. Maximum Crash = ( ) 0, 50 = 4 (4.23) Maximum hoeveelheid fasttracken De maximum hoeveelheid waarvoor een activiteit kan worden gefasttrackt, wordt bepaald door de hoeveelheid die wordt toegestaan om te overlappen. Dit percentage wordt, net zoals bij crashen, op voorhand vastgelegd via een bepaald overlap-percentage. In de volgende voorbeelden zullen we een overlap-percentage van 50% veronderstellen. Algemeen wordt de maximum hoeveelheid overlap berekend via volgend algoritme: 51

61 Stap 1: Bereken voor de te fasttracken activiteit i de maximum hoeveelheid overlap Maximum Overlap i = Duurtijd i P ercentage Overlap (4.24) Stap 2: Bereken voor de directe voorgangers van activiteit i de maximum hoeveelheid overlap Maximum Overlap voorganger = (Duurtijd voorganger + #Rework voorganger ) P ercentage Overlap + Slack voorganger (4.25) Met: Slack voorganger = LatestStart voorganger EarliestStart voorganger (4.26) Hier is het belangrijk om op te merken dat rework enkel in beschouwing wordt genomen bij de berekening van de maximale hoeveelheid overlap van de directe voorgangers. De hoeveelheid rework wordt niet beschouwd bij het berekenen van de maximale hoeveelheid overlap van de activiteit die uiteindelijk zal worden gefasttrackt. Stap 3: Bereken de uiteindelijke maximum hoeveelheid overlap In deze stap wordt een nieuwe variabele aangemaakt; namelijk de Maximum Hoeveelheid Overlap van activiteit i. Deze variabele krijgt een waarde toegekend die verkregen wordt door het minimum te nemen van de waarden voor de Maximum Overlap berekend in stap 1 en stap 2. Maximum Hoeveelheid Overlap i = min (Maximum Overlap stap1, Maximum Overlap stap2) (4.27) Stap 4: Indien simuleringstijdstip gelijk is aan t moet er worden gecontroleerd dat: Earliest Start i Maximum Hoeveelheid Overlap i T ijdstip > 0 (4.28) Indien voorgaande vergelijking groter blijkt te zijn dan 0 gebeurt er niets in deze vierde stap. Indien dit echter niet het geval is, wordt de Maximum Hoeveelheid Overlap aangepast volgens onderstaande formule: Maximum Hoeveelheid Overlap i = Earliest Start i T ijdstip (4.29) In het volgende stuk zal er aan de hand van voorbeelden worden aangetoond hoe dit algoritme voor alle mogelijke gevallen, die zich kunnen voordoen, exact in zijn werk gaat. Voorbeeld 1: Effect van de duurtijd van een activiteit op de maximum toegelaten hoeveelheid 52

62 om te fasttracken Veronderstel de situatie zoals voorgesteld in figuur Hierbij is de duurtijd van activiteit 1 gelijk aan 5 en de duurtijd van activiteit 2 gelijk aan 2. Bijkomend wordt activiteit 2 beschouwd als de meest optimale activiteit om te fasttracken. Figuur 4.14: Voorbeeld effect duurtijd activiteit op zijn maximum hoeveelheid fasttracking Stap 1: Stap 2: Stap 3: Maximum Overlap act2 = 2 50% = 1 (4.30) Maximum Overlap act1 = 5 50% = 2, 50 (4.31) Maximum Hoeveelheid Overlap act2 = min (1; 2, 50) = 1 (4.32) Dit betekent dat we activiteit 2 slechts voor maximum 1 eenheid kunnen fasttracken. beperking is voornamelijk te wijten aan de grootte van zijn eigen duurtijd. Deze Voorbeeld 2: Effect van de voorgaande activiteiten op de maximum toegelaten hoeveelheid om te fasttracken Het kan echter ook optreden dat de maximum toegelaten hoeveelheid om te fasttracken wordt beperkt door de voorgaande activiteit, zoals in dit voorbeeld het geval zal zijn. De duurtijd van activiteit 1 is nu gelijk aan 3 en de duurtijd van activiteit 2 is gelijk aan 4. Dit netwerk wordt voorgesteld in figuur 4.15 Figuur 4.15: Voorbeeld effect duurtijd voorgangers op maximum hoeveelheid fasttracking Stap 1: Maximum Overlap act2 = 4% = 2 (4.33) 53

63 Stap 2: Stap 3: Maximum Overlap act1 = 3 50% = 1, 50 (4.34) Maximum Hoeveelheid Overlap act2 = min (2; 1, 50) = 1, 50 (4.35) Uit voorgaande berekeningen blijkt dat activiteit 2 slechts voor maximum 1,50 eenheden kan worden gefasttrackt. In dit geval is de duurtijd van de voorgaande activiteit hiervoor de beperkende factor. Voorbeeld 3: Effect van slack op de maximum toegelaten hoeveelheid om te fasttracken De situatie zoals voorgesteld in figuur 4.16 kan eveneens optreden. Veronderstel een netwerk van activiteiten waarbij activiteit 0 geen kritische activiteit is, maar wel één van de voorgangers van de kritische activiteit 2. Verder heeft activiteit 0 een earliest start van 0 en een duurtijd van 3. We willen vervolgens achterhalen voor hoeveel eenheden we activiteit 2 kunnen fasttracken. Figuur 4.16: Voorbeeld effect van slack op maximum hoeveelheid fasttracking Stap 1: Maximum Overlap act2 = 3 50% = 1, 50 (4.36) Stap 2: Maximum Overlap act0 = 3 50% + 2 = 3, 50 Maximum Overlap act1 = 5 50% = 2, 50 (4.37) Stap 3: Maximum Hoeveelheid Overlap act2 = min (1, 50; 2, 50; 3, 50) = 1, 50 (4.38) Dit betekent dat we activiteit 2 maximum voor 1,50 eenheden kunnen fasttracken, ook hier is de beperkende factor zijn eigen duurtijd. Belangrijk is dat we bij de berekening van de Maximum Overlap van activiteit 0 rekening hebben gehouden met zijn hoeveelheid slack, in dit voorbeeld gelijk is aan 2. Bij het overlappen mag een bepaalde hoeveelheid slack sowieso worden overbrugd. We limiteren immers enkel de overlap met de voorgaande activiteit zelf en dus niet met zijn hoeveelheid slack. 54

64 Voorbeeld 4: Effect van rework op maximum toegelaten hoeveelheid om te fasttracken Veronderstel een netwerk zoals in figuur Activiteit 1 heeft een duurtijd van 2 en is reeds gefasttrackt waardoor er nog eens 1 eenheid rework nodig was om activiteit 1 af te werken. Activiteit 2 heeft een duurtijd van 3 en is de activiteit waarvan we de maximum toegelaten hoeveelheid om te fasttracken willen berekenen. Figuur 4.17: Voorbeeld effect van rework op maximum hoeveelheid fasttracking Stap 1: Stap 2: Stap 3: Maximum Overlap act2 = 3 50% = 1, 50 (4.39) Maximum Overlap act1 = (2 + 1) 50% = 1, 50 (4.40) Maximum Hoeveelheid Overlap act2 = min (1, 5; 1, 5) = 1, 50 (4.41) Uit voorgaande berekeningen blijkt dat we activiteit 2 maximum voor 1,50 eenheden kunnen fasttracken. Indien de hoeveelheid rework van activiteit 1 niet in rekening was gebracht, dan zou de maximum hoeveelheid overlap maar 1 eenheid bedragen. Bij de berekening van de maximum toegelaten hoeveelheid om te fasttracken zullen we dus wel rekening houden met de rework van de voorgaande activiteiten. In het geval dat activiteit 2 reeds een bepaalde hoeveelheid rework had opgelopen, zal deze hoeveelheid rework echter niet in beschouwing worden genomen bij de berekening van de maximum toegestane overlap. Voorbeeld 5: Effect van simuleringstijd op maximum toegelaten hoeveelheid om te fasttracken In dit geval hebben we een netwerk zoals in figuur We veronderstellen dat het trackingproces zich op simuleringstijd 4 bevindt en er 2 activiteiten aanwezig zijn. Activiteit 1 heeft een ES van 0 en een duurtijd van 5. Activiteit 2 daarentegen heeft een ES van 5, een duurtijd van 3 en is tevens de optimale activiteit om te fasttracken. 55

65 Figuur 4.18: Voorbeeld effect van rework op maximum hoeveelheid fasttracking Stap 1: Stap 2: Stap 3: Stap 4: Maximum Overlap act2 = 50% 3 = 1, 50 (4.42) Maximum Overlap act1 = 50% 5 = 2, 50 (4.43) Maximum Hoeveelheid Overlap act2 = min (1, 50; 2, 50) = 1, 50 (4.44) controle : (5 1, 50) 4 < 0 (4.45) Maximum Hoeveelheid Overlap act2 = (5 4) = 1 (4.46) Om te vermijden dat een activiteit wordt gefasttrackt naar een tijdstip in het verleden zal er telkens een controle worden uitgevoerd waarbij de simuleringstijd expliciet in beschouwing wordt genomen. In deze situatie zal activiteit 2 daardoor slechts voor maximum 1 eenheid kunnen worden gefasttrackt, hierbij is de beperkende factor aldus de simuleringstijd. 56

66 4.2.7 Bepalen optimale activiteit Algoritme 5 bepalen optimale activiteit 1: if Bottom-up trackingproces then 2: Stap 1: Vastleggen drempelwaarde 3: Stap 2: Selectie activiteiten 4: if Top-down trackingproces then 5: if geen parallel kritisch pad then 6: Stap 1: Selecteer alle kritische activiteiten 7: Stap 2: Selecteer activiteiten die we nog voor 1 eenheid kunnen corrigeren 8: Stap 3: Selecteer de activiteit met de laagste kost per eenheid 9: Stap 4: Corrigeer die activiteit 10: else parallel kritisch pad 11: Stap 1: Zoek alle parallelle kritische paden 12: Stap 2: Vergelijk 2 parallelle takken 13: W erkelijke T otale Kost ij = min (kp e l ) + min (kp e m ) 14: Stap 3: Bereken samengestelde kost van het parallelle pad 15: Samengestelde Kost k = max (kp e k ; W erkelijke T otale Kost ij ) 16: Stap 4: Selecteer uit alle kritische activiteiten de activiteit met de laagste samengestelde kost 17: if Meer dan 1 activiteit met laagste samengestelde kost then 18: Selecteer de activiteit met de laagste werkelijke kost 19: Stap 6: Corrigeer die activiteit Selectie van de optimale activiteit bij een bottom-up trackingproces Wanneer de projectmanager het project wenst op te volgen aan de hand van een bottom-up trackingproces door middel van een SRA-analyse zal een aantal activiteiten worden geselecteerd met een relatief hoge sensitiviteit. Deze activiteiten komen vervolgens in aanmerking voor correctieve acties. Het bepalen van de activiteiten, die deel zullen uitmaken van deze subset, gebeurt op basis van de SSI-waarde. De activiteiten worden namelijk gesorteerd volgens dalende SSI-waarde en de activiteiten met dezelfde SSI-waarde worden nogmaals gesorteerd volgens stijgende kost. De selectie van de te controleren activiteiten gebeurt aldus op volgende manier: Stap 1: Vastleggen drempelwaarde Veronderstel een SSI-drempelwaarde waarbij 25% van de activiteiten deel uitmaakt van de subset. Deze subset zal door de projectmanager moeten worden gecontroleerd en gecorrigeerd. Stap 2: Selectie activiteiten Vervolgens selecteren we effectief de activiteiten die deel zullen uitmaken van de subset. De activiteiten worden geordend volgens dalende SSI-waarde en bij gelijke SSI-waarden volgens stijgende kost. Nadien zullen er op basis van deze ordening activiteiten worden geselecteerd totdat zich in de subset exact 25% van alle activiteiten bevinden. 57

67 Voorbeeld: Veronderstel een netwerk bestaande uit volgende activiteiten met bijhorende kost en een SSIwaarde zoals weergegeven in tabel 4.5. We definiëren een drempelwaarde waarvoor 25% van de activiteiten deel moet uitmaken van de subset. Activiteit SSI-waarde Kost per eenheid , , , , , ,2 3 Tabel 4.5: Voorbeeld selectie activiteiten bij SRA Bij het creëeren van de subset zal eerst activiteit 7 worden geselecteerd aangezien deze de hoogste SSI-waarde heeft van alle activiteiten. Vervolgens zullen, indien men louter op basis van de SSIwaarde zou selecteren, zowel activiteit 2 als activiteit 6 in aanmerking komen. Alleen activiteit 6 zal echter worden opgenomen als onderdeel van de subset aangezien deze de laagste kost per eenheid heeft. Door activiteit 2 en 7 te selecteren als kandidaten voor eventuele correctieve acties wordt een subset bekomen van exact 25% van de activiteiten. Selectie van de optimale activiteit bij een top-down trackingproces Wanneer de projectmanager het project wenst op te volgen aan de hand van een top-down trackingproces door middel van de EVM-methode zal telkens de activiteit worden geselecteerd die zowel kritiek is alsook de laagste kost per eenheid heeft. Op deze manier zal het project op de meest kostenefficiënte manier terug op schema worden gebracht. We veronderstellen dat de kost om een activiteit met 1 eenheid te corrigeren dezelfde is als de kost per eenheid van de activiteit zelf. De selectie van de optimale activiteit zal afhangen van het feit of er al dan niet een parallel kritisch pad aanwezig is in het projectnetwerk. Met parallelle kritische paden bedoelen we twee of meer paden die parallel lopen en waarbij elk pad kritisch is. In wat volgt zal zowel het geval waarbij geen kritisch pad aanwezig is als het geval waarbij wel een kritisch pad aanwezig is nader worden toegelicht, alsook de manier waarop de activiteiten worden geselecteerd in elk van deze gevallen. 58

68 Geen parallel kritisch pad aanwezig Stap 1: Selecteer alle kritische activiteiten. Stap 2: Selecteer uit de verzameling activiteiten, bekomen in stap 1, alle activiteiten die nog voor 1 eenheid kunnen worden gecorrigeerd. Stap 3: Selecteer uit de verzameling activiteiten, bekomen in stap 2, de activiteit met de laagste kost per eenheid. Stap 4: Corrigeer de activiteit die in stap 3 werd geselecteerd. Parallel kritisch pad aanwezig Voorbeeld: Veronderstel een parallel kritisch pad zoals afgebeeld in figuur De activiteiten van deze parallelle paden hebben bijhorende kosten zoals vermeld in tabel 4.6. Het doel is om de volledige duurtijd van het netwerk met 1 eenheid te reduceren door middel van het crashen van activiteiten. Verder veronderstellen we dat alle activiteiten uit dit netwerk nog voor 1 eenheid kunnen worden gecorrigeerd. Dit betekent dat stap 1 en stap 2 van het voorgaand algoritme reeds werden uitgevoerd. Figuur 4.19: Voorbeeld parallel kritisch pad 59

69 Activiteit Kost per eenheid Tabel 4.6: Kosten voor netwerk met parallel pad Indien we stap 3 uit het voorgaande algoritme zouden toepassen dan zou activiteit 2 worden geselecteerd om te corrigeren aangezien deze activiteit de laagste kost heeft. Door de duurtijd van activiteit 2 met 1 eenheid te reduceren, wordt de volledige bovenste tak niet meer kritisch en blijft enkel volgend kritisch pad over: Figuur 4.20: Voorbeeld kritisch pad na correctieve actie Het toepassen van voorgaande correctieve actie zal geen onmiddellijke impact hebben op de totale duurtijd van het project. Er zal opnieuw een activiteit worden geselecteerd om te crashen. Op basis van voorgaand algoritme zal deze keer activiteit 4 worden geselecteerd om voor 1 eenheid te crashen tegen een totale kost van 4. Indien de projectmanager in dit geval de totale duurtijd van het project met 1 eenheid wenst te reduceren, dan zullen er op deze manier twee activiteiten moeten worden gecorrigeerd aan een totale kost van 6. Het is echter mogelijk om de totale duurtijd van dit netwerk op een goedkopere manier te verminderen. Indien namelijk activiteit 7 zou worden geselecteerd en gecorrigeerd, zou het mogelijk zijn om de totale duurtijd van dit netwerk met 1 eenheid te reduceren voor een totale kost gelijk aan 5. Het algoritme dat zal worden gebruikt indien er een parallel kritisch pad aanwezig is, zal dus op bepaalde punten afwijken van voorgaand stappenplan. Stap 1: Zoek alle parallelle kritische paden en hou bij welke activiteiten deel uitmaken van deze parallelle paden inclusief hun startactiviteit en eindactiviteit. Dit noemen we een tak van een parallel kritisch pad. Stap 2: 60

70 Vergelijk telkens twee takken van een parallel kritisch pad met elkaar zonder de startactiviteit en eindactiviteit van de paden in beschouwing te nemen. Aan de hand van deze twee takken wordt vervolgens de werkelijke totale kost berekend, door de minima van de kosten Per eenheid (kpe) van alle activiteiten per tak van het parallel pad te sommeren. Dit geeft volgende formule 4.47 waarbij telkens tak i en tak j, die beiden deel uitmaken van hetzelfde parallel kritisch pad, met elkaar worden vergeleken. De activiteiten l behoren tot tak i en activiteiten m behoren tot tak j. W erkelijke T otale Kost ij = min (kp e l ) + min (kp e m ) (4.47) Stap 3: Maak een nieuwe rij met de samengestelde kost van alle activiteiten uit het parallel pad. De samengestelde kost is het maximum van de kost van de activiteit en de werkelijke totale kost om een parallel kritisch pad te corrigeren. Dit geeft ons volgende formule waarbij we telkens de samengestelde kost van activiteit k berekenen en de activiteiten k deel kunnen uitmaken van tak i of tak j. Samengestelde Kost k = max (kp e k ; W erkelijke T otale Kost ij ) (4.48) Indien er meer dan 2 parallelle kritische paden zijn, dan is de samengestelde kost van elke activiteit gelijk aan het maximum van de samengestelde kosten van de individuele takken. Stap 4: Selecteer uit alle activiteiten, inclusief de start- en eindactiviteiten, de activiteit met de laagste samengestelde kost. Stap 5: Indien er meerdere activiteiten zijn met de laagste samengestelde kost wordt de activiteit met de laagste werkelijke kost geselecteerd. Stap 6: Corrigeer de activiteit die geselecteerd werd in stap 5. Voorbeeld 1: Toepassing algoritme op voorbeeld Veronderstel opnieuw hetzelfde parallel kritisch pad zoals in vorig voorbeeld. Stap 1: Er zijn 2 parallelle takken namelijk:

71 Stap 2: Eerst wordt het minimum van de kosten van de activiteiten van tak 1 berekend exclusief de start- en eindactiviteit: min (2; 3) = 2 (4.49) Hierna wordt het minimum van de kosten van de activiteiten van tak 2 berekend exclusief de start- en eindactiviteit: min (4; 5; 7) = 4 (4.50) Vervolgens wordt de werkelijke totale kost berekend door de minima op te tellen. Stap 3: W erkelijke T otale Kost 1,2 = = 6 (4.51) In tabel 4.7 worden de activiteiten, die deel uitmaken van het parallel kritisch pad met uitzondering van de start- en eindactiviteit, aangeduid in het vet en wordt er getoond hoe de samengestelde kost voor elke activiteit afzonderlijk kan worden berekend. De totale werkelijke kost is gelijk aan 6 zoals werd berekend in stap 2. Activiteit Samengestelde kost max (2; 6) = 6 3 max (3; 6) = 6 4 max (2; 6) = 6 5 max (5; 6) = 6 6 max (7; 6) = Tabel 4.7: Berekening samengestelde kost Stap 4: In deze stap wordt uit alle activiteiten de activiteit met de kleinste samengestelde kost geselecteerd. In dit geval is dit activiteit 7 met een samengestelde kost van 5. Stap 5: Aangezien er maar één activiteit is die de laagste samengestelde kost heeft, kan deze stap worden overgeslagen. 62

72 Stap 6: Activiteit 7 is de optimale activiteit en zal aldus worden gecorrigeerd. Voorbeeld 2: Toepassing algoritme op voorbeeld Veronderstel opnieuw hetzelfde parallel kritisch pad, maar in dit geval is de werkelijke kost van activiteit 7 gelijk aan 8. Tot en met stap 2 blijft alles hetzelfde. Stap 3: In tabel 4.8 worden de activiteiten, die deel uitmaken van het parallel kritisch pad met uitzondering van de start- en eindactiviteit, aangeduid in het vet en wordt er getoond hoe de samengestelde kost voor elke activiteit afzonderlijk kan worden berekend. De totale werkelijke kost is gelijk aan 6 zoals werd berekend in stap 2. Activiteit Samengestelde kost max (2; 6) = 6 3 max (3; 6) = 6 4 max (2; 6) = 6 5 max (5; 6) = 6 6 max (7; 6) = Tabel 4.8: Berekening samengestelde kost Stap 4: In deze stap wordt uit alle activiteiten de activiteit met de kleinste samengestelde kost geselecteerd. In dit geval zijn dit de activiteiten 1, 2, 3, 4 en 5 met elk een samengestelde kost van 6. Stap 5: Aangezien er nu meerdere activiteiten zijn met de laagste samengestelde kost, wordt uit deze verzameling de activiteit geselecteerd met de laagste werkelijke kost. In dit geval is dit activiteit 2. 63

73 Activiteit Samengestelde kost Werkelijke Kost Tabel 4.9: Selectie optimale activiteit Stap 6: In deze stap zal de duurtijd van activiteit 2 worden gereduceerd met 1 eenheid, waardoor het pad waarvan activiteit 2 deel uitmaakt niet meer kritisch is en er bijgevolg nog maar 1 kritisch pad overblijft. Op deze manier zal de totale duurtijd van het project echter nog steeds dezelfde zijn en zal er nogmaals moeten worden gecorrigeerd. We vinden dat activiteit 4 de nieuwe optimale activiteit is om te corrigeren. Aan de hand van dit algoritme zal er telkens worden verzekerd dat het totale project op de meest goedkope manier wordt gecorrigeerd. Het enige nadeel van dit algoritme is dat indien we activiteit 1 zouden corrigeren, er eveneens een totale kost van 6 wordt gerealiseerd. In dit geval hebben we echter maar één keer moeten ingrijpen in plaats van twee keer en dit kan bijgevolg een impact hebben op de tracking efficiency zoals gedefinieerd in sectie 5.1. Los van het feit of er één of meerdere keren moet worden ingegrepen, zal dit algoritme wel altijd een oplossing geven die even optimaal is of optimaler dan het algemeen algoritme waarbij geen onderscheid wordt gemaakt tussen netwerken met parallelle kritische paden en netwerken zonder parallelle kritische paden. Voorbeeld 3: Parallel kritisch pad dat verder wordt gesplitst We zullen nu het algoritme in dit voorbeeld toepassen op een complexer netwerk en op deze manier aantonen dat het algoritme ook in dit geval een betere oplossing geeft. Stel dat het parallel kritisch pad zich nog eens opsplitst in een parallel kritisch pad zoals weergeven in figuur

74 Figuur 4.21: Voorbeeld dubbel parallel kritisch pad, verder gesplitst Activiteit Werkelijke kost Activiteit Werkelijke kost Tabel 4.10: Werkelijke kosten per eenheid Stap 1: Alle parallelle kritische paden worden geïdentificeerd: Merk hierbij op dat het laatste kritische pad, slechts één van de takken van het tweede parallelle kritische pad bevat. Dit geeft echter geen probleem voor het toepassen van het algoritme. Stap 2a: We vergelijken eerst tak 1: en tak 2: W erkelijke T otale Kost 1,2 = min (5; 8) + min (3) = 8 (4.52) 65

75 Stap 3a: In deze stap wordt de samengestelde kost van alle activiteiten die deel uitmaken van het parallel kritisch pad, met uitzondering van de start- en eindactiviteiten, berekend zoals in tabel 4.11 Activiteit Samengestelde kost Activiteit Samengestelde kost max (5; 8) max (3; 8) max (8; 8) Tabel 4.11: Berekening samengestelde kost Aangezien er in dit geval nog andere kritische paden aanwezig zijn in het projectnetwerk gaan we terug naar stap 2 en herhalen het proces. Stap 2b: We vergelijken nu tak 3: en tak 4: Voor de berekening van de werkelijke totale kost van deze takken wordt er gebruik gemaakt van de samengestelde kost van de activiteiten in plaats van de werkelijke kost van de activiteiten. Hierdoor wordt de nieuwe de nieuwe werkelijke totale kost: Stap 3b: W erkelijke T otale Kost 3,4 = min (2; 5; 6) + min (2; 3; 8; 8; 2) = 4 (4.53) Activiteit Samengestelde kost Activiteit Samengestelde kost max (8; 4) 2 max (2; 4) max (3; 4) 9 max (8; 4) 4 max (2; 4) 10 max (2; 4) 5 max (5; 4) max (6; 4) Tabel 4.12: Berekening samengestelde kost Aangezien er geen andere parallelle kritische paden meer zijn, kan er worden overgegaan naar stap 4. Stap 4: In deze stap wordt uit alle activiteiten de activiteit met de kleinste samengestelde kost gese- 66

76 lecteerd. In dit geval zijn dit de activiteiten 2, 3, 4 en 10. Deze activiteiten hebben elk een samengestelde kost van 4. Stap 5: Aangezien er meerdere activiteiten zijn met de laagste samengestelde kost wordt vervolgens uit deze verzameling de activiteit met de laagste werkelijke kost geselecteerd. In dit geval zijn dit activiteiten 2, 4 en 10. Activiteit Samengestelde kost Werkelijke kost Tabel 4.13: Selectie optimale activiteiten Stap 6: Activiteit 2 wordt op basis van het voorgaande geselecteerd om te corrigeren, hierdoor valt het volledige bovenste kritische pad weg en blijft enkel nog maar pad 3 over. Hier zal dan activiteit 4 worden geselecteerd als de optimale activiteit om te corrigeren. Veronderstel nu hetzelfde netwerk als in vorig voorbeeld, maar activiteiten 7, 8 en 9 hebben nu een kost van 1 en activiteiten 2, 4 en 10 hebben een kost van 4. Dit verandert op zich niets aan de parallelle kritische paden. De uitwerking van stap 1 tot en met stap 5 laten wij aan de lezer. In stap 6 krijgt men het volgende resultaat: door activiteit 8 te corrigeren valt pad 2 weg en blijft er nog slechts een enkelvoudig parallel kritisch pad over. Hiervoor herhalen we alle bovengenoemde stappen en zullen vervolgens activiteit 7 of 9 selecteren om te corrigeren waardoor er na het uitvoeren van de correctieve acties nog maar één kritisch pad overblijft, namelijk het pad: Hiervan zal activiteit 4 worden geselecteerd. Dit alles komt dan neer op een totale kost van het toepassen van correctieve acties gelijk aan 6. Ook hier merken we de beperking van het algoritme zoals reeds eerder vermeld in voorbeeld 2. Indien we namelijk activiteit 1 zouden selecteren om te corrigeren dan kunnen we dit ook doen voor een totale kost van 6. Maar we zouden op deze manier dan wel maar één keer moeten 67

77 ingrijpen in plaats van drie keer zoals via het algoritme het geval zou zijn. Maar opnieuw ook hier geeft het algoritme nog altijd een oplossing die even optimaal is of optimaler dan het generische algoritme dat geen onderscheid maakt tussen netwerken met parallelle kritische paden en netwerken zonder parallelle kritische paden. Voorbeeld 4: Drievoudig parallel kritisch pad is aanwezig Bij een drievoudig (of meer) parallel kritisch pad zoals weergegeven in figuur 4.22 moet de berekening in stap 3 worden aangepast om tot een correct resultaat te komen. Figuur 4.22: Voorbeeld drievoudig parallel kritisch pad Activiteit Werkelijke kost Tabel 4.14: Werkelijke kosten per eenheid Stap 1: Alle parallelle kritische paden worden geïdentificeerd: Stap 2a: We vergelijken eerst tak 1: en tak 2: W erkelijke T otale Kost 1,2 = min (2; 3) + min (2) = 4 (4.54) 68