This short entry demonstrates why Level of Effort activities in Oracle Primavera P6 should be constructed using predecessor relationships only – especially when designating Critical activities using the Longest Path algorithm.
P6 LOE Activities
Level-of-Effort (LOE) activities in Oracle Primavera P6 project scheduling software are useful for summarizing the schedule dates of other (primary) activities. They are effectively a replacement for the “hammock” activities that existed in prior versions of Primavera products, including Primavera Project Planner (P3) and SureTrak Project Manager.
In prior software versions, hammocks were constructed by establishing a group of start-controlling activities as SS predecessors and a separate group of finish-controlling activities as FF successors. To avoid circular logic, the same activity could not be included in both predecessor (i.e. Start) and successor (i.e. Finish) groups.
In P6, LOE activities can be constructed using practically any mix of predecessors and successors, and the help file implies that the two can be used almost interchangeably. Although the same activity may not be included as both a predecessor and a successor, it MAY be included multiple times (e.g. as both an SS and FF predecessor) in either group. This allows for more flexibility in modeling activities that are not strictly hammocks.
P6 Help – Level of effort activity
Here’s a portion of the LOE Help topic in P6, which seems indifferent to the types of relationships used in specifying primary activities.
A level of effort activity is similar to but different from a hammock activity.
- A level of effort activity uses its assigned calendar to summarize its dates. Hammocks are not scheduled using their own calendar.
- Any type of relationship can be assigned to a level of effort activity. Only a start-to-start and finish-to-finish relationship can be assigned to a hammock activity.
- A level of effort activity’s duration is calculated from the earliest early start of its predecessors/successors (linked to the start end of the level of effort activity) to the latest early finish of its predecessors/successors (linked to the finish end of the level of effort activity).A hammock activity’s duration is calculated from the earliest early start of its predecessors to the latest early finish of its successor activities.
Problems with LOEs and Longest Path
Despite the increased flexibility afforded by LOE activities in P6 – and its implied indifference to predecessor or successor relationships – many users continue to use SS-predecessors and FF-successors when establishing LOE dates. This can create issues when the project’s Critical Path is defined using the Longest Path option.
Here is a simple example project comprising a Critical Path of activities A-B-C-D-E-F-G with a side branch of associated activities A1-B1-C1-D1-E1-F1. The side activities must be completed before the final activity G can start. All activities are on the same calendar, and there are no constraints or resources. The corresponding Critical Path, as determined by Total Float (TF=0), is highlighted red on the Gantt Chart.
For this simple project, the Critical Path based on Total Float should be identical to the Critical Path based on “Longest Path” – i.e. the “driving path to project completion.” Unfortunately, this is not the case, as activities A1 (TF=10) and B1 (TF=8) are now included – incorrectly – on the Longest Path.
This error is caused by the Level of Effort activity LOE-1, which summarizes the dates of the side activities in Branch 1. Similar to P3 hammocks, this LOE activity is constructed using SS-predecessors to govern its start and FF-successors to govern its finish. The resulting dates are correct, but two complications are introduced.
- As a rule, P6 marks all relationships to and from LOE activities as “Driving,” even when the relationship does not control any of the LOE’s dates.
- The Longest Path algorithm, which traces driving logic backward from the project completion, does not differentiate LOE driving relationships from other driving relationships during the trace.
As a result of these complications, the Longest Path calculation traces driving logic backward from activity F1 through LOE-1 to its two driving predecessors A1 and B1. The latter two – along with their entire chains of driving predecessor logic, if any – are now included on the Longest Path. P6 automatically removes the LOE activity and its relationships from the Longest Path (after the backward pass), but the “Critical” flag on its “driving” predecessors remains.
Activities that are incorrectly included on the Longest Path may be identified by first noting those “Critical” activities whose successor relationships are NOT BOTH “Driving” and “Critical.” Then their “driving” predecessors are traced until either 1) there are no more driving predecessors, or 2) an activity is reached that has a separate successor relationship that is BOTH “Driving” and “Critical,” provided that this successor does not ultimately lead to another incorrect LOE predecessor. Such an examination can be tedious.
A quicker identification is obtained by re-calculating the schedule using Multiple Float Paths (Free Float option), with no End activity specified. Unlike the erroneous LP algorithm, MFP analysis correctly truncates the backward trace at LOE activities. Consequently, the true driving path to project completion (i.e. the correct Longest Path) of our simple project is identified as “Float Path 1,” and activities A1 and B1 are correctly relegated to Float Paths 6 and 5, respectively.
When analyzing Multiple Float Paths under the Longest Path regime: if a “Critical” activity has a Float Path that is higher than the Float Path of even one non-critical activity (all computed using the Free Float option), then that “Critical” flag may be incorrect. In an ongoing, real-world construction project of 1,410 incomplete activities including 165 LOEs, 27 of the 93 “Critical” activities were in fact non-critical and had been mis-identified as “Critical” as a result of this bug. The highest Float Path of the culprits was 293, demonstrating that such mis-identifications can occur even far from the true Longest Path.
Avoiding the Problem
The simplest way to avoid this Longest Path LOE bug is to avoid including a mix of predecessors and successors when specifying the primary references for LOE activities. That is, use ONLY predecessors or ONLY successors. Since LOEs are technically inheriting their dates entirely from the primary activities, my preference is to use only predecessor relationships on the LOE.
As shown here, the Longest Path of our simple example project is fixed by re-constructing LOE-1 logic using predecessors only. The two activities that were formerly “FF” successors of the LOE are now “FF” predecessors of the same LOE. The dates and float calculations are essentially unchanged, but the Longest Path is now correct.
Late Cost Curves for LOE Activities
While using predecessors-only to specify LOE activity dates seems to fix the logic-flow issues, it has no effect on another defect of LOE activities. As Wail Menesi, has described in his LinkedIn Pulse entry, P6 incorrectly computes the remaining late start dates of certain in-progress LOE activities. As a consequence, the “Remaining Late” resource distribution for the affected activity is skewed to the left of the data date. In other words, P6 indicates that certain incomplete work must be completed in the past to avoid delaying the project, even when there is no negative float. That’s clearly incorrect. Fortunately, the issue seems to be limited to LOE activities who’s start dates are determined by Finish-to-Start relationships – a relatively rare structure in practice.