(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.
I've just seen the draft of the release notes on our next release of Asta Powerproject (version 14.0.02, due out in October). It includes this paragraph:
You can now calculate the drag of critical tasks when rescheduling. Critical path drag (Devaux's Removed Activity Gauge) can be thought of as:
To calculate the drag of critical tasks when rescheduling, select the Critical path drag check box, on either the Reschedule tab of the Options dialog or the Reschedule dialog:
You can display the drag of critical tasks in the spreadsheet, using a new Critical path drag field. Drag is also displayed in a new field on the Task tab of the Bar and Task Properties dialog and on the corresponding tab of the properties view. Tasks can also be filtered according to the amount of critical path drag.
I haven't seen the feature in person yet so my ability to answer further questions is limited to the text above! I'm sure once released we will be able to run webinar sessions demonstration the principle.
Ben @ Asta Powerproject
Printer-friendly version
Send to friend
Stephen,
I have now read, mostly read, both of your books. I admit that there were sections I skipped over because I felt I knew the material well enough to focus on the main topics of the books.
Let me see if I can recap some of the main points.
1. Every project has a value,
2. The PM should manage the value of the project,
3. Delivering the project fast will increase the value of the project,
4. Activities with the largest DRAG should be looked at first,
5. There is a DRAG Cost associated with each of the critical path activities,
6. DIPP should be used to determine if a project should be continued.
7. You don’t believe in Monte Carlo simulation.
These are the main topics with some sub topics.
So, the reason why I am addressing this with you is two-fold. Firstly I am about to embark on a doctorate program in Portfolio and Project Management and secondly I wanted to answer your question on the original post, “Why is DRAG not in the PMBOK?”
So, based on my readings of your books I have formulated a reply to your original question looking at the entirety of your work; books and articles.
I will address each topic I listed above in roughly sequential order.
1. Every project has value. I would say yes with a ‘but’. But some are done, as you point out, because we have to. They still have value, but it is not measurable only the negative consequences of not doing a thing is relevant. Also, the long term value of a project may be incalculable. Like you say, the schedule is just an estimate. The long term value is also just an estimate and therefore the value of delivering a project a day or two or event weeks or months early, or late, is just an estimate. I worked for Shell Oil early in my career building deep-water oil platforms. The platforms had a 30 year life. With discoveries of addition reservoirs and new technologies in oil recovery in addition to large fluctuations in oil prices, there would be no way to calculate the value of the project
2. Should the PM manage the ‘Value’ of a project?
Should the PM manage to a project value that is incalculable or irrelevant? Everything we do in life has some value even if just perceived by the person doing the thing. There is value in me driving to work each day. Is there more or less value in arriving a minute early or a minute late? Maybe, but probably not, and it is almost impossible to measure.
Also managing the any difference in delivery date from the planned date is in the realm of Risk Management. Late is the cause of risks becoming issues and early is risks becoming opportunities. So at a project level the PM should manage risks, i.e. conduct good Risk Management.
So, I would say the PM should not manage to the value of the project because 1. That should be the just of the portfolio management team, 2. It is nebulous, 3. If it could be done, how much time should a PM spend on it?
3. Delivering the project fast will increase the value of the project.
In some instances yes. In some no. In some a few days here or there won’t matter to the long-term goals of the project. It just matters what the project is going to deliver. The examples you have given in your books are more operational than project and because they are more frequent the risk is low and faster means getting the service back producing cash as fast as possible. The military and disaster relief examples are where faster means better but even those are operational.
But in a true project where you are producing new and different products and services, faster means a lack of control and increased risk due to poorly planned deliverables, bad decisions and stressed workforce. True engineering and design projects are like digging a trench or building a brick wall where extra resources don’t make it go faster.
4. Activities with the largest DRAG should be looked at first.
I feel that DRAG is a good number to know. Should it be looked at first when trying to compress a schedule? I say no. If I am trying to compress a schedule, I look at the tasks on the critical path or near critical path that are the longest. Why, because those are the tasks that were planned the worst. You mention in your books that a task should be around 80 hours in effort. If one task is much more than that in effort or the duration is more than say about 3 weeks, the task should be analyzed to determine if it was correctly decomposed from the WBS and can be decomposed more or if the skill set required or the person assigned needs to be revised.
Once that work is done, the DRAG duration should be small in comparison to the total durations of the tasks. But, it is a useful number and when used in conjunction with other schedule metrics, can prove to be useful.
5. There is a DRAG Cost associated with each of the critical path activities.
DRAG cost is a fictitious number. As I explained in posts, the units don’t cancel. Therefore DRAG Cost in dollars, cannot exist. If the project is late and there is a penalty, then the penalty is in units of dollars per day late. If the project is early then the benefit is in dollars per day early. The units of DRAG are, in your own words, amount to time (days) and activity is adding to the duration of the project. So, DRAG has nothing to do with late or early. It is the incremental duration added to the schedule as compared to its parallel tasks. It goes into determining the total duration and the planned delivery date of the project, but is not related to delivering earlier or later than the planned date. So, the units cannot be canceled and DRAG cost cannot be calculated, and therefore it cannot detract from the project’s value.
In calculating the benefit of shorting a task to the project, the calculation you provided, example in Figure 5.10 of Managing Projects as Investments, you calculate the “Improved True Cost.” In the first line of the table you calculate ITC as $10,000 by subtracting DTC from ITC. This calculation uses an addition of the ‘DRAG COST’ to get ITC and DTC. By adding DRAG Cost you are artificiality inflating numbers. More simply put, I have to spend $20,000 to save $30,000 therefore I have a $10,000 improvement. No need to add the artificial number to get to the same conclusion.
6. DIPP should be used to determine if a project should be continued.
This is an easy one. DIPP is a ratio. Ratios are good for looks back, not looks forward. A simple NPV cash flow analysis done in excel or even MS Project we provide a better picture of current state and ‘what-ifs’ of changes in the cost, time or future cash flow of the project. And, if you want to do a ratio, you can always ration current NPV over baseline NPV.
7. You don’t believe in Monte Carlo simulation.
This one puzzles me. An estimate is an estimate, period. There is a ZERO percent chance of getting an estimate correct if it is a point estimate. A range of estimate covers unforeseen issues which delay and efficiency issues of individuals doing the work. I always ask for a three point estimate to cover point estimation errors.
You dispelled the use of Monte Carlo simulation by just calling it voodoo and saying it is not scientific, yet you can include risk and changing critical paths to get a better estimate of schedule and cost and a much better idea of both management and risk reserve needs. It makes management aware of the probability of completing on time and on budget so that better portfolio decisions can be made. It seems like you dismissed it as being inconsequential to the field of scheduling. For someone trying to have new concepts come to the forefront of project management, dismissing this out of hand is disingenuous.
Overall, you have some minor areas of improvement to the field, but overall, it seems like you are attempting to create something out of nothing.
Chris
Chris,
I agree that DRAG is one more useful indicator like different kind of floats. Floats show what happens with the project schedule if an activity is delayed, Drag shows what happens if an activity is shortened. When considering project crashing DRAGs show where to look first.
There is another useful indicator that we call Flex but only Spider Project calculates it, so if you are interested we can discuss it in Spider Project forum on this site.
In our practice the end value is automatically calculated by Spider Project with each project update and when risk simulation is used probability to meet target values is calculated too. Project management decisions are justified by their impact on end value and probability to meet project targets. And top management requires regular reports on expected end values and trends of probability to meet project targets, so project managers cannot miss this. This is not just a theory, this is everyday practice in many companies.
The problem that I meet most frequently is that people manage project cost but do not manage actual expenses. Project schedules include the cost (what will be paid for the job) but not expenses that reflect the real costs of project resources, indirect costs, etc. Actually most people manage their contracts but not expenses, future profits, etc. Good and educated top managers would require this but there is a shortage of wise top managers. If some top managers will read Steve's books maybe they will start to require taking current decisions basing on their impact on overall project and company goals.
If you are interested how "time is money" is modeled in Spider Project start this topic in Spider Project forum.
This is Asta discussion and maybe Ben will tell us how Asta does it.
Best Regards,
Vladimir
Valdimir,
I am not sure, nor does anyone explain, how to manage a project using 'time is money.' Day to day decisions, management and control is not done with the end value in mind, nor should it be. As I stated, the end value cannot be accutatly calculated. In some minor cases thinking of a project in terms of profit might be useful and accpeted. In most cases not.
Steve writes his books like it is a foregone conclusion that ever PM has missed since the begining of PM when he addresses no real case studies and even cannot disprove my assertion that Drag cost cannot be calculated in the manner he prescribes.
Therefore, I cannot buy into his concept. Yes, no one, excpet a few apps, calculates DRAG. While I do think it is a useful number to know, I do believe that it is not useful by its self when looking to shorten the duration of a project. I see this as more of an addition the CPM practice and a than a whole new concept.
I have communicated this to Steve a number of times and it has fallen on deaf ears. He canot be shown the holes in his theory.
Chris
Done.
Rafael, thank you for your proposal but let's discuss Spider features in Spider Project forum.
Vladimir,
I am missing DRAG on the Calculated Data Tab, I believe it shall also be there as it is a very convenient view, frequently better than looking on a table with many columns. I believe it would be very convenient to disclose on the same line, next to DRAG value the calendar used.
Best Regards
Rafael
Chris,
I want to start my response with the basic concept that we use in our projects:
Project manager shall be able to select the best management decision basing on project success criterion that shall be known at the very beginning. This criterion may change during the process of project execution but it shall be defined at any moment of time.
Using triple (and more dimensional) constraint makes decision making complicated and subjective. One example of criteria integration is defining the cost (or other value) of time. Cost of time estimate may be subjective, not accurate, but it shall be defined and used when different options are compared. In my previous post I suggested some approaches for cost of time estimating just as examples. And yes, the customer may use a set of other criteria that in any case shall be integrated in one that can answer to the question if one way of project development is preferable if to compare with another. With integrated criterion project managers are able to justify their management decisions. Even inaccurate estimates set the rules and may may be improved or reconsidered later. Setting the rules shall be made by stakeholders and in some projects time may be of essence, in others not though it is hard to me to imagine such projects.
I know that PMI standards shall include only those methods and tools that are used in most of the projects most of the times though there are many things that are included but still rarely used or used different ways. AACEI and Planning Planet selected different approach and develop Recommended Practices (AACEI) or advanced sections (PP). I prefer an approach that helps to implement new methods and tools instead of repeating outdated methods in modern projects.
Practitioners may understand and accept only those methods that are available to them. There are many useful methods and tools developed and used in Russia but not known in the USA unless these people attended the conferences where these methods were discussed or used Russian software Spider Project where these methods are implemented. To accept any method people shall first of all become informed on its existence.
My post was not about drag cost (Steve may explain it better than me) but about overall concept that “time is money” and that all project parameters have their weights if to estimate project success and these weights shall be defined and known by decision makers even if their estimates are not as accurate as they could be.
Best Regards,
Vladimir
Vladimir,
My response.
“And thus it is usual that the projects are late and over budget just because initial schedule did not allow for project constraints (resource, supply, funding) and did not take into account risks and uncertainty.”
I agree with this statement 100%. The average PM does not know how to develop a basic schedule.
"So I do not accept your statement that if some methods and tools are not used by “average” project managers they should not be included in PM standards.”
If a method cannot be understood and is not adopted by practitioners, why should it be included? If it cannot be understood and used, what is the benefit of having it in a standard? Isn’t a standard just that, a standard accepted method of doing something?
“It is not hard to calculate the cost of contractor one day idle time and use it as the time cost for decisions like if it is profitable to add resources for finishing earlier.”
Let us not use idle time as a substitute for the discussion of Drag, late projects or lost value. A project may have idle time and finish early. Using expensive resources to finish early when there is no monetary value seems counterproductive, especially to the budget. There may be times when it is appropriate to use expensive projects to deliver early or even deliver on time, but that is part of Risk Management; exploiting opportunities.
“If the owner invests in construction of some object that will bring profit (a shop for example) he estimated future profit. In other case he would not invest. So some estimate of owner future profit (though approximate) is known at the project start and can be used for setting the cost of the day for future management decisions.
These estimates shall not be very accurate but they shall exist.”
Yes, every project has some value, monetary or otherwise. Can you accurately estimate the value per day or per week? How do you estimate with any degree of certainty the profit that can be obtained building a building that will last 50 years? I would never go to my boss with the statement, “well it’s an estimate, but it isn’t very accurate.” Sounds like a Dilbert cartoon to me. Don’t projects fail because of inaccurate estimates of time and resources?
“The performance is estimated by achieved total cost – successful project may be late but saved more money than the cost of delay or being over budget but finished earlier so that the acceleration savings exceed additional expenses.”
Doesn’t it, in the end, matter only what is important to the stakeholders?
“Once again – today's “average” project managers use project management techniques developed in 60-s mostly because top management is poorly educated and does not know what to require.”
I agree 110%
I would agree with Steve, and do on the calculation of DRAG. But, the other concepts he has proposed, DRAG cost, DIPP, etc. are either wrong or can be more accurately calculated with other methods. DIPP is a ratio that changes over the life of the project. A simple inflation adjusted NPV Cash Flow analysis produces more reliable number and more useful. To develop a ratio, the current NPV can be divided by the planned NPV to produce a performance ratio that should be close to 1 for the entire project.
DRAG itself is only a numerical calculation of a single characteristic of a task. Yes, it seems that through project management history it was never calculated. But, for it to be useful, may other attributes of a task must be known. Can it focus a team on those tasks that should be looked at first when attempting to shorten a schedule? Maybe.
So, with that maybe, we have written pages and pages either for or against the concept, putting it in application, making up additional concepts; resource loaded DRAG or something of the sort, but in the end, are the tools we have now not sufficient? Or, as you pointed out, the average PM doesn’t know how to use the tools we already have. Yet, we are trying to fix a problem by heaping on another scheduling concept. Feels like a government program used to fix a government program that isn’t working. Let’s teach PMs the basics first and see how that works.
Chris
darn duplicate!
Vladimir,
As always THANK YOU.
Best Regards,
Rafael
Rafael,
thank you for an example.
At the moment Spider calculates drags for resource constrained schedules but we still did not add material and financing constrained schedules. There are obvious errors in your example. In particular zero duration delivery activities should not have drags. I will discuss this with our team.
Chris,
I like discussions and criticism.
Do you have any specific arguments against cost of time concept that I described in my post addressed to you?
Regards,
Vladimir
Vladimir,
As I mentioned before a schedule that does not meet resource constraints is unfeasible, but Renewable Resources are not the only resources we must consider everyday. Consumable Resources, Spatial Resources, and Financial Resources must also be considered as we all know.
I am having problems to understand in the following sample schedule what the DRAG value on the Delivery Activities mean, I hope you can enlighten me.
Best Regards,
Rafael
Steve,
I understand about thinking differently and do agree that the state of Project Management needs to be improved. I have reviewed both your books. I have looked at them with a critical eye. I am engineer, MBA in Finance, MS in Project Management and have been practicing for nearly 20 years. I provided you my view of where your theory fails. You refuse to address even the most basic of my criticisms. You continue to dance around the criticisms leveled at your concept with obtuse comments.
If you refuse to address comments, that to either means you cannot defend your concept or you feel you are correct and everyone who levels a criticism just does not see the genius in the concept. You continuously write lengthy replies that don’t get to the heart of anyone’s comments.
I would be impressed if you proved me wrong about the calculation of DRAG cost. Can you do that? If you want to be taken seriously by the majority of PMs you must address the analyses. Don’t put out a question on these forums and expect everyone to fall in line. Defend your position with direct rebuttal.
Chris
Steve,
Spider Project calculates the amount of extra value/profit that a given decision might generate.
I'll be glad to discuss these problems off-line or in Spider Project forum. This is Asta discussion and we all wanted to congratulate Asta with the new achievement.
Best Regards,
Vladimir
Chris, I give up.
You keep talking about the way things are. I think everyone here understands how things are currently done. But as one of Vladimir's posts suggested, the way that things are currently done is very bad. Don't accept my word for it--check out PMI's Pulse of the Profession which shows, over many years, no improvement in an approximately 63% rate of what it judges to be "project success". A grade of D is, in most, fields, pretty bad.
I understand that thinking about projects as investments, and then planning, optimizing, performing and evaluating results on the basis of value-above-cost is a new way to think about things that requires a few new metrics and techniques. And I now understand that you are not interested in doing things differently. We must agree to disagree.
Fraternally in project management,
Steve the Bajan
Vladimir wrote:
Steve, the task that you suggested is very complex and requires full network analysis. Drag value may be caused by calendar of activity scheduled several months later and resource requirements that occur much later. It is easy to analyze the drag of concrete activity but analyzing all of them could be very time consuming.
As I just posted, Vladimir, I am comfortable with the way you are doing this.
Spider Project simulates the cost of time and we always recommend to model it, but acceleration cost is more complex because there are many ways activity duration may be made shorter. It may be achieved by using more resources, by replacing resources, by using different technology, by changing activity and/or resource calendars, etc. Cost of time is common but cost of acceleration is different for each activity and depends on the choice of the selected acceleration way. Selection may depend on resource availability, space constraints, existence of alternative resources and technologies, etc.
Vladimir, I'd be delighted to discuss this with you off-line. I think there are simple ways to do this, allowing computation of both drag cost and true cost, as well as net increase in profit. I don't know if you'd have the interest--but I suspect that the PM folks in your target market would appreciate having the s/w provide a report on the amount of extra value/profit that a given decision might generate.
Tom, I know your system doesn't compute drag cost, but I would be happy to share with you also. And Ben, of course, the same, although this initial step for Powerproject to compute drag is itself a huge leap.
Fraternally in project management,
Steve D.
Rafael, thanks. This makes total sense and I am comfortable with it!
As a vastly experienced and knowledgable scheduler who has now had access to s/w with drag for a while, I'd be curious to know how much you find yourself using it.
Fraternally in project management,
Steve the Bajan
I am flat out with personal and work issues. But there is a BUNCH of stuff in this thread that I really want to address. (And other stuff--not so much.) But as much as this all deals with complicated issues, I need to be brief (unlike with my other looong post of yesterday!).
I am IMMENSELY grateful to all who have developed software that computes critical path drag. Notwithstanding anyone who either doesn't (or won't) understand the concept of projects as investments and the impact of time on investments, to measure and bringing attention to the amount of time that each CP item adds to the project duration is a big step in critical path theory!
I recognize that there is a big difference between recognizing/computing something mentally and designing a computer algorithm to compute it. That's why someone like Magnus Carlsen can still occasionally win chess games against Deep Blue, even though the computer can rapidly analyze to many, many more levels than the human. The human can still, sometimes, see and utilize strategic concepts and judgement that is beyond Deep Blue.
The practical workaround that Spider uses makes perfect sense for a computer. For me, it is easy to distinguish work from calendar and say that it would be helpful if the s/w could differentiate a delay being caused by a calendar or resource availability from that being caused by work. But this step is small compared to the huge step of just computing drag and assigning it to an "object" (activity) and letting the scheduler determine exactly what aspect of the activity is causing the delay.
So, in short, I am QUITE comfortable with the way that Spider does its computations. In fact, I am delighted! One should never let the perfect be the enemy of the much improved!
Fraternally in project management,
Steve the Bajan
Vladimir,
Thanks for that clarification (about 4 posts back).
Vladimir and Chris, thanks for the thoughtful exchange. These last two posts are worth saving....
Chris,
we always suggest to estimate and to use the cost of time in project management. Yes, estimates may be very rough but without these estimates project management decisions like if it makes sense to hire more expensive subcontractor that will finish the work earlier cannot be justified.
You wrote that “The average PM does his/her own scheduling and therefore will not have time to manage project schedules with abstract and difficult concepts. How many PM’s doing their own scheduling will even use EV metrics that have been around for 60 years?” I agree with you that existing project management culture is poor and most schedulers do not even level resources though resource constraints always exist in any project. And thus it is usual that the projects are late and over budget just because initial schedule did not allow for project constraints (resource, supply, funding) and did not take into account risks and uncertainty. So I do not accept your statement that if some methods and tools are not used by “average” project managers they should not be included in PM standards.
Cost of the time is different for the owner and contractors.
In construction projects each day of contractor's work costs money even if nothing was done. People get some salary, construction site maintenance costs money, construction equipment like tower cranes is usually paid for time on site, etc. It is not hard to calculate the cost of contractor one day idle time and use it as the time cost for decisions like if it is profitable to add resources for finishing earlier.
If the owner invests in construction of some object that will bring profit (a shop for example) he estimated future profit. In other case he would not invest. So some estimate of owner future profit (though approximate) is known at the project start and can be used for setting the cost of the day for future management decisions.
These estimates shall not be very accurate but they shall exist.
The usual requirement to finish project on time and on budget does not supply project managers with the tools for justified management decisions. We suggest to set target budget, target date and the costs of acceleration and delays in respect to target date. The performance is estimated by achieved total cost – successful project may be late but saved more money than the cost of delay or being over budget but finished earlier so that the acceleration savings exceed additional expenses.
We used this approach for last 20 years in many projects and many companies with very good results.
Once again – today's “average” project managers use project management techniques developed in 60-s mostly because top management is poorly educated and does not know what to require. Earned Value is promoted but adds very little to informed and justified decision making, other methods that may add a lot are not promoted because “average” project managers do not use them. This way leads to project management stagnation. If you will compare functional capabilities of today's popular software tools (OPV, MSP) with the tools of early 90-s (Artemis, Open Plan, Cresta, P3) you may notice that the progress does not exist. Most people use the same Critical Path Method developed in late 50-s, do not level resources, do not properly manage project budgets, do not use advanced methods and tools developed later.
I agree that total float is a great tool! It is a pity that most project management software packages (like MSP and OPV) calculate wrong total floats in resource constrained schedules. And so in most projects the users of these packages cannot rely on total float values calculated by their tools.
Tom,
Your reply is what amazes me about this whole concept; something so simple has to be explained in so many words that it becomes overly complicated. Steve’s original question on LinkedIn was, “Why is DRAG not in the PMBOK?” The simple answer is in the pages of this blog. Yes, DRAG can be calculated. Great. Is it useful? Possibly. Is it useful to the average PM? No. Steve’s premise is that DRAG leads to a DRAG cost. I read both his books and what I gleaned is that every project has value and the critical path is preventing the project from obtaining that value.
Well, I have managed or been on $100k projects to $1B projects and have never once been asked if I can pull in the schedule by one day or one week what is the value. Projects are never estimated and approved with the caveat of a certain value predicated on a singular delivery date. The possibility of delivering a project on the exact planned date is zero. Project sponsors know this. That is why they will never say my value decreases if I deliver a project one day late. I worked for Shell Oil early in my career building deep water oil production platforms. They delivered billions of dollars of value. It would be impossible and ridiculous to attempt to calculate the value of the project of the 30 year life of the platform. Who’s to say delivering it 30 days late won’t increase the value due to fluctuating oil prices?
Steve’s example of the nuclear power plant is interesting, but, it isn’t a project. If I am doing a refueling or outage every year to two years, it isn’t a project. While there might be value getting the plant running on time or early, it is not a project. It might have a schedule, but it is not a project.
On to DRAG cost. Steve explains DRAG cost as the cost of delivering a project later than the due date. While this might be the case in a limited number of projects, the average project manager does not deal with this on a daily basis. Few companies enter into project delivery for end customers that contain stiff late delivery penalties. If it is a true project, the delivery date is either set with a wide margin, or padded so as not to be missed.
Or, DRAG cost is the cost of missed value of delivering early. See my Shell example above. The value of any real project, if it can be calculated, can be controlled by so many variables it will produce numbers with accuracies that would be highly questionable. I would not want to be the PM to bring questionable value numbers to the CIO asking for money to accelerate a schedule. Can the value even be calculated? While all projects have some value to someone, can they actually be calculated and can the early delivery by even a day be calculated? I delivered a project that allowed the CEO to be tracked on his morning run so security would know his position. He had been running without it for months. He saw a shiny object and wanted it. It had value to him. What was the value if we delivered it one day earlier? Who knows. Could it be calculated? Would the CEO pay to have it accelerated?
So, if I have a project to is 60 days in duration, and the critical path tasks have 2 days DRAG a piece as in Tom’s example schedule, what is the cost of delivering it a 60 days? Is there lost value? Unknown. Is there a penalty for delivering it exactly when we said it would be delivered? Most likely not. But in Steve’s theory, there is DRAG cost. If delivering one day late costs $10,000, then every task with DRAG of 2 days has a $20,000 DRAG cost associated with it.
Now you say, how can a task have a $20,000 DRAG cost when the project is delivered on time, or even one day late? I have also pointed out to Steve that on a basic level the math does not work. You cannot cross multiply DRAG days by Cost/Date late. A DRAG day is just, as Steve points out, the number of days a task’s duration can be reduced by before it falls off the critical path. This is basic 8th grade math. The units do not cancel so a nonsensical number is produced. On another level, if I don’t deliver a project late, is there a cost to my project? If a project is delivered on time and it doesn’t cost me a dime of my budget, is there a DRAG cost? Costs hit my budget, period. Lost value is almost impossible for the average PM to identify much less calculate.
So, why is DRAG, DRAG cost, DRED, etc. not in the PMBOK? I will tell you. The concept is, in no particular order, abstract beyond the pure calculation of DRAG, difficult to apply, difficult to calculate and somewhat unnecessary to the average PM. The average PM does his/her own scheduling and therefore will not have time to manage project schedules with abstract and difficult concepts. How many PM’s doing their own scheduling will even use EV metrics that have been around for 60 years? If I have a billion dollar project with schedulers and a WBS with thousands of tasks, I might try to employ the technique to plan and control the schedule. For the rest of us, this is just an unproven theory that can’t be sold to management.
That is why it is not in the PMBOK.
I agree with Valdimir 100%.. DRAG might give you a place to look, but does not tell you anything beyond the number of days before a task falls off the critical path. It does not tell you can a task be reduced, the cost of a reduction, how many days it can be reduced, if other resources, strategies or technology can be used. It tells you nothing beyond the number of days reduction before a task can fall of the critical path.
While it is a number that can be calculated, like total float, its usefulness is limited.
Vladimir,
Showing the predecessors as you did, all tasks are on the critical path … the only reason they have float is because you fixed a start date or you fixed Lag…because if non-critical path tasks can have drag, then Steve’s definition goes out the window. Just because you can get a tool to calculate some number, does not mean it meets a definition and therefore is not useful. We can calculate whole bunches of things and get an answer. It does not mean that answer is useful.
Chris
Resource leveled DRAG is equally important as any schedule that does not meet resource constraints is not feasible.
Unleveled Schedule 01 - no links amongh the activities - resource A availability 1 - activity resource loading quantity as per Quantity column.
Leveled Schedule 01 - no links among the activities - resource A availability 1- activity resource loading quantity as per Quantity column.
Leveled Schedule 02 - activilties witn logic links - not a single activity with DRAG - resource A availability 5 - activity resource loading quantity as per Quantity column.
Tom,
if to increase the durations of activities 1 and 2 to two days they will have zero drag and only activity 3 will have 1 day drag.
I think that restricting drag value is artificial and removing this restriction is right.
[Posting after Rafael's but without the benefit of reviewing its contents. I may revisit tomorrow.]
Vladimir,
Thanks very much for the clarification. It is so simple that I am embarrassed for asking.
I was thrown by a couple details that I failed to fully understand/address earlier:
Finally, I'd be very curious to see the results of your same example after increasing the durations of the first two tasks from one to two days....
Thanks for your patience.
Steve,
I created the following two versions of Vladimir schedule but using calendar days to determine project duration using a hammock as well as calendar days to determine DRAG. It all makes sense, take for example Activity 2 if its duration is set to 0 then the schedule duration is reduced from 11 to 4 calendar days yielding a reduction of 7 calendar days, a DRAG of 7 calendar days. This tell us that if we reduce the duration of Activity 2 to 0 we can compress the schedule by 7 calendar days.
Rafael
Steve, the task that you suggested is very complex and requires full network analysis. Drag value may be caused by calendar of activity scheduled several months later and resource requirements that occur much later. It is easy to analyze the drag of concrete activity but analyzing all of them could be very time consuming.
Spider Project simulates the cost of time and we always recommend to model it, but acceleration cost is more complex because there are many ways activity duration may be made shorter. It may be achieved by using more resources, by replacing resources, by using different technology, by changing activity and/or resource calendars, etc. Cost of time is common but cost of acceleration is different for each activity and depends on the choice of the selected acceleration way. Selection may depend on resource availability, space constraints, existence of alternative resources and technologies, etc.
DRAGs show where to look but the final decision shall be made using what if analysis.
Vladimir wrote: "...because activity drag may depend on many factors that may add their portions to the total drag."
I agree, Vladimir. But it would be nice, wouldn't it, if the software pointed the user to the specific factor causing the drag? The purpose, after all, of drag is to allow the user to see exactly what is causing the delay.
Please don't get me wrong--what Spider is already doing is a HUGE step forward. And the sophisticated user (Rafael?) should have little trouble seeing the specific aspect of the activity--calendar, logical constraint, resource insufficiency--that is causing the delay. But it's if the specificity is greater.
Maybe something to think about for a distant future release?
Of course, I'd say that an even more valuable feature would be a flexible (i.e., different premiums/cost per different unit earlier/later) drag cost (and true cost) calculator. One day late may cost $500K, but another week beyond might only be another $50K. But perhaps Spider already has this?
Fraternally in project management,
Steve the Bajan
Tom,
in my example activity DRAGs show what happens with the project duration if activity duration will become zero.
For first two activities project duration will become 5 days shorter, third activity may shorten project duration for 1 day.
What is wrong with this?
Spider Project calculates activity drags taking into account activity calendars, resource and other constraints. But it is still an activity property. Activity DRAG may depend on other activity calendars and resource requirements but I would not call it calendar drag or resource drag because calendars and resources themselves do not have drags and because activity drag may depend on many factors that may add their portions to the total drag.
Vladimir,
Could you please explain what is meant by the three instances of DRAG in your figure. Although very interesting for examining the impacts of variable calendars in a schedule, they seem inconsistent with the definition of drag that Steve has been pretty consistently espousing over the years. I wonder if the same word is being used for two very different concepts.
Please take no offense from the image below. It's an amusing line from a favorite film.
Hi, Vladimir. Just to clarify:
I think what you are saying is that it is not just critical path ACTIVITIES that can have drag? That other items, if they are on the critical path, can also have drag?
I agree. And as I wrote in my loooong post:
Critical path drag is the amount of time that any item—activity, calendar, logical constraint, resource bottleneck, rework, dropped baton—adds to the critical path.
In your example, it's the calendar, or resource availability, that has the drag. And ideally, the software should point the user to this fact. May I presume that Spider does this?
Fraternally in project management,
Steve the Bajan
I want to add an example of the project that consists of only three activities.
This example shows that DRAG can belong not only to critical activities.
In this example activities 1 and 2 have 5 days work week but activity 3 can be done only on Mondays.
Activities 1 and 2 have 4 days total float but 5 days drag.
So I would not associate drag entirely with critical activities.
Damn, Tom! That's a great post! It took you three paragraphs plus one graphic to capture what took me six pages!
Fraternally in project management,
Steve the Bajan
My Dad used to say: “It never rains but it pours.” I have a very important target date this week to deliver the material for a new course for a major aerospace/defense client. Then my son splintered his collarbone on Saturday and is due for surgery on Wednesday. Life causes unexpected schedule slippages, and responding to every point in this discussion would cause more.
The good news is that this discussion is SO good, and so full of comments by luminaries, that it may be better off without me! With drag being computed by Spider Project, InterPlan Systems, the Boyle Project Consulting’s add-on to MS Project, and now Asta Powerproject, I think it’s made it!
Drag has always been there, on every critical path! The obstacle was always the lack of scheduling software to do the computations and also the instantaneous drag updates every time something changes. That obstacle is now disappearing—it’s not as though users are going to decide that they want their s/w to give them less information! And as they get comfortable with it, they will use it more and more, and probably discover uses that I haven’t even thought of!
They will also increasingly discuss drag and its uses when I’m not around to contribute. Just like in this thread. And that’s good!
I will limit myself to some brief comments:
***
Vladimir wrote: I expect that Steve will once more explain what is DRAG.
First, I must say that I prefer the name “critical path drag” to the acronym for Devaux’s Removed Activity Gauge. DRAG can be a trivia question, perhaps on the future TV show So Who Wants to be a Project Manager?
Second, I really can’t provide a much better definition than these two:
Tom: I would suggest a simple analogy: if Total Float represents the amount of time a (non-critical) activity may be extended before it becomes Critical, then Critical Path Drag represents the amount of time a (Critical) activity may be shortened before it becomes non-critical.
Chris: Yes, DRAG is the number of time periods (days, weeks, etc.) before a task falls off the critical path.
I might extend it a little: Critical path drag is the amount of time that any item—activity, calendar, logical constraint, resource bottleneck, rework, dropped baton—adds to the critical path. (And the logical constraint factor particularly relates to the “negative drag” issue: it’s the FF or SF constraint, which has POSITIVE drag, that causes the constrained activity to seem like it has negative drag! But negative drag is like negative time: no real meaning.)
And for anyone tuning in to this thread who is being introduced to the concept for the first time, I think the Wikipedia pages for drag and drag cost do a pretty good job.
***
Dr. Paul wrote: How is this any different than what we in construction have always called "negative float"?
Again, I can add nothing to the answers of Rafael and Vladimir:
Rafael: DRAG and Negative Float are not the same. A milestone activity can have negative float but no DRAG also some non-milestone activities migh have different DRAG values than their Negative Float. Just take a look at activities 1B, 2B, 3B and 4B, they all have the same Negative Float but different DRAG values. Activity 2B have a negative DRAG value of -10 while Activity 4B have a positive DRAG value of 10… Negative Float, DRAG and Start Flex are not equivalent, each give us a different and valuable measures of schedule flexibility.
Vladimir: (Drag) has nothing common with the negative float, total float and is very useful when crashing is considered.
***
Dr. Paul wrote: How is this any different than what we in construction have referred to as "near critical" activities and can be seen by filtering "Activities <5 days Total Float"?
They are similar, perhaps, but different in several key ways.
***
Dr. Paul wrote: (O)nly crash actitivies on the critical path (don't crash non-critical activities) and prioritize which ones to crash based on which one yields the most schedule compression for the least amount of money.
This is a bit complicated, and I think is also related to some of Chris’s issues. First, what others wrote:
Vladimir responded: (Drag) is very useful when crashing is considered.
And Tom responded: While not a panacea, knowing the Drag of every Critical Path activity in advance does help to focus the effort… Even if the crashing limits revealed by Drag seem obvious to the planner/scheduler who is intimately familiar with the details of the project plan (Steve’s note: I’d suggest that such is EXTREMELY rare on a large project, involving many thousands of activities, types of work, and multiple subcontractors!), Drag can also provide valuable information for a supervisor or other reviewer – less familiar with the details – in understanding the critical and near critical paths. Negative Drag, in particular, is useful as an indicator of reverse logic flow in a PDM schedule.
Tom’s statement is right on the money! For example, the “negative drag” can show the scheduler that it’s a specific logical dependency that is causing X amount of drag (and which is why I’d attribute the drag to the dependency). Or in Spider, which now computes resource schedule drag, it can point the scheduler to the resource insufficiency causing X amount of drag!
Dr. Paul, I really can’t put it any better. But I will say one more thing: I do not agree with: “(O)nly crash actitivies on the critical path.” That indeed has been the traditional methodology, and, without drag computation, it seemed to make sense. However, using drag computation to crash schedules (as I have been doing with my clients for years and years), it turns out that in specific cases, crashing OFF the critical path is occasionally HUGELY beneficial—precisely because it increases the drag on the longest (and sometimes second-longest) path that can then be leveraged to greatly reduce the project duration! I am surprised that those who’ve said they’ve read my books would overlook this, as I thought I emphasized it. Perhaps insufficiently, though? However, on pages 146-152 of Total Project Control (2nd edition): A Practitioner’s Guide to Managing Projects as Investments, there is a specific example of compression OFF the critical path so as to increase the drag totals ON it and then to crash/fast track those activities with the drags.
I can say that, over the past quarter century, I have used drag to (fairly effortlessly) compress many, many schedules at large corporations and I usually can count on a 15% to 40% compression with minimal increased cost. And at the start of the process, I usually compress activities MORE than their drag, with the excess becoming float that generates the drag to be addressed on the NEW critical path. Eventually, of course, we reach a point of diminishing returns.
***
Dr. Paul also wrote: Now have you truly invented something "new" or have you simply given a new name to what we (in construction) have always done?
I hear you, Dr. Paul, but that’s not really for me to say, is it? Others here far more knowledgeable than I about construction projects have pointed out that drag is different from negative float. Perhaps unbeknownst to all of us, some Tierra del Fuegans have been using drag to optimize their fish processing schedules for generations. It would not surprise me; the Vikings discovered the “New World” centuries before Columbus, and, with all your time in Indonesia, you are probably aware that Alfred Russel Wallace conceived of evolutionary theory contemporaneously with Charles Darwin.
I have specifically eschewed any sort of patent on drag and its computation, so it’s out in the general domain to be used. And really, while I do flatter myself that I (a) have explored its value and applicability to other aspects of project/process management and (b) formalized some of the rather tricky “rules” for computing it mentally in a network with SS and other complex relationships, the real key is what Spider’s Vladimir Liberzon and Bernard Ertl’s InterPlan Systems and Tom Boyle’s Boyle Project Consulting and now Ben Taunt’s Asta Powerproject have done! They have made it a PRACTICAL and useful tool for compressing project schedules!
And that means that whatever I think, or Dr. Paul thinks, or Chris thinks, or even what Vladimir, Bernard, Tom and Ben think, no longer matters. Because users will decide! And I believe that they will recognize the value of the additional info and rapidly assimilate it into their standard techniques and processes.
And my contribution has been simply to bang this drum for the past 17 years till we’ve reached this point. (And since I believe that good project management helps all mankind in many different ways, I bloody well wish those Tierra del Fuego fishermen had beaten THEIR drums about it a hundred years ago!)
Finally, I don’t consider drag to be anywhere nearly as important as many of the other new concepts, techniques and metrics I have written about in my books! For example, drag cost and true cost (TC = resource costs plus drag cost) are, in my opinion, even more important than drag to schedule compression (though of course you first have to compute drag). The importance of quantifying the value/cost of time on projects, estimating the expected monetary value of the scope, assembling a value breakdown structure (VBS), planning the DIPP and tracking the DIPP Progress Index (DPI), the cost of leveling with unresolved bottlenecks (the CLUB), and the doubled resource estimated duration are all Total Project Control concepts that are of value, some IMO of much greater value than critical path drag.
Drag is just SO obvious, and obviously valuable! How can any experienced project manager think that it’s NOT important to know what each item is that’s adding how much time to the project duration?? And yet, this critical metric has remained ‘hidden” for over half a century! It goes to prove that our discipline is still VERY immature, and there is lots of room for improvement. And hopefully it will encourage professionals to check out my other (again, more valuable!) concepts.
***
Chris writes: While (drag) is marginally useful when reducing schedule duration, it has to be used in conjunction with other metrics or it is not useful.” And Vladimir replies: Of course DRAG shall be used together with other metrics like any other project management tool.
Chris, you say you’ve read my books, but nothing in them would suggest that drag doesn’t need ”to be used in conjunction with other metrics”. I talk extensively about the value/cost of time and drag cost and true cost and the value breakdown structure and the doubled resource estimated duration (DRED) which not only specifically deals with your criticism that drag is not useful “(i)f the task cannot be crashed, or the cost per period is much higher than the other tasks,” but even MEASURES the task’s ability to be crashed (i.e., resource elasticity).
***
Chris wrote: Therefore, the ‘DRAG’ for each activity on the critical path will be small…
First, not necessarily. And second, as mentioned several times, drag is not as important as drag cost. If the cost of an extra HOUR is $100K (like with some nuclear plant shutdowns), or $500K (as with new pharmaceutical development) or 100 human lives (as discussed in my chapter “Time Is a Murderer!” from the Handbook of Emergency Response), then even a quarter hour can be very significant.
***
Finally, Chris wrote: (C)rashing the activies that have the lowest cost/duration reduction will naturally occur first.
No. Again, as Vladimir noted: “Of course DRAG shall be used together with other metrics like any other project management tool.” Cost of resources is certainly one of those tools. But on most project investments (and especially large ones!), the value/cost of time is considerably larger than the cost of the resources that would significantly reduce that time. Thus the more drag an activity has, the greater (usually!) is its drag cost. And the greater its drag cost, the more likely it is that increasing its resource cost will significantly decrease its true cost.
Expenditures must always be judged in terms of the value they buy. On critical paths, they buy the resources to shorten the duration. That varies from project to project, but usually it’s a LOT. And to focus on cost and to ignore the value bought is often to say you’d rather buy a used Yugo than a brand new Rolls Royce. (Which, of course, are sometimes equal value—but not often!)
***
Focusing on the cost of the resources to crash, rather than the reduction in true cost based on drag cost, reminds me of an old story:
Dmitri (this is dedicated to Vladimir!) runs into Fyodor under a streetlamp at midnight. Fyodor is searching all around.
DMITRI: Fyodor, what are you searching for?
FYODOR: I dropped my cars keys.
DMITRI: Where did you drop them?
FYODOR: Next street over.
DMITRI: Well, why are you looking here, then?
FYODOR: Because there’s no streetlamp on that street.
That’s what trying to crash a schedule while focusing only on cost and without drag information (and drag-computing software!) is like.
***
I probably won’t be back for a while. But this discussion really doesn’t need me.
Fraternally in project management,
Steve the Bajan
Chris,
(The following is cribbed from another article by me.) Consider the simple project illustrated in Figure 1. The "Critical Path" (ACFIJ - dark-red bars) is partially flanked by a near-critical path (BEH - hatched red bars) with a relative float (same as total slack here) of 2 days. The overall project duration can be shortened by accelerating critical-path tasks, and most experienced schedulers would be tempted to first consider modifying the two longest critical tasks (C and I). Accelerating either of them by more than two days yields no benefit, however, as the near-critical path then becomes Critical. Drag indicates this limit for each task - not so obvious in complex project schedules - in advance.
Risk-management aside, it is certainly true that, for a lump-sum construction contract anyway, "...crashing the activities that have the lowest cost/duration reduction will naturally occur first," - but only as long as they remain on the critical path. A low drag value indicates that the true acceleration costs may not be as low as hoped (since either the fixed/mobilization costs must be allocated over a much shorter time, or the cost of accelerating parallel tasks must be added). A high drag value, on the other hand, offers assurance that money spent accelerating a particular task will lead to a corresponding project benefit.
In managing detailed project schedules, drag has not been proven to be indispensible, and it is not mainstream. It nevertheless is a distinct metric that can prove useful if computed by the software.
Start Flex activity with a SS successor is a better indicator of reverse logic than DRAG as reverse logic can also happen in non-critical path activities. You can take a look at my prior example where Activity 2 [non-critical] and Activity 2B [critical] exhibit reverse logic. Negative Float, DRAG and Start Flex are not equivalent, each give us a different and valuable measures of schedule flexibility.
Tom, this is where a network diagram should be preferentially used over a Gantt Chart.
“While not a panacea, knowing the Drag of every Critical Path activity in advance does help to focus the effort.”
I have been trying to figure out how it focuses the effort? If a task has 10 days or 'DRAG', what does it mean? If the task cannot be crashed, or the cost per period is much higher than the other tasks? If all things are equal, maybe this is a differentiator, but it is certainly not the first thing you would look at when crashing a schedule. Agree or not?
Happy to clarify. If all my activity estimations are 80 to 120 hours, there will not be any tasks significantly longer than any other task. This will give, depending on predecessors and resource calendars, a critical path with many near critical paths. Therefore, the ‘DRAG’ for each activity on the critical path will be small and probably a normal distribution with a narrow standard deviation. So, the act of focusing on the tasks with the longest DRAG will be irrelevant and crashing the act ivies that have the lowest cost/duration reduction will naturally occur first.
duplicate comment
Dr. Paul,
I would suggest a simple analogy: if Total Float represents the amount of time a (non-critical) activity may be extended before it becomes Critical, then Critical Path Drag represents the amount of time a (Critical) activity may be shortened before it becomes non-critical. (Perhaps some folks might describe that as “negative float,” but TF<0 is a totally different animal.)
This is certainly not a new concept for any experienced project planner, who typically experiences it first-hand when trying to crash a schedule with complex logical paths. I imagine most planners have incrementally shortened a plump CP activity until it yields no further project acceleration as the Critical Path shifts elsewhere. In this case, Drag might be thought of as a relatively useless (after the fact) output of the iterative crashing process. While not a panacea, knowing the Drag of every Critical Path activity in advance does help to focus the effort.
Even if the crashing limits revealed by Drag seem obvious to the planner/scheduler who is intimately familiar with the details of the project plan, Drag can also provide valuable information for a supervisor or other reviewer – less familiar with the details – in understanding the critical and near critical paths. Negative Drag, in particular, is useful as an indicator of reverse logic flow in a PDM schedule. (Steve’s original definition doesn’t seem to allow for negative Drag under any circumstances, but Spider Project and BPC Logic Filter for Microsoft Project both compute it as a mathematical artifact in such cases.)
Chris,
I regret that I have taken much longer to say what you have elegantly put into your first sentence.
Like Vladimir, I’m also a bit mystified by the first sentence of your second paragraph – please re-phrase.
Unfortunately, the introduction of variable calendars, late constraints, and heuristic resource leveling in the dominant PDM scheduling tools (e.g. OPV and MSP) make total float unreliable as an indicator of logical connectedness between and among activities in a schedule. To the extent that such factors are included in a project schedule (as they must be in my opinion), I would be dubious of any conclusions based on “total float of the parallel tasks.” That would include Drag and any related metrics that rely on a total-float-based definition of the Critical Path.
Chris,
starting from this statement: "If all tasks are estimated on the 80 to 120 hour range, it is doubtful if any task would be on the critical path significantly more than any other task" I don't understand you. Please clarify what do you mean and why activity duration matters.
Of course DRAG shall be used together with other metrics like any other project management tool.
Yes, DRAG is the number of time periods (days, weeks, etc.) before a task falls off the critical path. While it is marginally useful when reducing schedule duration, it has to be used in conjunction with other metrics or it is not useful.
If all tasks are estimated on the 80 to 120 hour range, it is doubtful if any task would be on the critical path significantly more than any other task. If one is, which can be determined by the total float of the its parallel tasks, or by DRAG, or even by looking at total duration, it should be broken down into smaller tasks.
Why has someone not thought of this in the past? Because it is not singularly important to being able to compress a schedule.
I expect that Steve will once more explain what is DRAG.
It has nothing common with the negative float, total float and is very useful when crashing is considered.
Dr. Paul,
I agree with you. I have read both of Stephen's books and I am writing a response to the theories proposed in those books. Not being in the construction industry, I was not aware that negative float was used in this manner. Stephen's original question was, "Why is Drag not in the PMBOK?"
I think you comments point out some of the questions that have to be answered before this concept should be considered as main-stream.
Chris
Dr. Paul,
I agree with you. I have read both of Stephen's books and I am writing a response to the theories proposed in those books. Not being in the construction industry, I was not aware that negative float was used in this manner. Stephen's original question was, "Why is Drag not in the PMBOK?"
I think you comments point out some of the questions that have to be answered before this concept should be considered as main-stream.
Chris
DRAG and Negative Float are not the same. A milestone activity can have negative float but no DRAG also some non-milestone activities migh have different DRAG values than their Negative Float. Just take a look at activities 1B, 2B, 3B and 4B, they all have the same Negative Float but different DRAG values. Activity 2B have a negative DRAG value of -10 while Activity 4B have a positive DRAG value of 10.
Congratulations, Stephen but I am still trying to grasp the nuances of what you call "Critical Path Drag"?
[PDG] How is this any different than what we in construction have always called "negative float"?
[PDG] How is this any different than what we in construction have referred to as "near critical" activities and can be seen by filtering "Activities <5 days Total Float"?
[PDG] Again coming from a background in construction the two rules for "crashing" (which is what we call what you describe above) are only crash actitivies on the critical path (don't crash non-critical activities) and prioritize which ones to crash based on which one yields the most schedule compression for the least amount of money.
Now have you truly invented something "new" or have you simply given a new name to what we (in construction) have always done?
Thanks for elaborating......
BR,
Dr. PDG, Jakarta, Indonesia
Congratulations, Stephen but I am still trying to grasp the nuances of what you call "Critical Path Drag"?
[PDG] How is this any different than what we in construction have always called "negative float"?
[PDG] How is this any different than what we in construction have referred to as "near critical" activities and can be seen by filtering "Activities <5 days Total Float"?
[PDG] Again coming from a background in construction the two rules for "crashing" (which is what we call what you describe above) are only crash actitivies on the critical path (don't crash non-critical activities) and prioritize which ones to crash based on which one yields the most schedule compression for the least amount of money.
Now have you truly invented something "new" or have you simply given a new name to what we (in construction) have always done?
Thanks for elaborating......
BR,
Dr. PDG, Jakarta, Indonesia
Ben, this is great news! Thanks so much for posting this!
As Vladimir and Tom suggest, welcome on board! And I too would be interested in how Asta does the computation in the situations that Tom mentions.
Fraternally in project management,
Steve the Bajan
P.S. Thanks also to Mike Testro for any contribution he may have made to this.
Indeed! Welcome on board! That's great news for the profession!
Once the new release is out, I'd be very curious to learn how Asta is calculating Drag in some of the special cases - e.g. reverse logic flow, variable calendars, early constraints....
Email: PPadmin@planningplanet.com
Replies