In delay claims the conventional analysis method requires the prior identification of delay causes. The “snapshot” technique provides an alternative method whereby a comparison is made at selected keystone dates between the schedule in effect at the start of each period experiencing delay and the extended duration schedule at the end of the period. This technique greatly helps in the determination of the length of delays and of the corresponding causes and responsibilities. Its execution is “computer friendly”.
An owner hires a contractor to build a building for a fixed price and within a one-year period. A contract is signed. The contractor submits his schedule for the project. Work proceeds. Eighteen months later the building is completed. The contractor claims cost overruns due to owner-caused delay. The owner claims costs from the contractor due to late occupancy. The problem: how to determine the cause or causes of the six months’ delay.
There are many parties involved: the owner, the contractor, the architect, the engineer, other contractors, the municipality—even God himself (i.e. delay caused by an “Act of God”). There are even more potential causes of delay: strikes, material shortages, equipment failure, design changes, rework, poor organization, and weather—to name just a few. There may be more than one cause of delay occurring at the same time. It quickly becomes an almost insurmountable task to assess the cause or causes of delay on a global basis. A systematic approach is required.
Conventional Method
The conventional method of delay analysis requires at the outset that the events that caused delay be identified. Each delay-causing event is analyzed individually. The schedule in effect immediately prior to the event is modified by incorporating revised durations into all those remaining activities directly affected by the event in question. The schedule is recalculated and the projected completion date is compared with the projected completion date prior to the incorporation of the delay. The difference between these two dates is the delay to the project caused by the event under consideration.
The above method is simple to apply and widely used; however, it does have a number of shortcomings.
Firstly, you have to know before you start, not only what the causes of delay on the project were, but also how much delay resulted from each cause. Neither of these is self-evident. The subjectivity inherent in determining the causes and amount of delay may undermine the entire analysis.
Secondly, this technique does not address concurrent delays. The amount of delay to the project is assessed independently for each delay-causing event.
The third—and most serious—drawback of the conventional method of delay analysis is that it disregards the impact of a delay to one activity on other indirectly affected activities. This can often result in a serious underestimation of the total impact a delay-causing event has on a project schedule.
The Snapshot Technique
Snapshot Analysis is a delay analysis technique used to determine the amount of delay that has occurred on a project, when the delay occurred, and the cause or causes of the delay.
This method approaches the problem from the opposite perspective to that of the conventional method of delay analysis: instead of asking the question, “This event occurred; what delay did it cause to the project?”, Snapshot Analysis asks, “This delay occurred; what event or events caused it?”
The analysis is based upon the original—or “As-Planned”—schedule; the actual—or “As-Built”—schedule; and any revised schedules that may have been implemented during the execution of the project.
In our earlier building example, six months’ delay occurred. What caused it? On a large complex job, it is next to impossible to come up with a meaningful answer to the question without breaking it down further.
The total project duration is therefore divided into a number of time periods. For each time period, the amount of delay that occurred within that time period is determined, and the causes of the delay are assessed.
The breakdown of the project duration into time periods is achieved by the selection of a series of dates. Each date represents the end of one period and the beginning of the subsequent period. The dates are selected to coincide with major project milestones, including the implementation of significant changes in planning, and to isolate known major delays or groups of delays.
The first time period under consideration is the time period from the beginning of the job to the first date selected as described above.
The project completion status at the end of this time period is determined from the As-Built schedule, taking, so to speak, a snapshot of the project. The schedule for the uncompleted portion of the work is projected to completion according to the schedule in effect at the beginning of the time period, which for this first period is the As-Planned schedule. This projected schedule at the Snapshot date is referred to as the Extended Duration schedule. The project completion date in the As-Planned schedule is compared with the project completion date in the Extended Duration schedule. In other words, the projected completion date at the beginning of the period is compared with the projected completion date at the end of the period. The difference between these two dates is the delay to the project that occurred during the period. Once the amount of delay that occurred during the period is known, the causes of this delay are assessed.
For example, let us say that at the end of the first two months the contractor had only executed the work he had originally planned to execute in the first five weeks. The last day of the second month is therefore the Snapshot date. The information shown prior to this date is historic information and forms part of the As-Built schedule. The information shown subsequent to this date is future planning and comes from the contractor’s As-Planned schedule. When we calculate the critical path for this new Snapshot schedule, we generate a new completion date and the completion date shown on the contractor’s original As-Planned schedule is the delay that has occurred during the time period from the beginning of the job to the first Snapshot date. In the present example, a three-week delay has occurred during the first two months of the job.
Where the Extended Duration schedule pushes the project completion date beyond the previously projected completion date and into either a period of inclement weather or a vacation period, an adjustment is required. In the first case, the durations of those activities occurring during inclement weather periods are increased to reflect the anticipated loss of productivity due to weather. In the second case, the project calendar is prolonged and non-working days are identified as such. It is possible that, as the result of either of the above situations, the total delay to the project completion incurred during a particular period can exceed the duration of the period itself, i.e. the events that occur during a four-week period can actually cause a five-week delay to the project completion.
Causes of the Delays
We have now determined objectively how much delay occurred during the first time period. The next step is to determine the cause or causes of this delay. A detailed analysis of the events that occurred during the time period should reveal the causes of delay. A comparison of the As-Planned schedule with the As-Built schedule for the time period under study can be very revealing.
For example, the contractor may have mobilized according to schedule; however, excavation took one week longer than originally planned due to heavy rains in the fourth and fifth weeks. No work was accomplished on the concrete footings because a design change delayed the release of the construction drawings. The contractor was behind schedule but could have regained the time by mobilizing additional equipment. The Extended Duration schedule shows a project completion date three weeks later than the original planned completion date. We have two parallel delays, the net effect of which is a three-week delay to the completion date of the project. Because the cause of each delay is known, the relevant importance can be assessed and responsibility for the net delay apportioned accordingly.
The determination of the cause or causes of delay becomes significantly easier when the time period under consideration is shorter and the amount of delay is known.
The first Snapshot is now complete. Both the amount of delay and the causes of delay have been determined for the first two-month period of the job. We are now ready to go on to the analysis of the second time period.
Changes in the Plan
The first step—and a critical step—is the verification of the Extended Duration schedule. If this schedule is no longer valid because of a change in planning, the schedule is revised to reflect the planning in effect on the project at the point in time under consideration. The difference between the projected completion date shown on the Extended Duration schedule on a Snapshot date and the Revised Schedule on the same Snapshot date is an indication of the amount of acceleration (or relaxation) achieved through the change in planning.
In the case of owner-caused delays, the contractor has an obligation to mitigate the ultimate damages, i.e. delays. If this can be done through resequencing with no additional cost to the contractor, then he must revise his schedule according.
In our example, we know the project was running three weeks late on the Snapshot date. Was there a change in planning to regain this time? Let’s assume that our contractor adopted an accelerated schedule to bring the job back on schedule. We revise our Extended Duration schedule accordingly. This “Revised Schedule” forms the basis of comparison for the second Snapshot.
The delay analysis is continued progressively through each of the periods defined by the selection of the Snapshot dates. The total delay to the project is calculated by adding up the individual delays associated with the various periods, disregarding any time that might have been gained through acceleration. The so-accumulated total delay time represents the total extended duration which is then analyzed for responsibility apportionment between owner and contractor, or designated as excusable, depending on the terms of the contract. The so-determined total delay is, however, not necessarily the basis of damage quantification. For calculating extended duration or acceleration costs, the extent of acceleration should also be considered.
This technique is intended to be used in after-the-fact delay analysis in that the analysis is based on the actual job progress immediately after the delay in question.
The As-Planned schedule and revisions to this schedule, and the As-Built schedule, form part of the job record. These can be agreed upon as fact by both parties involved in a delay dispute. The argument can therefore be limited to assessing the cause of the known delay in each of the periods developed during the Snapshot analysis.
This structuring of the issues is perhaps the greatest service afforded by Snapshot analysis. The delay measured is actual delay, not estimated delay. As such it encompasses all delay—both direct and indirect—experienced on the project. Subjective and usually inaccurate estimates of the impact of a delay-causing event on unaffected work are not required and form no part of this method of delay analysis.
Snapshot Technique Computer Friendly.
The snapshot method of delay analysis takes full advantage of the computer programs currently available for data base management and project planning.
The As-Built schedule is developed from the job records including diaries, correspondence and minutes of meetings. Relevant information is extracted from these documents, coded and entered into a computer file. Each record includes the date, the source document, one or more subject or area codes, and a code to relate the information to the appropriate activity of the As-Built schedule. The data is entered in the same order as it is reviewed by the analyst or technician. Once the coding system is established, a team can be mobilized to complete the document review in the available time.
The data is then sorted and summarized in the computer to yield a list of actual start and finish dates for the activities on the As-Built schedule. This information is transferred by batch process to the project management software that is used to develop the project schedules.
A chronological listing of the data extracted for the job records forms the basis of a statement of facts for the project. The coding system enables this statement of facts to be regenerated by subject. It therefore becomes a valuable tool to all parties involved in the project.
The As-Planned schedule, if not already in CPM format, is converted into CPM format.
The above two schedules must be co-related. The means of co-relation is determined by the particular program selected. The simplest method of co-relation from the computer’s point of view is via a common list of activities for the two schedules. Given the divergence of the two schedules, particularly on jobs requiring delay analysis, there is often not a good co-relation possible between sets of activities. The option to co-relate activities by activity codes is most desirable; however, it is not often available.
A “pattern” for the schedule at the first Snapshot date is made by duplicating the As-Planned schedule. A computerized sort is performed on the As-Built schedule to identify all activities having an actual start date prior to the Snapshot date. For those activities whose actual finish date is also prior to the Snapshot date, the actual dates are fed into the above “pattern”, to create an updated schedule in effect on the Snapshot date. Those activities started but not completed as of the Snapshot date require special attention. Someone familiar with the job must evaluate the remaining duration of these activities, based on the schedule in effect at the beginning of the period. Once this information has been in-put, the updated schedule is recalculated to yield the extended duration schedule.
The Extended Duration schedule is revised (if required) to reflect any change in planning, and is then duplicated to form the pattern for the Extended Duration schedule at the next Snapshot date.
The process is repeated.
The graphic capabilities of project management software greatly facilitate the comparison of the schedule in effect at the beginning of a period with the Extended Duration schedule at the end of a period. This visualization of the difference between the planned dates and the actual dates for each activity is extremely helpful in assessing the causes of delay within a period.
Project Simulation
The schedule analysis is only a means to an end. The ultimate objective is to determine the cost implications of unforeseen events. The Snapshot method measures only the impact on time of unforeseen events. The analyst must then go on and quantify the cost implications of the delay. The inclusion of resource and cost data for each activity in the As-Planned schedule would further enhance the application of this technique by generating a financial model for the project. The calculation of the Extended Duration schedule would then yield the impact on the total cost of the project, as well as the impact on the schedule. Certainly, the tools required to perform this enhanced analysis are currently available. The maintenance of pertinent job records will greatly facilitate the application of the snapshot technique. Yet another reason for maintaining the adequate records!
Conclusion
Snapshot Analysis offers a systematic and objective method of quantifying the amount of delay incurred on a project on a progressive basis. It greatly facilitates the task of assessing the causes of delay and the corresponding responsibility for the delay. The measurement of the amount of delay is inclusive of both the direct and indirect consequences of a delay-causing event. The method lends itself well to a computerized analysis, taking full advantage of the features currently available in project management software.
LORNA M. TARDIF, eng., MBA
Lorna Tardif graduated from McGill University with a civil engineering degree in 1975. A Senior Consultant with RAL, Montreal, she is responsible for the Estimating Department and network analyses and is actively involved in claims preparation work. As a professional background to such activities, she has a decade of experience in heavy engineering construction on major projects with major companies in Trois Rivières, Long Spruce, Baie James, Revelstoke and Montreal.
