Guild of Project Controls: Compendium | Roles | Assessment | Certifications | Membership

Tips on using this forum..

(1) Explain your problem, don't simply post "This isn't working". What were you doing when you faced the problem? What have you tried to resolve - did you look for a solution using "Search" ? Has it happened just once or several times?

(2) It's also good to get feedback when a solution is found, return to the original post to explain how it was resolved so that more people can also use the results.

Multiple Float Path Ranking/Tie-breaker Calculations

14 replies [Last post]
Nick Johnson-Pond
User offline. Last seen 5 years 34 weeks ago. Offline
Joined: 10 Mar 2010
Posts: 11
Groups: None

Hi All,

I thought I understood pretty well how P6.2 calculated/ranked Multiple Float Paths using Total Float after reading this old POINT article http://primavera.zxlm.cn/kb/prim36502 (despite the article referring to P5) however I have run into an odd scenario where this ranking system seems to fall apart.

I've managed to re-create the oddity by creating a simple 4 milestone schedule 

The steps to re-create the situation are as follows:

  1. Create a new schedule with 4 start milestones each using a 7 day calendar (for simplicity)
  2. Create FS relationships between activities (1-2),(2-3),(3-4),(1-4),(2-4) (I realise some of these are redundant)
  3. Now create a new, temporary calendar using the 7 day calendar as a base, but set the date upon which all the milestones sit to a 'non-work' day. 
  4. Assign this calendar to milestone 3
  5. Run the scheduler using Multiple paths based on "Total Float"

Strangely I end up with two float paths FP1 milestones (1,4) and FP 2 milestones (2,3), whereas I would have expected all four milestones to have been float path 1 since the 'driving' and 'most critical' relationship working back from milestone 4 should be milestone 3.

I have read in many places that P6 has some 'issues' when it comes to dealing with float calcs and multiple calendars, but this seemed pretty clear cut to me.

I'd like to know if other people have this issue, whether it's restricted to P6.2 specifically, and if anyone can explain what's actually going on. Is there something obvious I'm missing here?

Replies

Rafael Davila
User offline. Last seen 13 hours 45 min ago. Offline
Joined: 1 Mar 2004
Posts: 5228

Nick,

I cannot see anymore the images you posted. Anyway today I just saw a posting that occurs to me might be related to the issue.

http://www.planningplanet.com/forums/planning-scheduling-programming-discussion/511636/p6-data-date

I do not have P6 but used SureTrak long ago, the above posting along with the early finish of the last schedule activity being different than the late date made me suspect that the issue might be there. I am not sure if the issue was with the last activity on the path as the images are no longer there.

Ron Winter give some advice on how to handle the issue on the backward calculation date that can be of further help.

What if you add an isolated long duration activity to make it the longest path? Do the milestone dates perform as expected or the issue is still there?

Good luck with your search and once again sorry, my mistake.

Best regards,

Rafael

PS. I use Photobucket a free image files hosting and post the HTML code with rich-text disabled.

Rafael Davila
User offline. Last seen 13 hours 45 min ago. Offline
Joined: 1 Mar 2004
Posts: 5228

Mike,

My issue is not on the state of resource leveling algorithm per-se, the issue is on the possibility of the multiple path computations being wrong when the schedule is resource leveled no matter the state of the algorithms, most software give different results and everyone knows. If flawed it does not matter how rudimentary the resource leveling algorithm is.  I would never use functionality that is flawed under resource leveling and this was my warning, if cannot be trusted under resource leveling why bother with such functionality, 50-50 does not meets my standards.

My question was honest, not with the intention to annoy you, but now I realize it was too much of a distraction. If you do not want to deal with resource leveling on your thread it is ok, it is up to you, sorry for that. I just deleted my postings as not to divert the issue any more.

I will pass to other thread my question about how P6.2 and any other software implements this computation on multiple paths to find out if flawed or not under resource leveling, to me that would be a major flaw.

Best regards,

Rafael

Nick Johnson-Pond
User offline. Last seen 5 years 34 weeks ago. Offline
Joined: 10 Mar 2010
Posts: 11
Groups: None

Rafael,

I admire your enthusiasm and passion for resource levelling and can sympathise with your frustration that the available tools today are inadequate to meet your needs in this regard.

I somewhat doubt that software developers are in a position to implement sophisticated functionality for which there is not already an agreed standard set of mathematics to support (Grammar school or otherwise). I imagine they are just doing the best they can do with partial theories, although I cannot confess to have more than passing knowledge in this area.

Regardless of all of this, I am concerned that your empassioned contributions are diverging somewhat from the original topic of this thread which concerns the multiple float path calculations used by P6.2.

Specifically whether the special case illustrated (un-resourced milestones) represents a flaw in the software algorithm, or whether it is 'by design' and instead represents a failure to meet certain un-documented requirements when building a schedule.

I sincerely welcome your contributions and input on this matter, but respectfully suggest that your theories on the state of resource levelling algorithms probably deserves its own thread.

Regards

Nick JP

Rafael Davila
User offline. Last seen 13 hours 45 min ago. Offline
Joined: 1 Mar 2004
Posts: 5228

DELETED

Nick Johnson-Pond
User offline. Last seen 5 years 34 weeks ago. Offline
Joined: 10 Mar 2010
Posts: 11
Groups: None

Hi Baris,

I'm certainly not going to argue with you that it makes sense for this program to finish with a finish milestone, that would always be my preference. However there's a difference between it being good practice and it being necessary for the CPM or FP calculations to function.

I am occasionally required to analyse programs that I would not consider to conform to 'good practice', however usually I try to make as few 'fixes' to these raw programs as possible. I'm trying to work out if this is a necessary 'fix' and it's looking like it may be the case, however I'm not even particularly comfortable with the results of this change.

See the below table which has resulted from converting M4 to a finish milestone and re-scheduling.

752
p6_milestone_brain_twister_finishms.jpg

I'm now happily getting my continuous float path, but look what has happened to the Late dates and Total Float calcs. What the...?! In case you are wondering I am "Calculating Total Float as" "Finish Float".

This looks like utter gibberish to me. M1 and M2 should have 8 hours total float.

Baris Hazar
User offline. Last seen 7 years 4 weeks ago. Offline
Joined: 4 Dec 2009
Posts: 39

Please see my updated post below.

Nick Johnson-Pond
User offline. Last seen 5 years 34 weeks ago. Offline
Joined: 10 Mar 2010
Posts: 11
Groups: None

Baris,

See below:

753
p6_milestone_brain_twister_pert.jpg

I'm not sure how legible that is. The float values are in the top right corner of each activity box. Both MS1 and MS2 have float.

Baris Hazar
User offline. Last seen 7 years 4 weeks ago. Offline
Joined: 4 Dec 2009
Posts: 39

Dear Nick,

There is another thing that we should be thinking of; that is the type of last activity MS 4. There should be at least 1 finish MS of this schedule. Please change the type of MS 4 to Finish Milestone and re-schedule. I have modeled your schedule in my PC and i have ended up with another pattern by changing the type of MS 4 but the result is not satisfactory enough to deduct a logic.

A suggestion: Try to use not Milestones but Task type activities to understand the dynamics of FP calculations. In my opinion, milestones don't give any simplicity rather than the problems they introduced. For instance; in P6 6.1, when you link a start ms to a finish ms fith FS link, finish milestone finishes at 08:01 even if start milestone starts at 08:00. However, duration of both is 0. Also see the attached snapshot of above mentioned revision and note that there is no critical relationship line here.  (m4 is Finish MS here) 

731
capture.jpg

 

 

732
capture2.jpg

 

 

Regards,

 

Baris

Nick Johnson-Pond
User offline. Last seen 5 years 34 weeks ago. Offline
Joined: 10 Mar 2010
Posts: 11
Groups: None

Baris to the rescue again, thanks for the re-direct. I was puzzling over the possible relationship to default global calendars and it hadn't occurred to me that the relationship lag setting would have anything to do with this since I am not using lags.

My scenario is quite deliberately simple/artificial to help isolate the problem.

754
p6_milestone_brain_twister.jpg

There are non-driving relationships between (MS1, MS4) and (MS2, MS4) however the driving chain of relationships is quite clearly (MS1 -> MS2 -> MS3 -> MS4) (See attached screenshot). What you have explained to me only seems to reinforce my concern that the calculated float paths demonstrated here are not correct. I do not understand why the scheduler would select the M1-M4 relationship over the clearly driving M3-M4 one.

(Note that in the provided screenshot I have used the 5 day calendar rather than the 7 day calendar. The "temp calendar" is a copy of this with the Wednesday (12th Oct) set to non-work)

I will however track down that book and read through the algorithm myself to see if it makes any difference. Thank you for the reference.

Baris Hazar
User offline. Last seen 7 years 4 weeks ago. Offline
Joined: 4 Dec 2009
Posts: 39

Hi Nick,

 

I don't think that 'project default calendar' has a direct effect on the float path calculations. If you select the option "Project Default Calendar" for "Calendar For Scheduling Relationship Lag" under scheduling options, you might have an indirect effect of it cause it plays a role in CPM calculations at this case. Moreover, i think 'global calendar' is the last thing that you should refer for the solution of this issue.

If you ended up with two float paths as you stated, FP1=1-4 and FP2=2-3 then it means you might have some how 'non-driving' relationships between:

MS 1 and MS 2

MS 2 and MS 4

MS 3 and MS 4.

First of all, make sure that you have only driving relationships. If you have a case as i mentioned above, then it is normal to have 2 FPs. 

Please refer to the book "CPM In Construction Management" by James J. O'Brien; Page:427; Topic: "25.8. Detail Views of Output of Schedule Calculations". Here you can find the manual calculation method of FPs for P3. As far as i understood, Program determines the paths according to 2 main criteria:

- Total Float,

- Driving Relationships

 

Regards,

Baris

Nick Johnson-Pond
User offline. Last seen 5 years 34 weeks ago. Offline
Joined: 10 Mar 2010
Posts: 11
Groups: None

Thanks for the feedback Rafael.

Prioritised resource auto-leveling is unfortunately not something I've had much experience with in P6. My early experiments with it yielded some strange results and it's not something I've been particularly comfortable with since.

I was specifically considering the case of unresourced milestones to keep things simple. The scenario I have described is something I have run into on occasion when analysing programs where many calendars and redundant logic links have been used.

The multiple float path tool would seem to 'split' a float path in contradiction with the aforementioned 'ranking' system. I want to see if others have a similar interpretation, or if my understanding of how the ranking is intended to work is flawed.

Rafael Davila
User offline. Last seen 13 hours 45 min ago. Offline
Joined: 1 Mar 2004
Posts: 5228

DELETED

Nick Johnson-Pond
User offline. Last seen 5 years 34 weeks ago. Offline
Joined: 10 Mar 2010
Posts: 11
Groups: None

Hi Arend, 

Thanks for your response. The only 'project' calendars I know of is the default new activity calendar and the default global calendar, I assume you are referring to the latter am I correct?

I was not aware that the default global calendar had any direct impact on the Float Path calculations themselves, nor do I seem to be able to repeat your results. It does not seem to matter which global calendar I use, I still end up with the two float paths.

Would you mind elaborating on how the project calendar plays a part in the multiple float path calculations? I'm afraid I don't understand how that would work and I cant seem to find any documentation on the matter.

Arend Woltjer
User offline. Last seen 8 years 19 weeks ago. Offline
Joined: 26 Sep 2011
Posts: 74
Groups: None

Nick,

 

of course you end up with different float paths when you forget to define your PROJECT calender.

If you had taken the 24\7 calender all of the milestones would have ended on 1 floatpath.

You see that it's not the software that makes mistakes or has issues.