Exploring the Dynamic As-Built Program of Delay Analysis
This article outlines the benefits of an alternative approach to maintaining an up-to-date programme that accurately reflects actual project progress. It compares two methods for updating the programme: actualising the programme and maintaining a live programme.
The dynamic critical path method makes demonstrating delay after the fact much easier. It negates the need to reconstruct the as-built programme so that a clear critical path can be demonstrated to prove Extension of Time entitlement. For a little extra effort during the project execution phase, less reliance on the delay experts opinion can be achieved.
Methods for Updating the Programme
The first method involves entering actual start and finish dates, along with percentage complete for each activity. This process overwrites the original logic and relationships for completed activities. It is the method used on most projects.
The second, alternative method keeps the programme and its logic current as the project advances. This approach preserves the historical critical path, making it easier to understand the causes of delays or changes.
Applying Actual Start and Finish Dates
The actualisation method represents a percentage of time, not work completed, since most activities are planned by duration rather than quantity. Once a programme is actualised with start and finish dates and percentage complete, all historical as-built, critical path, and logic data before the status date is lost.
The Dynamic Critical Path As-Built Method
The as-built method is highlighted as the most effective for delay analysis and for presenting planned versus actual performance. It is also valuable for benchmarking future projects.
Actualising the Project Programme
You can enter actual start and finish dates and percentage complete for each activity, as recommended by software manuals. The software then calculates new finish dates for ongoing activities, using rules such as prorated forecasts or remaining duration. This method is suitable if you are willing to overwrite the original logic and relationships for completed activities. However, you end up with a record that shows only completed activities, without any calculated critical path.
The history of how you reached the current status is not visible, and the programme cannot be reconstructed by reversing the actualisation. Restoring original durations does not recover the as-built programme.
If you need to retain project history for future reference or to protect against (or prepare) Extension of Time claims, this method is not the most suitable.
Maintaining a Dynamic Programme
The second method keeps the programme and logic current. The status date is left before the project start so that software calculations do not interfere. For each update period, adjust the logic of activities that occurred, reflecting their actual timing. Ensure that all current activities show their true remaining duration compared to the status date.
This approach produces a programme that looks like the first method but retains the logic and paths leading to the status date. You can see what was important and where the impacts of events or actions occurred. These can be described, changed, divided, or deleted as needed. It is vital that a “Basis of Schedule” (BOS) document is maintained that details the changes made to as-built programme after each periodic update, supported by contemporaneous records such as variation logs, site photographs and correspondence.
Most software allows you to update progress to a certain date, adjusting percentage completes and other features to match the first method. However, the valuable as-built network paths remain in the dynamic version.
Why Actualising Cannot Provide an As-Built Critical Path
Delay analysis methodologies, such as the as-planned versus as-built state that comparing several versions of the first method allows the analyst to see the path throughout the project by reviewing each month’s programme. This is a misconception. As no critical path information is retained in the monthly actualised programmes, the analyst often must infer the critical path.
Throughout a project, the critical path and non-critical paths change. They shift between site and off-site activities, sections, and trades. What is critical one month may not be critical the next. You cannot determine the as-built critical path this way. Once activities are actualised as complete, the logic is overwritten, and the software does not calculate logic paths for completed activities.
Back to News and Insights
Related News and
Insights from Accura
