Universiteit Gent

Faculteit Economie en Bedrijfskunde

Academiejaar 20132014

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

 Universiteit Gent

Faculteit Economie en Bedrijfskunde

Academiejaar 20132014

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 gere-
produceerd worden, mits bronvermelding.

Karen Van Crombrugghe

Woord vooraf

Dit eindwerk is de laatste stap die nog genomen moet worden om mijn diploma Handelsin-
genieur 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 proble-
men 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 vi

Lijst van figuren 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 critical path
CPM critical path method
DAMDUS delay analysis method using delay section
DS delay section
DWDA daily windows delay analysis
EC excusable compensable delay
EDAM effect-based delay analysis method
EF earliest finish
EN excusable non-compensable delay
ES earliest start
FIFO first in, first out
LF latest finish
LS latest start
MWA modified windows analysis
NE non-excusable delay
PF path float
S/P serial/parallel factor
TWA traditional windows analysis
WACC 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 gellustreerd . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.1 Windows op basis van de TWA en MWA methode toegepast op het voorbeeld
project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2 Delay section gellustreerd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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, uitge-
drukt 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 oor-

zaak 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 efficient
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 inefficienties van de huidige beschikbare methodes oplost.

1
Hoofdstuk 1. Inleiding 2

Vervolgens worden de beschikbare methodes en de voorgestelde methode vergeleken naar

efficientie op basis van de serial/parallel-factor (S/P factor). Er wordt nagegaan in welke
mate deze factor bepalend is voor de efficientie 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 op-
lost. 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 windows-
based 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 uitge-
voerd met de verschillende methodes. Hieruit worden een aantal conclusies genomen over de
efficientie 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, gedefinieerd en uitgewerkt. Dit heeft tot doel het verdere
onderzoek voor iedereen begrijpbaar te maken. Alles wordt gellustreerd 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

Duur Voorg.
Act.
(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

Soort Start
Act. Duur
delay dag
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 opeenvol-
gende 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 start- en 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 Pj )
EF i = ES i + duri

Waarbij:

Pj Verzameling van de voorgaande activiteiten van activiteit j

duri De duur van activiteit i

Hoofdstuk 2. Basisprincipes 6

Tabel 2.3: Earliest start en earliest finish toegepast op voorbeeld project

Duur Voorg.
Act. ES EF
(dag) act.
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 Sj )
LS i = LF i duri

Waarbij:

n Aantal activiteiten in het project

PD Project duur

Sj Verzameling van activiteiten die volgen op activiteit j

duri 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

Duur Voorg.
Act. ES EF LS LF
(dag) act.
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

Duur Voorg.
Act. ES EF LS LF PF
(dag) act.
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

Duur Voorg.
Act. ES EF LS LF PF CP
(dag) act.
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 op-
gedeeld worden in twee categorien in hoofde van de aannemer, namelijk excusable en non-
excusable 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 aan-
nemer. 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 on-
voorziene 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 gellustreerd

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, kun-
nen hierdoor hun path float opgebruiken en kritiek worden (Kraiem & Diekmann, 1987). Dit
gebeurt als gevolg van vertragingen in voorgaande activiteiten (de la Garza; Apirath Pratea-
pusanond & 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 initiele 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 vertra-
gingen is vaak complex en moeilijk te bepalen. Zoals beschreven door Arditi & Pattanakit-
chamroon (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 verantwoorde-
lijkheid. Hierdoor is een betrouwbare methode nodig die de effecten en oorzaken van project-
vertragingen correct en efficient 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 windows-

based 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 ge-
noemd 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 Ana-

lysis

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 vertra-
gingen 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 benvloeden

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 gedefinieeerde 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 verantwoor-
delijkheid 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 me-
thode 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 single-
occurred 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 gellustreerd 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. DS4 is een DS waarin meerdere vertragingen tegelijkertijd optreden.
Hoofdstuk 3. Window-based delay analysis 16

Figuur 3.2: Delay section gellustreerd

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 voor-
komen

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 vertra-
gingen, 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:

DSi ide DS in het project, 1 i n

Dj jde delay in het project, 1 j m

Dij jde delay in de ide DS

DurDSi duur van DS i

P Fk path float van activiteit k, k is activiteit waarin Dj gebeurt, 1 k t

CDi 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
categorien.

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 DS3
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 (Dj ) 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

DurDSi P Fk : 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
DurDSi > P Fk : 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
DurDS1 = 2 en P F1 = 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 DurDS4 = 2 en P F3 = 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 (Dj ) die aan de basis ligt
van de DS i

Stap 2: analyseer de gegevens na de aanpassing van het schema

Stap 3: Voor elke Dij wordt nagegaan of DurDSi > P Fk . Indien dit het geval is, wordt
CDi voor elke Dij die daaraan voldoet, verhoogt met 1

Stap 4: analyseren van CDi

CDi = 0: Geen enkele vertraging in deze DS heeft een invloed gehad op de pro-
jectduur. 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

CDi = 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.
CDi 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.

DS2 is hiervan een voorbeeld. Voor D21 geldt DurDS2 = 1 en P F1 = 0, voor D22 geldt
DurDS2 = 1 en P F2 = 0. Dit resulteert in een CD2 = 2 en dus een concurrent delay. Zowel
de NE vertraging in activiteit1 als de EC vertraging in activiteit2 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 toege-
wezen 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 samen-
vatting 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 intutieve 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 analy-

seren, 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 start- en eindtijd ervan zijn. Ook de
verantwoordelijke van elke delay wordt gedentificeerd.

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 Di = P Di1 geen verandering in de projectduur, de vertraging werd ongedaan

gemaakt door de beschikbare path float.
Hoofdstuk 3. Window-based delay analysis 23

P Di > P Di1 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 Di Projectduur gedurende windowi

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 uit-
gebreid 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 ver-
anderingen correct in kaart brengen. De MWA en de DAMUDS methode falen om de veran-
deringen 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 efficientie van een be-
paalde 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

Werkelijk
Type delay Timing EDAM TWA/MWA DAMUDS DWDA
voorgekomen
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 efficientie 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 windows-
based 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 tekortko-
mingen van de huidige beschikbare methodes.

De hieronder beschreven methode tracht de toewijzing van de verschillende vertragingen als-

ook 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 efficientie 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 me-
thodes. 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 as-
planned 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 gellustreerd. 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 vertra-
gingen 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 D0 , gebruikt
Di = P Di P Di1

Stap 2: toewijzen van deze Di vertragingen

Di = 0: zelfde analyse als voor een window zonder vertragingen

Di > 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, Di = 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 Di 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:

Di het aantal vertragingen in het ide window die een invloed op de projectduur hebben,
1in

P Di de projectduur in het ide window

n aantal windows in het project

Dit wordt gellustreerd 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 D1 als P D0 gelijk zijn aan 6, is
D1 = 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 D2 = 7 en
P D1 = 6 waardoor D2 = 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. Aan-
gezien de projectduur verandert (P D4 = 8 en P D3 = 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 verant-
woordelijk 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 win-
dow 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 ver-
gelijking 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
efficientie 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 belang-
rijke 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 efficiente 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 verge-
lijken 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
Werkelijk
Type delay Timing EDAM TWA/MWA DAMUDS DWDA WACC
voorgekomen
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 efficientie 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 varieren 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 efficientie 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 gellustreerd in welke mate deze NE vertragingen correct worden toege-
wezen 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 per-
centages

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 gedeelte-
lijke 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 ver-
anderingen. 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 efficientie 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 f actor = 0 indien
alle activiteiten parallel van elkaar verlopen, in een project met S/P f actor = 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 on-
middellijk 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 gellustreerd 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.
Hoofdstuk 5. Resultaten 42

Net zoals in de vorige paragraaf, wordt ook hier een onderscheid gemaakt tussen twee situaties.
Figuur 5.7 geeft weer in hoeveel projecten de verschillende methodes de critical path changes
volledig correct opmerken. Hier is een licht dalende trend te bemerken naarmate de projecten
meer parallel worden.

Figuur 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

Figuur 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

Daarentegen is er in figuur 5.8 een stijgende trend op te merken. Dit is te verklaren door het
feit dat er in de meer parallel opgebouwde projecten ook meer veranderingen in het kritieke
pad zullen voorkomen.
Hoofdstuk 5. Resultaten 43

Echter, de belangrijkste beoordelingsfactor is het aantal analyse periodes en dus het aantal
windows. Hierbij is vooral het verschil tussen de WACC methode en de EDAM en DAMUDS
methode van belang aangezien zij als enige een correcte toewijzing van het volledige project
ondersteunen.

Door Yang & Kao (2012) werd het kleine aantal windows van de EDAM methode tegenover de
DWDA methode geprezen. Echter, er was een vermoeden dat dit verschil sterk zou minderen
naarmate projecten op een meer parallele wijze zijn opgebouwd. Dit wordt bevestigd in figuur
5.9.

Figuur 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

Daarenboven is de efficientie van de WACC methode duidelijk in figuur 5.9. Voor om het even
welke S/P factor, heeft de WACC methode slechts de helft van het aantal analyse periodes
nodig ten opzichte van de EDAM methode.

Bovenstaande vergelijkingen hebben duidelijk aangetoond dat de nieuw voorgestelde methode,

de WACC methode, duidelijk een verbetering is van de voorgaande methodes. Zelfs ten
opzichte van de meest recente, en tot voor kort de beste methode, is de WACC een duidelijke
verbetering.
Bibliografie

D. Arditi & T. Pattanakitchamroon (2006). Selecting a delay analysis method in resolving

construction claims. International Journal of Project Management, 24(2):145155.

D. W. Bordoli & A. N. Baldwin (1998). A methodology for assessing construction project

delays. Construction Management and Economics, 16(5):327337.

J. M. de la Garza; Apirath Prateapusanond & N. Ambani (2007). Allocation of total path

float in the application of a critical path method based construction contract. Journal of
Construcion Engineering and Management, 133:836845.

K. D. Gothandi (2003). Schedule delay analysis: modified windows approach. Cost Enginee-
ring, 45(9):1823.

T. Hegazy & K. Zang (2005). Daily windows delay analysis. Journal of Construcion Engi-
neering and Management, 131:505512.

C.-K. Kao & J.-B. Yang (2009). Comparision of windows-based delay analysis methods.
International Journal of Project Management, 27:408418.

Y. K. K. Kim & D. Shin (2005). Delay analysis method using delay section. Journal of
Construcion Engineering and Management, 131:11551164.

Z. M. Kraiem & J. E. Diekmann (1987). Concurrent delays in construction projects. Journal

of Construction Engineering and Management, 113:591602.

S. B. Mohan & K. S. Al-Gahtani (2006). Current delay analysis techniques and improvements.
Cost Engineering, 48(9):1221.

J. K. Pinto (2010). Project Management: Achieving competitive advantage. Pearson, second

edition.

R. A. Rubin, S. D. Guy, A. C. Maevis & V. Fairweather (1983). Construction claims: Analysis,

presentation, defense. Van Nostrand Reinhold, New York.

M. Vanhoucke (2012). Project management with dynamic scheduling: Baseline scheduling,

risk analysis and project control. Springer.

44
Bibliografie 45

J.-B. Yang & C.-K. Kao (2012). Critical path effect based delay analysis method for con-
struction projects. International Journal of Project Management, 30:385397.