My theory of relationships is that we use them for two reasons. The first is the laws of physics, you can’t put a pipe in a trench if you haven’t dug the trench. The second is that resources (essentially anything we count on the “y” axis) men, material, access, deck space, money, maximum permit count – the list is long – are not infinitely available, and we use relationships to help manage the restrictions/limitations. When we remove all of “type 2” relationships, our PERT network is likely to have lots of parallel tasks. Resource levelling should deal with this however we describe the “budget” for the resources.
Disappointingly, P6 lacks several key features. Some of which P3 had 30 years ago, and all of which Spider Project has now.
Proper control of splittable activities. If we have started a job, but a higher priority job that needs the same resource(s) becomes available, do we interrupt the first task? What is the minimum ”split” duration, what is the maximum split duration? (P3 didn’t quite get this right)
Stretching/Crunching. Simplistically, if the only job I can do takes 3 fitters, and I have 4 available, can I reduce the duration of the activity by using all four? Conversely, can I extend the duration if I have too few of a trade? (P3 nearly got this right)
Hard Lag. All lags in P6 are “soft”, i.e. not mandatary. For example, I isolate a valve, and then it is removed for service. In P6 a levelled schedule might show the valve isolated a week ago, because there are not enough fitters to do the actual work. I want a lag which is mandatory, the successor MUST start immediately the predecessor is finished ( no primavera product offered this)
I still have P3 running on an old laptop. The same one I have Suretrack on.
Member for
20 years 5 months
Member for20 years5 months
Submitted by Peter Holroyd on Sun, 2024-11-24 09:52
Member for
9 years 8 monthseh, no. My theory of
eh, no.
My theory of relationships is that we use them for two reasons. The first is the laws of physics, you can’t put a pipe in a trench if you haven’t dug the trench. The second is that resources (essentially anything we count on the “y” axis) men, material, access, deck space, money, maximum permit count – the list is long – are not infinitely available, and we use relationships to help manage the restrictions/limitations. When we remove all of “type 2” relationships, our PERT network is likely to have lots of parallel tasks. Resource levelling should deal with this however we describe the “budget” for the resources.
Disappointingly, P6 lacks several key features. Some of which P3 had 30 years ago, and all of which Spider Project has now.
Proper control of splittable activities. If we have started a job, but a higher priority job that needs the same resource(s) becomes available, do we interrupt the first task? What is the minimum ”split” duration, what is the maximum split duration? (P3 didn’t quite get this right)
Stretching/Crunching. Simplistically, if the only job I can do takes 3 fitters, and I have 4 available, can I reduce the duration of the activity by using all four? Conversely, can I extend the duration if I have too few of a trade? (P3 nearly got this right)
Hard Lag. All lags in P6 are “soft”, i.e. not mandatary. For example, I isolate a valve, and then it is removed for service. In P6 a levelled schedule might show the valve isolated a week ago, because there are not enough fitters to do the actual work. I want a lag which is mandatory, the successor MUST start immediately the predecessor is finished ( no primavera product offered this)
I still have P3 running on an old laptop. The same one I have Suretrack on.
Member for
20 years 5 monthsSo its a manual process of
So its a manual process of moving resources / budgets to top up gaps by presumably changing logic / durations etc. based on priority list?
Can't remember P3 doing this.
Member for
9 years 8 monthsWhat I usually do, is break
What I usually do, is break the work down into as many parallel jobs that can be done at the same time as possible.
Then allow the levelling to choose "enough" of these jobs to fill the availability, probably by an activity-level priority code.
Member for
9 years 8 monthsPeter, Tragically, you could
Peter,
Tragically, you could get P3 to do this in 1990. But P6 does not "crunch" during resource levelling.
The best way to do it is to transfer the data into Spider Project, complete the levelling, and send it back.
It is a shame that P6, which is a magnificent piece of late 2oth century software, remains unfinished.