If I understand your problem correctly, why dont you filter all your activities that you require a answer for,copy it into excell and subtract your actual finish from your Target finish, that would give you your delays and then you can even give reasons why delayed etc.

Hope I understood your problem correctly.

Mohamed,

Unless I am missing something here, what you are looking for should be pretty simple.

Its a commomn practice to keep various versions of the schedule, including the very first one (popularly known as Baseline), before any progress data was added.

Select the version you want to compare with your current schedule. Copy this schedule in the folder where your current schedule is residing.

(Following is the tricky bit). Make the old version as your current schedule and assign the actual current as Target 1 to this schedule.

You can now filter all the critical activities and compare them by adding another bar for the assigned Target. You could also have various current and target values in the columns for easy comparision.

This should work unless you have addedd significant number of activities since the version you are using to compare.

Hope that helps,

AWADOOD SIDDIQUI

Mohamed,

The way most analysts determine if completed activities were on the critical path is to take two known points and interpolate between them. In this case, look at the most recent schedule submitted just before the activities in question were statused. What was on the critical path? Then take a look at the next schedule and ask yourself the same question. Now, connect the two events in your mind.

The actual critical path should have started with the active, critical activity or activities in the early schedule and end at the critical activity or activities in the later schedule. The activities in the logical chain between these two activities should reasonably be inferred to have been critical as well.

Of course, this reasoning doesn’t always work. The two active and critical activities might not even be in the same logical chain. The later schedule might have new logic or an unexpected added event that changed everything. That is where you need to go day-by-day using the logs and logic in determining the actual critical path.

There is another way, but I hesitate to mention it. It works extremely well and is easy to use. It is fairly new but professional delay analysts are beginning to use it even in court situations. The problem with me mentioning it is that I am the developer and I hate people pushing advertisements into this forum. It is called Schedule Analyzer Schedule Destatuser. Destatuser takes a completed P3 schedule and ‘walks’ it backward day-by-day to uncover the actual critical path. You can read more about this on www.RonWinterConsulting.com. Good luck!

Hi,

The subject chosen is very interesting and tricky as well. As I understand the question is how do we separate the “Net delay” caused by the employer particularly reviewing a submittal for approval?

In my opinion to start with I am in agreement with Mr. Ronald’s comment. We need to identify the path, which are critical or approaching critical i.e. Negative float.

In our project the contract specifies 21 calendar days for review for approval and 14 calendar days for resubmitting back to the engineer.

So I suggest for a given set of activities which needs window analysis, we need to make a tabulated format with headings baseline activity, AS, AF, Actual Dur (Y), Duration allowed as per baseline (X), Gain or Loss, Employer risk event. The columns Gain or Loss = X-Y and ERE = Cumulative days of delay contributed by the employer.

In conclusion if for example the negative float got is –60days and the employer delay is –40 days then we are entitled to claim only 40 days.

Regards to all,

The first question you have to ask yourself is, “why do you have to show the net negative delay impact resulting from the owners extended durations in reviewing/approving submittals?” Did any of these late reviews actually delay the completion of the project or was the Owner just using up some project float?

Then you need to address what your contract and specifications say about this situation. In most cases, Step 1 is almost always notification of potential claim. Analysis independent of the contract requirements is perhaps wasted time. Good luck!