I don't agree. When there are few limited resources it is possible though hard to do it manually, if there are multiple limited resources in the complex program then only automatic resource levelling is practical. Project planner still have the control applying user defined activity priorities. If project model is correct then everything shall be right. We use resource levelling in most projects and do not loose control.
As I have said in previous disussions I do not like giving control of my programme to computer software to make my decisions.
I have used resource levelling on live programmes where the project only had two road scrapers and 200 hundred roads to repair so random allocation was not a problem - in fact it helped to stop arguments on priority from the area supervisors.
I can imagine the same result on a pipeline where only three automatic welding machines were deployed over 5 sections.
I have also used resource levelling on a disruption claim to show the likely result on completion if ONLY 40 were operatives deployed on a resource modelled programme.
But to try to level multiple resources over a complex 3d programme is to lose control.
Best regards
Mike Testro
Member for
24 years 8 months
Member for24 years9 months
Submitted by Vladimir Liberzon on Mon, 2014-10-27 20:54
basing on your comments: you are not satisfied with Asta resource levelling.
As well as any other software does not sound optimistic - you know that both MSP and P6 create awful resource constrained schedules. It is easy to be better than them as I expect Asta is. But still you are not satisfied.If this is true then I suggest you to try Spider. It is not right to spend a lot of your valuable time on unefficient manual resource levelling.
Regards,
Vladimir
Member for
20 years 7 months
Member for20 years7 months
Submitted by Stephen Devaux on Mon, 2014-10-27 17:41
Ah, but Mike, even if that is true, Asta still doesn't compute critical path drag.
Here is why this is relevant: critical path drag computation greatly assists the scheduler in compressing and optimizing the initial schedule. And that can allow a Spider Project user to resolve. without even realizing it, what would have been bottlenecks and lead to a shorter schedule.
For example, let us assume that a WIDGETER, needed for the one-week activity called WIDGETING, is available only during the first week of every month.
The Asta user does a little CPM schedule optimization limited to traditional CPM metrics and WIDGETING is scheduled for the second week in June. Then resource leveling is performed and WIDGETING slips to the first week in July, when the WIDGETER is available.
The Spider user does CPM schedule optimization which includes critical path drag and is thus easily able to compress the schedule so that WIDGETING is scheduled for two weeks earlier than with Asta, back to the last week in May. Now when resource leveling is performed, WIDGETING still slips to the next availability window -- only now that slippage is only to the first week in June, a month earlier than with Asta.
If WIDGETING is on the critical path, Spider Project's drag computation functionality may have saved a month of duartion and many hundreds of thousands of dollars (if not millions) because its resource leveling algorithm is operating on a drag-optimized schedule. And this is just one example -- how many situations like this are they in a 20,000 activity schedule?
I'm not at all meaning to give you a hard time, Mike. But Vladimir saw the value of drag computation and programmed it into Spider Project five years ago. Despite your nudging them, Asta has yet to act.
They argument in the arcticle that resource levelling is often not the optimal approach for a turnaround schedule and they introduce the concept of critical mass.
Has anyone thoughts, ideas or opinions about this article it's concepts ?
Member for
24 years 8 monthsI don't agree. When there are
I don't agree. When there are few limited resources it is possible though hard to do it manually, if there are multiple limited resources in the complex program then only automatic resource levelling is practical. Project planner still have the control applying user defined activity priorities. If project model is correct then everything shall be right. We use resource levelling in most projects and do not loose control.
Member for
19 years 10 monthsHi VladimirAs I have said in
Hi Vladimir
As I have said in previous disussions I do not like giving control of my programme to computer software to make my decisions.
I have used resource levelling on live programmes where the project only had two road scrapers and 200 hundred roads to repair so random allocation was not a problem - in fact it helped to stop arguments on priority from the area supervisors.
I can imagine the same result on a pipeline where only three automatic welding machines were deployed over 5 sections.
I have also used resource levelling on a disruption claim to show the likely result on completion if ONLY 40 were operatives deployed on a resource modelled programme.
But to try to level multiple resources over a complex 3d programme is to lose control.
Best regards
Mike Testro
Member for
24 years 8 monthsHi Mike,basing on your
Hi Mike,
basing on your comments: you are not satisfied with Asta resource levelling.
As well as any other software does not sound optimistic - you know that both MSP and P6 create awful resource constrained schedules. It is easy to be better than them as I expect Asta is. But still you are not satisfied. If this is true then I suggest you to try Spider. It is not right to spend a lot of your valuable time on unefficient manual resource levelling.
Regards,
Vladimir
Member for
20 years 7 monthsAh, but Mike, even if that is
Ah, but Mike, even if that is true, Asta still doesn't compute critical path drag.
Here is why this is relevant: critical path drag computation greatly assists the scheduler in compressing and optimizing the initial schedule. And that can allow a Spider Project user to resolve. without even realizing it, what would have been bottlenecks and lead to a shorter schedule.
For example, let us assume that a WIDGETER, needed for the one-week activity called WIDGETING, is available only during the first week of every month.
The Asta user does a little CPM schedule optimization limited to traditional CPM metrics and WIDGETING is scheduled for the second week in June. Then resource leveling is performed and WIDGETING slips to the first week in July, when the WIDGETER is available.
The Spider user does CPM schedule optimization which includes critical path drag and is thus easily able to compress the schedule so that WIDGETING is scheduled for two weeks earlier than with Asta, back to the last week in May. Now when resource leveling is performed, WIDGETING still slips to the next availability window -- only now that slippage is only to the first week in June, a month earlier than with Asta.
If WIDGETING is on the critical path, Spider Project's drag computation functionality may have saved a month of duartion and many hundreds of thousands of dollars (if not millions) because its resource leveling algorithm is operating on a drag-optimized schedule. And this is just one example -- how many situations like this are they in a 20,000 activity schedule?
I'm not at all meaning to give you a hard time, Mike. But Vladimir saw the value of drag computation and programmed it into Spider Project five years ago. Despite your nudging them, Asta has yet to act.
Fraternally in project management,
Steve the Bajan
Member for
19 years 10 monthsHi VladimirAsta PowerProject
Hi Vladimir
Asta PowerProject will carry out resource levelling a well as any other software - Including Spider.
Best regards
Mike Testro
Member for
11 years 6 monthsDoes any one has an idea/
Does any one has an idea/ referenece about what should be our WBS for decommissioning of mine ?
Regards
Mukesh Gupta
Member for
24 years 8 monthsHi Floris,Mike just never
Hi Floris,
Mike just never used the software that does resource leveling properly. It cannot be replaced by anything else.
Regards,
Vladimir
Member for
19 years 10 monthsHi FlorisMy philosophy is
Hi Floris
My philosophy is NEVER EVER use resource levelling software.
Critical Mass as defined in the article seems to be planned resources deployed being larger than resources available.
This is displayed on most histograms as a red band over the available band.
Even P6 does it.
Why bother with expensive add ons?
Best regards
Mike Testro
Member for
11 years 3 monthsHi MikeI thought that the
Hi Mike
I thought that the defintion "critical mass" was a wellknown word in the scheduling theory after reading this article:
https://www.interplansystems.com/project-management-software/resource-leveling-critical-mass.html
They argument in the arcticle that resource levelling is often not the optimal approach for a turnaround schedule and they introduce the concept of critical mass.
Has anyone thoughts, ideas or opinions about this article it's concepts ?
Member for
19 years 10 monthsHi FlorisI think I am one of
Hi Floris
I think I am one of many on PP who have no idea what you are going on about.
Best regards
Mike Testro
Member for
11 years 3 monthsNobody ?
Nobody ?