(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.
how primavera calculate the total float for started activities ?
Printer-friendly version
Send to friend
P6 calculates late start and late finish dates even on completed and started activities. Calculating late dates on completed activities is probably just a waste of computing power, however, when this is done on activities in progress this might affect float calculation.
Below is a string of activities on the critical path with two of them linked with a start-to-start relationship
Structural steel activity above is linked to Earthwork with SS relationship and a lag of 3 days; its predecessor is EHT with FF relationship and a lag of 4 days. Project Finish MS is the last milestone in the network and has no successors, Project Must Finish by field is left blank.
Obviously Project Finish MS has other driving predecessors which are not shown here for simplicity.
Structural steel work started ahead of plan and now has an actual start. Technically speaking this is not work out of sequence because the schedule logic still determines its finish date (FF to EHT), the start date is determined strictly by its remaining duration.
Since started Structural Steel several months earlier than planned this would allow Earthwork to start much earlier as well because of the SS relationship and one would expect some significant improvement in the schedule criticality on this path but:
Earthworks gained 118 days of float, structural steel that is not driving anything and EHT (driving its completion date) now have 21 days of negative float.
Here is how it seems to work:
Earlier start of earthworks resulted in some improvement of the project finish date, which now moved from Nov 28 to Nov 5, since the project does not have a must finish by date the total float on this MS will be set to 0 as this is the last activity in the network. On this basis P6 recalculates the late start for the earthworks and it is now 23 days earlier than before - because the project finish date moved by 23 days as well. This is perfectly fine and good old P3 would have done the same thing, what is weird is calculation of the late start date on structural steel - since earthwork needs to start no later than Mar 31 (in order not to impact the project finish date) the late start date on structural steel is set on Mar 30 (should be in fact Mar 28 because of the 3 days lag we have on this SS relationship). Late finish date on structural steel is calculated as late start + activity duration and is now equal to Mar 31. Since Mar 31 is 21 days earlier than the early finish date (Apr 21) P6 calculates 21 days of negative float on this path, which does not seem correct.
On a prior PP discussion,
http://www.planningplanet.com/forums/primavera-version-pm5-pm6/421949/st...
Vladimir said:
I agree 100% with Vladimir and the PMI. I agree with the implementation of showing both as different, instead of "the same that might be different".
You can find different values of start float and finish float on summary bars as well as on hammocks. These mimic intermittent duration schedule calculations.
I consider intermittent duration model poor, it was available on P3 but maybe P6 no longer supports it, that I do not know. The intermittent portions do have their own duration, their own resources, their own float values the intermittent model gives no control and do no show the values. I consider intermittent duration is a poor model, you shall explore the arguments in pro as well as against. Reason shall prevail over misleading convenience.
Because the unrealized portion of activities in progress can be modeled under intermittent duration schedule calculations it is possible to find differing values of start and finish float on activities in progress on such software. An illustration of this statement requires use of software that implements intermittent duration, fortunately I use software that do not implements intermittent durations.
As far as I recall P3 was able to display Total Float and Free Float at the same time, but not all of the many versions of Float available in the literature.
How about P6?
For the less common float values follow the link; http://hafeezrm.hubpages.com/hub/Floats-in-a-Network#lastcomment
Do not underestimate the value of the less commonly used floats, I never before heard of Start and Finish Flex and I soon found they are of much value.
I suspect some or all these float calculations will require to identify resource dependencies in order to keep their validity under resource leveling. If this is true software incapable of creating resource dependencies will not be able to get them right on resource leveled schedules.
I would ammend your last sentence to "Wrong selection for the type of relationship can give us a false value for Early Start and/or Finish dates, which would be factored into total float."
The below link will take you to a previous thread explaining the effect of different constraints on ealry & late dates (and by extension, on total float)
Also Rafael explains the "reverse logic" issue with total float well in this thread:
http://www.planningplanet.com/forums/primavera-version-pm5-pm6/535652/total-float
For the example you have given, if you could give us a snapshot of the programme, or all the key info (durations, relationships, lags, actual early & late dates, total float, etc) then we could explain in detail how total float is calculated
Cheers,
G
The problems all of resources available shows how to do the calculation manually for baseline program none of them tell us how to do the calculation for updated programs with start to start or / finish to finish relationships with constrains ....
i know it look complex but i thing i show know the TF float is calculated in different cases even for very small scale
i do not want to do manual calculation for 5k activity program but i want to know how the TF for certain activity is affected by its relationship between predecessors and successors .
For example
Using Primavera P6 I have one activity lined to a predecessor with start to start relationship. When this activity started the TF remained big and unrealistic even the with significant progress
Wrong selection for the type of relationship can give us a false value for TF.
Rafael,
Just to clarify: Primavera default option is (I believe. -It's been a long while since I used a factory settings version of Primavera) total float = the smallest of start or finish float. Personally, I prefer this version over the PMI's.
But since the OP is asking about total float of started activities, it will always be the finish float that is used.
As per PMI
Total Float = The total amount of time that a schedule activity may be delayed from its early start date without delaying the project finish date, or violating a schedule constraint.
At least the PMI is not ambiguous, it uses a single definition for a single term.
It looks like P6 decided for the ambiguous option of multiple definitions for the same term and if not enough decided to use a default option different to that of the PMI single and not ambiguous definition.
Some people believe Total Float calculations using start dates versus using finish date shall yield same value but it can happen on ongoing activities and perhaps on interruptible/non-contiguous activity duration schedule calculations.
I compare both side by side as I use other software capable of calculating/displaying both at the same time. If a big job then a filter to identify activities with different Start and Finish Float would do it. Changing options and recalculating the schedule is NUTS.
Calculated in the normal way:
Total Float =Late Finish - Early Finish
Late finish = Latest date activity can finish without delaying end of the project (backward pass calculation)
Early finish = Data date + remaining duration OR FF predecessor Actual/Early finish + lag (whichever is the later)
The above is the simple version. It can get more complicated if you have differing calendars, odd relationships, out of sequence working, Actual dates in thre future, or constraints.
P6 have several options to calculate Total Float, obviously they can be different at any time, otherwise there would be no need for different formulas. By looking at some reference I found them to be:
Keep in mind your selection of options for calculation when there is out-of-sequence work will also have an impact on how Start/Finish dates are computed and therefore will have an impact on the float calculations.
The software I use keep the names and values apart, avoiding the confusion as to what is Total Float. Please take a look at the following figure in order to explore how Total Float for activities on progress (started but not finished) might be calculated in your software.
I selected the option for retained logic. As you can see the remaining portion of Activity 2 was delayed by the still active SS link. The remaining part of Activity a is delayed to its early dates but it might still be delayed without impacting the project duration as it is not critical. The critical activity is Activity 3 and therefore have 0 Total Float. The remaining part of activity 2 can still be delayed 18 days before it becomes critical.
I used a SF link with lag of 10 days as to illustrate the fact that lag is similar to an activity, it has duration, it has a relative float with regard to its successor, a relative float value decades ago was labeled as "slack". The lag duration in links represents elapsed time on the link calendar and will be automatically updated, a convenient advantage of links with lags over an activity representation on lag.
Also "Lag", similar to activities have a start date, a finish date, total duration, actual/elapsed duration and remaining duration. When a link/lag still have remaining duration it is said to be active. In this case the start lag of 10 days have an elapsed duration of 5 days and a remaining duration of 5 days and 0 "slack" so it is still driving the end of Activity 2.
Always know what formula your software is using to compute Total Float, it can be misleading and is not as obvious as if kept separate.
Email: PPadmin@planningplanet.com
Replies