It seems I overlooked you was using portfolios instead of a single file with multiple sub-projects and therefore assumed you was looking for a way to make open ends critical through FNL constraints, a functionality available in most other software except Spider, a real issue for some, to the extent the functionality exists in other software. Seems it is not an issue for you nor Vladimir but for me it is when I want the FNL constraint on open ends to adjust dynamically.
If you do not have Spider Project Professional but a scaled down version that does not support Portfolios then you might need to use a single schedule to manage several independent jobs, jobs that might be internal and do not have a contractual finish date or not even a real FNL constraint, then you might need to display open ends critical.
I am still trying to solve the issues with regard to the script but for my exclusive use as you are not looking for this issue, I am having some issues with todays release that is preventing me to work out the formulas for the script.
I don't understand why you say, that the following is applicable for the method
"you shall first run the resource leveling without any artificial constraint, as good practice dictates, then you can adjust float on open ended paths with a formula that will make open ended activities FNL constraint equal to resource leveled finish of the activity and run again resource leveling. "
I envisage to use it as following (in the example of Portfolio scheduling)
Every project shall have no lose ends. All activities should always have a finish milestone as of its successors. The amount of milestones every project shall terminate to shall depend on the amount of priority levels, which shall be present for this project (minimal 1, but may be more. e.g.):
Project 1
Project 1 time critical Activities Finish
Project 1 none-time critical Activities Finish
Project 2
Project 2 time critical Activities Finish
Project 2 none-time critical Activities Finish
Then portfolio scheduler assigns different priorities to the milestones by assigning them different unachievable NLT constraints. The earlier date of NLT constraint, the higher the priority
Such approach probably does not allow usage of "normal" NLT constraints within the project. But they probably shall not be used in any case, if we are scheduling projects with different priorities (may be only on the highest priority project)
Do you see any flaws in such approach?
Member for
21 years 8 months
Member for21 years8 months
Submitted by Rafael Davila on Tue, 2013-12-03 15:06
Resource leveling algorithms shall consider all constraints and this include FNL constraints. Use of constraints for a purpose other than their true intent shall be avoided, this is why in most contracts use of FNL constraints other than contractually required/mandated is prohibited.
At some point use of constraints might have a similar effect as using soft logic instead of true resource leveling.
It seems to me you are looking for making open ends critical a functionality not available in Spider Project.
The problem is that in order for it to work correctly under Spider project [Vladimir correct me if I am wrong, please] you shall first run the resource leveling without any artificial constraint, as good practice dictates, then you can adjust float on open ended paths with a formula that will make open ended activities FNL constraint equal to resource leveled finish of the activity and run again resource leveling. The problem is that before every update you shall clear the artificial constraints you used for purpose of showing open ends as critical. To me it would be better if such functionality for making open ends critical is implemented within the software that will make sure all correct steps are done automatically.
I am trying to create a script for this purposes but it seems like it fixes leveling conditions at time of creation of script, will let you know if this is an issue and if I found the solution.
Member for
24 years 8 months
Member for24 years9 months
Submitted by Vladimir Liberzon on Tue, 2013-12-03 13:07
having looked at the floats calculation I can see that with my method floats are also calculated the way I would want them to.
Every sub-project has it's own float calculation, not influenced by the float of another (lower priority) sub-project. The only disputable thing is the float of the NLT-constraint Finish milestone, but even this one is probably exactly the way I would want it to be.
Or am I missing something?
Member for
24 years 8 months
Member for24 years9 months
Submitted by Vladimir Liberzon on Mon, 2013-12-02 23:54
I did not mean, that NTL constraint is unofficial, but usage of an “unachievable NLT constraint” to set the project priority is not something, which I saw in any of the manuals or help files.
Question: what advantages are delivered by this manipulation with the “Previous Version Support” option, which you described the previous post in compare to constantly keeping “unachievable NLT constraint”?
Regards.
Member for
24 years 8 months
Member for24 years9 months
Submitted by Vladimir Liberzon on Mon, 2013-12-02 17:16
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
Member for
21 years 8 months
Member for21 years8 months
Submitted by Rafael Davila on Mon, 2013-12-02 17:09
A portfolio model is similar/equivalent to a single job model where multiple jobs are included under different phases within same model. If optimization is in order at the single job model that includes all sub-projects each with different priorities then optimization is in order at the equivalent portfolio model. As Vladimir said optimization does not stop at the project level but considers whole portfolio. It is just that if priorities are in conflict with optimization then optimization takes precedence.
Resource leveling shall be done considering all constraints, if other jobs share resources with your job then resource leveling shall be done at the portfolio that includes all connected jobs via hard links as well as via resource sharing. When resource leveling must be done at the portfolio level and when the portfolio is in trouble then optimization can be the the weapon to use.
Indiscriminate use of optimization algorithms can create chaos, not only in portfolios but at the individual project as well. It is precisely because of this that Spider provides the optional algorithm to keep previous version order of activities when leveling.
At some point it makes sense to go back and get the job/portfolio within target and and optimization algorithm is used when the other algorithm options where activity priority takes preference fail to meet target schedule.
OK understood. But do you actually "bless" prioritizing projects in portfolios by assining "unachievable Finish NLT" constraints to "Project Finish" milestones of different projects ?
So far I found this "trick" very powerfull, flexible and much more intuitime, than assiging priorities to phases and individual activities, but since this is not an "official feature" I fear, that there may be some hidden problem somewhere, which I did not discover or that you will eliminate this feature during one of the scheduling engine updates (there is always this risk, with unofficial features)
I have posted this before, but this is how I mean to use the feature:
Optimization Plus is still useful - it shows the minimal time for performing the whole portfolio and sometimes it may be useful. But in this case multitasking is not avoided. So, yes use the standard leveling or enter Finish No Later Than for the Finish milestones of projects with high priorities. Optimization algorithms respect NLT constraints.
Did you try to schedule your portfolio example by other tools? It is interesting to delete priorities and compare the results with 72 hours project duration calculated by Spider Project optimization plus method.
so, if I understand it correctly, "Optimisation Plus" shall not be used to resource level portfolio, where projects, have different priorities, only Standard resource leveling shall be used in this case. Is it correct?
Regards.
Member for
24 years 8 months
Member for24 years9 months
Submitted by Vladimir Liberzon on Mon, 2013-12-02 11:15
I already wrote in my previous posts that if priorities are necessary then use standard leveling because optimization finds the shortest schedule and may ignore priorities.
And remember that if some activities of other projects precede activities of high priority project they also get the same priority.
Is it clear?
If resource is available and is required by activities of different projects then activity of the project with highest priority is selected. This is how standard leveling is working. Optimization does not stop at this stage.
may be I just have a different definition of a High Priority Project
RE "Optimization may ignore activity priorities"
One of the advertised features of Spider is portfolio scheduling, where different projects are assigned different priorities.
Question: what is your (or Spider) definition of the fact, that Project A in portfolio has a higher priority, than Project B? In another words if you were to give to somebody a task to do a manual resource leveling of a very simple portfolio schedule, where one project has a higher priority, than other, how would you verify, that this person has done a correct job?
In case of equal priority projects this is simple, you would just say: make sure, that you develop the shortest possible portfolio schedule, whilst taking care of resource (and other) constraints in all projects. But what would you say in case of portfolio of different priorities projects, how would you instruct this prson?
Regards.
Evgeny
Member for
24 years 8 months
Member for24 years9 months
Submitted by Vladimir Liberzon on Mon, 2013-12-02 06:52
in your example highest priority 100 is assigned to "Phase to prior". It means that the same priority is inherited by preceding activities/phases. This is why phase 3 has the highest priority and starts first if to apply standard leveling.
Optimization may ignore activity priorities and this is why your first schedule is "right"
Regarding example 2 (let us finish with example 2 first)
Activity 7 does not have Finish NLT constraint, in which we found a logical problem in previous thread, but it has Start NET constraint. Does your explanation require reconsideration in this case?
Note: I have posted the link to *.sprj file, so you can easily check it.
Regards.
Evgeny
Member for
24 years 8 months
Member for24 years9 months
Submitted by Vladimir Liberzon on Sun, 2013-12-01 23:23
as I wrote in my previous post: if priorities shall be certainly followed use Standard leveling option because optimization may ignore manually entered priorities if the schedule duration may be made shorter. So use Standard option in your portfolio and don't forget to check Use activity priorities box. In your example optimization plus ignores project priorities but creates much shorter schedule than any standard option that set priorities right.
We found logical error with using NLT constraint that will be fixed soon. That explains the behaviour in your second example.
Finish NLT creates stronger priority. If manual priority does not work but required set Finish NLT.
Activity priority is maximum of its own priority and priorities of all succeding activities. This is the explanation of the schedule behaviour in your second example. Activity 7 became critical and NLT constraint is not met. So preceding activities got highest priority including activity 6.
We will make some improvements in dealing with NLT constraints soon.
Thank you for your response. I think this is what I have described pretty much, except when it comes to critical chain.
Having played around with different priorities, at the moment I now find that priorities produce often unpredictable effect, even on simple schedules. So far the only predictable solution I found to impose priorities is the “unachievable Finish NLT contain”, set to the Finish milestone (I described it here). However since this is not exactly “certified” method, I fear that it may have some hidden problems, which I have not discovered yet
So, specific things, which I don’t understand:
1) RE “Activity priorities may be ignored by optimization algorithms if shorter option is found.” Note: I also found, that phase priorities can also be ignored by Optimization Plus.
I think I am missing the point here. By definition, when human assigns priorities he does not want the shortest schedule, he wants some parts of it to happen earlier than others, even for expenses of overall duration.
One of the features, which Spider advertizes, is portfolio resource leveling, when different projects are assigned different priorities and resources are leveled based on these priorities. So, if we look at at a simple example below (leveled with Optimization Plus), how could I explain to a higher management, that Resource A is 1st working on Low Priority Project (Activity 1), then on Medium Priority Project (Activity 7) and only then on the High Priority Project (Activity 10)? What is the point of assigning phase priorities in this case if Spider ignores them?
Management will ask: who allowed resource A to work on low and medium priority projects, whilst high priority project is waiting for resource?
2) RE “If an activity has some priority then all its predecessors inherit this priority.”
I find that for Optimization Plus it does not happen always and follows some logic, which I don’t understand. In 2 examples below the only difference is duration of Activity 8, which, however, shall not really affect Phase 1 – Phase 3 (due to NET constraint of Activity 7). Yet in one case priority of Activity 7 has been transferred to Phase 3 and in another case it wasn’t.
What is the logic of this? How can this be explained?
Member for
21 years 8 monthsEvgeny,It seems I overlooked
Evgeny,
It seems I overlooked you was using portfolios instead of a single file with multiple sub-projects and therefore assumed you was looking for a way to make open ends critical through FNL constraints, a functionality available in most other software except Spider, a real issue for some, to the extent the functionality exists in other software. Seems it is not an issue for you nor Vladimir but for me it is when I want the FNL constraint on open ends to adjust dynamically.
http://www.slideshare.net/InSyncConference/p6-version-7-tricks-and-traps
If you do not have Spider Project Professional but a scaled down version that does not support Portfolios then you might need to use a single schedule to manage several independent jobs, jobs that might be internal and do not have a contractual finish date or not even a real FNL constraint, then you might need to display open ends critical.
I am still trying to solve the issues with regard to the script but for my exclusive use as you are not looking for this issue, I am having some issues with todays release that is preventing me to work out the formulas for the script.
Best Regards,
Rafael
Member for
17 years 9 monthsRafael,I don't understand why
Rafael,
I don't understand why you say, that the following is applicable for the method
"you shall first run the resource leveling without any artificial constraint, as good practice dictates, then you can adjust float on open ended paths with a formula that will make open ended activities FNL constraint equal to resource leveled finish of the activity and run again resource leveling. "
I envisage to use it as following (in the example of Portfolio scheduling)
Every project shall have no lose ends. All activities should always have a finish milestone as of its successors. The amount of milestones every project shall terminate to shall depend on the amount of priority levels, which shall be present for this project (minimal 1, but may be more. e.g.):
Project 1
Project 1 time critical Activities Finish
Project 1 none-time critical Activities Finish
Project 2
Project 2 time critical Activities Finish
Project 2 none-time critical Activities Finish
Then portfolio scheduler assigns different priorities to the milestones by assigning them different unachievable NLT constraints. The earlier date of NLT constraint, the higher the priority
Such approach probably does not allow usage of "normal" NLT constraints within the project. But they probably shall not be used in any case, if we are scheduling projects with different priorities (may be only on the highest priority project)
Do you see any flaws in such approach?
Member for
21 years 8 monthsResource leveling algorithms
Resource leveling algorithms shall consider all constraints and this include FNL constraints. Use of constraints for a purpose other than their true intent shall be avoided, this is why in most contracts use of FNL constraints other than contractually required/mandated is prohibited.
At some point use of constraints might have a similar effect as using soft logic instead of true resource leveling.
It seems to me you are looking for making open ends critical a functionality not available in Spider Project.
The problem is that in order for it to work correctly under Spider project [Vladimir correct me if I am wrong, please] you shall first run the resource leveling without any artificial constraint, as good practice dictates, then you can adjust float on open ended paths with a formula that will make open ended activities FNL constraint equal to resource leveled finish of the activity and run again resource leveling. The problem is that before every update you shall clear the artificial constraints you used for purpose of showing open ends as critical. To me it would be better if such functionality for making open ends critical is implemented within the software that will make sure all correct steps are done automatically.
I am trying to create a script for this purposes but it seems like it fixes leveling conditions at time of creation of script, will let you know if this is an issue and if I found the solution.
Member for
24 years 8 monthsNo, you are not missing.In
No, you are not missing.
In portfolios we suggest to set NLT constraints for individual projects.
But in projects NLT constraints may be used as hard priorities but their influence on floats is not desirable.
Member for
17 years 9 monthsVladimir,having looked at the
Vladimir,
having looked at the floats calculation I can see that with my method floats are also calculated the way I would want them to.
Every sub-project has it's own float calculation, not influenced by the float of another (lower priority) sub-project. The only disputable thing is the float of the NLT-constraint Finish milestone, but even this one is probably exactly the way I would want it to be.
Or am I missing something?
Member for
24 years 8 monthsEvgeny,previous version
Evgeny,
previous version support is usually applied when optimal schedule is found.
NLT constraints change activity floats. Removing them amd using Previous Version option we restore real activity floats.
Best Regards,
Vladimir
Member for
17 years 9 monthsVladimir, I did not mean,
Vladimir,
I did not mean, that NTL constraint is unofficial, but usage of an “unachievable NLT constraint” to set the project priority is not something, which I saw in any of the manuals or help files.
Question: what advantages are delivered by this manipulation with the “Previous Version Support” option, which you described the previous post in compare to constantly keeping “unachievable NLT constraint”?
Regards.
Member for
24 years 8 monthsI don't consider this feature
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
Member for
21 years 8 monthsA portfolio model is
Member for
17 years 9 monthsVladimir,OK understood. But
Vladimir,
OK understood. But do you actually "bless" prioritizing projects in portfolios by assining "unachievable Finish NLT" constraints to "Project Finish" milestones of different projects ?
So far I found this "trick" very powerfull, flexible and much more intuitime, than assiging priorities to phases and individual activities, but since this is not an "official feature" I fear, that there may be some hidden problem somewhere, which I did not discover or that you will eliminate this feature during one of the scheduling engine updates (there is always this risk, with unofficial features)
I have posted this before, but this is how I mean to use the feature:
https://drive.google.com/file/d/0B1FBt_G3gCVqZnRveUFmMlBoQlE/edit?usp=sharing
Member for
24 years 8 monthsOptimization Plus is still
Optimization Plus is still useful - it shows the minimal time for performing the whole portfolio and sometimes it may be useful. But in this case multitasking is not avoided. So, yes use the standard leveling or enter Finish No Later Than for the Finish milestones of projects with high priorities. Optimization algorithms respect NLT constraints.
Did you try to schedule your portfolio example by other tools? It is interesting to delete priorities and compare the results with 72 hours project duration calculated by Spider Project optimization plus method.
Member for
17 years 9 monthsVladimir,so, if I understand
Vladimir,
so, if I understand it correctly, "Optimisation Plus" shall not be used to resource level portfolio, where projects, have different priorities, only Standard resource leveling shall be used in this case. Is it correct?
Regards.
Member for
24 years 8 monthsEvgeny,I already wrote in my
Evgeny,
I already wrote in my previous posts that if priorities are necessary then use standard leveling because optimization finds the shortest schedule and may ignore priorities.
And remember that if some activities of other projects precede activities of high priority project they also get the same priority.
Is it clear?
If resource is available and is required by activities of different projects then activity of the project with highest priority is selected. This is how standard leveling is working. Optimization does not stop at this stage.
Best Regards,
Vladimir
Member for
17 years 9 monthsVladimir,may be I just have a
Vladimir,
may be I just have a different definition of a High Priority Project
RE "Optimization may ignore activity priorities"
One of the advertised features of Spider is portfolio scheduling, where different projects are assigned different priorities.
Question: what is your (or Spider) definition of the fact, that Project A in portfolio has a higher priority, than Project B? In another words if you were to give to somebody a task to do a manual resource leveling of a very simple portfolio schedule, where one project has a higher priority, than other, how would you verify, that this person has done a correct job?
In case of equal priority projects this is simple, you would just say: make sure, that you develop the shortest possible portfolio schedule, whilst taking care of resource (and other) constraints in all projects. But what would you say in case of portfolio of different priorities projects, how would you instruct this prson?
Regards.
Evgeny
Member for
24 years 8 monthsEvgeny,in your example
Evgeny,
in your example highest priority 100 is assigned to "Phase to prior". It means that the same priority is inherited by preceding activities/phases. This is why phase 3 has the highest priority and starts first if to apply standard leveling.
Optimization may ignore activity priorities and this is why your first schedule is "right"
Member for
17 years 9 monthsVladimir,thank you for a
Vladimir,
thank you for a quick reply.
Regarding example 2 (let us finish with example 2 first)
Activity 7 does not have Finish NLT constraint, in which we found a logical problem in previous thread, but it has Start NET constraint. Does your explanation require reconsideration in this case?
Note: I have posted the link to *.sprj file, so you can easily check it.
Regards.
Evgeny
Member for
24 years 8 monthsEvgeny,as I wrote in my
Evgeny,
as I wrote in my previous post: if priorities shall be certainly followed use Standard leveling option because optimization may ignore manually entered priorities if the schedule duration may be made shorter. So use Standard option in your portfolio and don't forget to check Use activity priorities box. In your example optimization plus ignores project priorities but creates much shorter schedule than any standard option that set priorities right.
We found logical error with using NLT constraint that will be fixed soon. That explains the behaviour in your second example.
Finish NLT creates stronger priority. If manual priority does not work but required set Finish NLT.
Activity priority is maximum of its own priority and priorities of all succeding activities. This is the explanation of the schedule behaviour in your second example. Activity 7 became critical and NLT constraint is not met. So preceding activities got highest priority including activity 6.
We will make some improvements in dealing with NLT constraints soon.
Best Regards,
Vladimir
Member for
17 years 9 monthsVladimir, Thank you for your
Vladimir,
Thank you for your response. I think this is what I have described pretty much, except when it comes to critical chain.
Having played around with different priorities, at the moment I now find that priorities produce often unpredictable effect, even on simple schedules. So far the only predictable solution I found to impose priorities is the “unachievable Finish NLT contain”, set to the Finish milestone (I described it here). However since this is not exactly “certified” method, I fear that it may have some hidden problems, which I have not discovered yet
So, specific things, which I don’t understand:
1) RE “Activity priorities may be ignored by optimization algorithms if shorter option is found.”
Note: I also found, that phase priorities can also be ignored by Optimization Plus.
I think I am missing the point here. By definition, when human assigns priorities he does not want the shortest schedule, he wants some parts of it to happen earlier than others, even for expenses of overall duration.
One of the features, which Spider advertizes, is portfolio resource leveling, when different projects are assigned different priorities and resources are leveled based on these priorities. So, if we look at at a simple example below (leveled with Optimization Plus), how could I explain to a higher management, that Resource A is 1st working on Low Priority Project (Activity 1), then on Medium Priority Project (Activity 7) and only then on the High Priority Project (Activity 10)? What is the point of assigning phase priorities in this case if Spider ignores them?
Management will ask: who allowed resource A to work on low and medium priority projects, whilst high priority project is waiting for resource?
https://drive.google.com/file/d/0B1FBt_G3gCVqOWRZLXoxYkJoajg/edit?usp=sharing
2) RE “If an activity has some priority then all its predecessors inherit this priority.”
I find that for Optimization Plus it does not happen always and follows some logic, which I don’t understand. In 2 examples below the only difference is duration of Activity 8, which, however, shall not really affect Phase 1 – Phase 3 (due to NET constraint of Activity 7). Yet in one case priority of Activity 7 has been transferred to Phase 3 and in another case it wasn’t.
What is the logic of this? How can this be explained?
https://drive.google.com/file/d/0B1FBt_G3gCVqYmdiLVk2Rk9oM2M/edit?usp=sharing
Member for
24 years 8 monthsEvgeny,Spider does not apply
Evgeny,
Spider does not apply priorities this way.
Phase priorities are hierarchical and override activity priorities.
Activity priorities matter if phase priorities are the same.
Critical Chain is the result of the calculation, it is not known when scheduling starts.
If an activity has some priority then all its predecessors inherit this priority.
So activity priority is maximal of its own priority and priorities of all succeding activities.
I described the way Spider works with user defined priorities.
Activity priorities may be ignored by optimization algorithms if shorter option is found.