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.

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?

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.

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.
 

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

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.

get the values that you want by adding the columns 

then select edit select all 

then rigth click and select Export to Excel 

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.)

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