"Fortunately Spider development team is not fully contaminated by western models..."
Rafael,
You might very well say that (twice, even!), but I couldn't possibly comment! ;-)
As to Drag values changing, absolutely! Whenever the critical path changes, it is mandatory to:
1. Re-compute the Drag values of the new critical path tasks.
2. Re-compute the Drag Cost values of the new critical path tasks!
3. Determine the value-added of each optional task on the new CP to ensure its value is not less than its True Cost (True Cost = resource cost + Drag cost).
Projects are performed every day with optional activities that were worthwhile performing when they were OFF the critical path, but that should be jettisoned if their Drag makes their True Cost greater than their value-added.
Fraternally in project management,
Steve the Bajan
Member for
21 years 8 months
Member for21 years8 months
Submitted by Rafael Davila on Fri, 2013-02-15 16:53
Spider Monte Carlo is in its infancy so we shall wait until Vladimir disclose the details on how to use it. Also much of additional and unique functionality might still be on the work. Fortunately Spider development team is not fully contaminated by western models that for some calculations are wrong (resource critical float, negative float and a few others), so wrong the users go over and over the errors without even noticing.
I believe Vladimir recognizes the limitations of Monte Carlo for many reasons, some of them the ones you have mentioned. Still he mentions how valuable it is, maybe quantitatively it is not precise because of the data source but in qualitative/relative terms it gives you much value. I am a fan of statistical methods even in the case we can never get precise statistics, single valued analysis is no better than an approximate statistical analysis, single valued analysis is less.
I do not know if you ever read the book "The Flaw of Averages" and the story about the statistician who drowned because the average depth of the river was 3ft, he did not drawn because of a "black swan event" a 1,000 ft deep hole. The book warns about how wrong in many cases using only the averages is wrong.
The same thing happens in scheduling, it can even happen that the most possible critical path is not the one you get by imputing average values into a deterministic model. Probabilities of near critical activities might be relevant.
The same might happen to DRAG values, if the critical path changes they will change.
Best regards,
Rafael
Member for
21 years 8 months
Member for21 years8 months
Submitted by Rafael Davila on Fri, 2013-02-15 16:50
When you say "your software", I assume you don't mean MY software because I certainly don't have any! I agree with what you say about free float, both CPM and resource-leveled -- it is relevant (even if most schedulers don't understand it), and the old Qwiknet Professional product most certainly should have computed it.
"It will be interesting to see how Drag distribution comes out and how best to make use of this information."
As to Spider's new Monte Carlo functionality, I'm VERY eager to find out what it has to say about Drag distribution, and what YOU have to say about how best to use the info. Will it compute a distribution for Drag Cost, too? I wish you'd publish an article about it -- there is no one better equipped to do so.
As you may remember, I am NOT a huge fan of Monte Carlos, for several reasons:
1. People don't know the fundamentals behind them enough to use them with the necessary rigor (e.g., running 5,000 or more activities ALL on a default Beta distribution!).
2. Using estimates that are no better than guesstimates (as opposed to having the sort of historical data and benchmarks that are commonplace in construction).
3. Garbage in, Gospel out: inputting guesstimates, running them on a default distribution, and then believing whatever you get.
That said, if planners use the Monte Carlo with sufficient rigor, it can add value. (And I am very curious about what you report on the Drag distribution!)
Fraternally in project management,
Steve the Bajan
Member for
21 years 8 months
Member for21 years8 months
Submitted by Rafael Davila on Fri, 2013-02-15 15:06
Anything that is relevant to time or monetary cost matters, the slope of the cost curve matters. Spider recently added Monte Carlo to its probabilistic methods, 3 scenario approach is still available. It will be interesting to see how Drag distribution comes out and how best to make use of this information.
Regarding your mentioning of free float I would like to highlight that as well as there is a resource critical total float there is a resource critical free float. Because many software computations fail to always display correct values for resource critical float I suspect their values for resource leveled free float be wrong. In the case of Monte Carlo runs they might get thousands wrong values.
The following sample job might be too simple to rule out the possibility that your software is capable of always disclosing correct values for reslurce leveld free float but scince a single occurrence is enough to prove it, in case your software get it wrong it will be enough not to trust on the float values for a resource leveled job your software display.
By the way I do not believe there is such thing as always free float, consumption of free float even if on the deterministic schedule shows no impact it might reduce your probabilities of success if you perform a Monte Carlo run.
Member for
20 years 7 months"Fortunately Spider
"Fortunately Spider development team is not fully contaminated by western models..."
Rafael,
You might very well say that (twice, even!), but I couldn't possibly comment! ;-)
As to Drag values changing, absolutely! Whenever the critical path changes, it is mandatory to:
1. Re-compute the Drag values of the new critical path tasks.
2. Re-compute the Drag Cost values of the new critical path tasks!
3. Determine the value-added of each optional task on the new CP to ensure its value is not less than its True Cost (True Cost = resource cost + Drag cost).
Projects are performed every day with optional activities that were worthwhile performing when they were OFF the critical path, but that should be jettisoned if their Drag makes their True Cost greater than their value-added.
Fraternally in project management,
Steve the Bajan
Member for
21 years 8 monthsStephen,Spider Monte Carlo is
Stephen,
Spider Monte Carlo is in its infancy so we shall wait until Vladimir disclose the details on how to use it. Also much of additional and unique functionality might still be on the work. Fortunately Spider development team is not fully contaminated by western models that for some calculations are wrong (resource critical float, negative float and a few others), so wrong the users go over and over the errors without even noticing.
I believe Vladimir recognizes the limitations of Monte Carlo for many reasons, some of them the ones you have mentioned. Still he mentions how valuable it is, maybe quantitatively it is not precise because of the data source but in qualitative/relative terms it gives you much value. I am a fan of statistical methods even in the case we can never get precise statistics, single valued analysis is no better than an approximate statistical analysis, single valued analysis is less.
I do not know if you ever read the book "The Flaw of Averages" and the story about the statistician who drowned because the average depth of the river was 3ft, he did not drawn because of a "black swan event" a 1,000 ft deep hole. The book warns about how wrong in many cases using only the averages is wrong.
Best regards,
Rafael
Member for
21 years 8 monthsOops clicked twice the save
Oops clicked twice the save button.
Member for
20 years 7 monthsHi, Rafael.When you say "your
Hi, Rafael.
When you say "your software", I assume you don't mean MY software because I certainly don't have any! I agree with what you say about free float, both CPM and resource-leveled -- it is relevant (even if most schedulers don't understand it), and the old Qwiknet Professional product most certainly should have computed it.
"It will be interesting to see how Drag distribution comes out and how best to make use of this information."
As to Spider's new Monte Carlo functionality, I'm VERY eager to find out what it has to say about Drag distribution, and what YOU have to say about how best to use the info. Will it compute a distribution for Drag Cost, too? I wish you'd publish an article about it -- there is no one better equipped to do so.
As you may remember, I am NOT a huge fan of Monte Carlos, for several reasons:
1. People don't know the fundamentals behind them enough to use them with the necessary rigor (e.g., running 5,000 or more activities ALL on a default Beta distribution!).
2. Using estimates that are no better than guesstimates (as opposed to having the sort of historical data and benchmarks that are commonplace in construction).
3. Garbage in, Gospel out: inputting guesstimates, running them on a default distribution, and then believing whatever you get.
4. Black swans.
That said, if planners use the Monte Carlo with sufficient rigor, it can add value. (And I am very curious about what you report on the Drag distribution!)
Fraternally in project management,
Steve the Bajan
Member for
21 years 8 monthsStephen,Anything that is
Stephen,
Anything that is relevant to time or monetary cost matters, the slope of the cost curve matters. Spider recently added Monte Carlo to its probabilistic methods, 3 scenario approach is still available. It will be interesting to see how Drag distribution comes out and how best to make use of this information.
Regarding your mentioning of free float I would like to highlight that as well as there is a resource critical total float there is a resource critical free float. Because many software computations fail to always display correct values for resource critical float I suspect their values for resource leveled free float be wrong. In the case of Monte Carlo runs they might get thousands wrong values.
The following sample job might be too simple to rule out the possibility that your software is capable of always disclosing correct values for reslurce leveld free float but scince a single occurrence is enough to prove it, in case your software get it wrong it will be enough not to trust on the float values for a resource leveled job your software display.
By the way I do not believe there is such thing as always free float, consumption of free float even if on the deterministic schedule shows no impact it might reduce your probabilities of success if you perform a Monte Carlo run.
Best regards,
Rafael