Philip,

This is a debate, I know I am sometimes probably cross the line in some of my postings, but hey, hopefully it may stimulate some interesing responses, further debate and deliberation.

Is it just me or has the site had a few problems with posts recently - a few seem to be missing.

Hi Andrew,

In your example, what is the situation on day 12 and afterwards. Both activities are completed and therefore no longer critical. Also as they were both freestanding activities, there was no logical path involved. So what you are looking at any time after day 11 is history. This seems to be proof that the ABCP is a figment of the imagination.

Just to go a bit further, if you have a chain/path of activities through the schedule, and all the activities end up being completed on or within time, except one activity, which has major problems during it’s execution. Two scenarios is possible, the whole chain could go critical, or it may not. When it does go critical is the whole chain then treated as the ABCP? Or, if it does not go critical, is the problems, with the single activity, ignored? An interesting dilemma.

Regards

Philip

Gerry

Lets just call it history so we can stop worrying about the name. (I actually think history’s quite a good name) I think we all know what we’re are on about, just some people on here seem to like splitting hairs and focusing on word play instead of discussing the bigger picture - probably reflected in thier attitude to planning and or analysis as well!

I think by now that most have agreed that the ABCwhatever is the series of events or activities that turned out to be critical to the overall duration of the project.

At any given time in the life of a project an activity or activities will be critical in determining the overall duration of the project. The sequence, path, whatever of these activities will form the ABCH.

Can we all agree on this? (or not!)

Roger,

Thanks for your interesting post. I’d like to respond:

1. You are obviously right, there are no explicit provisions in the Contract regarding which method to use. However, I usually look in the contract for clues which may point me in the right direction by posing two questions relevant to our discussion:
a. what is the most apropriate point in time in which the analysis should be carried out? (in Australia the most frequent answer would be "when the Contractor became aware of the delay")
b. what is the most appropriate DA method? (to me the TIA method is more consistent with the contract provisions of most standards forms in Australia than any other method).

2. There could be a terminology problem here. My understanding of the ’Windows’ method is this method which combines pieces of the critical path at different time windows during the project (from one ststus to the next) into one ’Global’ programme. GF calles it Montage. I am familiar with the term ’progressive Critical Path’. If my understanding is correct the product of this analysis is one programme which suppose to represent the CP at different times during the project. Please correct me if I’m wrong.

4. The reality check is valid, however, this is not my point.

4a. Could you please tell me how many programmes are being compared under the AB v AP method? If your answer would be ’one’ we have a problem since in most projects (especially the more complicated ones, where there are more chances of delays) the CP changes during the project. How can you see the previous CP?

4b. In the ’windows’ analysis that I’ve seen the analyst compared only one ’Global’ programme (which was combined of many staus programmes to a montage) to the AP to find out the delays. Is this wrong? If it is right, then the impact of the delays on the date of PC at the time of the delay can not be found since you are using a different programme.

Gary,

I have several issues with your post #22 (dated 9 April).

1. What bothers me the most is that it ignores completely the Contract between the parties. To me this is the most important reference, and any choice of DA method should be directed by and well supported in the contract.

2. I do not agree that this "Windows" or what I believe some people call "Progressive Critical Path" method is ’perfectly reasonable to use’. The problem with this method is that the critical path produced is nor the ’actual’ CP neither the critical path leading to completion at the time of the delay. Delay analysis should include the impact of the delay on the date of PC, which you can not really figure out with this "Windows" critical path.

3. I was wondering whether "what people believed was the critical path at the time" should rather be "what people should have believed (having the information that they had at the time) the critical path should have been". This is not only semantics, as there could be big differences!

4. I think the main difference between the two main approaches (what Roger Gibson calles the ’retrospective’ and the ’prospective’ or perhaps more simply ’backward’ and ’forward’) is that in the ’backward’ approach (AB v AP or the Windows) there is only one programme and therefore one "Global" Critical path whereas in the ’forward’ approach (TIA) there are as many critical paths as the point of analysis.

I’ll save some point for later.

Thank you Gary,
Agreed.
Regards
Philip

Hi Gary
The theorists are the so-called planners that sit behind their computers all day, instead of taking a walk, whether around the site, or to the draughtsman’s office, or to the design engineer’s office, etc, to find the true state of the project. They worry about critical paths, float, reports, etc instead of focusing on the job at hand, and trying to manage it to finish on time. Try and read Sun Tzu - "The Art of War" and you will understand that although planning is seemingly complicated, it is in fact very simplistic, but it requires experience and thought.
Regards
Philip

Philip,

I am intrigued by your last post. Who are the theorist’s and what are they trying to hijack?

Gary

Hi Joshi,

Machiavelli was an ancient statesman and writer of Florence, Italy who lived in 1469 to 1527, and is known for being cunning and unprincipled, it is common usage in the English/International language to refer to Machiavelli,as he set some rules in the world.

If you prefer, let’s take Mao Tse-Tung, who wrote a lot, but plagiarised Sun Tzu.

Life is about history. The first planning principles was written by Sun Tzu in his book "The Art of War", which sets the principles for modern day planning in that history/experience is the greatest teacher in planning the future.

Hope this explains what I was saying.

Sorry to the rest of you guys, who probably knew about Machiavelli.

Regards

Philip

David,

While agreeing with most of what you wrote, I’d just like to nitpick a bit with "a path is the ’route’ through the project from start to finish."

If you mean the start to finish of the path, fine. But I’d like to mention that some paths sometimes emerge only in mid-project: product scope changes, re-work, or what in the nuclear industry is sometimes called "emergent work." And such a path can sometimes wind up being the critical path.

And Gary, I just wanted to say that your last post sounds like the basis for an interesting article.

This ABCP (path) or ABCH (history) debate has now progressed to another level and this is most welcome. One of the subjects recently discussed below is worthy of more debate. This is whether the retrospective delay analyst should look at the actual critical path that ran through the completed project, or whether he/she should consider what the critical path was forecast to be at the time.

We need to be very careful here for this is a crucial point in retrospective delay analysis.

In his paper “How to Manually Determine the As-Built Critical Path” that Ron kindly provides a link to below, he quotes Kenji Hoshino who “proposed a simple look-ahead method using planned activity float…..[using] the predicted critical path from each successive update period and sort of paste each period together to create a montage of predicted critical paths.” This I believe is describing what is often referred to as the “Windows” method of analysing the delay to a project. In has paper, Ron goes on to say that “This may be a good approximation of the actual critical path, but this technique only explains what was supposed to happen, not what actually did”.

This is the crucial point. It raises one fundamental point about forensic delay analysis work as to whether the person undertaking a retrospective delay analysis should consider (1) what was the actual critical path or (2) what people believed was the critical path at the time.

Stephen, Andrew and Vladimir rightly mention this below and that critical paths change. Clearly, determining what was the actual critical path is often very important as it determines what actually happened, but often understanding what people believed the critical path was at the time is equally as important. So why is this crucial difference important?

We all know that something may have been critical at the time, but an event, or series of events, that occurred later, may have resulted in the critical path shifting, making the activity that people believed at the time was critical, actually non-critical. That is a simple fact of life. Often, in retrospective delay analysis work, you need to consider if a party to the contract acted reasonably given what they knew at the time. This means that determining the actual critical path is not the only thing that must be done. Under these circumstances of needing to consider what people knew at the time, it is perfectly reasonable to use the “windows” method of delay analysis, whereby the delay analyst creates a series of snapshots showing where the critical path was believed to be at the time.

This then leads onto the question posed by David Barry in another thread entitled “Delay Analysis Methods” where he posed the question “What is the most effective / reliable delay analysis methodology?” This is a difficult question to answer, in that it depends upon what you are trying to achieve in your delay analysis work. Often, when starting out on forensic delay work, you don’t know what you are going to need to determine / give an opinion on and therefore it is difficult to select the most appropriate method to be used at the beginning of your work. You have to have an open mind on this. It is often un-wise to select the delay analysis method early in your deliberations.

My final point is about how important is all of this? In my experience, the selection of which method to use is nowhere as important as the research that must be done to understand the facts of what happened. After all, the method chosen and the software used are only tools. There is no substitute for spending the greatest proportion of your time in analysing the facts. Use whatever method, or indeed methods, you think are best suited to what you are trying to achieve.

Gary France

Hi Guys,

Lets not go the Miachiavellian route. I like the title ABCH, but lets just try something like retrospective analysis, as the forensic planners, ie the pathologigists/morticians take over from there.

It can.
If you will create user defined activity field and put there some symbol indicating that an activity is critical at the time of project scheduling. It can be done using formulae. Filtering the project you will receive a set of activities that were considered critical during project execution.
Spider Project users keep project history and can open any project file that was actual at any time in the past.

Andrew,
information may be correct at the moment, but risk events may change project situation. Critical path may change due to many expected and unexpected factors.
Vladimir

Andrew, just want to register as completely agreeing with your points in your last post re the importance of understanding:

1. What the beliefs were at a given time that caused a decision to be made.

2. What the ACTUAL situation was, irrespective of the belief.

Ron,

Read your article with interest and you obviously choose to work your analysis backwards in time which gives you what was critical on each date.

Who supports working backwards in time to give what was actually critical or working forwards in time to give what was critical at the time and thought to be critical in the future.

I had a long discussion on this subject recently with two others of opposing views but both had thier merits.

Determining what turned out to be critical gives insight on how the contract progressed or sometimes, should have progressed.

Determining what was critical on a date and thought to be critical in the future gives insight into why certain decisions were made even if future events conspired to change what was thought to be critical to that which was not.

No, that does not describe the technique that I use to determine the day-to-day As-Built critical path. Working on the principal that the critical path is only known on the actual data date, I progressively move back the data date, adjust the status of all activities, re-compute the critical path, and then note what was critical.

I presented this technique at last year’s AACEi annual convention with a paper titled, “How to Manually Determine the As-Built Critical Path.

The article is posted on my website at http://www.ronwinterconsulting.com/published.htm.

Phillip,

Still waiting, you’re not usually this quite!!!!

Phillip,

Still waiting for an answer?

There is such thing as Resource Critical Path (also known as Critical Chain) where activities may be not linked with each other. Due to resource, supplies or financial constraints activities that are critical may constitute critical sequence (chain, path) even without logical depencies links.
A history of what activities were critical during project execution shall be stored.
I think that project history shall be stored in any case and project model that existed in the past shall be able to be opened and investigated. During project execution it is necessary to be able to compare not only current version and baseline, but also current version with the project version that existed one week (month, year ago). It is useful for trend analysis and estimating project performance.
Vladimir