Calculation of Activities Relationship Floats

This may help:

https://www.linkedin.com/pulse/relationship-float-viewing-primavera-p6-…

Mim,

Thanks for sharing.  Your x-factor is something that is automatically calculated in my modified xer-parser, but I've never thought to rigorously apply it to driving path analysis.  After a quick review, I think your approach is a good one that seems to work, mostly, with a couple border-case issues.  Namely; 1) in fact no predecessors are driving if the successor is delayed by a constraint; and 2) by using standard date/time arithmetic instead of successor-calendar arithmetic, this approach may omit some driving predecessors in a multi-calendar project.  Still, nice work - I especially appreciate the interactive powerBI interface.

[Deleted Duplicate]

"Thanks for the link.  Your powerBI app is interesting, though I don't see what it provides that the P6 user interface does not"

of course not, I am trying to provide to the team a better solution than PDF not P6 :)

"have you read these from the P6 database or calculated them separately?  If the latter, how?"

in the table "TASKPRED", first I calculated  x=[arls]-[aref] then Min x per Task_id is driving, I quickly checked some value and it seems it is correct,

actually, I used this formula based on your post, unfortunately the inner working of Primavera is not well documented and having this kind of discussion is very helpful.

Cheers

Mim

Mimoune,

Thanks for the link.  Your powerBI app is interesting, though I don't see what it provides that the P6 user interface does not.

I haven't looked at the relationship dates in an xer file since participating in this discussion a few years ago; your suggestion that those represent relationship early start/finish dates doesn't jibe with my prior understanding ("aref" = relationship early finish and "arls" = relationship late start.)  As noted earlier, you could identify relationship total float using these dates in addition to the necessary calendars.

"Driving" relationships are identified by P6 during the forward pass.  We could reverse-engineer driving relationships using relationship free floats, but not as they are calculated by P6.  For the "driving" relationships in your PowerBI demo, have you read these from the P6 database or calculated them separately?  If the latter, how?

Tom

thanks for your post, yes indeed, in the xer they store the early start and early finish for every relationship, the driving relationship is the one with the lowest float, 

here is an example here

https://app.powerbi.com/view?r=eyJrIjoiOTQxZmZhN2MtMmY5Yy00NWQ2LWE1OTUt…

Tom,

To my knowledge Spider does not disclose remaining lag.  This is a legitimate call by Ron Winter that maybe no software provides yet, if he eventually provides for it under his software he will be the first, something that will not surprise me at all. As he said - We plan to build in a function to calculate and display Remaining Lag.

Best Regards,

Rafael

I see some value on Longest Path only on old CPM theory models where constraints are not taken into consideration, as soon as there are date and resource constraints it falls apart and is misleading.  

http://docs.oracle.com/cd/E17462_01/Web_Access/Help/en/Projects/Tasks/pm_cpm.htm

• Longest path defines the sequence of driving activities that determine the project end date. 
• The longest path is broken when activities are no longer driven by relationships; that is, when activity dates are driven by constraints or resource leveling. Longest path calculation includes interproject relationships. 

For modern models that take into consideration all types of constraints such as date constraints, consumable and renewable resource constraining, spatial resources and financial resources I see more value on resource assignment floats. I do not mean to say other metrics are valuable but a minimum requirement is that are not broken and misleading.  

All my schedules are resource constrained an include several contractual milestones.  Time of tower crane in a building is limited and must be resource leveled, elevated slab forms are spatial resources that must be leveled as well.  Even resources easily available must be artificially constrained as to reduce idle time, from the contractor's perspective construction jobs are to make money.

Hi Patrick,

I think you are absolutely correct to remind us of that - clearly only an activity can be delayed and thereby consume float.  Nevertheless, there must be a reason that P6 has calculated relationship floats for many years.  While I have never found a use for relationship total float, I believe that relationship free float must be computed (as an intermediate variable) to do other than rudimentary logical analysis of the schedule.  For example:

1. To differentiate driving from non-driving predecessors;
2. To compute the "Longest Path".
3. To perform Multiple Float Path analysis in P6.  This requires either free or total (relationship) float, as selected by the analyst, to prioritize branches in the logic paths leading to the specified end activity.

Independently, when I developed a little add-in program for logic analysis in Microsoft Project schedules, I had to compute relationship free float - I just called it relative float or relationship float - for similar reasons.  http://wp.me/p6CCB4-L          

Rafael,  having previously read Ron's paper on MFP analysis in P6, which I think you've quoted, I was also under the impression that the relationship dates were not saved in the database.  Nevertheless, the presence of two of these dates in the xer file implies to me that at least those two are permanently stored in the most recent version.  These seems to have changed over the years; while P6 R15.2 stores 2 dates in the xer file, an xer from an earlier version ("5.0.4000" - don't know whether this is P6 or P5) only has 1 date, relationship early finish.

At times you got to think out of the box;

http://www.ronwinterconsulting.com/The_Inner_Workings_Of_P6.pdf

When one considers that a relationship with a lag functions just like an activity with duration, it is reasonable to assume that computed early and late start/finish dates could be computed for relationships. If these dates can be computed, then one could also compute the total float of a relationship.

This float is not necessarily the same thing as activity float. In fact, it would be considered the measurement of the controlling relationship between two activities.

P6 places these relationship date fields under the heading, “Multiple Float Paths.” By expanding this heading, one can display the following columns in the relationship tab, • Relationship Early Start • Relationship Early Finish • Relationship Late Start • Relationship Late Finish • Relationship Total Float These dates are not saved in the database. They are re-computed every time the user opens a new schedule.

At this time we are already a few boxes ahead, we are already talking about another concept, the concept of remaining lag. 

http://www.ronwinterconsulting.com/Extended_Relationship.pdf

Remaining Lags - We plan to build in a function to calculate and display Remaining Lag. Currently, the data field known as, “Lag” actually represents “Original Lag.” It does not reflect the amount of lag remaining to be used. This is especially problematic for lags that are currently crossing the data date. These lags are neither at 0 days, nor are that at their original setting. You cannot calculate an in-progress schedule without knowing Remaining Lag. The original CPM did not have Remaining Duration, only (Original) Duration. It is time for CPM to include Remaining Lag.

 

Relationships DO NOT have float.  The definition of float is the time an ACTIVITY can be delayed …….  See: http://www.mosaicprojects.com.au/PDF/Schedule_Float.pdf

All a relationship does is transfer calculation information between activities, modified by leads, lags and calendars.

Meraj,

As Zoltan suggests, you could certainly copy-paste the relationship data one activity at a time directly in P6.  The project needs to be pretty small to make that worthwhile, but at the moment that is all I could suggest.

You could also parse the xer file into Excel using the xerFileParserBuilder tool that Oracle provides.  (That tool alone is golden – giving full Excel visibility into every single piece of data in the xer file, which is itself simple text.)  The TASKPRED table of the resulting workbook includes two date fields – “aref” and “arls” that I believe represent Relationship-Early-Finish and Relationship-Late-Start.  These are sufficient to compute the relationship floats when combined with relationship lag, predecessor and successor calendars, and successor early dates that are all also found in the parsed workbook.  With two exceptions, it’s pretty straightforward for an Excel wiz to pull the data together.  The two exceptions are:

1.       Calendar data are parsed into one long (ASCII) text string that you have to decode.  It looks pretty easy for simple calendars (i.e. standard week with holidays), but it could get real complicated with a lot of hourly exceptions.  (I know it is possible to generally decode because XER Toolkit has done it.)  Still, timeconsuming.

2.       “Calendar math” can be complicated, and my brain hurts when I consider how to set it up in Excel.  It’s really near the core of what these scheduling tools do.

I agree with Rafael’s caution about what calculation rules to use.  You’ll want to do some trial and error testing to get fully aligned with what P6 reports.  I’ve never seen remaining lag in P6, though obviously it’s a valid construct.  (I bet Spider has it.)

Indeed Ron Winter has some great stuff on his site, and I’ve learned a lot from him especially in areas that are not P6-focused.  He has been quite generous to share this information for free.

1. First you shall make sure you calculations are aligned with the lag calendars, P6 has a limited set of rules you select but do not count it is alway the default, whatever it is.
2. Secondly same as activities have remaining duration also lags do have remaining lag.

CPM aclculations rules can be tricky.  I am not sure if current version of Logicleague includes calculation of remaining lag.

http://www.ronwinterconsulting.com/Making_CPM_Transparent.pdf

http://www.ronwinterconsulting.com/Extended_Relationship.pdf

Anyway if you are a regular P6 user keep taking regular visits to Ron Winter's site, I am not and take regular visits to his site. 

Good Luck 

get the values that you want by adding the columns 

then select edit select all 

then rigth click and select Export to Excel 

The following reference again by Ron Winter expands on it.  This calculation was also disclosed in old P3.

http://www.ronwinterconsulting.com/The_Inner_Workings_Of_P6.pdf

Traditional notions of Total Float and Free Float are tied to the activities in the network, but they are not sufficient for evaluating logical float paths in complex CPM schedules, especially when variable calendars and/or late constraints are imposed.  Relationship floats are needed for identifying driving relationships and for longest-path and multiple-float-path analyses.

Documentation seems very sketchy, but based on my own observations I believe relationship floats are calculated similarly to activity floats - that is

1. The early and late dates of relationships are computed by treating them as activities (with single FS+0 links at each end) in the forward and backward passes through the network (Duration equals lag, normally zero).
2. Relationship total float (RelTF) = relationship late finish (RelLF)  -  relationship early finish (RelEF); 
3. Relationship free float (RelFF) = (Early Date of Relationship Successor Activity, ES for "FS" and "SS" links, EF for "FF" and "SF" links) - RelEF

The calendars used for the calculations seem to be as follows:

• Early dates use predecessor calendar (from the forward pass)
• Late dates use successor calendar (from the backward pass)
• Relationship free float and total float use the predecessor calendar.

(I'm not an expert on the insides of P6, but I would agree with RD that Ron Winter is.)

http://ronwinterconsulting.com/Longest_Path_Value.pdf

the total float has to do with the forward and backward pass the early date are derived from the forward pass and the late dates are derived from the backward pass.

The difference between the early finish and the late finish is the TOTAL FLOAT 

I do not know what realtionship float is unless you are talking about FREE FLOAT

Free float the amount of time the activity can be delayed without delaying the early start of any successor activity. This is also deteremined by the forward and backward pass.

Free float is calculated by subtracting the Early Finish Date of the activity form the Early Start date of the next activity so its

Early Start date of the next activity - Early Finish of the current activity  

this is the basic fundamental process of cpm scheduling

total float is the difference between the early dates and the late dates 

the forward and backward pass is associated with the data date and is used to deterermine the float values

The forward pass begins at the data date (or the project start date if is this is a baseline schedule) and goes forward in time and takes into consideration the remaining durations and the logic for each activity. This is how the early start and early finish dates are derived.

The backward pass begins with the Project must finish by date or the early finsh date of the last activity and goes backward in time and looks at logic and remaining duration.

This is how the late start and late finish dates are derived.

The difference between the early dates and the late dates determine your float values.