Aren't "windows" delay analysis flawed by the common condensing of schedule as schedule goes on? - Do if the project is complete and you have 5 delays at 20 days each, but he job is only 20 days late - couldn't you just prorate each delay - because none should get credit for other changes to bring it back onto "close to" schedule?
Aren't "windows" delay analysis flawed by the common condensing of schedule as schedule goes on?
Forum Sponsor
Top Posters
Julian Pegg
1 posts
Peter Nagy
2 posts
Raymund de Laza
17 posts
Syed_Asad
0 posts
Tony Greyvenstein
0 posts
Ahmed Al-Jubouri
13 posts
Umar Alvi
3 posts
Sibusiso Mahlalela
0 posts
Michael Samanyayi
3 posts
Simon Gumede
0 posts
Thank you very much for the comment, that is what makes this site great! I am dealing with a contractor doing Windows analysis and the total of the Windows adds to up to more than the project is delayed. Not sure yet, if it is concurrency, logic changes or yet, but that is why I asked if a contractor should be given the day "due" or the days "necessary" when it is showing less.
The 'windows' approach to delay analysis is supported by AACEi and many legal precedents. BUT the delay within the time window does need to be shown to cause a delay to the completoin of the project: Costain Limited -and- Charles Haswell & Partners Limited 2009] EWHC B25 (TCC). See: https://mosaicprojects.com.au/PDF_Papers/P035_Assessing_Delays.pdf