(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.
For purpose of the discussion I am to Call FF Activities all duration type activities that have a FF predecessor link.
A FF link can create reverse logic computations that are relevant to scheduling strategy. If the FF link is driving the duration of the activity might be increased without this causing a delay on the project duration and at times it can even cause a reduction.
By adding a zero duration activity whose predecessors are equal to the FF Activity and whose successor is the FF Activity we can determine a duration amount by which the activity can be increased before the FF link stop being the driving link, will be equal to the free float of this zero duration split activity.
I am looking for some functionality that will disclose this duration without the need for the user to create the split. It will be computed only for activities with FF predecessors and will be used for the user to determine if the activity will be split, if the duration will be increased or left as is; a management decision, not a computer decision, on a one to one basis, one of my reasons to be an avid advocate for continuous activity scheduling. Of course being an advocate of continuous activity models means this issue must be identified and handled in an efficient way by our continuous activity models.
Perhaps some right click functionality can create the split for the user, this split will be a new duration type activity of zero duration with same start links as the original and a second activity linked FS(0) and remainder definition similar to the original. Then the user will determine how to spread duration and resources among the activities. If there is need for more splits the functionality can always be applied to the remaining activities.
Any comments, corrections and alternate strategies will be welcomed.
Best Regards,
Rafael
Printer-friendly version
Send to friend
Vladimir,
Trying to reason the logic on negative total float and the manipulation on late dates makes no sense, in any case makes a joke.
Take a look at the following schedule, if you run it on software that do such manipulation will give you negative float for the first two activities, will give positive free float for the first and zero for the second activity. Being zero and positive values greater than negative values it will display free float values greater than total float, it does not makes any sense.
There is a logical relationship between different float definitions, calculations are based on Early and Late Dates. If you tamper Late Dates with artificial values the relationship will be broken.
If you add resource leveling it becomes beyond any comprehension.
Best Regards,
Rafael
Rafael,
let's imagine that activity has total float --5. What happens if it will be delayed for 10 days?
I don't know the answer to this question without detailed schedule analysis.
One of the options - nothing, because next activity has TF=-15.
Float values shall be useful for decision making and show what may happen with the scheduled dates in the current schedule.
Vladimir,
Some developers insist on negative float to be embeded into the total float field in order to display criticality of unattainable date constraints. This is not necessary to show criticality, it is similar to making open ends critical without use of functionality that creates negative float.
The application of impossible date constraints to Late Dates that are prior to Early Dates distort not only Total Float values but also other float values. This makes other float values to loose meaning, make them erroneous.
I believe this might be one/main reason why some developers do not show other types of float.
Best Regards,
Rafael
Vladimir,
Thanks, it came out perfect, AWESOME, all float types are visible at the columns selected for display as well as at the activity dialog box. Not only in hours but also in days, very convenient for when some workdays have less hour than the others.
As you can see with the Start Flex I will be able to filter active reverse logic and will be able to know available slack if I split the activity. This particular value to me is extremely relevant when using FF/SF links that can cause reverse logic. A topic I rarely see people debating, as if float values do not matter except only Total and Free Float for delay claims. My focus is not on claims but on using the model as a practical planning tool to get better plans.
Under resource leveling it becomes even more interesting, the activity splits can be driven by resource dependencies, you might have activities with Start Flex and no Total Float. It is important to know how these splits will impact the schedule as in some cases starting ahead work on some split can impact other unsuspecting activities via the resource dependencies. Just another reason why intermittent work shall be transparent, another reason why interruptible schedule durations on a single activity is such a bad model.
I recall long ago advanced software would show several types of float in addition to the very basic Total and Free Float, I recall Artemis by reference when it was a mainframe only software. With these values there is much understanding of the logic, with these you do not have to go and search all predecessors/successors links to find out about what is driving and near [insane and impractical for everyday procedures]. I remember the literature would tell you about how to use them. I guess I will have to do my homework and re-learn lost knowledge.
I was frustrated before finding about Spider, I was starting to believe we were moving backwards and nobody cared, or perhaps that I was wrong. But I know you would not add functionality if it does not add real value, so maybe I was not that wrong. At times I think about following the masses and move to low quality and full of bugs but best selling software, but find it impossible to lower the standard and miss such functionalities.
Guess Spider team will have to continue competing against themselves, the gap is big and continues widening.
Best Regards,
Rafael
Vladimir,
Many thanks in advance, you know how tedious these computations can be if done outside the CPM but now I will have it at a click of the mouse. I will compare values after unleveled schedule run versus after leveled schedule run.
I have no doubt you have investigated this and many other similar computations.
Not sure if it makes sense to create some special functions that can make these values available for formula usage. I know of no software that allows the user to explore these computations in an easy way.
Something like:
Best Regards,
Rafael
Ok Guys,
Thank you for proposal!
Flex is accepted.
Regards,
Vladimir
Steve the Bajan
Agree, I like the idea about using the term Flex/Flexibility so much because is a descriptive term that say much about the value, as usual Vladimir is on the bulls eye with his choice of words.
Perhaps Start Flex and Finish Flex (Superfloat) can be considered. The instant response by Vladimir to relate it to Superfloat makes me believe that Superfloat can be re-named to Finish Flex as to show this relationship. In this way when a new user looks at the terms he/she will be confronted with the relationship between both values and activity duration.
Best Regards,
Rafael
Rafael and Vladimir,
"Together they will show activity duration flexibility in both directions."
This will be very nice. It would dissolve most of my concerns about computing drag with the continuous activity assumption.
"My guess is that it shall be = Activity Early Start - Max {Early Finish + lag of all Activity Start Predecessors}"
After some thinking, that seems like the right formula to me, Rafael.
And if I might be so bold as to suggest, "flex" (or "critical path flex") would not be a bad name...
Fraternally in project management,
Steve the Bajan
Vladimir,
But how would you name this value? Maybe on ADM literature there is a name for similar value that makes sense under ADM jargon but we are on PDM and although today PDM is dominant I have not being able to find a reference to it.
Best regards,
Rafael
Rafael,
my intital estimate also went this way (remember I wrote about free floats of preceding activities).
Just imagine two activities linked by both SS and FF. Succeeding activity duration is smaller, preceding activity is critical (no floats, no lags).
Exactly I want to see flexibility in both directions, about the math you know better than I do, most probablhy you will not have to use the dummy split to figure it out by going to the core CPM calculations.
My guess is that it shall be = Activity Early Start - Max {Early Finish + lag of all Activity Start Predecessors}
Rafael,
it works in both directions. Existing Superfloat - Total Float shows duration flexibility in forward direction, you want to add the same to the backwad duration. Together they will show activity duration flexibility in both directions.
Best Regards,
Vladimir
I believe both are of much value.
I am looking for a value that is independent of total float - "I am looking for a metric that will tell me how much the duration of Task B can be increased without delaying end of (itself) task B." Something that might happen only under reverse logic path.
Best Regards,
Rafael
Rafael,
it is an analogue of superfloat but to the start direction.
I am looking for a strategy to decide when to mimic P3 contiguous scheduling. On the second figure Task B is split into intermitent work, it reduces the duration of the overall job, although in other ocassions might not. P3 solution is not controllable and do not recall disclosing the distribution of the split(s). I prefer to decide when to split and how.
I am looking for a metric that will tell me how much the duration of Task B can be increased without delaing end of (itself) task B.
Then if I decide to split some functionality to make the split easy.
Vs.
Rafael,
do you mean finding minimal free float of preceding activities (in case calendars are the same)?
Sometimes to split is necessary for optimizing project schedule like in this example:
Hi, Rafael.
First, I was trying to avoid getting back into our debate about the software's assumption of continuous or non-continuous activities. We agree on almost everything, including all that you have said about making management decisions about where to split the activity. We seem to agree that:
1. An activity can almost always be split if it is valuable to do so.
2. Where we split an activity should always be a management decision.
3. The software should point the user to where the constraints are that might result in a reverse CP anomaly.
All that is agreed. The only place we disagree is:
What should be the default that the SOFTWARE, not the user/scheduler, applies in creating the schedule. Again it's NOT a disagreement about what the user should do, only about what the algorithm, which has been programmed "generically" by someone who has not a clue about the specifics of the project, should do.
1. You are used to the continuous activity assumption that is programmed into CPM algorithms so that you seem not to see the continuous activty default as an optional assumption. The software HAS to make an assumption and it chooses to make the assumption that the activity is continuous, which often makes the project longer in a way that is not clearly visible to most users. We seem to completely agree that this should be made more visible, and I am quite comfortable with using the continuous assumption provided that this is made highly visible and the software identifies the drag with the delaying constraint/assumption.
The other possible default that the software could use is to generate the shortest possible schedule (which most users actually think that the software is doing!). This is certainly a legitimate alternative, and is both practical and better (i.e., shorter schedule) in the vast majority of instances. But once again, the software must show the user what it is doing by:
By the way, the Sumatra.com Project Optimizer add-on to MS Project that computes drag does all of this and, additionally, does it ONLY if the user specifically elects to implement "optimization" of the schedule by splitting out milestones on activities with SF/FF predecessors. Once the user does this, they can see the impact and then go in and change where the activity is split, if they so choose.
Again, we are in complete agreement about what the user/manager should do, and about the fact that the software should act in a transparent and helpful manner. Our disagreement is just about the CPM algorithm's default, which I believe should be to emphasize producing the shortest possible schedule, not assuming a longer schedule in a not-very-transparent way due to making an assumption (i.e., that the activity MUST be continuous) that is almost never valid.
Fraternally in project management,
Steve the Bajan
Deveaux,
What is wrong is to assume splitting is always in order, that can be anything the computer decides.
Continuous models assume nothing nor it does prevents splitting, if you want to split one such activity or all will be a management decision, once you split the activity it is better than equivalent as you still got to decide where to split 50-50, 90-10, or perhaps 60-60 (>100) as very frequently split comes at a cost and overall duration will have to be increased as well as resources.
Users of the continuous model are aware but some extra functionality might help to identify such suspects for splitting.
You said the majority of activities can be split, I would add it is not only that can be split but that it is better if you split them on the majority of cases. Of course this does not solve the issue on how to split. I would tend to split my activities on my own terms and keep the free float between the last two splits as a buffer. If the activity is neither critical or near critical I might be tempted not to spilt the activity, the benefits of continuous work will prevail.
Because criticality changes as the job progress the desirability to split or not to split might change, therefore the need for continuous monitoring of metrics that will warn you, good management is a continuous operation.
Maybe a "Merge" functionality will also be of help. Perhaps double links shall be taken into account on the split and merge functionalities.
Best Regards,
Rafael
Hi, Rafael.
We have of course discussed this previously. You know my feeling -- that the continuous activity is an assumption that:
That said, we don't have to debate the issue and can agree to disagree as long as the software does precisely what you are proposing! I would be supremely comfortable with such a solution! I absolutely agree that a software package that uses the continuous activity assumption should:
1. Make the user aware of the issue and its potential impact (most users don't have a clue about it!); and
2. Point the user correctly to the FF (or SF, by the way!) relationship that is causing the constraint/delay.
It seems to me that the simplest way to accomplish this if the activity is on the critical path is through drag computation: a task which is causing the reverse critical path anomaly will have negative drag.
This of course makes no sense, as drag is a measure of how much an activity is pushing out the end of the project, and an activity cannot be pushing out a project by a negative amount! It is actually NOT the task that is delaying the project, but the FF or SF relationship! And that is where the software should point the user in diagnosing the cause of the project delay. Relationships and constraints, including lags, dependency relationships, calendars and calendar constraints, and resource constraints can ALL have critical path drag, and the software should diagnose it, identify the cause of the drag and measure it.
None of this, of course, addresses the case of the FF or SF relationship delaying an activity that is NOT on the critical path and therefore does not have critical path drag. It's less important (less critical?) of course if it is off the CP, but still has an impact. That impact is to decrease the activity's or path's float. I believe I am correct in saying that the issue only occurs when an activity has BOTH an FF or SF predecessor AND an SS or SF successor. Perhaps the software could simply look through the network, identify any such activities, and list them for the user as areas where attention might be warranted?
So glad to see you looking at this, especially in the Spider forum, as Spider is seems to be the only s/w package that both computes drag and seems aware of this as an issue.
Fraternally in project management,
Steve the Bajan
Email: PPadmin@planningplanet.com
Replies