As Built Critical History.

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.

Hi Andrew,



Understand this as a debate. whatever you want to say, say it, and I will reply.

Regards my friend

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

Philip (with one l )



After these activities finish something else will be critical and so on until project completion - you seem unable to grasp the concept that at any given time there will always be an activity or activites that are critical, what has been critical is a matter of fact. As stated before and my example shows, they do not have to be linked by logic or form part of any continuous chain (and very often don’t)



To answer your points:



Yes, we are looking at history - AS BUILT is historical, you can’t have a future tense as built!!!!!! As built has happened by defintion - it has been built, therefore is a historical fact.



If, as in your example, one activity is extended which then goes critical, it will only affect those activities that proceed it. Whatever the critical path was prior to that event (a matter of historical fact) will remain the critical path to that point. The critical path after that point may change or remain the same depending on the effect of the event. The fact it changes a string of activities prior to the event to critical on your computer programme does not change what was critical up to that point in time, it’s just a querk of the software.



This actually brings me back to my point that computer software is only an aid to planning or analysis - accepting it results on face value can lead to the wrong conclusions and the above is a very good example.



It also re opens the discussion on "what was perceived to be critical at a given time during the project" versus "what at the end of the project turned out to be critcal". Often not the same things.



Hope the above answers your questions Philip.

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

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!)

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.

Uri,



You’ve raised some very good points, and I would like to give my views on them.



1. I totally agree that the Contract is the starting point. However, all the standard forms of contract I have seen don’t include contract conditions that show what type of Delay Analysis methodology should be used to evaluate either extensions of time or actual delays.



2. I don’t agree with your view of ’windows’ methodology. A ’windows’ analysis, if done correctly, does give the delay caused to PC as at the date of the ’window’; and if the delay continues it will show the delay to PC increasing in successive ’windows’. This is actual delay at the time, not a ’likely delay’ to support an eot claim.



3. I agree with you on this. It is "what people should have believed (having the information that they had at the time) the critical path should have been". Gary France can probably give a better view on this, as one of the major issues in the recent GEH dispute was what the CM was saying what was critical at the same.



4. I firmly disagree with your point that in the AP v AB or ’windows’ approach there is "only one programme". In my ’windows’ methodology, the programme at the end of the window that is used to measure the criticality of a delayed activity, i.e. the path from the delayed activity to completion of the project should be subject to a ’reality check’. That is, the programme’s future activities should be reviewed to make sure they conform to what the contractor’s plan or intention was at the time. For example, the planned logic may show that an activity is not due to start for 6 weeks, however the contractors current progress report shows he is going to start this activity in 2 weeks time (and he did). This ’reality check’ is, in my view, a very important part of ’windows’ methodology and should be carried out at the end of each window.



Roger Gibson

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.

Gary,



You say a good planner spends only 25% of their time planning. This is a rather vague statement. What do you mean by ’planning’ here? Is this 25% of time actually on planning software? Do you mean that interfacing between disciplines and time on site is something you do not regard as planning? I’d just like to clarify what you are trying to say if you dont mind.



I totally agree with your comments Philip about planning having relatively simple principles but requiring good site knowledge and practical judgement.



I’ve read the Art of War as well Philip. I seem to remember it recommends the use of deception and destroying the alliances of your opponents, before you destroy them! Real hardball stuff and still a popular read in business. Interesting given how old it is. Have you read ’The Prince’ by Niccolo Machievelli? It is a book(although written as a long letter) in a similair vain, although far more cynical.



Cheers,



Allan

Thank you Gary,

Agreed.

Regards

Philip

Philip,



Good, you were generalising. I did wonder if you had somebody in particular, or a specific group of planners in mind. There are all sorts of planners out there. They all have a point of view that we should listen to and learn from.



I gave a talk recently during which I suggested that a "good" planner spends no more than about 25% of his or her time planning. Slightly controversial, but not many disagreed with me!



Best wishes,

Gary.

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

David,



Generally agree with your points except that the path has to be logic linked. It will be linked but the links maybe events or something other than logic.



Gary,



Totally agree with your comments, the difference between what actually was and what was thought to be are crucial aspects of any project to understand.

Philip,



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



Gary

Hi Guys,



Getting back to the subject, a path is a continious way, sometimes diverging into parrallel routes/path, and sometimes when like a river crossing there are stepping stones, but at the end of the day it is a continious route.



Something like I was taught, about the PERT chart. The proplem is that planning is a totally pragmatic/practical discipline, however, the theorist are trying to hijack it. I spent a long time in engineering/construction before I landed up in planning by default. When I first learnt planning while studying engineering, it took all of 4 and a half hours out of a four year course, and I learnt all I needed to know in those four and a half hours, the basics, computors came later.



What I am trying to say is that whatever you do, keep on planning practically, avoid the pitfalls of theorising to much, and understand that we are not prophets, but people with experience and foresight.

Regards



Philip

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

Stephen,

Yes I appreciate that this is often the case, in plotting the path through the project I would take this into account.



Sometimes it is a case of a first pass attempt at plotting a path from beginning to end, then step back and look at it and compare it to the original master programme. The next stage would be the ’Why?’. This is one of the most important stages, why did the project deviate and it may be at this stage that scope changes and so on emerge. (Of course there may be other reasons, such as equipment supplies or resources forced the project team to make changes).



So at the end of the day the path is still based on logic and exists up until a new path springs up, "emergent work" and of course this may and often does happen several times in the life of a project; but it all forms part of the route from start to finish.



By the way I have not forgotten that there can be more than one path running concurrently.



David

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.

Gerry,



My definition of a path, without obvious funnies? You spoil all the fun. Ok here we go, for me a path is the ’route’ through the project from start to finish. This route relies on logic links in the same way as a prospective programme would but the method of calculation would be approached differently based on the source information.



If we have progress reports and photographs and so on we can calculate the path. If however there is perhaps little more than site diaries, then we can plot what was done each day and, this is where experience comes into play, the planner can draw the logic and work out the path through the job. Subjective? Yes, but experience and common sense count and if we can back this up with other records (photos, emails, correspodence etc) then maybe on occassions this is just the best we can do.



David

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

PJ



Not try to become over smart or impress the members by writing such words in this forum



"Miachiavellian route"



The dicussions under this thread are very conclusive so if you have different opinion, write here

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.

Sorry Andrew, I hope The answer you are awaiting is not from me, as you got my name wrong, it is Philip with one L.



I have had an operation, and am still trying to catch up with the threads, you will hear my opinion later



Regards



Philip

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.

Vladamir,



Exactly my point - and happens very often! Therefore, does a backward in time analysis pick this up?

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

Stephen,



Thanks, two points of subtle difference but very important ones when trying to understand why a decision was made during a project.



The right decision may have been made but based on information that was incorrect (or vice versa!!) by any or all parties. The decision and information may have been correct at the time but subsequently changed. Lots of permutations, however, understanding what factors were being considered at the time of the decision is important.

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.

Sorry Ron, I stand corrected.



David

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.

Andrew,

First let me say, I am a believer and I think that those who aren’t are stuck in future tense (I know this is what planning is about) however this subject is as much about forensic planning and delving into the past as projecting the future. With this in mind I believe that certain individuals need to think about ’what was’ and not just ’what is’ or ’will be’. I believe that to be a successful planner an open mind and lateral thinking are important prerequisites, so I am rather disappointed at the closed minds of some individuals.



Now that that is off my chest, there is the Ron Winter software that can analyse programmes and construct an ABCP. I believe that it compares the original duration to the actual duration, the difference being float. (Feel free to correct me on this Ron).



Overall I believe the best way (records allowing) is to manually plot the CP, ie when we completed floor slab to GL x we were able to commence blockwork and when we completed y blockwork we were able to commence... etc



David

Phillip,



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

Gerry,



I know I’m being very simplistic in the example and life just isn’t like that. Just want to see what those who insist that the "what ever you want to call it" doesn’t exist in any circumstances, are going to say.



We are talking as built, so the in’s and out’s of what may have been doesn’t really apply so much.



Someone in the last thread called it the search for "the holy grail" - and I would agree that is very unlikely that good enough records etc exist to enable anyone to 100% accurately establish it retrospectively and you’d have to be really on the ball to do so even during the project.



But to say it doesn’t exist is mistaken, it exists, its there, but we just can’t always find it.



To go in a slightly different direction, but very closely related, does anyone think there is any computer software that can really pick up all the subtle changes in a programme. Personally I think they are an aid but no substitute for the human touch.

I think we are getting close, what ever you wish to call it-



A short example, take 2 totally independant activities, (not linked, independantly resourced, etc, etc) on a programme:



For simplicity, both start on the same day,



Activity A - currently critical and duration 10 days

Activity B - 8 days duration, 2 days float



So day 1 - A is critical

on day 5 - an event extends duration of B by 3 days so it now becomes critcal

on day 8 - an event extends duration of A by 1 day so both are critical

on day 10 - an event extends duration of A by 1 day so it becomes critical again



The sequence of critical activities (or I would still call it ABCP) is:



Days 1 - 5 - A critical

Days 5 - 8 - B critical

Days 8 - 10 - Both critical (just threw this in to see what the reaction on concurrent criticality would be!)

Days 10 - 11 - A critical



As already stated, it does not have to be linked nor does an activity have to be critical for it’s total duration, but - the chain, sequence, path or whatever exists and is determinable both during and after the project.

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