Load leveling splits tasks

[andrewandrew]

I have an industrial project with several hundred tasks. I am using MSP's
load leveling algorithm twice a week during the execution of the project as
updates come in and things change. I am also rescheduling incomplete work to
start in the future. I understand that the rescheduling of incomplete work
creates some splits in tasks, and I am fine with that. What I don't
understand is why the load leveling is creating so many splits: I've cleared
the "Leveling can create splits in remaining work" option in the leveling
dialog, but leveling creates splits anyway, in some cases several splits in
the same task. I would rather not abandon the use of the leveling algorithm:
does anyone know why it is behaving this way? The only thing I want leveling
to do is change the values in the Leveling Delay field.

Thanks for the info!

Andrew

 

[andrewandrew]

Incidentally, all of the tasks that are splitting have only one resource on
them. Some have several resource units, but always on the same resource.

 

[andrewandrew]

I just put together a sample file to demonstrate my issue:

three tasks, all have the same resource, resource calendar is 24 hour with
no holidays or other edits. all have 'leveling can split' and 'level
assignments' set to no. the leveling dialog has these options unchecked as
well, and im leveling hour by hour, in priority, standard order. i use
priority a lot in my real projects.

the first task is set to priority 950, 0% complete.

the second task is prioty 950, 0% complete, with a SNET constraint that
lands it somewhere in the middle of the third task.

the third task is ~10x longer than the first two, has prioty 500, and is 25%
complete.

when I level this project is splits the third task to make room for the
higher priority task, and actually pulls the latter half of the split all the
way past the second task, which has a SNET constraint that puts it out in the
future somewhere. didn't i specify TWICE that I didn't want a split? what
gives?

thanks for any input!

Andrew

 

[andrewandrew]

To continue the example from the last post, if I turn of the "Split in
progress tasks" check box in Tools>Options>Schedule (what exactly does this
do, anyway?), none of the tasks split, but leveling doesn't resolve the
overallocations! Give it a try!

A

 

[andrewandrew]

That's a good point, Trevor. I've seen that happen before. I don't think
though that in this case that there are any constraints preventing leveling
delay from resolving overallocations--leveling doesn't need to split the
in-progress task, it can just delay the other two. There are no MSO
constraints, and no limit on the amount of leveling delay that can be
introduced.

 

[Steve House]

Task three is splitting because showing 25% complete means that work has
physically taken place on the dates currently shown and can't be moved for
any reason. Actual progress represents historical fact and you have told
MSP that those are the dates where work did take place. All resource
leveling can work with is the remaining, unworked portion of the task. If
another higher priority task is demanding the resource's attention on those
dates the unworked portion will move. But the portion of the task that has
been completed has to stay shown on the dates when its work did, in fact,
take place. The result is a task split regardless of your settings.

HTH

 

[Jan De Messemaeker]

Hi Steve,

I've looked at the case in depth and the poster is right, there's an anomaly
here. When you specify leveling cannot make splits in remaining work Project
Won't... except just after the actual work (it can in fact change the Resume
date). Pity, but alas;

--
Jan De Messemaeker
Microsoft Project MVP
http://users.online.be/prom-ade

Task three is splitting because showing 25% complete means that work has
physically taken place on the dates currently shown and can't be moved for
any reason. Actual progress represents historical fact and you have told
MSP that those are the dates where work did take place. All resource
leveling can work with is the remaining, unworked portion of the task. If
another higher priority task is demanding the resource's attention on
those dates the unworked portion will move. But the portion of the task
that has been completed has to stay shown on the dates when its work did,
in fact, take place. The result is a task split regardless of your
settings.

HTH

--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

I just put together a sample file to demonstrate my issue:

three tasks, all have the same resource, resource calendar is 24 hour
with
no holidays or other edits. all have 'leveling can split' and 'level
assignments' set to no. the leveling dialog has these options unchecked
as
well, and im leveling hour by hour, in priority, standard order. i use
priority a lot in my real projects.

the first task is set to priority 950, 0% complete.

the second task is prioty 950, 0% complete, with a SNET constraint that
lands it somewhere in the middle of the third task.

the third task is ~10x longer than the first two, has prioty 500, and is
25%
complete.

when I level this project is splits the third task to make room for the
higher priority task, and actually pulls the latter half of the split all
the
way past the second task, which has a SNET constraint that puts it out in
the
future somewhere. didn't i specify TWICE that I didn't want a split? what
gives?

thanks for any input!

Andrew

 

[Steve House]

Yes, that's what I see too but I wonder if that's a bad thing - in the
scenario he described how could the poster's task 3 NOT be split by leveling
regardless of the setting of the "leveling can create splits" permission? I
have two parallel tasks A and B scheduled to start together, both 5 days
duration, not linked. Joe is assigned to both tasks and NOT leveled. Task A
is a higher priority than task B but for some unknown reason Joe has started
work first on B for a couple of days without doing anything on A. At this
stage we resource level. It seems intuitive to me that work on B should
stop, the start of A should move to the first available date and Joe works
on A until it's finished before returning to work on B. After all, A is
higher in priority and we started B when we did by mistake - in fact we
should have started A. By splitting B we're correcting that mistake. If we
really do want B not to split and instead A move to start after B is
completed, we need to set B's priority higher than A. After all, that's
what priority means - a way of establishing preferred sequencing when
there's no process mandated sequencing to control it. The behaviour our
poster has observed seems perfectly logical to me unless I've misunderstood
his scenario.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

Hi Steve,

I've looked at the case in depth and the poster is right, there's an
anomaly here. When you specify leveling cannot make splits in remaining
work Project Won't... except just after the actual work (it can in fact
change the Resume date). Pity, but alas;

--
Jan De Messemaeker
Microsoft Project MVP
http://users.online.be/prom-ade

Task three is splitting because showing 25% complete means that work has
physically taken place on the dates currently shown and can't be moved
for any reason. Actual progress represents historical fact and you have
told MSP that those are the dates where work did take place. All
resource leveling can work with is the remaining, unworked portion of the
task. If another higher priority task is demanding the resource's
attention on those dates the unworked portion will move. But the portion
of the task that has been completed has to stay shown on the dates when
its work did, in fact, take place. The result is a task split regardless
of your settings.

HTH

--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

I just put together a sample file to demonstrate my issue:

three tasks, all have the same resource, resource calendar is 24 hour
with
no holidays or other edits. all have 'leveling can split' and 'level
assignments' set to no. the leveling dialog has these options unchecked
as
well, and im leveling hour by hour, in priority, standard order. i use
priority a lot in my real projects.

the first task is set to priority 950, 0% complete.

the second task is prioty 950, 0% complete, with a SNET constraint that
lands it somewhere in the middle of the third task.

the third task is ~10x longer than the first two, has prioty 500, and is
25%
complete.

when I level this project is splits the third task to make room for the
higher priority task, and actually pulls the latter half of the split
all the
way past the second task, which has a SNET constraint that puts it out
in the
future somewhere. didn't i specify TWICE that I didn't want a split?
what
gives?

thanks for any input!

Andrew

:

I have an industrial project with several hundred tasks. I am using
MSP's
load leveling algorithm twice a week during the execution of the
project as
updates come in and things change. I am also rescheduling incomplete
work to
start in the future. I understand that the rescheduling of incomplete
work
creates some splits in tasks, and I am fine with that. What I don't
understand is why the load leveling is creating so many splits: I've
cleared
the "Leveling can create splits in remaining work" option in the
leveling
dialog, but leveling creates splits anyway, in some cases several
splits in
the same task. I would rather not abandon the use of the leveling
algorithm:
does anyone know why it is behaving this way? The only thing I want
leveling
to do is change the values in the Leveling Delay field.

Thanks for the info!

Andrew

 

[andrewandrew]

Thank you Jan and Steve. I agree that the scheduling logic wherein an
in-progress task splits to make room for a higher priority task makes sense,
but I also know from personal experience that that's not always the behavior
that is desirable. I was hoping that I could turn off task splitting on
in-progress tasks by clearing the "Split in-progress tasks" check box, but
evidently that doesn't work, as indicated by Jan. As always, the most
powerful thing is to know how it works, so it's not the end of the world.

A

Yes, that's what I see too but I wonder if that's a bad thing - in the
scenario he described how could the poster's task 3 NOT be split by leveling
regardless of the setting of the "leveling can create splits" permission? I
have two parallel tasks A and B scheduled to start together, both 5 days
duration, not linked. Joe is assigned to both tasks and NOT leveled. Task A
is a higher priority than task B but for some unknown reason Joe has started
work first on B for a couple of days without doing anything on A. At this
stage we resource level. It seems intuitive to me that work on B should
stop, the start of A should move to the first available date and Joe works
on A until it's finished before returning to work on B. After all, A is
higher in priority and we started B when we did by mistake - in fact we
should have started A. By splitting B we're correcting that mistake. If we
really do want B not to split and instead A move to start after B is
completed, we need to set B's priority higher than A. After all, that's
what priority means - a way of establishing preferred sequencing when
there's no process mandated sequencing to control it. The behaviour our
poster has observed seems perfectly logical to me unless I've misunderstood
his scenario.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

Hi Steve,

I've looked at the case in depth and the poster is right, there's an
anomaly here. When you specify leveling cannot make splits in remaining
work Project Won't... except just after the actual work (it can in fact
change the Resume date). Pity, but alas;

--
Jan De Messemaeker
Microsoft Project MVP
http://users.online.be/prom-ade

Task three is splitting because showing 25% complete means that work has
physically taken place on the dates currently shown and can't be moved
for any reason. Actual progress represents historical fact and you have
told MSP that those are the dates where work did take place. All
resource leveling can work with is the remaining, unworked portion of the
task. If another higher priority task is demanding the resource's
attention on those dates the unworked portion will move. But the portion
of the task that has been completed has to stay shown on the dates when
its work did, in fact, take place. The result is a task split regardless
of your settings.

HTH

--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs


I just put together a sample file to demonstrate my issue:

three tasks, all have the same resource, resource calendar is 24 hour
with
no holidays or other edits. all have 'leveling can split' and 'level
assignments' set to no. the leveling dialog has these options unchecked
as
well, and im leveling hour by hour, in priority, standard order. i use
priority a lot in my real projects.

the first task is set to priority 950, 0% complete.

the second task is prioty 950, 0% complete, with a SNET constraint that
lands it somewhere in the middle of the third task.

the third task is ~10x longer than the first two, has prioty 500, and is
25%
complete.

when I level this project is splits the third task to make room for the
higher priority task, and actually pulls the latter half of the split
all the
way past the second task, which has a SNET constraint that puts it out
in the
future somewhere. didn't i specify TWICE that I didn't want a split?
what
gives?

thanks for any input!

Andrew

:

I have an industrial project with several hundred tasks. I am using
MSP's
load leveling algorithm twice a week during the execution of the
project as
updates come in and things change. I am also rescheduling incomplete
work to
start in the future. I understand that the rescheduling of incomplete
work
creates some splits in tasks, and I am fine with that. What I don't
understand is why the load leveling is creating so many splits: I've
cleared
the "Leveling can create splits in remaining work" option in the
leveling
dialog, but leveling creates splits anyway, in some cases several
splits in
the same task. I would rather not abandon the use of the leveling
algorithm:
does anyone know why it is behaving this way? The only thing I want
leveling
to do is change the values in the Leveling Delay field.

Thanks for the info!

Andrew

 

[Steve House]

Try setting the priority of the task who's splitting you need to prevent to
be higher than that of the other tasks and I think it'll do what you want.
Remember to tell it to use the "Priority, Standard" order in the leveling
setup screen. As I emtnioned, the idea of priority is to allow you to
assume manual control over the sequencing algorithm. Worked fine for my
couple of test tasks.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

Thank you Jan and Steve. I agree that the scheduling logic wherein an
in-progress task splits to make room for a higher priority task makes
sense,
but I also know from personal experience that that's not always the
behavior
that is desirable. I was hoping that I could turn off task splitting on
in-progress tasks by clearing the "Split in-progress tasks" check box, but
evidently that doesn't work, as indicated by Jan. As always, the most
powerful thing is to know how it works, so it's not the end of the world.

A

Yes, that's what I see too but I wonder if that's a bad thing - in the
scenario he described how could the poster's task 3 NOT be split by
leveling
regardless of the setting of the "leveling can create splits" permission?
I
have two parallel tasks A and B scheduled to start together, both 5 days
duration, not linked. Joe is assigned to both tasks and NOT leveled.
Task A
is a higher priority than task B but for some unknown reason Joe has
started
work first on B for a couple of days without doing anything on A. At
this
stage we resource level. It seems intuitive to me that work on B should
stop, the start of A should move to the first available date and Joe
works
on A until it's finished before returning to work on B. After all, A is
higher in priority and we started B when we did by mistake - in fact we
should have started A. By splitting B we're correcting that mistake. If
we
really do want B not to split and instead A move to start after B is
completed, we need to set B's priority higher than A. After all, that's
what priority means - a way of establishing preferred sequencing when
there's no process mandated sequencing to control it. The behaviour our
poster has observed seems perfectly logical to me unless I've
misunderstood
his scenario.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs



"Jan De Messemaeker" <jandemes at prom hyphen ade dot be> wrote in
message

Hi Steve,

I've looked at the case in depth and the poster is right, there's an
anomaly here. When you specify leveling cannot make splits in remaining
work Project Won't... except just after the actual work (it can in fact
change the Resume date). Pity, but alas;

--
Jan De Messemaeker
Microsoft Project MVP
http://users.online.be/prom-ade
"Steve House" <sjhouse at hotmail dot com> wrote in message
Task three is splitting because showing 25% complete means that work
has
physically taken place on the dates currently shown and can't be moved
for any reason. Actual progress represents historical fact and you
have
told MSP that those are the dates where work did take place. All
resource leveling can work with is the remaining, unworked portion of
the
task. If another higher priority task is demanding the resource's
attention on those dates the unworked portion will move. But the
portion
of the task that has been completed has to stay shown on the dates
when
its work did, in fact, take place. The result is a task split
regardless
of your settings.

HTH

--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs


message
I just put together a sample file to demonstrate my issue:

three tasks, all have the same resource, resource calendar is 24 hour
with
no holidays or other edits. all have 'leveling can split' and 'level
assignments' set to no. the leveling dialog has these options
unchecked
as
well, and im leveling hour by hour, in priority, standard order. i
use
priority a lot in my real projects.

the first task is set to priority 950, 0% complete.

the second task is prioty 950, 0% complete, with a SNET constraint
that
lands it somewhere in the middle of the third task.

the third task is ~10x longer than the first two, has prioty 500, and
is
25%
complete.

when I level this project is splits the third task to make room for
the
higher priority task, and actually pulls the latter half of the split
all the
way past the second task, which has a SNET constraint that puts it
out
in the
future somewhere. didn't i specify TWICE that I didn't want a split?
what
gives?

thanks for any input!

Andrew

:

I have an industrial project with several hundred tasks. I am using
MSP's
load leveling algorithm twice a week during the execution of the
project as
updates come in and things change. I am also rescheduling incomplete
work to
start in the future. I understand that the rescheduling of
incomplete
work
creates some splits in tasks, and I am fine with that. What I don't
understand is why the load leveling is creating so many splits: I've
cleared
the "Leveling can create splits in remaining work" option in the
leveling
dialog, but leveling creates splits anyway, in some cases several
splits in
the same task. I would rather not abandon the use of the leveling
algorithm:
does anyone know why it is behaving this way? The only thing I want
leveling
to do is change the values in the Leveling Delay field.

Thanks for the info!

Andrew

 

[Jan De Messemaeker]

Hi Steve,

Some tasks shouldn't be split, full stop.
Imagine a task that needs a big crane installed in say Vancouver for a
month.
Then if you need the crane for a one week job in Halifax, however urgent
that task is, you won't move the crane, transport it through the whole of
Canada to move it back one week later.

Unsplittable tasks nearly always deal with setting up machines (a slow
cooling process, once started, must use the cooling furnace till the end...)

--
Jan De Messemaeker
Microsoft Project MVP
http://users.online.be/prom-ade

Yes, that's what I see too but I wonder if that's a bad thing - in the
scenario he described how could the poster's task 3 NOT be split by
leveling regardless of the setting of the "leveling can create splits"
permission? I have two parallel tasks A and B scheduled to start
together, both 5 days duration, not linked. Joe is assigned to both tasks
and NOT leveled. Task A is a higher priority than task B but for some
unknown reason Joe has started work first on B for a couple of days
without doing anything on A. At this stage we resource level. It seems
intuitive to me that work on B should stop, the start of A should move to
the first available date and Joe works on A until it's finished before
returning to work on B. After all, A is higher in priority and we started
B when we did by mistake - in fact we should have started A. By splitting
B we're correcting that mistake. If we really do want B not to split and
instead A move to start after B is completed, we need to set B's priority
higher than A. After all, that's what priority means - a way of
establishing preferred sequencing when there's no process mandated
sequencing to control it. The behaviour our poster has observed seems
perfectly logical to me unless I've misunderstood his scenario.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

Hi Steve,

I've looked at the case in depth and the poster is right, there's an
anomaly here. When you specify leveling cannot make splits in remaining
work Project Won't... except just after the actual work (it can in fact
change the Resume date). Pity, but alas;

--
Jan De Messemaeker
Microsoft Project MVP
http://users.online.be/prom-ade

Task three is splitting because showing 25% complete means that work has
physically taken place on the dates currently shown and can't be moved
for any reason. Actual progress represents historical fact and you have
told MSP that those are the dates where work did take place. All
resource leveling can work with is the remaining, unworked portion of
the task. If another higher priority task is demanding the resource's
attention on those dates the unworked portion will move. But the
portion of the task that has been completed has to stay shown on the
dates when its work did, in fact, take place. The result is a task
split regardless of your settings.

HTH

--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs


I just put together a sample file to demonstrate my issue:

three tasks, all have the same resource, resource calendar is 24 hour
with
no holidays or other edits. all have 'leveling can split' and 'level
assignments' set to no. the leveling dialog has these options unchecked
as
well, and im leveling hour by hour, in priority, standard order. i use
priority a lot in my real projects.

the first task is set to priority 950, 0% complete.

the second task is prioty 950, 0% complete, with a SNET constraint that
lands it somewhere in the middle of the third task.

the third task is ~10x longer than the first two, has prioty 500, and
is 25%
complete.

when I level this project is splits the third task to make room for the
higher priority task, and actually pulls the latter half of the split
all the
way past the second task, which has a SNET constraint that puts it out
in the
future somewhere. didn't i specify TWICE that I didn't want a split?
what
gives?

thanks for any input!

Andrew

:

I have an industrial project with several hundred tasks. I am using
MSP's
load leveling algorithm twice a week during the execution of the
project as
updates come in and things change. I am also rescheduling incomplete
work to
start in the future. I understand that the rescheduling of incomplete
work
creates some splits in tasks, and I am fine with that. What I don't
understand is why the load leveling is creating so many splits: I've
cleared
the "Leveling can create splits in remaining work" option in the
leveling
dialog, but leveling creates splits anyway, in some cases several
splits in
the same task. I would rather not abandon the use of the leveling
algorithm:
does anyone know why it is behaving this way? The only thing I want
leveling
to do is change the values in the Leveling Delay field.

Thanks for the info!

Andrew

 

[Steve House]

Of course, no argument ... and as I posted, using the task priority setting
allows you to override the normal behaviour in those special cases.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

Hi Steve,

Some tasks shouldn't be split, full stop.
Imagine a task that needs a big crane installed in say Vancouver for a
month.
Then if you need the crane for a one week job in Halifax, however urgent
that task is, you won't move the crane, transport it through the whole of
Canada to move it back one week later.

Unsplittable tasks nearly always deal with setting up machines (a slow
cooling process, once started, must use the cooling furnace till the
end...)

--
Jan De Messemaeker
Microsoft Project MVP
http://users.online.be/prom-ade

Yes, that's what I see too but I wonder if that's a bad thing - in the
scenario he described how could the poster's task 3 NOT be split by
leveling regardless of the setting of the "leveling can create splits"
permission? I have two parallel tasks A and B scheduled to start
together, both 5 days duration, not linked. Joe is assigned to both
tasks and NOT leveled. Task A is a higher priority than task B but for
some unknown reason Joe has started work first on B for a couple of days
without doing anything on A. At this stage we resource level. It seems
intuitive to me that work on B should stop, the start of A should move to
the first available date and Joe works on A until it's finished before
returning to work on B. After all, A is higher in priority and we
started B when we did by mistake - in fact we should have started A. By
splitting B we're correcting that mistake. If we really do want B not to
split and instead A move to start after B is completed, we need to set
B's priority higher than A. After all, that's what priority means - a
way of establishing preferred sequencing when there's no process mandated
sequencing to control it. The behaviour our poster has observed seems
perfectly logical to me unless I've misunderstood his scenario.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

Hi Steve,

I've looked at the case in depth and the poster is right, there's an
anomaly here. When you specify leveling cannot make splits in remaining
work Project Won't... except just after the actual work (it can in fact
change the Resume date). Pity, but alas;

--
Jan De Messemaeker
Microsoft Project MVP
http://users.online.be/prom-ade
"Steve House" <sjhouse at hotmail dot com> wrote in message
Task three is splitting because showing 25% complete means that work
has physically taken place on the dates currently shown and can't be
moved for any reason. Actual progress represents historical fact and
you have told MSP that those are the dates where work did take place.
All resource leveling can work with is the remaining, unworked portion
of the task. If another higher priority task is demanding the
resource's attention on those dates the unworked portion will move.
But the portion of the task that has been completed has to stay shown
on the dates when its work did, in fact, take place. The result is a
task split regardless of your settings.

HTH

--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs


message I just put together a sample file to demonstrate my issue:

three tasks, all have the same resource, resource calendar is 24 hour
with
no holidays or other edits. all have 'leveling can split' and 'level
assignments' set to no. the leveling dialog has these options
unchecked as
well, and im leveling hour by hour, in priority, standard order. i use
priority a lot in my real projects.

the first task is set to priority 950, 0% complete.

the second task is prioty 950, 0% complete, with a SNET constraint
that
lands it somewhere in the middle of the third task.

the third task is ~10x longer than the first two, has prioty 500, and
is 25%
complete.

when I level this project is splits the third task to make room for
the
higher priority task, and actually pulls the latter half of the split
all the
way past the second task, which has a SNET constraint that puts it out
in the
future somewhere. didn't i specify TWICE that I didn't want a split?
what
gives?

thanks for any input!

Andrew

:

I have an industrial project with several hundred tasks. I am using
MSP's
load leveling algorithm twice a week during the execution of the
project as
updates come in and things change. I am also rescheduling incomplete
work to
start in the future. I understand that the rescheduling of incomplete
work
creates some splits in tasks, and I am fine with that. What I don't
understand is why the load leveling is creating so many splits: I've
cleared
the "Leveling can create splits in remaining work" option in the
leveling
dialog, but leveling creates splits anyway, in some cases several
splits in
the same task. I would rather not abandon the use of the leveling
algorithm:
does anyone know why it is behaving this way? The only thing I want
leveling
to do is change the values in the Leveling Delay field.

Thanks for the info!

Andrew

 

[Jan De Messemaeker]

Hi Steve,

Yes indeed.
I've been thinking, if I ever have to consult in these situations, I'd write
a small macro:
If %complete between 0 and 100 AND Leveling can split is Off then set
priority to 1000.

Greetings,

--
Jan De Messemaeker
Microsoft Project MVP
http://users.online.be/prom-ade

Of course, no argument ... and as I posted, using the task priority
setting allows you to override the normal behaviour in those special
cases.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

Hi Steve,

Some tasks shouldn't be split, full stop.
Imagine a task that needs a big crane installed in say Vancouver for a
month.
Then if you need the crane for a one week job in Halifax, however urgent
that task is, you won't move the crane, transport it through the whole of
Canada to move it back one week later.

Unsplittable tasks nearly always deal with setting up machines (a slow
cooling process, once started, must use the cooling furnace till the
end...)

--
Jan De Messemaeker
Microsoft Project MVP
http://users.online.be/prom-ade

Yes, that's what I see too but I wonder if that's a bad thing - in the
scenario he described how could the poster's task 3 NOT be split by
leveling regardless of the setting of the "leveling can create splits"
permission? I have two parallel tasks A and B scheduled to start
together, both 5 days duration, not linked. Joe is assigned to both
tasks and NOT leveled. Task A is a higher priority than task B but for
some unknown reason Joe has started work first on B for a couple of days
without doing anything on A. At this stage we resource level. It seems
intuitive to me that work on B should stop, the start of A should move
to the first available date and Joe works on A until it's finished
before returning to work on B. After all, A is higher in priority and
we started B when we did by mistake - in fact we should have started A.
By splitting B we're correcting that mistake. If we really do want B
not to split and instead A move to start after B is completed, we need
to set B's priority higher than A. After all, that's what priority
means - a way of establishing preferred sequencing when there's no
process mandated sequencing to control it. The behaviour our poster has
observed seems perfectly logical to me unless I've misunderstood his
scenario.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs



"Jan De Messemaeker" <jandemes at prom hyphen ade dot be> wrote in
message Hi Steve,

I've looked at the case in depth and the poster is right, there's an
anomaly here. When you specify leveling cannot make splits in remaining
work Project Won't... except just after the actual work (it can in fact
change the Resume date). Pity, but alas;

--
Jan De Messemaeker
Microsoft Project MVP
http://users.online.be/prom-ade
"Steve House" <sjhouse at hotmail dot com> wrote in message
Task three is splitting because showing 25% complete means that work
has physically taken place on the dates currently shown and can't be
moved for any reason. Actual progress represents historical fact and
you have told MSP that those are the dates where work did take place.
All resource leveling can work with is the remaining, unworked portion
of the task. If another higher priority task is demanding the
resource's attention on those dates the unworked portion will move.
But the portion of the task that has been completed has to stay shown
on the dates when its work did, in fact, take place. The result is a
task split regardless of your settings.

HTH

--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs


message I just put together a sample file to demonstrate my issue:

three tasks, all have the same resource, resource calendar is 24 hour
with
no holidays or other edits. all have 'leveling can split' and 'level
assignments' set to no. the leveling dialog has these options
unchecked as
well, and im leveling hour by hour, in priority, standard order. i
use
priority a lot in my real projects.

the first task is set to priority 950, 0% complete.

the second task is prioty 950, 0% complete, with a SNET constraint
that
lands it somewhere in the middle of the third task.

the third task is ~10x longer than the first two, has prioty 500, and
is 25%
complete.

when I level this project is splits the third task to make room for
the
higher priority task, and actually pulls the latter half of the split
all the
way past the second task, which has a SNET constraint that puts it
out in the
future somewhere. didn't i specify TWICE that I didn't want a split?
what
gives?

thanks for any input!

Andrew

:

I have an industrial project with several hundred tasks. I am using
MSP's
load leveling algorithm twice a week during the execution of the
project as
updates come in and things change. I am also rescheduling incomplete
work to
start in the future. I understand that the rescheduling of
incomplete work
creates some splits in tasks, and I am fine with that. What I don't
understand is why the load leveling is creating so many splits: I've
cleared
the "Leveling can create splits in remaining work" option in the
leveling
dialog, but leveling creates splits anyway, in some cases several
splits in
the same task. I would rather not abandon the use of the leveling
algorithm:
does anyone know why it is behaving this way? The only thing I want
leveling
to do is change the values in the Leveling Delay field.

Thanks for the info!

Andrew