Rafael,

RE “In your sample job I did not find any defined phase or activity priority! The priority comumn is empty, if you are not expicit the software will not know”

I achieve priority by NTL constraint, the earlier it is – the higher priority

RE “I never liked the idea on using constraints as a way to tweak resource levelling, I keep constraints at a bare minimum.  Spider”

I understand, that may be I am using the feature not the way it was supposed to be used, but it still has been "blessed"  by Vladimir. But can you achieve the same result different way? Can you take the schedule from the bottom example and try to make Spider schedule it the way I scheduled it without using NLT constraints? Note: you need to make sure, that Spider would respect priorities of phases:

• No Prior Activities
• Medium priority project
• Low priority project
• Absence (highest priority)

Evgeny,

I used Optimization as Standard or Advanced were not so good, in this case Optimization Plus yields same result. I erased all FNL constraints.  Do they look like what you are looking?

Best Regards,

Rafael

Rafael,

OK, in this particular example results seem to be the same both using prioritisation using NLT and using phase priorities.

But I think in the below (new) example you can't achieve this.

https://drive.google.com/file/d/0B1FBt_G3gCVqaHkwU3BOMDNyTGs/view?usp=sharing

I do not get it if not using priorities, no constraints you can get better results by simply clicking on optimization. In this example the finish of the phases will still be in same order.

Rafael,

Imagine:

Resource A – emergency department doctor A

Resource B – emergency department doctor B

High Priority – help a very ill patient with live threatening illness, who require immediate attention. Any delay in treatment significantly increases chance of death.

Medium Priority – help seriously ill patient, not live threatening, but requires attention ASAP

Low Priority – treat patient with minor illness.

Your schedule suggests, that it OK to delay treatment of a High Priority patient, if due to this delay  treatment for  Medium and Low priority patients will also finish earlier.  But I want an algorithm where a High Priority patient gets attention 1^st (just because he may die otherwise), even it delays overall schedule.

Do you see what I am trying to say?

Use the option  "Standard" that will respect the task prioritization.  Let the patient live, of course he will stay longer at the hospital if he survives.

This is why we need several algorithms, because no single algorithm is the cure for all illness.

In your original example the operation activity was not split but the operation started after treating a patient for a headache and he died. 

In case of life/death assignment sequence is so strict then resource dependencies become hard links and shall be scheduled as such.  As you start treating patients the schedule shall be updated in the hope there is time to take care of those with a headache.

Rafael,

standard resource prioritization downgrades spider to MS Project in terms of resource leveling algorithm, thus losing significant advantage of the tool.

I used example of doctors just to illustrate, that often one needs prioritization, which will concentrate resources on one subproject and only then on another one and not on all of them in parallel.

Your example with doctors has a very simple schedule, so one can not see the advantages of the advanced resource leveling there.

RE: “This is why we need several algorithms, because no single algorithm is the cure for all illness.”

I think we already have effectively 2 algorithms

Using priorities of activities or phases

Advantages: straightforward and logical

Disadvantage: gets strictly followed only in the Standard resource leveling. In Optimization and   Optimization Plus may be ignored. Not clear what rules Spider follows, when he takes decision to follow or not follow prioritization.

Using unachievable NLT constraint

Advantages: followed even in Optimization Plus method

Disadvantage: not straightforward to use. Screws float calculation (there is a workaround for this by using “previous version support”)

Your example is confusing as you are assigning a FNL constraint of 05-11-2014 to the chain for Medium priority project via the Medium Finish Milestone while you are assigning a FNL constraint for the Low priority project of 06-11-2014 via the Low Finish Milestone, I cannot follow the logic of what you say. 

Rafael,

Advantages: followed even in Optimization Plus method

I do not see this happening on your example,  some activities on a chain with earlier NLT constraint are scheduled after those on a chain with a latter one.

Can you point me exactly what you mean? I think everything is happening as I would expect.

Disadvantage: not straightforward to use. Screws float calculation (there is a workaround for this by using “previous version support”).

Also unreliable with regard to keeping priorities, optimization will look for shortest schedule duration and this will take precedence.

Well..this is my understanding (and testing), that NLT constraint has a higher priority, then the desire of Spider to make the shortest possible schedule. I did find one example, where it does not quite works like this, but this is still much better, than using priorities. 

<<

Your example is confusing as you are assigning a FNL constraint of 05-11-2014 to the chain for Medium priority project via the Medium Finish Milestone while you are assigning a FNL constraint for the Low priority project of 06-11-2014 via the Low Finish Milestone, I cannot follow the logic of what you say. 

>>

Why is that confusing? The lower priority, the later the date, the higher the priority, the earlier the date. And it works!! 

Your example is confusing as you are assigning a FNL constraint of 05-11-2014 to the chain for Medium priority project via the Medium Finish Milestone while you are assigning a FNL constraint for the Low priority project of 06-11-2014 via the Low Finish Milestone, I cannot follow the logic of what you say. 

Why is that confusing? The lower priority, the later the date, the higher the priority, the earlier the date. And it works!! 

OOps you are correct, jumping back and forth from one example to another is confusing, it would be easier if using prioritization number rather than dates and because FNL can be anything, no matter if the tweaking make all the chains artificially critical, then why use them? 

OOPS an unsuspected predecessor to Acticvity 10 became critical and priority sequence is broken.

Also everything is critical due to the indiscriminate use of NLT constraints.  Well this is good no matter what any delay by owner justifies an EOT. 

 I did find one example, where it does not quite works like this, but this is still much better, than using priorities. 

I guess this makes it unreliable.

After erasing from my mind your first example in which activity description did not follwed prioritization using FNL I could understand you and found no difficulty on its implementation.  I tried myself finding the single example where it does not woks like this and could not find it on the spot, complex resource modeling takes time.  

It would be interesting to see your example. Maybe the procedure can be adapted to make it reliable for optimization to enforce strict priorities without need to use NLT constraints for this purpose, scheduling is also about transparency. 

I do not believe Optimization shall attempt to satisfy any requirement above what the name implies, shortest duration or it shoulb called Sub-optimizations.  All NLT constraints that make the chain critical shall be considered equally critical, with 0 total float. Use of unreal constraints that might artificially make other meeting chains critical is a capital sin.  When you have to keep a strict priority rule it shall be transparent and under another algorithm, otherwise would be misleading.  

Now it comes out that if real constraints when critical can control optimization you have to figure it out how to tweak them in order to keep a desired order of precedence without making everything critical. Maybe you shall never use NLT constraints for real and use them only for prioritization, anyway they can be anything you want, in such case better call them prioritization constraints. 

Rafael,

One of the consequences of using of prioritization via unachievable NLT constraint is that you get several critical paths. But one can consider, that this is actually an advantage, as effectively we have several subprojects in a schedule then (each of them with different priority), so it is logical to know the critical path of each of them. So, I think this is comparable to MS Project option “Calculate multiple critical paths”.

Any way,  Vladimir has actually described the workaround  to avoid both confusion with stack and multiple critical paths. See his post from Mon, 2013-12-02 16:16.

http://www.planningplanet.com/forums/spider-project/553007/activity-and-phase-priority-rules

This goes about portfolio, but equally applicablte to for project as well

<< 

I don't consider this feature as unofficial. It is natural and exists for more than 20 years.

But I have a proposal: now save this portfolio, define it as a previous version, delete these artificial Finish NLT dates and calculate portfolio schedule with Previous Version Support option.

Best Regards,

Vladimir

>> 

Evgeny,

I do not agree with the idea on using ambiguous and arbitrary NLT constraints to tame open ends, open ends shall always be critical, simple and unambiguous.  When working with portfolios you should keep all chains constrained by a single start and a single finish activity.  In this way if you want to see float on a portfolio you will see real float.  If you want to optimize the portfolio it will be optimized to its best the software can find.  If you want to keep certain project prioritization then use other algorithm and be explicit about your project priorities in a transparent way.  Using dates when adding a new job it is possible everything gets twisted, if you want to change priorities the intuitive way is to use priorities rather than dealing with a bunch of dates, or hundred of dates if your portfolio is big.  If you do not want or need for portfolio to share resources and be self sufficient as is required in our contracts just do not plan them with shared resources and use an independent pool for each job.

I do not like this approach and did not noticed before as most of my schedules are for construction contractors whose projects are mandated to be scheduled as stand alone, only for curiosity I use portfolios.  Maybe I got scared away by the complexity of rules and decided not to pay attention to it.  Too complicated for everyday use.

Rafael

Rafael,

I understand what you say and agree with it, but the only thing which I can say is: in my view resource leveling without prioritization has a little use, because projects (or subproject) rarely operate standalone and they never have the same priority.

And the method of "unachievable NLT" constraint is the only way I found make sure that Spider will really make sure that low priority schedule will almost have no influence of the high priority schedule whilst still enjoying the advanced resource leveling algorithm.

But I really wonder how you address this prioritization thing? Do you use it in your projects? 

My jobs are all stand alone.

The priority of all my jobs is project delivery, forget about any prioritization taking precedence, to me it makes no sense to target sub-optimal because of how tight our projects are.  I target for an early finish job in the hope [after my own delays] I will still be able to make it.  I believe prioritization shall be considered if it does not affect shortest schedule duration and believed it is how it works.  I use prioritization for activities as well as for resource selection with the understanding optimization can override them. 

Prioritization algorithms and any improvement on them shall always be an option, in case your project is not tight even in the absence of life and death issues can be a better option.  Not always minimum duration will define optimal.  

Once the schedule is running I avoid too many changes in the sequence using the calculation option for "previous version support", after optimization done once in a while, when projected finish have no longer any buffer.

We need multiple options and Spider provides them. 

Proritization is useful and in many cases necessary but there is an hierarchy of goals. In Spider Project priorities are considered as soft, like nice to follow. But if there is a solution that at some moments does not follow required order but leads to shorter project duration (and cost) then it is selected.Priorities are used forwhat if 

Priorities are must for portfolio management.

When project is leveled the software looks first to activity priorities and then to other activity data. When priorities are applied and the schedule shall strictly follow required priorities then optimization does not add much and standard algorithms are good enough.

In Spider Project standard means that the user selects the way activities will be prioritised. It can be total float, duration, Start ALAP, ID, etc. - any field selected manually. This is an approach that is used by some other packages like P6, Open Plan, etc. So the user can try several options and select the best for the current project. In MS Project there are no options. This is why I don't agree with Evgeny that Spider standard option is the same as MS Project leveling capabilities. You still have more choices. 

In reference to my statement:

"I do not agree with the idea on using ambiguous and arbitrary NLT constraints to tame open ends, open ends shall always be critical, simple and unambiguous."

I would like to add Spider Hammocks shall not be considered open ended activities as the finish of these are calculated using predecessor logic.

The problem would be what to do with open ended activities on old project files that are based on current Spider calculations. For this reason I do not believe my suggestion will ever be implemented in Spider, no big deal for me.

The implementation of Zero Total Float Constraint that assigns a total float value of zero, causing the Early Dates to equal the Late Dates of the activity could be an option.

Best Regards,

Rafael