The basic concept of a but-for analysis is not difficult to comprehend, but the actual procedure can become quite complex. In the basic model we are identifying the delay element(s), proving it, quantifying it, and assigning cause/those responsible for the cause and then removing the time period from cause initiation to recovery (time delay period).
The above is, of course greatly simplified. In the real world, over the course of an entire project there are many activities that are connected with real enacted logic. There are most likely many individual and interconnected delay logic sequences (fragnets) that have affected various in-scope network paths which must all be dealt with. This can become a huge research project and requires quality documentation.
To Do This Correctly, You Will Need:
You will also need a sizable budget and time to do the work, sometimes months.
|A fully-progressed or as-built schedule. Complete with as-enacted relationships.|
|Quality Daily Field Reports with schedule notation and a means to identify activities. At least Decent reports.|
|Lots of time to read the reports and use them to verify/correct schedule dates and identify issues.|
|Other supporting documents, such as:|
|Well-coded timesheets (with connection to schedule activities)|
|Impact Documents and RFIs|
|Change Orders with associated drawings/sketches|
|Change and or Impact documentation (Issue files, if the exist)|
|Weekly crew assignments and 3-week look-ahead charts/lists|
|Jobsite meeting minutes|
Documents to read on this subject:
|Delay Analysis Process.pdf|
|Stepping Through a But-For Process.pdf|