Has anyone heard of an As-Is Methodology.
Using progress only update data, with an option to modify when (as built) dates do not match( progress update ) critical activities dates.
I try and stick to the guidelines a reference with the SCL protocol, and 29r-3, so never heard of this used before, as it seems too manipulative, requiring more substantiation.
Any thoughts
Stephen,
The whole point of an 'as-is' method is that you leave the data 'as-is', to avoid any allegation of manipulation etc.
The main As-Is methodology I use is in the production of 'float map'. This uses only as-built data programme data, taken directly from the Contractor's files.
Essentially its just an abstract of monthly total float values, which you can sort / filter to illlustrate as-built critical path changes, etc.
Of course if there are discrepencies in as-built data, these will need to be addressed.
In practical terms, its also neccassary to adjust total float values to accomodate different calenders etc, and you'll be scratching your head with a way to show driving/sub-critical tasks so it can get pretty complicated. However the underlying data being unchanges is the key.
I've got a fairly good system, which can quickly identify the as-built critical path, subject to further scrutiny.
Cheers,
Alan
Mike,
In what way would this methodology have validity. Do you mean in sub contract form, the process is used to quickly identify the impact and delay.?
Hi Stephen
According to Mr Chris Carson there are at least 18 different delay analysis methods.
What you have described seems to be an As Planned v As Built variant.
This could be valid in a sub-contract EoT but otherwise useless.
Best regards
Mike Testro