AACE 29R-03 is flawed:
1) AACE 29R-03 makes continuous reference to float values instead of just using the software to show cause and effect which shall be the same, no matter if your software can or cannot display correct resource leveled float values.
It is wrongfully biased in favor of Primavera products, ironically products that under resource leveling cannot yield correct float values while others can correctly display resource leveled float.
2) To make it even worse the recommended practice embed the concept of Longest Path into the concept of Critical Path, a concept that includes activities that are not critical as they still have float, by definition is wrong as the added activities still have some float and can still be delayed without impacting the project finish.
Still the meaning of float shall be the potential delay that does not postpone project finish or due dates. Well incredible but true, Longest Path misses resource critical activities.
What is even more of a joke is the fact that in page 9 of the AACE 49R-06 Recommended practice for identifying the Critical Path, the authors make reference to Primavera Software and say "This RP assumes that the algorithms used in each of these implementations are identical and give identical results."
Seems like the AACE is unable to validate the correctness of Primavera products when a single wrong result would be enough to prove its unreliability. Making reference to a product you cannot validate is irresponsible.
The implementation of Longest Path by Primavera products is flawed and can be easily demonstrated by modeling a four activities job, each activity independent of each other and using a single resource of which only one unit is available. After resource leveling Primavera products will give wrong float values, and even when P6 yields in this sample job correct total float, the values of free float are wrong. Incredibly neither P3 nor P6 will display a continuous critical path and in some occasions can yield a single activity Longest Path that can even be non critical. Beware that in other schedules P6 can yield wrong values of resource leveled total float. Longest path will not always provide you with a continuous path as frequently required in the recommended practice. If because of different calendars or resource leveling the critical path is discontinuous then let it be, just keep the correct mathematical meaning of float. Saying critical path can be this or another thing just bring confusion and is wrong.
3) The inclusion of negative float theory into the practice is inappropriate in delay analysis protocols, negative float hides schedule logic to the extent the forensic analyst and many schedulers disable the constraints that create negative float.
Still the AACE 29R-03 requires to consider negative float and this results in very cumbersome exceptions to be applied, for example;
under one of the many delays methodology,
Excusable & Compensable Delay (ECD) - The difference between the as-built completion date and the collapsed as-built completion date resulting from the extraction of all owner-caused delays is the total ECD. If the owner has paid the contractor specifically to accelerate, then any negative delay durations (delay mitigation) resulting from the owner-paid acceleration should be credited to the owner against the total ECD to avoid double payment to the contractor for acceleration. Where the quantification of the duration of the specific paid mitigation is not reasonably feasible, the credit adjustment may be accomplished by crediting the monetary value of the acceleration payment against the monetary value of the ECD.
or under other delay methodology,
Excusable & Compensable Delay (ECD) - The difference between the as-built completion date and the collapsed as-built completion date resulting from the extraction of all owner-caused delays is the total ECD for each modeled time period. If the owner has paid the contractor specifically to accelerate, then any negative delay durations (delay mitigation) resulting from the owner-paid acceleration should be credited to the owner against the total ECD to avoid double payment to the contractor for acceleration. Where the quantification of the duration of the specific paid mitigation is not reasonably feasible, the credit adjustment may be accomplished by crediting the monetary value of the acceleration payment against the monetary value of the ECD.
... and the workarounds to deal with negative float are endless, what a mess !!!
To prove cause and effect, negative float is unnecessary, it just adds to the confusion. It is enough to make proper reference to criticality as defined under the contract and use procedures that do not depend on the use of negative float, procedures that do not hide schedule logic.
- If the dominant cause is defined on the contract to govern, what some call “longest path” then be it.
- If delays on already critical activities but not dominant is defined on the contract to govern criticality then be it.
- If the contract apportions some float to both parties then be it.
- If the contract is not clear then common law interpretation in favor of the party that does not write the contract shall prevail.
4) The basic principle of cause and effect is still valid, the recommended practiced shall concentrate on using the CPM model to prove cause and effect in a way it does not depends on flawed theories, in a way it allows for the use of software that even when correct values of resource leveled float are not displayed as this does not necessarily invalidates the analysis. It shall not rule out software that provide better functionality with regard to the implementation of constraints and still identify all critical paths avoiding the use of negative float because it hides schedule logic. More advanced software that implement “finish not later than” constraints in a way it identifies criticality without modeling the impossible and without making possible the creation of wrong progress curves that at times might cross each other.
The precise numerical value is not as important as the absolute delay calculated when measuring the planned completion date to the projected completion date. From, Delay Analysis in Construction Contracts P. J. Keane & A. F. Caletka
The industry needs protocols that do not favor or advocate particular interests, particular egos or particular software.
Best regards,
Rafael