(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.
Rafael Davila's riddle on the joke-and-trivia page gave me an idea. How about a simple little CPM exercise?
Below is a critical path network logic diagram consisting of just 18 activities. The critical path is the bottom path (outlined in red). All relationships are FS, and the forward and backward pass numbers have all been filled in.
The questions:
A suggestion: time yourself and see how long it takes you to figure out each answer. Post your answers here, if you like. I'll give those who would like to do the exercise a chance, and then post my answers here in a few days. (Or alternatively, you can get the answers from the software. The two packages that compute critical path drag are Spider Project and the Sumatra Project Optimizer from Sumatra.com. But even if you use software, try computing the answers "manually" first!)
Obviously, this is a fairly simple exercise, with just eighteen activities. But if enough people like this, I have lots of other, much tougher, exercises from my graduate classes that I can post.
Fraternally in project management,
Steve the Bajan
Printer-friendly version
Send to friend
Hi, Anoon.
"I'm curious why by defining an activity duration (your answer), you haven't used the term "by having to do specific work"?
Isn't that in your Plan (or estimates) you will always be needing specifics in order to reach your desired target? So it can be predictable if you have defined your "specifics" in the first place."
I guess I thought this was understood. But it's a valid point -- an estimate of an activity's duration should be based on meeting its completion criteria.
"" Some estimates are reliable than others" - Does this statement applies to Plans or Schedules as well? If so, then "Drag" is dependent on the reliability of the plan or schedule that has been made."
Absolutely. And not just on the reliability of the original plan, but also, during project performance, on how well it has been maintained and updated. I'd say that's true for any schedule data and decisions (one reason why out-of-sequence work is so damaging to good schedule management).
"Thus, can I say that an "activity duration" and "drag" are the same thing?"
Nope, that you can't say. Activity duration and drag are only the same thing in the case of a critical path activity that has nothing in parallel. Duration is the amount of time an activity takes -- drag is the amount of time by which the activity's duration delays project completion. An activity that is not on the critical path adds no time to the project duration, and a 30D activity ON the critical path may add anywhere from 0D to 30D.
The answer I posted below, to Jorge, is the clearest explanation (with the specific examples) I can give for computing the drag of an activity in an all-FS network. Of course, PDM dependencies and lags make the computations much more problematic (though no less important). And finally, it should be noted that lags, constraints, resource unavailability, and delayed "hand-offs" can also have drag, especially in ABCP analysis.
Fraternally in project management,
Steve the Bajan
Stephen,
I'm curious why by defining an activity duration (your answer), you haven't used the term "by having to do specific work"?
Isn't that in your Plan (or estimates) you will always be needing specifics in order to reach your desired target? So it can be predictable if you have defined your "specifics" in the first place.
" Some estimates are reliable than others" - Does this statement applies to Plans or Schedules as well? If so, then "Drag" is dependent on the reliability of the plan or schedule that has been made.
Thus, can I say that an "activity duration" and "drag" are the same thing?
Thank you.
Hi, Jorge. I had actually posted the answers in a separate thread. But now I'll post them here.
First, you're right on question 1.
On Question 2 you are incorrect. Free float is the amount of time an activity can be delayed without delaying the EARLY dates of another activity. In order to have free float, an activity must first have total float. A is on the critical path and has no total float. So:
2. Which activity or activities has/have EXACTLY fifteen units of free float? Activities D & L have exactly 15 units of free float. More than 15 days of delay and D will delay the early start of H, and L would delay the early starts of all three of its successors.
You were also correct on two of the answers in 3, and incorrect on the other four:
3. How many units of time is each critical path activity ADDING to the total project duration of 160 units (i.e., what is the drag of each activity)?
The answers you gave were the durations of each of the critical path activities -- but, depending on the parallel paths, a critical path activity with duration of 40D might only add 1 day to the project duration, whereas a 5D activity may add 5 days to the project duration.
Drag is ONLY on critical path activities, and in a network with ONLY FS relationships, it can easily be computed as follows:
To show the answers to the exercise, and how to determine them, in diagram form:
Two activities are, by definition, parallel if they are not on the same logical path. So A and S are on every path (everything is a descendant of A and an ancestor of S) and thus have nothing in parallel, so their durations are their drags.
The activity with the least total float that's parallel with E is C (TF=20). E has a duration of 20, so its drag is the LOWER of 20 and 30, or 20. Similarly, I has drag of 10 (H's TF), M has drag of 15 (L's TF) and R has drag of 5 (Q's TF).
Jorge, if you have any questions about the answers, let me know. And if you'd like another exercise, let me know that, too, and I'll post one. (I have lots of them from my graduate classes.)
Fraternally in project management,
Steve the Bajan
I've never encoutered this thing called DRAG so I am guessing on number 3.
Hi, Anoon.
I'll answer the first question: an activity duration is how long an activity took. An estimate of activity duration is an estimate of how long an activity is likely to take. Some estimates are more reliable than others.
Your question really goes to the heart of planning, not just for projects, but for all human existence. To paraphrase a famous quote: "It is the job of the future to be unpredictable, and the one thing you can count on is that the future will do its job." Why plan anything, when we don't know what's going to happen? Why play poker when we (almost) never know what the next card is going to be? But Dan Harrington has made many millions of dollars playing poker by estimating the unknowns better than most people. Even in chess, we don't know what the opponent's next move will be -- but clearly some chessplayers are better than others. So too with planners, estimators and project managers.
There's an old question and answer about planning:
Question: Why plan when we KNOW the plan will be wrong?
Answer: Because once we have spent several weeks putting together a detailed plan consisting of thousands of activities and hundreds of resources, we have ELIMINATED ONE of the infinite number of ways the project could actually go!
So critical path drag, like project duration, like budget, like float, like early and late starts and finishes, like resource requirements, like everything else in the planning process, like the stock market, like the weather tomorrow, is uncertain and changeable. But some people will check the weather forecast and, even when it called for fair weather, will take an umbrella if dark clouds suddenly blow in. Others will regularly be caught in a downpour without an umbrella. Just like a project, where one of the big advantages of NOT planning is that the disasters will all come as complete surprises rather than the project manager having to worry about them beforehand.
Drag, like all planning tools, will be more useful on some occasions than on others. When someone's schedule starts slipping, every scheduler starts trying to figure out where the critical path drag is, whether they know what it is and how to do it or not.
Perhaps a more meaningful question is why would someone who doesn't believe in the value of estimating, scheduling and planning belong to a group called Planning Planet?
Fraternally in project management,
Steve the Bajan
Steve from Barbados,
"Drag is the amount of time that having to do specific work is adding to the project duration".
May I ask the following:
1. How do you define an activity duration?
2. Why bother with "Drag" when an activity duration cannot even be estimated or predicted accurately?
3. And how do you estimate an activity duration?
Thank you.
Miklos, are you still here?? I'm sort of waiting for you to confirm which drag totals you feel are correct, because, depending on which ones, I think I can provide a way to make the right drag computations even in a continuous activity CPM algorithm.
Steve
STEVE COMMENT #17
Okay, you are beginning to convince me that Mike Testro is correct: all projects should be scheduled using only FS relationships! Certainly the continuous PDM algorithm, in specific (and, fortunately, contrived!) cases, not only can make the project longer but also gives answers that are unhelpful to the point of absurdity. This may be the reason that the computation of drag (i.e., telling the scheduler how much time a critical path activity is adding to the project duration so that the scheduler can figure out how to optiize the schedule) has never previously been defined or used.
Nevertheless, I will try to see if I can "salvage" the drag computation in the continuous algorithm. First, though, some points, and then some questions:
As I say, let me somehow try to resolve this issue (which is not a problem either in pure CPM nor in non-continuous PDM) for continuous activity PDM. But first, let me ask:
Earlier, Miklos, you listed the drags as:
Drags for A,B,C
| B is 10 days | B is 9 days | B is 11 days | ||||||||
| Activity names | A | B | C | A | B | C | A | B | C | |
| Act. Durations | 10 | 10 | 10 | 10 | 9 | 10 | 10 | 11 | 10 | |
| 3 | Drag in continious act dur case time lags (already agreed) | 0 | -10 | 0 | 1 | -9 | 1 | 0 | -9 | 0 |
But in the most recent post, you say:
"Miklós and Rafael have the following solutions
When B is 10: A = 0, B= -10, C = 0
When B is 9: A = 1, B = -1, C = 0
When B is 11: A = 0, B = -9, C = 0"
So what IS your calculation for the drag of B when it has a duration of 9? Is it -9 or -1? Needless to say, it makes a huge difference. I think the continuous activty algorithm would say -9, yes?
Second: Miklos, did you look at the network when I decomposed it into all-FS+0 relationships in my COMMENT #13? If not, would you do so and see if you agree that mine are the correct answers (in fact, those that someone like Mike Testro, doing the schedule in all FS+0 relationships) would get?
Fraternally in project management,
Steve the Bajan
Sorry guys for disappearing so long. I stille have a jetlag.
Steve
Let's deal with my sample, and your answer for that in Steve #13
steve says that the drags for A,B,C are the follows in case of continious activities and time lag.
When B is 10: A = 0, B= 0, C = 0
When B is 9: A = 1, B = -1, C = 1
When B is 11: A = 0, B = 1, C = 0
Sorry for not dealing with links, but let's make tis stuff clear first
Miklós and Rafael have the following solutions
When B is 10: A = 0, B= -10, C = 0
When B is 9: A = 1, B = -1, C = 0
When B is 11: A = 0, B = -9, C = 0
For this just look at Rafael's letter just before MIKLOS COMMENT #10.
You can simply check it, by changing the duration of activity B from 10 to 0. The project duration will change from 20 to 30 days. As the drag is defined for an activity (from the definition!!!!) as the difference of the
drag for an act. = project duration with the original act. duration - project duration when dur. of the act is zero
it means that the drag for B is -10 days. Check this by looking Rafaels's pictures on this before my comment #10.
Rafael!
I knew, that volume lags will cause problems, that's why I want to go step by step, and now I'm not glad to run forward with this. We still did not agree with the drag for the simpliest case.
Let's make this issue clear after we have the same solution for continious case with time lags.
Miklós
STEVE COMMENT #16
Rafael wrote:
"Almost always or always does not means it shall be applied always, in addition using a single rule across the board, it is wrong. The software will make the wrong assumptions or perhaps the unwary scheduler will allow it to do so. You just shall only split critical activities and not be a lazy scheduler, do your homework and do the necessary adjustments, is very simple, it is not that difficult to figure out when splitting a critical activity will result in shorter project duration, perhaps for an unqualified scheduler."
I'm not making myself clear, because we are in vilolent agreement about this. Every case is different, and there should be absolutely be careful analysis before EITHER splitting activities OR not splitting them and thus starting activities, and perhaps finishing the project later. I would prefer that ALL PM sofware provide an option to the scheduler to use either a continuous or a non-continuous algorithm. The only disagreement here is that, given the software will NOT offer such an option, offering ONLY the continuous guarantees that a large percentage of schedulers, who SHOULD know better but DON'T, will make the projects take longer, cost more, and cause lives to be lost in a not insignificant number of cases. Yes, the bulkheads on the Titanic SHOULD have been higher, it SHOULDN'T have been traveling so fast through an iceberg field, and there SHOULD have been more lifeboats -- but 1,600 people who had NOTHING to do with those decisions died! And that's the problem: incompetence IS the human condition. Let's work to educate schedulers better; but let's also provide them with tools whose default best matches what they'd want to do if they understood the problem. And you said, and I agreed, that 99.832 % of the time this would be to split activities so as to get a shorter schedule.
"It is not about dead men, this is not a morgue nor a Broadway Play, it is about taking responsibility and command of the schedule. Most jobs are tight on budget, the pharmaceutical jobs are the exception,"
They are not by any means a small exception. Just in the construction industry, hospital construction, levees, potable water wells all have a direct impact on people dying if they take longer than they should. In other industries, delays not just in pharmaceuticals but also medical devices, defense systems (Google "dhahran" and scud" and check out what the impact of a one day delay can be!), airport security systems, and, perhaps most of all, emergency response cause hundreds and thousands of deaths unnecessarily. And when they don't, they still cause losses of money. One of the tragedies of project management is that the value being lost by inadequate scheduling is not being measured. It's what is known in economics as an "externality", and the results include the routine failure to spend an extra dollar where the return might be tens or hundreds or thousands of times more in ROI, contracts that exacerbate the principal-agent problem and moral hazard, and law suits that use up money that could far better be spent on cranes, backhoes and laborers than on lawyers.
Until we, as a profession, start to recognize that we are in the business of managing investments, and not just spitting out schedule dates, we will fail to achieve the proper professional recognition that we should have.
"Crashing a schedule by brute force can be done even by the inexperienced scheduler."
But isn't. If you weren't even willing to go in and compute drag in a very simple network, most schedulers aren't going to be bothered to do any analysis that the software is not helping them with, nor make the decisions for which analysis of resource cost vs. drag cost is essential.
"it is like a Catholic trying to convince a Jew that Christ is the messiah."
Only if simple economics (including the cost of time) lies as much in the realm of faith as religion. (Some would say it does.)
"PS. By the way I believe that as more and more parallel paths become critical then DRAG is useless as it becomes equal to 0 for all activities in these critical paths, but this is an issue I will leave it to you. Not to mention when multiple critical path share some activities."
Now this is a VERY insightful comment! As optimization is performed, both float and drag are "squeezed" out of the schedule -- on individual activities! (Of course, that very process relies on drag computation, too!) Now we may have parallel paths where shortening either does nothing to shorten the project unless we shorten both. The ideal would be allow the scheduler to click-and-drag the mouse to highlight a chunk of the network, define it as though it were one task, and have the software compute its drag as a chunk! This would have huge additional vallue. Unfortunately, if you leave it to me, although I have done analysis of a lot more very valuable PM metrics and techniques than drag (you can read about them in my Total Project Control book), I know nothing about programming. Persuade Vladimir to incorporate the full range of TPC techniquesinto Spider -- I would say that drag is not even the most useful metric in TPC, merely the one whose value is the most intuitively obvious to schedulers.
If it is not valid under resource critical paths and useless in multiple parallel critical paths then it is of not much value."
If you understood me to say that drag is not valid for resource critical paths, I was not making myself clear: it can be computed for the resource schedule critical path in exactly the same way as for CPM criticlal path. What's significant is that, computed properly on the resource path, drag (and the all-important drag cost) is even MORE vlauable, in that now you're attaching the cost of drag not only to the work activity, but ALSO to the resource performing that work! And, again if done properly, the drag cost now can be tied to insufficiencies of specific resources during specific calendar periods! And that's huge, for setting staffing levels on one project or accross a multiprojected organization. Check out the article "Paving the Critical Path" at ProjectsatWork.com:
http://www.projectsatwork.com/content/articles/234378.cfm
Fraternally in project management,
Steve the Bajan
RAFAEL DAVILA COMMENT NO 102
Stephen,
Quote - You are suggesting that the default should be NOT splitting -- but in an earlier post, you said that you "almost always" could split. I'm saying that I would have defaults as the "almost always", especially when the alternative may result in a (usually very costly) longer schedule. But either way, the upside/downside of splitting should be analyzed.
Almost always or always does not means it shall be applied always, in addition using a single rule across the board, it is wrong. The software will make the wrong assumptions or perhaps the unwary scheduler will allow it to do so. You just shall only split on selected critical activities and not be a lazy scheduler, do your homework and do the necessary adjustments, is very simple. It is not that difficult to figure out when splitting a critical activity will result in shorter project duration, except for an unqualified scheduler, unable to identify reverse logic and what it means it might be difficult.
It is not about dead men, this is not a morgue nor a Broadway Play, it is about taking responsibility and command of the schedule. Most jobs are tight on budget, the pharmaceutical jobs are the exception, they live on the opulence. Splitting of activities comes at a cost. Crashing a schedule by brute force can be done even by the inexperienced scheduler.
Well my friends this is all, this is as far as I am going in this debate, it is like a Catholic trying to convince a Jew that Christ is the messiah.
Best regards,
Rafael
PS. By the way I believe that as more and more parallel paths become critical then DRAG is useless as it becomes equal to 0 for all activities in these critical paths, but this is an issue I will leave it to you. If it is not valid under resource critical paths and useless in multiple parallel critical paths then it is of not much value. Not to mention when multiple critical path share some activities.
STEVE COMMENT #15
Rafael wrote:
"The general rule is that blind splitting is in error and uneconomical. Many Project Managers understand the advantages of keeping the continuity of the activities and use lag instead of splitting with this knowledge. Allowing for the software to split activities at will is calling for chaos."
Now you are creating a straw man, Rafael. And the general rule is that creating a straw man is most efficiently done by splitting the creating into first creating the body, then waiting till you create the arms and legs, then waiting and creating the head, and then, finish-to-finish, putting all the parts into the old suit of overalls and saying it's what the other side is suggesting.
No one ever suggested blind splitting. Just as no one suggested blindly NOT splitting, and so getting the crane only once to install the chillers, and thus finishing the hospital annex you're building take an extra three weeks with loss of life of two patients a week who would have otherwise been saved. In either case, we need to know the cost/benefit (including resource cost, drag, and drag cost) of splitting and the cost/benefit of NOT splitting. You are suggesting that the default should be NOT splitting -- but in an earlier post, you said that you "almost always" could split. I'm saying that I would have defaults as the "almost always", especially when the alternative may result in a (usually very costly) longer schedule. But either way, the upside/downside of splitting should be analyzed.
"Guess the Big Dig was managed under the wrong perception activity splitting across the board is good, a very dangerous option, a wrong option. I doubt they did go as primitive as FS(0) only but probably made the wrong choice about activity splitting."
It's okay, 'cause I guess the Hoover Dam was done with splitting, and it finished two years ahead of schedule!
Fraternally in project management,
Steve the Bajan
RAFAEL DAVILA COMMENT NO 101
Steve,
Whenever you substitute overlap created by lag with a split with FS(0) relationships the model is not equivalent, is a different model. It will allow for the split parts to separate and then you get a situation like the one I mentioned for what happens when you split a continuous activity. The general rule is that blind splitting is in error and uneconomical.
Many Project Managers understand the advantages of keeping the continuity of the activities and use lag instead of splitting with this knowledge. Allowing for the software to split activities at will is calling for chaos. It is the keyboard jockey who do not understand that even when primitive CPM theory is easy to understand and follow, its simplicity comes at a real cost. The real issue is not in creating or not a few extra activities for ease of understanding, the issue is to create a better model.
Guess the Big Dig was managed under the wrong perception activity splitting across the board is good, a very dangerous option, a wrong option. I doubt they did go as primitive as FS(0) only but probably made the wrong choice about activity splitting.
Best Regards,
Rafael
STEVE COMMENT #14:
Rafael wrote:
"Spider solution would be to manually split the activity and compute DRAG independently for each split."
I agree, except that I would not call that the "Spider solution": I'd call it the "intelligent scheduler solution". And of course, it's at least as easy to accomplish in a non-continuous algorithm. The non-continuous algorithm will show the project duration (and the drags) with the activity's early start as early as possible, even though its last nanosecond cannot take place until the finish constraint is satisfied (again, I'd like to see it represented with a dotted line to call the scheduler's attention to what's goin on). If the scheduler wants to split it in another way and delay the start, s/he can always do that, carefully noting, as you point out, the increase in project duration, drag, drag cost, and expected project profit (and maybe lives saved or lost).
BTW, it is also always easy to model a continuous activty in a non-continuous algortihm. To use Miklos's example, just make A BOTH a FS-5 and a FF+5 predecessor of B, and you get the same result as you would with the continuous algorithm!
The reason that the software packages use continuous activity algorithms (even though, as you point out, Rafael, they can be split 99.832% of the time!) is all because some programmer from back in the '60s who probably knew precious little about CPM scheduling, found it easier to input just the one algorithm and decided continuous was the easiest to program. And the result has been that, for about half a century, projects run by schedulers who couldn't tell a continuous or non-continuous algorithm from a hole in the ground have been making projects longer than they need to be, thus costing money and costing lives.
Fraternally in project management,
Steve the Bajan
STEVE COMMENT #14
"Does the above holds no matter what relationship types?"
Absolutely not! With PDM dependencies, one would have to determine what those dependencies would be if modeled purely with FS0 relationships (as I did in my response to Miklos), in order to compute the drag correctly.
"Still my question is, what when the critical path is driven by resource dependencies, are DRAG calculations still valid?"
No, and they shouldn't be. It's very imporant to understand whether the reason for a delay is due to CPM logic, a scheduling constraint, or due to a resource insufficiency. It's (usually!) much easier to correct a resource insufficiency than the logic of the wy the work must be done. Indeed, resource availability drag (or RAD, in TPC terms) is a key metric to help justify the cost of getting the needed resource (the Cost of Leveling with Unresolved Bottlenecks, or the CLUB, in TPC terms).
"About the differences between Spider and Sumatra on basic jobs is no surprise to me, many times before I found MSP in error..."
I know that the Sumatra people had to do quite a bit of work (working with a US DoD scheduler) to allow the user to "optimize" the project so that MSP would give the correct data.
Fraternally in project management,
Steve the Bajan
STEVE COMMENT #13
Notice that Mike Testro is not getting involved in this discussion at all. I suspect the reason is that he thinks this discussion is like arguing over how many angels can dance on the head of a pin. And you know what? I think he may be right! Since Mike uses only FS relationships, this whole discussion is moot for him.
I am sure that any good scheduler (Mike?) who uses only FS relationships would be able to come up with as good a schedule (indeed, the same schedule!) as anyone using PDM. And the fact is, if one wants to know the drag of an activity in a PDM network, re-model it into an all-FS network, using milestones, activities for time lags, and decomposition of the predecessor at the lag amount for volume lags. In addition, as soon as one does that, one sees that the continuous activity versus non-continuous activity controversy is mooted -- they're all non-continuous. (And this discussion is making me begin to think that Mike's approach may be the right one! Well, almost...)
So how would Miklos's network be modeled using only FS relationships? Because once we do that, the drag amounts become easy to see. Miklos, you wrote: "We have already agreed in row 3." I'm sorry, but we haven't. I agreed that, with time lags, A would have 0 drag. In my opinion, every other activity and lag would also have 0 drag, because everything else would have something in parallel with 0 float. So I don't understand why you feel that B would have drag of -10. For time lags and continuous activities, my drag numbers would be:
When B is 10:
A = 0, B= 0, C = 0
When B is 9:
A = 1, A-B SS time lag = 1, B = -1, C = 0
When B = 11:
A = 0, B = 1, B-C FF lag =1
It might help if I explained how this would look (for me!) in an all-FS network, so here it is. I think at least you'll see the reason for my answers, and you can examine it when B = 10D, 9D, 11D...
In this network, a = activity, sm = start milestone, fm = finish milestone, sst = SS time lag, and fft = FF time lag. (Remember, all time lags are modeled as activities and all relationships are FS+0):
Asm = 0D No preds
Aa = 10D Preds: Am
Afft = 5D Preds: Aa
Asst = 5D Preds: Am
Bsm = 0D Preds: Asst
Ba = 10D Preds: Bm
Bfm = 0D Preds: Ba, Afft
Bfft = 5D Preds: Bfm
Bsst = 5D Preds: Bsm
Ca = 10D Preds: Bsst
Cfm = 0D Preds: Ca, Bfft
If the SS+lags were volume lags (FS and FF lags are always time lags because otherwise they should be modeled as activities), I would decompose the predecessor at the amount of the lag, so that Aa, for instance, wold become Aa and Ab, each of 5D duration with Aa being an FS+0 pred of Bsm.
I agree, this is so hard and would be so much easier were we in the same room. But I hope it helps to see how I would approach this, and thus how I would get my answers. If you would approach it differently, could you model your approach using just FS+0 relationships and milestones? (Of course, it's much harder to model than if using PDM relationships -- but when one is finished, I think it's much clearer - which I suspect is why Mike favors it.)
Fraternally in project management,
Steve the Bajan
RAFAEL COMMENT 100
Miklos,
Under SS, SF, FS an FF with lag seems like Spider Project have no issues, definitively Wiki is limited to FS relationships. Wiki is not my algorithm it was presented as the starting point to investigate. Mine is whatever Spider use, the software developer got to do his homework.
Wiki solution to DRAG applies to some models and not to all, same as non-continuous PDM.
Spider Project does not recognize non-continuous PDM, I believe they agree with regard that if you are to split an activity you got to do it on a one to one basis to decide on each case to split or not to split and if durations will change as well as resources or even logic.
Take for example you have a continuous activity to install 4 chillers at the top of a 7th floor roof. If continuous you will need only one crane mobilization, if non continuous and you decide to split in two you have to decide on each split how many chillers will be installed, if there is efficiency lost, if there will be two mobilizations as the rental for the crane can offset the re-mobilization costs. If the activity will be split you will have the installation resources on each split but also the crane will be available in the span between the installations, an additional activity (a Hammock) is needed, otherwise your resource modeling will be wrong. I do not now software that will make this decisions. And what if a manager solution is different than the programmed and mine?
This is so easy to understand between users of Spider all we need is a single or at the most two sentences to forever agree, not even a sample job of a single activity split is needed.
Spider solution would be to manually split the activity and compute DRAG independently for each split.
About DRAG under resource constraining I have not investigated it yet. If it depends on resource dependencies, Spider Project can generate resource dependencies but it generates only one per parallel occurrences as it is enough to solve the resource leveling and display the resource delay in some way. For purpose of DRAG computations, relevant parallel resource critical paths might be missed. The software will display all resource critical activities as critical but will not display all resource dependencies. This is kind of complex and Vladimir is the person who can really tell us.
If just the computation of simple DRAG creates computational overhead, same as the generation of a single resource dependency per resource delay then adding to all this an additional level of computation that can be several times that of the first two combined it might be that the cost outweigh the benefits.
By the way I do not understand your examples nor your definition of volume lag. For a start can you define volume lag? Iin spider in order for it to exist some volume of work must be assigned to any activity linked by some volume lag. It is different to activity duration, depending on how the model is set up you might change activity duration without changing activity volume of work as in the case of volume of work activity type.
After we agree on volume lags then I suggest exchanging files using a file format we can agree via a file hosting service as Rapidshare or MediaFire. I can read Spider, MSP and XER, importing from Excel and CSV can be done but is not as easy as data must be imported to multiple database tables and at times in a particular sequential order. We use the concept of Reference Books, more advanced and powerful than Excel or CSV.
Best Regards,
Rafael
PS. DONT BE SURPRISED IF I START CREATING MY REFERENCE NUMBER AT RANDOM - WILL BE FUN, BETTER THAN PP WAY.
MIKLOS' COMMENT #13
Rafael
Steve and Rafael
Here comes the results from the sample project - as I promised yesterday - when activities are non-continious. You can simple check this - if your software can handle non-continious activity durations - by simple changing the activity durations to zero.
I also provide the results when lags are volume lags, it is also easy to check 'cause if act. duration is set to zero, then following lags should be set to zero as well.
I need your comment on my solutions Are you agreeing or not?
Drags for A,B,C
| B is 10 days | B is 9 days | B is 11 days | ||||||||
| Activity names | A | B | C | A | B | C | A | B | C | |
| Act. Durations | 10 | 10 | 10 | 10 | 9 | 10 | 10 | 11 | 10 | |
| 3 | Drag in continious act dur case time lags (already agreed) | 0 | -10 | 0 | 1 | -9 | 1 | 0 | -9 | 0 |
| 4 | Drag in non-continious act dur. case time lags | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 |
| 5 | Drag in continious act dur case volume lags | 5 | -5 | 0 | 6 | -4 | 1 | 5 | -4 | 0 |
| 6 | Drag in non-continious act dur. case volume lags | 5 | 5 | 0 | 5 | 5 | 0 | 5 | 6 | 0 |
We have already agreed in row 3.
All the others have to very carefully checked, because different interpretations exist for non-continious time analysis.
Steve! please check the calculation with your algorithm, I think it will never give the same result.
Rafael! Drags in resource constrained cases require a completely new solution, but I also have a very simple idea for this.
If you all agree with these solutions then we can go to the definition, and to the algorithm.
Please check
Miklós
Miklos,
If we set aside the issues in min/max relationships then we can continue the debate here or in a separate thread in PP. PP is for all levels of expertise and you only get involved on what is of your interest. I hope more and more people from academia join PP as the interaction with the actual practitioners shall benefit both.
You got to realize I finished schooling about 30 years ago and went directly into PM practice working for a couple of General Contractors, then within my own Construction Company and now as a Civil Engineering and Cost Estimator consultant. I am not sure but maybe for over a decade my school no longer have a Project Management program per-se within the Civil Engineering department, perhaps after the head of the program retired. Therefore theoretical algorithms are not my strong. I depend on the algorithms as implemented by Spider Project.
In Spider Project the calculation of DRAG is an option and not automatic, I suspect because it is a time consuming exercise in big compressed networks with hundreds or thousands multiple parallel paths. The algorithm for this I do not know.
Does the above holds no matter what relationship types?
Maybe the algorithm to analyze longest path by Ron Winter can give you a clue as it might identify parallel critical paths. In his site Ron Winter exposes the algorithm for the benefit of everyone. Still my question is, what when the critical path is driven by resource dependencies, are DRAG calculations still valid?
About the differences between Spider and Sumatra on basic jobs is no surprise to me, many times before I found MSP in error and have my issues with the sticky constraint it do add to some activities as the job is progressed. I no longer use MSP not even to satisfy my curiosity. I believe there is a possibility the problem is with MSP and not with DRAG theory.
Best Regards,
Rafael
MIKLOS' COMMENT#12
Rafael and Steve
Rafaell,
I really sorry your decision, max relations could be the last steps on this road. This moment we have the problem, that the algorithm gives different results in Spider, and in Sumatra for the same easy sample project. This is not good, and you (we) should clarify it or remove it from both applications, and from Wiki and from this site as well
At this moment it seems to me that the algorithm given by Steve works only at CPM (AOA representation) and in precedence duagramming when only FS relations are allowed, and only non-continious approach allowed, and do not work it in any other cases. But we even couldn't justify this in almost 30 comments. This looking for the parallell smallest float works only in this case, and NOT in any other cases.
I'm convinced that I have the solution for the general case that can handle all the possible cases, therefore would work in simplified cases as well, cause I teach it, but to convince you it require's time and a strict step to step approach around in twenty different steps. (Now we are around 30 and we couldn't finish with the first one)
As this site is definietly non adequate for this type of theoretical discussion I understand your decision, I was thinking about the same thing as I saw the effiviency of our converstaion.
Maybe we should organize a conference for real planners. As far as I know Fred Plotnick organized some conferences Construction CPM for "real" planners, with the slogen "we go where no conferences have gone before" or something like that but the end more emphaisi was put on introducing MSP and Primavere and etc. by their developers, than were put on issues that can add something to theory.
SteveI
I'll send you my solutions, but I have to go sleep as it is around 3 AM here in Melbourne, and I would like to adopt myself to my jetlag or what is called, and I go to bed.
Miklós
STEVE COMMENT #12:
Miklos, if the lags are indeed time lags (not often the case, in my experience), then my answers would agree with yours: no activity or lag would have separate drag.
I am curious as to why you get answers different from mine when they are volume lags...
Fraternally in project management,
Steve the Bajan
Miklos,
I will call myself out as I have lost interest on minimal/maximal relationships as the software I use do not implement such functionality, also the software you referred I did not liked. Seems like the incompatibilities of many such links create a set with no solution at all and the handling of such situations is poor, much improvement is still needed.
Best regards,
Rafael
MIKLOS' COMMENT #11
Rafael
Sorry for not reflecting into your comment, but if we do not concentrate on the lag issue, that this will be a neverending story without any mutual benefit.
Let's go back to drag.
Steve!
In my example I've defined time lags. So please give us your solution when all the lags are time lags.
This is the simpliest case if we do not agree on this, than it i has no meaning to go to the more sophisticated cases.
We have to define the drag when both minimal and maximal relations are allowed with volume and time lag, and when both non-continious and continious approach allowed at the same time.
(Anyway I've calculated the drags when lags are volume lags and my results are still not the same as yours)
If we do not go step-by -step than this topic won't go anywhere.
Miklós
The following illustration is a rough idea I have about how to address the crashing issue in a way non-linearity of time-cost curve is not ruled out.
STEVE'S COMMENT #11:
First, we are not alking about mathematical truth here (in the sense that 2 + 2 = not 5 but 4) -- we are talking about a model and, in the words of George Box: "Essentially, all models are wrong, but some are useful; the practical question is how wrong do they have to be to not be useful." The original AOA was all FS, but had other problems (dummy activities, etc.). An AON diagram using all FS relationships (as I believe Mike Testro recommends) probably the version that allows tghe most "accurate" modelin of a schedule, provided that sufficient decomposition is done. (My caveat: I don't think the vast majority of schedulers do sufficient decomposition, so in my experience one gets longer schedules than necessary. And I believe that, of all the benefits CPM provides, schedule optimization is the most beneficial.) Continuous and non-continuous models both have problems in terms of distorting reality. Rafael, as you said, you can (almost) always split the activity. Since I believe that it is crucial that the software compute the shortest schedule, the one I prefer is the one that will do that. However, we agree that the software should let the users know what the algorithm is doing, so they can react apprpriately. (And by the way, drag, like float, is there anway -- you can compute it or not. But when the project starts slipping, boy, is it ever a useful thing for the software to compute!)
Miklos, the whole difference between our results is based in the difference between time and volume lags. In the US, by far the most popular s/w package is MS Project. Second is Primavera. Neither have volume lags. As a result, the time lag is used to represent volume las. (BTW, even when volume lags are supported, I'd bet most people still use time lags for volume lags.)
So, if an SS+5 TRULY represents a time lag, then the lag has drag and the project cannot be shortened simply be reducing the length of the predecessor. However, if it is a volume lag (again, as it almost always is when there's onlyone type of lag) , then getting the predecessor's work done faster WILL reduce the amount of time before the successor can start (i.e., digging the first 100m. of trench in one day instead of 5). Thus the drag is in the predecessor activity, and the scheduler should be pointed to it as the place to reduce project duration.
Volume lags and time lags are just different (I believe I recall having this conversation with Vladimir Liberzon), and I have no trouble with the drag being assigned to a time lag.
Miklos, in your example, if the SS+5 represents getting the first 100m. of trench dug, then that is where the time is being added, and the project can be reduced by up to 5 days by etting that work done faster.
Fraternally in project management,
Steve the Bajan
MIKLOS' COMMENT#10
Guys,
We have solutions from Steve, Miklós, and Rafael
From Steve : a) for A,B,C is 5, 0, 0 b.) for A,B,C is 6, 0, 0. c) for A,B,C is 5, 1, 0
From Miklós: a) for A,B,C is 0, -10, 0 b.) for A,B,C is 1, -9, 1. c) for A,B,C is 0, -9, 0
From Rafael: a) for A,B,C is 0, -10, 0 b.) for A,B,C is 1, -9, 1. c) for A,B,C is 0, -9, 0
Steve!
Check your solution again please! If you insist and not agree with ours, then let's find out what is the difference.
After that I suggest to move forward what are the drags if we take the non continious case.
I would like to follow it, because we should give a definition that works in case of all the minimal relations (not only in FS case), in case of maximal relations, in case of non-continious and continious case, and in case of volume legs (that is when thee lag is a linear finction of preceeding (or succeeding?) activity duration as well.
After that we can say that this problem is settled down, and move to the next question in connection with that, that in case of multiple critical path how can you found the right combinations of activities.... back to this when the above mentioned are solved. Steve now it's your turn!
Miklós
Miklos,
Sorry for looking without reading your post, I was kind of disturbed by the fact we have been asking for long for PP Admin solve the issue on post numbering, just to be as a few years ago. In addition I was blindly focused on answering Steve about the issue on continuous versus non-continuous PDM.
About your sample job my results using Spider Project agree 100% with you as you can see from the following figure.
Best regards,
Rafael
MIKLOS' COMMENT #9
Rafael, Steve
I can't beleive how this site works....
I've sent a comment (CALLED: MIKLOS' COMMENT #8) almost five hours ago, now I have your comment form 2 minutes ago, and you say:
"Sorry but I do not know which schedule you are referring to, the way PP numbers the posts is confusing me."
Well, it's in comment #8.
I have a lot of comments on non-cont. and cont PDM, Projack handles both, but I won't tell anymore until we do not clarify the drag in this case and do not come to a mutual agreement about the results.
But let's keep the topic in its track:
Rafael, please read my comment #8, and you will found the sample task there, with my and Steve's solution as well.
I have bad feelings that while the definition is common, the algorithms we use are not the same.
I'm pretty sure that mine is the good one, biut let's discuss it, after we convinced EACH OTHER ABOUT THE RESULTS
Miklós
Steve,
Non continuous PDM is wrong:
First, because of economical reasons. In a particular job with thousands of activities perhaps there will be one such activity on the critical path per every 100 not in the critical path. Splitting by brute force the remaining 99 is not economical, does not make sense when there is available float as a buffer, a waste of money and resources. No matter how powerful your computer is, good scheduling still requires the inputs of a good planner, not of a typing machine jockey.
Second, because blind splitting will induce errors with regard to split activities costs and duration. As we all know a split activity is not as efficient as a continuous one, even when spanning several days, is is not merely a learning curve issue as it might be zero in some cases. At times for new split, a new cost and a new duration shall be estimated in a way the sum of the splits is grater than the original activity. More frequently than not it is not the best strategy to split it in half, it might be better alternative for first split to be larger than the second split as to get more reserve float on the maximum duration before the split. these are decisions that must be evaluated on a one by one basis as there are no shortcuts here, blind splitting of an activity is the lazy scheduler option, is the option not of a true manager but of a managed.
If DRAG does not fit the continuous model then it is no good, that is new to me. Guess I will have to discard the functionality and perhaps it shall be taken out of Spider as to avoid any misleading. Maybe under continuous PDM it is good only to warn about reverse CP, then all we need is the warning and no misleading value.
Miklos,
Sorry but I do not know which schedule you are referring to, the way PP numbers the posts is confusing me.
Best regards,
Rafael
MIKLÓS' COMMENT #8
Guys,
So far we have a definition as it follows from Steve:
"It is the amount of time than a task is adding to the project duration or, alternatively, the amount of time by which a project's completion date could be accelerated if an activity's work could be accomplished in zero time."
We have a sample project from Miklos (t's me) as follows:
A (10days), B (10 days), C (10 days) relatations are SS5, FF5 from A to B, and SS5, FF5 from B to C,
and the questions
We have solutions from Steve, Miklós,
From Steve : a) for A,B,C is 5, 0, 0 b.) for A,B,C is 6, 0, 0. c) for A,B,C is 5, 1, 0
From Miklós: a) for A,B,C is 0, -10, 0 b.) for A,B,C is 1, -9, 1. c) for A,B,C is 0, -9, 0
From Rafael: still waiting
Steve! I think result can be checked in a simple way. Just put this sample into any software, and then change an activity duration to 0 day, and check the change of the project duration:
I did this with projack, and MS project (in this last case I had to use dummy activities 'cause it is not allowed the use of two relationship between the same two activities)
So I did it, in case a) and changed the duration of A from 10 to 0. Nothing has happened with the project duration. So according to the accepted definition the drag is zero, and not 5.
I did this with B and the projeck duration has changed from 20 to 30, so the drag is -10 and not zero
Comment these please!
Miklós
Hi, Mohd.
I'm not sure what exmple/network you are referring to. But if Activity1 is on the critical path, and it is delayed, then yes, I would expect project completion to be delayed.
Fraternally in project management,
Steve the Bajan
Mohd,
You are using negative float because of some finish constraint, look for information on negative float at other threads if you need to understand it.
If you want to follow us suggest eliminating all finish constraints existing either at the individual activity level or at the project completion date (leave it open or empty).
Regards,
Rafael
PS. I give up in trying to identify my posts with a permanent reference number, from now on all will be "guess".
Hi rafael and all,
Just correct me if my concept is wrong
Activity1 is critical activity with total float as -45 project completion is on scheduled date.
This means Any further delay in Activity1 will cause the project completion date to be slipped off.
please reply
Volume lag is related to volume of work while time lag is related to a fixed duration.
Duration of volume lag is defined by the volume lag required and the resources productivity. Therefore if resources are increased the duration of volume lag is decreased accordingly. This is specially useful on software capable of assigning different productivity to different resources assigned to a single activity.
If activity B is linked by a SS relationship with a time lag of five days, no matter how well A performs the lag will always be 5 days.
If A and B are related by a volume lag of say 10 LM and the combined resources productivity is 2 LM per day the duration of the volume lag will be 5 days. But if you change resources productivity because of automatic shift assignments or by assigning more resources it will vary. Say you duplicate all resources and remaining volume of work is the same then volume lag duration will be 2.5 days.
Volume lag by default is defined by predecessor activity but by using double links it can be on successor or on both.
Note that automatic shift assignment cannot be done by most software, in most you will have to model shift work using different activities and then manually reassign work assignments but this is another issue that would require a separate thread of its own.
Rafael Post 06
Hi, again. Miklos. I realized I didn't answer this question:
"The only technological relation between A and B and B and C that 50meters safety distance should be kept between activities in order to avoid that workers on B will get a punch from a Caterpillar working on earthwork."
Makes perfect sense. However much time it will take to get that 50meters safety distance, that time will be the drag of A, as shortening it up will shorten the project duration by letting B start sooner.
"This fifty meters is one day. If the work will be shorter it will be six hour, or less, but there is no meaning to tell the workers that come at 2 pm., because now the safety distance is big enough."
That's a separate issue. And if the cost of not shortening the project is great enough (i.e., the drag cost of A), we will tell those workers to start work as soon as the gap is large enough, even if they start work at 2pm, because the cost of delay is greater.
"So we use time lag wich is one day, instead of volume lag."
Time lag or volume lag, use whatever you like. But the issue is how long will it take to get the work in the first part of A done. Thus the drag is based on the work in A, and the software should be pointing the scheduler to optimize the work in the first part of A to get that 50metres of safety, as a way to get the project finished faster.
Fraternally in project management,
Steve the Bajan
MIKLOS' COMMENT #7
Steve, Rafael,
This is why I do not like to make conversion in this way, because we react for some points and do not react for others which would be more important at the other end of the net.
So I try to be as simple as straightforward as I can
1) It seems that we use the same definition for drag what do you use. (I was a bit confused at the beginning, because we teach it in connections with criticality (on BSc) and in connection with time-cost trade offs (on MSc) but I never found this english term before.
2) I want the drags from all of you for the following sample
A (10days), B (10 days), C (10 days) relatations are SS5, FF5 from A to B, and SS5, FF5 from B to C,
3) I want the drags from all of you if B is 9 days
4) I want the drags from all of you if B is 11 days.
(I have these drags from Steve, but please chek or modify if you want)
5) I maintain my drags
these are
5) After that if we agree in drags we can continue with the other questions. But please concentrate on this first.
last info: my project duration is 20 days when B is 10, and 21 days in to other two cases.
very last info to Rafael: the date is 2011-07-05 11:21 instead of yours 2011-07-05 01:34, it sems that there's no help in identifying our comments :))
Miklós
Rafael Davila wrote:
"My definition for DRAG (Devaux’s Removed Activity Gauge) is Stephen Deveaux definition."
I'm honored, Rafael, but it's possibly a dangerous path to take. I do think the term "Removed Activity Gauge" has value in terms of describing exactly what drag is: a measurement of the impact of removing an activity's duration. But actually I have for some time now just been describing it as "critical path drag", all lowercase. Anyone, but especially engineers, understands the concept of drag in English as being the stuff that slows you down. I have an article scheduled to be published in the Jan/Feb 2012 edition of Defense AT&L magazine of the Defense Acquisition University that is called "The Drag Efficient", once again referencing the aerospace engineering concept (as in: the drag coefficient).
Under any circumstances, since I didn't invent drag (it's there, on every critical path, whether or not one computes it!), but simply published a book that (among many other things) shows how to compute and manage it, it's probably better that it just be lowercase (despite the efforts of one lawyer to get me to patent the computation process, which I rejected -- I want people to USE it!).
Fraternally in project management,
Steve the Bajan
To continue:
The reverse criticality issue is a very interesting one. It is problematic even without the issue of drag computaton -- I wonder how many planners, on PP and elsewhere, are even aware of it? I wonder how many urgent projects (hospital construction? Flood levee construction?) are being delayed by weeks and months just because of the Continuous Activity issue and the lack of awareness of it? And of course, as shown in the example at bottom of this post, it also makes schedule optimization more difficult by making drag computation problematic.
Rafael writes:
"(A)ny continuous activity can be split when needed."
I'm not sure that's true -- I actually think it's only about 99.8943% of activities that can be split when needed (which does round up to 100%, so we're still in agreement, Rafael!). Now, Rafael also says:
"The trap is on automating the split, convenient but wrong, good software design shall avoid such traps."
I completely agree that the software needs to make crystal clear to the user what it is doing. Rafael and I agree that, if Spider Project uses the Continuous Activity algorithm, it should also use the negative drag computation to point out to the user that the project duration is probably being (unnecessarily) extended because of the continuous activity algorithm. I think all PM software should probably offer the user the alternative of whether to use continuous or non-continuous. (By the way, the Sumatra add-on to MS Project offers the option to correct the MSP algorithm by inputting milestones -- and yes, "correct" is the right term, as MSP has other limitations that would make computing drag impossible otherwise.)
My philosophy is this: the software is a tool that is designed to help the scheduler. Whatever is going to help the scheduler generateh a more "profitable" schedule for the project investment is what the software should provide. There are two possible algorithms based on separate assumptions:
1. The Continuous Activity algorithm will keep the activity duration as input at the downside of (1) computing an incorrect (99.8943% of the time!) Early Start date of activities with FF or SF predecessors, (2) providing inaccurate drag computation (often on several activities -- an example lower down), and (3) frequently causing project schedules that are longer than they need to be.
2. The Non-continuous Activity algorithm will allow the duration to be "elastic" (as occurs anyway when we allow activity splitting in resource leveling), while (1) computing the CORRECT (99.8943% of the time!) Early Start date of activities with FF or SF predecessors, (2) providing ACCURATE drag computation on all activities (thus providing more help to the scheduler looking to shorten the schedule) and (3) computing project schedules that are as short as they can be.
Again, I believe with Rafael that the software should inform the user and let him/her decide. But IF there is only one choice for the design of a tool, I believe it should be the one that will most often be of greatest aid to the tool user. And in this case, that's not the Coninuous Activity algorithm, which Rafael points out the user would always want to "correct" by splitting the activity if the user understood that it was making the project longer.
The Continuous Activity rule was chosen (I believe in the old K&H PDM algorithm that most s/w still uses) because it was much easier to program it one way or the other back in the Sixties, and they chose the Continuous Activity way. They would NOT have done it that way if they understood the importance of computing drag. Here is a reverse critical path algorithm where, not only will the software give a longer duration than necessary, but it will also give incorrect drag and float amounts for several activities and even show the wrong critical path!
A Dur: 5D; No Pred
B Dur: 10D; Pred: A/FS
C Dur: 5D; Preds: A/FS, B/FF
D Dur: 10D; Pred: C/SS
E Dur: 5D; Preds: B/FS, D/FS
Of course, if one followed Mike Testro's advice and modeled the schedule using ONLY FS relationships and milestones (and BTW, it wouldn't have to be Activity On Arrow, just Activity on Node with just FS relationships), one would get the shorter schedule. This is one reason I have sympathy with avoiding PDM relationships (though I worry that, for many projects, the planners will not do sufficient activity decomposition and will wind up with a longer schedule anyway). I'd like to be able to use PDM, but get the better (non-continuous, and correct drag computation) answers!
Fraternally in project management,
Steve the Bajan
Miklos,
My answer is on the following previous post, which might show different time depending on your time zone. This is an issue Mike Testro and many others have called to the attention to PP Admin but we are still waiting for a response to get back the numbering of post as it was years ago, until then we will have to play "guess" by using the minutes of the hours displayed. I edited my posts to be numbered in sequential order at the ent of the post, using this as a reference my answer is on Rafael Post 01.
.................................................................................
Can you tell me what time it is displaying on your screen, 01:34 or different hour same minutes? What about the date, a day before? Maybe at that hour I was on a different day than you.
My definition for DRAG (Devaux’s Removed Activity Gauge) is Stephen Deveaux definition.
http://www.planningplanet.com/wiki/422733/critical-path-drag
Best Regards,
Rafael
Rafael Post 05
So many good points raised by both Miklos and Rafael, but my wife wants me to go kayaking with her in half an hour...
Miklos, I certainly will take any opportunity I evr get to visit Hungary. And while meeting Mr. Polgar would be an attraction, meeting you and chatting would be even more so!
First, my definition of critical path drag:
It is the amount of time than a task is adding to the project duration or, alternatively, the amount of time by which a project's completion date could be accelerated if an activity's work could be accomplished in zero time.
I would also like to add here that perhaps an even more important concept is drag cost: this is the amount (of money or human lives lost!) by which the return on a project investment is reduced due to an activity's drag extending project completion. This may be due to reduced expected value of the project and/or to increased cost (direct, indirect or opportunity costs). This amount may be very different for the contractor than for the customer, and this difference can and does cause moral hazard unless the contract is carefully drawn to quantify and track the cost/value of time in a way that appropriately aligns and incentivizes both sides of the principal-agent relationship.
Miklos wrote:
"How this will work when volume lags are used, instead of time lags. (I think volume lag is the right term if the lag depends on the predecessor or successor (usually as a linear function of one of them)"
Someone please tell me of other packages than Spider Project that include volume or work lags -- I think it's an excellent idea, but all of the other (many!) packages I've ever seen simply use SS (and SF) time lags to model what are really volume lags. In the case of a volume lag, it seems clear to me: an SS+5 with a volume lag will have 5 days of work (and drag, if on the CP) in the predecessor before we achieve that intended volume. If we can achieve the volume in three days of the predecessor, the lag should become three days and the drag of the predecessor should be automatically lowered to three days. A time lag (which most s/w packages usually intend for modeling FS or FF lags) is like a separate activity and should have its own dragindependent of the predecessor activity.
Oops, interrupt to go kayaking. More later...
Fraternally in project management,
Steve the Bajan
MIKLOS' COMMENT #6
Rafael,
I'm absolutely agree with you.
Now please give a definition for drag and the result for the sample project as well, just to settle down this drag question.
See sample at 07-03 15:37 and 07:03 16:57
Miklós
MIKLOS' COMMENT #5
Steve,
There is a chance that my English is better than your Hungarian, but despite of this I still do not feel it perfect.
I'm really happy that you like chess The father of the Polgar girls just bought a house hundred meters away from ours, so we meet regularly at the baker in the morning. Last time he sad to me, that what he did with his three girls was just an experiment to increase their creativity, and the results of the girls were just kind of byproducts of this experiment. He also sad, that if he had a new chance he would start with a game which is similar to the chess (unfortunately I do not remember for the name of it) because it will have the same result within a fraction time of what he needed with chess.
So back to the original question, I still need an exact definition to make sure that we have the same understanding, so let's continue when you come back, or have more time. Or you can visit me in Hungary at the university, if you have time.
Your thoughts give me a new aspect, so let me add a new question to to last three:
Anyway this reverse criticality very often arise in construction. Just look at your pipe laying project that you have mentioned.
No, just look this example:
You have a pipe laying project consist of three activities A erthwork (10 days), B pipa laying (8 days), then burying (10 days) A and C will be accomplished by your staff, and your machines, trucks, etc.
The only technological relation between A and B and B and C that 50meters safety distance should be kept between activities in order to avoid that workers on B will get a punch from a Caterpillar working on earthwork. This fifty meters is one day. If the work will be shorter it will be six hour, or less, but there is no meaning to tell the workers that come at 2 pm., because now the safety distance is big enough. So we use time lag wich is one day, instead of volume lag
B will be carried out by your subcontractor and they need eight days for that. Now suppose that a new subcontractor comes to the town and tells that he will finish the pipe-laying within 4 days and he asks for the same amount of money. What do you say in this case?
You say that thanks I do not want this, because your for days faster work on B will result a four days delay in the project duration. Check this with any software.
So this kind of anomalous behavior arise in every infrastructural project (road, pipe, train etc.)
This was only an example for reverse criticality, just to show you that they are frequantly arise in construction industry
Back to your original calculation given in the topic starter. I understand your calculation when you have only FS relation, this is practically nothing else as a CPM (activity on arrow) network, and in this case it works. But here in pecedence diagramming when SS,FF,SF are also allowed, the situation is more complex, and we cannot say that our definition and algorithm are valid only for the FS-relation case.
Definition that work in CPM (activity on arrow) sometimes are not valid without changes in precedence diagramming so we have to be very carefull when we apply them or adjust them to PDM.
Finally you are right I feel almost impossible to come to a solutiuon with this kind of communication, this would be hundred times more efficient at the both side of the same table (and in the same time:))
Miklós
There are several reasons to avoid the use of the traditional Activity on Arrow computations and the Non-Continuous PDM (its PDM equivalent).
The advantage of non-continuous PDM over continuous PDM is a fallacy, any continuous activity can be split when needed. The trap is on automating the split, convenient but wrong, good software design shall avoid such traps.
Like Activity on Arrow, non-continuous PDM provides the dates for the nodes and not the activity, therefore it assumes the activity to be discontinuous with one end driven by the first node and the last end driven by the last node. In the majority of scheduling need the most efficient scheduling of an activity is for it to be continuous. The method denies the scheduler for the use of Continuous scheduling while by merely splitting the activity the Continuous method do allows for the proper application of the splits.
If you need for an activity to be discontinuous this assumption should not be automated as the splitting rule must be determined on a per activity basis, and then there is no benefit on the automation of a rule that must be on a case by case. Also the difference in durations between the parts of a split activity and a continuous activity must be taken into consideration. In addition the splits do have a particular duration of their own, early start and early finish of their own, float of their own which can be different after resource leveling. Because the software summarizes this under a single activity line some of this information is hidden to the user.
The float computations for Continuous PDM as well as the float computations for Non-continuous PDM will vary and DRAG will vary accordingly. One split might fall on the CP and thus will have DRAG (non-zero) while the other or other splits will not.
Rafael Post 04
Hi, Miklos. Fascinating discussion! First, let me reassure you as to how much better your English is than my Hungarian! (I gather you are Hungarian -- Lajos Portisch was one of my favorite chess grandmasters! Also Pal Benko, and now Judit Polgar.)
Unfortunately, this method of communication is quite inadequate -- a face-to-face conversation would be much more efficient. (I am one of the world's worst and slowest typists!) I think I understand the basis for your position and different (from mine) computations. We may have to agree to disagree, but I'd like to explain why I feel my answers are the most useful ones to a planner.
A few philosophical points to explain where I am coming from:
I think that much of the disagreement between us on our drag calculation comes, as you say, from definition, particularly around two things: lag and continuous activities. In both cases, I want the software to represent what the likely nature of the work is. We don't know for sure, but I want it to reflect how the user will be using it in > 99% of the cases rather than in the other < 1%.
First, lag: it is almost always used to represent either work that can be accomplished faster or slower, or a period of time that can be shortened or expanded (albeit with an increase of risk). An exception is Spider Project, the only software I know of (there may be others?) that has the capacity to handle both types of lag separately. In a case like Spider:
Time lag should be a fixed amount, I think (1D for cement to dry); work lag should be "elastic": get the work done faster and the lag amount should decrease, thus decreasing the drag. The latter is the way that lags are used far more than 99% of the time outside of the construction industry (I leave you to tell me what the percentage is in construction). And when time lags are intended, it is almost always following an FS or FF relationship (Paint First Coat -> FS+1D -> Paint Second Coat). In such cases, the lag represents time that is NEITHER in the predecessor NOR in the successor, but between. As such, an FS or FF lag is just like an activity and, if it is on the CP, should have it's own drag amount.
On the other hand, an SS (or SF) lag amount is almost always used to represent the completion of a certain amount of work in the predecessor, and a subdeliverable or handoff that has been accomplished. In pure FS terms, the predecessor would be decomposed to two tasks: (A) Construct First 50% of Fence -> (B) Paint Fence AND (A') Construct Last 50% of Fence. Accomplishing the work to that handoff faster is what will shorten the project, because the handoff will occur after four days of lag instead of five. And so, if we reduce the duration of Construct First 50% of Fence from 5 days to four days, if we are modeling the relationship using SS+lag, the lag amount should automatically be reduced to four days.
Let's take your example, and assume that the activities are:
A. DIG 100m. OF TRENCH
B. LAY 100m. OF PIPE
C. BURY 100m. OF PIPE
In this case, the ONLY CHANGE we can make to ONE (and ONLY ONE) activity that will pull in the end of the project is to get the first 50m. of trench dug faster. Dig those 50m. in four days instead of 5 and the lag will become 4D and the project will become 19D instead of 20D. Otherwise, becaue of the parallel critical paths the rest of the way, any shortening of one path will also require a shortening 0f the other path to pull in the project duration. Thus I'd like drag-computation software to point the scheduler to the fact that s/he can pull in the schedule by eliminating some of the drag in the first five days of Activity A (by getting the work done faster).
My wife and I are currently on vacation, and if I keep working on this, she'll kill me. So I'm afraid I must stop now and come back to the rest of our discussion later this week, Miklos. I hape the way I approach this makes sense to you, even if you disagree.
Fraternally in project management,
Steve the Bajan
MIKLOS' COMMENT #4
Steve, Rafael
Do not read this until you have read my previous mail.
If you have read my previous post carefully, then my next questions will be:
So this definietly requires some further research.
Let me explain elastic activities.
Imagine thre activities A,B, C with 10, 5, and 10 says durations. Relations from A to B are SS5, FF5, from B to C are SS5 and FF5 as well. Now the question is if elastic activities are allowed what would be the time of for example B if we want to achieve the shortest project duration. It is important that elastic activities can only be lengthened, so crashing is not allowed.
(This is an interesting feauture because it gonna define a new (greater) activity times for those activities where this results shorter project duration. You can read about this in a couple of books on scheduling, but it is still not part of the general project management practice.)
In this case the newly defined activity time will be ten days, because this will result in the shortest (20 days) project duration. Now it is your decision how to adjust arrange it, less resource, machines with lower capacity, or simply say work half an hour then have a half an hour rest, or simply do not care about this option.
But let's go step by step and deal first with my previous mail. What is the starting definition and what are the results.
Last note: time cost trade off will find the cost optimal combinations for shortenings in case of multiple critical paths.
Miklós
MIKLOS' COMMENT #3
Steve,
My answers are not the same as yours (In Hungary we use different metric terms for critical activities at least two so we have to check it wether we speak about the same thing or not))
Here I'll just concentrate on activities, and suppose that you use the same definition for drags.
It differs from yours so we have to go back to the definitionjs
So please give me your definition for drag time. My verbal definition is the following: a drag time shows how much the length of a critical activity or the length of a lag time of a critical relationships adds to the project duration comparing - and this is important - if their duration would be zero, and nothing else changes at the same time . (My English is not perfect but reading it again it seems correct to me.) (That's why I love to give mathematical formulas instead of verbal definitions:))
When you give your definition do not forget the "compared to" part, because I think this is where the secret is hidden
So... accurate mathematical definition is important. :)
Some minor differences: we never say that a critical activity hasn't got a drag. We say it is zero. It is important because according to our definition a negative drag can also exist. A negative drag means that a one day decrement in activity duration would increase the project duration by one day. The - 9 days means that the project duration will increase by 9 days if you decrease the activity duration to zero day.
So negatíve drags arise for example iin case of reverse critical activities. This could be more accurate if you discuss drag in connection of time cost trade offs, or in connection of critical path characteristics. For example when B is 9 days it has a -9 day drag.
So... accurate mathematical definition is important. :))
Here in Hungary some professors argue that when B is 9 days, than drag for B will be -1 day, and when B is 11 days, than the drag for B is +1 day. They say that drag should be defined in the following way: a drag time shows how much the length of a critical activity or the length of a lag time of a critical relationships adds to the project duration comparing - and this is important - to their duration where project duration would be the shortest, and nothing else changes at the same time.
Acording to this definition
So accurate mathematical definition is very important. :))))))))
Let's start with checking the project durationj
For example when B is 10 days that is the project duration is 20 days, change the duration of activity A to 1 or 0 day, and see what happens with the project duration. (As its critical characteristic is decreasing neutral increasing normal the lenght of the critical path won't change.) So why do you say that it has 5 days drag?
First let's start checking with project durations.
If these project durations are not the same, than the problems can originate from here. (I hope that you have the same project durations)
Miklós
Hi, Miklos! Yes, I can understand that the difference in numbering could throw you off. As you say: "The difference is basically nothing" -- the results would be the same. But still, it's what one is used to.
As to your problem:
My answers:
1. If B is 10D, A has drag of 5D and nothing else has drag (parallel critical paths).
2. If B is 9D, A has drag of 6D, FF5 relationship from A to B has drag of 1D, and FF5 relationship from B to C has drag of 1D. Nothing else has drag.
3. If B is 11D, A has drag of 5D, B has drag of 1D, and FF5 relationship from B to C has drag of 1D. Nothing else has drag.
Are those the same answers you would have?
I'll post the answers to the diagram problem when I have a few minutes tomorrow, so other folks can see how easy it is to compute drag in a simple, all FS, network.
Fraternally in project management,
Steve the Bajan
MIKLOS' COMMENT #2
Steve
To continue my last post (see below) and what will be the drag time if the duration of B is 9 days?
And what will be the drag time if the duration is 11 days?
I've got a software that can handle time cost trade off in the case of:
I have a generalized algorithm for this (no software, but published) when:
I also have huge case studies: the last one was published by the Australian Institute of project Management at the last IPMA word congress. (Was it in 2006?) If you are interested I can look for that.
(There are algorithmss that can handle resource limits during time cost trade off , so even the resource oriented planners like Rafael would be also satisfied with them (but as I know they are goog for small projects only because of the required time of the calculation)
The reason that we did not finished the generalized algorithm, that we found that a vast majority of project managers even haven't heard about the problem, so we keep it as our application and sometimes we make huge money on consulting a larger infrastructural project.
Miklós
MIKLOS' COMMENT #1
Steve,
It's a nice little ridle. As a prof. of construction management I felt myself challanged - although I found out years ago, that my students beat me in network analysis at the end of the course :)) - so I tried to calculate it manually but I gave up after three minutes. (As I'm getting older and older day by day this is the maximum time I can concentrate on the same topic :))
However there are some interesting things I want to mention here:
1) We teach a different calculation rules (yours is a calendar like, ours are based in integer numbers). This latter means that: let's say an activity starts on day 0. If its duration is 10 days than it will finish on day 10. If there is a FS0 to the successor than the successor will start on day 10.
So our rule is: forward calculation starts at 0. ES+t=EF. In case of a successor FS z (z is the lag time) the early start of the successor is EF of the predecessor +z.
Your rule (working calendar like rule). Calculation starts at 1. ES+t-1=EF In case of a successor FS z the early start of the successor is EF of the predecessor +z+1.
The difference is basically nothing - we tell our students that leave the calendarization to the software- , but it was enough to confuse me that's why I left it after 3 minutes.
About the drag times:
We teach drag time in connection with
A last question for being sure that we understand drag time at the same way
We have A,B,C all of them 10 days. From A to B we have a SS5, and a FF5, From B to C we have a SS5 and a FF5. Question what is the drag time of B?
Miklós
Hi, Mike.
"I used to do these problems at College back in 1962 but I can't be bothered to do it all over again.
I am with Rafael on this - leave me with the software please."
We're all three in complete agreement! Only trouble is, neither Primavera nor Asta (nor any other s/w package I know of except for Spider Project and the Sumatra add-on to MS Project) computes critical path drag.
And that means that either schedulers who aren't using those two packages need to learn how to compute it "manually" or they aren't doing their scheduling properly. I think you'll agree that it's important to know which critical path activities are costing you the most time and money! And the little sample network above is about as simple as it gets: just 18 activities and all FS relationships -- if someone can't figure it out there, they are in lots of trouble on large, complex networks!
Fraternally in project management,
Steve the Bajan
Raphael, wow! What great discussion! Let me try to respond to each of your key points:
"As you can see I do not believe in crashing a network with a single click of the mouse"
We are in violent agreement! That is one of the key things that drag (and drag cost!) computation adds: a metric that guides the scheduler to the right decision for crashing, rather than some "expert system algorithm" that's as likely to be the wrong decision much of the time!
"Then in another field you can toggle on and off the activities for which time/cost can be applied. In this way by looking at my critical path I can toggle off those activities I do not want to crash,"
Yes! Crashing some activities, even if the payoff is substantially reduced project duration, might result in unacceptably increased risk!
"I believe in the absence of a defined cost curve the software as default can compute the slope as:
etc.
where each pair of values is grouped by a comma and within each pair the slash will separate the two values, similar to the data entry I use on a software called Pizer Earth for earthwork calculations..." I am sure you can improve on this initial idea if you believe it makes sense, won't be surprised if you already have."
I'm not sure I can improve on it, as it all sounds very interesting, and a good approach in many cases. But I also agree with your statement: "I believe this simplified procedure or algorithm will not always yield optimum results, perhaps only if all curves are staight lines with a negative slope." Each situation can be very different. One technique that I have used, and describe in my Total Project Control book, is the development of a second duration estimate for each task: the Doubled Resource Estimate of Duration, or DRED. This is an estimate of the resource elasticity of an activity's duration: how long would the activity take if it had twice the resources? If an activity's normal estimate is 20D, possi ble DREDs would be:
a. 10D (perfectly resource elastic, a rather rare situation especially poutside the construction projects).
b. 12D (somewhat more common, in my experience).
c. 17D (some duration benefit, but often must be purchased at great cost. Often worth it on big drag tasks, though).
d. 20D (not at all resource elastic).
e. 30D (increasing resources causes inefficiencies, such as working on the avionics in the cockpit of an F16).
Again, the DRED is not a perfect tool and is only designed as an aid to the scheduler, but it can help.
"Whether to crash a network or not shall be an option of the resource leveling and performed after the schedule is leveled"
This is a case where I'm not completely in agreement. My reason is, optimizing a schedule (whether by crashing or fasttracking) BEFORE leveling can have two very beneficial impacts:
1. By pulling the schedule earlier, many resource bottlenecks that delay the schedule when leveling actually disappear! For example, I don't have a hobbit available when I need him on a task in June. This will be a bottleneck that will force that task out to July when I level. But if I first optimize, so that the task is pulled in to May, now there is no bottlenecked hobbit and my schedule is accelerated by up to two months!
2. Resource leveling, when compared to the "pure" CPM schedule, has the ability to isolate the delay cost of specific resource shortages. By showing that a delay is being caused exclusively by a lack of a specific resource on a specific task at a specific time, and then measuring the cost of that delay, we justify the additional cost through what the TPC method refers to as the Cost of Leveling with Unresolved Bottlenecks, or the CLUB. I have used that many times on consulting engagements to show the customer that the cost of an additional hobbit will be paid back many times over by avoiding the delay such an insufficiency would cause.
"I believe crashing is of last resort but you will need it when the logic and resources cannot be changed anymore, then at the worst moment you need it, better having some computer assistance than none."
Again, a slightly difference in philosophy. I believe that the value/cost of project time is the great externality of project management. It is almost always worth a huge amount to have a shorter duration -- to not just avoid finishing "late", but to finish early! Most customers would love this, yet contracts are rarely being written to provide the contractor (or subcontractor on the CP!) with adequate incentive for early delivery. This causes the much-written-of principal-agent problem, which in turn leads to moral hazard and all the law suits, instead of the win-win situation where both customer and contractor are driven by shared incentives. This, to me, is one of the great failings in the practice of project management.
"Those who have never run the basic CPM computations such as early and late dates, total float and finish float shall at least do it for a couple of times. I learned to do it using the diagrams as you show but with the values empty. This shall be also done with lag values as well as with SS, SF and FF relationships as the rules vary for continuous versus non-continuous PDM. It is good for practice exercise to have the answer but in order for others calculate DRAG some of your advice shall be welcomed"
Yes, I absolutely feel that this is something that a professional scheduler MUST be able to do. And if their software doesn't do it (and I guess we agree that it should!), then they must be able to do it "manually".
"I am considering the modeling of these costs using separate hammocks that must be defined in a way they are always on a Critical Path. In Spider Project we can cost load linear variable costs with hammocks, yes it got to be proved with a model that works and my desire to have these metrics embedded into the software is to make it easier to get into such a discussion to see how far we can get."
This also sounds very interesting.
"If a day savings by crashing costs more than a day of LDs go for the LDs, this all contractors know. What not everyone knows is that not necessarily payment for LDs limits the Owner to claim for damages for the delay. Better finish on time if you know the delay is going to cost much more than the LDs, better start crashing your schedule."
Even better , finish early! Optimize the project schedule, bid a shorter schedule with nice incentives for early delivery, and you' can retire when you're still young! (Unlike me!)
Fraternally in project management,
Steve the Bajan
Hi Rafael
Once you have extracted the resource hours from the cost plan / BOQ and allocated them to the baseline tasks you have closed the bid triangle of scope>cost>time.
Entering actual resource deployment will show the trend of actual v tendered resource allocation.
Projection of such trends on future work will indicate future performance.
If acceleration is deemed beneficial then there are two methods available.
1. Cost free = change of logic
2. Costly = Change of resources
You can only change resources if you have allocated resource hours into the baseline programme when you can consider increasing gang size or working overtime on any particular task.
The effect of any change is immediate on the completion date only if the baseline is constructed properly with sound bottom up planning priciples.
Best regards
Mike Testro
Mike,
Guess you got a point, perhaps using costs can yield the lowest cost option for a deterministic schedule but for a probabilistic schedule not necessarily will yield the expected lowest cost option, nor the best strategy. That is why I was suggesting toggling off from crashing late critical activities, to have some reserve to crash in the future if the strategy does not works on early crashed activities.
It might be that the probability of success of crashing two activities is not the same, but how would you suggest solving the issue if on a probabilistic analysis where other non critical events might influence the expected duration probability distribution?
I believe in the value of probabilistic schedule but seems like at home no one else believe in the use of probabilities distribution taken from the air. For some (or many) it is just because they do not understand probabilities for others it is they don't believe in the value of rough probability estimates for tend forecast. How would you estimate the probability distribution, using some function of resource hours, activity duration, a guess? For me this is getting kind of difficult, seems like I belong to the first group.
I prefer procedures real management will use, procedures that will not necessarily give you the mathematical optimal solution but a good one can be enough. Better than having no strategy for crashing, mere brute force crashing at any point in the schedule is not good.
Best regards,
Rafael
Rafael Post 03
Hi Stephen
I used to do these problems at College back in 1962 but I can't be bothered to do it all over again.
I am with Rafael on this - leave me with the software please.
Best regards
Mike Testro
Hi Rafael
I believe that resource hours is a better measurement than costs at task level 4.
Costs can be applied to the summary bars at a calculated daily rate.
You can then run both slopes in Line format against Planned.
Best regards
Mike Testro
Steve,
About the activity cost slope f(time,cost)
I believe in the absence of a defined cost curve the software as default can compute the slope as:
default slope = total activity cost / activity duration
If the user inputs the cost curve on a single muli-values field then the slope can be determined from the actual duration and the cost curve:
slope = dc/dt f(time,cost)
and the curve definition can be a set of sequential values ordered in time values such as;
time1/cost1, time2/cost2, .... timeN/costN
where each pair of values is grouped by a comma and within each pair the slash will separate the two values, similar to the data entry I use on a software called Pizer Earth for earthwork calculations. Then in another field you can toggle on and off the activities for which time/cost can be applied. In this way by looking at my critical path I can toggle off those activities I do not want to crash, like for example late activities as to make the crash to happen on early activities.
Then the real issue will be when by crashing your network there begin to emerge other parallel critical paths where the slope shall be defined on the sum of the cost of several critical activities occurring at the same time.
Whether to crash a network or not shall be an option of the resource leveling and performed after the schedule is leveled under the assumption crashing creates no increase in resource demand. If not it might be necessary to manually adjust resource supply/demand and run a few "what-if" scenarios until it satisfies real needs.
I believe this simplified procedure or algorithm will not always yield optimum results, perhaps only if all curves are staight lines with a negative slope it will.
As you can see I do not believe in crashing a network with a single click of the mouse because of the changing resource requirements but by following a sequence of steps where you toggle on and off which activities are to be crashed you can get a workable approach. This will give us some control on the crashing of the network and will even make it easier to program as a secondary benefit.
I believe crashing is of last resort but you will need it when the logic and resources cannot be changed anymore, then at the worst moment you need it, better having some computer assistance than none.
I am sure you can improve on this initial idea if you believe it makes sense, won't be surprised if you already have.
Those who have never run the basic CPM computations such as early and late dates, total float and finish float shall at least do it for a couple of times. I learned to do it using the diagrams as you show but with the values empty. This shall be also done with lag values as well as with SS, SF and FF relationships as the rules vary for continuous versus non-continuous PDM. It is good for practice exercise to have the answer but in order for others calculate DRAG some of your advice shall be welcomed, although the procedure can be found on the internet some might not find it.
About the four contributors I have not forgot, the debate is still pending but I want to try some models with my ideas on how to model the issues. I am considering the modeling of these costs using separate hammocks that must be defined in a way they are always on a Critical Path. In Spider Project we can cost load linear variable costs with hammocks, yes it got to be proved with a model that works and my desire to have these metrics embedded into the software is to make it easier to get into such a discussion to see how far we can get.
If a day savings by crashing costs more than a day of LDs go for the LDs, this all contractors know. What not everyone knows is that not necessarily payment for LDs limits the Owner to claim for damages for the delay. Better finish on time if you know the delay is going to cost much more than the LDs, better start crashing your schedule.
Best regards,
Rafael
Rafael Post 02
Hi, Rafael. Maybe you should have put "spoiler" on your reply, so anyone else who wanted to could have done it manually? :-)
Earlier, you said you'd find it a lot easier to do it in the software than manually. Actually, with a simple network like this,I suspect it's quicker to figure it out manually than to go to the trouble of entering all the activities and relationships into the software. (I'll post the answers, along with how to do the computations manually, in a few days.)
However, if one has the whole project network already entered, or if it's a large/complex network, then it's undoubtedly MUCH easier to use the software -- provided you have either Spider Project or the Sumatra MS Project add-on. So that leads to the question: why doesn't all the other software -- Primavera, Asta, etc. -- do this calculation? Does someone think that it's not important for a scheduler to know how much time each critical path activity is adding to the project? Isn't that crucial (critical?) information to know:
Two weeks ago, I was teaching a class in Chicago to a group of very experienced PMs with a large engineering firm. When I showed them how the drag analysis highlighted and called their attention to the stuff that was costing them the most time, they immediately saw how it would help them optimize their schedules.
You also wrote: "By the way maybe activity cost slope shall be a predefined field, better than using formulas. It is a useful metrics and in combination with DRAG even more."
I'd actually be very interested to hear more about this. The corollary concept, drag cost, is the amount of money by which a CP activity is reducing "expected project profit" through its drag. I have identified about four contributors to this, but am eager to hear about more:
Its sounds as though your thought about the activity cost slope is related to this latter. Again, I'd love to hear more about this. Have you thought of publishing an article on it? (You also write very well.)
Fraternally in project management,
Steve the Bajan
By the way maybe activity cost slope shall be a predefined field, better than using formulas. It is a useful metrics and in combination with DRAG even more.
Rafael Post 01
Email: PPadmin@planningplanet.com
Replies