Vladimir,

 I will move the discussion particular to Spider Project to the following forum.

http://www.planningplanet.com/forums/spider-project/547916/about-consumable-resources-materials-spider-glossary

I understand what P6 calls materials is a different functionality to consumable resources, called in Spider and other software Materials therefore discussing this here is not appropriate even if relates to the same issue.

I will copy your sample schedule into a fragenet for future reference and perhaps latter on will add a few activities as to use it for copy and pasting the procurement chain for each of my deliveries.

To start it looks good and even if you have to create an independent material for each delivery it is much better and easier than copying the complex fragnet based on CPM logic.

Still the minimal/maximal lag has the advantage of no risk for inadvertently adding a successor an ALAP activity that might drag the activity to the left.  In the lack of Minimal/Maximal Lag functionality I wonder if some functionality to prevent adding links to an activity [unless unlocked] makes sense as to prevent an error prone to occur in such models. A protection different to access rights functionality, something simple.  This also we can discuss it on Spider Forum as you suggested.

As always thanks for your prompt response.

Rafael

Vladimir,

I had my thoughts about it but how can you copy and paste the fragment/fragnet without having issues with regard to material resources as it might end up assigning the same material resource to group of activities you want to be allowed to work in parallel. For some scheduling problems such as modeling of forms sets that move from building to building and for other spatial resources there is no match to Spider Material Resources as far as I know. Needles to say I am curious about your solution using Spider Project, never say never, I might end using it on regular basis. 

I am looking for a fragnet/fragment you can copy and paste that remains valid, still updating all those extra activities is a pain.

The other workaround I would consider is to create a feeding buffer also ALAP between the Delivery and Installation Activity, if the feeding buffer becomes critical then reduce its duration to 0. 

• Delivery(ALAP) ===> Buffer(ALAP) ===> Installation(ASAP)    
• Just make sure you do not add additional ASAP successor to any Delivery or Buffer activity other than as shown, the undesired effect of dragging to the left the ALAP activities is not always that obvious. This is no issue when using max/min lag but without these links it can be a relevant issue.

I still consider Minimal/Maximal Lag a superior model for this particular need, where no additional activities are requires nor whrere there is any danger of undesired effect when adding links to ALAP activities. 

I also believe full Maxima/Minimal lag functionality can cause a lot of errors and if Maximal Lag is limited to one per activity the possibility of error would be reduced. While more limited than ProJack implementation it might be Monte Carlo would not present the problems the unlimited implementation might. 

Best Regards,

Rafael

If your software provides for Min/Max Lag then modeling near to just-in-time deliveries keeping the desired float reserve and always disclosing correct float does not require any extra activity and is a breeze, just an additional maximal link.

Look how after delaying installation activity Close to Just in time Delivery is dragged to keep desired distance while maintaining desired float.

This I would like to do about 20 times on my deliveries on each of my typical job, unfortunately the workaround I am trying is so convoluted an error prone for practical purposes we do not have this option unless someone else shows a practical work around.

Best Regards,

Rafael

Hi Gary

So what - keep it simple I say every time.

Complex planning concepts are not the daily topic of conversation in the higher arcanar of the cocktail bars frequented by judges and construction arbtrators.

Best regards

Mike Testro

Gary, You said - So I think both your model using neg lag and my/Mike's model using ALAP are flawed. And gues what, you are right, the model shall be revised as follows as not to fall into the trap you just discovered. As I said before the idea just ocurred to me a few weeks ago but was never debugged. I appreciate a lot your help in this matter. 

http://www.mediafire.com/download/t3o7x70aw3cm2d3/RD020_2.xer

I would dare to say both models can be used, JIT determined by Installation Predecessors or JIT determined by Installation Activity.  Would be a matter of choice, the first one shall be safer as being equal or earlier will allow you to make some resource adjustments.

 

Best Regards,

Rafael

Mike,

 

It's only very simple if you ignore the valid point Rafael is making that using ALAP gives false values for free & total float.

 

Cheers,

 

G

Mike,

The issue presented on this discussion is about "deliveries close to just in time", deliveries delayed but not that much as to eliminate all free float.  Consumption of free float means consumption of total float is at risk. Management of Free Float is so important that even the dumbest software discloses it.

It might happen that the deliveries are delayed or that installation activities can start somewhat earlier than expected, do not entrap yourself to zero free float, reserve some of it. The model shall allow for the delivery activity to be delayed within available float without delaying the installation activities you are grouping with a Hammock. The model shall respond to delays/acceleration in projected installation activities by delaying/accelerating the deliveries accordingly while keeping desired float allowance, therefore fixed date constraints will not be good enough. 

For such long duration job it seems like some deliveries can be delayed over a year without consuming all float. It might even be that for protection of paint pot life and to avoid freezing the delay is somewhat mandatory. It is very common for us to delay some deliveries on purpose so it looks like beloved negative lag has a frequent and valid use on Construction Jobs. We do not model all deliveries in our jobs, perhaps about 60/job and delay on purpose 20 of them so 20 negative lag occurrence "occur" to me might make a valid need that is not that un-frequent. Never say Never.

One common procurement we usually delay is asphalt pavement, usually one of the last activities for which no subcontractor will guarantee price for so long, even in short duration jobs they include a cost escalation clause. The selection of the contractor and submittal process plus delivery requires you delay these activities but with some float reserve. There are other activities you might need to delay on long duration jobs for many reasons. At times even installation activities might be delayed such as in the case of some high cost equipment or landscaping you do not want to kee maintaing for too long. In all cases you want to have some float reserve the ALAP method will not allow in a transparent and correct model.

Best Regards,

Rafael

 thumbs up to negative lag

1.     OK I understand your point now. –Yes if you make an ALAP activity the only predecessor to another activity then it would shift it to the left, but the same would happen in your negative lag solution if the installation milestone had no predecessors, so I don’t see this as a reason not to use ALAP for deliveries.

·   The suggested procedure requires the use of the installation milestone and that the installation milestone is a successor to all installation predecessors.  Therefore it will not move to  the left, just try with the model as suggested, do not make changes, it would be a different model. We all know activities without predecessors will move to the extreme left.

·   In this case the ALAP method yields incorrect schedule, yields incorrect float values, yields incorrect critical path as the delivery activities in most cases shall be scheduled with some float, then why insist on using wrong model?

·  Most people like to take shortcuts usually to find a shortcut is the longest path in duration and distance between two points. That it looks relatively good does not makes it good at all, float values are wrong and therefore at some point it might be wrong logic that will will not drive correct successors.

2.     Agreed limited trucks might be an issue (only projects I have come across where this was the case was on cross-country pipelines, which tend to be better planned using line of balance planning rather than CPM resource leveling IMO), but approval of submittals would be a separate (non-ALAP) activity to delivery, so not an issue.

·   Approval of submittals is not critical in the initial model, but schedules are not static and logic shall be correct so that if submittals are delayed they can become critical and the model shall still display correct early and late dates as well as correct float values.

·   Good CPM/PDM scheduling software should have no problem at all with linear projects.  Line of Balance graphical display is just a plot that can be generated using good CPM/PDM scheduling software, not all software are as bad as not to be able to generate these displays.

I am not sure how the various software packages handle resource scheduling of ALAPs. –It would be nice if the algorithm allowed them to move to the left (assuming no driving predecessor), but I suspect this is not the case.

·   I understand MSP is different, I believe it means zero total float constraint instead of zero free float.            

Also, could you confirm my understanding is correct regarding the potential flaw in your model using milestone & neg lag (ie if the milestone predecessors progress as planned, but resources are not available for installation so it is delayed, then delivery is driven by the on-time predecessors and not the later installation date, hence wrong early dates for delivery)

·  There is no flaw, if for any reason a predecessor is delayed the milestone is delayed, the successors are delayed and the delivery is delayed as to keep the desired float or desired just in time logic.

1.     I agree that float is very important, but specific to this particular problem: it seems to me that your method guarantees correct early / late dates & hence float calcs for most (but NOT all) potential progress scenarios, and my method guarantees correct early dates for ALL progress scenarios, but ensures late dates & hence float is wrong. Neither method is perfect, and I am wondering which you think is more important –to ensure early dates are always correct at expense of float calcs, or to ensure float calcs are generally correct at the expense of certainty over early dates?

·  Model the problem exactly as suggested and test it, a single scenario shall be enough to make it invalid, just provide the single scenario using the model exactly as suggested.

You can download the XER file from the following link.

http://www.mediafire.com/download/si2fgukw4np3w02/RD020_1.xer

Finally, I 100% agree with you that use of unusual logic such as SF or neg lags should not be banned, but require justification. My advice to more junior planners however remains not to use them –They cause a lot more problems than they solve, in my experience.

·  But in this case the ALAP method yields incorrect schedule, yields incorrect float values, yields incorrect critical path as the delivery activities in most cases shall be scheduled with some float, then why insist on using wrong model?1.     OK I understand your point now. –Yes if you make an ALAP activity the only predecessor to another activity then it would shift it to the left, but the same would happen in your negative lag solution if the installation milestone had no predecessors, so I don’t see this as a reason not to use ALAP for deliveries.

·  But the suggested procedure requires the use of the installation milestone and that the installation milestone is a successor to all installation predecessors.  Therefore it will not move tom  the left, just try with the model as suggested, do not make changes, it would be a different model.

2.     Agreed limited trucks might be an issue (only projects I have come across where this was the case was on cross-country pipelines, which tend to be better planned using line of balance planning rather than CPM resource leveling IMO), but approval of submittals would be a separate (non-ALAP) activity to delivery, so not an issue.

·  Approval of submittals is not critical in the initial model, but schedules are not static and logic shall be correct so that if submittals are delayed they can become critical and the model shall still display correct early and late dates as well as correct float values.

I am not sure how the various software packages handle resource scheduling of ALAPs. –It would be nice if the algorithm allowed them to move to the left (assuming no driving predecessor), but I suspect this is not the case.

·  I understand MSP is different.                 

Also, could you confirm my understanding is correct regarding the potential flaw in your model using milestone & neg lag (ie if the milestone predecessors progress as planned, but resources are not available for installation so it is delayed, then delivery is driven by the on-time predecessors and not the later installation date, hence wrong early dates for delivery)

·  There is no flaw, if for any reason a predecessor is delayed the milestone is delayed, the successors are delayed and the delivery is delayed as to keep the desired float or desired just in time logic.  Note the software shows Start Flex, and this is relevant information for such cases as you might be interested in knowing how much you can increase beloved negative lag in this particular model.  Although I suspect Start and Finish Flex are unknown float values for most P6 users as P6 can only display total and free float and cannot even display side by side start float and finish float values. Superfloat another valuable metric is also lacking in P6 but a discussion of these would require a separate topic. 

1.     I agree that float is very important, but specific to this particular problem: it seems to me that your method guarantees correct early / late dates & hence float calcs for most (but NOT all) potential progress scenarios, and my method guarantees correct early dates for ALL progress scenarios, but ensures late dates & hence float is wrong. Neither method is perfect, and I am wondering which you think is more important –to ensure early dates are always correct at expense of float calcs, or to ensure float calcs are generally correct at the expense of certainty over early dates?

·  Model the problem exactly as suggested and test it, a single scenario shall be enough to make it invalid, just provide the single scenario using the model exactly as suggested.

·  Latter we can try with your ALAP model and test it with a desired float provision for the delivery (say 5 days float similar to my sample job), in the same way a single scenario shall be enough to prove it invalid, of course after you disclose your model as to follow it exactly then I will be willing to test it. You cand send me the XER file or even better post it on a file sharing server. Needless to remind you that good management of your deliveries shall allow for some float on your deliveries, otherwise the model is not good enough. 

Finally, I 100% agree with you that use of unusual logic such as SF or neg lags should not be banned, but require justification. My advice to more junior planners however remains not to use them –They cause a lot more problems than they solve, in my experience.

·  But in this case the ALAP method yields incorrect schedule, yields incorrect float values, yields incorrect critical path as the delivery activities in most cases shall be scheduled with some float, then why insist on using wrong model?

Gary, 1) See following figure, by adding a direct successor to delivery it was moved to the extreme left.  2) I was thinking on resources for delivery, it can be limited trucks or even limited resources for approval of submittals prior to shipping.  3) Correct early and late dates do matter, they define available float.  Without float you essentially have a Gantt Chart, it is logic what makes so useful CPM models, but it got to be good logic.  Float is the difference between Early and Late dates if you got them wrong you got wrong float values.  Unfortunately some belive if you got correct early dates then the model is correct and will automatically result in correct late dates.   I am oposed to specifications that prohibit unusual logic, it might be better not to prohibit them but to require such uncommon cases be substantiated.  Interesting discussion indeed, for your knowledge some of the arguments came out to my mind a few weeks ago, I am in a permanent state of learning.   Best regards,Rafael

The following shows on the lower figure how it would be if you do not use the milestone. It might look ok as even the few float values shown are equal but it is not safe as of predecessor P02 is not correctly linked and if delayed further than P01 the results will be wrong. If you link P02 to Delivery then P02 float values will be wrong.

I do not like the ALAP method as if you add a direct link to Delivery activity it will move to the left, in addition in case you want to model the delivery with some float the ALAP might not do the trick. 

Remember float values are relevant to Critical Path and resource leveling, make sure you get them right.

In the following figure you will see that using ALAP prevents delivery from having Free Float, so in this case ALAP is wrong modeling.  Never say never, that negative lag is usually wrong (99%) does not means it is always wrong, in this case ALAP is not even close to represent a good model while ironically beloved negative lag is a better alternative.  It is so wrong that it includes the Delivery on the critical path when in reality there is available float.

2 thumbs up to negative lag!

In your case for such long job I would use a larger absolute value for negative lag, perhaps -30 calendar days if your software is capable of defining lag calendar independent of predecessor/successor calendars.

Try modeling of delivery as just-in-time as per following figure. Note I used a milestone, necessary in case there are more than a single predecessor to determine delivery/installation.

I used some negative lag to create some float into the delivery as pure just in time might be risky.

Good luck.