Critical path effect based delay analysis method for construction projects

Universiteit Gent Faculteit Economie en Bedrijfskunde Academiejaar 2013 2014 Critical path effect based delay analysis method for construction projects Masterproef voorgedragen tot het behalen van de graad van Master of Science in de Toegepaste Economische Wetenschappen: Handelsingenieur Karen Van Crombrugghe onder leiding van Prof. dr. M. Vanhoucke

Permission Ondergetekende verklaart dat de inhoud van deze masterproef mag geraadpleegd en/of gereproduceerd worden, mits bronvermelding. Karen Van Crombrugghe

Woord vooraf Dit eindwerk is de laatste stap die nog genomen moet worden om mijn diploma Handelsingenieur te behalen aan de Universiteit Gent. Het was niet altijd even eenvoudig maar de voldoening is dan ook evenredig. Kunnen zeggen dat dit werk het resultaat is van eigen onderzoek en zelfstandig werk, was het meer dan waard. Graag wil ik dan ook een aantal mensen bedanken die dit mede mogelijk gemaakt hebben en zonder wie dit niet gelukt zou zijn. Eerst en vooral mijn dank aan mijn begeleider Pieter Leyman en promotor Prof. dr. Mario Vanhoucke. Aan Pieter Leyman, bedankt om altijd klaar te staan om mijn vragen en problemen te beantwoorden en helpen oplossen. Aan Prof. dr. Mario Vanhoucke, bedankt om mijn interesse te wekken voor het onderwerp project management. Bedankt aan mijn ouders en broer om mij doorheen mijn volledige studies steeds te steunen. Ook voor hun hulp bij het maken van de figuren en tabellen ben ik hun dankbaar. Alberto, ik ben je eeuwig dankbaar voor je hulp bij het doorgronden van C++. Ook David en Bert verdienen hier een vermelding voor de afgelopen vijf jaar. ii

Inhoudsopgave Lijst van tabellen Lijst van figuren vi vii 1 Inleiding 1 1.1 Doelstelling..................................... 1 1.2 Structuur...................................... 2 2 Basisprincipes 3 2.1 Voorbeeld...................................... 3 2.2 Critical Path Method............................... 4 2.3 Basisbegrippen................................... 9 2.3.1 Soorten delays............................... 9 2.3.2 Concurrent delay.............................. 10 2.3.3 Path float.................................. 10 2.3.4 Schedules.................................. 11 3 Window-based delay analysis 12 3.1 Traditional Windows Analysis en Modified Windows Analysis......... 13 3.1.1 Windows aanmaken............................ 13 3.1.2 Analyse................................... 14 3.1.3 Voor- en nadelen.............................. 15 3.2 Delay Analysis Method Using Delay Section................... 15 3.2.1 Windows aanmaken............................ 16 3.2.2 Analyse................................... 17 3.2.3 Voor- en nadelen.............................. 19 3.3 Daily Windows Delay Analysis.......................... 20 3.3.1 Windows aanmaken............................ 20 3.3.2 Analyse................................... 20 3.3.3 Voor- en nadelen.............................. 21 3.4 Effect-based Delay Analysis Method....................... 21 iii

Inhoudsopgave iv 3.4.1 Windows aanmaken............................ 21 3.4.2 Analyse................................... 22 3.4.3 Voor- en nadelen.............................. 23 3.5 Conclusie...................................... 23 4 Eigen methode (WACC) 26 4.1 Windows Analysis using Critical path Changes................. 26 4.1.1 Windows aanmaken............................ 27 4.1.2 Analyse................................... 29 4.1.3 Voor- en nadelen.............................. 32 4.2 Vergelijking..................................... 33 4.3 Project acceleration................................ 34 5 Resultaten 37 5.1 Simulaties...................................... 37 5.2 S/P factor...................................... 41 Bibliografie 44

Lijst van afkortingen CP CPM DAMDUS DS DWDA EC EDAM EF EN ES FIFO LF LS MWA NE PF S/P TWA WACC critical path critical path method delay analysis method using delay section delay section daily windows delay analysis excusable compensable delay effect-based delay analysis method earliest finish excusable non-compensable delay earliest start first in, first out latest finish latest start modified windows analysis non-excusable delay path float serial/parallel factor traditional windows analysis windows analysis using critical path changes v

Lijst van tabellen 2.1 Gegevens van voorbeeld project.......................... 3 2.2 Vertragingen in voorbeeld project......................... 4 2.3 Earliest start en earliest finish toegepast op voorbeeld project......... 6 2.4 Latest start en latest finish toegepast op voorbeeld project........... 7 2.5 Path float toegepast op voorbeeld project.................... 8 2.6 Kritieke pad toegepast op voorbeeld project................... 9 3.1 Resultaten van de TWA en MWA methode toegepast op het voorbeeld project 15 3.2 Resultaten van de DAMUDS methode toegepast op het voorbeeld project.. 19 3.3 Resultaten van de DWDA methode toegepast op het voorbeeld project.... 21 3.4 Resultaten van de EDAM methode toegepast op het voorbeeld project.... 23 3.5 Samenvatting van de resultaten van de verschillende methode toegepast op het voorbeeld project.................................. 25 4.1 Resultaten van de WACC methode toegepast op het voorbeeld project.... 34 4.2 Samenvatting van de resultaten van de verschillende methode aangevuld met de WACC, toegepast op het voorbeeld project.................. 36 vi

Lijst van figuren 2.1 Schematische voorstelling van voorbeeld project................. 4 2.2 As-planned schedule van voorbeeld project.................... 4 2.3 As-built schedule van voorbeeld project..................... 5 2.4 Earliest start en earliest finish toegepast op voorbeeld project......... 6 2.5 Latest start en latest finish toegepast op voorbeeld project........... 7 2.6 Path float toegepast op voorbeeld project.................... 8 2.7 Kritieke pad toegepast op voorbeeld project................... 9 2.8 Concurrent delay geïllustreerd........................... 10 3.1 Windows op basis van de TWA en MWA methode toegepast op het voorbeeld project........................................ 14 3.2 Delay section geïllustreerd............................. 16 3.3 Windows op basis van de DAMUDS methode toegepast op het voorbeeld project 16 3.4 Windows op basis van de DWDA methode toegepast op het voorbeeld project 20 3.5 Windows op basis van de EDAM methode toegepast op het voorbeeld project 22 3.6 Samenvatting van de verschillende windows van de methodes......... 24 4.1 Windows op basis van de WACC methode toegepast op het voorbeeld project, het as-planned schedule en dag 1......................... 27 4.2 Windows op basis van de WACC methode toegepast op het voorbeeld project, dag 2 en dag 3 van het project.......................... 28 4.3 Windows op basis van de WACC methode toegepast op het voorbeeld project, dag 4 en dag 5 van het project.......................... 28 4.4 Windows op basis van de WACC methode toegepast op het voorbeeld project, dag 6 en dag 7 van het project.......................... 29 4.5 Windows op basis van de WACC methode toegepast op het voorbeeld project, dag 8 en dag 9 van het project.......................... 29 4.6 Analyse van het eerste window met de WACC methode............ 31 4.7 Analyse van het tweede window met de WACC methode............ 31 4.8 Analyse van het derde window met de WACC methode............ 32 vii

Lijst van figuren viii 4.9 Analyse van het vierde window met de WACC methode............ 32 4.10 Analyse van het vijfde window met de WACC methode............ 33 4.11 Analyse van het zesde window met de WACC methode............. 33 4.12 Samenvatting van de verschillende windows van de methodes aangevuld met de WACC...................................... 35 5.1 Correctheid van de toewijzing van de NE vertragingen per methode, uitgedrukt in percentages.................................... 38 5.2 Het aantal projecten waarin een critical path change optreedt, uitgedrukt in percentages..................................... 39 5.3 Het aantal volledig correcte toewijzingen van critical path changes voor elke methode, uitgedrukt in percentages........................ 39 5.4 Het aantal correcte toewijzingen van critical path changes voor elke methode, uitgedrukt in percentages............................. 40 5.5 Het aantal windows in vergelijking met het aantal dagen in het project, uitgedrukt in een percentage.............................. 40 5.6 Het aantal projecten waarin een critical path change optreedt, uitgedrukt in percentages, verdeeld op basis van de S/P factor................ 41 5.7 Het aantal volledig correcte toewijzingen van critical path changes voor elke methode, uitgedrukt in percentages en verdeeld op basis van de S/P factor. 42 5.8 Het aantal correcte toewijzingen van critical path changes voor elke methode, uitgedrukt in percentages en verdeeld op basis van de S/P factor....... 42 5.9 Het aantal windows in vergelijking met het aantal dagen in het project per methode, uitgedrukt in percentages, verdeeld op basis van de S/P factor... 43

Hoofdstuk 1 Inleiding Bouwprojecten kunnen gezien worden als een van de meest complexe op het vlak van project scheduling en de opvolging ervan. Het aantal betrokken partijen, de structuur en opeenvolging van de activiteiten, en dergelijke zijn de voornaamste redenen voor deze complexiteit. Ook de invloed van externe factoren is aanzienlijk. Als gevolg hiervan zijn vertragingen eerder regel dan uitzondering. Wanneer bouwprojecten vertragingen oplopen en dus niet op tijd afgewerkt kunnen worden, betekent dit een aanzienlijke kost voor zowel de aannemer als de eigenaar. Hierdoor is het van belang om de impact van vertragingen op het volledige project te onderzoeken. Wanneer vertragingen voorkomen tijdens de projectuitvoering, is het belangrijk om de oorzaak en de verantwoordelijken van deze vertragingen te achterhalen. Door het kostintensieve karakter van bouwprojecten is het hier van groot belang om dit op een zo correct en efficiënt mogelijke manier te doen. Dit is het doel van windows-based delay analysis. Vertragingen kunnen het gevolg zijn van een aantal oorzaken. Er zijn vertragingen die kunnen ontstaan door acties van de eigenaar zelf, van de aannemer, als gevolg van een derde partij, of door een combinatie van al deze betrokken partijen. Ook toeval en externe factoren zoals het weer spelen een rol. 1.1 Doelstelling Er zijn al tal van methodes beschikbaar die trachten vertragingen in projecten op te volgen. In dit onderzoek wordt dieper ingegaan op de windows-based delay analysis methodes. Elk van de bestaande methodes heeft echter enkele belangrijke minpunten. In dit onderzoek wordt een nieuwe windows-based delay analysis methode voorgesteld die de tekortkomingen en inefficiënties van de huidige beschikbare methodes oplost. 1

Hoofdstuk 1. Inleiding 2 Vervolgens worden de beschikbare methodes en de voorgestelde methode vergeleken naar efficiëntie op basis van de serial/parallel-factor (S/P factor). Er wordt nagegaan in welke mate deze factor bepalend is voor de efficiëntie van de verschillende methodes. Ook wordt er een voorstel gedaan voor het bepalen van mogelijkheden tot project acceleration of projectversnelling. Dit alles wordt getest aan de hand van een dataset van 746 projecten die verschillen in hun S/P factor. Deze projecten bestaan telkens uit tien activiteiten. 1.2 Structuur Ten eerste wordt er een bespreking gegeven van de voornaamste begrippen die doorheen dit hele onderzoek frequent gebruikt zullen worden. De critical path methode alsook de verschillende soorten vertragingen zijn hiervan de belangrijkste. Zoals voorheen gezegd, wordt in dit onderzoek gefocust op de windows-based delay analysis methodes. In dit hoofdstuk worden de bestaande methodes uitgebreid uitgelegd en uitgewerkt aan de hand van een voorbeeld. Ook de voor- en nadelen van elke methode worden besproken. Zo wordt een conclusie bekomen die de tekortkomingen van de huidige methodes uitlijnt. Uiteindelijk wordt een nieuwe methode voorgesteld die de tekortkomingen van de vorige oplost. Deze wordt voorgesteld en aan de hand van een voorbeeld uitgewerkt. Hier wordt ook een voorstel gedaan om project acceleration toe te passen tijdens de besproken methode. Aan de hand van een programma geprogrammeerd in C++, worden de besproken windowsbased delay analysis methodes met elkaar vergeleken. Dit gebeurt op basis van een dataset van enkele honderden projecten waarop telkens een analyse van de vertragingen werd uitgevoerd met de verschillende methodes. Hieruit worden een aantal conclusies genomen over de efficiëntie en correctheid van de verscheidene methodes.

Hoofdstuk 2 Basisprincipes In onderstaand hoofdstuk worden de belangrijkste begrippen en principes die verder in dit onderzoek gebruikt zullen worden, gedefiniëerd en uitgewerkt. Dit heeft tot doel het verdere onderzoek voor iedereen begrijpbaar te maken. Alles wordt geïllustreerd met een voorbeeld dat doorheen dit hele onderzoek gebruikt zal worden. De gegevens voor dit voorbeeld worden als eerste besproken. Daarna wordt er dieper ingegaan op de critical path method (CPM). Tenslotte wordt een definitie gegeven van de belangrijkste begrippen. 2.1 Voorbeeld In tabel 2.1 worden de gegevens van het voorbeeldproject weergegeven. Van elke activiteit worden de duur alsook voorgaande activiteiten gegeven. Deze voorgaande activiteiten zijn de activiteiten die onmiddellijk voorgaan aan de huidige activiteit en die ook voltooid moeten zijn voor de huidige activiteit kan gestart worden. In onderstaande figuur 2.1 wordt dit schematisch voorgesteld. Tabel 2.1: Gegevens van voorbeeld project Act. Duur Voorg. (dag) act. 1 2-2 3-3 2 1 4 3 2 De volgende vertragingen (zie tabel 2.2) zullen in dit project optreden. Deze zullen ook de basis vormen van de delay analysis die verder in dit onderzoek wordt gedaan aan de hand van 3

Hoofdstuk 2. Basisprincipes 4 Figuur 2.1: Schematische voorstelling van voorbeeld project de verschillende windows-based delay analysis methodes. In figuur 2.2 en figuur 2.3 wordt dit voorgesteld in een Gantt-chart. (zie verder hoofdstuk 2.3.4). Tabel 2.2: Vertragingen in voorbeeld project Act. Soort Start delay dag Duur 1 NE 1 3 2 EC 3 1 3 EN 6 2 4 - - - Figuur 2.2: As-planned schedule van voorbeeld project 2.2 Critical Path Method Om de effecten van vertragingen die tijdens een project voorkomen te analyseren, wordt in het algemeen gebruik gemaakt van de CPM (Bordoli & Baldwin, 1998). Volgens Pinto (2010) is de CPM een netwerk analyse techniek die bepaalt welke rij van activiteiten (welk pad) het

Hoofdstuk 2. Basisprincipes 5 Figuur 2.3: As-built schedule van voorbeeld project minst flexibiliteit (de kleinste path float) heeft. Hierbij wordt verondersteld dat alle nodige middelen om een activiteit te voltooien, aanwezig zijn. De bedoeling van de CPM is het bepalen van het critical path. Dit is het pad van opeenvolgende activtieten dat de totale projectduur bepaalt. Het is van belang om de activiteiten op dit pad extra aandachtig op te volgen aangezien een vertraging in een van de activiteiten op dit pad er voor zal zorgen dat het volledige project met een vertraging zal worden afgeleverd (Vanhoucke, 2012). Om te kunnen bepalen of een activiteit zich op het critical path bevindt, is het nodig om de earliest en latest starten eindtijdstippen van elke activiteit te kennen. De earliest start (ES) van een activiteit geeft het vroegst mogelijke tijdstip aan waarop een activiteit kan gestart worden (Pinto, 2010). Gelijkaardig geeft de earliest finish (EF) het vroegst mogelijke moment weer waarop de activiteit kan voltooid worden. Deze worden berekend via forward scheduling. Hierbij wordt vanaf de start activiteit stap voor stap voor elke activiteit de ES en EF bijgehouden. Onderstaand worden de formules gegeven aan de hand van dewelke dit kan berekend worden. Dit wordt toegepast op ons voorbeeld in tabel 2.3 en figuur 2.4. ES start = 0 ES j = max(ef i i P j ) EF i = ES i + dur i Waarbij: P j Verzameling van de voorgaande activiteiten van activiteit j dur i De duur van activiteit i

Hoofdstuk 2. Basisprincipes 6 Tabel 2.3: Earliest start en earliest finish toegepast op voorbeeld project Act. Duur Voorg. (dag) act. ES EF 1 2-0 2 2 3-0 3 3 2 1 2 4 4 3 2 3 6 Figuur 2.4: Earliest start en earliest finish toegepast op voorbeeld project Dit geeft voor het voorbeeld project een ES start = 0, ES 1 = 0 en EF 1 = 2, ES 2 = 0 en EF 2 = 3, ES 3 = 2 en EF 3 = 4, ES 4 = 3 en EF 4 = 6 Na deze stap is ook de totale projectduur gekend. Deze is namelijk het tijdstip waarop de laatste activiteit wordt afgesloten. Met andere woorden de projectduur is gelijk aan de EF met de hoogste waarde. In het voorbeeld, wordt een projectduur van 6 dagen bekomen. Vervolgens dienen de latest start (LS) en latest finish (LF) berekend te worden. Dit wordt gedaan aan de hand van backward scheduling. De LS is het laatst mogelijke tijdstip waarop een activiteit kan starten zodanig dat het volledige project geen vertragingen oploopt. Daaruit volgt dat de LF het laatst mogelijke moment weergeeft waarop de activiteit kan voltooid worden. De formules voor beide zijn hieronder gegeven. Voor de praktische toepassing hiervan wordt verwezen naar tabel 2.4 en figuur 2.5 waarin zowel de LS als de LF worden toegepast op het voorbeeld. Startend bij de eindactiviteit, met een LF gelijk aan de totale projectduur, wordt achteruit gerekend tot aan de startactiviteit.

Hoofdstuk 2. Basisprincipes 7 LF eind = max(ef i i = 1, 2,..., n) = P D LF j = max(ls i i S j ) LS i = LF i dur i Waarbij: n Aantal activiteiten in het project PD Project duur S j Verzameling van activiteiten die volgen op activiteit j dur i De duur van activiteit i Dit geeft voor het voorbeeld project een LF eind = 6, LF 4 = 6 en LS 4 = 3, LF 3 = 6 en LS 3 = 4, LF 2 = 3 en LS 2 = 0, LF 1 = 4 en LS 1 = 2. Tabel 2.4: Latest start en latest finish toegepast op voorbeeld project Act. Duur Voorg. (dag) act. ES EF LS LF 1 2-0 2 2 4 2 3-0 3 0 3 3 2 1 2 4 4 6 4 3 2 3 6 3 6 Figuur 2.5: Latest start en latest finish toegepast op voorbeeld project

Hoofdstuk 2. Basisprincipes 8 Nu de ES, EF, LS en LF gekend zijn voor elke activiteit in het project, is het mogelijk om de path float (PF) te berekenen. Deze geeft weer hoeveel vertraging een activiteit mag oplopen zonder dat dit een effect heeft op de complete projectduur. Met andere woorden, de flexibiliteit die een activiteit heeft. Het wordt als volgt berekend: P F i = LS i ES i of P F i = LF i EF i In tabel 2.5 en figuur 2.6 werd dit toegepast op het voorbeeld project. Tabel 2.5: Path float toegepast op voorbeeld project Act. Duur Voorg. (dag) act. ES EF LS LF PF 1 2-0 2 2 4 2 2 3-0 3 0 3 0 3 2 1 2 4 4 6 2 4 3 2 3 6 3 6 0 Figuur 2.6: Path float toegepast op voorbeeld project Op basis van deze path float, kan bepaald worden welke activiteiten zich op het critical path (CP) bevinden. Aangezien dit het pad is dat de projectduur bepaalt, zijn vertragingen in een van de activiteiten op dit pad niet mogelijk zonder het gehele project te vertragen. Hieruit kan afgeleid worden dat activiteiten met een path float gelijk aan 0, de activiteiten zijn die deel uitmaken van het critical path. Een project kan ook meer dan een critical path hebben. In onderstaande tabel 2.6 en figuur 2.7 wordt dit toegepast. Dit vervolledigt de CPM, het kritische pad is bepaald en de projectduur is gekend.

Hoofdstuk 2. Basisprincipes 9 Tabel 2.6: Kritieke pad toegepast op voorbeeld project Act. Duur Voorg. (dag) act. ES EF LS LF PF CP 1 2-0 2 2 4 2 nee 2 3-0 3 0 3 0 ja 3 2 1 2 4 4 6 2 nee 4 3 2 3 6 3 6 0 ja Figuur 2.7: Kritieke pad toegepast op voorbeeld project 2.3 Basisbegrippen 2.3.1 Soorten delays Volgens Kraiem & Diekmann (1987) kunnen delays of vertragingen in bouwprojecten opgedeeld worden in twee categoriën in hoofde van de aannemer, namelijk excusable en nonexcusable vertragingen. Ten eerste heeft men de non-excusable (NE) vertragingen. Deze zijn het resultaat van de acties van de aannemer zelf. De eigenaar kan enige vertraging die het project oploopt door een delay opgedeeld in deze categorie, verhalen op de aannemer. Daartegenover staan de vertragingen die excusable zijn vanuit het standpunt van de aannemer. Deze kunnen nogmaals opgedeeld worden in de excusable compensable (EC) en de excusable non-compensable (EN) vertragingen (Yang & Kao, 2012). Deze excusable delays zijn vertragingen die buiten de wil van de aannemer hebben plaatsgevonden. De niet-vergoedbare, verontschuldigbare (EN delays) vertragingen zijn het resultaat van onvoorziene omstandigheden die niet konden ingecalculeerd worden door zowel de eigenaar als de aannemer. Meestal zijn deze opgenomen in een clausule in het contract (Kraiem & Diek-

Hoofdstuk 2. Basisprincipes 10 mann, 1987). Ook evenementen die niet het resultaat zijn van een fout of nalatigheid worden hierin onderverdeeld. De EC delays zijn vertragingen die te verhalen zijn op de eigenaar. Ze zijn het gevolg van eigen acties (Kao & Yang, 2009). De aannemer kan hiervoor extra tijd krijgen om zijn deel af te werken. 2.3.2 Concurrent delay Een concurrent delay is een combinatie van twee of meerdere vertragingen die tegelijkertijd voorkomen en hierdoor de verantwoordelijkheid voor de projectvertraging delen. Waarbij beide vertragingen, indien ze alleen zouden voorkomen, elk afzonderlijk een effect zouden hebben op de projectduur (Rubin et al., 1983). Mohan & Al-Gahtani (2006) verduidelijken dit nog meer door te stellen dat concurrent delays voorkomen in parallele kritieke paden tijdens hetzelfde tijdsframe. De vertragingen zijn de verantwoordelijkheid van verschillende partijen. In onderstaande figuur 2.8 is een voorbeeld gegeven van een concurrent delay. Delay A en Delay B zijn beide verantwoordelijk voor de vertraging die het project oploopt. Zowel A als B zouden dezelfde vertragingen veroorzaken in het geval ze afzonderlijk waren voorgekomen. Figuur 2.8: Concurrent delay geïllustreerd 2.3.3 Path float Path float werd al besproken op pagina 8. Het is echter van belang hier nog even op terug te komen met het oog op de volgende hoofdstukken. Op pagina 8 werd enkel ingegaan op de berekeningswijze van de path float. Bij het analyseren van projecten en de effecten van

Hoofdstuk 2. Basisprincipes 11 vertragingen op de projectduur, is het ook belangrijk om te weten hoe deze path float wordt verdeeld tussen de verschillende partijen. Wanneer path float wordt gebruikt om vertragingen op te vangen, wordt de flexibiliteit van die activiteit verminderd. Activiteiten die oorspronkelijk niet op het critical path lagen, kunnen hierdoor hun path float opgebruiken en kritiek worden (Kraiem & Diekmann, 1987). Dit gebeurt als gevolg van vertragingen in voorgaande activiteiten (de la Garza; Apirath Prateapusanond & Ambani, 2007). In de rest van dit werk, veronderstellen we dat de path float wordt toegewezen volgens het first in, first out (FIFO)-principe. De path float wordt toegewezen aan de partij die het als eerste kan gebruiken. 2.3.4 Schedules Zoals gezegd door Kim & Shin (2005), wordt bij het analyseren van vertragingen in het algemeen gebruik gemaakt van een as-planned schedule (zie figuur 2.2) en een as-built schedule (zie figuur 2.3). Ook in windows-based delay analysis worden deze twee plannen vergeleken. De definities van beide plannen wordt hieronder gegeven: ˆ As-planned schedule: geeft het initiële plan weer met de opeenvolging en duur van de activiteiten ˆ As-built schedule: geeft de werkelijke opeenvolging en duur weer van activiteiten tijdens de uitvoering van het project

Hoofdstuk 3 Window-based delay analysis Vertragingen zijn meer regel dan uitzondering in bouwprojecten. De impact van deze vertragingen is vaak complex en moeilijk te bepalen. Zoals beschreven door Arditi & Pattanakitchamroon (2006), resulteert een vertraging in een activiteit niet altijd in dezelfde vertraging van de projectduur. Sommige vertragingen hebben geen enkele invloed op de projectduur, anderen slechts ten dele en in nog andere gevallen is er sprake van een gedeelde verantwoordelijkheid. Hierdoor is een betrouwbare methode nodig die de effecten en oorzaken van projectvertragingen correct en efficiënt kan beoordelen. Elke actie die een vertraging veroorzaakt, moet verantwoord worden en toegewezen worden aan de eigenaar of aannemer. Van de vele methodes die bestaan om projecten en vertragingen te analyseren, is de windowsbased delay analysis methode het meest nauwkeurig (Kao & Yang, 2009). Windows-based delay analysis methodes zijn uitzonderlijk in het identificeren en toewijzen van vertragingen in bouwprojecten. Voor een bespreking van andere dan de windows-based delay analysis methode wordt verwezen naar de literatuur. De windows-based delay analysis methode gebruikt de CPM als basis voor zijn analyse. Het te analyseren project wordt opgedeeld in verschillende tijdsperiodes die verder windows genoemd zullen worden. Deze windows worden chronologisch geanalyseerd naar vertragingen die voorkomen tijdens die tijdsperiode. Hierbij ligt de focus op het critical path. In de volgende paragrafen, worden de vier bestaande windows-based delay analysis methodes stap voor stap uitgelegd en besproken. Enkel de windows-based delay analysis methodes die van het as-planned schedule vertrekken en zo vooruit werken, worden besproken. Als laatste wordt een conclusie gegeven en worden deze vier methodes met elkaar vergeleken. 12

Hoofdstuk 3. Window-based delay analysis 13 3.1 Traditional Windows Analysis en Modified Windows Analysis De traditional windows analysis (TWA) en de modified windows analysis (MWA) methode zijn gelijkaardig. Zoals wordt uitgelegd door Kao & Yang (2009), gebruikt de TWA methode het as-planned schema (zie pagina 11) als basis. Dit plan wordt periodiek aangepast aan het einde van elk scenario. Vertragingen in een window worden in oplopende volgorde geanalyseerd. De MWA methode leunt dicht aan tegen de TWA methode. Echter, hier worden de vertragingen al voor de analyse toegevoegd en worden de verantwoordelijken aangesteld. Aangezien in het voorbeeld dat in dit onderzoek gevolgd wordt, de vertragingen van in het begin duidelijk beschreven zijn, zijn de resultaten van de MWA en de TWA methode dezelfde en worden ze hier dus samen besproken. 3.1.1 Windows aanmaken De windows in de TWA en MWA methode worden op subjectieve manier bepaald. Gothandi (2003) beschreef de analyse die gevolgd wordt bij het bepalen van de windows als volgt: ˆ Stap 1: identificeer activiteiten die plaatsvinden op het huidige moment ˆ Stap 2: identificeer delays in de activiteiten uit stap 1 die het project kunnen vertragen ˆ Stap 3: vind deze die het meest waarschijnlijk het schedule zal beïnvloeden ˆ Stap 4: start window hier ˆ Stap 5: duur van het window is gelijk aan de duur van de delay die gevonden werd in stap 3 Om tot de conclusies te komen die later in dit onderzoek gemaakt worden, werd een Monte- Carlo simulatie uitgevoerd van verschillende projecten die door de hier beschreven methodes werden geanalyseerd. Dit werd gedaan aan de hand van een programma geschreven in C++ (zie verder). Aangezien dit geen subjectiviteit toelaat, werd voor het aanmaken van de windows telkens geopteerd voor de delay die voorkwam in de eerstvolgende activiteit die plaatsvond op het huidige tijdstip. Dit wordt toegepast in figuur 3.1. Hier worden de windows van de TWA en MWA methode aangemaakt voor het voorbeeld project.

Hoofdstuk 3. Window-based delay analysis 14 Figuur 3.1: Windows op basis van de TWA en MWA methode toegepast op het voorbeeld project 3.1.2 Analyse Volgende stap in de TWA en MWA methode is het analyseren van de vertragingen op basis van de voorheen gedefiniëeerde windows. Hierbij wordt aan het begin van elk window, het as-planned schema aangepast aan de werkelijke duur van de activiteiten. De MWA methode definieert drie belangrijke tijdstippen op basis van dewelke de verantwoordelijkheid van de verschillende delays zal worden verdeeld. Deze zijn: ˆ Baseline impact schedule completion tijdstip: (BSCD) de projectduur bepaald tijdens het vorige window ˆ Claimant impact schedule completion tijdstip: (CSCD) stelt de vertragingen voor van de eiser en de projectduur die daaruit resulteert ˆ Defendant impact schedule completiontijdstip: (DSCD) stelt de vertragingen voor van de verdediger en de projectduur die daaruit resulteert Hieruit kan men dan het volgende berekenen ˆ Concurrent delay: (CD) = CSCD BSCD ˆ Schedule delay: (SD) = DSCD BSCD Toegepast op het voorbeeld project, worden de vertragingen toegewezen zoals weergegeven in tabel 3.1. Ook de mogelijke concurrent delays en critical path changes worden hierin weergegeven.

Hoofdstuk 3. Window-based delay analysis 15 Tabel 3.1: Resultaten van de TWA en MWA methode toegepast op het voorbeeld project Type delay Timing Werkelijk voorgekomen TWA/MWA NE delay 1 - x EN delay 6 x x 7 x x EC delay - - - Concurrent delay 3 x - Critical path changes 2 x - 3 - x 6 x - 7 - x 3.1.3 Voor- en nadelen Het grootste pluspunt van de TWA en MWA methode is het relatief gezien weinig aantal windows ten opzichte van de projectduur (zoals duidelijk uit figuur 3.1) Dit maakt dat het aantal analyse periodes beperkt is. Snelheid en gebruiksvriendelijkheid zijn hiervan een gevolg. Echter, deze methode heeft meer nadelen dan voordelen. De betrouwbaarheid van deze methode laat namelijk te wensen over, zoals duidelijk zichtbaar in tabel 3.1. Critical path changes en concurrent delays worden niet correct toegewezen. Ook het toewijzen van NE, EN en EC vertragingen gebeurt niet steeds correct. Geen van beide methodes is daarenboven geschikt voor real-time analysis (Kao & Yang, 2009). 3.2 Delay Analysis Method Using Delay Section De delay analysis method using delay section (DAMUDS) probeert de tekortkomingen van de vorige methode te overwinnen. Hiervoor wordt een nieuw begrip ingevoerd door Kim & Shin (2005), namelijk delay section (DS). DS is een tijdsframe dat een delay opdeeld in een singleoccurred periode, een periode waarin slechts een vertraging optreedt (er is geen overlap met andere vertragingen) of in een periode waarin meerdere vertragingen tegelijkertijd optreden (er is overlap). Dit begrip, DS, wordt geïllustreerd in onderstaande figuur 3.2. In de eerste DS treedt slechts een enkele vertraging op, dit is een single-occured periode. Vervolgens is er een sectie zonder delays. DS 4 is een DS waarin meerdere vertragingen tegelijkertijd optreden.

Hoofdstuk 3. Window-based delay analysis 16 Figuur 3.2: Delay section geïllustreerd 3.2.1 Windows aanmaken Periodes met een vertraging worden opgedeeld met behulp van DS. Dit vormt de basis voor het bepalen van de windows in de DAMUDS methode. Een nieuw window wordt aangemaakt indien een van de volgende drie gevallen voorkomt: ˆ Geen vertraging: indien in geen enkele activiteit een vertraging optreedt ˆ Single delay-occurred: een DS die vertragingen bevat die alleen voorkomen ˆ Multiple delay-occurred: een DS die meerdere vertragingen bevat die tegelijkertijd voorkomen De volledige projectduur wordt op die manier opgedeeld in verschillende windows, die in de volgende stap geanalyseerd zullen worden. In onderstaande figuur 3.3 wordt dit toegepast op het voorbeeld project. Figuur 3.3: Windows op basis van de DAMUDS methode toegepast op het voorbeeld project

Hoofdstuk 3. Window-based delay analysis 17 3.2.2 Analyse Als volgt, dienen de onderscheiden windows geanalyseerd te worden naar hun invloed op de projectduur. Er zijn drie verschillende mogelijkheden, namelijk een window zonder vertragingen, een window met een enkele vertraging en een window met meerdere vertragingen die tegelijkertijd optreden. Deze hebben elk hun eigen analyse die hieronder zal worden uitgelegd. Hiervoor worden onderstaande variabelen gebruikt: DS i ide DS in het project, 1 i n D j jde delay in het project, 1 j m D ij jde delay in de ide DS Dur DSi duur van DS i P F k path float van activiteit k, k is activiteit waarin D j gebeurt, 1 k t CD i som van de concurrent delay n aantal DS in het project m aantal vertragingen in het project t aantal activiteiten in het project Elk window wordt chronologisch geanalyseerd en opgedeeld in een van de bovenstaande drie categoriën. Window zonder vertragingen Wanneer geen vertragingen gebeuren in een window, is er ook geen analyse nodig van de projectduur aangezien deze gelijk blijft. Het enige dat dient te gebeuren is het aanpassen van het aanvangsschema. Dit wordt gedaan door de huidige activiteiten hieraan toe te voegen. Een voorbeeld van een window zonder vertragingen is te vinden in figuur 3.3. Hierin is DS 3 een window zonder vertragingen. Window met een single-portion van vertragingen Wanneer vertragingen voorkomen in het window moet worden nagegaan welke effecten deze hebben op de projectduur. Indien de projectduur wordt gewijzigd, dienen verantwoordelijken voor deze vertraging te worden aangeduid. ˆ Stap 1: aanpassen van het aanvangsschema, tot het moment waarop het window stopt. De duur van het window is gelijk aan de duur van de delay (D j ) die aan de basis ligt van de DS i

Hoofdstuk 3. Window-based delay analysis 18 ˆ Stap 2: analyseer de gegevens na de aanpassing van het schema Dur DSi P F k : Aangezien de duur van de onderzochte DS, en dus de duur van de vertraging, kleiner is dan de beschikbare path float, is de analyse dezelfde als deze bij een window waarin geen vertragingen plaatsvinden. De path float wordt verminderd, maar de totale projectduur wordt niet aangetast waardoor er geen delays dienen te worden toegewezen Dur DSi > P F k : In dit geval, duurt de vertraging langer dan de beschikbare path float. Op het moment dat deze path float opgebruikt is, wordt de activiteit een onderdeel van het critical path en leiden verdere vertragingen tot een verlenging van de projectduur. Deze vertragingen moeten worden toegewezen aan de juiste verantwoordelijke partij Een voorbeeld hiervan is te vinden in het eerste window van figuur 3.3, waarvoor geldt dat Dur DS1 = 2 en P F 1 = 2. Daaruit volgt dat de analyse dezelfde is als voor een window zonder vertragingen. Het project ondervindt geen vertraging. In tabel 3.2 zijn dan ook geen NE vertragingen uit de periode van dit window opgelijst. Een tweede voorbeeld is het vierde window, waarvoor geldt dat Dur DS4 = 2 en P F 3 = 0. In dit geval dienen twee tijdsperiodes van vertragingen te worden toegewezen aan de EN delays. Dit wordt ook opgemerkt in tabel 3.2. Window met meerdere delays die tegelijkertijd optreden In deze categorie bevinden zich de concurrent delays. Deze treden op wanneer twee of meer vertragingen tegelijkertijd de oorzaak zijn van een projectvertraging. Het is de bedoeling om per window na te gegaan wat het effect van de acties die tijdens dit window gebeuren, is op de projectduur. Indien deze veranderd is, dient te worden nagaan welke vertraging hiervan de oorzaak is en of het gaat om een concurrent delay of een enkele vertraging. ˆ Stap 1: aanpassen van het aanvangsschema, tot het moment waarop het window stopt. De duur van het window is gelijk aan de duur van de delay (D j ) die aan de basis ligt van de DS i ˆ Stap 2: analyseer de gegevens na de aanpassing van het schema ˆ Stap 3: Voor elke D ij wordt nagegaan of Dur DSi > P F k. Indien dit het geval is, wordt CD i voor elke D ij die daaraan voldoet, verhoogt met 1 ˆ Stap 4: analyseren van CD i CD i = 0: Geen enkele vertraging in deze DS heeft een invloed gehad op de projectduur. De path float werd gebruikt om de vertragingen op te vangen. Verdere analyse is gelijk aan deze voor een window zonder vertraging

Hoofdstuk 3. Window-based delay analysis 19 CD i = 1: Slechts een van de vertragingen heeft een invloed op de projectduur. De overige vertragingen werden ongedaan gemaakt door de path float. De rest van de analyse is gelijkaardig aan deze voor een window met single portion vertraging. CD i 2: In dit geval zijn meerdere vertragingen de oorzaak van veranderingen in de projectduur. Indien deze vertragingen allemaal de verantwoordelijkheid zijn van dezelfde partij (de aannemer of de eigenaar), kan dit opnieuw worden opgevat als een window met single portion vertraging. Indien deze vertragingen de verantwoordelijkheid zijn van meerdere verschillende partijen, is er sprake van een concurrent delay. DS 2 is hiervan een voorbeeld. Voor D 21 geldt Dur DS2 = 1 en P F 1 = 0, voor D 22 geldt Dur DS2 = 1 en P F 2 = 0. Dit resulteert in een CD 2 = 2 en dus een concurrent delay. Zowel de NE vertraging in activiteit 1 als de EC vertraging in activiteit 2 zijn verantwoordelijk voor een projectvertraging. In tabel 3.2 is dan ook een concurrent delay terug te vinden. Tabel 3.2: Resultaten van de DAMUDS methode toegepast op het voorbeeld project Type delay Timing Werkelijk voorgekomen DAMUDS NE delay - - - EN delay 6 x x 7 x x EC delay - - - Concurrent delay 3 x x Critical path changes 2 x x 6 x - 7 - x 3.2.3 Voor- en nadelen De DAMUDS methode verhelpt duidelijk de nadelen die ondervonden worden bij het gebruik van de MWA methode. Met behulp van de DAMUDS methode worden vertragingen toegewezen aan de juiste verantwoordelijke partij. Ook concurrent delays worden op een correcte wijze geanalyseerd. Grootste nadeel van de DAMUDS methode is te vinden bij de critical path changes. Deze worden niet toegewezen op het correcte moment.

Hoofdstuk 3. Window-based delay analysis 20 3.3 Daily Windows Delay Analysis De daily windows delay analysis (DWDA) methode tracht het probleem van de DAMUDS methode, namelijk het incorrect toewijzen van de critical path changes, te verhelpen. Volgens Hegazy & Zang (2005) is de oorzaak van dit incorrect toewijzen van de critical path changes te vinden in de grootte van de gebruikte windows. 3.3.1 Windows aanmaken Om in staat te zijn alle schommelingen in het kritieke pad correct op te merken, wordt het project opgedeeld in windows met de kleinst mogelijke duur. Dit resulteert in een project dat is opgedeeld in windows met een duur van een enkele dag ongeacht of er vertragingen voorkomen of niet. Dit wordt toegepast op het voorbeeld project in figuur 3.4. Figuur 3.4: Windows op basis van de DWDA methode toegepast op het voorbeeld project 3.3.2 Analyse Aan het begin van de analyse wordt gestart van het as-planned schedule (zie pagina 11). Elk window, of elke dag, worden de volgende stappen ondernomen: ˆ Stap 1: het as-planned schedule wordt aangepast aan de werkelijke situatie, de duur van de activiteiten wordt aangepast aan de werkelijke duur ˆ Stap 2: invloed van het huidige window op de totale projectduur wordt nagegaan. Indien er een verandering in projectduur is, worden vertragingen op het critical path onderzocht ˆ Stap 3: indien vertragingen zijn opgetreden, wordt het huidige critical path vergeleken met het vorige window om veranderingen hierin op te merken

Hoofdstuk 3. Window-based delay analysis 21 Op het einde van het proces, wanneer het volledige project doorlopen is, wordt een samenvatting bekomen van alle veranderingen die tijdens het project hebben plaatsgevonden. Dit wordt voorgesteld in onderstaande tabel 3.3 die de samenvatting geeft voor het voorbeeld project. Tabel 3.3: Resultaten van de DWDA methode toegepast op het voorbeeld project Type delay Timing Werkelijk voorgekomen DWDA NE delay - - - EN delay 6 x x 7 x x EC delay - - - Concurrent delay 3 x x Critical path changes 2 x x 6 x x 3.3.3 Voor- en nadelen Zoals blijkt uit de analyse van het voorbeeld project, is duidelijk dat aan de hand van de DWDA methode, vertragingen correct kunnen worden geanalyseerd. Ook critical path changes en concurrent delays worden correct opgemerkt en toegewezen. Ook het aanmaken van de windows gebeurt op een intuïtieve wijze waardoor de methode gemakkelijk te gebruiken is. Daartegenover staat de hoeveelheid windows en dus het aantal analyseperiodes nodig om tot het eindresultaat te komen. Zeker naarmate de complexiteit van het project stijgt en dus ook de duur ervan, wordt het aantal analyse periodes aanzienelijk. Het is een tijdsconsumerende methode die veel inspanning vergt. 3.4 Effect-based Delay Analysis Method De effect-based delay analysis method (EDAM) maakt gebruik van extracted windows in de analyse van vertragingen. Dit wordt gedaan door middel van het analyseren van de effecten van vertragingen op het critical path. 3.4.1 Windows aanmaken Voor het bepalen van de windows in de EDAM methode, wordt slechts rekening gehouden met twee situaties:

Hoofdstuk 3. Window-based delay analysis 22 ˆ Geen vertraging: in deze situatie, wordt het window toegewezen aan een periode zonder vertragingen ˆ Vertraging: om op een correcte manier de effecten van vertragingen te kunnen analyseren, wordt gebruik gemaakt van de kleinst mogelijke tijdsperiode die mogelijk is. Dit betekent dat voor elke periode waarin een delay voorkomt, een apart window wordt aangemaakt De volledige periode waarin het project plaatsvindt, wordt dus opgedeeld in windows van een enkele tijdsperiode, waarin een vertraging gebeurt en windows die meerdere dagen kunnen duren en die geen delays bevatten. Dit wordt weergegeven in figuur 3.5 voor het voorbeeld project. Figuur 3.5: Windows op basis van de EDAM methode toegepast op het voorbeeld project 3.4.2 Analyse Ook in deze methode wordt bij de analyse fase gestart van het as-planned schedule. Daarna wordt van elke vertraging duidelijk aangeduid wat de starten eindtijd ervan zijn. Ook de verantwoordelijke van elke delay wordt geïdentificeerd. Daarna wordt op basis van de windows een onderscheid gemaakt tussen twee verschillende situaties: ˆ Zonder vertragingen: geen vertragingen, dus ook geen verandering in het schedule ˆ Window met vertragingen: P D i = P D i 1 geen verandering in de projectduur, de vertraging werd ongedaan gemaakt door de beschikbare path float.

Hoofdstuk 3. Window-based delay analysis 23 P D i > P D i 1 verandering in projectduur, dus vertraging dient toegewezen te worden aan de correcte verantwoordelijke partij. Onderzoek de vertraging op het critical path. Wanneer er meerdere kritieke paden zijn met een delay is er sprake van een concurrent delay. Met P D i Projectduur gedurende window i Deze analyse werd toegepast op het voorbeeld project, de resultaten hiervan zijn te vinden in tabel 3.4. Voor zowel het eerste als het tweede window is er geen verandering in de projectduur waar te nemen, deze NE delays worden dan ook niet opgenomen in deze tabel. Echter, in het derde window is er wel een verandering in de projectduur. De vertragingen in dit window zijn verantwoordelijk voor een verlenging van het project. Tabel 3.4: Resultaten van de EDAM methode toegepast op het voorbeeld project Type delay Timing Werkelijk voorgekomen EDAM NE delay - - - EN delay 6 x x 7 x x EC delay - - - Concurrent delay 3 x x Critical path changes 2 x x 6 x x 3.4.3 Voor- en nadelen De EDAM methode heeft dezelfde positieve punten als de DWDA methode. Deze zijn het correct toewijzen van NE, EN en EC vertragingen, maar ook van de concurrent delay en de critical path changes. Hoewel het aantal windows kleiner is dan het aantal in de DWDA methode, is het toch opvallend meer dan deze in de overige methodes. 3.5 Conclusie In de vorige paragrafen werden de verschillende window-based delay analysis methodes uitgebreid uitgelegd en besproken. Hieronder worden deze methodes met elkaar vergeleken op

Hoofdstuk 3. Window-based delay analysis 24 verschillende vlakken. Hieruit hopen we te kunnen bepalen aan welke voorwaarden een nieuwe methode dient te voldoen en welke valkuilen dienen te worden vermeden. Eerst en vooral volgt een analyse op basis van de resultaten van de hierboven beschreven methodes op het voorbeeld project. Ten eerste worden de verschillende windows van de beschreven methodes nogmaals gegeven in een samenvattende figuur (zie figuur 3.6). Ook een samenvattende tabel van de resultaten wordt gegeven (zie tabel 3.5). Figuur 3.6: Samenvatting van de verschillende windows van de methodes Eerste opvallende punt is dat enkel de EDAM en DWDA methode alle vertragingen en veranderingen correct in kaart brengen. De MWA en de DAMUDS methode falen om de veranderingen in het kritieke pad correct te beoordelen. Dit is nochtans van belang om de impact van een vertraging op de projectduur te kunnen bepalen. Daarenboven is de MWA methode niet in staat om de andere vertragingen op een juiste manier te verdelen over de verschillende verantwoordelijken. Vervolgens worden de windows bekeken. Deze zijn van belang om de efficiëntie van een bepaalde methode te bepalen aangezien deze bepalen hoeveel analyse periodes nodig zijn. Gezien het kostintensieve karakter van bouwprojecten en hun complexiteit is dit van uitzonderlijk belang om het aantal analyse periodes zo minimaal mogelijk te houden. Het is ook van belang om projecten ook tijdens de uitvoering te kunnen opvolgen. Enkel een analyse die mogelijk is na het vervolledigen van het project, komt niet ten goede aan de effectiviteit. Hierbij wordt ook een kans gemist om het project mogelijks nog bij te sturen. Op basis van de opmerkingen gemaakt in de vorige paragrafen, is het mogelijk om een duidelijk beeld te krijgen van de criteria waaraan een nieuwe windows-based delay analysis methode dient te voldoen. Deze zijn het correct toewijzen van de verschillende delays alsook van de

Hoofdstuk 3. Window-based delay analysis 25 Tabel 3.5: Samenvatting van de resultaten van de verschillende methode toegepast op het voorbeeld project Type delay Timing Werkelijk voorgekomen EDAM TWA/MWA DAMUDS DWDA NE delay 1 - - 1 - - EN delay 6 x x x x x 7 x x x x x EC delay - - - - - - Concurrent delay 3 x x - x x Critical path 2 x x - x x changes 3 - - x - - 6 x x - - x 7 - - x x - Analyse 7 4 5 9 periodes critical path changes. Daarenboven moet getracht worden het aantal analyse periodes, en dus het aantal windows zo klein mogelijk te houden om de efficiëntie te garanderen. Ook de mogelijkheid om het project in real-time op te volgen is een pluspunt.

Hoofdstuk 4 Eigen methode (WACC) Zoals duidelijk werd uit het vorige hoofdstuk, voldoen geen van de bestaande windowsbased delay analysis methodes. In dit hoofdstuk wordt een voorstel gedaan voor een nieuwe windows-based delay analysis methode die een antwoord probeert te geven op de tekortkomingen van de huidige beschikbare methodes. De hieronder beschreven methode tracht de toewijzing van de verschillende vertragingen alsook van de veranderingen op het kritieke pad op een correcte wijze te doen. Dit alles wordt gedaan in een minimaal mogelijk aantal analyse periodes om de efficiëntie van de methode te bewaren. Er wordt gepoogd een oplossing aan te bieden aan de nood dit op een real-time basis te doen. Daarna volgt een korte vergelijking van deze nieuwe eigen methode met de beschikbare methodes. Dit wordt gedaan aan de hand van de resultaten van het voorbeeld project. Ten slotte wordt de mogelijkheid tot project acceleration onderzocht. 4.1 Windows Analysis using Critical path Changes Deze eigen methode, de windows analysis using critical path changes (WACC), maakt gebruik van de veranderingen in het kritieke pad. Op die manier kunnen de critical path changes worden toegewezen aan het correcte tijdstip met een beperkt aantal windows. Verder wordt uitgelegd op welke manier het project wordt opgedeeld in verschillende windows. Daarna volgt een beschrijving van de analyse en worden de resultaten gegeven van het voorbeeld project. Als laatste worden nog een aantal voor- en nadelen van de besproken methode gegeven. 26

Hoofdstuk 4. Eigen methode (WACC) 27 4.1.1 Windows aanmaken Met behulp van een Gannt chart dat dagelijks wordt aangepast aan de huidige situatie, is het aanmaken van de windows in de WACC methode eenvoudig. Er wordt rekening gehouden met drie situaties, op basis van dewelke de windows worden bepaald. De drie situaties zijn de volgende: ˆ Geen vertraging: er worden geen vertragingen waargenomen in de beschouwde periode ˆ Critical path change: aan het einde van de dag wordt een verandering in het kritieke pad waargenomen. Het huidige window wordt afgesloten, er wordt een nieuwe window gestart de volgende periode. ˆ Vertraging: In dezelfde activiteit geldt voor de beschouwde periode dezelfde delay Dit wordt stap voor stap toegepast op het voorbeeld project. Er wordt gestart van het as-planned schedule. Dit is ook de start van het eerste window. Het as-planned schedule wordt aangepast na dag 1 (zie figuur 4.1). Er wordt geen verandering in het kritieke pad waargenomen, er treedt echter wel een NE vertraging op. Het window wordt nog open gelaten, een analyse dringt zich nog niet op. Figuur 4.1: Windows op basis van de WACC methode toegepast op het voorbeeld project, het asplanned schedule en dag 1 In dag 2 wordt er een verandering in het kritieke pad opgemerkt. Dit luidt het einde in van het eerste window. De volgende dag is dan ook de start van het tweede window. Er wordt geen critical path change waargenomen, maar wel een vertraging. Het window blijft nog open. Het bovenstaande wordt weergegeven in figuur 4.2.

Hoofdstuk 4. Eigen methode (WACC) 28 Figuur 4.2: Windows op basis van de WACC methode toegepast op het voorbeeld project, dag 2 en dag 3 van het project In figuur 4.3 worden dag 4 en dag 5 geïllustreerd. Er treden geen vertragingen of critical path changes op. Het window kan nog niet worden afgesloten, er moet worden afgewacht of er veranderingen in het project optreden in dag 6. Figuur 4.3: Windows op basis van de WACC methode toegepast op het voorbeeld project, dag 4 en dag 5 van het project De periode zonder vertragingen stopt hier, er wordt dan ook een nieuw window gestart. Er wordt echter ook een verandering in het kritieke pad opgemerkt waardoor het daarnet begonnen window hier alweer wordt afgesloten. Zoals te zien in figuur 4.4 vindt er in dag 7 een EN vertraging plaats. Aangezien er geen verandering van het critical path is, kan window 5 nog niet gesloten worden. Het vorige window kan worden afgesloten. Hierna volgt enkel nog een periode zonder vertragingen of veranderingen in het kritieke pad (zie figuur 4.5). Beide dagen vormen samen het laatste window. Op dag 9 is het project voltooid en werd de volledige projectduur opgedeeld in windows.

Hoofdstuk 4. Eigen methode (WACC) 29 Figuur 4.4: Windows op basis van de WACC methode toegepast op het voorbeeld project, dag 6 en dag 7 van het project Figuur 4.5: Windows op basis van de WACC methode toegepast op het voorbeeld project, dag 8 en dag 9 van het project 4.1.2 Analyse Na het afsluiten van een window kan telkens de analyse gestart worden. In tegenstelling tot bij het bepalen van de windows moet hier slechts rekening gehouden worden met twee situaties, namelijk: ˆ Geen vertraging: Er treden geen vertragingen op gedurende de periode van het window ˆ Vertraging: Er treden wel vertragingen op gedurende de periode van het window Beide hebben elke hun eigen analyse die op een verschillende manier wordt uitgevoerd. Dit wordt hieronder verduidelijkt. Window zonder vertragingen In het geval er geen vertragingen optreden tijdens het window, is er geen verdere analyse nodig. In dit geval zijn er geen NE, EN, EC of concurrent delays die moeten worden toegewezen. Er zijn dus ook geen veranderingen in het kritiek pad te bemerken.

Hoofdstuk 4. Eigen methode (WACC) 30 Window met vertragingen Indien vertragingen voorkomen, moet nagegaan worden in welke mate deze een effect hebben op het project. Dit geldt voor zowel de projectduur alsook voor het kritieke pad. ˆ Stap 1: bepalen van het aantal vertragingen die een invloed hebben op de projectduur. Dit wordt gedaan door de huidige projectduur te vergelijken met de projectduur van het vorige window. Voor het eerste window wordt de projectduur van het as-planned schedule, P D 0, gebruikt D i = P D i P D i 1 ˆ Stap 2: toewijzen van deze D i vertragingen D i = 0: zelfde analyse als voor een window zonder vertragingen D i > 0: de vertragingen die voorkomen in de activiteiten tijdens het window en op het kritieke pad liggen, worden geanalyseerd. Er wordt gestart bij de laatste dag van het window en er wordt teruggewerkt tot er geen vertragingen meer dienen toegewezen te worden, met andere woorden, D i = 0. Dit wordt gedaan omdat de PF wordt toegewezen volgens het FIFO principe. Hierdoor zijn de activiteiten die een invloed uitoefenen op de projectduur ook de vertragingen die als laatste voorkomen. Wanneer een vertraging wordt toegewezen, wordt D i vermindert met 1. ˆ Stap 3: het huidige critical path wordt vergeleken met dit van het vorige window om veranderingen na te gaan. Voor het eerste window wordt vergeleken met het as-planned schedule Waarbij: D i het aantal vertragingen in het ide window die een invloed op de projectduur hebben, 1 i n P D i de projectduur in het ide window n aantal windows in het project Dit wordt geïllustreerd met behulp van het voorbeeld project. In het eerste window (zie figuur 4.6) treden duidelijk een aantal vertragingen op. Er wordt eerst nagegaan hoeveel van deze vertragingen een invloed hebben. Aangezien zowel P D 1 als P D 0 gelijk zijn aan 6, is D 1 = 0. Er zijn geen veranderingen in het project opgetreden en dus ook geen vertragingen en dergelijke toe te wijzen, zoals te zien is in tabel 4.1.

Hoofdstuk 4. Eigen methode (WACC) 31 Figuur 4.6: Analyse van het eerste window met de WACC methode Het tweede window (zie figuur 4.7) is opnieuw een window met vertragingen. P D 2 = 7 en P D 1 = 6 waardoor D 2 = 1, er is dus een vertraging opgetreden die verantwoordelijk is voor een verlenging van de projectduur. Zoals duidelijk is uit het Gannt chart in figuur 4.7, liggen beide activiteiten op het critical path en beiden lopen hier een vertraging op. Er is dus sprake van een concurrent delay (zie tabel 4.1). Figuur 4.7: Analyse van het tweede window met de WACC methode In het derde window (zie figuur 4.8) vinden geen vertragingen plaats. Er zijn dus ook geen delays of veranderingen in het kritieke pad toe te wijzen. Ook de projectduur verandert niet. In het vierde window (zie figuur 4.9) is er daarentegen terug sprake van een vertraging. Aangezien de projectduur verandert (P D 4 = 8 en P D 3 = 7), moet een delay worden toegewezen die verantwoordelijk is voor deze projectvertraging. Er is slechts een critical path waarin een EN vertraging plaatsvindt. Deze vindt men dan ook terug in tabel 4.1. Ook in het vijfde window (zie figuur 4.10) treedt een EN delay op. De projectduur in dit window is gelijk aan 9, waaruit besloten kan worden dat deze EN vertraging hiervoor verantwoordelijk is (zie tabel 4.1).

Hoofdstuk 4. Eigen methode (WACC) 32 Figuur 4.8: Analyse van het derde window met de WACC methode Figuur 4.9: Analyse van het vierde window met de WACC methode Het zesde en tevens laatste window (zie figuur 4.11) is net zoals het derde window een window zonder vertragingen. Er zijn geen critical path changes en er verandert niks aan de projectduur. De resultaten van deze analyse worden voorgesteld in tabel 4.1. Deze is een samenvatting van de toegewezen vertragingen en veranderingen in het kritieke pad. Ze worden vergeleken met de vertragingen en critical path changes die werkelijk zijn voorgekomen. 4.1.3 Voor- en nadelen Uit de resultaten in tabel 4.1 blijkt duidelijk dat de WACC methode zowel de NE, EN en EC vertragingen de correcte verantwoordelijk geeft voor een verandering in de projectduur. Daarenboven worden de concurrent delays alsook de veranderingen in het critical path op een correcte wijze aangeduid. Hierbij maakt de WACC methode gebruikt van een kleiner aantal analyse periodes in vergelijking met de EDAM en DWDA methode, dewelke de enige ander methodes zijn die elke

Hoofdstuk 4. Eigen methode (WACC) 33 Figuur 4.10: Analyse van het vijfde window met de WACC methode Figuur 4.11: Analyse van het zesde window met de WACC methode toewijzing correct uitvoeren. Het gebeurt daarenboven allemaal op een real-time basis. Echter, deze real-time werkwijze kan ook een grote inspanning vragen om alle gegevens op tijd in te zamelen en te gebruiken om het huidige schema aan te passen. 4.2 Vergelijking In dit hoofdstuk werd een nieuwe windows-based delay analysis methode aangereikt, namelijk de WACC. Hier gaan we na in welke mate deze een verbetering is ten opzichte van de bestaande methodes. Om dit na te gaan worden zowel de verdeling van de windows als de resultaten van de verschillende methodes nogmaals gegeven in een samenvattende figuur en tabel (zie figuur 4.12 en tabel 4.2). In het vorige hoofdstuk werd gesteld dat een nieuwe methode moet voldoen aan een aantal criteria. Ten eerste was er het correct toewijzen van de verschillende delays alsook van de

Hoofdstuk 4. Eigen methode (WACC) 34 Tabel 4.1: Resultaten van de WACC methode toegepast op het voorbeeld project Type delay Timing Werkelijk voorgekomen WACC NE delay - - - EN delay 6 x x 7 x x EC delay - - - Concurrent delay 3 x x Critical path changes 2 x x 6 x x critical path changes. Vervolgens zijn ook het aantal analyse periodes van belang voor de efficiëntie van de methode. Ten laatste werd de mogelijkheid voor een real-time analyse aangehaald. Zoals blijkt uit tabel 4.2, is de WACC samen met de EDAM en de DWDA methode, de enige die in staat zijn om zowel normale vertragingen als concurrent delays en critical path changes correct op te merken. De TWA en MWA methode falen in elke categorie en de verandering in het kritieke pad vormen een hindernis voor de DAMUDS methode. Deze veranderingen in het critical path zijn echter wel van belang aangezien de activiteiten op het kritieke pad de projectduur bepalen en deze dus ook geen vertraging mogen oplopen. Wanneer verandering in dit pad niet correct worden opgemerkt, bestaat de kans dat belangrijke veranderingen in het project onopgemerkt blijven en dus incorrect worden toegewezen. Om een eerlijke vergelijking te kunnen doen, wordt voornamelijk rekening gehouden met de EDAM en de DWDA methode. Tegenover deze methodes is het duidelijk dat de WACC methode de meest efficiënte is. 4.3 Project acceleration In deze sectie wordt de mogelijkheid voor project acceleration onderzocht, er wordt nagegaan of en waar er mogelijkheden bestaan om het project te versnellen. Op het einde van elk window wordt gekeken naar mogelijkheden voor acceleration. Hierbij wordt enkel gekeken naar activiteiten die zich op het kritieke pad bevinden aangezien dit de activiteiten zijn die de totale projectduur bepalen. Een ingreep op activiteiten die niet op het critical path liggen heeft weinig zin, deze activiteiten bezitten namelijk al een zekere flexibiliteit en kunnen vertragingen al in zekere mate opvangen.

Hoofdstuk 4. Eigen methode (WACC) 35 Figuur 4.12: Samenvatting van de verschillende windows van de methodes aangevuld met de WACC Om optimaal gebruik te maken van een project versnelling moet, bij het bepalen van de duur van deze versnelling, rekening gehouden worden met de parallele paden. De path float op deze parallele paden dient te worden nagegaan, deze bepaalt namelijk mede de kans dat een pad in de toekomst kritiek zal worden. Om bovenstaande reden is het niet nuttig om bijvoorbeeld een activiteit op het kritieke pad drie dagen in te korten wanneer de path float op een parallel pad slechts een dag bedraagt. Het project zal namelijk maar met een dag versneld zijn. De duur van een versnelling zal dan ook beperkt worden tot de minimum path float van de parallele paden. Aangezien er geen gegevens zijn in verband met de kost van vertragingen en versnellingen, wordt hier eerst en vooral gekeken naar de eerstvolgende activiteiten. De effectiviteit wordt nagegaan door het aantal dagen dat het project werd versneld te vergelijken met de verandering in projectduur. In het geval deze gelijk zijn, werd er een effectiviteit van 100 procent gehaald.

Hoofdstuk 4. Eigen methode (WACC) 36 Tabel 4.2: Samenvatting van de resultaten van de verschillende methode aangevuld met de WACC, toegepast op het voorbeeld project Type delay Timing Werkelijk voorgekomen EDAM TWA/MWA DAMUDS DWDA WACC NE delay 1 - - 1 - - - EN delay 6 x x x x x x 7 x x x x x x EC delay - - - - - - - Concurrent 3 x x - x x x delay Critical path 2 x x - x x x changes 3 - - x - - - 6 x x - - x x 7 - - x x - - Analyse 7 4 5 9 6 periodes

Hoofdstuk 5 Resultaten In de vorige hoofdstukken werd gebruikt gemaakt van slechts een enkel voorbeeld om de resultaten van de verschillende methodes te vergelijken. Hieruit kon de conclusie genomen worden dat de WACC methode het beste resultaat gaf, dit voor zowel de correctheid als de efficiëntie van de methode. Echter, om aan te tonen dat dit geen toeval was, werd een Monte-Carlo simulatie uitgevoerd. Hiervoor werd eerst en vooral een programma in C++ geprogrammeerd die een automatische analyse van projecten op basis van de verschillende methodes mogelijk maakt. Er werden in totaal 746 projecten gesimuleerd met RanGen. Deze projecten variëren in hun S/P factor (zie sectie 5.2) en bestaan elk uit tien activiteiten. De verschillende vertragingen die optreden in het project werden in het C++ programma gegenereerd. Voor elke activiteit werd eerst het aantal vertragingen die gebeuren, opgevraagd. Dit varieert van geen vertragingen tot maximum drie. Daarna werd de categorie van de delay bepaald, namelijk een NE, EN of een EC vertragingen. Hierbij geldt de assumptie dat elke categorie slechts eenmaal kan voorkomen per activiteit. Als laatste wordt de duur van de vertragingen meegegeven. Ten eerste worden de resultaten van de uitgevoerde simulaties besproken. Er wordt nagegaan of de conclusies die in het vorige hoofdstuk gemaakt werden op basis van een voorbeeld project, ondersteund worden door een grotere simulatie studie. Daarna wordt het effect van de S/P factor op de efficiëntie en correctheid om de verschillende methodes nagegaan. 5.1 Simulaties Om te beginnen wordt gekeken naar de toewijzing van de de verschillende delays door de MWA, DAMUDS, DWDA, EDAM en ook de WACC methode. Zoals al duidelijk werd 37

Hoofdstuk 5. Resultaten 38 in hoofdstuk 3 en 4 door middel van het voorbeeld project, is dit een probleem voor de MWA methode. De andere methodes deden dit wel correct, zowel voor de NE, EN en de ECvertragingen. Aangezien de concurrent delays daarmee samengaan, wordt dit in de MWA methode niet correct weergegeven en wel door de andere methodes. In figuur 5.1 wordt geïllustreerd in welke mate deze NE vertragingen correct worden toegewezen door de verscheidene windows-based delay analysis methodes. In de vermelde grafiek wordt weergegeven welk percentage van vertragingen correct werd toegewezen. Hieruit blijkt dat, zoals al werd aangetoond met het voorbeeld project, de MWA methode inderdaad faalt om deze vertragingen correct toe te wijzen. De juistheid ligt slechts rond de 35 procent. De overige methodes halen hier 100 procent. Hetzelfde geldt voor zowel de NE, EN, EC en de concurrent delays. Figuur 5.1: Correctheid van de toewijzing van de NE vertragingen per methode, uitgedrukt in percentages Vervolgens wordt verder gegaan met de critical path changes. Aangezien niet elk project een verandering in het kritieke pad ondergaat, wordt in figuur 5.2 weergegeven in hoeveel projecten dit wel het geval is. Het is duidelijk dat dit een gelijke verdeling is. In wat verder volgt over de veranderingen in het kritieke pad, worden enkel de projecten waarin een critical path change voorkomt in beschouwing genomen. In wat volgt, wordt nagegaan in welke mate de verschillende delay analysis methodes deze veranderingen in het critical path kunnen opmerken. Figuur 5.3 geeft het aandeel van de projecten aan waarvoor een volledig correcte analyse van de critical path changes is gegeven. Zoals zichtbaar is dat voor de MWA methode een bedroevend laag getal, slechts in 18 procent geeft de MWA methode een correcte weergave van de veranderingen in het kritieke pad. Ook

Hoofdstuk 5. Resultaten 39 Figuur 5.2: Het aantal projecten waarin een critical path change optreedt, uitgedrukt in percentages de DAMUDS heeft hier een probleem mee. Alhoewel deze in 51 procent van de projecten correct is, is dit nog steeds problematisch. Figuur 5.3: Het aantal volledig correcte toewijzingen van critical path changes voor elke methode, uitgedrukt in percentages Omdat de MWA en DAMUDS methode de veranderingen in het critical path slechts in zo een beperkt aantal projecten volledig correct kan aanwijzen, wordt in figuur 5.4 ook de gedeeltelijke correctheid nagegaan. Er wordt ook dus in de projecten waarin geen volledig correcte analyse van de critical path changes is gedaan, gekeken naar het aantal enkele correcte veranderingen. Dit leidt tot een stijging van de juistheid tot 49 procent en 72 procent voor respectievelijk de MWA en de DAMUDS methode.

Hoofdstuk 5. Resultaten 40 Figuur 5.4: Het aantal correcte toewijzingen van critical path changes voor elke methode, uitgedrukt in percentages Vervolgens wordt gekeken naar het aantal windows dat elke methode nodig heeft om tot zijn resultaten te komen. Voor dit geldt de regel, hoe minder hoe beter. Het aantal windows bepaalt namelijk het aantal analyse periodes en dus de efficiëntie van de methode. Figuur 5.5: Het aantal windows in vergelijking met het aantal dagen in het project, uitgedrukt in een percentage In figuur 5.5 wordt het gemiddelde aantal windows van elke methode gegeven in verhouding tot de gemiddelde totale duur van een project. Aangezien de DWDA methode gebruik maakt van windows met de kleinst mogelijke duur, geeft dit 100 procent. Opvallend hierbij is het lage percentage voor de WACC methode, dat zelfs gelijk loopt met de MWA methode. Dit toont de grote verbetering aan die deze nieuwe methode heeft ten opzichte van de EDAM en

Hoofdstuk 5. Resultaten 41 DWDA methode. Alledrie wijzen ze alle vertragingen en veranderingen in een project correct aan, maar de WACC methode doet dit in bijna de helft van de analyse periodes. 5.2 S/P factor De S/P factor is een variabele die weergeeft in welke mate de activiteiten in een project elkaar in serie of in parallel opvolgen (Vanhoucke, 2012). Een project heeft een S/P factor = 0 indien alle activiteiten parallel van elkaar verlopen, in een project met S/P factor = 1 zijn al de activiteiten in serie geplaatst. In de gebruikte dataset van projecten varieert de S/P factor van 0,2 tot 1. Er wordt hier een aparte analyse van de resultaten gedaan op basis van de S/P factor omdat er een vermoeden is dat deze factor een invloed zal hebben op het aantal critical path changes en het aantal windows. Aangezien de S/P factor weinig tot geen invloed heeft op de vertragingen wordt hier onmiddellijk verder gegaan met de veranderingen in het kritieke pad. Er wordt opnieuw een onderscheid gemaakt tussen de projecten waarin geen veranderingen optreden en de projecten waarin wel een critical path change werd waargenomen. Dit wordt geïllustreerd in figuur 5.6. Figuur 5.6: Het aantal projecten waarin een critical path change optreedt, uitgedrukt in percentages, verdeeld op basis van de S/P factor Zoals te verwachten, is het aandeel van projecten met een verandering in het critical path groter naarmate de projecten meer parallel worden. In projecten met een meer serie-achtige opeenvolging, zijn er dan weer amper veranderingen in het kritieke pad op te merken.