(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.
Dear all,
Can you please check the below example.
Unless I am missing something it looks for me, that Resource Constrained Schedule does not produce correct results for Start to Finish linked tasks.
See example below
Initial schedule
Resource Contrained scheduled
What I think Resource Constrained Schedule shall produce
Regards.
Evgney
Printer-friendly version
Send to friend
Vladimir,
Best regards,
Rafael
Rafael,
I think that the best solution is a warning that some constraints (like JIT dependency) cannot be satisfied and why.
Ignoring any entered data may be more confusing.
Rafael,
RE
"Can you manually level your sample job without breaking the logic as to yield optimal, optimal that meets all criteria is a delayed job."
I would want my schedule to be resource leveled like this
instead of like this
Thought I agree with you, that maximum type relation is probably the most correct solution for this problem, because in my case it is possible, that activity 401 can be so much brought forward, that it will not be a "just in time delivery" any longer.
Evgeny,
Can you manually level your sample job without breaking the logic as to yield optimal, optimal that meets all criteria is a delayed job.
BTW I made some adjustments to the delivery activity as it shall be of the Spider ALAP type and it is possible there is no workaround on MSP, it is possible this was Vladimir warning, not sure.
You can download the file and test it with any combination of resource loading, one mishap will be enough to prove it does not always yield expected results. Note I added to all phases the link to Installation predecessors, this was also missing.
As you can see even if it works it is error prone, maximal lag is easier and safer because it is not a workaround, but a direct mathematical representation of the problem.
http://www.mediafire.com/download/dugwg7tj8i7bsyk/RD020.003.sprj
Vladimir,
Sometimes for such schedules I wish I could block additional links to specific activities as to prevent errors when using some convoluted logic. Maybe an editable warning for the individual activity will add understanding of why the scheduler issued the lock. Does it makes sense to you?
Best Regards,
Rafael
Rafael,
I probably did not express it correctly.
The correct statement is: the convoluted logic method works, but when resource leveled, it does not produce the result, which I would consider optimal.
In my example, the activity Code=401 has been delayed, thus delaying the subsequent schedule, however I would expect, that this activity would be brought forward instated.
Regards.
Evgeny
Evgeny,
Can you be specific as to where the sequence is wrong and where are the overloads?
I downloaded your file and checked sequence before and after resource leveling and it looks ok, also run an overloads report and nothing came out after leveling while before leveling there were some overloads.
Installation milestone after resource leveling is not driving, but the delivery is, it is the workaround to allow for direct links to delivery activity without it dragging to the left the delivery.
Best Regards,
Rafael
Rafael,
I have now had a deeper look at you convoluted logic example and, as Vladimir has suggested, it does not work when resource leveling is used. And this was the very reason, why I started discussion.
See below
https://docs.google.com/file/d/0B1FBt_G3gCVqSlBuY1RBaGVUVWM/edit
Pro Jack got it as expected with a single maximal link.
On the following link there is a video, look how the successor to delivery does not drag it to the left, note how at some point delivery float is reduced to zero. Works without need of unreliable workaround and no need to create add milestone.
http://www.youtube.com/watch?v=YXTs31c3gUY
Best Regards,
Rafael
Vladimir,
Purpose of Phase2 was to show Evjeny the trap, your workaround of using SS links from successor works without need of any milestone, the idea of the milestone was to avoid the trap and make it work even if you link successor to delivery activity, it also worked, without the trap but with additional milestone.
I changed all delivery activities to ALAP to fix some issues and added resources, the scenario resource leveling worked as expected.
Maybe some maximal lag functionality will provide for it with no such trap, allowing the scheduler to link other activities directly to the JIT activity, this I do not know but will test ProJack Manager to see if and how JIT with some buffer (can be zero) might be modeled.
Best regards.
Rafael
I have no ProJack Manager license so I cannot save files but can try some simple scenarios.
Rafael,
if JIT is required it necessary to add SS dependencies from JIT successor and all others.
In this case phase 2 will be properly schedules.
It is logical and easier than add and manage unnecessary milestone.
But still resource constraints may create problems.
Best Regards,
Vladimir
Evgeny,
The ALAP delivery will be moved to an earlier time with the added ASAP successor as the new successor will be driving the activity to the left, you just need to follow what I am saying before moving forward to the next issue of modeling some delivery buffer. It is how ALAP works in Spider, it delays the activity within free float, of course if you apply ALAP to all activities as soon as all activities Free Float is consumed no Total Float will be left.
Because what I call the convoluted logic does not depend on how ALAP I believe it should work in MSP as well, sorry I do not have MSP to try it. It shall also keep the correct logic while resource leveling. As all the available methods this also have his own traps.
http://www.mediafire.com/download/521mthbhamyxmb3/RD020.001.sprj
Phase1 represents a simple model of just in time using a FS link and ALAP for delivery, it look good for early bars as well as for late bars.
Phase2 represente the above model but with an ASAP successor added to the delivery activity, for early bars it does not model just in time delivery. This is a trap I was warning you to speed up your understanding of how ALAP works in Spider.
Phase3 represents the FS method as suggested by others, it looks good for early bars but it misses correct late bars becuase a late delivery will not delay the installation activity.
Phase4 represente the FS method that works with the addition of an auxiliary milestone. Early bars and late bars make sense. But at the expense of adding a milestone that must be correctly updated.
Because things usually do not happen as planned the milestone actual date is not as planned, correct update to such milestones is an issue to my clients, either they miss the update or do it wrong. Frequently these milestones have multiple predecessors and the driving predecessor as planned is not the driving as per as built logic.
I believe after Spider improves strict links and implements some maximal lag functionality we will be able to tackle the issue in a safe way, with no traps, that is not so cumbersome, that do not add more milestones that create updating problems.
At times less is more but people that make scheduling specifications only see one side and forget how such simple things as adding milestones to "make it clear" complicate things at the time of updating the schedule.
Best regards,
Rafael
Rafael,
RE
Add another successor to the just in time delivery activity, most probably ALAP will not do it.
Not sure what you meant, but it works the way I would want it to.
RE
At times I like to schedule not just in time but close to just in time. Say delivery to be a week or less before installation start. A lag will not do it as it will artificially delay installation if delivery is delayed to 3 days before installation.
What I do normally is the following:
Are there any reasons you think it may not work?
Add another successor to the just in time delivery activity, most probably ALAP will not do it.
At times I like to schedule not just in time but close to just in time. Say delivery to be a week or less before installation start. A lag will not do it as it will artificially delay installation if delivery is delayed to 3 days before installation.
That our model looks good with early dates is not enough, it shall also correctly model intended float allowances. There are alternative ways to improve the just in time model but unfortunately too intricate. I hope improved strict links and maximal lag will provide for safer modeling of just in time in addition to many other things. Keeping some limitations on maximal lag shall make it easier to understand the implications.
Evgeny,
If you model just in time in MSP using SF link and no successor to the delivery activity it can be delayed till the end of job, here some convoluted logic must be added for resource leveling and late schedule to work as expected when using SF logic.
Still somewhat tricky as you shall take care not to link predecessors to installation activity but to installation start milestone. Needless to say with the use of user defined fields, formulas and filters you can keep it under control.
Best regards,
Rafael
Vladimir,
it is clear now. I think it was my misunderstanding of what SF relation actually means, which was partially caused by advise of Microsoft to use these types of relations for just in time delivery planning.
Strangely enough also Microsoft Project does not produce "just in time delivery result", when resource leveling is used.
I will raise this at Mcrosoft forum.
Regards.
Evgeny,
the time difference between start and finish in this case is still zero.
We shall look how to avoid this confusion.
Regards,
Vladimir
Vladimir,
thank you very much for your answer.
In Spider setting activities, which are to be "just in time delivered" to be ALAP worked fine. Also resource leveling worked correctly in this case.
In Microsoft Project, as you pointed out, it pushed all succession activities backwards. So in Microsoft Project it did not work.
So, the topic of planning just in time deliveries in Spider is closed.
However I have one question regarding SF links
You write "It means that if you apply SF dependency succeeding activity shall finish AFTER preceding activity start. "
May be I miss something, but this is not how Spider schedules it, when no resource leveling is used
In thus case Activity 3 is preceding, activity 4 is succeeding
Regards.
Vladimir,
Of course Contractor site security is a hammock (LOE) activity that may finish as soon as owner site security starts. I just did not showed this way for simplicity as in most of my schedules hammocks are frequently defined by a lot of unlinked activities, I always miss the topic activities but modeling the dragging of a topic activity or MSP Summary Activity is out of Spider functionality. In any case to show Contractor site security is dragged by the late start of Security by Owner a SF link is needed.
Never say never ...
Evgeny,
Same as you I would schedule just in time using SF links but suppose in MSP an auxiliary milestone under the Summary Task would be needed unless you can create a SF link to the Summary Task. As Far as I recall links to Summary Tasks are somewhat limited, and this limitation can make sense but I do not have a current MSP license.
I do not schedule just in time very frequently but maybe I learned the use of SF links from MSP forum and the security guard issue is just an extension of the concept, somehow it was on my mind.
I am glad to know you accept some uncommon link types and are even wanting more such as strict and maximal lag though I have my reserves about full implementation of maximal lag. It is good that Spider Team listens like no other team, because of you a few good things have already been included.
Contrary to what many advocate, that we do not make enough use of milestones I am against their indiscriminate use and use them only when needed. These have been a burden with schedule updates as my clients frequently forget milestone shall be updated and shall match the update of multiple related activities, an update usually different to as planned. They frequently miss some of the multiple links, among them the driving as happened, not necessarily the same as planned The need for extra milestones to mimic the topic activity is something I hate.
Best regards,
Rafael
Evgeny,
in your screenshots you did not show that resource A is assigned to activity 3. In this case the schedule that you presented is correct.
I want to remind you that FS, SS, FF, and SF dependencies are of No Earlier Than type. It means that if you apply SF dependency succeding activity shall finish AFTER preceeding activity start. So using SF dependencies for JIT modeling is totally wrong. With resource leveling succeding activity may be delayed and it will be right!
For this purpose link activities with FS dependency (in right order), make preceding activity ALAP (select this in activity properties) and you will get required result.
Don't do this with MS Project - it interprets ALAP different way delaying all successing activities.
Gentlemen,
in Microsoft Project I normally use Start to Finish relation to plan "just in time" delivery. This is actually what it is meant for, as I understand:
http://office.microsoft.com/en-gb/project-help/linking-project-tasks-RZ001135937.aspx?section=8
In the example of my 1st post, I need Activity 4 to finish just before Activity 2.
Spider schedules it correctly for non-resource constrained schedule, however when resources are constrained, Activity 4 gets delayed, and this is clearly not what I want. In case of constrained resources, I want it to be brought forward. The real life logic is as follows: if we can't do it just in time, let us do it a bit earlier.
So, now I have the following questions
1) What is the purpose of the SF relation in Spider if, when resources leveled, it does no obey the logic, imposed by non-resourced leveled schedule? For me it looks that without resource-leveling is follows the SF logic, however with resource leveling it follows Start to Start logic.
2) If not using SF logic, how would I achieve correctly resource-leveled just in time delivery planning?
Regards.
Evgeny
PS.
Rafael,
Contractor site security is a hammock (LOE) activity that may finish as soon as owner site securuty starts.
Mike,
Never say never .... we have such activities in all our jobs, our crime rate is high.
If the owner delays bringing his security as it happens on government jobs then the start of his activity will delay the finish of ours.
Not surprisingly I don't remember a single other case when we used this dependency for real activities, but maybe I used them, just do not recall,... never say never.
So on a forensic analysis if the owner delays the start of his responsibilities he would not be liable for delaying the finish of my responsibilities with regard to site security?
Best Regards,
Rafael
Mike,
sometimes we use this link to hammocks but I don't remember a single case when we used this dependency for real activities.
Hi Evgeny
Vlaimir was too kind.
The type of link that you described - Start to Finish - has no place in construction planning so stop doing it now.
Best regards
Mike Testro
Evgeny,
activity 4 shall finish after activity 3 start. In the last screenshot it finishes before activity 3 start.
I tried to create your project and got the following schedule that looks right:
Email: PPadmin@planningplanet.com
Replies