The Right Way to Construct Level of Effort (LOE) Activities in Primavera P6

This short entry demonstrates why Level of Effort activities in Oracle Primavera P6 should be constructed using predecessor successor 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.

1. 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.
2. 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.*

[Edit:  Unfortunately, similar symptoms are produced by MFP analysis when P6 incorrectly assigns legitimate members of the Longest Path to much higher Float Path numbers.  See details in Relationship Free Float and Float Paths in Multi-Calendar Projects (P6 MFP Free Float Option).]

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 initial preference was to use only predecessor relationships in the LOE.

Using Predecessor-Only Relationships

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.

Sometimes we want to make an LOE activity whose finish corresponds to the finish date of the project.  Creating such an LOE using predecessor-only relationships doesn’t work as intended, however, because P6 picks the new LOE as the starting point of its Longest Path trace during the backward pass.  Thus, our intention to stop logic flow through the LOE is foiled.  In the next figure, this is shown by the new LOE-2 activity, whose finish is determined by the finish milestone (FM) of the project.  Since LOE-2 is the latest-finishing activity with no successors, P6 starts the backward pass with it, ultimately including its non-critical predecessors A1 and B1 (incorrectly) on the Longest Path.

Predecessor-Only Relationships – LOE-2

Using Successor-Only Relationships

In contrast, if LOE-2 is constructed using successor-only relationships, then P6 will never choose it as the starting point of the Longest Path trace.  Moreover, the absence of predecessors will ensure that when P6 does encounter such an LOE during the backward pass, the Longest Path trace will not continue past the LOE.  As shown below, constructing LOE-2 using successor-only relationships leads to dates, float calculations, and Longest Path calculation that are all correct.  This example suggests that successor-only relationships should be the preferred method for specifying LOE activities in P6.*

*Thanks to astute reader A Lou Gonzalez, who pointed out the special issue with using predecessor-only relationships to define LOE activities at the project completion date.

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.