Common Sense has flown out the Windows

Why do planners apply the rules blindly and forget to just look at their work and apply a judgemental view of the results - just a bit of common sense.

Just because you have followed the books and collected all the event data and formed a dinky little fragnet and you know which programme event is to be impacted it does not mean that the answer is the right one.

If it doesn't look right then it is probably wrong.

At this stage of my career I have formed a healthy cynical view of established methods of delay analysis - especially those that rely on impacted events - the more complex the less I like them.

There are practical reasons for my jaundiced view because when defending it is so easy to pull out a few props and watch the whole impacted edifice come crashing down.

It starts with the baseline and the easiest way to defeat a claim is to show that the baseline is flawed. This can be done simply by pointing out that the wrong baseline has been used. Another prop is flawed logic or better still rigged logic. If there is more than one critical path then it has been rigged.

Then the As Built data. It is usually derived from inadequate records so it is often easy to cut through monthly programme reports from programme droplines which are just too broad to be of much use. One dated photograph or a concrete cube test will often weaken the credibility of As Built data. QA/QC reports are a rich source of such data.

Next are the scheduled events that are used to impact the delay - how often are they not even relevent events? And where are the neutral events such as weather? How often are the Contractor's own events put into the causal nexus?

Just one or two of these common sense adjustments are sufficient to bring down an impacted EoT.

This is why I now rarely use any of the standard four reccomended methods but I have gone back to the days when I used graph paper and coloured crayons (no colour sticks in those days) to show the effect of a delay event.

Just a few coloured lines will do the trick:

1. The position of the impacted task on the planned chart.
2. The period of time to complete the remaining work shown in one bar.
3. The as built duration of the task - just the date of completion will do extended from the planned duration.
4. Indication of the relevant event date and duration between the as planned and as built lines.
5. Transfer of the duration to complete bar to the last date of the As Built end or the end of the Relevant event - whichever is the earliest.

And that is a simple common sense approach that even a judge can understand - they do not like being bamboozled.

I have called the method Projected as Built to make it look professional although in fact it is the basis of the original method used by the US Corps of Engineers to establish time delays during the monthly progress meetings - which then developed into the Windows method and common sense went out.