NTL constraint does not work always

Yes, it may happen. If to follow this constraint project finish date will be delayed.

This is why I siggested to make other activities splittable or use variable resource assignments when we discussed exception activities.

Vladimir,

can we put the "splitable" flag aside for a moment and look at the situation of the activities being not splitable.

The 2 schedules, which I showed in the 1st post are exactly the same when not resource leveled. They both start on 3 of March. However when they are resource-leveled, Spider produces different  results. And the only difference in them is that in the 2nd schedule Exception is put in a separate phase.

I still do not understand, why in one case NLT is respected and in another case is not.

Regards.

Evgeny

Evgeny,

What is the data date for first version?

Can you please post the two versions on a file server, this interests me. Using default settings and same data date I got both versions ending on Mar 10.

Best Regards,

Rafael

Evgeny,

did you use the same leveling options in both cases?

I tried replicating Evgeny's schedule and got the same results. I used the same algorithm (optimization+) with the initial settings.

Here is the file: http://speedy.sh/M6NBA/Project1.001.sprj

Bodgan,

Change Data Date on your model to 3-11-2014 and you will get results similar to Evgeny 1st schedule, it is all as expected.

Best Regards,

Rafael

Yes, I belive Evgeny was asking why does Spider produce different results for basicialy the same scenario. 

Best Regards,

Bogdan

They are not the same schedule, very different indeed.

One have a date constraint after Data Date, because the model is contiguous and both activities cannot happen on same day if you delay Exception then Activity one must happen after it and the job is delayed more than the feasible option selected by the software. The software selection is correct.

The other have the constraint at DD so the order does not matter, some was to be selected based on some prioritization rules either by default or by scheduler options. 

I have some intolerance to rules being broken, I have issues with strict dependencies and resource leveling on Spider Hammocks. I believe strict dependencies is a prioritization rule and shall not be defined as a link type but some kind of priority. I believe Spider hammocks shall accept resource loading and resource leveling only with minimum values of 0 for quantity and workloads. But this is a separate issue I solve by not using strict links I cannot trust and by resource leveling on hammocks only with variable quantities and workloads and minimal set to 0 in both. 

Using hammock resources is good for cash flow disclosure and good for accounting for cost of idle resources. I do not find a good practice to use hammocks as a trash can for resources to be used at same time on many activities, can lead to over allocations, better use partial assignments and workloads. Spider Hammocks are more powerful than traditional hammocks and can be defined by a single parent activity.

Rafael,

I am not quite sure, that we are talking about the same thing. Both schedules, which I have included in the link have the same data date: 03-03-14.

https://drive.google.com/file/d/0B1FBt_G3gCVqMzgwQXN1LVFoWmc/edit?usp=sharing

You can see it on the non-resource constraint schedules of them:

Evgeny,

Finally I got it and agree with you, optimization in order to yield an earlier overall project delivery broke the FNL constraint even when it was feasible. But what if it is contractual and you will be castrated if failing to meet it?

Probably an option to FNL constraints could be implemented so that optimization can by-pass it on a case by case if doing so will improve overall project delivery. Although visible on Gantt it might also be convenient to have a field to disclose when a FNL constraint was broken because of the optimization algorithm, good for filtering and reports.

The only reason to the breaking of constraints I can accept is if unfeasible, here the reason would be different and shall also be disclosed. As a matter of fact I believe no unfeasible constraint shall ever be allowed to happen, otherwise the schedule is not credible, is unfeasible. 

I bet you I have less tolerance than you to the breaking of rules.

Best Regards,

Rafael

Rafael,

RE "Probably an option to FNL constraints could be implemented so that optimization can by-pass it on a case by case if doing so will improve overall project delivery" 

Just if you think of it logically, most probably in most of the cases putting a constraint will make the schedule longer. Just because it reduces the room for manoeuvre for whomever is doing resource leveling (Spider algorithm in this case).

This is the same thing, that implementing a calendar exception also extends the schedule in most of the cases. Nobody suggests that algorithm shall ignore the calendar exception if it can find a shorter schedule without it. So, why NLT constraint shall be ignored?

Regards.

Evgeny

RE: Nobody suggests that algorithm shall ignore the calendar exception if it can find a shorter schedule without it. So, why NLT constraint shall be ignored?

I believe some NLT constraints can be released if it makes sense because doing so will improve end of job. If I have to delay an intermediate milestone to save time on total delivery I would consider it. But it got to be under my knowledge and control, the option will tell you if the release makes sense.

It looks like as of now that Spider optimization allows for breaking the NLT constraint if doing so reduces project delivery.

I just noticed, that this has been resolved (at least for example, which I used) in the just released version 11.03.01. (Thank you, Vladimir!)

Still it is not clear whether there are some other cases, when NLT contstraints can be chosen to be ignored.

Regards.

Evgeny

Evgeny,

we found an error in the program and it was fixed.

There are new features that may be of interest in the new version.

In particular now you can use any formulas to create filters.

Evgeny,

Start NET and Finish NLT are set to same day and time while duration to 1 day, therefore Finish NLT is still and will always be broken. Or am I missing something?

Rafael 

Rafael,

yes, you are right, but this is what I call "unachievable NTL constraint", which is a very powerful tool to set priority in Spider.

I was asking Vladimir, whether there are scenarios, when Spider can decide not respect even achievable NLT constraint

Regards.

Evgeny

Evgeny,

optimization algorithm can select shorter schedule ignoring NLT constraints.

But NLT is more powerful than manually set activity priorities and Spider tries to find good schedule respecting NLT constraints.

Vladimir,

Thanks for the clarification, this is what I would expect.

Evgeny,

Spider does not enforce unachievable constraints and this is why negative float calculations are not natural within Spider, something I would also expect of good late date calculations as Spider does. To me negative float is unnatural and even asked for it as for the software to give the number to whoever want it, as a special float definition I welcome it though I do not have much use for it. 

What I am missing is a warning when any constraint is not enforceable, I believe shall be part of the report and also included on some fields to identify start/finish broken/unenforceable constraints whether because of regular or optimization algorithms. In small schedules they can be identified visually but on large schedules filtering for broken constraint might be desirable.

Best Regards,

Rafael

Rafael,

using unachievable Finish NLT constraint is a very effective way to set the priority between different projects or subproject, this has been approved by Vladimir

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

I do not know other way to set priority, as the task and phase priority gets ignored by Spider in Optimisation Plus.

In the link I posted Vladimir also suggested a way to avoid negative floats by using the Previous Version Support feature.

Regards.

Evgeny

Using FNL constraints to control priorities seems unreliable even under standard algorithm.

Activity 2 have same priority and the FNL constraint on activity 2 had no effect whatsoever. 

Rafael,

in your example you are using the Start NET contstraint and not the Finish NLT, which I was talking about.

If you change it to Finish NLT, you will see how well everything is working

Seems like it works, overriding activity priority.

• I will investigate how this matches our usual specifications not allowing FNL constraints other than contractual, the reason why I am interested in other ways of getting the same effect but without creating confusion about real date constraints versus some prioritization. 
• Our contracts require transparency, require disclosing negative float relative only to contractual dates.

Rafael,

I may repeat myself, but I just find an "unachievable NLT constraint" as a very effective mechanism to set a relative priority of a certain project within a portfolio or subproject within a project.

This requires however, that all activities of a project will terminate to one or several milestones (which will get these NLT constraints assigned). In another words you shall not have a lose ends. But this is a recommended way of working any way, not to have a lose ends.

Regards. 

Evgeny

Adding some milestones makes no difference with regard to contractual dates, they cannot be tweaked in our contracts, only real contractual dates are allowed.

Here this method of tweaking would be considered bad practice. 

Rafael,

I agree, that I propose to use unachievable NLT constraint only to set a relative priority of a project or project path for correct resource allocations.

A scheduler will then have to monitor it manually on whether the certain contractual milestones being met, but this is also in line with Success Driven Project Management methodology, as I understand.

Evgeny,

I would like to see an alternate way to do what you are doing that does not break other rules, taking some extra control is not a bad idea, a very good one indeed. 

Best Regards,

Rafael

Rafael,

if you find an alternative way to set a relative priorities between 2 project, which will not be ignored by Optimization Plus, this will be very interesting for me. By I think that activity priority and NLT constraint are conflicting features by definition. At the moment Spider is implemented in such a way, that NLT constraint has a priority. 

Regards.

Evgeny