Consider using a Dummy fixed by SF(negative lag) to installation activity, with no successor. The negative lag will represent desired buffer. Update dummy dates in sync with real delivery activity and do not duplicate costs or resources on dummy.
Dummy activity will drive nothing but will tell you when to execute it to meet the desired target of just in time with some buffer. Having a negative lag on such a dummy activity is no sin as it will drive nothing and will have no impact on the schedule other than being a dynamic marker. Real delivery activity will not delay installation until all remaining buffer is consumed and you will always have true float visibility as long as you disregard dummy activity float values, these are meaningless.
Many of us do not consider good practice modeling buffers within the duration of an activity or as a lag, unconsumed buffers shall never drive activities as lag can do.
Good luck.
Member for
21 years 8 months
Member for21 years8 months
Submitted by Rafael Davila on Fri, 2015-07-10 13:38
Another option could be to keep a second schedule using the ALAP strategy and use it as a comparison schedule or comparison baseline. This can be time consuming if your software does not provide for easy transfer of update data. I use software that provides for easy transfer of update data but still prefer to avoid the two schedules approach as much as possible.
@Zoltan: I think your solution to constrain the milestones to ALAP and remove it after recalculating is the cleanest, but it carries a risk of dates changing if someone F9's the schedule.
@Johannes: the No Earlier Than constraint will surely be questioned by my client simply because it's a constraint and he wants to reduce the number of constraints to absolute minimum - hence his original comment about ALAP.
The rules I have to follow are:
- minimum number of constraints
- no negative lags
- no SF logic
- no open ended activities
not easy to do what I'm trying to achieve...
One other option would be to make the ROS a start milestone, link it FROM construction activity SS (+lag for safety buffer), leave the open end on milestone and in calculation settings select "Make open ended activites critical", but then it violates the open end criteria and still shows the float incorrectly.
The backward logic is a good start but I need to find a way to close the open end to show the float correclty.
Member for
15 years 9 months
Member for15 years9 months
Submitted by Johannes Vandenberg on Thu, 2015-07-09 15:41
I suggest to use a soft constraint like "not earlier then".
ALAP constraint is difficult to manage and this leaves no float unless an lead is applied.
The use of "not earlier then" constrained is that the activity remains at its position. On the frond-end, link it to the procurement delivery activity. When the delivery activity is delayed the "delivery time buffer shall be decreased.
On the successor activities you can monitor the time buffer between the ROS date and the actual construction requirement.
Regards
Johannes
Member for
16 years 3 months
Member for16 years3 months
Submitted by Zoltan Palffy on Thu, 2015-07-09 15:15
Raymunds solution to convert the gap into a lag between delivery period and approval period, then remove the ALAP. However this will have to be done during each update or you will have to manage the lags increasing them or decreasing them to match what the ALAP date would be.
I guees you cant use an expected finish date in the delivery of the procurment item either. Same thing would apply you would have to change the XF dates to match what the ALAP dates would be.
I am thinking that maybe a global chanage from xf to ALAP, recaculate the schedule then global change back to XF
another way to do it would be to use the ALAP recalcute the schedule then remove the ALAP. As long as no one recacluates the schedule then the activities will hold the ALAP date. Gets you what you want and what the client wants.
Member for
15 years 11 months
Member for15 years11 months
Submitted by Raymund de Laza on Thu, 2015-07-09 11:54
Procurement includes when to submit the Item, when is the expected approval, when will be the PO finalized and how long is the lead for delivery upon PO issued.
Usually, as much as possible all items are required to be approved as earlier as possible, but we can not requires delivery at earlier stage due to Warehousing or Storing problems specially for Activities that are to be executed at later dates.
In this case, delivery can be delayed but Approval and PO shall be done earlier. Which means that there will be a big gap between PO and Delivery Period for items that are to be used for the Activities that are to be executed at later dates.
Your idea will require you to use a negative lag, which I think is not advisable.
We have the same method of using the ALAP and also encountered the same comments from the client.
My solution is that apply the ALAP in order to establish the dates of the Delivery to Site, then convert the gap into a lag between delivery period and approval period, then remove the ALAP.
Member for
21 years 8 monthsConsider using a Dummy fixed
Consider using a Dummy fixed by SF(negative lag) to installation activity, with no successor. The negative lag will represent desired buffer. Update dummy dates in sync with real delivery activity and do not duplicate costs or resources on dummy.
Dummy activity will drive nothing but will tell you when to execute it to meet the desired target of just in time with some buffer. Having a negative lag on such a dummy activity is no sin as it will drive nothing and will have no impact on the schedule other than being a dynamic marker. Real delivery activity will not delay installation until all remaining buffer is consumed and you will always have true float visibility as long as you disregard dummy activity float values, these are meaningless.
Many of us do not consider good practice modeling buffers within the duration of an activity or as a lag, unconsumed buffers shall never drive activities as lag can do.
Good luck.
Member for
21 years 8 monthsAnother option could be to
Another option could be to keep a second schedule using the ALAP strategy and use it as a comparison schedule or comparison baseline. This can be time consuming if your software does not provide for easy transfer of update data. I use software that provides for easy transfer of update data but still prefer to avoid the two schedules approach as much as possible.
Member for
12 years 8 monthsThanks for your input
Thanks for your input guys.
@Zoltan: I think your solution to constrain the milestones to ALAP and remove it after recalculating is the cleanest, but it carries a risk of dates changing if someone F9's the schedule.
@Johannes: the No Earlier Than constraint will surely be questioned by my client simply because it's a constraint and he wants to reduce the number of constraints to absolute minimum - hence his original comment about ALAP.
The rules I have to follow are:
- minimum number of constraints
- no negative lags
- no SF logic
- no open ended activities
not easy to do what I'm trying to achieve...
One other option would be to make the ROS a start milestone, link it FROM construction activity SS (+lag for safety buffer), leave the open end on milestone and in calculation settings select "Make open ended activites critical", but then it violates the open end criteria and still shows the float incorrectly.
The backward logic is a good start but I need to find a way to close the open end to show the float correclty.
Member for
15 years 9 monthsHi Thomasz I suggest to use a
Member for
16 years 3 monthsRaymunds solution to convert
Raymunds solution to convert the gap into a lag between delivery period and approval period, then remove the ALAP. However this will have to be done during each update or you will have to manage the lags increasing them or decreasing them to match what the ALAP date would be.
I guees you cant use an expected finish date in the delivery of the procurment item either. Same thing would apply you would have to change the XF dates to match what the ALAP dates would be.
I am thinking that maybe a global chanage from xf to ALAP, recaculate the schedule then global change back to XF
another way to do it would be to use the ALAP recalcute the schedule then remove the ALAP. As long as no one recacluates the schedule then the activities will hold the ALAP date. Gets you what you want and what the client wants.
Member for
15 years 11 monthsTom,Procurement includes when
Tom,
Procurement includes when to submit the Item, when is the expected approval, when will be the PO finalized and how long is the lead for delivery upon PO issued.
Usually, as much as possible all items are required to be approved as earlier as possible, but we can not requires delivery at earlier stage due to Warehousing or Storing problems specially for Activities that are to be executed at later dates.
In this case, delivery can be delayed but Approval and PO shall be done earlier. Which means that there will be a big gap between PO and Delivery Period for items that are to be used for the Activities that are to be executed at later dates.
Your idea will require you to use a negative lag, which I think is not advisable.
Regards,
Member for
12 years 8 monthsThanks Raymund - the lag is a
Thanks Raymund - the lag is a solution, however it will conceal the TF in procurement activities, which is not ideal.
While we at the ROS, do people double up the links? I mean:
1. link from delivery to ROS and ROS to construction and
2. link from delivery to construction?
Otherwise it's difficult to trace the logic (without link 2) and see which procurement package drives the construction.
Just asking becasue in general doubling up on the logic can be seen as a bad practice (not that it makes much difference to the schedule).
Member for
15 years 11 monthsTom,We have the same method
Tom,
We have the same method of using the ALAP and also encountered the same comments from the client.
My solution is that apply the ALAP in order to establish the dates of the Delivery to Site, then convert the gap into a lag between delivery period and approval period, then remove the ALAP.
I hope this will help.