Re: Month by month resource leveling results in overallocated reso

OK, I get it. I'll end this string now. I still don't think I've gotten to
the root cause of my original problem, but I've figured out how to work
around it. Thanks for all your insight.
--
April


"Steve House" wrote:

Let's say he's available 50% of the time to make the numbers easier on our
heads. He has to do Task X whose deliverable requires 4 man-hours of work
effort to create. Do you want that to show in the project plan as an 8 hour
duration task work taking place during an unknown 4 hours sometime during
the day or do you want to show it as a task lasting 4 hours from start to
finish? IMHO, it's better to show it 4 hours start to finish but it could
go either way. What gives you the more accurate model to allow you to do
hands dirty management of the resource's work and predict the delivery dates
of the major milestone events?
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs


"AprilPM" <AprilPM@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:2A0D37D4-1C0A-4A31-AE30-3E9C03E92310@xxxxxxxxxxxxxxxx
OK, I think I'm following you, but don't you get tangled up when you start
recording actual hours worked? And what if a resource truly is only
available to me, say, 30% of the time because he's working on other
projects?
--
April


"Steve House" wrote:

It does require some mental gymnastics to keep it all straight, at least
for
me. Your practice of assigning at a 70% level means that when you look
at a
plan that has Bill assigned to a task that shows a duration of 8 hours,
starting Monday at 8am and ending at 5pm, it really means that Bill will
work on it for 6 hours sometime between 8 and 5. The hours work out, of
course, but it's going to be hard to be 100% consistent. It's not too
bad
for one day tasks but gets harder to wrap your mind around with longer
tasks.

I agree with you about not micromanaging the employees, avoiding telling
them in too much detail what hours of the day to work on something. But
you
need to do it a little since you not only need to schedule Bill's work
but
you also have to tell Mary, who's doing the task dependent on Bill's,
when
he'll be finished on his part so she can start on her's. With your
method,
you can't say if the task will be done at 3pm or 5pm. Not too bad for a
1
day task, you can just tell Mary to be ready to roll on Tuesday morning.
But lets say the task is a week long - should Mary be ready to go on
Thursday at noon or should we tell her not to worry about it until the
following Monday at 8? That's bit more problematic if the objective is
to
develop the most efficient project work schedule that leads to the
earliest
finish date.

One thought I have regarding holding back time for legacy apps, email,
etc
starts with the notion of just how you are able to know how much work a
task
will require in the first place. It's especially difficult when it comes
to
managing intangible or creative work like programming - how do you
accurately estimate just how long it will take someone to hatch an idea
anyway? Whether tangible or intangible you have to fall back on history.
If you have to wax 100 widgets and need to estimate the work required -
what
do you look at? You look for other times you've waxed widgets and see
how
long it took you then. But those records rarely detail hour by hour what
the resource was doing - you know it took Bill about a week last year but
you don't have a step by step record of his day, merely the fact he
worked
on it during the second week of March. So we estimate it'll take a week
this year. But wait - last year he also had to maintain legacy apps, do
email, chat a bit at the watercooler, etc. So that 2nd week of March was
actually a combination of some hours working on widgets and some hours
doing
other stuff but we really just guessing about the mix. So for our
project
planning purposes we can just ignore the other stuff and assume all the
hours of the week were spent in working on widgets - after all, the
objective of project planning is to figure out a work schedule that lets
us
deliver the widgets by the contractually required dates along with giving
us
an estimate of what it's going to cost us to do it - the firm's detailed
hour-by-hour staffing budgets really aren't part of the process.
Estimate a
week's duration with him at 100% and be done with it. We'll know that not
all of those hours are spent physically working on the widgets but we
don't
really care - all we really care about in terms of completing the project
is
when he'll start and when he'll be done.

Just a few thought, hope they help

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



"AprilPM" <AprilPM@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:F9A24B75-71EC-4F97-9080-8BF0F28BE762@xxxxxxxxxxxxxxxx
Wow. I guess I've really been confused on the resource availability
bit.
(Though the priority explanation was as I expected it...thanks for the
detailed explanation.) I have two people on the team who are part-time
employees; that's how I get to 7.2 FTE's. On average, a programmer is
only
available for project work 70% of the time with the other 30% being
used
for
support of legacy products, and stuff like education, PTO, etc. So I
never
have put a resource, say "Bill," as being 100% available; I always use
70%
(or whatever number is right for Bill....when I get to assigning a
specific
programmer, I may know that that person is available for more or less
than
70% of their time.) Still, I don't understand why this would not work
out
to essentially the same thing. My situation must be pretty common.
How
do
you suggest I account for it? Do I use a shortened workday? I don't
schedule tasks to the level of detail where the specific hours that an
employee works during the day matter.
--
April


"Steve House" wrote:

Summary tasks aren't really tasks ... in fact they more resemble
reports,
serving to rollup their subtasks which represent the real deal. In
fact,
in a properly designed and detailed plan, if you deleted all the
summary
tasks while leaving all the lowest level subtasks intact, all of the
work
in
the project would still get done.

Task priorities control the scheduling of a resource's work when the
resource exceeds his maximum due to being assigned to several
concurrent
tasks. But since summaries are a:reports, not physical work
activities;
and
b: should never have resources assigned to them, their priority
settings
are
meaningless. Subtasks don't inherit their parent's priorities,
instead
the
summaries are driven by the priorities of their children.

I'm confused as to your resource availability setting as you described
it
in
your intial post - I'm wondering if this has something to do with your
issue. You said your resource was "software" with 7.2 FTEs available
about
70% of the time to give you a maximum availability of 500%. The
resource
assignment percentage is fundamentally a measure of the rate at which
a
resource generatess work output over time. A 70% assignment means
that
when
the resource is working on something for a solid 8 hour day, for some
reason
they can only generate the amount of work that would normally only
require
about 6 hours to complete. While if you think in terms of days it
seems
to
work out the same, it doesn't really mean they are available to work
exclusive on the project tasks for 6 hours out of their 8 with the
other
2
hours reserved for other activity. A task that requires 6 hours of
work
with the resource giving it his full attention is not an 8 hour
duration
task with a resource assigned 75%. Rather it is a 6 hour duration
task
that
has the resource on it 100%. Also, I interpret an FTE as a warm
body -
when
your plan gets to the point of assigning real resouces, each FTE will
become
a real live human being Joe or Mary or Bill or a piece of equipment,
bulldozer serial XXXXX. So how do you get a "0.2" person? You'd also
expect Joe to devote his full attention to the work he's been assigned
to,
ie. work at a 100% level. So I wonder if it would help your situation
to
go
ahead and reflect that in your planning now by making your resource
700%
reflecting that the group is made up of 7 individuals, each of whom is
available for task assigments which require their full attention from
start
to finish?

Just sharing some ideas - hope this helps
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs


"AprilPM" <AprilPM@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:7050D9C5-3CA1-42E0-AA90-1123A18FEFCC@xxxxxxxxxxxxxxxx
A little more data. I played around with the priority. Everything
works
as
expected if I set the priority of this task to 500, ie, no resources
appear
to be over-allocated after leveling. However, as soon as I make its
priority
higher than 500 (600, 700, 800, or 900), the problem shows up again,
ie,
my
resource gets way over-allocated after leveling, and some of those
over-allocated months are not flagged with red. Of course, the
start
date
changes every time I change the priority, as it should. I knew 1000
priority
was a magic number (ie, the tasks are not affected by leveling), but
I
didn't
think there was anything special about the other priorities? It's
almost
like MSP has the mind of an executive: "Wow! This is a really
important
project! I better work my resources at 50% OT for the duration of
this
project!" Also, does the priority of the summary task affect it at
all? I
leave the summary task at the default (500) and only assign
priorities
to
the subtasks. I know under most circumstances that doesn't really
make
sense
but in this case my summary task is "Future Projects" and I have the
future
projects listed underneath that, each with a gross
effort/duration/resource
assignment, and their own priorites.

--
April


"AprilPM" wrote:

I am having trouble with resource leveling. I'm using MSP
Professional
Desktop edition.
I have a resource, "software," who is available 500% (7.2 FTE's at
about
70%
utilization).
I have a number of in-process tasks that I don't want to affect, so
I
set
them to priority 1000.
Future tasks have various priority, all less than 1000.
I have "month by month" leveling set.
The leveling order set to "Priority, Standard."
All other checkboxes in "resolving allocations" are unchecked.
I "clear leveling," then "level now."
I would expect to see no more than about 860 hours per month for
this
resource after all the priority 1000 tasks are out of the way.
However, I see 1012 hours in January '08. In fact, December
through
May
are
all over allocated with more than 900 hours (only December and
February
are
flagged as red, but I ignore the colorÃf¢?Ã,¦too deceiving.)
Upon investigation, I see that MSP has started a 900 priority task
which
requires a big portion of my "software" resource at this point in
.

Relevant Pages

  • Re: Month by month resource leveling results in overallocated reso
    ... Insofar Summary tasks don't have resources of their own, yes, their priority ... Summary task A is a priority 900, ... "Jan De Messemaeker" wrote: ... One you can check is insert the columln "can level" in the resource ...
    (microsoft.public.project)
  • Re: Month by month resource leveling results in overallocated reso
    ... "Jan De Messemaeker" wrote: ... Insofar Summary tasks don't have resources of their own, yes, their priority ... Summary task A is a priority 900, ... One you can check is insert the columln "can level" in the resource ...
    (microsoft.public.project)
  • Re: Month by month resource leveling results in overallocated reso
    ... Your practice of assigning at a 70% level means that when you look at a plan that has Bill assigned to a task that shows a duration of 8 hours, starting Monday at 8am and ending at 5pm, it really means that Bill will work on it for 6 hours sometime between 8 and 5. ... But those records rarely detail hour by hour what the resource was doing - you know it took Bill about a week last year but you don't have a step by step record of his day, merely the fact he worked on it during the second week of March. ... should never have resources assigned to them, their priority settings are ... does the priority of the summary task affect it at> all? ...
    (microsoft.public.project)
  • Re: Month by month resource leveling results in overallocated resource
    ... But since summaries are a:reports, not physical work activities; and b: should never have resources assigned to them, their priority settings are meaningless. ... I'm confused as to your resource availability setting as you described it in your intial post - I'm wondering if this has something to do with your issue. ... A 70% assignment means that when the resource is working on something for a solid 8 hour day, for some reason they can only generate the amount of work that would normally only require about 6 hours to complete. ... does the priority of the summary task affect it at all? ...
    (microsoft.public.project)
  • Re: Month by month resource leveling results in overallocated reso
    ... I guess I've really been confused on the resource availability bit. ... should never have resources assigned to them, their priority settings are ... A 70% assignment means that when ... does the priority of the summary task affect it at all? ...
    (microsoft.public.project)