(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.
Dear all,
I was looking at Floats, DRAG and FLEX in Spider. With Floats and DRAG everything seems to be clear an logical. But I still have a couple of questions, as help does not seem to provide a lot of info here.
1) As I understand Float Super = Float Free in the situation, when resource constrains have been removed from this spesific activity. Is it correct?
2) Why Float Total also has Float Finish Total and other floats don't have such destinction?
3) What is FLEX (I couldn't google for it either)
Regards.
Printer-friendly version
Send to friend
Evgeny, I just read this! Awesome!
And congrats on becoming an SP.
Fraternally in project management,
Steve the Bajan
Evgeny,
Congrats, you are pushing the right buttons, with good reasoning the message for much needed improvement will be eventually noticed.
If we want to get a performance better than actual experience we must look for changes as doing the same thing over and over will not make it. Good reasoning shall prevail, we need models that get closer to reality, different float values give much understanding.
Regards,
Rafael
Stephen,
Just to let you know, that I was taking PMI-SP exam yesterday and at the end there was a questioner on what I would advice to add to the exam.
I suggested to add advanced things like DRAG and variable resource loading into exam. Not to say that I expect too much of effect there, but slowly we will move it forward
Regards.
Evgeny
Very informative post updated here. its really nice to have such informational post with just a click.
Yes, correct.
But we will change this soon.
Regards,
Vladimir
Vladimir,
thanks for explanation. With this I was able to create a smaller schedule, which still reproduces this behavior.
As far as I understand, Activity 1 is delayed by a day, because when schedule was calculated with all activities being ASAP, Activity 9 was placed on the 16th.
Regards.
Evgeny,
in Spider Project ALAP now works following way:
the schedule is created as if all activities are ASAP and then ALAP activities are delayed as far as possible in the created schedule.
In your example activity 3 is delayed because activity 9 in the initial schedule started earlier.
To adjust all activities requires additional pass of the algorithm that takes time and will not change finish date. We try to accelerate calculations and skip steps that do not improve the result. But actually it can be improved easily, so we'll do it in future.
As for Super Float there is another problem in resource leveled schedule. Imagine that activity finish may be delayed for 20 days but resource that is required on this activity is busy from day 12 to day 16. Super Float information is an indicator that in any case required additional research.
Best Regards,
Vladimir
You are right, there is nothing 100% optimal about optimization algorithm, the difference might be that standard algorithms of the 70's would look for the solution using a static rule to solve the issue that will give you a workable result but at a very high cost in project duration compared to modern algorithms that are better.
Optimization is a mathematical science mostly understood by specialists, usually mathematicians and operations research scientists. Depending on how the algorithm works they catalog the algorithm. Some have names like genetic algorithm, branch and bound ...
I do not know a bit about them, same as I do not know a bit about how to design or fly a plane, I leave this to the specialist. I enjoy the ride.
All algorithm understand what ASAP means, but during resource leveling ASAP dates are delayed because the algorithm considers the resource constraints. Consider the 3 activity prioritization scenarios I used, they all yielded different results but same resource leveled float for all activities, which is good, very good.
Take for example the square root of 4, the correct solution mathematical solution is not {2} but {2,-2}. Same as most people would say 2 is the square root of 4 the resource leveling algorithm will yield one of the [near optimal] solutions.
Many schedulers have problems to understand resource leveled float is different to traditional float, the implications on how activities can be moved without delaying activity durations can lead to a solution that is not a continuous bar, this is why Spider display late bar not as a continuous bar, at times it can be, at times the solution is a step function.
Many do not even know about the difference between activity float and assignment float, that can be different in value for nay given activity. In your example they are equal, maybe because quantity of resource is limited to 1. When you have many activities competing for multiple quantities of the same resource it becomes more complicated, but Spider will give you the value.
For convenience I will give you again the reference just in case you missed it.
Going back to the square root of 4 the solution is {2,-2} but it excludes any value in between, it is not continuous, the same might or might not happen with resource leveled float solution set, at times might be a continuous set that can take any value between a range, at times might be a discrete set of values.
Any algorithm can be improved but got to be with caution as while by improving solution for some specific scenarios like the one you presented this might have negative impact under other schedules. This is why I said I would not mess with proven algorithms.
Maybe Vladimir, the mathematician, can give us better answer than this old engineer that no longer can solve first year calculus problems.
Rafael,
regarding my comment on Activity 1
I agree, this is not a big thing at all and it is possible influence the result by changing priorities. But are you actually saying, that it is correct, that requirement ASAP is not taken into account for Activity 1?
By the way, it is being taken in effect, when Activity 8 and Activity 9 are removed. So there is something not 100% optimal in the algorithm in my view
>
Regards.
Evgeny
By changing priorities you can controll sequence but I do not see any difference in float other than a redistribution.
I have a preference on the output without any activity preference as it seems to me more stable.
I would not mess with algorithms that have proven so good.
By changing priorities you can controll sequence but I do not see any difference in float other than a redistribution.
I have a preference on the output without any activity preference as it seems to me more stable.
I would not mess with algorithms that have proven so good.
Vladimir,
You probably did not read through all text here, but just to conclude. There are still 2 things, where Spider functionality I think is not quite clear/correct in the schedule, which I posted in my example on Fri, 2013-12-13 00:13 .
1) It is not clear what definition of superfloat is used to calculate the superfloat. It looks like the following definition can be applicable, but is it the one meant to be?
Super Float – the time period of potential activity finish delay without delaying the activity’s start and that does not delay the project finish date and assuming no further resource restriction for this activity till the end of the schedule.
2) Regardless of superfloat, it is not clear, why Activity 1 is delayed till 18 December, it can start already on 17.
Hi, Raphael.
Despite your nice words about academic contributions, I certainly don't think I can be dismissed as "an academic". Yes, in the past decade I have done some teaching of graduate courses as an adjunct professor -- but only due to having worked as a PM consultant and trainer in dozens of corporations in industries from software to IT to engineering to DOD to construction to nuclear and oil & gas energy. It was that experience that allowed me to write the book that allowed me to teach academically.
All of the ideas we are discussing are in my first book Total Project Control, published before I had taught a single academic course. I think we'd both agree with Yogi Berra: "In theory, there's no difference between theory and practice. In practice, there is." All these ideas came from practical experience, helping clients. I discovered critical path drag and how to compute it while consulting with Texas Instruments to compress a schedule on a toxic waste cleanup project in 1993. The corollary drag cost concept followed as a result of working with Cook Nuclear Power in Bridgman, MI, and Clinton Nuclear Power of Illinois Power Company.
Once I had the drag and drag cost concepts, the CLUB and resource availability drag (RAD) just came from applying the same concepts to a resource-leveled schedule. I was very familiar with those from helping clients implement PROJECT/2, a mainframe PM software package from PSDI, with whom I worked from 1987-1991. The DRED concept just came from applying commonsense.
I guess the DIPP could be considered "academic" -- actually, the idea for that came from my previous experience explaining economic concepts for the Federal Reserve Bank and from game theory. I learned that back in the 70s from playing chess, backgammon and poker with a bunch of friends in Boston. Among them, they'd win the US Open Chess Championship (1973), two World Backgammon Championships (1983 and 1987) and the 1995 World Series of Poker, but also make lots of money in real estate and currency options.
They all were a bit better at games than me, so I was left in a life of comparative poverty as a project management consultant. But if my PM contributions improve efficiency and maybe save some lives in fields like healthcare, pharma and the like, I won't be complaining.
Fraternally in project management,
Steve the Bajan
Steve,
Continue with the good work. Contributions from the academic world have consistently proven invaluable in all areas of knowledge.
Business know how good they are but technology might be lagging. A few decades ago Monte Carlo was exclusively for the Main Frame Computer [those with the punch cards in case you forgot] now a laptop can do it with some effort. The application of many valuable theories must wait for their time, meanwhile make them better, but please once in a while keep us informed.
Best Regards,
Rafael
Rafael wrote:
"In a similar way we have total and free float we might be interested on what happens if you remove resource constraint from a single activity as well as might happen if we remove resource specific constraint from the whole schedule while the rest remain."
Rafael, you are now seeing all the benefits that the TPC techniques and metrics can bring to the process! If we know the value/cost of time on the project, we can compute not just the drag and drag cost of work but also the drag and drag cost of each individual resource constraint. This is a hard thing for a human to do, but the software can do it rapidly! And if we know how much an individual constraint is costing us by delaying project completion (or even an individual deliverable), we know how much we can justify spending to make it go away.
This is quite exciting for me, as I've been trying to get it across in this forum for a long time, and you now seem to be visualizing it perfectly.
The next step is the DIPP and the DIPP Progress Index, to plan and track the project value against the cost estimate-to-complete (cost ETC) as changes occur as the project is implemented. The DPI works just like the CPI (indeed, CPI-derived ETC is an input), except that instead of just tracking cost, it tracks value-over-cost.
Fraternally in project management,
Steve the Bajan
In a similar way we have total and free float we might be interested on what happens if you remove resource constraint from a single activity as well as might happen if we remove resource specific constraint from the whole schedule while the rest remain.
Evgeny and Rafael, your posts are very apropos, but would take a lot to address in detail. I'll try to give brief answers.
First, Rafael, your post hits many nails on the head. (I have ceased to be surprised by how often you seem to immediately understand implications that I've been working through for almost two decades!) I'll just respond to this paragraph:
"Based on Drag definition I believe a way to calculate Resource Leveled Drag can be to assign a duration of 0 to the activity in question execute a resource leveling schedule run and compare schedule durations. Running this for every activity on the critical path is what is needed as activities not on critical path have 0 Drag."
The last sentence is correct -- provided one means the resource schedule critical path, as I am sure you do. As to the section I bolded, I just want to point out that it's not just activity durations -- the duration might remain the same but simply have to start (and finish!) much later due to a resource bottleneck. In general, it's important to compare the CPM schedule with the activities on the resource schedule CP -- that is the delay being caused by the resource insufficiencies. And then that info and the cost of those delays must be tied not just to the activity but also to the specific resource.Evgeny, you wrote:
I have been pushing this particular rock up this hill for almost 20 years, and whenever I think I'm getting close to the top, it rolls back down a ways. I have used these methods on specific projects where I have been consulting (to justify more resources, for instance), but I have had less success getting companies to adopt the overall methods. I now have two big clients who are finally beginning to use drag and drag cost, but it's been a long haul. Perhaps the most successful has been a defense contractor company that has not been a client of mine but where one of my former grad students took a job as a master scheduler. He has been quite successful in using these concepts and has been promoted several times.
Nuclear power and oil & gas refineries are the best candidates, because they always quantify the value/cost of project time, which is crucial. Indeed, it is from working with nukes that I extended drag to drag cost. Other industries should do the same thing (i.e., quantify the cost of time), but usually don't.
However, one other success story was someone who took a seminar through PMI with me in Baltimore in 2001. He went back to his company at the time (IT -- Lucent, to be precise) and put in places several of my TPC techniques, including measuring to the DIPP. he had remarkable success, and introduced some of the techniques to a major multinational engineering company, where he has had me in to do a lot of work.
P6 doesn't compute drag. I can't go into why on this forum -- but Joel Koppelman, founder of Primavera, thought these ideas were important enough to give me the following blurb for the back of my first book: "Critical path method needed a shot in the arm and Devaux delivers it in Total Project Control. His new book is an invaluable and much-needed advance in the art and practice of project management. Every project manager (and software developer) should read this book to understand what project management is all about." -Joel Koppelman, President, Primavera Systems, Inc.
There was an add-on to MS Project 2007 from Sumatra.com that computes drag. They've talked about extending it to MSP 2010 and 2013 (indeed incorporating other TPC functionalities, too), but I don't know if they will.
I first tried with the 2000 edition, but they've never seemed that interested. I did a webinar for their scheduling Community of practice this past summer, though. If you're a PMI member, you can download it for free here:
http://scheduling.vc.pmi.org/Public/Home.aspx
You might also find the PDF of this article at Defense AT&L Magazine interesting:
http://www.dau.mil/pubscats/ATL%20Docs/Jan_Feb_2012/Devaux.pdf
And InterPlan Systems has announced their next release will compute drag.
So we're still trying, Evgeny, we're still trying.
Fraternally in project management,
Steve the Bajan
DRAG in CPM without resource leveling might be easy to calculate without need to execute a schedule run for every activity but for resource leveled job as usual everything becomes more complicated and time consuming.
For these reason some calculations that take significant overhead but not needed to get the schedule and calculate everything else except these values are optional in Spider. Keep in mind Monte Carlo approach for statistical analysis takes a lot of computer time, a lot of schedule calculations here make sense to toggle off some calculations that you will never see. I would expect Spider will take such approach if they decide to implement Resource Leveled Drag.
Based on Drag definition I believe a way to calculate Resource Leveled Drag can be to assign a duration of 0 to the activity in question execute a resource leveling schedule run and compare schedule durations. Running this for every activity on the critical path is what is needed as activities not on critical path have 0 Drag.
Maybe even the concept can be expanded to Resource Drag if we define how much the demand of a resource is delaying the schedule completion. So if you eliminate the need or constraints in this resource it will give you some valuable information.
I believe DRAG concepts are valid under resource leveling but not computed, the good thing about it is that it is not difficult to understand. It will not solve all issues but add understanding on how your schedule behaves.
Stephen,
You described very interesting and logical concepts. I see in your profile, that you are an adviser to many different business and organizations, therefore I have a couple of questions:
Regards.
Evgeny
Evgeny wrote:
"With Floats and DRAG everything seems to be clear an logical."
Really, Evgeny? Really?? You have no idea how excited you are making me! Maybe after all these years of trying to explain critical path drag and its importance, it's finally catching on! (About thirteen people a day are now hitting the critical path drag page in Wikipedia, too!)
If folks are now understanding critical path drag and using it, I guess the next step is to explain the corollary (and important!) concepts of drag cost (DC) and true cost (TC) and maybe the CLUB (cost of leveling with unresolved bottlenecks) and the DRED (doubled resource estimated duration). They all use drag as a jumping-off point to add value to projects.
Drag cost is the amount by which the expected project profit (EPP) of the project is being reduced due to the drag of a CP activity. It can be caused by loss of early delivery incentives, exposure to liquidated damages (LDs), losing out on a contract because the bid time is too great, or increased cost due to burn rate or "marching army costs", i.e., overhead and LOE costs that go on until the phase or project is over.
True cost is the sum of drag cost and resource cost on an activity. Although finance departments in general have no clue about this concept (as they don't understand drag, or often even critical path!), it is the true cost of doing work on the critical path: TC = actual cost + drag cost. This is important because it allows the PM/scheduler to justify additional resources: reducing the true cost of an activity by increasing the resources. A CP activity that has a budget of $25,000 and drag of six days at a DC of $15,000/day has a TC of $115,000. Increase its budget to $50,000 to reduce its drag to 3 days and its TC becomes $50,000 + $45,000 or just $95,000.
The CLUB is the cost of having to level the schedule due to over-allocated resources, i.e., drag cost that is caused by specific over-allocations and that is attached not to activities but to the specific resource unavailabilities that are causing the additional drag and drag cost. For example, using this metric might allow us to see that our company's having only having two bulldozers is delaying ten activities a total of 8 weeks, causing five weeks of resource availability drag (RAD) at a DC of $150,000/week, or $750,000. That cost is tied specifically to the resource causing the delay, and can be used to justify buying an extra bulldozer.
The DRED is a measure of the resource elasticity of a given activity, i.e., an estimate of how long a given activity would take if we doubled the assigned resources. It is a variation of what is sometimes called "crash duration", but is much more understandable, accessible and applicable. Take an example of an activity that will take 20 days with current expected resource levels. We ask the subject matter expert how long it would take if we could double the resources. Possible answers might be 5 days (two people can carry refrigerators up flights of stairs MUCH more easily than one!); 10 days (said to be perfectly resource elastic, and actually quite rare in practice); 12 days (more common than 10 days); 17 days (only slightly resource elastic); 20 days (not at all resource elastic); 30 days (negatively resource elastic as the resources get in each other's way -- think of work being performed in a submarine or in a cockpit). Collecting DREDs upfront as alternative duration estimates allows the scheduler after assembling a first-pass schedule to see where there are activities with large drags and drag costs but robust DRED differentials, and to easily see where using the DRED will have a big impact on a CP activity's true cost.
I should apologize for not having contributed much to this forum of late -- I have been busy working on my manuscript for Beyond Earned Value: Managing Programs and Projects as Investments which is to be published by CRC Press next year. I hope to have finished it by the end of January and then to be back on Planning Planet a whole lot more.
Fraternally in project management,
Steve the Bajan
I believe Flex and SuperFloat can be modeled via hammocks that will capture any resource leveling and therefore always valid, but Vladimir can provide better answer as he knows SuperFloat better than I do.
For an unleveled schedule versus a leveled schedules float might vary and so Flex and Superfloat.
Rafael,
but do you agree with my observation, that in my example Spider does not take into considerations resource restrictions, when calculating Super Float? So, either Spider has some other definition of a Super Float or there is a bug.
By the way, what Spider now calculates as a Super Float I find also very usefull piece of information: how much activity can be extended without delaying finish data, provided resource restrictions are removed.
Regards.
To understand Superfloat the key is on Driving Link, we can easily be confused when driving link is a start link instead of finish link and here is where Superfloat comes into play. Look at the figure on my prior post and you will see driving link in darker color, it is a SS link.
Let answer the question - by how much finish of activity 1 can be delayed before it becomes critical?
We can go by trial and error increasing the duration to force a delay on the activity finish as follows.
by this point a finish link has become driving.
.....
We can delay finish by 10 work days before it becomes critical but we first must make it driving by finish links(s). The calculation give us this automatically, no need to figure it out for every activity. Spider is a contiguous model and Flex as well as Superfloat give us a lot of information.
I used my sample file but you can try to follow it using yours.
Hope this helps.
Rafael
Evgeny,
One of the float drivers that is missing perhaps in all software, although calculated by all is Remaining Lag.
http://www.ronwinterconsulting.com/Making_CPM_Transparent.pdf
http://www.mediafire.com/download/6cvaghd0hhbnrz6/RD003.001.sprj
From: http://www.ronwinterconsulting.com/Longest_Path_Value.pdf
Rafael
Rafael,
as usual, thank you for very interesting links. It is clear now, what the definitions are.
To be honest the more I work with Spider, the more documents and presentations from Vladimir I read, the more I come to the conclusion, that I did not see anything more structured, logical and complete in terms of project scheduling and project scheduling theory. This is realy an awesome tool with sound underlaying theory. This is despite of the little things I periodically find with it.
I still see however, that the way Super Float is calculated in the current version of Spider is a bit different from the definition.
See below example for Super Floats of Activity 1 and Activity 4 and Activity 10.
Your post says:
"Super Float – the time period of potential activity finish delay without delaying the activity’s start and that does not delay the project finish date."
However if I look at the Super Float of Activity 1 and Activity 4 and Activity 10, then the definition could be:
Super Float – the time period of potential activity finish delay without delaying the activity’s start and that does not delay the project finish date and assuming no further resource restriction for this activity till the end of the schedule.
Am I correct?
https://drive.google.com/file/d/0B1FBt_G3gCVqbE50R1g0Q3NURnM/edit?usp=sharing
Email: PPadmin@planningplanet.com
Replies