Retrospective Longest Path Analysis: Step-by-Step Practical Guidance

Delay analysis is essential for identifying the extent and causes of project delays. Among the various methodologies endorsed by industry guidance such as the AACEI and SCL Protocol, the Retrospective Longest Path analysis has gained popularity as an "effect and cause" type analysis that is considered forensically reliable.

Definition

The Retrospective Longest Path analysis identifies the critical sequence through the as-built programme by working backwards from the completion date to the project start, determining the longest path retrospectively.

Critical Path Identification

This method discerns the critical path by identifying the longest sequence of retrospective as-built activities, working backwards from the actual completion date rather than relying on programming software calculations.

Delay Measurement

Delays are measured by comparing key dates identified on the as-built critical path with corresponding planned dates in the baseline programme, providing a straightforward assessment of delay extent.

Step-by-Step Guide to Retrospective Longest Path Analysis:

1. Identify a Suitable Baseline Programme

Select a baseline programme that accurately represents the original planned intent for the project. This serves as the reference point against which delays will be measured.

2. Create an Accurate As-Built Programme

Develop an as-built programme using progress records and contemporaneous documents if one is not readily available. This should accurately reflect what actually happened during the project execution.

3. Identify the As-Built Critical Path

Trace the longest sequence of activities working backwards from the completion date. This retrospective approach identifies the actual critical path that determined the project's duration.

4. Compare Key Dates

Compare key dates from the as-built programme with corresponding planned dates in the baseline programme to determine the extent of delay incurred at various project stages.

5. Identify Causes of Delay

Review project documentation to identify the events or factors that caused the delays identified in the previous step, focusing on those affecting the critical path.

Advantages and Limitations

Advantages

• Can be used when there are insufficient programme updates

• Simple and cost-effective

• Easy to understand for non-specialists

• Less reliance on programming software to calculate the critical path

• Based on what actually happened rather than theoretical projections

Limitations

• Does not recognise or allow for switches in the critical path during project execution

• The retrospectively identified longest path might differ from what was deemed critical at the time

• Cannot be used on live projects as the longest path cannot be identified when numerous sequences are progressing simultaneously

• May oversimplify complex project interactions

When selecting a delay analysis methodology, consider factors such as contract requirements, quality and availability of documentation, available programmes/schedules, and the specific circumstances of the project. The Retrospective Longest Path method is particularly valuable when programme updates are limited but accurate as-built information is available.

Looking for Assistance with a Claim or Dispute?

Just get in touch for a no-obligation complimentary review.

Contact

Mark Holden-Smith

07834284308

mark@holden-smith.com