Guild of Project Controls: Compendium | Roles | Assessment | Certifications | Membership

Tips on using this forum..

(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.

NTL constraint does not work always

28 replies [Last post]
Evgeny Z.
User offline. Last seen 34 weeks 2 days ago. Offline
Joined: 13 Jan 2008
Posts: 442
Groups: None

Vladimir,

whilst I was looking at the subject of exceptions, I noticed, that my favorite NLT constraint  does not always work as I would expect it to.

In the example below you will notice, that in the 2nd case it does not work, because the activity with NLT constraint is put in a separate phase

Is it an expected behavior?

 photo NLTisnotalwaysrespected_zpsd8b457f6.png

Replies

Evgeny Z.
User offline. Last seen 34 weeks 2 days ago. Offline
Joined: 13 Jan 2008
Posts: 442
Groups: None

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

Rafael Davila
User offline. Last seen 5 days 6 hours ago. Offline
Joined: 1 Mar 2004
Posts: 5227

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

Evgeny Z.
User offline. Last seen 34 weeks 2 days ago. Offline
Joined: 13 Jan 2008
Posts: 442
Groups: None

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.

Rafael Davila
User offline. Last seen 5 days 6 hours ago. Offline
Joined: 1 Mar 2004
Posts: 5227

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. 

Evgeny Z.
User offline. Last seen 34 weeks 2 days ago. Offline
Joined: 13 Jan 2008
Posts: 442
Groups: None

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

Rafael Davila
User offline. Last seen 5 days 6 hours ago. Offline
Joined: 1 Mar 2004
Posts: 5227

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.
Evgeny Z.
User offline. Last seen 34 weeks 2 days ago. Offline
Joined: 13 Jan 2008
Posts: 442
Groups: None

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

Rafael Davila
User offline. Last seen 5 days 6 hours ago. Offline
Joined: 1 Mar 2004
Posts: 5227

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. 

 photo 3-24-20146-55-07AM_zps7467b02b.jpg

Evgeny Z.
User offline. Last seen 34 weeks 2 days ago. Offline
Joined: 13 Jan 2008
Posts: 442
Groups: None

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

Rafael Davila
User offline. Last seen 5 days 6 hours ago. Offline
Joined: 1 Mar 2004
Posts: 5227

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

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.

Evgeny Z.
User offline. Last seen 34 weeks 2 days ago. Offline
Joined: 13 Jan 2008
Posts: 442
Groups: None

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

Rafael Davila
User offline. Last seen 5 days 6 hours ago. Offline
Joined: 1 Mar 2004
Posts: 5227

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 

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 Z.
User offline. Last seen 34 weeks 2 days ago. Offline
Joined: 13 Jan 2008
Posts: 442
Groups: None

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

Rafael Davila
User offline. Last seen 5 days 6 hours ago. Offline
Joined: 1 Mar 2004
Posts: 5227

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.

Evgeny Z.
User offline. Last seen 34 weeks 2 days ago. Offline
Joined: 13 Jan 2008
Posts: 442
Groups: None

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

Rafael Davila
User offline. Last seen 5 days 6 hours ago. Offline
Joined: 1 Mar 2004
Posts: 5227

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

Evgeny Z.
User offline. Last seen 34 weeks 2 days ago. Offline
Joined: 13 Jan 2008
Posts: 442
Groups: None

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:

 photo Notresourceleveled_zps99fd843f.png
Rafael Davila
User offline. Last seen 5 days 6 hours ago. Offline
Joined: 1 Mar 2004
Posts: 5227

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.

 photo 3-10-20142-18-44PM_zps7bf94041.jpg

Evgeny Z.
User offline. Last seen 34 weeks 2 days ago. Offline
Joined: 13 Jan 2008
Posts: 442
Groups: None
Bogdan,
thanks for reproducing the problem.Please also see link to my files  
https://drive.google.com/file/d/0B1FBt_G3gCVqMzgwQXN1LVFoWmc/edit?usp=sharing 
So, at the moment I have the following questions:   
1) Why spider produces different results for effectively the same schedule  
2) I also would like to question the very concept that Spider can decide to ignore constraint  “If to follow this constraint project finish date will be delayed".
What is the point of having this constraint feature then? This is obvious, that by setting constraints we will in most of the cases make the schedule longer, so it is a conscious decision of human to set a constraint.
I general I would like a software to respect the constraints I as a human set as long as it is possible and warn me if it isn’t. Regards. Evgeny
Bogdan Leonte
User offline. Last seen 1 week 3 days ago. Offline
Joined: 18 Aug 2012
Posts: 284

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

 

Best Regards,

Bogdan

Rafael Davila
User offline. Last seen 5 days 6 hours ago. Offline
Joined: 1 Mar 2004
Posts: 5227

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

 photo 3-8-201410-46-11AM_zpsfaed9136.jpg

Bogdan Leonte
User offline. Last seen 1 week 3 days ago. Offline
Joined: 18 Aug 2012
Posts: 284

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

Evgeny,

did you use the same leveling options in both cases?

Rafael Davila
User offline. Last seen 5 days 6 hours ago. Offline
Joined: 1 Mar 2004
Posts: 5227

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 Z.
User offline. Last seen 34 weeks 2 days ago. Offline
Joined: 13 Jan 2008
Posts: 442
Groups: None

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

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.