(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.
Hi everyone,
I know this topic has been discussed before, but I haven't really found a solution I'm after.
So in my procurement schedule, I have milestones linked from delivery to construction called ROS (required on site), which I currently constrained to As Late As Possible to indicate where do I want the equipment on site. Works like a charm, shows float correclty and all. However, my client is not happy with this solution and my attempts to convince him that it's still a good practice, he wants me to remove the constraint.
Now, I could use reverse logic and link the milestone from start of construction, the problem is that P6 won't allow me to link it back to same activity as a successor (which will cause a loop) which means the milestone will have no successor, hence showing the TF incorrectly.
Just curious if anyone knows of any way to get around the issue and show the ROS where it should be without the use of ALAP.
Cheers
Tom
Printer-friendly version
Send to friend
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.
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.
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.
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.
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,
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).
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.
Email: PPadmin@planningplanet.com
Replies