As Built Critical Path

A Complex discussion even though it seems simple.

The definition of the "Critical Path" is the longest Path through the schedule and the answer is yes.

I have observed that you will always have a critical path (more than one) in the process industry. But what I have noticed is that the path will change during the project live from planned to final (Different Activity).

The reason why is once a critical path has been identifyed the project does everything in their power to reduce the critical path once you have reduced it you will noticed that something else becomes critical. And then you would do everything in your power to reduce this.

Also you end up giving more slack (delay) on your non critical activity’s so that you can address your critical path.

So in the end of the project you end up with various critical paths (also called a photo finish)

So yes "critical path" does exist in As Build Project I sometimes use the Term Critical Chain (Everything Finishing together but all part of the Critical Path) but I know that somebody is marketing "Critical Chain method" I have not seen what their definition of a critical chain is.

If it was not for the longest path we will be able to do a project overnight.


Cheers

Gerry,
It is essential that an as-built CP is developed if an argument arises over EOT to a Contract.

The as-built CP will sequentially trace the work activities that were executed for the project to reach completion, or up to the time under consideration. If completion is reached, or shown to be reached, later than originally planned, then you have a delay. If all or part of that delay is attributed to reasons not applicable to the Contractor, then the Contractor may be entitled to an EOT, which may equal all or part of the delay.
Subsequently the Contractor may be entitled to costs related to the EOT.

But the foundation for all of this is the as-built CP. If the Contractor cannot demonstrate that the as-built CP was pushed out for reasons not attributable to himself, then he cannot claim an EOT.

And remember that an as-built CP is not just the final one produced at the end of a project; it is the CP that has occurred from the start of the project up to the time in the schedule under consideration.

Cheers,

Stuart

www.rosmartin.com

Do you agree with the notion that it is appropriate to insert logic between as-built activities that have already been constructed?

Gerry,

Provided that the logic as inserted is not inconsistent with the other related activities, there is nothing wrong in adding it into as-built already-constructed activities.
This happens all the time when trying to demonstrate that a Delaying or Relevant Event (call it what you will!!) has had an impact on the CP.

Hope this helps

Cheers,

Stuart

www.rosmartin.com

Gerry,

Can we assume that you are putting together some sort of a claim document to demonstrate what actually happened on a project? If you are, then you have to be very careful in adding links retrospectively. You will / may have to justify each one if they are different from the originally programmed logic. This is because, by introducing new logic, you might well change the critical path from that which would have occurred in your as-built programme had you retained the original logic.

Many experts / delay analysis consultants have been criticised for adding retrospective logic that change the critical path. In effect, by adding links retrospectively, you can make your as-built critical path show whatever you want it to show. Be wary of falling into this trap. You will need to be certain that you can justify all changes, because if you do not, or cannot, than be prepared to do battle big time with whoever you send this to.

Good luck.

Gary France
Chairman
The Planning Engineers Organisation
www.planningengineers.org

Gerry,

Gary is right that you have to take care when you add in retrospective logic – hence my caveat about ensuring that there are no inconsistencies with the original logic.

In principle, however, provided that your logic is sound and reasonable, there is nothing inappropriate in inserting retrospective logic (subject to the points that Gary and I have made).

Cheers,

Stuart

www.rosmartin.com

Gerry / Stuart,

I agree, there is nothing inherently wrong in adding retrospective links. In fact, you must do it because chances are that the original programme logic will have changed over time. Apologies if I didn’t make that clear.

Gary France
Chairman
Planning Engineers Organisation

Gerry, Whilst it is acceptable to change the logic by adding links in creating an As Built Critical Path, it is important to justify and explain the reasoning for each change. Another important ’verification’ check of the As Planned network are the activity durations. I have often seen eot/delay calculaions based on original programme durations that were excessive and therefore resulted in eot/delay calculations being longer than reasonable or realistic. Roger Gibson

How would you handle retrospective logic in the situation which always prevails in as-built programmes - that being that as-built activities are always disconnected and characterised by start/stop/resume/restart/stop/resume/restart.....etc.

Gerry,

Personally, I don’t think an ’As Built’ critical path with true as built logic can be created. Just because activity B started 3 weeks after activity A started does not mean that the as built logic between these activities is a start-to-start of 3 weeks. It could be because of a number of factors, e.g. shortage of resources or awaining information.

In carrying out a retrospective analysis of actual delay my preferred approach is a series of progress snapshots, or ’windows’, which show which activity was critical at each snapshot. From this, and further investigation and interrogation of the network, progress and other records an ’As Built’ critical path is established.

Roger Gibson

Thanks Roger. Stuart, Gary, Jaco - what do you think? Can a true as built critical path be created?

My answer is yes.

An as build longest Path can be produced. I would suggest to forget about the logic issues. Please note the diffinition of a critical path is the longest path. Not the longest path due to logic. With other words if the logic is wrong (We are all human) the critical path is something else than the longest path.

But why do you require this. I am not sure what type of project you are working on / or refering too.

Cheers

Dear Jaco,

What you have said is correct, The longest path is the critical path. As Built Critical Path is based on the actuals happening at the site i.e. based on the actual update; when the project is in progress due to the rate of progress of work experienced at site the original critical path(or the baseline critical path) could be altered and may be at the end of the project a new longest path could be found than the expected one. Once the project was over we can say it as a As Built Schedule just like saying as-built drawings. The As built schedule should reflect the history of the project in genuine. Obiviously the longest path formed in the As-built schedule would be a As-built critical path but not necessarily to represent the original baselined critical path.

Regards

Daya

Daya,

Jaco has defined it correctlt; it is the longest path that is established. However, this is often termed as the ’As Built critical path’.


Roger Gibson

Yes, critical path is most commomnly used term in planning and also it is the longest path based on the correct logic whereas "As Built Path" is not commonly used and not depenable.

Gerry, re your question: "Can a true as built critical path be created?"

I hope so, otherwise I have wasted much of my working life!! (not an entire impossibility, I grant you!!) ;-)

Cheers,

Stuart

www.rosmartin.com

What about the normal scenario for a medium sized building project beyond the more obvious critical path items (piles/foundations/sub-structure/superstructure/envelope) - i.e. producing an as-built critical path which addresses all that goes in within the envelope such as M&E, BWIC, partitioning finishes, BMS systems... Is it practical to expect an **as-built** critical path to be identifiable for this work?

There are two issues here:
1. The legel issue
2. The programming issue.

When analysing delays, the first place to look at should be the CONTRACT. Only when there is a reference in the contract to actual delays to the date for PC, the As Built programme becomes relevant. The Critical Path then would be the longest path in the as built programme.

In most cases the As Built Critical Path is not relevant, since the analysis is carried out RETROSPECTIVELY. The as built programme is used only as a record of actual dates, and not as a real programme with float, links etc.

I think Uri is right in general to make As built critical path Schedule. But if you want to keep As built Schedule for future reference of planning then we should consider only those delay points which generally happens in project to identify the critical path. I mean to say that if the delay something like unavailibity of fund or vendor’s bankrupt comes on critical path we should ignore that to say that is not the critical path even though that will be longest path. Then we can say second longest path is really ctritical for future reference of planning but for cliam purpose the longest path will be considered.

Hi Gerry

Yes it is Practical to do an As Built Critical Path on these Items.
Your Critical Path Should be something like this
From Back to Front.
1) Building Handover
2) Commision BMS - SAT -BMS FAT BMS - Development BMS -
2) Commision HVAC
2) Commision Fire Detection
2.1) Commision Permenet Power (LV) - Delivery MCC - Delivery UPS etc
2.2) Commision Permananet Power (HV)- Delivery Transformer -Delivery Switchgear etc
2.3) Power Supply Available
3) Installation of Controls Instrucments
4) Installation of HVAC - Delivery HVAC-Order HVAC
5) Access to Install HVAC
Your other activitys should run Concurrent.

Please note this just to give you some ideas.

Cheers

Dear all,

This has become a very interesting thread. I would like to return to something that Roger Gibson said earlier. Assuming that Gerry is undertaking some sort of a delay analysis, or is preparing a claim, then that is why he is considering an as-built critical path approach.

In so doing, Gerry also needs to consider what Roger described as the “windows” approach. I concur with Roger, in that it is my preferred method of analysis as well. The reason why is this…..

In producing an as-built critical path programme, you can see what was the longest critical path chain throughout the project as it was at the end of the project. This is fine, but it lacks one vital consideration. The problem is that it considers the project only after it is completed looking back, but ignores what was known about at the time. Let me give a very simple example. Let’s say a house is being built and there are problems with building the foundations. The design is late and this causes a 3 week delay. This is on the critical path and an extension of time of 3 weeks is quite properly given. All quite straightforward and simple.

However, the design also incorporates a swimming pool in the garden, which is a contractor designed item. At the time of granting the extension of 3 weeks due to the late foundations, the swimming pool excavation is on programme and all seems okay with the pool. But, the contractor takes far too long to design the pool and order the water treatment equipment and this turns out to be the eventual cause of the house being completed 10 weeks late.

So if a retrospective as-built programme was drawn, it would show the as-built critical path going through the swimming pool, but not through the main house foundations.

Would you say that this as-built critical path programme was correct? It does, quite correctly, show that the eventual critical path went through the swimming pool, but some would argue that it would ignore the true cause of early delay – the house foundations. This is where a “windows” approach is preferred by some courts, because the windows approach, as Roger has stated, considers what was critical AT THE TIME. This is the important point. An as-built critical path can only consider what eventually turned out to be critical, but doesn’t consider what was known about at the time.

So, Gerry will have to bear this in mind when (if) he produces his as-built critical path. There are drawbacks to this system, as there are with most.

Gary France
Chairman
Planning Engineers Organisation

Gary - thank you for your response. However, my point is more basic. In ’real’ planning (prospective - and before anything is built) the notion of critical path analysis is sound. It is sensible to hold a view that Activity B cannot start until Activity A is completed (or whatever lead/lag constraints)in order to derive the undoubted benefit of planning software. However, in practice, we ALL know that these ’hard’ relationships rarely exist - unless you go to the nth level of detail at activity level. In disputed contracts there is an inexorable drive to detail - including an examination of the as built (facts). This often results in the once ’as-planned’ activities being shown as as-built activities with start/stop/resume/restart/stop/resume/etc etc etc - especially if the detail is compiled from daily labour and plant allocation sheets - in conjunction with a typical (and useful/appropriate at the time) as-planned contract programme. Is it not the case that the piecemeal working and intermittent effort upon the activity (especially the kind of activities that Jaco mentioned earlier) seriously compromise the insertion of logic into an *as-built* programme.

PS - I’m not doing a claim. Just love the subject!

Hi Gerry

Please Explain

Is it not the case that the piecemeal working and intermittent effort upon the activity (especially the kind of activities that Jaco mentioned earlier) seriously compromise the insertion of logic into an *as-built* programme.

Jaco - (hope this presents on your screen satisfactorily)

Imagine planned activities A,B and C - all having 15 days duration and ladder linked S-S=5d and FF=5d. What actually happens is the following: (note a dash indicates not worked that day, an x indicates worked that day).

[A] ----xx---x-----xx-------xx----x--xx--xxxxxxx-xxx---x
[B] xxx---xxx---x---xxxx-xxxxx-xxxx-xxx---------xx-xxxx-
[C] x-----x------x--x--xxxx-xxx-xxxx-----xxx----x-----x

Within the above there are 28 segments. The planned logic bears little resemblence to what happened. How would you go about discerning the as-built critical path from such records which are not unusual in disputed delay analysis - except vastly more complex. Wouldn’t you find that the insertion of logic will become extremely subjective.

[Duplicate entry deleted.]

I believe that the secret to understanding the type of network that you describe is to look at a re-computed CPM on a day-to-day basis. Start from the latest date, move the data date back one day, adjust the remaining durations of each active activity to reflect the actual work days remaining and re-compute the CPM. Then note which activity (or activities) was critical and active that day. Repeat this process, moving the data date to one day earlier until you reach the start of the project.

This is the algorithm that we use for a software product that we call “As-Built Critical Path.” It is a part of the Schedule Analyzer Forensic series. You can see more at http://www.ronwinterconsulting.com/forensic_main.htm. I also presented a paper on performing this algorithm manually at this year’s AACEi Annual Convention. You can find it somewhere under http://www.aacei.org/.

Ron Winter

Ron - I had a look at the links you provided and I found a short article on Schedule Analyser Pro Ver 2.48. It does not tell me how to do things. It looks like a sales pitch. In reading your webpage it states


"As-Built Critical Path ’walks’ an As-Built schedule backwards, stepwise removing the actual progress, recalculating the CPM, and noting the active critical path. As-Built Critical Path tells you what actually happened to the critical path every day of the project. SA Profiler adds the ability for As-Built Critical Path to consider the actual days of work remaining when recalculating the critical path"

Again, I am not informed. How does the programme decide what logic should be inserted into the network to enable identification of a critical path? Is it simply relying upon successive iterations of the retained logic which P3 offers? Hence - no judgement by the person doing the retrospective analysis?

I understand if you do not want to share the knowledge freely.

I have no qualms on explaining myself. Take a look at my Published Articles Section http://www.ronwinterconsulting.com/published.htm of my website. There is a listing there for, "AACEi 2004 Annual Conference: How to Manually Determine the As-Built Critical Path." It is a later version of the paper that I delivered at the conference. They let me live after presenting it, so it can’t be too far off.

Ron Winter.

Hi Ronald

I was looking at your paper and was wondering why can’t you calculate Float on activity’s that is completed. Remember you can change the dates to Non dates (numericals) even though computer systems don’t calculate float in activitys that is in the past you as a person can calc it manual.

I know actual should not have float but to do an as Build Critical Path you must calculate the float manual.

You can do a forward and a Backword pass on actual start & finish dates

Cheers

Hi Gerry and others.
I have been watching this discussion with keen interest.

My opinion is, on the question that Gerry originally asked, is that there is no thing such as an as-built critical path, simply because if something is complete, how can it be critical? ie Hindsight is 20/20 vision. Anybody trying to establish the critical path in retrospect did not do his/her planning properly in the first place. Further, the critical path will not always remain in the same chain of activities. If Gerry is working on a claim, any tampering with the original and as-built programmes would make such programmes nul and void, as back-up material in the claim.

Regards

Philip

Jaco - Yes, you can compute the CPM for completed activities but do not forget that the CPM is computed using activity remaining durations. The remaining duration for a completed activity is zero. This does not tell you much about the critical path in the past.

Philip - You are correct ahout ’hindsight’ but what about ’Today’? You can certainly tell what is critical today. Tomorrow will eventually come and when it is ’today’, you will be able to determine the critical activity for that as well. My point is that for any given date, you should be able to state what was critical for that date - even for dates in the past. I have not said anything about the Critical Path - only the critical activity for any given date.

Ronald - I’m confused. Contrary to what you state, the message you send out is precisely that you can produce an as-built critical PATH (read my cut-and-paste from your website in earlier posting) I highlight the word path as it denotes logic. Who inserts this logic? And upon what basis?

What about Philip Jonker’s point (? If something is already built, how can it be critical? Critical to what? It’s not critical to Completion as it is already built.

I am actually probing the minds here to enquire as to the limitations of the concept "was critical". How stable/useful is it in retrospective delay analysis. For example -is it logical to try and logic-link lots of "was critical" (i.e in the past) activities. Will it really be a PATH?

If a delaying event arose half-way during a project then the critical path could switch instantaneously to that event. It may have absolutely nothing to do with the critical path that existed up to the second before that event arose. In this case, how can you get an *as-built* critical PATH which connects activites from the end of the project back to the very start of the project.

The "Critical Path" extends from "Today" (the data date) to the end of the project. Due to the dynamic nature of daily CPM activity, the critical Path can switch daily for one chain of activities to another and back again the next day. Each day, there will be a critical path (but not necessarily the same path.)

I am saying that the only thing that the critical path has in common from one day to the next is that ON THE DATA DATE, a certain set of activities were both critical and active. This is the only thing that matters. Note what was critical on any date. Add all of the dates together (one at a time) and you have a list of critical, active activities. This is the only truth.

The daily critical ’path’ may hop from one chain of activities to another without a logical relationship between then to ’model’ it. The ’critical path’ may actually hop between two or more activities as they progress. It does not matter. Each and every day, something is critical and active. All of the rest is either unknown or planned.

Don’t focus on one single critical path. Instead, focus on what was critical and active on any given day. The difference between the two is the difference between classical CPM theory and the truth.

Ron Winter.

Hi Ronald,

I already mentioned the point about the critical path moving, however, I understand the project in this instance is already completed, hence "as built". If it is partially completed, yes there will always remain a critical path , and if it is behind schedule you may even have two or more critical paths, and in the instance where the project is well ahead of schedule, the critical path can disappear.
In my experience one of the best ways of analysing a completed schedule is by looking at the costing data, ie performance factors. When I speak about costing, I mean using budget manhours against each activity, and recording actual (clocked) manhours to calculate performance factors.
These performance factors can be plotted against time or % progress, or for individual phases or discplines for the project. If you look at these curves, it will help you in future projects of similar nature to adjust budget estimates, which in turn will give you a better idea on how to work out durations. I have found this a valuable tool in the past where we repeated the same job twice but reduced the duration of the second project by twenty percent.

Regards

Philip

Hi Phillip

Can you please supply us with your definition of the Critical Path.

Thanx

Hi Jaco,

The commonly accepted definit1on, of a critical path is a chain of activities with total float of zero or less, you can decide whether you want to increase the figure to more than zero, if I am working in days, and dependent on the overall duration of the project, I might increase the criticality to up to a week. The reason for this is to be able to spot all activities which is problematic, or might become a problem. You can also say that it is the longest chain of activaties in the project, however this is not always true, as the longest chain might be ahead of schedule, and another shorter chain might go critical, because of intermediate completion dates, resulting from commissioning procedures or other constraints.

Regards

Philip

Hi guys,

Just want to share my ideas on the subject.

1. It is a fact that a Critical Path(CP) today may not be the same tomorrow, next week, next month etc. Unless someone will dispute this fact, please feel free to discuss it.

2. In comparison, as built CP is not the same as as-built drawings. As built drawings can not change meaning if a foundation size on the original plan is 2mx2m and it is actually built at 2.5mx2.5m, no one can dispute that what was constructed is a 2.5mx2.5m foundation because you can easily prove it. In As-built CP it is ever changing. What you may have as an as-built last week may not be the same tomorrow.

IMHO, I believe the word As-built CP is not the most appropriate term. I think History of Critical Path is the better term.

what about coding the critical path networks say cpm1, cpm2....(the ranking of numbers 1, 2 will be based on the longest critical path compared to the next and so on....) in the baseline program itself so that it would be useful for monitoring the changes of critical path if any during update period and that can be used for tracking as built critical path if it exists so.

Hi Sigfredo,

What you say is true. There is one thing however, that is a useful tool, that is saving the history after each each update. P3 has this feature in store period performance. Using this feature has two advantages, one , in that S-curves and histogrammes give a better reflection of actual events, and secondly, where delays occured they can be tracked correctly in the the event of a claim. The value of stored period performance is obviously dependent on the frequency of updates, the more frequnt the updates, the more accurate the stored information. One of the biggest and serious causes of productivity losses is disruption of activities.

Regards
Philip

[Duplicate posting deleted.]

Very interesting thread (now that I have caught up with it!), and I think that we are mainly reading from the same page. I would agree with Roger and Gary about the “snapshot” or “windows” approach – personally, I stay away from the word “windows” to avoid confusion with u-no-what; I prefer to call it “sausage or salami slicing!”

Unsurprisingly, we all seem to agree that the CP runs forward to the end of the project (starting now or at some other point in the future) and we all seem to agree that the CP can multiply and can flit around from day to day. Ronald’s last post (!) emphasises this point. However, I am unsure as to whether this answers Gerry’s earlier question as to what you call the CP once it is consigned to history (i.e., what do you call today’s CP tomorrow when it becomes yesterday??) [Thank God no lawyers are taking part in this discussion!!]

In addition, from a claims entitlement point of view, I would just add that if your Baseline Schedule is itself incorrect and unreasonable (subjective definition anyone??) then the formation of an As-Built Schedule that emanates from said Baseline Schedule, will itself be incorrect.

Cheers,

Stuart

www.rosmartin.com

Hi Stuart,

It is like magic, here today gone tomorrow.

The point is if an activity is complete it’s float disappears.

Hi Philip,

Yes, I agree – which is why we should stay away from the term “Critical Path” insofar as an As-Built Schedule is concerned. What therefore, would you call the longest line of activities through an As-Built Schedule?
Isn’t this where it all began?

Cheers,
Stuart

www.rosmartin.com

Stuart,

I would call if the ’Actual Critical Path’. It is the sequence of activities over the life of the project that caused the completion date to be delayed from ’x’ to ’y’.

By using the ’windows’ or ’salami slicing’ methodology, (’windows’ sounds less painful Stuart)then this path is established.

Also, as it is often the case that an activity may be only be critical for part of its actual duration, I don’t know of any planning foftware that can determine and graphically show this from a final as-built project with actual start and finish dates for each activity.

Roger Gibson

Hi Staurt,

I don’t think there is a name for it so just call it the longest path:-) The point being that if the project finished early the longest path was never critical. Further if the project finished exactly on time or late, and the last activity was say "Handover", There would probably have been some other chain of activities linked to the final activity, so it might not necessary have been the longest path activities that forced thee project to end late. So again give one good reason for bothering with a so-called "As-built CP".

Regards,

Philip

Hi Staurt,

I don’t think there is a name for it so just call it the longest path:-) The point being that if the project finished early the longest path was never critical. Further if the project finished exactly on time or late, and the last activity was say "Handover", There would probably have been some other chain of activities linked to the final activity, so it might not necessary have been the longest path activities that forced thee project to end late. So again give one good reason for bothering with a so-called "As-built CP".

Regards,

Philip

Stuart

Contrary to your earlier email, I do not see general agreement in this thread. In relation to the question "Does an as-built critical path exist" there are unequivocal "Yes" and unequivocl "No" answers among planning enthusiasts expressed within the replies.

Furthermore - it looks like you’ve changed your position as expressed in your first few postings at the beginning of this thread.

The realisation that each day will comprise critical activities does not lead to the notion that - upon completion of the project a sequential as-built critical path can be constructed from beginning to end.

Have yours (and Jaco’s) views changed as a result of this interesing thread? (Which I hope continues for a wee bit yet).

It’d be useful if top-level planning enthusiasts can bottom out "Does an *as-built* critical path exist". The phrase is bandied about willy nilly - and it is clear the term requires close examination. Do no underesitmate the import of changing the word critical to longest.

Hi Gerry,

My views have not essentially moved from that of my earlier posts; if anything, however, my expressions may have modified! I now accept (thanks to the clarifications offered by this thread) that the term “As-Built CP” is at best misleading and at worst entirely wrong! ;-)

Against the background of the clarifications offered by this thread, I would say that I haven’t changed my mind – just my words!

Cheers,

Stuart

www.rosmartin.com

Surely you realise the import of not using the word "Critical". You’ve spent much of your working life doing claims. I dont mean to be rude but - have you ever worked as a planner?

Gerry,

Don’t you mean “I don’t mean to be critical but….” ?

Me ? Plan?
Couldn’t plan a piss-up in a distillery on Hogmanay!

Cheers,

Stuart
www.rosmartin.com