Marking a resource as overallocated when they don't appear to be

[Seann]

I have two resources in my project file that are marked Bold/Red in the
resource usage page, indicating overallocation.

As I scroll through the dates, the days that are marked red are actually
days in the past. The resources were scheduled at 6.8hrs (85%) on those days,
yet the actual work they applied to their tasks was 5.5 and 5 respectively. I
don't understand why project would mark these (RED) as overallocated when
they don't appear to be.

We have leveled the project with no effect to these two days.

 

[Jan De Messemaeker]

Hi,

The best explanation can be found in FAQ 34: Overallocation occurs in less
than one day at
http://project.mvps.org/faqs.htm

Greetings,

 

[John]

I have two resources in my project file that are marked Bold/Red in the
resource usage page, indicating overallocation.

As I scroll through the dates, the days that are marked red are actually
days in the past. The resources were scheduled at 6.8hrs (85%) on those days,
yet the actual work they applied to their tasks was 5.5 and 5 respectively. I
don't understand why project would mark these (RED) as overallocated when
they don't appear to be.

We have leveled the project with no effect to these two days.

Seann,
You have to understand how Project views overallocation. It is based on
several factors such as the number of work hours in a day
(Tools/Options/Calendar tab), the Max Units for a resource (Resource
Sheet) and the resource's calendar if different from the project
calendar.

If two tasks occur simultaneously such that a given resource is assigned
to work those tasks and the total amount of work is more than 8 hours in
a day, or even 60 minutes in any given hour, than that resource will be
overallocated.

You mentioned that the tasks are already complete (i.e. actual hours
have been entered). Project's leveling function has no effect on what
has already happened - history can't be changed (although historians
tell us it does repeat). All it can do is to help resolve future
overallocations. However I caution you, using the leveling function
should be a last resort after you have manually reviewed the schedule
and changed it as appropriate to resolve resource scheduling conflicts.
Why? Because sometimes the fixed algorithm in the leveling function does
things that you don't want (e.g. levels your plan out to 2049). It is
just the nature of non-neural logic.

John
Project MVP

 

[Seann]

Seann,
You have to understand how Project views overallocation. It is based on
several factors such as the number of work hours in a day
(Tools/Options/Calendar tab), the Max Units for a resource (Resource
Sheet) and the resource's calendar if different from the project
calendar.

If two tasks occur simultaneously such that a given resource is assigned
to work those tasks and the total amount of work is more than 8 hours in
a day, or even 60 minutes in any given hour, than that resource will be
overallocated.

You mentioned that the tasks are already complete (i.e. actual hours
have been entered). Project's leveling function has no effect on what
has already happened - history can't be changed (although historians
tell us it does repeat). All it can do is to help resolve future
overallocations. However I caution you, using the leveling function
should be a last resort after you have manually reviewed the schedule
and changed it as appropriate to resolve resource scheduling conflicts.
Why? Because sometimes the fixed algorithm in the leveling function does
things that you don't want (e.g. levels your plan out to 2049). It is
just the nature of non-neural logic.

John
Project MVP

The problem here was in fact that for whatever reason project was trying to
schedule two tasks with the same hour, even though we were not forcing that.
We manually fixed this and it resolved the over allocation. It's not clear to
me how or why these tasks would have been scheduled within the same hour if
we did not manually force it.

In terms of your warning about leveling, I'm surprised to hear that you're
recommending against. I'm big supporter of leveling within my organization as
long as you know what your doing and how to control it. For example we
typically level once at the very beginning of a project for all resources. We
level by ID Only, hour by hour, manually only, and only allow the option for
project to split tasks where necessary. Then once the project file is live
we typically level one resource at a time for specific date range. I have
found that putting these types of clamps on the leveling function results in
a much more controled outcome.

I'm interested to know what you mean by "manually" reviewed the schedule.

 

[Jan De Messemaeker]

Hello Seann,

When you somehow define a task's start by day without specifying the hour of
day, it will start on the default start hour.
And when there's several of them, they'll all start on the same hour.
The default is the same for all so the result will be the same.

And like you, I am very, very strong PRO-LEVELING.
Personally I will only enter resources in a plan when I intend to level, if
not it isn't worth the investment.
Task linking and constraining is one half of Project, Leveling is the other
half.
So why limping on one leg?

Greetings,

 

[John]

The problem here was in fact that for whatever reason project was trying to
schedule two tasks with the same hour, even though we were not forcing that.
We manually fixed this and it resolved the over allocation. It's not clear to
me how or why these tasks would have been scheduled within the same hour if
we did not manually force it.

In terms of your warning about leveling, I'm surprised to hear that you're
recommending against. I'm big supporter of leveling within my organization as
long as you know what your doing and how to control it. For example we
typically level once at the very beginning of a project for all resources. We
level by ID Only, hour by hour, manually only, and only allow the option for
project to split tasks where necessary. Then once the project file is live
we typically level one resource at a time for specific date range. I have
found that putting these types of clamps on the leveling function results in
a much more controled outcome.

I'm interested to know what you mean by "manually" reviewed the schedule.

Seann,
I think Jan addressed the overallocation issue and it sounds like you
have it resolved.

With regard to leveling. In your case it sounds like you have a pretty
good process for using the leveling function. Unfortunately I don't
think that is the norm. A lot of users want a quick solution to their
scheduling problems so they try whatever whistles and bells the
application has to "take care of it". Since scheduling attempts to
emulate the dynamics of real life, there is just no substitute for a
savy project manager who keeps close tabs on what the schedule is doing
and can tell when it is giving bogus information. That's what I mean by
"manually" reviewing the schedule.

Leveling can be a very useful tool, as long as it is used for that and
not as a substitute for good planning based on experience.

John
Project MVP